Re: [PATCH v4 2/4] x86/elf: Support a new ELF aux vector AT_MINSIGSTKSZ

On 1/15/21 4:10 PM, Chang S. Bae via Libc-alpha wrote: > Historically, signal.h defines MINSIGSTKSZ (2KB) and SIGSTKSZ (8KB), for > use by all architectures with sigaltstack(2). Over time, the hardware state > size grew, but these constants did not evolve. Today, literal use of these > constants

Re: [Y2038][time namespaces] Question regarding CLOCK_REALTIME support plans in Linux time namespaces

On 11/25/20 7:17 PM, Thomas Gleixner wrote: > Carlos, Petr, > > On Wed, Nov 25 2020 at 15:37, Carlos O'Donell wrote: >> On 11/19/20 7:14 PM, Thomas Gleixner wrote: >>> So from my point of view asking for distorted time still _is_ a request >>> for ponies. >>

Re: [Y2038][time namespaces] Question regarding CLOCK_REALTIME support plans in Linux time namespaces

On 11/19/20 7:14 PM, Thomas Gleixner wrote: > I hope you are aware that the time namespace offsets have to be set > _before_ the process starts and can't be changed afterwards, > i.e. settime() is not an option. I not interested in settime(). I saw Petr's request and forwarded it on here to

Re: [Y2038][time namespaces] Question regarding CLOCK_REALTIME support plans in Linux time namespaces

On 11/6/20 7:47 PM, Thomas Gleixner wrote: > On Thu, Nov 05 2020 at 12:25, Carlos O'Donell wrote: >> On 10/30/20 9:38 PM, Thomas Gleixner wrote: >> If kata grows up quickly perhaps this entire problem becomes solved, but >> until >> then I continue to have a

Re: [Y2038][time namespaces] Question regarding CLOCK_REALTIME support plans in Linux time namespaces

On 10/30/20 9:38 PM, Thomas Gleixner wrote: > Coming back to your test coverage argument. I really don't see a problem > with the requirement of having qemu installed in order to run 'make > check'. Cost. It's is cheaper and easier to maintain and deploy containers. A full VM requires

Re: [Y2038][time namespaces] Question regarding CLOCK_REALTIME support plans in Linux time namespaces

On 10/30/20 4:06 PM, Thomas Gleixner wrote: > On Fri, Oct 30 2020 at 12:58, Carlos O'Donell wrote: >> I expect that more requests for further time isolation will happen >> given the utility of this in containers. > > There was a lengthy discussion about this and the

Re: [Y2038][time namespaces] Question regarding CLOCK_REALTIME support plans in Linux time namespaces

On 10/30/20 11:10 AM, Thomas Gleixner via Libc-alpha wrote: > On Fri, Oct 30 2020 at 10:02, Zack Weinberg wrote: >> On Fri, Oct 30, 2020 at 9:57 AM Cyril Hrubis wrote: According to patch description [1] and time_namespaces documentation [2] the CLOCK_REALTIME is not supported (for now?)

Re: [PATCH v4 0/2] Syscall User Redirection

On 7/16/20 4:30 PM, Gabriel Krisman Bertazi wrote: > Christian Brauner writes: > >> On Thu, Jul 16, 2020 at 01:25:43PM -0700, Kees Cook wrote: >>> On Thu, Jul 16, 2020 at 10:22:34PM +0200, Christian Brauner wrote: On Thu, Jul 16, 2020 at 01:04:38PM -0700, Kees Cook wrote: > On Thu, Jul

Re: [RFC PATCH 0/4] rseq: Introduce extensible struct rseq

On 7/15/20 9:02 AM, Mathieu Desnoyers wrote: > At this point, the main question I would like answered is whether > it would be acceptable to increase the size and alignment of > the __rseq_abi symbol (which will be exposed by glibc) between > e.g. glibc 2.32 and 2.33. If it's not possible, then we

Re: [RFC PATCH 2/4] rseq: Allow extending struct rseq

On 7/14/20 9:19 AM, Mathieu Desnoyers wrote: > Is there an arch-agnostic way to get the thread pointer from user-space code > ? That > would be needed by all rseq critical section implementations. Yes, and no. We have void *__builtin_thread_pointer (void), but few architectures implement the

Re: [RFC PATCH 0/4] rseq: Introduce extensible struct rseq

On 7/13/20 11:03 PM, Mathieu Desnoyers wrote: > Recent discussion led to a solution for extending struct rseq. This is > an implementation of the proposed solution. > > Now is a good time to agree on this scheme before the release of glibc > 2.32, just in case there are small details to fix on

Re: [RFC PATCH for 5.8 3/4] rseq: Introduce RSEQ_FLAG_RELIABLE_CPU_ID

