Re: [patch] mremap.2: Add description of old_size == 0 functionality

On 09/25/2017 02:52 PM, Michal Hocko wrote: So, how are you going to deal with the CoW and the implementation which basically means that the newm mmap content is not the same as the original one? I don't understand why CoW would kick in. The approach I outlined is desirable because it avoids

Re: [patch] mremap.2: Add description of old_size == 0 functionality

On 09/25/2017 02:35 PM, Michal Hocko wrote: What would be the usecase. I mean why don't you simply create a new mapping by a plain mmap when you have no guarantee about the same content? I plan to use it for creating an unbounded number of callback thunks at run time, from a single set of

Re: [patch] mremap.2: Add description of old_size == 0 functionality

On 09/25/2017 02:35 PM, Michal Hocko wrote: What would be the usecase. I mean why don't you simply create a new mapping by a plain mmap when you have no guarantee about the same content? I plan to use it for creating an unbounded number of callback thunks at run time, from a single set of

Re: [patch] mremap.2: Add description of old_size == 0 functionality

On 09/18/2017 07:11 PM, Mike Kravetz wrote: On 09/18/2017 06:45 AM, Florian Weimer wrote: On 09/15/2017 11:53 PM, Mike Kravetz wrote: +If the value of \fIold_size\fP is zero, and \fIold_address\fP refers to +a private anonymous mapping, then +.BR mremap () +will create a new mapping

Re: [patch] mremap.2: Add description of old_size == 0 functionality

On 09/18/2017 07:11 PM, Mike Kravetz wrote: On 09/18/2017 06:45 AM, Florian Weimer wrote: On 09/15/2017 11:53 PM, Mike Kravetz wrote: +If the value of \fIold_size\fP is zero, and \fIold_address\fP refers to +a private anonymous mapping, then +.BR mremap () +will create a new mapping

Re: [patch] mremap.2: Add description of old_size == 0 functionality

On 09/15/2017 11:53 PM, Mike Kravetz wrote: +If the value of \fIold_size\fP is zero, and \fIold_address\fP refers to +a private anonymous mapping, then +.BR mremap () +will create a new mapping of the same pages. \fInew_size\fP +will be the size of the new mapping and the location of the new

Re: [patch] mremap.2: Add description of old_size == 0 functionality

On 09/15/2017 11:53 PM, Mike Kravetz wrote: +If the value of \fIold_size\fP is zero, and \fIold_address\fP refers to +a private anonymous mapping, then +.BR mremap () +will create a new mapping of the same pages. \fInew_size\fP +will be the size of the new mapping and the location of the new

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/11/2017 04:24 PM, Michal Hocko wrote: > On Fri 11-08-17 16:11:44, Florian Weimer wrote: >> On 08/11/2017 04:06 PM, Michal Hocko wrote: >> >>> I am sorry to look too insisting here (I have still hard time to reconcile >>> myself with the madvise (ab)use) but

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/11/2017 04:24 PM, Michal Hocko wrote: > On Fri 11-08-17 16:11:44, Florian Weimer wrote: >> On 08/11/2017 04:06 PM, Michal Hocko wrote: >> >>> I am sorry to look too insisting here (I have still hard time to reconcile >>> myself with the madvise (ab)use) but

[PATCH] uapi/linux/quota.h: Do not include linux/errno.h

linux/errno.h is very sensitive to coordination with libc headers. Nothing in linux/quota.h needs it, so this change allows using this header in more contexts. Signed-off-by: Florian Weimer <fwei...@redhat.com> --- include/uapi/linux/quota.h | 1 - 1 file changed, 1 deletion(-) diff

[PATCH] uapi/linux/quota.h: Do not include linux/errno.h

