[PATCH v9 09/10] kselftest: save-and-restore errno to allow for %m formatting

Previously, using "%m" in a ksft_* format string can result in strange output because the errno value wasn't saved before calling other libc functions. The solution is to simply save and restore the errno before we format the user-supplied format string. Signed-off-by: Aleksa Sarai ---

[PATCH v9 08/10] open: openat2(2) syscall

The most obvious syscall to add support for the new LOOKUP_* scoping flags would be openat(2). However, there are a few reasons to not do this: * The new LOOKUP_* flags are intended to be security features, and openat(2) will silently ignore all unknown flags. This means that users would

[PATCH v9 07/10] namei: aggressively check for nd->root escape on ".." resolution

This patch allows for LOOKUP_BENEATH and LOOKUP_IN_ROOT to safely permit ".." resolution (in the case of LOOKUP_BENEATH the resolution will still fail if ".." resolution would resolve a path outside of the root -- while LOOKUP_IN_ROOT will chroot(2)-style scope it). magic-link jumps are still

[PATCH v9 06/10] namei: LOOKUP_IN_ROOT: chroot-like path resolution

The primary motivation for the need for this flag is container runtimes which have to interact with malicious root filesystems in the host namespaces. One of the first requirements for a container runtime to be secure against a malicious rootfs is that they correctly scope symlinks (that is, they

[PATCH v9 04/10] namei: split out nd->dfd handling to dirfd_path_init

Previously, path_init's handling of *at(dfd, ...) was only done once, but with LOOKUP_BENEATH (and LOOKUP_IN_ROOT) we have to parse the initial nd->path at different times (before or after absolute path handling) depending on whether we have been asked to scope resolution within a root.

[PATCH v9 03/10] open: O_EMPTYPATH: procfs-less file descriptor re-opening

Userspace has made use of /proc/self/fd very liberally to allow for descriptors to be re-opened. There are a wide variety of uses for this feature, but it has always required constructing a pathname and could not be done without procfs mounted. The obvious solution for this is to extend openat(2)

[PATCH v9 02/10] procfs: switch magic-link modes to be more sane

Now that magic-link modes are obeyed for file re-opening purposes, some of the pre-existing magic-link modes need to be adjusted to be more semantically correct. The most blatant example of this is /proc/self/exe, which had a mode of a+rwx even though tautologically the file could never be opened

[PATCH v9 00/10] namei: openat2(2) path resolution restrictions

Patch changelog: v9: * Replace resolveat(2) with openat2(2). [Linus] * Output a warning to dmesg if may_open_magiclink() is violated. * Add an openat2(O_CREAT) testcase. v8: * Default to O_CLOEXEC to match other new fd-creation syscalls (users can always disable O_CLOEXEC

[PATCH v9 01/10] namei: obey trailing magic-link DAC permissions

The ability for userspace to "re-open" file descriptors through /proc/self/fd has been a very useful tool for all sorts of usecases (container runtimes are one common example). However, the current interface for doing this has resulted in some pretty subtle security holes. Userspace can re-open a

Alpha Systems Ceased Production and Sales After April 2007?

Good morning from Singapore, Alpha systems ceased production and sales after April 2007? Thank you. -BEGIN EMAIL SIGNATURE- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link:

Re: [PATCH] Drop unused isa_page_to_bus

On Thu, 13 Jun 2019, Stephen Kitt wrote: > isa_page_to_bus is deprecated and no longer used anywhere, this patch > removes it entirely. > > Signed-off-by: Stephen Kitt Acked-by: Thomas Gleixner

[PATCH] Drop unused isa_page_to_bus

isa_page_to_bus is deprecated and no longer used anywhere, this patch removes it entirely. Signed-off-by: Stephen Kitt --- arch/alpha/include/asm/io.h | 5 - arch/arm/include/asm/io.h | 1 - arch/mips/include/asm/io.h | 2 -- arch/x86/include/asm/io.h | 1 - 4 files changed, 9

Thanks and I wait for your answer

Hello, I am Martin Henry, An American Citizen; I am the personal secretary to Mr. Donald Railton, the controller of a Lottery Company. Please I am having big problem now, I have a 6yrs old daughter who has leukemia, a disease of the blood, and she needs a bone marrow transplant or she will die.

Quation needed For June Inquiry

Hello dear, We are in the market for your products after meeting at your stand during last expo. Please kindly send us your latest catalog and price list so as to start a new project/order as promised during the exhibition. I would appreciate your response about the above details required

URGENT REPLY FOR THIS BUSINESS...

Dear Friend, I am Ms Lisa Hugh work with the department of Audit and accounting manager here in the Bank, There is this fund that was keep in my custody years ago,please i need your assistance for the transferring of thIs fund to your bank account for both of us benefit for life time

Purchase_rfq

INQUIRY_4178916..xlsx Description: Binary data

Re: [PATCH 4/5] kconfig: make arch/*/configs/defconfig the default of KBUILD_DEFCONFIG

On Mon, May 27, 2019 at 11:37:24PM +0900, Masahiro Yamada wrote: > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile > index b025304bde46..970c41a30ed3 100644 > --- a/arch/arm64/Makefile > +++ b/arch/arm64/Makefile > @@ -30,8 +30,6 @@ LDFLAGS_vmlinux += --fix-cortex-a53-843419 >endif

Re: [PATCH] [RFC] Remove bdflush syscall stub

Hi! > >> > I've tested the patch on i386. Before the patch calling bdflush() with > >> > attempt to tune a variable returned 0 and after the patch the syscall > >> > fails with EINVAL. > >> > >> Should be ENOSYS, doesn't it? > > > > My bad, the LTP syscall wrapper handles ENOSYS and produces

Re: [PATCH] [RFC] Remove bdflush syscall stub

* Cyril Hrubis: > Hi! >> > I've tested the patch on i386. Before the patch calling bdflush() with >> > attempt to tune a variable returned 0 and after the patch the syscall >> > fails with EINVAL. >> >> Should be ENOSYS, doesn't it? > > My bad, the LTP syscall wrapper handles ENOSYS and produces

Re: [PATCH] [RFC] Remove bdflush syscall stub

On Mai 28 2019, Cyril Hrubis wrote: > I've tested the patch on i386. Before the patch calling bdflush() with > attempt to tune a variable returned 0 and after the patch the syscall > fails with EINVAL. Should be ENOSYS, doesn't it? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key

[PATCH] [RFC] Remove bdflush syscall stub

While reviewing LTP testcases I've found that we still carry workaround for 17 years old distributions that attempted to start bdflush from userspace. I guess it's about the time to remove it. I've tested the patch on i386. Before the patch calling bdflush() with attempt to tune a variable

Re: [PATCH v2 2/2] tests: add close_range() tests

On Tue, May 28, 2019 at 12:33:41PM +1000, Michael Ellerman wrote: > Christian Brauner writes: > > This adds basic tests for the new close_range() syscall. > > - test that no invalid flags can be passed > > - test that a range of file descriptors is correctly closed > > - test that a range of file

Re: [PATCH v3 2/3] arch: wire-up close_range()

Christian Brauner writes: > diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl > b/arch/powerpc/kernel/syscalls/syscall.tbl > index 103655d84b4b..ba2c1f078cbd 100644 > --- a/arch/powerpc/kernel/syscalls/syscall.tbl > +++ b/arch/powerpc/kernel/syscalls/syscall.tbl > @@ -515,3 +515,4 @@ > 431

Re: [PATCH v2 2/2] tests: add close_range() tests

Christian Brauner writes: > This adds basic tests for the new close_range() syscall. > - test that no invalid flags can be passed > - test that a range of file descriptors is correctly closed > - test that a range of file descriptors is correctly closed if there there > are already closed file

[PATCH 4/5] kconfig: make arch/*/configs/defconfig the default of KBUILD_DEFCONFIG

Until recently, if KBUILD_DEFCONFIG was not set by the arch Makefile, the default path arch/*/defconfig was used. The last users of the default are gone by the following commits: - Commit f3e20ad67b4c ("s390: move arch/s390/defconfig to arch/s390/configs/defconfig") - Commit 986a13769c4b

Re: [PATCH v2 1/2] open: add close_range()

* Christian Brauner [2019-05-23 17:47:46 +0200]: > This adds the close_range() syscall. It allows to efficiently close a range > of file descriptors up to all file descriptors of a calling task. > > The syscall came up in a recent discussion around the new mount API and > making new file

URGENT REPLY FOR THIS BUSINESS...

Dear Friend, I am Ms Lisa Hugh work with the department of Audit and accounting manager here in the Bank, There is this fund that was keep in my custody years ago,please i need your assistance for the transferring of thIs fund to your bank account for both of us benefit for life time

[PATCH v3 2/3] arch: wire-up close_range()

This wires up the close_range() syscall into all arches at once. Suggested-by: Arnd Bergmann Signed-off-by: Christian Brauner Reviewed-by: Oleg Nesterov Acked-by: Arnd Bergmann Cc: Jann Horn Cc: David Howells Cc: Dmitry V. Levin Cc: Linus Torvalds Cc: Al Viro Cc: Florian Weimer Cc:

Re: [PATCH v3 1/2] pid: add pidfd_open()

On Tue, May 21, 2019 at 04:32:20PM +0200, Christian Brauner wrote: > On Mon, May 20, 2019 at 05:56:29PM +0200, Christian Brauner wrote: > > This adds the pidfd_open() syscall. It allows a caller to retrieve pollable > > pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a > >

Re: [PATCH v1 1/2] open: add close_range()

On Thu, May 23, 2019 at 07:22:17PM +0300, Konstantin Khlebnikov wrote: > On 22.05.2019 18:52, Christian Brauner wrote:> This adds the close_range() > syscall. It allows to efficiently close a range > > of file descriptors up to all file descriptors of a calling task. > > > > The syscall came up

Re: [PATCH v1 1/2] open: add close_range()

On Fri, May 24, 2019 at 09:43:53AM +0200, Arnd Bergmann wrote: > On Thu, May 23, 2019 at 6:33 PM Christian Brauner > wrote: > > On Thu, May 23, 2019 at 07:22:17PM +0300, Konstantin Khlebnikov wrote: > > > On 22.05.2019 18:52, Christian Brauner wrote:> This adds the > > > close_range() syscall.

Re: [PATCH v1 1/2] open: add close_range()

On Thu, May 23, 2019 at 6:33 PM Christian Brauner wrote: > On Thu, May 23, 2019 at 07:22:17PM +0300, Konstantin Khlebnikov wrote: > > On 22.05.2019 18:52, Christian Brauner wrote:> This adds the close_range() > > syscall. It allows to efficiently close a range > > > 22 files changed, 100

Re: [PATCH v2 1/2] open: add close_range()

On Thu, May 23, 2019 at 06:20:05PM +0200, Oleg Nesterov wrote: > On 05/23, Christian Brauner wrote: > > > > +int __close_range(struct files_struct *files, unsigned fd, unsigned max_fd) > > +{ > > + unsigned int cur_max; > > + > > + if (fd > max_fd) > > + return -EINVAL; > > + > > +

Re: [PATCH v1 1/2] open: add close_range()

On Thu, May 23, 2019 at 07:22:17PM +0300, Konstantin Khlebnikov wrote: > On 22.05.2019 18:52, Christian Brauner wrote:> This adds the close_range() > syscall. It allows to efficiently close a range > > of file descriptors up to all file descriptors of a calling task. > > > > The syscall came up

RE: [PATCH v1 1/2] open: add close_range()

From: Konstantin Khlebnikov > Sent: 23 May 2019 17:22 > > In addition, the syscall will also work for tasks that do not have procfs > > mounted and on kernels that do not have procfs support compiled in. In such > > situations the only way to make sure that all file descriptors are closed

Re: [PATCH v1 1/2] open: add close_range()

On 22.05.2019 18:52, Christian Brauner wrote:> This adds the close_range() syscall. It allows to efficiently close a range > of file descriptors up to all file descriptors of a calling task. > > The syscall came up in a recent discussion around the new mount API and > making new file descriptor

Re: [PATCH v1 1/2] open: add close_range()

On 05/23, Christian Brauner wrote: > > So given that we would really need another find_next_open_fd() I think > sticking to the simple cond_resched() version I sent before is better > for now until we see real-world performance issues. OK, agreed. Oleg.

Re: [PATCH v2 1/2] open: add close_range()

On 05/23, Christian Brauner wrote: > > +int __close_range(struct files_struct *files, unsigned fd, unsigned max_fd) > +{ > + unsigned int cur_max; > + > + if (fd > max_fd) > + return -EINVAL; > + > + rcu_read_lock(); > + cur_max = files_fdtable(files)->max_fds; > +

[PATCH v2 2/2] tests: add close_range() tests

This adds basic tests for the new close_range() syscall. - test that no invalid flags can be passed - test that a range of file descriptors is correctly closed - test that a range of file descriptors is correctly closed if there there are already closed file descriptors in the range - test that

[PATCH v2 1/2] open: add close_range()

This adds the close_range() syscall. It allows to efficiently close a range of file descriptors up to all file descriptors of a calling task. The syscall came up in a recent discussion around the new mount API and making new file descriptor types cloexec by default. During this discussion, Al

[PATCH v2 0/2] close_range()

Hey, This is v2 of this patchset. In accordance with some comments There's a cond_resched() added to the close loop similar to what is done for close_files(). A common helper pick_file() for __close_fd() and __close_range() has been split out. This allows to only make a cond_resched() call when

Re: [PATCH v1 1/2] open: add close_range()

On Thu, May 23, 2019 at 04:32:14PM +0200, Jann Horn wrote: > On Thu, May 23, 2019 at 1:51 PM Christian Brauner > wrote: > [...] > > I kept it dumb and was about to reply that your solution introduces more > > code when it seemed we wanted to keep this very simple for now. > > But then I saw that

Re: [PATCH v1 1/2] open: add close_range()

On Thu, May 23, 2019 at 1:51 PM Christian Brauner wrote: [...] > I kept it dumb and was about to reply that your solution introduces more > code when it seemed we wanted to keep this very simple for now. > But then I saw that find_next_opened_fd() already exists as > find_next_fd(). So it's

Re: [PATCH v1 1/2] open: add close_range()

On Thu, May 23, 2019 at 04:14:47PM +0200, Christian Brauner wrote: > On Thu, May 23, 2019 at 01:51:18PM +0200, Christian Brauner wrote: > > On Wed, May 22, 2019 at 06:57:37PM +0200, Oleg Nesterov wrote: > > > On 05/22, Christian Brauner wrote: > > > > > > > > +static struct file *pick_file(struct

Re: [PATCH v1 1/2] open: add close_range()

On Thu, May 23, 2019 at 01:51:18PM +0200, Christian Brauner wrote: > On Wed, May 22, 2019 at 06:57:37PM +0200, Oleg Nesterov wrote: > > On 05/22, Christian Brauner wrote: > > > > > > +static struct file *pick_file(struct files_struct *files, unsigned fd) > > > { > > > - struct file *file; > > > +

Re: [PATCH v1 1/2] open: add close_range()

On 05/22, Christian Brauner wrote: > > +static struct file *pick_file(struct files_struct *files, unsigned fd) > { > - struct file *file; > + struct file *file = NULL; > struct fdtable *fdt; > > spin_lock(>file_lock); > @@ -632,15 +629,65 @@ int __close_fd(struct

[PATCH v1 2/2] tests: add close_range() tests

This adds basic tests for the new close_range() syscall. - test that no invalid flags can be passed - test that a range of file descriptors is correctly closed - test that a range of file descriptors is correctly closed if there there are already closed file descriptors in the range - test that

[PATCH v1 1/2] open: add close_range()

This adds the close_range() syscall. It allows to efficiently close a range of file descriptors up to all file descriptors of a calling task. The syscall came up in a recent discussion around the new mount API and making new file descriptor types cloexec by default. During this discussion, Al

Re: [PATCH 1/2] open: add close_range()

On Tue, May 21, 2019 at 10:23 PM Linus Torvalds wrote: > > On Tue, May 21, 2019 at 9:41 AM Christian Brauner > wrote: > > > > Yeah, you mentioned this before. I do like being able to specify an > > upper bound to have the ability to place fds strategically after said > > upper bound. > > I

Re: [PATCH 1/2] open: add close_range()

On Tue, May 21, 2019 at 9:41 AM Christian Brauner wrote: > > Yeah, you mentioned this before. I do like being able to specify an > upper bound to have the ability to place fds strategically after said > upper bound. I suspect that's the case. And if somebody really wants to just close

Re: [PATCH 1/2] open: add close_range()

On Tue, May 21, 2019 at 08:20:09PM +0100, Al Viro wrote: > On Tue, May 21, 2019 at 05:30:27PM +0100, David Howells wrote: > > > If we can live with close_from(int first) rather than close_range(), then > > this > > can perhaps be done a lot more efficiently by: > > > > new =

Re: [PATCH 1/2] open: add close_range()

On Tue, May 21, 2019 at 04:00:06PM +0100, Al Viro wrote: > On Tue, May 21, 2019 at 01:34:47PM +0200, Christian Brauner wrote: > > > This adds the close_range() syscall. It allows to efficiently close a range > > of file descriptors up to all file descriptors of a calling task. > > > > The

Re: [PATCH 1/2] open: add close_range()

On Tue, May 21, 2019 at 05:30:27PM +0100, David Howells wrote: > Al Viro wrote: > > > Umm... That's going to be very painful if you dup2() something to MAX_INT > > and > > then run that; roughly 2G iterations of bouncing ->file_lock up and down, > > without anything that would yield CPU in

Re: [PATCH 1/2] open: add close_range()

Al Viro wrote: > Umm... That's going to be very painful if you dup2() something to MAX_INT and > then run that; roughly 2G iterations of bouncing ->file_lock up and down, > without anything that would yield CPU in process. > > If anything, I would suggest something like > > fd =

Re: [PATCH 1/2] open: add close_range()

On Tue, May 21, 2019 at 01:34:47PM +0200, Christian Brauner wrote: > This adds the close_range() syscall. It allows to efficiently close a range > of file descriptors up to all file descriptors of a calling task. > > The syscall came up in a recent discussion around the new mount API and >

Re: [PATCH v3 1/2] pid: add pidfd_open()

On Mon, May 20, 2019 at 05:56:29PM +0200, Christian Brauner wrote: > This adds the pidfd_open() syscall. It allows a caller to retrieve pollable > pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a > process that is created via traditional fork()/clone() calls that is only

Re: [PATCH 1/2] open: add close_range()

On Tue, May 21, 2019 at 03:10:11PM +0200, Florian Weimer wrote: > * Christian Brauner: > > >> Solaris has an fdwalk function: > >> > >> > >> > >> So a different way to implement this would expose a nextfd system call > > > >

Re: [PATCH 1/2] open: add close_range()

On Tue, May 21, 2019 at 03:10:11PM +0200, Florian Weimer wrote: > * Christian Brauner: > > >> Solaris has an fdwalk function: > >> > >> > >> > >> So a different way to implement this would expose a nextfd system call > > > >

Re: [PATCH 1/2] open: add close_range()

* Christian Brauner: >> Solaris has an fdwalk function: >> >> >> >> So a different way to implement this would expose a nextfd system call > > Meh. If nextfd() then I would like it to be able to: > - get the nextfd(fd) >= fd

Re: [PATCH 1/2] open: add close_range()

On Tue, May 21, 2019 at 02:09:29PM +0200, Florian Weimer wrote: > * Christian Brauner: > > > +/** > > + * __close_range() - Close all file descriptors in a given range. > > + * > > + * @fd: starting file descriptor to close > > + * @max_fd: last file descriptor to close > > + * > > + * This

Re: [PATCH 1/2] open: add close_range()

* Christian Brauner: > +/** > + * __close_range() - Close all file descriptors in a given range. > + * > + * @fd: starting file descriptor to close > + * @max_fd: last file descriptor to close > + * > + * This closes a range of file descriptors. All file descriptors > + * from @fd up to and

[PATCH 2/2] tests: add close_range() tests

This adds basic tests for the new close_range() syscall. - test that no invalid flags can be passed - test that a range of file descriptors is correctly closed - test that a range of file descriptors is correctly closed if there there are already closed file descriptors in the range - test that

Re: [GIT PULL 1/4] ARM: SoC platform updates

On Thu, May 16, 2019 at 7:10 PM Olof Johansson wrote: > On Thu, May 16, 2019 at 8:53 AM Arnd Bergmann wrote: > > > I'm going to remove that #ifdef in my merge, because I do *not* want > > > to see new warnings, and it doesn't seem to make any sense. > > > > > > Maybe that's the wrong

[PATCH v3 2/2] tests: add pidfd_open() tests

This adds testing for the new pidfd_open() syscalls. Specifically, we test: - that no invalid flags can be passed to pidfd_open() - that no invalid pid can be passed to pidfd_open() - that a pidfd can be retrieved with pidfd_open() - that the retrieved pidfd references the correct pid

Re: [PATCH v2 1/2] pid: add pidfd_open()

On Mon, May 20, 2019 at 4:48 PM Christian Brauner wrote: > > On Mon, May 20, 2019 at 04:37:03PM +0200, Arnd Bergmann wrote: > > On Mon, May 20, 2019 at 3:46 PM Christian Brauner > > wrote: > > > > > > In line with Arnd's recent changes to consolidate syscall numbers across > > > architectures,

Re: [PATCH v2 1/2] pid: add pidfd_open()

On Mon, May 20, 2019 at 04:37:03PM +0200, Arnd Bergmann wrote: > On Mon, May 20, 2019 at 3:46 PM Christian Brauner > wrote: > > > > In line with Arnd's recent changes to consolidate syscall numbers across > > architectures, I have added the pidfd_open() syscall to all architectures > > at the

Re: [PATCH v2 1/2] pid: add pidfd_open()

On Mon, May 20, 2019 at 3:46 PM Christian Brauner wrote: > > In line with Arnd's recent changes to consolidate syscall numbers across > architectures, I have added the pidfd_open() syscall to all architectures > at the same time. Thanks! I've checked that the ones you have added are all done

Re: [PATCH v2 1/2] pid: add pidfd_open()

On Mon, May 20, 2019 at 3:46 PM Christian Brauner wrote: > This adds the pidfd_open() syscall. It allows a caller to retrieve pollable > pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a > process that is created via traditional fork()/clone() calls that is only >

[PATCH v2 2/2] tests: add pidfd_open() tests

This adds testing for the new pidfd_open() syscalls. Specifically, we test: - that no invalid flags can be passed to pidfd_open() - that no invalid pid can be passed to pidfd_open() - that a pidfd can be retrieved with pidfd_open() - that the retrieved pidfd references the correct pid

[PATCH v2 1/2] pid: add pidfd_open()

This adds the pidfd_open() syscall. It allows a caller to retrieve pollable pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a process that is created via traditional fork()/clone() calls that is only referenced by a PID: int pidfd = pidfd_open(1234, 0); ret =

Re: [PATCH v1 1/2] pid: add pidfd_open()

On Sat, May 18, 2019 at 05:48:03AM -0400, Joel Fernandes wrote: > Hi Christian, > > For next revision, could you also CC sur...@google.com as well? He is also > working on the low memory killer. And also suggest CC to > kernel-t...@android.com. And mentioned some comments below, thanks. Yip,

Re: [PATCH v1 1/2] pid: add pidfd_open()

Hi Christian, For next revision, could you also CC sur...@google.com as well? He is also working on the low memory killer. And also suggest CC to kernel-t...@android.com. And mentioned some comments below, thanks. On Thu, May 16, 2019 at 03:59:42PM +0200, Christian Brauner wrote: [snip] > diff

Re: [GIT PULL 3/4] ARM: SoC-related driver updates

On Thu, May 16, 2019 at 9:27 AM Linus Torvalds wrote: > > On Wed, May 15, 2019 at 11:43 PM Olof Johansson wrote: > > > > Various driver updates for platforms and a couple of the small driver > > subsystems we merge through our tree: > > Hmm. This moved the aspeed drivers from drivers/misc to >

Re: [GIT PULL 3/4] ARM: SoC-related driver updates

From: Linus Torvalds Date: Thu, May 16, 2019 at 9:27 AM To: Olof Johansson, Patrick Venture, Greg Kroah-Hartman Cc: ARM SoC, Linux List Kernel Mailing, linux-alpha@vger.kernel.org > On Wed, May 15, 2019 at 11:43 PM Olof Johansson wrote: > > > > Various driver updates for platforms and a couple

Re: [GIT PULL 3/4] ARM: SoC-related driver updates

On Wed, May 15, 2019 at 11:43 PM Olof Johansson wrote: > > Various driver updates for platforms and a couple of the small driver > subsystems we merge through our tree: Hmm. This moved the aspeed drivers from drivers/misc to drivers/soc/aspeed (in commit 524feb799408 "soc: add aspeed folder and

Re: [GIT PULL 1/4] ARM: SoC platform updates

On Thu, May 16, 2019 at 5:34 PM Linus Torvalds wrote: > > On Wed, May 15, 2019 at 11:43 PM Olof Johansson wrote: > > > > SoC updates, mostly refactorings and cleanups of old legacy platforms. > > Major themes this release: > > Hmm. This brings in a new warning: > >

Re: [PATCH v1 1/2] pid: add pidfd_open()

On 05/17, Aleksa Sarai wrote: > > On 2019-05-16, Oleg Nesterov wrote: > > On 05/17, Aleksa Sarai wrote: > > > On 2019-05-16, Oleg Nesterov wrote: > > > > On 05/16, Christian Brauner wrote: > > > > > With the introduction of pidfds through CLONE_PIDFD it is possible to > > > > > created pidfds at

Re: [PATCH v1 1/2] pid: add pidfd_open()

On 2019-05-16, Oleg Nesterov wrote: > On 05/17, Aleksa Sarai wrote: > > On 2019-05-16, Oleg Nesterov wrote: > > > On 05/16, Christian Brauner wrote: > > > > With the introduction of pidfds through CLONE_PIDFD it is possible to > > > > created pidfds at process creation time. > > > > > > Now I am

Re: [PATCH v1 1/2] pid: add pidfd_open()

On 05/17, Aleksa Sarai wrote: > > On 2019-05-16, Oleg Nesterov wrote: > > On 05/16, Christian Brauner wrote: > > > > > > With the introduction of pidfds through CLONE_PIDFD it is possible to > > > created pidfds at process creation time. > > > > Now I am wondering why do we need CLONE_PIDFD, you

Re: [PATCH v1 1/2] pid: add pidfd_open()

On Thu, May 16, 2019 at 04:56:08PM +0200, Geert Uytterhoeven wrote: > Hi Christian, David, > > On Thu, May 16, 2019 at 4:00 PM Christian Brauner > wrote: > > This adds the pidfd_open() syscall. It allows a caller to retrieve pollable > > pidfds for a process which did not get created via

Re: [PATCH v1 1/2] pid: add pidfd_open()

On Thu, May 16, 2019 at 04:27:00PM +0200, Oleg Nesterov wrote: > On 05/16, Christian Brauner wrote: > > > > With the introduction of pidfds through CLONE_PIDFD it is possible to > > created pidfds at process creation time. > > Now I am wondering why do we need CLONE_PIDFD, you can just do > >

Re: [PATCH v1 1/2] pid: add pidfd_open()

On 2019-05-16, Oleg Nesterov wrote: > On 05/16, Christian Brauner wrote: > > > > With the introduction of pidfds through CLONE_PIDFD it is possible to > > created pidfds at process creation time. > > Now I am wondering why do we need CLONE_PIDFD, you can just do > > pid = fork(); >

Re: [PATCH v1 1/2] pid: add pidfd_open()

Hi Christian, David, On Thu, May 16, 2019 at 4:00 PM Christian Brauner wrote: > This adds the pidfd_open() syscall. It allows a caller to retrieve pollable > pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a > process that is created via traditional fork()/clone() calls

Re: [PATCH 1/2] pid: add pidfd_open()

On 2019-05-16, Christian Brauner wrote: > On Wed, May 15, 2019 at 10:45:06AM -0700, Daniel Colascione wrote: > > On Wed, May 15, 2019 at 3:04 AM Christian Brauner > > wrote: > > > + if (pid <= 0) > > > + return -EINVAL; > > > > WDYT of defining pid == 0 to mean "open

Re: [PATCH 1/2] pid: add pidfd_open()

On Thu, May 16, 2019 at 04:03:27PM +0200, Jann Horn wrote: > On Thu, May 16, 2019 at 3:08 PM Christian Brauner > wrote: > > On Wed, May 15, 2019 at 10:45:06AM -0700, Daniel Colascione wrote: > > > On Wed, May 15, 2019 at 3:04 AM Christian Brauner > > > wrote: > > > > > > > > This adds the

Re: [PATCH 1/2] pid: add pidfd_open()

On Thu, May 16, 2019 at 3:08 PM Christian Brauner wrote: > On Wed, May 15, 2019 at 10:45:06AM -0700, Daniel Colascione wrote: > > On Wed, May 15, 2019 at 3:04 AM Christian Brauner > > wrote: > > > > > > This adds the pidfd_open() syscall. It allows a caller to retrieve > > > pollable > > >

[PATCH v1 2/2] tests: add pidfd_open() tests

This adds testing for the new pidfd_open() syscalls. Specifically, we test: - that no invalid flags can be passed to pidfd_open() - that no invalid pid can be passed to pidfd_open() - that a pidfd can be retrieved with pidfd_open() - that the retrieved pidfd references the correct pid

[PATCH v1 1/2] pid: add pidfd_open()

This adds the pidfd_open() syscall. It allows a caller to retrieve pollable pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a process that is created via traditional fork()/clone() calls that is only referenced by a PID: int pidfd = pidfd_open(1234, 0); ret =

Re: [PATCH 1/2] pid: add pidfd_open()

On Wed, May 15, 2019 at 10:45:06AM -0700, Daniel Colascione wrote: > On Wed, May 15, 2019 at 3:04 AM Christian Brauner > wrote: > > > > This adds the pidfd_open() syscall. It allows a caller to retrieve pollable > > pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a > >

Re: [PATCH 1/2] pid: add pidfd_open()

On Wed, May 15, 2019 at 3:04 AM Christian Brauner wrote: > > This adds the pidfd_open() syscall. It allows a caller to retrieve pollable > pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a > process that is created via traditional fork()/clone() calls that is only >

Re: [PATCH 1/2] pid: add pidfd_open()

On Wed, May 15, 2019 at 05:35:15PM +0200, Oleg Nesterov wrote: > On 05/15, Oleg Nesterov wrote: > > > > On 05/15, Christian Brauner wrote: > > > > > > +SYSCALL_DEFINE2(pidfd_open, pid_t, pid, unsigned int, flags) > > > +{ > > > + int fd, ret; > > > + struct pid *p; > > > + struct task_struct *tsk;

Re: [PATCH 1/2] pid: add pidfd_open()

On 05/15, Oleg Nesterov wrote: > > On 05/15, Christian Brauner wrote: > > > > +SYSCALL_DEFINE2(pidfd_open, pid_t, pid, unsigned int, flags) > > +{ > > + int fd, ret; > > + struct pid *p; > > + struct task_struct *tsk; > > + > > + if (flags) > > + return -EINVAL; > > + > > + if

Re: [PATCH 1/2] pid: add pidfd_open()

On Wed, May 15, 2019 at 05:19:13PM +0200, Oleg Nesterov wrote: > On 05/15, Christian Brauner wrote: > > > > On Wed, May 15, 2019 at 04:38:58PM +0200, Oleg Nesterov wrote: > > > > > > it seems that you can do a single check > > > > > > tsk = pid_task(p, PIDTYPE_TGID); > > > if (!tsk) > > >

Re: [PATCH 1/2] pid: add pidfd_open()

Hi, Le mercredi 15 mai 2019 à 16:16 +0200, Christian Brauner a écrit : > On Wed, May 15, 2019 at 04:00:20PM +0200, Yann Droneaud wrote: > > Le mercredi 15 mai 2019 à 12:03 +0200, Christian Brauner a écrit : > > > diff --git a/kernel/pid.c b/kernel/pid.c > > > index 20881598bdfa..237d18d6ecb8

Re: [PATCH 1/2] pid: add pidfd_open()

On 05/15, Christian Brauner wrote: > > On Wed, May 15, 2019 at 04:38:58PM +0200, Oleg Nesterov wrote: > > > > it seems that you can do a single check > > > > tsk = pid_task(p, PIDTYPE_TGID); > > if (!tsk) > > ret = -ESRCH; > > > > this even looks more correct if we race with

Re: [PATCH 1/2] pid: add pidfd_open()

On 2019-05-15, Christian Brauner wrote: > On Wed, May 15, 2019 at 04:00:20PM +0200, Yann Droneaud wrote: > > Would it be possible to create file descriptor with "restricted" > > operation ? > > > > - O_RDONLY: waiting for process completion allowed (for example) > > - O_WRONLY: sending process

Re: [PATCH 1/2] pid: add pidfd_open()

On Wed, May 15, 2019 at 04:38:58PM +0200, Oleg Nesterov wrote: > On 05/15, Christian Brauner wrote: > > > > +SYSCALL_DEFINE2(pidfd_open, pid_t, pid, unsigned int, flags) > > +{ > > + int fd, ret; > > + struct pid *p; > > + struct task_struct *tsk; > > + > > + if (flags) > > +

Re: [PATCH 1/2] pid: add pidfd_open()

On 05/15, Christian Brauner wrote: > > +SYSCALL_DEFINE2(pidfd_open, pid_t, pid, unsigned int, flags) > +{ > + int fd, ret; > + struct pid *p; > + struct task_struct *tsk; > + > + if (flags) > + return -EINVAL; > + > + if (pid <= 0) > + return -EINVAL; >

Re: [PATCH 1/2] pid: add pidfd_open()

Hi, Le mercredi 15 mai 2019 à 12:03 +0200, Christian Brauner a écrit : > > diff --git a/kernel/pid.c b/kernel/pid.c > index 20881598bdfa..237d18d6ecb8 100644 > --- a/kernel/pid.c > +++ b/kernel/pid.c > @@ -451,6 +452,53 @@ struct pid *find_ge_pid(int nr, struct > pid_namespace *ns) >

Re: [PATCH 1/2] pid: add pidfd_open()

On Wed, May 15, 2019 at 04:00:20PM +0200, Yann Droneaud wrote: > Hi, > > Le mercredi 15 mai 2019 à 12:03 +0200, Christian Brauner a écrit : > > > > diff --git a/kernel/pid.c b/kernel/pid.c > > index 20881598bdfa..237d18d6ecb8 100644 > > --- a/kernel/pid.c > > +++ b/kernel/pid.c > > @@ -451,6

<    1   2   3   4   5   6   7   8   9   10   >