On 7/7/20 8:06 AM, Mathieu Desnoyers wrote: > - On Jul 7, 2020, at 7:32 AM, Florian Weimer f...@deneb.enyo.de wrote: > >> * Mathieu Desnoyers: >> >>> Those are very good points. One possibility we have would be to let >>> glibc do the rseq registration without the RSEQ_FLAG_RELIABLE_CPU_ID

Re: [PATCH 1/3] glibc: Perform rseq registration at C startup and thread creation (v22)

On 7/2/20 10:46 AM, Florian Weimer wrote: > * Mathieu Desnoyers via Libc-alpha: > >> Register rseq TLS for each thread (including main), and unregister for >> each thread (excluding main). "rseq" stands for Restartable Sequences. >> >> See the rseq(2) man page proposed here: >>

Re: [PATCH] futex: send SIGBUS if argument is not aligned on a four-byte boundary

On Fri, May 15, 2020 at 1:50 PM Carlos O'Donell wrote: > This isn't fixed because this is the older code in pthread_mutex_lock > which we haven't ported to futex-internal.h yet, otherwise we would abort > the process. I filed this upstream as a QoI issue so I don't forget to port the

Re: [PATCH] futex: send SIGBUS if argument is not aligned on a four-byte boundary

On 5/15/20 12:27 PM, Peter Zijlstra wrote: > On Fri, May 15, 2020 at 06:36:47PM +0300, Konstantin Khlebnikov wrote: >> Userspace implementations of mutexes (including glibc) in some cases >> retries operation without checking error code from syscall futex. >> This is good for performance because

Re: [PATCH glibc 2.31 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v12)

On 9/11/19 3:08 PM, Florian Weimer wrote: > * Carlos O'Donell: > >> It would be easier to merge the patch set if it were just an unconditional >> registration like we do for set_robust_list(). > > Note that this depends on the in-tree system call numbers list, which

Re: [PATCH glibc 2.31 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v12)

On 9/11/19 2:26 PM, Florian Weimer wrote: > * Mathieu Desnoyers: > >> +#ifdef SHARED >> + if (rtld_active ()) >> +{ >> + /* Register rseq ABI to the kernel. */ >> + (void) rseq_register_current_thread (); >> +} >> +#else > > I think this will need *another* check for the

Re: [PATCH 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v10)

On 6/6/19 7:57 AM, Florian Weimer wrote: > Let me ask the key question again: Does it matter if code observes the > rseq area first without kernel support, and then with kernel support? > If we don't expect any problems immediately, we do not need to worry > much about the constructor ordering

Re: [PATCH 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v7)

On 4/9/19 9:58 AM, Tulio Magno Quites Machado Filho wrote: Alan Modra writes: Yes, looks fine to me, except that in VLE mode (do we care?) ".long 0x0fe50553" disassembles as 0: 0f e5 se_cmphl r5,r30 2: 05 53 se_mullw r3,r5 No illegal/trap/privileged insn there.

Re: [PATCH 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v7)

On 4/8/19 3:20 PM, Tulio Magno Quites Machado Filho wrote: Carlos O'Donell writes: On 4/5/19 5:16 AM, Florian Weimer wrote: * Carlos O'Donell: It is valuable that it be a trap, particularly for constant pools because it means that a jump into the constant pool will trap. Sorry, I don't

Re: [PATCH 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v7)

On 4/5/19 5:16 AM, Florian Weimer wrote: * Carlos O'Donell: It is valuable that it be a trap, particularly for constant pools because it means that a jump into the constant pool will trap. Sorry, I don't understand why this matters in this context. Would you please elaborate? Sorry, I

Re: [PATCH 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v7)

On 3/25/19 11:54 AM, Mathieu Desnoyers wrote: Hi Carlos, - On Mar 22, 2019, at 4:09 PM, Carlos O'Donell codon...@redhat.com wrote: [...] I took care of all your comments for an upcoming round of patches, except the following that remain open (see answer inline). I'm adding Linux

Re: [PATCH 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v7)

On 4/2/19 3:08 AM, Florian Weimer wrote: * Michael Ellerman: I'm a bit vague on what we're trying to do here. But it seems like you want some sort of "eye catcher" prior to the branch? That value is a valid instruction on current CPUs (rlwimi. r5,r24,6,1,9), and even if it wasn't it could

Re: [PATCH 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v7)

On 4/2/19 2:02 AM, Michael Ellerman wrote: Mathieu Desnoyers writes: Hi Carlos, - On Mar 22, 2019, at 4:09 PM, Carlos O'Donell codon...@redhat.com wrote: ... [...] +++ b/sysdeps/unix/sysv/linux/powerpc/bits/rseq.h [...] +/* Signature required before each abort handler code

