* Catalin Marinas:
> On Tue, Dec 11, 2018 at 10:02:45AM +0100, Arnd Bergmann wrote:
>> On Tue, Dec 11, 2018 at 6:35 AM Andy Lutomirski wrote:
>> > I tried to understand what's going on. As far as I can tell, most of
>> > the magic is the fact that __kernel_long_t and __kernel_ulong_t are
>> >
* Mathieu Desnoyers:
> I want to keep the __rseq_refcount symbol so out-of-libc users can
> register rseq if they are linked against a pre-2.29 libc.
Sorry, I was confused.
> diff --git a/csu/Makefile b/csu/Makefile
> index 88fc77662e..81d471587f 100644
> --- a/csu/Makefile
> +++ b/csu/Makefile
* John Paul Adrian Glaubitz:
> As for the enterprise support, this seems to be correct. I don't know
> of any enterprise distribution with x32 support either.
Me neither. I would expect a pure userspace port, with limitations in
what ioctls you can use, and perhaps support from GCC to share
* Linus Torvalds:
> Apparently the main real use case is for extreme benchmarking. It's
> the only use-case where the complexity of maintaining a whole
> development environment and distro is worth it, it seems. Apparently a
> number of Spec submissions have been done with the x32 model.
Are you
* Andy Lutomirski:
>> I suppose that's fine. Or alternatively, when thread group support is
>> added, introduce a flag that applications have to use to enable it, so
>> that they can probe for support by checking support for the flag.
>>
>> I wouldn't be opposed to a new system call like this
* Andy Lutomirski:
>> I suppose that's fine. Or alternatively, when thread group support is
>> added, introduce a flag that applications have to use to enable it, so
>> that they can probe for support by checking support for the flag.
>>
>> I wouldn't be opposed to a new system call like this
* Maciej W. Rozycki:
> On Thu, 6 Dec 2018, Joseph Myers wrote:
>
>> > So how are `SYS_' macros generated that land in ?
>>
>> By gen-syscall-h.awk, which generates #ifdef conditionals for each
>> possible __NR_* name (as listed in syscall-names.list in glibc).
>
> I seem to remember having to
* Eric W. Biederman:
> Floriam are you seeing a problem with this behavior or the way Christian
> was describing it?
My hope is that you could use taskfd_send_signal one day to send a
signal to a process which you *known* (based on how you've written your
application) should be running and not
* Eric W. Biederman:
> Floriam are you seeing a problem with this behavior or the way Christian
> was describing it?
My hope is that you could use taskfd_send_signal one day to send a
signal to a process which you *known* (based on how you've written your
application) should be running and not
* Jürg Billeter:
> On Thu, 2018-12-06 at 14:12 +0100, Florian Weimer wrote:
>> * Jürg Billeter:
>>
>> > On Thu, 2018-12-06 at 13:30 +0100, Florian Weimer wrote:
>> > > * Christian Brauner:
>> > >
>> > > > /* zombies */
>> >
* Jürg Billeter:
> On Thu, 2018-12-06 at 14:12 +0100, Florian Weimer wrote:
>> * Jürg Billeter:
>>
>> > On Thu, 2018-12-06 at 13:30 +0100, Florian Weimer wrote:
>> > > * Christian Brauner:
>> > >
>> > > > /* zombies */
>> >
* Christian Brauner:
> On Thu, Dec 06, 2018 at 01:30:19PM +0100, Florian Weimer wrote:
>> * Christian Brauner:
>>
>> > /* zombies */
>> > Zombies can be signaled just as any other process. No special error will be
>> > reported since a zombie state
* Christian Brauner:
> On Thu, Dec 06, 2018 at 01:30:19PM +0100, Florian Weimer wrote:
>> * Christian Brauner:
>>
>> > /* zombies */
>> > Zombies can be signaled just as any other process. No special error will be
>> > reported since a zombie state
* Jürg Billeter:
> On Thu, 2018-12-06 at 13:30 +0100, Florian Weimer wrote:
>> * Christian Brauner:
>>
>> > /* zombies */
>> > Zombies can be signaled just as any other process. No special error will be
>> > reported since a zombie state is an unreliabl
* Jürg Billeter:
> On Thu, 2018-12-06 at 13:30 +0100, Florian Weimer wrote:
>> * Christian Brauner:
>>
>> > /* zombies */
>> > Zombies can be signaled just as any other process. No special error will be
>> > reported since a zombie state is an unreliabl
* Christian Brauner:
> /* zombies */
> Zombies can be signaled just as any other process. No special error will be
> reported since a zombie state is an unreliable state (cf. [3]).
I still disagree with this analysis. If I know that the target process
is still alive, and it is not, this is a
* Christian Brauner:
> /* zombies */
> Zombies can be signaled just as any other process. No special error will be
> reported since a zombie state is an unreliable state (cf. [3]).
I still disagree with this analysis. If I know that the target process
is still alive, and it is not, this is a
* Mathieu Desnoyers:
> diff --git a/sysdeps/unix/sysv/linux/riscv/rv64/libpthread.abilist
> b/sysdeps/unix/sysv/linux/riscv/rv64/libpthread.abilist
> index c370fda73d..9da78d59d2 100644
> --- a/sysdeps/unix/sysv/linux/riscv/rv64/libpthread.abilist
> +++
* Mathieu Desnoyers:
> diff --git a/sysdeps/unix/sysv/linux/riscv/rv64/libpthread.abilist
> b/sysdeps/unix/sysv/linux/riscv/rv64/libpthread.abilist
> index c370fda73d..9da78d59d2 100644
> --- a/sysdeps/unix/sysv/linux/riscv/rv64/libpthread.abilist
> +++
* Christian Brauner:
> On Mon, Dec 03, 2018 at 05:57:51PM +0100, Florian Weimer wrote:
>> * Christian Brauner:
>>
>> > Ok, I finally have access to source code again. Scratch what I said above!
>> > I looked at the code and tested it. If the process has exited
* Christian Brauner:
> On Mon, Dec 03, 2018 at 05:57:51PM +0100, Florian Weimer wrote:
>> * Christian Brauner:
>>
>> > Ok, I finally have access to source code again. Scratch what I said above!
>> > I looked at the code and tested it. If the process has exited
* Christian Brauner:
> Ok, I finally have access to source code again. Scratch what I said above!
> I looked at the code and tested it. If the process has exited but not
> yet waited upon aka is a zombie procfd_send_signal() will return 0. This
> is identical to kill(2) behavior. It should've
* Christian Brauner:
> Ok, I finally have access to source code again. Scratch what I said above!
> I looked at the code and tested it. If the process has exited but not
> yet waited upon aka is a zombie procfd_send_signal() will return 0. This
> is identical to kill(2) behavior. It should've
* Jürg Billeter:
> On Fri, 2018-11-30 at 14:40 +0100, Florian Weimer wrote:
>> * Jürg Billeter:
>>
>> > This introduces a new thread group flag that can be set by calling
>> >
>> > prctl(PR_SET_KILL_DESCENDANTS_ON_EXIT, 1, 0, 0, 0)
>> >
* Jürg Billeter:
> On Fri, 2018-11-30 at 14:40 +0100, Florian Weimer wrote:
>> * Jürg Billeter:
>>
>> > This introduces a new thread group flag that can be set by calling
>> >
>> > prctl(PR_SET_KILL_DESCENDANTS_ON_EXIT, 1, 0, 0, 0)
>> >
* Jürg Billeter:
> This introduces a new thread group flag that can be set by calling
>
> prctl(PR_SET_KILL_DESCENDANTS_ON_EXIT, 1, 0, 0, 0)
>
> When a thread group exits with this flag set, it will send SIGKILL to
> all descendant processes. This can be used to prevent stray child
>
* Jürg Billeter:
> This introduces a new thread group flag that can be set by calling
>
> prctl(PR_SET_KILL_DESCENDANTS_ON_EXIT, 1, 0, 0, 0)
>
> When a thread group exits with this flag set, it will send SIGKILL to
> all descendant processes. This can be used to prevent stray child
>
Disclaimer: I'm looking at this patch because Christian requested it.
I'm not a kernel developer.
* Christian Brauner:
> diff --git a/arch/x86/entry/syscalls/syscall_32.tbl
> b/arch/x86/entry/syscalls/syscall_32.tbl
> index 3cf7b533b3d1..3f27ffd8ae87 100644
> ---
Disclaimer: I'm looking at this patch because Christian requested it.
I'm not a kernel developer.
* Christian Brauner:
> diff --git a/arch/x86/entry/syscalls/syscall_32.tbl
> b/arch/x86/entry/syscalls/syscall_32.tbl
> index 3cf7b533b3d1..3f27ffd8ae87 100644
> ---
* Christian Brauner:
> +.\" Copyright (C) 2018 Christian Brauner
The text seems to be largely derived from rt_sigqueueinfo, so I'm not
sure if this appropriate here.
> +the null signal (0) can be used to check if a process with a given
> +PID exists.
What does this mean if hte process is
* Christian Brauner:
> +.\" Copyright (C) 2018 Christian Brauner
The text seems to be largely derived from rt_sigqueueinfo, so I'm not
sure if this appropriate here.
> +the null signal (0) can be used to check if a process with a given
> +PID exists.
What does this mean if hte process is
* Mathieu Desnoyers:
> So let's make __rseq_abi and __rseq_refcount strong symbols then ?
Yes, please. (But I'm still not sure we need the reference counter.)
Thanks,
Florian
* Mathieu Desnoyers:
> So let's make __rseq_abi and __rseq_refcount strong symbols then ?
Yes, please. (But I'm still not sure we need the reference counter.)
Thanks,
Florian
* Mathieu Desnoyers:
> Using a "weak" symbol in early adopter libraries is important, so they
> can be loaded together into the same process without causing loader
> errors due to many definitions of the same strong symbol.
This is not how ELF dynamic linking works. If the symbol name is the
* Mathieu Desnoyers:
> Using a "weak" symbol in early adopter libraries is important, so they
> can be loaded together into the same process without causing loader
> errors due to many definitions of the same strong symbol.
This is not how ELF dynamic linking works. If the symbol name is the
* Rich Felker:
> On Fri, Nov 23, 2018 at 06:39:04PM +0100, Florian Weimer wrote:
>> * Rich Felker:
>>
>> > On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
>> >> There has been presumptions about signals being blocked when the thread
>
* Rich Felker:
> On Fri, Nov 23, 2018 at 06:39:04PM +0100, Florian Weimer wrote:
>> * Rich Felker:
>>
>> > On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
>> >> There has been presumptions about signals being blocked when the thread
>
* Rich Felker:
> On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
>> There has been presumptions about signals being blocked when the thread
>> exits throughout this email thread. Out of curiosity, what code is
>> responsible for disabling signals in this situation ? Related to
* Rich Felker:
> On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
>> There has been presumptions about signals being blocked when the thread
>> exits throughout this email thread. Out of curiosity, what code is
>> responsible for disabling signals in this situation ? Related to
* Daniel Colascione:
> On Mon, Nov 12, 2018 at 12:11 AM, Florian Weimer wrote:
>> * Daniel Colascione:
>>
>>> If the kernel provides a system call, libc should provide a C wrapper
>>> for it, even if in the opinion of the libc maintainers, that syst
* Daniel Colascione:
> On Mon, Nov 12, 2018 at 12:11 AM, Florian Weimer wrote:
>> * Daniel Colascione:
>>
>>> If the kernel provides a system call, libc should provide a C wrapper
>>> for it, even if in the opinion of the libc maintainers, that syst
* Mathieu Desnoyers:
I don't think you need unregistering if the memory is initial-exec TLS
memory. Initial-exec TLS memory is tied directly to the TCB and cannot
be freed while the thread is running, so it should be safe to put the
rseq area there even if glibc knows nothing
* Mathieu Desnoyers:
I don't think you need unregistering if the memory is initial-exec TLS
memory. Initial-exec TLS memory is tied directly to the TCB and cannot
be freed while the thread is running, so it should be safe to put the
rseq area there even if glibc knows nothing
* Rich Felker:
>> I'm not entirely sure because the glibc terminology is confusing, but I
>> think it places intial-exec TLS into the static TLS area (so that it has
>> a fixed offset from the TCB). The static TLS area is placed on the
>> user-supplied stack.
>
> This is an implementation detail
* Rich Felker:
>> I'm not entirely sure because the glibc terminology is confusing, but I
>> think it places intial-exec TLS into the static TLS area (so that it has
>> a fixed offset from the TCB). The static TLS area is placed on the
>> user-supplied stack.
>
> This is an implementation detail
* Mathieu Desnoyers:
> - On Nov 22, 2018, at 11:28 AM, Florian Weimer fwei...@redhat.com wrote:
>
>> * Mathieu Desnoyers:
>>
>>> Here is one scenario: we have 2 early adopter libraries using rseq which
>>> are deployed in an environment with an older gl
* Mathieu Desnoyers:
> - On Nov 22, 2018, at 11:28 AM, Florian Weimer fwei...@redhat.com wrote:
>
>> * Mathieu Desnoyers:
>>
>>> Here is one scenario: we have 2 early adopter libraries using rseq which
>>> are deployed in an environment with an older gl
* Mathieu Desnoyers:
> Here is one scenario: we have 2 early adopter libraries using rseq which
> are deployed in an environment with an older glibc (which does not
> support rseq).
>
> Of course, none of those libraries can be dlclose'd unless they somehow
> track all registered threads.
Well,
* Mathieu Desnoyers:
> Here is one scenario: we have 2 early adopter libraries using rseq which
> are deployed in an environment with an older glibc (which does not
> support rseq).
>
> Of course, none of those libraries can be dlclose'd unless they somehow
> track all registered threads.
Well,
* Rich Felker:
> On Thu, Nov 22, 2018 at 04:11:45PM +0100, Florian Weimer wrote:
>> * Mathieu Desnoyers:
>>
>> > Thoughts ?
>> >
>> > /* Unregister rseq TLS from kernel. */
>> > if (has_rseq && __rseq_unregister_current_thre
* Rich Felker:
> On Thu, Nov 22, 2018 at 04:11:45PM +0100, Florian Weimer wrote:
>> * Mathieu Desnoyers:
>>
>> > Thoughts ?
>> >
>> > /* Unregister rseq TLS from kernel. */
>> > if (has_rseq && __rseq_unregister_current_thre
* Mathieu Desnoyers:
> Thoughts ?
>
> /* Unregister rseq TLS from kernel. */
> if (has_rseq && __rseq_unregister_current_thread ())
> abort();
>
> advise_stack_range (pd->stackblock, pd->stackblock_size, (uintptr_t) pd,
> pd->guardsize);
>
> /* If the thread is
* Mathieu Desnoyers:
> Thoughts ?
>
> /* Unregister rseq TLS from kernel. */
> if (has_rseq && __rseq_unregister_current_thread ())
> abort();
>
> advise_stack_range (pd->stackblock, pd->stackblock_size, (uintptr_t) pd,
> pd->guardsize);
>
> /* If the thread is
* Andy Lutomirski:
> 5. Adjust the scripts so that we only have to wire up new syscalls
> once. They'll have a nr above 1024, and they'll have the same nr on
> all x86 variants.
Is there a sufficiently sized gap on all other architectures as well?
The restriction to the x86 variants seems
* Andy Lutomirski:
> 5. Adjust the scripts so that we only have to wire up new syscalls
> once. They'll have a nr above 1024, and they'll have the same nr on
> all x86 variants.
Is there a sufficiently sized gap on all other architectures as well?
The restriction to the x86 variants seems
* Andy Lutomirski:
> Thread cancellation is a big mess, and we only really need to support
> it because on legacy code. The whole mechanism should IMO be
> considered extremely deprecated.
The part regarding legacy code is not true: people write new code using
it all the time. It's true that
* Andy Lutomirski:
> Thread cancellation is a big mess, and we only really need to support
> it because on legacy code. The whole mechanism should IMO be
> considered extremely deprecated.
The part regarding legacy code is not true: people write new code using
it all the time. It's true that
* Adam Borowski:
> On Sun, Nov 11, 2018 at 12:46:35PM +0100, Florian Weimer wrote:
>> A lot of multi-threaded applications assume that most high-level
>> functionality remains usable even after fork in a multi-threaded
>> process.
>
> How would this be even possible
* Adam Borowski:
> On Sun, Nov 11, 2018 at 12:46:35PM +0100, Florian Weimer wrote:
>> A lot of multi-threaded applications assume that most high-level
>> functionality remains usable even after fork in a multi-threaded
>> process.
>
> How would this be even possible
* Dave Martin:
> Fair points, though this is rather what I meant by "sane essentials".
> Because there are strict limits on what can be done in the vDSO, it may
> be more bloat-resistant and more conservatively maintained.
>
> This might provide a way to push some dumb compatibility kludge code
>
* Dave Martin:
> Fair points, though this is rather what I meant by "sane essentials".
> Because there are strict limits on what can be done in the vDSO, it may
> be more bloat-resistant and more conservatively maintained.
>
> This might provide a way to push some dumb compatibility kludge code
>
* Yury Norov:
> diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
> index 53a22e8e0408..dbf58bbf5bad 100644
> --- a/include/uapi/linux/fs.h
> +++ b/include/uapi/linux/fs.h
Could you move it to a dedicated header? Or add
a comment that the header is only for rename flags?
Then we
* Yury Norov:
> diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
> index 53a22e8e0408..dbf58bbf5bad 100644
> --- a/include/uapi/linux/fs.h
> +++ b/include/uapi/linux/fs.h
Could you move it to a dedicated header? Or add
a comment that the header is only for rename flags?
Then we
* Daniel Colascione:
> What about off_t differences? Again, it doesn't matter. From the
> *kernel's* point of view, there's one width of offset parameter per
> system call per architecture. The library I'm proposing would expose
> this parameter literally.
Does this mean the application author
* Daniel Colascione:
> What about off_t differences? Again, it doesn't matter. From the
> *kernel's* point of view, there's one width of offset parameter per
> system call per architecture. The library I'm proposing would expose
> this parameter literally.
Does this mean the application author
* Willy Tarreau:
>> > What we'd really need would be to have the libc
>> > interface as part of the operating system itself. I'm perfectly fine
>> > with glibc providing all the "high-level" stuff like strcpy(), FILE*
>> > operations etc, and all this probably is mostly system-independent.
>>
>>
* Willy Tarreau:
>> > What we'd really need would be to have the libc
>> > interface as part of the operating system itself. I'm perfectly fine
>> > with glibc providing all the "high-level" stuff like strcpy(), FILE*
>> > operations etc, and all this probably is mostly system-independent.
>>
>>
* Daniel Colascione:
> If the kernel provides a system call, libc should provide a C wrapper
> for it, even if in the opinion of the libc maintainers, that system
> call is flawed.
It's not that simple, I think. What about bdflush? socketcall?
getxpid? osf_gettimeofday? set_robust_list?
* Daniel Colascione:
> If the kernel provides a system call, libc should provide a C wrapper
> for it, even if in the opinion of the libc maintainers, that system
> call is flawed.
It's not that simple, I think. What about bdflush? socketcall?
getxpid? osf_gettimeofday? set_robust_list?
* Willy Tarreau:
> On Sun, Nov 11, 2018 at 11:30:25AM +0100, Florian Weimer wrote:
>> * Willy Tarreau:
>>
>> > On Sun, Nov 11, 2018 at 07:55:30AM +0100, Michael Kerrisk (man-pages)
>> > wrote:
>> >> [1] https://sourceware.org/bugzilla/show_bug.cg
* Willy Tarreau:
> On Sun, Nov 11, 2018 at 11:30:25AM +0100, Florian Weimer wrote:
>> * Willy Tarreau:
>>
>> > On Sun, Nov 11, 2018 at 07:55:30AM +0100, Michael Kerrisk (man-pages)
>> > wrote:
>> >> [1] https://sourceware.org/bugzilla/show_bug.cg
* Willy Tarreau:
> I think the issue is a bit more complex :
> - linux doesn't support a single libc
> - glibc doesn't support a single OS
>
> In practice we all know (believe?) that both statements above are
> true but in practice 99% of the time there's a 1:1 relation between
> these two
* Willy Tarreau:
> I think the issue is a bit more complex :
> - linux doesn't support a single libc
> - glibc doesn't support a single OS
>
> In practice we all know (believe?) that both statements above are
> true but in practice 99% of the time there's a 1:1 relation between
> these two
* Michael Kerrisk:
> [adding in glibc folk for comment]
>
> On 11/10/18 7:52 PM, Daniel Colascione wrote:
>> Now that glibc is basically not adding any new system call wrappers,
>> how about publishing an "official" system call glue library as part of
>> the kernel distribution, along with the
* Michael Kerrisk:
> [adding in glibc folk for comment]
>
> On 11/10/18 7:52 PM, Daniel Colascione wrote:
>> Now that glibc is basically not adding any new system call wrappers,
>> how about publishing an "official" system call glue library as part of
>> the kernel distribution, along with the
* Michael Kerrisk:
> I'm not sure I'd view the glibc position quite so harshly (although
> it is disappointing to me that bug 6399 remains open). I think they
> are simply short of people to work on this task. There was a lengthy
> period where no syscall wrappers were being added (pretty much
* Michael Kerrisk:
> I'm not sure I'd view the glibc position quite so harshly (although
> it is disappointing to me that bug 6399 remains open). I think they
> are simply short of people to work on this task. There was a lengthy
> period where no syscall wrappers were being added (pretty much
* Daniel Colascione:
> On Sun, Nov 11, 2018 at 12:17 AM, Willy Tarreau wrote:
>>
>> On Sun, Nov 11, 2018 at 07:55:30AM +0100, Michael Kerrisk (man-pages) wrote:
>> > [1] https://sourceware.org/
>>
>>
>> Bah, after all, this
>>
>> wipes quite a bit of the shame I feel every time I do something to
* Daniel Colascione:
> On Sun, Nov 11, 2018 at 12:17 AM, Willy Tarreau wrote:
>>
>> On Sun, Nov 11, 2018 at 07:55:30AM +0100, Michael Kerrisk (man-pages) wrote:
>> > [1] https://sourceware.org/
>>
>>
>> Bah, after all, this
>>
>> wipes quite a bit of the shame I feel every time I do something to
* Willy Tarreau:
> On Sun, Nov 11, 2018 at 07:55:30AM +0100, Michael Kerrisk (man-pages) wrote:
>> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=6399 is a
>> longstanding example.
>
> This one was a sad read and shows that applications will continue to
> suffer from glibc's
* Willy Tarreau:
> On Sun, Nov 11, 2018 at 07:55:30AM +0100, Michael Kerrisk (man-pages) wrote:
>> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=6399 is a
>> longstanding example.
>
> This one was a sad read and shows that applications will continue to
> suffer from glibc's
* Mathieu Desnoyers:
> Basically, the use-cases targeted are those where some cores on the
> system support a larger instruction set than others. So for instance,
> some cores could use a faster atomic add instruction than others,
> which should rely on a slower fallback. This is also the same
* Mathieu Desnoyers:
> Basically, the use-cases targeted are those where some cores on the
> system support a larger instruction set than others. So for instance,
> some cores could use a faster atomic add instruction than others,
> which should rely on a slower fallback. This is also the same
* Andy Lutomirski:
> The basic idea would be to allow libc, or maybe even any library, to
> register a handler that gets a chance to act on an exception caused by
> a user instruction before a signal is delivered. As a straw-man
> example for how this could work, there could be a new syscall:
>
* Andy Lutomirski:
> The basic idea would be to allow libc, or maybe even any library, to
> register a handler that gets a chance to act on an exception caused by
> a user instruction before a signal is delivered. As a straw-man
> example for how this could work, there could be a new syscall:
>
* Amir Goldstein:
> On Thu, Oct 18, 2018 at 4:11 PM Miklos Szeredi wrote:
>>
>> Constants of the *_ALL type can be actively harmful due to the fact that
>> developers will usually fail to consider the possible effects of future
>> changes to the definition.
>>
>> Remove STATX_ALL from the uapi,
* Amir Goldstein:
> On Thu, Oct 18, 2018 at 4:11 PM Miklos Szeredi wrote:
>>
>> Constants of the *_ALL type can be actively harmful due to the fact that
>> developers will usually fail to consider the possible effects of future
>> changes to the definition.
>>
>> Remove STATX_ALL from the uapi,
* Miklos Szeredi:
> #define STATX__RESERVED 0x8000U /* Reserved for future
> struct statx expansion */
What about this? Isn't it similar to STATX_ALL in the sense that we
don't know yet what it will mean?
* Miklos Szeredi:
> #define STATX__RESERVED 0x8000U /* Reserved for future
> struct statx expansion */
What about this? Isn't it similar to STATX_ALL in the sense that we
don't know yet what it will mean?
* Jan Kara:
> On Thu 18-10-18 01:15:13, Amir Goldstein wrote:
>> FYI, I identified a similar anti-pattern in fanotify UAPI when I wanted to
>> add new flags and did not want to change the UAPI _ALL_ constants.
>> This is how we plan to solve it:
>>
* Jan Kara:
> On Thu 18-10-18 01:15:13, Amir Goldstein wrote:
>> FYI, I identified a similar anti-pattern in fanotify UAPI when I wanted to
>> add new flags and did not want to change the UAPI _ALL_ constants.
>> This is how we plan to solve it:
>>
* Miklos Szeredi:
> On Thu, Oct 18, 2018 at 12:22 AM, Florian Weimer wrote:
>> * Andreas Dilger:
>>
>>>> So what's the point exactly?
>>>
>>> Ah, I see your point... STATX_ALL seems to be mostly useful for the kernel
>>> to mask off flags
* Miklos Szeredi:
> On Thu, Oct 18, 2018 at 12:22 AM, Florian Weimer wrote:
>> * Andreas Dilger:
>>
>>>> So what's the point exactly?
>>>
>>> Ah, I see your point... STATX_ALL seems to be mostly useful for the kernel
>>> to mask off flags
* Andreas Dilger:
>> So what's the point exactly?
>
> Ah, I see your point... STATX_ALL seems to be mostly useful for the kernel
> to mask off flags that it doesn't currently understand. It doesn't make
> much sense for applications to specify STATX_ALL, since they don't have any
> way to know
* Andreas Dilger:
>> So what's the point exactly?
>
> Ah, I see your point... STATX_ALL seems to be mostly useful for the kernel
> to mask off flags that it doesn't currently understand. It doesn't make
> much sense for applications to specify STATX_ALL, since they don't have any
> way to know
* Aleksa Sarai:
> On 2018-10-01, Andy Lutomirski wrote:
>> >>> Currently most container runtimes try to do this resolution in
>> >>> userspace[1], causing many potential race conditions. In addition, the
>> >>> "obvious" alternative (actually performing a {ch,pivot_}root(2))
>> >>> requires a
* Aleksa Sarai:
> On 2018-10-01, Andy Lutomirski wrote:
>> >>> Currently most container runtimes try to do this resolution in
>> >>> userspace[1], causing many potential race conditions. In addition, the
>> >>> "obvious" alternative (actually performing a {ch,pivot_}root(2))
>> >>> requires a
* Rich Felker:
>> I believe the expected userspace interface is that you probe support
>> with set_robust_list first, and then start using the relevant futex
>> interfaces only if that call succeeded.
>
> In order for it to work, set_robust_list needs to succeed for all
> threads, present and
* Rich Felker:
>> I believe the expected userspace interface is that you probe support
>> with set_robust_list first, and then start using the relevant futex
>> interfaces only if that call succeeded.
>
> In order for it to work, set_robust_list needs to succeed for all
> threads, present and
* Rich Felker:
> I just spent a number of hours helping someone track down a bug that
> looks like it's some kind of futex_cmpxchg_enabled detection error on
> powerpc64 (still not sure of the root cause; set_robust_list producing
> -ENOSYS), and a while back I hit the same problem on sh2 due to
201 - 300 of 698 matches
Mail list logo