linux/errno.h is very sensitive to coordination with libc headers. Nothing in linux/quota.h needs it, so this change allows using this header in more contexts. Signed-off-by: Florian Weimer --- include/uapi/linux/quota.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/uapi/linux

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/11/2017 04:06 PM, Michal Hocko wrote: > I am sorry to look too insisting here (I have still hard time to reconcile > myself with the madvise (ab)use) but if we in fact want minherit like > interface why don't we simply add minherit and make the code which wants > to use that interface

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/11/2017 04:06 PM, Michal Hocko wrote: > I am sorry to look too insisting here (I have still hard time to reconcile > myself with the madvise (ab)use) but if we in fact want minherit like > interface why don't we simply add minherit and make the code which wants > to use that interface

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/09/2017 11:59 AM, Kirill A. Shutemov wrote: > It's not obvious to me what would break if kernel would ignore > MADV_DONTFORK or MADV_DONTDUMP. Ignoring MADV_DONTDUMP could cause secrets to be written to disk, contrary to the expected security policy of the system. Thanks, Florian

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/09/2017 11:59 AM, Kirill A. Shutemov wrote: > It's not obvious to me what would break if kernel would ignore > MADV_DONTFORK or MADV_DONTDUMP. Ignoring MADV_DONTDUMP could cause secrets to be written to disk, contrary to the expected security policy of the system. Thanks, Florian

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/08/2017 05:19 PM, Mike Kravetz wrote: > On 08/08/2017 06:15 AM, Rik van Riel wrote: >> On Tue, 2017-08-08 at 11:58 +0200, Florian Weimer wrote: >>> On 08/07/2017 08:23 PM, Mike Kravetz wrote: >>>> If my thoughts above are correct, what about returning EINVAL if

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/08/2017 05:19 PM, Mike Kravetz wrote: > On 08/08/2017 06:15 AM, Rik van Riel wrote: >> On Tue, 2017-08-08 at 11:58 +0200, Florian Weimer wrote: >>> On 08/07/2017 08:23 PM, Mike Kravetz wrote: >>>> If my thoughts above are correct, what about returning EINVAL if

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/07/2017 08:23 PM, Mike Kravetz wrote: > If my thoughts above are correct, what about returning EINVAL if one > attempts to set MADV_DONTFORK on mappings set up for sharing? That's my preference as well. If there is a use case for shared or non-anonymous mappings, then we can implement

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/07/2017 08:23 PM, Mike Kravetz wrote: > If my thoughts above are correct, what about returning EINVAL if one > attempts to set MADV_DONTFORK on mappings set up for sharing? That's my preference as well. If there is a use case for shared or non-anonymous mappings, then we can implement

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/07/2017 03:46 PM, Michal Hocko wrote: > How do they know that they need to regenerate if they do not get SEGV? > Are they going to assume that a read of zeros is a "must init again"? Isn't > that too fragile? Why would it be fragile? Some level of synchronization is needed to set things

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/07/2017 03:46 PM, Michal Hocko wrote: > How do they know that they need to regenerate if they do not get SEGV? > Are they going to assume that a read of zeros is a "must init again"? Isn't > that too fragile? Why would it be fragile? Some level of synchronization is needed to set things

Re: [musl] Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions

On 04/25/2017 02:29 PM, Carlos O'Donell wrote: > In glibc right now we support including linux or glibc header files first, > and this has always been a requirement from the start. This requirement > dictates > that the kernel know which libc it's being used with so it can tailor > coordination.

Re: [musl] Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions

On 04/25/2017 02:29 PM, Carlos O'Donell wrote: > In glibc right now we support including linux or glibc header files first, > and this has always been a requirement from the start. This requirement > dictates > that the kernel know which libc it's being used with so it can tailor > coordination.

Re: commit cfafcd117 "futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()" causes glibc nptl/tst-robustpi8 failure

On 05/18/2017 10:41 AM, Peter Zijlstra wrote: > On Thu, May 18, 2017 at 10:34:34AM +0200, Florian Weimer wrote: >> On 05/18/2017 10:31 AM, Peter Zijlstra wrote: >>> That more or less worked, it still failed: >>> >>> /usr/bin/ld: /usr/local/src/glib

Re: commit cfafcd117 "futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()" causes glibc nptl/tst-robustpi8 failure

On 05/18/2017 10:41 AM, Peter Zijlstra wrote: > On Thu, May 18, 2017 at 10:34:34AM +0200, Florian Weimer wrote: >> On 05/18/2017 10:31 AM, Peter Zijlstra wrote: >>> That more or less worked, it still failed: >>> >>> /usr/bin/ld: /usr/local/src/glib

Re: commit cfafcd117 "futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()" causes glibc nptl/tst-robustpi8 failure