Re: [PATCH 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v7)

On 3/27/19 5:16 AM, Martin Schwidefsky wrote: On Mon, 25 Mar 2019 11:54:32 -0400 (EDT) Mathieu Desnoyers wrote: +++ b/sysdeps/unix/sysv/linux/s390/bits/rseq.h [...] + +/* Signature required before each abort handler code. */ +#define RSEQ_SIG 0x53053053 Why not a s390 specific value

Re: [PATCH 2/4] glibc: sched_getcpu(): use rseq cpu_id TLS on Linux

, but is blocked on patch 1/4 being reworked. Reviewed-by: Carlos O'Donell glibc sched_getcpu(): 13.7 ns (baseline) glibc sched_getcpu() using rseq: 2.5 ns (speedup: 5.5x) inline load cpuid from __rseq_abi TLS: 0.8 ns (speedup: 17.1x) Signed-off-by: Mathieu

Re: [PATCH 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v7)

This patch is based on glibc-2.29. The rseq(2) system call was merged into Linux 4.18. Signed-off-by: Mathieu Desnoyers CC: Carlos O'Donell CC: Florian Weimer CC: Joseph Myers CC: Szabolcs Nagy CC: Thomas Gleixner CC: Ben Maurer CC: Peter Zijlstra CC: "Paul E. McKenney" CC: Boqun Feng

Re: Official Linux system wrapper library?

On 12/10/18 11:27 AM, Jonathan Corbet wrote: > On Sat, 8 Dec 2018 20:38:56 -0800 > Randy Dunlap wrote: > >> On 11/12/18 8:08 AM, Jonathan Corbet wrote: >>> On Sun, 11 Nov 2018 18:36:30 -0800 >>> Greg KH wrote: >>> We should have a checklist. That's a great idea. Now to find someone

Re: Official Linux system wrapper library?

On 11/15/18 12:08 PM, Theodore Y. Ts'o wrote: > On Thu, Nov 15, 2018 at 04:29:43PM +, Joseph Myers wrote: >> On Thu, 15 Nov 2018, Theodore Y. Ts'o wrote: >> >>> That's great. But is it or is it not true (either de jure or de >>> facto) that "a single active glibc developer" can block a system

Re: Official Linux system wrapper library?

On 11/15/18 12:08 PM, Theodore Y. Ts'o wrote: > On Thu, Nov 15, 2018 at 04:29:43PM +, Joseph Myers wrote: >> On Thu, 15 Nov 2018, Theodore Y. Ts'o wrote: >> >>> That's great. But is it or is it not true (either de jure or de >>> facto) that "a single active glibc developer" can block a system

Re: Official Linux system wrapper library?