On 05/18/2017 10:31 AM, Peter Zijlstra wrote: > That more or less worked, it still failed: > > /usr/bin/ld: /usr/local/src/glibc/build/nptl/tst-once5.o: relocation > R_X86_64_32 against `.text' can not be used when making a shared object; > recompile with -fPIC > /usr/bin/ld: final link failed:

Re: commit cfafcd117 "futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()" causes glibc nptl/tst-robustpi8 failure

On 05/18/2017 10:31 AM, Peter Zijlstra wrote: > That more or less worked, it still failed: > > /usr/bin/ld: /usr/local/src/glibc/build/nptl/tst-once5.o: relocation > R_X86_64_32 against `.text' can not be used when making a shared object; > recompile with -fPIC > /usr/bin/ld: final link failed:

Re: commit cfafcd117 "futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()" causes glibc nptl/tst-robustpi8 failure

On 05/18/2017 09:40 AM, Peter Zijlstra wrote: > OK, so how do I get those tests build? > > I did a checkout of glibc.git > > glibc$ mkdir build; cd build > build$ ../configure --disable-sanity-checks ; make -j40 > build$ ./nptl/tst-robustpi8 > -bash: ./nptl/tst-robustpi8: No such file or

Re: commit cfafcd117 "futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()" causes glibc nptl/tst-robustpi8 failure

On 05/18/2017 09:40 AM, Peter Zijlstra wrote: > OK, so how do I get those tests build? > > I did a checkout of glibc.git > > glibc$ mkdir build; cd build > build$ ../configure --disable-sanity-checks ; make -j40 > build$ ./nptl/tst-robustpi8 > -bash: ./nptl/tst-robustpi8: No such file or

Re: commit cfafcd117 "futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()" causes glibc nptl/tst-robustpi8 failure

On 05/17/2017 07:36 PM, Markus Trippelsdorf wrote: > Since: > commit cfafcd117da0216520568c195cb2f6cd1980c4bb > Author: Peter Zijlstra > Date: Wed Mar 22 11:35:58 2017 +0100 > > futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock() > > glibc's

Re: commit cfafcd117 "futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()" causes glibc nptl/tst-robustpi8 failure

On 05/17/2017 07:36 PM, Markus Trippelsdorf wrote: > Since: > commit cfafcd117da0216520568c195cb2f6cd1980c4bb > Author: Peter Zijlstra > Date: Wed Mar 22 11:35:58 2017 +0100 > > futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock() > > glibc's nptl/tst-robustpi8 testcase fails: >

Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions

On 03/09/2017 01:14 AM, Szabolcs Nagy wrote: the other way (linux header included first) is problematic because linux headers don't follow all the standards the libc follows, they violate namespace rules in their struct definitions, so the libc definitions are necessarily incompatible with them

Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions

On 03/09/2017 01:14 AM, Szabolcs Nagy wrote: the other way (linux header included first) is problematic because linux headers don't follow all the standards the libc follows, they violate namespace rules in their struct definitions, so the libc definitions are necessarily incompatible with them

Re: [PATCH v7 resend 00/20] ILP32 for ARM64