On 11/14/18 1:47 PM, Joseph Myers wrote: > On Wed, 14 Nov 2018, Daniel Colascione wrote: > >> A good demonstration of a new commitment to pragmatism would be >> merging the trivial wrappers for gettid(2). > > I support the addition of gettid (for use with those syscalls that take > tids, and

Re: Official Linux system wrapper library?

On 11/14/18 1:47 PM, Joseph Myers wrote: > On Wed, 14 Nov 2018, Daniel Colascione wrote: > >> A good demonstration of a new commitment to pragmatism would be >> merging the trivial wrappers for gettid(2). > > I support the addition of gettid (for use with those syscalls that take > tids, and

Re: Official Linux system wrapper library?

On 11/14/18 6:58 AM, Szabolcs Nagy wrote: > an actual proposal in the thread that i think is > worth considering is to make the linux syscall > design process involve libc devs so the c api is > designed together with the syscall abi. Right, I see at least 2 actionable items: * "The Checklist"

Re: Official Linux system wrapper library?

On 11/14/18 6:58 AM, Szabolcs Nagy wrote: > an actual proposal in the thread that i think is > worth considering is to make the linux syscall > design process involve libc devs so the c api is > designed together with the syscall abi. Right, I see at least 2 actionable items: * "The Checklist"

Re: Official Linux system wrapper library?

On 11/12/18 11:43 AM, Joseph Myers wrote: > On Sun, 11 Nov 2018, Florian Weimer wrote: > >> People may have disappeared from glibc development who have objected to >> gettid. I thought this was the case with strlcpy/strlcat, but it was >> not. > > Well, I know of two main people who were

Re: Official Linux system wrapper library?

On 11/12/18 11:43 AM, Joseph Myers wrote: > On Sun, 11 Nov 2018, Florian Weimer wrote: > >> People may have disappeared from glibc development who have objected to >> gettid. I thought this was the case with strlcpy/strlcat, but it was >> not. > > Well, I know of two main people who were

Re: Official Linux system wrapper library?

On 11/10/18 2:20 PM, Greg KH wrote: > Also, what about the basic work of making sure our uapi header files can > actually be used untouched by a libc? That isn't the case these days as > the bionic maintainers like to keep reminding me. That might be a good > thing to do _before_ trying to add

Re: Official Linux system wrapper library?

On 11/10/18 2:20 PM, Greg KH wrote: > Also, what about the basic work of making sure our uapi header files can > actually be used untouched by a libc? That isn't the case these days as > the bionic maintainers like to keep reminding me. That might be a good > thing to do _before_ trying to add

Re: Official Linux system wrapper library?

On 11/10/18 2:58 PM, Vlastimil Babka wrote: > On 11/10/18 8:20 PM, Greg KH wrote: >> On Sat, Nov 10, 2018 at 10:52:06AM -0800, Daniel Colascione wrote: >>> Now that glibc is basically not adding any new system call wrappers, >> >> Why are they not doing that anymore? > > FYI just noticed there's

Re: Official Linux system wrapper library?

On 11/10/18 2:58 PM, Vlastimil Babka wrote: > On 11/10/18 8:20 PM, Greg KH wrote: >> On Sat, Nov 10, 2018 at 10:52:06AM -0800, Daniel Colascione wrote: >>> Now that glibc is basically not adding any new system call wrappers, >> >> Why are they not doing that anymore? > > FYI just noticed there's

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On 10/13/2017 02:36 PM, Mathieu Desnoyers wrote: > I also spoke to Carlos O'Donell from glibc about it, and he was very > excited about the possible use of rseq for malloc speedup/memory usage > improvement. But again, I don't see a project like glibc starting to > use a system ca

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On 10/13/2017 02:36 PM, Mathieu Desnoyers wrote: > I also spoke to Carlos O'Donell from glibc about it, and he was very > excited about the possible use of rseq for malloc speedup/memory usage > improvement. But again, I don't see a project like glibc starting to > use a system ca

Re: RFC: Audit Kernel Container IDs

On 09/13/2017 12:13 PM, Richard Guy Briggs wrote: > Containers are a userspace concept. The kernel knows nothing of them. I am looking at this RFC from a userspace perspective, particularly from the loader's point of view and the unshare syscall and the semantics that arise from the use of it.

Re: RFC: Audit Kernel Container IDs

On 09/13/2017 12:13 PM, Richard Guy Briggs wrote: > Containers are a userspace concept. The kernel knows nothing of them. I am looking at this RFC from a userspace perspective, particularly from the loader's point of view and the unshare syscall and the semantics that arise from the use of it.

Re: new ELF marking

On 08/09/2017 05:24 PM, H.J. Lu wrote: > On Wed, Aug 9, 2017 at 1:32 PM, Kostya Serebryany wrote: I believe this would only be an output bit, but I'm not sure how it would be wired into binutils. Kostya, do you know any details about how AddressSanitizer might

Re: new ELF marking

On 08/09/2017 05:24 PM, H.J. Lu wrote: > On Wed, Aug 9, 2017 at 1:32 PM, Kostya Serebryany wrote: I believe this would only be an output bit, but I'm not sure how it would be wired into binutils. Kostya, do you know any details about how AddressSanitizer might be able to

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

On 04/25/2017 02:45 AM, Hauke Mehrtens wrote: > On 03/08/2017 05:39 PM, Carlos O'Donell wrote: >> Any header needing compat with a libc includes libc-compat.h (per the >> documented way the model works). With this patch any included linux kernel >> header that also include

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

On 04/25/2017 02:45 AM, Hauke Mehrtens wrote: > On 03/08/2017 05:39 PM, Carlos O'Donell wrote: >> Any header needing compat with a libc includes libc-compat.h (per the >> documented way the model works). With this patch any included linux kernel >> header that also include

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

On 04/25/2017 02:37 AM, Hauke Mehrtens wrote: > > > On 03/08/2017 01:46 PM, David Woodhouse wrote: >> On Fri, 2016-11-11 at 07:08 -0500, Felix Janda wrote: >>> Currently, libc-compat.h detects inclusion of specific glibc headers, >>> and defines corresponding _UAPI_DEF_* macros, which in turn

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

On 04/25/2017 02:37 AM, Hauke Mehrtens wrote: > > > On 03/08/2017 01:46 PM, David Woodhouse wrote: >> On Fri, 2016-11-11 at 07:08 -0500, Felix Janda wrote: >>> Currently, libc-compat.h detects inclusion of specific glibc headers, >>> and defines corresponding _UAPI_DEF_* macros, which in turn

Re: Formal description of system call interface

On 11/06/2016 05:39 PM, Dmitry Vyukov wrote: > Hello, > > This is notes from the discussion we had at Linux Plumbers this week > regarding providing a formal description of system calls (user API). > > The idea come up in the context of syzkaller, syscall fuzzer, which > has descriptions for

Re: Formal description of system call interface

On 11/06/2016 05:39 PM, Dmitry Vyukov wrote: > Hello, > > This is notes from the discussion we had at Linux Plumbers this week > regarding providing a formal description of system calls (user API). > > The idea come up in the context of syzkaller, syscall fuzzer, which > has descriptions for

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

On 03/08/2017 07:14 PM, Szabolcs Nagy wrote: > * Carlos O'Donell <car...@redhat.com> [2017-03-08 10:53:00 -0500]: >> On 11/11/2016 07:08 AM, Felix Janda wrote: >>> fixes the following compiler errors when is included >>> after musl : >>> >>>

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

On 03/08/2017 07:14 PM, Szabolcs Nagy wrote: > * Carlos O'Donell [2017-03-08 10:53:00 -0500]: >> On 11/11/2016 07:08 AM, Felix Janda wrote: >>> fixes the following compiler errors when is included >>> after musl : >>> >>> ./linux/in6.h:32:8: error:

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

On 03/08/2017 11:25 AM, Rich Felker wrote: > On Wed, Mar 08, 2017 at 10:53:00AM -0500, Carlos O'Donell wrote: >> On 11/11/2016 07:08 AM, Felix Janda wrote: >>> Currently, libc-compat.h detects inclusion of specific glibc headers, >>> and defines corresponding _UAPI_

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

On 03/08/2017 11:25 AM, Rich Felker wrote: > On Wed, Mar 08, 2017 at 10:53:00AM -0500, Carlos O'Donell wrote: >> On 11/11/2016 07:08 AM, Felix Janda wrote: >>> Currently, libc-compat.h detects inclusion of specific glibc headers, >>> and defines corresponding _UAPI_

Re: opaque types instead of union epoll_data

On 03/07/2017 12:59 PM, Greg KH wrote: > On Tue, Mar 07, 2017 at 09:33:57AM -0500, Carlos O'Donell wrote: >> I don't know anyone else who is working on this problem. Though I >> have a vested interested in it as a glibc maintainer, since it would >> be nice to avoid du

Re: opaque types instead of union epoll_data

On 03/07/2017 12:59 PM, Greg KH wrote: > On Tue, Mar 07, 2017 at 09:33:57AM -0500, Carlos O'Donell wrote: >> I don't know anyone else who is working on this problem. Though I >> have a vested interested in it as a glibc maintainer, since it would >> be nice to avoid du

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

On 03/08/2017 07:46 AM, David Woodhouse wrote: > On Fri, 2016-11-11 at 07:08 -0500, Felix Janda wrote: >> Currently, libc-compat.h detects inclusion of specific glibc headers, >> and defines corresponding _UAPI_DEF_* macros, which in turn are used in >> uapi headers to prevent definition of

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

On 03/08/2017 07:46 AM, David Woodhouse wrote: > On Fri, 2016-11-11 at 07:08 -0500, Felix Janda wrote: >> Currently, libc-compat.h detects inclusion of specific glibc headers, >> and defines corresponding _UAPI_DEF_* macros, which in turn are used in >> uapi headers to prevent definition of

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

On 11/11/2016 07:08 AM, Felix Janda wrote: > Currently, libc-compat.h detects inclusion of specific glibc headers, > and defines corresponding _UAPI_DEF_* macros, which in turn are used in > uapi headers to prevent definition of conflicting structures/constants. > There is no such detection for

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

On 11/11/2016 07:08 AM, Felix Janda wrote: > Currently, libc-compat.h detects inclusion of specific glibc headers, > and defines corresponding _UAPI_DEF_* macros, which in turn are used in > uapi headers to prevent definition of conflicting structures/constants. > There is no such detection for

Re: opaque types instead of union epoll_data

On 03/07/2017 07:31 AM, Sodagudi Prasad wrote: > uapi structs epoll_data are more opaque than user space expects. > kernel have defined as __u64 instead of the union epoll_data. Because > of this libc have redefined struct epoll_event with union data > member. We do the same in glibc. >

Re: opaque types instead of union epoll_data

On 03/07/2017 07:31 AM, Sodagudi Prasad wrote: > uapi structs epoll_data are more opaque than user space expects. > kernel have defined as __u64 instead of the union epoll_data. Because > of this libc have redefined struct epoll_event with union data > member. We do the same in glibc. >

Re: [PATCH] uapi: fix asm/signal.h userspace compilation errors

On Fri, Mar 3, 2017 at 8:23 PM, Carlos O'Donell <car...@systemhalted.org> wrote: > On Thu, Mar 2, 2017 at 10:48 AM, Dmitry V. Levin <l...@altlinux.org> wrote: >> On Thu, Mar 02, 2017 at 10:22:18AM -0500, Carlos O'Donell wrote: >>> On Wed, Mar 1, 2017 at 11:20 AM

Re: [PATCH] uapi: fix asm/signal.h userspace compilation errors

On Fri, Mar 3, 2017 at 8:23 PM, Carlos O'Donell wrote: > On Thu, Mar 2, 2017 at 10:48 AM, Dmitry V. Levin wrote: >> On Thu, Mar 02, 2017 at 10:22:18AM -0500, Carlos O'Donell wrote: >>> On Wed, Mar 1, 2017 at 11:20 AM, Arnd Bergmann wrote: >>> > On Sun, Feb 26, 20

Re: [PATCH] uapi: fix asm/signal.h userspace compilation errors

On Thu, Mar 2, 2017 at 10:48 AM, Dmitry V. Levin <l...@altlinux.org> wrote: > On Thu, Mar 02, 2017 at 10:22:18AM -0500, Carlos O'Donell wrote: >> On Wed, Mar 1, 2017 at 11:20 AM, Arnd Bergmann <a...@arndb.de> wrote: >> > On Sun, Feb 26, 2017 at 2:01 AM, Dmitry V. L

Re: [PATCH] uapi: fix asm/signal.h userspace compilation errors

On Thu, Mar 2, 2017 at 10:48 AM, Dmitry V. Levin wrote: > On Thu, Mar 02, 2017 at 10:22:18AM -0500, Carlos O'Donell wrote: >> On Wed, Mar 1, 2017 at 11:20 AM, Arnd Bergmann wrote: >> > On Sun, Feb 26, 2017 at 2:01 AM, Dmitry V. Levin wrote: >> >> Include (guarded

Re: [PATCH] uapi: fix asm/signal.h userspace compilation errors

On Wed, Mar 1, 2017 at 11:20 AM, Arnd Bergmann wrote: > On Sun, Feb 26, 2017 at 2:01 AM, Dmitry V. Levin wrote: >> Include (guarded by #ifndef __KERNEL__) to fix asm/signal.h >> userspace compilation errors like this: >> >> /usr/include/asm/signal.h:126:2:

Re: [PATCH] uapi: fix asm/signal.h userspace compilation errors

On Wed, Mar 1, 2017 at 11:20 AM, Arnd Bergmann wrote: > On Sun, Feb 26, 2017 at 2:01 AM, Dmitry V. Levin wrote: >> Include (guarded by #ifndef __KERNEL__) to fix asm/signal.h >> userspace compilation errors like this: >> >> /usr/include/asm/signal.h:126:2: error: unknown type name 'size_t' >>

Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR

On 12/26/2016 09:24 PM, Kirill A. Shutemov wrote: > On Mon, Dec 26, 2016 at 06:06:01PM -0800, Andy Lutomirski wrote: >> On Mon, Dec 26, 2016 at 5:54 PM, Kirill A. Shutemov >> wrote: >>> This patch introduces new rlimit resource to manage maximum virtual >>>

Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR

On 12/26/2016 09:24 PM, Kirill A. Shutemov wrote: > On Mon, Dec 26, 2016 at 06:06:01PM -0800, Andy Lutomirski wrote: >> On Mon, Dec 26, 2016 at 5:54 PM, Kirill A. Shutemov >> wrote: >>> This patch introduces new rlimit resource to manage maximum virtual >>> address available to userspace to map.

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

On 08/26/2016 10:55 AM, Florian Weimer wrote: > 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

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

On 08/26/2016 10:55 AM, Florian Weimer wrote: > 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

Re: [RFC patch 4/7] futex: Add support for attached futexes

On 04/03/2016 07:30 AM, Linus Torvalds wrote: > On Sun, Apr 3, 2016 at 6:16 AM, Ingo Molnar wrote: >> >> So an ABI distinction and offloading the decision to every single >> application that >> wants to use it and hardcode it into actual application source code via an >> ABI

Re: [RFC patch 4/7] futex: Add support for attached futexes

On 04/03/2016 07:30 AM, Linus Torvalds wrote: > On Sun, Apr 3, 2016 at 6:16 AM, Ingo Molnar wrote: >> >> So an ABI distinction and offloading the decision to every single >> application that >> wants to use it and hardcode it into actual application source code via an >> ABI is >> pretty much

Re: [PATCH v2 1/2] posix-timers: Prevents overrun counter overflow

On 01/24/2015 12:48 PM, Daniel Church wrote: > +#define DELAYTIMER_MAX_DEFAULT 100 Why did you chose 1 million? Have you reviewed what constant userspace, particularly glibc, is using? Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of

Re: [PATCH v2 2/2] posix-timers: Exposes DELAYTIMER_MAX constant used to govern overruns

On 01/24/2015 02:20 PM, Thomas Gleixner wrote: > On Sat, 24 Jan 2015, Daniel Church wrote: > >> POSIX.1-2001 specification of timer_getoverrun() supports constant >> DELAYTIMER_MAX which prevents overflow and caps overrun count. Exposes >> delaytimer_max value to userland via

Re: [PATCH v2 1/2] posix-timers: Prevents overrun counter overflow

On 01/24/2015 12:48 PM, Daniel Church wrote: +#define DELAYTIMER_MAX_DEFAULT 100 Why did you chose 1 million? Have you reviewed what constant userspace, particularly glibc, is using? Cheers, Carlos. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a

Re: [PATCH v2 2/2] posix-timers: Exposes DELAYTIMER_MAX constant used to govern overruns

On 01/24/2015 02:20 PM, Thomas Gleixner wrote: On Sat, 24 Jan 2015, Daniel Church wrote: POSIX.1-2001 specification of timer_getoverrun() supports constant DELAYTIMER_MAX which prevents overflow and caps overrun count. Exposes delaytimer_max value to userland via

Re: [PATCH] arch: uapi: asm: mman.h: Support MADV_FREE for madvise()

On Mon, Dec 1, 2014 at 4:35 PM, Geert Uytterhoeven wrote: > On Mon, Dec 1, 2014 at 9:52 PM, Max Filippov wrote: >> On Mon, Dec 1, 2014 at 11:43 PM, Chen Gang wrote: >>> At present, kernel supports madvise(MADV_FREE), so can benefit to all >>> related architectures (can grep MADV_WILLNEED or

Re: [PATCH] arch: uapi: asm: mman.h: Support MADV_FREE for madvise()

On Mon, Dec 1, 2014 at 4:35 PM, Geert Uytterhoeven ge...@linux-m68k.org wrote: On Mon, Dec 1, 2014 at 9:52 PM, Max Filippov jcmvb...@gmail.com wrote: On Mon, Dec 1, 2014 at 11:43 PM, Chen Gang gang.chen.5...@gmail.com wrote: At present, kernel supports madvise(MADV_FREE), so can benefit to all

Re: futex(2) man page update help request

On 05/15/2014 04:19 PM, Michael Kerrisk (man-pages) wrote: > On 05/15/2014 04:14 PM, Thomas Gleixner wrote: >> On Thu, 15 May 2014, Michael Kerrisk (man-pages) wrote: >>> And that universe would love to have your documentation of >>> FUTEX_WAKE_BITSET and FUTEX_WAIT_BITSET ;-), >> >> I give you

Re: futex(2) man page update help request

On 05/15/2014 04:19 PM, Michael Kerrisk (man-pages) wrote: On 05/15/2014 04:14 PM, Thomas Gleixner wrote: On Thu, 15 May 2014, Michael Kerrisk (man-pages) wrote: And that universe would love to have your documentation of FUTEX_WAKE_BITSET and FUTEX_WAIT_BITSET ;-), I give you almost the full

Re: [PATCH resend #7] fcntl-linux.h: add new definitions and manual updates for open file description locks

On 07/23/2014 02:21 PM, Jeff Layton wrote: > From: Jeff Layton Thanks for resending. Sorry for the delay. Your use of 3 different emails caused me to miss the recent resends. That's my fault and tied to the way I'm tracking everything from patchwork using the first email you used. I am

Re: [PATCH resend #7] fcntl-linux.h: add new definitions and manual updates for open file description locks

On 07/23/2014 02:21 PM, Jeff Layton wrote: From: Jeff Layton jlay...@poochiereds.net Thanks for resending. Sorry for the delay. Your use of 3 different emails caused me to miss the recent resends. That's my fault and tied to the way I'm tracking everything from patchwork using the first email

Re: [patch 0/3] futex/rtmutex: Fix issues exposed by trinity

On 05/15/2014 04:25 AM, Peter Zijlstra wrote: > On Wed, May 14, 2014 at 04:59:58PM -0400, Carlos O'Donell wrote: >> I will make my personal opinion clear: >> >> - Internal defects should raise immediate assertions. >> >> - Real problems like resource availa

Re: [patch 0/3] futex/rtmutex: Fix issues exposed by trinity

On 05/15/2014 04:07 AM, Peter Zijlstra wrote: > On Wed, May 14, 2014 at 05:17:35PM -0400, Carlos O'Donell wrote: >>> No, its perfectly fine to have a lock sequence abort with -EDEADLK. >>> Userspace should release its locks and re-attempt. >> >> I agree.

Re: [patch 0/3] futex/rtmutex: Fix issues exposed by trinity

On 05/14/2014 06:28 AM, Thomas Gleixner wrote: > On Wed, 14 May 2014, Peter Zijlstra wrote: >> On Wed, May 14, 2014 at 11:53:44AM +0200, Thomas Gleixner wrote: What error would we return? This particular case is a serious error for which we have no good error code to

Re: [patch 0/3] futex/rtmutex: Fix issues exposed by trinity

On 05/14/2014 07:11 PM, Thomas Gleixner wrote: > On Wed, 14 May 2014, Carlos O'Donell wrote: >> On 05/14/2014 05:22 AM, Peter Zijlstra wrote: >>>>> I believe the thinking goes that if we get to here, then the lock is in an >>>>> inconsistent state (betw

Re: [patch 0/3] futex/rtmutex: Fix issues exposed by trinity

On 05/14/2014 07:11 PM, Thomas Gleixner wrote: On Wed, 14 May 2014, Carlos O'Donell wrote: On 05/14/2014 05:22 AM, Peter Zijlstra wrote: I believe the thinking goes that if we get to here, then the lock is in an inconsistent state (between kernel and userspace). I don't have an answer

Re: [patch 0/3] futex/rtmutex: Fix issues exposed by trinity

On 05/14/2014 06:28 AM, Thomas Gleixner wrote: On Wed, 14 May 2014, Peter Zijlstra wrote: On Wed, May 14, 2014 at 11:53:44AM +0200, Thomas Gleixner wrote: What error would we return? This particular case is a serious error for which we have no good error code to return to userspace. It's

Re: [patch 0/3] futex/rtmutex: Fix issues exposed by trinity

On 05/15/2014 04:07 AM, Peter Zijlstra wrote: On Wed, May 14, 2014 at 05:17:35PM -0400, Carlos O'Donell wrote: No, its perfectly fine to have a lock sequence abort with -EDEADLK. Userspace should release its locks and re-attempt. I agree. If I can prove that it's actually a deadlock

Re: [patch 0/3] futex/rtmutex: Fix issues exposed by trinity

On 05/15/2014 04:25 AM, Peter Zijlstra wrote: On Wed, May 14, 2014 at 04:59:58PM -0400, Carlos O'Donell wrote: I will make my personal opinion clear: - Internal defects should raise immediate assertions. - Real problems like resource availability, deadlocks, and other recoverable errors

Re: futex(2) man page update help request

On 05/14/2014 08:28 PM, H. Peter Anvin wrote: > On 05/14/2014 01:56 PM, Davidlohr Bueso wrote: >>> However, unless I'm sorely mistaken, the larger problem is that glibc removed the futex() call entirely, so these man pages don't describe >>> >>> I don't think futex() ever was in

Re: futex(2) man page update help request

On 05/15/2014 09:49 AM, Michael Kerrisk (man-pages) wrote: > On Thu, May 15, 2014 at 3:22 PM, Peter Zijlstra wrote: >> On Thu, May 15, 2014 at 09:18:22AM -0400, Carlos O'Donell wrote: >>> On 05/15/2014 04:14 AM, Peter Zijlstra wrote: >>>> On Wed, May 14, 2014 at 04:

Re: futex(2) man page update help request

On 05/15/2014 04:14 AM, Peter Zijlstra wrote: > On Wed, May 14, 2014 at 04:23:38PM -0400, Carlos O'Donell wrote: >> There are other syscalls like gettid() that have a: >> NOTE: There is no glibc wrapper for this system call; see NOTES. > > Yes, can we finally fix that pl

Re: futex(2) man page update help request

On 05/15/2014 04:14 AM, Peter Zijlstra wrote: On Wed, May 14, 2014 at 04:23:38PM -0400, Carlos O'Donell wrote: There are other syscalls like gettid() that have a: NOTE: There is no glibc wrapper for this system call; see NOTES. Yes, can we finally fix that please? It gets tedious having

Re: futex(2) man page update help request

On 05/15/2014 09:49 AM, Michael Kerrisk (man-pages) wrote: On Thu, May 15, 2014 at 3:22 PM, Peter Zijlstra pet...@infradead.org wrote: On Thu, May 15, 2014 at 09:18:22AM -0400, Carlos O'Donell wrote: On 05/15/2014 04:14 AM, Peter Zijlstra wrote: On Wed, May 14, 2014 at 04:23:38PM -0400, Carlos

Re: futex(2) man page update help request

On 05/14/2014 08:28 PM, H. Peter Anvin wrote: On 05/14/2014 01:56 PM, Davidlohr Bueso wrote: However, unless I'm sorely mistaken, the larger problem is that glibc removed the futex() call entirely, so these man pages don't describe I don't think futex() ever was in glibc--that's by design,

  1   2   >