On 04/11/2017 08:36 PM, Yury Norov wrote: Also, the latest benchmarks I've seen were mostly for user space while I'm more concerned with the user-kernel interface (https://marc.info/?l=linux-arm-kernel=148690490713310=2). On the glibc testing side, have the regressions been identified/fixed?

Re: [PATCH v7 resend 00/20] ILP32 for ARM64

On 04/11/2017 08:36 PM, Yury Norov wrote: Also, the latest benchmarks I've seen were mostly for user space while I'm more concerned with the user-kernel interface (https://marc.info/?l=linux-arm-kernel=148690490713310=2). On the glibc testing side, have the regressions been identified/fixed?

Re: RFC: reject unknown open flags

* Linus Torvalds: > But probing for flags is why we *could* add things like O_NOATIME etc > - exactly because it "just worked" with old kernels, and people could > just use the new flags knowing that it was a no-op on old kernels. Right, it mostly works for the flags we added. > The whole

Re: RFC: reject unknown open flags

* Linus Torvalds: > But probing for flags is why we *could* add things like O_NOATIME etc > - exactly because it "just worked" with old kernels, and people could > just use the new flags knowing that it was a no-op on old kernels. Right, it mostly works for the flags we added. > The whole

Re: [PATCH v2] statx: optimize copy of struct statx to userspace

On 03/13/2017 05:34 AM, Andreas Dilger wrote: Not that it is a huge deal either way, but I'd think it is harder for the compiler to optimize across a function call boundary like memset() vs. a struct initialization in the same function where it can see that all but a few of the fields are being

Re: [PATCH v2] statx: optimize copy of struct statx to userspace

On 03/13/2017 05:34 AM, Andreas Dilger wrote: Not that it is a huge deal either way, but I'd think it is harder for the compiler to optimize across a function call boundary like memset() vs. a struct initialization in the same function where it can see that all but a few of the fields are being

Re: Hard-coding PTY device node numbers in userspace

* Greg KH: > On Fri, Feb 17, 2017 at 12:02:52PM +0100, Florian Weimer wrote: >> We want to reject PTY devices from other namespaces as valid input to >> the ttyname and ttyname_r functions, while still providing a hint to >> callers that the device is, in fact, a PTY. Ch

Re: Hard-coding PTY device node numbers in userspace

* Greg KH: > On Fri, Feb 17, 2017 at 12:02:52PM +0100, Florian Weimer wrote: >> We want to reject PTY devices from other namespaces as valid input to >> the ttyname and ttyname_r functions, while still providing a hint to >> callers that the device is, in fact, a PTY. Ch

Re: [Question] New mmap64 syscall?

On 01/03/2017 09:54 PM, Pavel Machek wrote: ...actually, with strace and batched interface, it will be impossible to see what is going on because of races. So I'm not sure if I like the batched interface at all... I'm not sure if I understand this problem. ioctl, fcntl, most socket system

Re: [Question] New mmap64 syscall?

On 01/03/2017 09:54 PM, Pavel Machek wrote: ...actually, with strace and batched interface, it will be impossible to see what is going on because of races. So I'm not sure if I like the batched interface at all... I'm not sure if I understand this problem. ioctl, fcntl, most socket system

Re: [Question] New mmap64 syscall?

On 12/07/2016 04:48 PM, Yury Norov wrote: On Wed, Dec 07, 2016 at 02:23:55PM +0100, Florian Weimer wrote: On 12/06/2016 07:54 PM, Yury Norov wrote: 3. Introduce new mmap64() syscall like this: sys_mmap64(void *addr, size_t len, int prot, int flags, int fd, struct off_pair *off); (The pointer

Re: [Question] New mmap64 syscall?

On 12/07/2016 04:48 PM, Yury Norov wrote: On Wed, Dec 07, 2016 at 02:23:55PM +0100, Florian Weimer wrote: On 12/06/2016 07:54 PM, Yury Norov wrote: 3. Introduce new mmap64() syscall like this: sys_mmap64(void *addr, size_t len, int prot, int flags, int fd, struct off_pair *off); (The pointer

Re: [Question] New mmap64 syscall?

On 12/06/2016 07:54 PM, Yury Norov wrote: 3. Introduce new mmap64() syscall like this: sys_mmap64(void *addr, size_t len, int prot, int flags, int fd, struct off_pair *off); (The pointer here because otherwise we have 7 args, if simply pass off_hi and off_lo in registers.) I would prefer a

Re: [Question] New mmap64 syscall?

On 12/06/2016 07:54 PM, Yury Norov wrote: 3. Introduce new mmap64() syscall like this: sys_mmap64(void *addr, size_t len, int prot, int flags, int fd, struct off_pair *off); (The pointer here because otherwise we have 7 args, if simply pass off_hi and off_lo in registers.) I would prefer a

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

* Daniel Micay: > On Mon, 2016-10-31 at 22:38 +0100, Florian Weimer wrote: >> * Daniel Micay: >> >> > -fstack-stack is supposed to handle a single guard by default, and >> > that's all there is for thread stacks by default. >> >> Okay, then I'll rea

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

* Daniel Micay: > On Mon, 2016-10-31 at 22:38 +0100, Florian Weimer wrote: >> * Daniel Micay: >> >> > -fstack-stack is supposed to handle a single guard by default, and >> > that's all there is for thread stacks by default. >> >> Okay, then I'll rea

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

* Daniel Micay: > -fstack-stack is supposed to handle a single guard by default, and > that's all there is for thread stacks by default. Okay, then I'll really have to look at the probing offsets again. It's been on my to-do list since about 2012, and arguably, it *is* a user-space thing. And I

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

* Daniel Micay: > -fstack-stack is supposed to handle a single guard by default, and > that's all there is for thread stacks by default. Okay, then I'll really have to look at the probing offsets again. It's been on my to-do list since about 2012, and arguably, it *is* a user-space thing. And I

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

* Jann Horn: > Until recently: Zero, no guard pages below stacks, stack overflow > goes straight into some other allocation. > Now: One guard page, thanks to a lot of work by Andy Lutomirski. > (I think that change is in the current 4.9-rc3 kernel, but not in > any stable kernel yet.) Sorry, I

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

* Jann Horn: > Until recently: Zero, no guard pages below stacks, stack overflow > goes straight into some other allocation. > Now: One guard page, thanks to a lot of work by Andy Lutomirski. > (I think that change is in the current 4.9-rc3 kernel, but not in > any stable kernel yet.) Sorry, I

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

* Daniel Micay: >> It makes a lot of sense on x86_64 where it means the canary is >> still 56 bits. Also, you want -fstack-check for protecting again >> stack overflows rather than stack *buffer* overflow. SSP won't >> really help you in that regard. Sadly, while -fstack-check now >> works well

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

* Daniel Micay: >> It makes a lot of sense on x86_64 where it means the canary is >> still 56 bits. Also, you want -fstack-check for protecting again >> stack overflows rather than stack *buffer* overflow. SSP won't >> really help you in that regard. Sadly, while -fstack-check now >> works well

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

* Jann Horn: > On Mon, Oct 31, 2016 at 09:04:02AM -0700, Kees Cook wrote: >> On Mon, Oct 31, 2016 at 7:04 AM, Jann Horn wrote: >> > On machines with sizeof(unsigned long)==8, this ensures that the more >> > significant 32 bits of stack_canary are random, too. >> > stack_canary is

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

* Jann Horn: > On Mon, Oct 31, 2016 at 09:04:02AM -0700, Kees Cook wrote: >> On Mon, Oct 31, 2016 at 7:04 AM, Jann Horn wrote: >> > On machines with sizeof(unsigned long)==8, this ensures that the more >> > significant 32 bits of stack_canary are random, too. >> > stack_canary is defined as

Re: [PATCH v5] powerpc: Do not make the entire heap executable

* Jason Gunthorpe: > Eg that 32 bit powerpc currently unconditionally injects writable, > executable pages into a user space process. > > This critically undermines all the W^X security work that has been > done in the tool chain and user space by the PPC community. Exactly, this is how we found

Re: [PATCH v5] powerpc: Do not make the entire heap executable

* Jason Gunthorpe: > Eg that 32 bit powerpc currently unconditionally injects writable, > executable pages into a user space process. > > This critically undermines all the W^X security work that has been > done in the tool chain and user space by the PPC community. Exactly, this is how we found

Re: [PATCH] binfmt_misc: allow selecting the interpreter based on xattr keywords

On 08/25/2016 06:15 PM, James Bottomley wrote: On Sun, 2016-08-21 at 21:01 -0700, Josh Max wrote: This patch allows binfmt_misc to select the interpeter for arbitrary binaries by comparing a specified registered keyword with the value of a specified binary's extended attribute

Re: [PATCH] binfmt_misc: allow selecting the interpreter based on xattr keywords

On 08/25/2016 06:15 PM, James Bottomley wrote: On Sun, 2016-08-21 at 21:01 -0700, Josh Max wrote: This patch allows binfmt_misc to select the interpeter for arbitrary binaries by comparing a specified registered keyword with the value of a specified binary's extended attribute

Re: [PATCH 01/27] [AARCH64] Fix utmp struct for compatibility reasons.

On 06/23/2016 09:56 AM, Andreas Schwab wrote: Andrew Pinski writes: So the question becomes do we care enough about the incompatibles between AARCH32 and AARCH64 to fix this and go just worry about ILP32 and LP64? Some armv8 chips do not implement all of armv7, so how

Re: [PATCH 01/27] [AARCH64] Fix utmp struct for compatibility reasons.

On 06/23/2016 09:56 AM, Andreas Schwab wrote: Andrew Pinski writes: So the question becomes do we care enough about the incompatibles between AARCH32 and AARCH64 to fix this and go just worry about ILP32 and LP64? Some armv8 chips do not implement all of armv7, so how relevant is aarch32 on

Re: [PATCH 01/27] [AARCH64] Fix utmp struct for compatibility reasons.

On 06/23/2016 09:36 AM, Yury Norov wrote: On Thu, Jun 23, 2016 at 09:32:46AM +0200, Andreas Schwab wrote: Andrew Pinski writes: So if you want aarch64 to be compatible with aarch32, you need to define __WORDSIZE_TIME64_COMPAT32. If we don't want aarch64 and aarch32 to be

Re: [PATCH 01/27] [AARCH64] Fix utmp struct for compatibility reasons.

On 06/23/2016 09:36 AM, Yury Norov wrote: On Thu, Jun 23, 2016 at 09:32:46AM +0200, Andreas Schwab wrote: Andrew Pinski writes: So if you want aarch64 to be compatible with aarch32, you need to define __WORDSIZE_TIME64_COMPAT32. If we don't want aarch64 and aarch32 to be compatible at all,

Re: [PATCH v4 0/3] vfs: Define new syscall umask2 [formerly getumask]

* H. Peter Anvin: > I have to say I'm skeptic to the need for umask2() as opposed to > getumask(). I find the extension with a set-the-thread umask somewhat unlikely. How would a potential per-thread umask interact with CLONE_FS? Have a per-thread umask that, when active, overrides the global

Re: [PATCH v4 0/3] vfs: Define new syscall umask2 [formerly getumask]

* H. Peter Anvin: > I have to say I'm skeptic to the need for umask2() as opposed to > getumask(). I find the extension with a set-the-thread umask somewhat unlikely. How would a potential per-thread umask interact with CLONE_FS? Have a per-thread umask that, when active, overrides the global

Re: [PATCH 1/2] vfs: Define new syscall getumask.

* Richard W. M. Jones: > +SYSCALL_DEFINE0(getumask) > +{ > + return current->fs->umask; > +} The convention seems to be to call current_umask(), instead of inlining its contents.

Re: [PATCH 1/2] vfs: Define new syscall getumask.

* Richard W. M. Jones: > +SYSCALL_DEFINE0(getumask) > +{ > + return current->fs->umask; > +} The convention seems to be to call current_umask(), instead of inlining its contents.

Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

On 04/07/2016 06:39 PM, Linus Torvalds wrote: > Can anybody give a *coherent* and actual *real* reason why the kernel > would ever care about anything else? We already have a similar per-thread data structure, the robust mutex list. The CPU ID is another one. So it's conceivable we might get

Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

On 04/07/2016 06:39 PM, Linus Torvalds wrote: > Can anybody give a *coherent* and actual *real* reason why the kernel > would ever care about anything else? We already have a similar per-thread data structure, the robust mutex list. The CPU ID is another one. So it's conceivable we might get

Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

On 04/07/2016 02:25 PM, Peter Zijlstra wrote: > Do you have a pointer to something I can read? Because I'm clearly not > understanding the full issue here. I believe the canonical reference still is this document: For newer architectures (ppc64le,

Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

On 04/07/2016 02:25 PM, Peter Zijlstra wrote: > Do you have a pointer to something I can read? Because I'm clearly not > understanding the full issue here. I believe the canonical reference still is this document: For newer architectures (ppc64le,

Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

On 04/07/2016 01:19 PM, Peter Zijlstra wrote: > On Thu, Apr 07, 2016 at 12:39:21PM +0200, Florian Weimer wrote: >> On 04/07/2016 12:31 PM, Peter Zijlstra wrote: >>> On Thu, Apr 07, 2016 at 11:01:25AM +0200, Florian Weimer wrote: >>>>> Because ideally this struc

Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

On 04/07/2016 01:19 PM, Peter Zijlstra wrote: > On Thu, Apr 07, 2016 at 12:39:21PM +0200, Florian Weimer wrote: >> On 04/07/2016 12:31 PM, Peter Zijlstra wrote: >>> On Thu, Apr 07, 2016 at 11:01:25AM +0200, Florian Weimer wrote: >>>>> Because ideally this struc

Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

On 04/04/2016 07:01 PM, Mathieu Desnoyers wrote: > NAME >thread_local_abi - Shared memory interface between user-space >threads and the kernel We already have set_robust_list, which is conceptually similar. Florian

Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

On 04/04/2016 07:01 PM, Mathieu Desnoyers wrote: > NAME >thread_local_abi - Shared memory interface between user-space >threads and the kernel We already have set_robust_list, which is conceptually similar. Florian

Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

On 04/07/2016 12:31 PM, Peter Zijlstra wrote: > On Thu, Apr 07, 2016 at 11:01:25AM +0200, Florian Weimer wrote: >>> Because ideally this structure would be part of the initial (glibc) TCB >>> with fixed offset etc. >> >> This is not possible because we have layeri

Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

On 04/07/2016 12:31 PM, Peter Zijlstra wrote: > On Thu, Apr 07, 2016 at 11:01:25AM +0200, Florian Weimer wrote: >>> Because ideally this structure would be part of the initial (glibc) TCB >>> with fixed offset etc. >> >> This is not possible because we have layeri

Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

On 04/05/2016 06:47 PM, Peter Zijlstra wrote: > On Tue, Apr 05, 2016 at 06:02:25PM +0200, Florian Weimer wrote: >> On 04/04/2016 10:48 PM, Mathieu Desnoyers wrote: >> >>> Moreover, the feature set that the application knows about, glibc >>> knows about, and

Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

On 04/05/2016 06:47 PM, Peter Zijlstra wrote: > On Tue, Apr 05, 2016 at 06:02:25PM +0200, Florian Weimer wrote: >> On 04/04/2016 10:48 PM, Mathieu Desnoyers wrote: >> >>> Moreover, the feature set that the application knows about, glibc >>> knows about, and

Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

On 04/04/2016 10:48 PM, Mathieu Desnoyers wrote: > Moreover, the feature set that the application knows about, glibc > knows about, and the kernel knows about are three different things. > My intent here is to have glibc stay out of the way as much as possible, > since this is really an interface

Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

On 04/04/2016 10:48 PM, Mathieu Desnoyers wrote: > Moreover, the feature set that the application knows about, glibc > knows about, and the kernel knows about are three different things. > My intent here is to have glibc stay out of the way as much as possible, > since this is really an interface

Re: Kernel uapi and glibc header conflicts (was Re: header conflict introduced by change to netfilter_ipv4/ip_tables.h )

On 02/07/2016 12:31 PM, Mikko Rapeli wrote: > On Thu, Jan 07, 2016 at 10:30:40AM -0800, Stephen Hemminger wrote: >> On Thu, 7 Jan 2016 07:29:50 + >> Mikko Rapeli wrote: >> >>> On Wed, Jan 06, 2016 at 09:20:07AM -0800, Stephen Hemminger wrote: This commit breaks compilation of iproute2

Re: Kernel uapi and glibc header conflicts (was Re: header conflict introduced by change to netfilter_ipv4/ip_tables.h )

On 02/07/2016 12:31 PM, Mikko Rapeli wrote: > On Thu, Jan 07, 2016 at 10:30:40AM -0800, Stephen Hemminger wrote: >> On Thu, 7 Jan 2016 07:29:50 + >> Mikko Rapeli wrote: >> >>> On Wed, Jan 06, 2016 at 09:20:07AM -0800, Stephen Hemminger wrote: This commit breaks

Re: Asterisk deadlocks since Kernel 4.1

On 11/19/2015 01:46 PM, Stefan Priebe - Profihost AG wrote: > I can try Kernel 4.4-rc1 next week. Or something else? I found this bug report which indicates that 4.1.10 works: But in your original report, you said that 4.1.13 is

Re: Asterisk deadlocks since Kernel 4.1

On 11/18/2015 10:36 PM, Stefan Priebe wrote: >> please try to get a backtrace with debugging information. It is likely >> that this is the make_request/__check_pf functionality in glibc, but it >> would be nice to get some certainty. > > sorry here it is. What I'm wondering is why is there ipv6

Re: Asterisk deadlocks since Kernel 4.1

On 11/18/2015 10:23 PM, Stefan Priebe wrote: >> please try to get a backtrace with debugging information. It is likely >> that this is the make_request/__check_pf functionality in glibc, but it >> would be nice to get some certainty. >> >> Which glibc version do you use? Has it got a fix for

Re: Asterisk deadlocks since Kernel 4.1

On 11/18/2015 10:23 PM, Stefan Priebe wrote: >> please try to get a backtrace with debugging information. It is likely >> that this is the make_request/__check_pf functionality in glibc, but it >> would be nice to get some certainty. >> >> Which glibc version do you use? Has it got a fix for

Re: Asterisk deadlocks since Kernel 4.1

On 11/18/2015 10:36 PM, Stefan Priebe wrote: >> please try to get a backtrace with debugging information. It is likely >> that this is the make_request/__check_pf functionality in glibc, but it >> would be nice to get some certainty. > > sorry here it is. What I'm wondering is why is there ipv6

Re: Asterisk deadlocks since Kernel 4.1

On 11/19/2015 01:46 PM, Stefan Priebe - Profihost AG wrote: > I can try Kernel 4.4-rc1 next week. Or something else? I found this bug report which indicates that 4.1.10 works: But in your original report, you said that 4.1.13 is

Re: Asterisk deadlocks since Kernel 4.1

On 11/18/2015 09:23 PM, Stefan Priebe wrote: > > Am 17.11.2015 um 20:43 schrieb Thomas Gleixner: >> On Tue, 17 Nov 2015, Stefan Priebe wrote: >>> I've now also two gdb backtraces from two crashes: >>> http://pastebin.com/raw.php?i=yih5jNt8 >>> >>> http://pastebin.com/raw.php?i=kGEcvH4T >> >> They

Re: Asterisk deadlocks since Kernel 4.1

On 11/18/2015 09:23 PM, Stefan Priebe wrote: > > Am 17.11.2015 um 20:43 schrieb Thomas Gleixner: >> On Tue, 17 Nov 2015, Stefan Priebe wrote: >>> I've now also two gdb backtraces from two crashes: >>> http://pastebin.com/raw.php?i=yih5jNt8 >>> >>> http://pastebin.com/raw.php?i=kGEcvH4T >> >> They

Re: Getrandom wrapper

On 10/25/2015 02:40 PM, Theodore Ts'o wrote: > On Sun, Oct 25, 2015 at 02:17:23PM +0100, Florian Weimer wrote: >> >> I think we can reach consensus for an implementation which makes this code >> >> unsigned char session_key[32]; >> getrandom (ses

Re: Getrandom wrapper

On 10/25/2015 02:40 PM, Theodore Ts'o wrote: > On Sun, Oct 25, 2015 at 02:17:23PM +0100, Florian Weimer wrote: >> >> I think we can reach consensus for an implementation which makes this code >> >> unsigned char session_key[32]; >> getrandom (ses

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

On 10/25/2015 12:58 PM, Theodore Ts'o wrote: > Well, I was thinking we could just teach them to use > "syscall(SYS_gettid)". Right, and that's easier if TIDs are officially part of the GNU API. I think the worry is that some future system might have TIDs which do not share the PID space, or are

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

On 10/25/2015 11:41 AM, Theodore Ts'o wrote: > On Sun, Oct 25, 2015 at 10:33:32AM +0100, Ingo Molnar wrote: >> >> Hm, that's weird - all our sched_*() system call APIs that set task >> scheduling >> priorities are fundamentally per thread, not per process. Same goes for the >> old >>

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

On 10/25/2015 12:58 PM, Theodore Ts'o wrote: > Well, I was thinking we could just teach them to use > "syscall(SYS_gettid)". Right, and that's easier if TIDs are officially part of the GNU API. I think the worry is that some future system might have TIDs which do not share the PID space, or are

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

On 10/25/2015 11:41 AM, Theodore Ts'o wrote: > On Sun, Oct 25, 2015 at 10:33:32AM +0100, Ingo Molnar wrote: >> >> Hm, that's weird - all our sched_*() system call APIs that set task >> scheduling >> priorities are fundamentally per thread, not per process. Same goes for the >> old >>

Re: [PATCH 07/12] mm: Pass the 4-bit protection key in via PROT_ bits to syscalls

* Dave Hansen: > On 09/04/2015 01:13 PM, Florian Weimer wrote: > ... >>>>> >>> #define PROT_WRITE 0x2 /* page can be written */ >>>>> >>> #define PROT_EXEC0x4 /* page can be executed */ >>>

<    1   2   3   4   5   6   7   >