* Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation
From: Rich Felker @ 2018-11-23 14:28 UTC (permalink / raw)
To: Florian Weimer
Cc: Mathieu Desnoyers, carlos, Joseph Myers, Szabolcs Nagy,
libc-alpha, Thomas Gleixner, Ben Maurer, Peter Zijlstra,
Paul E. McKenney, Boqun Feng, Will Deacon, Dave Watson,
Paul Turner, linux-kernel, linux-api
In-Reply-To: <871s7cvt1l.fsf@oldenburg.str.redhat.com>
On Fri, Nov 23, 2018 at 02:10:14PM +0100, Florian Weimer wrote:
> * 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 that should not leak to applications,
> > and I believe it's still considered a bug, in that, with large static
> > TLS, it could overflow or leave unusably little space left on an
> > otherwise-plenty-large application-provided stack.
>
> Sure, but that does not matter in this context because right now, there
> is no fix for this bug, and when we fix it, we can take backwards
> compatibility into account.
>
> Any library that ends up using rseq will need to coordinate with the
> toolchain. I think that's unavoidable given the kernel interface.
Right. I don't agree with this. What I'm saying is that this behavior
(putting static TLS in the caller-provided stack) should not be
documented as a behavior applications can rely on or accounted as a
solution to the rseq problem, since doing so would preclude fixing the
"application doesn't have as much stack as it requested" bug.
> >> > One issue here is that early adopter libraries cannot always use
> >> > the IE model. I tried using it for other TLS variables in lttng-ust, and
> >> > it ended up hanging our CI tests when tracing a sample application with
> >> > lttng-ust under a Java virtual machine: being dlopen'd in a process that
> >> > possibly already exhausts the number of available backup TLS IE entries
> >> > seems to have odd effects. This is why I'm worried about using the IE model
> >> > within lttng-ust.
> >>
> >> You can work around this by preloading the library. I'm not sure if
> >> this is a compelling reason not to use initial-exec TLS memory.
> >
> > Use of IE model from a .so file (except possibly libc.so or something
> > else that inherently needs to be present at program startup for other
> > reasons) should be a considered a bug and unsupported usage.
> > Encouraging libraries to perpetuate this behavior is going backwards
> > on progress that's being made to end it.
>
> Why? Just because glibc's TCB allocation strategy is problematic?
> We can fix that, even with dlopen.
>
> If you are only concerned about the interactions with dlopen, then why
> do you think initial-exec TLS is the problem, and not dlopen?
The initial-exec model, *by design*, only works for TLS objects that
exist at initial execution time. That's why it's called initial-exec.
This is not an implementation flaw/limitation in glibc but
fundamental to the fact that you don't have an unlimited-size (or
practically unlimited) virtual address space range for each thread.
The global-dynamic model is the one that admits dynamic creation of
new TLS objects at runtime (thus the name).
> >> > The per-thread reference counter is a way to avoid issues that arise from
> >> > lack of destructor ordering. Is it an acceptable approach for you, or
> >> > you have something else in mind ?
> >>
> >> Only for the involved libraries. It will not help if other TLS
> >> destructors run and use these libraries.
> >
> > Presumably they should have registered their need for rseq too,
> > thereby incrementing the reference count. I'm not sure this is a good
> > idea, but I think I understand it now.
>
> They may have to increase the reference count from 0 to 1, though, so
> they have to re-register the rseq area. This tends to get rather messy.
>
> I still I think implicit destruction of the rseq area is preferable over
> this complexity.
Absolutely. As long as it's in libc, implicit destruction will happen.
Actually I think the glibc code shound unconditionally unregister the
rseq address at exit (after blocking signals, so no application code
can run) in case a third-party rseq library was linked and failed to
do so before thread exit (e.g. due to mismatched ref counts) rather
than respecting the reference count, since it knows it's the last
user. This would make potentially-buggy code safer.
Rich
^ permalink raw reply
* Re: [RFC PATCH 2/3] mm, thp, proc: report THP eligibility for each vma
From: Vlastimil Babka @ 2018-11-23 15:07 UTC (permalink / raw)
To: Michal Hocko, linux-api
Cc: Andrew Morton, Alexey Dobriyan, linux-mm, LKML, Michal Hocko
In-Reply-To: <20181120103515.25280-3-mhocko@kernel.org>
On 11/20/18 11:35 AM, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
>
> Userspace falls short when trying to find out whether a specific memory
> range is eligible for THP. There are usecases that would like to know
> that
> http://lkml.kernel.org/r/alpine.DEB.2.21.1809251248450.50347@chino.kir.corp.google.com
> : This is used to identify heap mappings that should be able to fault thp
> : but do not, and they normally point to a low-on-memory or fragmentation
> : issue.
>
> The only way to deduce this now is to query for hg resp. nh flags and
> confronting the state with the global setting. Except that there is
> also PR_SET_THP_DISABLE that might change the picture. So the final
> logic is not trivial. Moreover the eligibility of the vma depends on
> the type of VMA as well. In the past we have supported only anononymous
> memory VMAs but things have changed and shmem based vmas are supported
> as well these days and the query logic gets even more complicated
> because the eligibility depends on the mount option and another global
> configuration knob.
>
> Simplify the current state and report the THP eligibility in
> /proc/<pid>/smaps for each existing vma. Reuse transparent_hugepage_enabled
> for this purpose. The original implementation of this function assumes
> that the caller knows that the vma itself is supported for THP so make
> the core checks into __transparent_hugepage_enabled and use it for
> existing callers. __show_smap just use the new transparent_hugepage_enabled
> which also checks the vma support status (please note that this one has
> to be out of line due to include dependency issues).
>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
Not thrilled by this, but kernel is always better suited to report this,
than userspace piecing it together from multiple sources, relying on
possibly outdated knowledge of kernel implementation details...
Acked-by: Vlastimil Babka <vbabka@suse.cz>
A nitpick:
> ---
> Documentation/filesystems/proc.txt | 3 +++
> fs/proc/task_mmu.c | 2 ++
> include/linux/huge_mm.h | 13 ++++++++++++-
> mm/huge_memory.c | 12 +++++++++++-
> mm/memory.c | 4 ++--
> 5 files changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
> index b1fda309f067..06562bab509a 100644
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -425,6 +425,7 @@ SwapPss: 0 kB
> KernelPageSize: 4 kB
> MMUPageSize: 4 kB
> Locked: 0 kB
> +THPeligible: 0
I would use THP_Eligible. There are already fields with underscore in smaps.
^ permalink raw reply
* Re: [RFC PATCH 2/3] mm, thp, proc: report THP eligibility for each vma
From: Michal Hocko @ 2018-11-23 15:21 UTC (permalink / raw)
To: Vlastimil Babka; +Cc: linux-api, Andrew Morton, Alexey Dobriyan, linux-mm, LKML
In-Reply-To: <73b55240-d36c-cf97-d7fd-85e2ae1e9309@suse.cz>
On Fri 23-11-18 16:07:06, Vlastimil Babka wrote:
> On 11/20/18 11:35 AM, Michal Hocko wrote:
> > From: Michal Hocko <mhocko@suse.com>
> >
> > Userspace falls short when trying to find out whether a specific memory
> > range is eligible for THP. There are usecases that would like to know
> > that
> > http://lkml.kernel.org/r/alpine.DEB.2.21.1809251248450.50347@chino.kir.corp.google.com
> > : This is used to identify heap mappings that should be able to fault thp
> > : but do not, and they normally point to a low-on-memory or fragmentation
> > : issue.
> >
> > The only way to deduce this now is to query for hg resp. nh flags and
> > confronting the state with the global setting. Except that there is
> > also PR_SET_THP_DISABLE that might change the picture. So the final
> > logic is not trivial. Moreover the eligibility of the vma depends on
> > the type of VMA as well. In the past we have supported only anononymous
> > memory VMAs but things have changed and shmem based vmas are supported
> > as well these days and the query logic gets even more complicated
> > because the eligibility depends on the mount option and another global
> > configuration knob.
> >
> > Simplify the current state and report the THP eligibility in
> > /proc/<pid>/smaps for each existing vma. Reuse transparent_hugepage_enabled
> > for this purpose. The original implementation of this function assumes
> > that the caller knows that the vma itself is supported for THP so make
> > the core checks into __transparent_hugepage_enabled and use it for
> > existing callers. __show_smap just use the new transparent_hugepage_enabled
> > which also checks the vma support status (please note that this one has
> > to be out of line due to include dependency issues).
> >
> > Signed-off-by: Michal Hocko <mhocko@suse.com>
>
> Not thrilled by this,
Any specific concern?
> but kernel is always better suited to report this,
> than userspace piecing it together from multiple sources, relying on
> possibly outdated knowledge of kernel implementation details...
yep.
> Acked-by: Vlastimil Babka <vbabka@suse.cz>
Thanks!
> A nitpick:
>
> > ---
> > Documentation/filesystems/proc.txt | 3 +++
> > fs/proc/task_mmu.c | 2 ++
> > include/linux/huge_mm.h | 13 ++++++++++++-
> > mm/huge_memory.c | 12 +++++++++++-
> > mm/memory.c | 4 ++--
> > 5 files changed, 30 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
> > index b1fda309f067..06562bab509a 100644
> > --- a/Documentation/filesystems/proc.txt
> > +++ b/Documentation/filesystems/proc.txt
> > @@ -425,6 +425,7 @@ SwapPss: 0 kB
> > KernelPageSize: 4 kB
> > MMUPageSize: 4 kB
> > Locked: 0 kB
> > +THPeligible: 0
>
> I would use THP_Eligible. There are already fields with underscore in smaps.
I do not feel strongly. I will wait for more comments and see whether
there is some consensus.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: Official Linux system wrapper library?
From: Szabolcs Nagy @ 2018-11-23 15:23 UTC (permalink / raw)
To: David Newall, Florian Weimer, Daniel Colascione
Cc: nd, Michael Kerrisk (man-pages), linux-kernel, Joel Fernandes,
Linux API, Willy Tarreau, Vlastimil Babka, Carlos O'Donell,
libc-alpha@sourceware.org
In-Reply-To: <a50dbc52-b5e8-6684-508d-b96ad8d70d4f@davidnewall.com>
On 23/11/18 14:11, David Newall wrote:
> On 24/11/18 12:04 am, Florian Weimer wrote:
>> But socketcall does not exist on all architectures. Neither does
>> getpid, it's called getxpid on some architectures.
>> ...
>> I think it would be a poor approach to expose application developers to
>> these portability issues. We need to abstract over these differences at
>> a certain layer, and applications are too late.
>
> Interesting. I think the opposite. I think exposing the OS's interfaces is exactly what a c-library should do. It might also provide
> alternative interfaces that work consistently across different platforms, but in addition to, not instead of the OS interface.
you don't understand the point of the c language if you think so.
^ permalink raw reply
* Re: [RFC PATCH 2/3] mm, thp, proc: report THP eligibility for each vma
From: Vlastimil Babka @ 2018-11-23 15:24 UTC (permalink / raw)
To: Michal Hocko; +Cc: linux-api, Andrew Morton, Alexey Dobriyan, linux-mm, LKML
In-Reply-To: <20181123152136.GA5827@dhcp22.suse.cz>
On 11/23/18 4:21 PM, Michal Hocko wrote:
> On Fri 23-11-18 16:07:06, Vlastimil Babka wrote:
>> On 11/20/18 11:35 AM, Michal Hocko wrote:
>>> From: Michal Hocko <mhocko@suse.com>
>>>
>>> Userspace falls short when trying to find out whether a specific memory
>>> range is eligible for THP. There are usecases that would like to know
>>> that
>>> http://lkml.kernel.org/r/alpine.DEB.2.21.1809251248450.50347@chino.kir.corp.google.com
>>> : This is used to identify heap mappings that should be able to fault thp
>>> : but do not, and they normally point to a low-on-memory or fragmentation
>>> : issue.
>>>
>>> The only way to deduce this now is to query for hg resp. nh flags and
>>> confronting the state with the global setting. Except that there is
>>> also PR_SET_THP_DISABLE that might change the picture. So the final
>>> logic is not trivial. Moreover the eligibility of the vma depends on
>>> the type of VMA as well. In the past we have supported only anononymous
>>> memory VMAs but things have changed and shmem based vmas are supported
>>> as well these days and the query logic gets even more complicated
>>> because the eligibility depends on the mount option and another global
>>> configuration knob.
>>>
>>> Simplify the current state and report the THP eligibility in
>>> /proc/<pid>/smaps for each existing vma. Reuse transparent_hugepage_enabled
>>> for this purpose. The original implementation of this function assumes
>>> that the caller knows that the vma itself is supported for THP so make
>>> the core checks into __transparent_hugepage_enabled and use it for
>>> existing callers. __show_smap just use the new transparent_hugepage_enabled
>>> which also checks the vma support status (please note that this one has
>>> to be out of line due to include dependency issues).
>>>
>>> Signed-off-by: Michal Hocko <mhocko@suse.com>
>>
>> Not thrilled by this,
>
> Any specific concern?
The kitchen sink that smaps slowly becomes, with associated overhead
(i.e. one of reasons there's now smaps_rollup). Would be much nicer if
userspace had some way to say which fields it's interested in. But I
have no good ideas for that right now :/
^ permalink raw reply
* Re: [RFC PATCH 3/3] mm, proc: report PR_SET_THP_DISABLE in proc
From: Vlastimil Babka @ 2018-11-23 15:49 UTC (permalink / raw)
To: Michal Hocko, linux-api
Cc: Andrew Morton, Alexey Dobriyan, linux-mm, LKML, Michal Hocko
In-Reply-To: <20181120103515.25280-4-mhocko@kernel.org>
On 11/20/18 11:35 AM, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
>
> David Rientjes has reported that 1860033237d4 ("mm: make
> PR_SET_THP_DISABLE immediately active") has changed the way how
> we report THPable VMAs to the userspace. Their monitoring tool is
> triggering false alarms on PR_SET_THP_DISABLE tasks because it considers
> an insufficient THP usage as a memory fragmentation resp. memory
> pressure issue.
>
> Before the said commit each newly created VMA inherited VM_NOHUGEPAGE
> flag and that got exposed to the userspace via /proc/<pid>/smaps file.
> This implementation had its downsides as explained in the commit message
> but it is true that the userspace doesn't have any means to query for
> the process wide THP enabled/disabled status.
>
> PR_SET_THP_DISABLE is a process wide flag so it makes a lot of sense
> to export in the process wide context rather than per-vma. Introduce
Agreed.
> a new field to /proc/<pid>/status which export this status. If
> PR_SET_THP_DISABLE is used then it reports false same as when the THP is
> not compiled in. It doesn't consider the global THP status because we
> already export that information via sysfs
>
> Fixes: 1860033237d4 ("mm: make PR_SET_THP_DISABLE immediately active")
> Signed-off-by: Michal Hocko <mhocko@suse.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
^ permalink raw reply
* Re: [PATCH v4 2/4] namei: O_BENEATH-style path resolution flags
From: Andy Lutomirski @ 2018-11-23 16:07 UTC (permalink / raw)
To: j
Cc: Aleksa Sarai, Al Viro, Jeff Layton, J. Bruce Fields,
Arnd Bergmann, David Howells, Eric W. Biederman,
Christian Brauner, Linux API, Andrew Lutomirski, Jann Horn,
David Drysdale, Aleksa Sarai, Linux Containers, Linux FS Devel,
LKML, linux-arch
In-Reply-To: <1ce83cdf6e3168350b69f98f08aaa202bbaa682d.camel@bitron.ch>
> On Nov 23, 2018, at 5:10 AM, Jürg Billeter <j@bitron.ch> wrote:
>
> Hi Aleksa,
>
>> On Tue, 2018-11-13 at 01:26 +1100, Aleksa Sarai wrote:
>> * O_BENEATH: Disallow "escapes" from the starting point of the
>> filesystem tree during resolution (you must stay "beneath" the
>> starting point at all times). Currently this is done by disallowing
>> ".." and absolute paths (either in the given path or found during
>> symlink resolution) entirely, as well as all "magic link" jumping.
>
> With open_tree(2) and OPEN_TREE_CLONE, will O_BENEATH still be
> necessary?
This discussion reminds me of something I’m uncomfortable with in the
current patches: currently, most of the O_ flags determine some
property of the returned opened file. The new O_ flags you're adding
don't -- instead, they affect the lookup of the file. So O_BENEATH
doesn't return a descriptor that can only be used to loop up files
beneath it -- it just controls whether open(2) succeeds or fails. It
might be nice for the naming of the flags to reflect this. I also
don't love that we have some magic AT_ flags that work with some
syscalls and some magic O_ flags that work with others.
In this regard, I liked the AT_ naming better. Although I don't love
adding AT_ flags because the restrict our ability to usefully use the
high bits of the fd in the future.
--Andy
^ permalink raw reply
* Re: [PATCH v4 2/4] namei: O_BENEATH-style path resolution flags
From: Aleksa Sarai @ 2018-11-23 16:48 UTC (permalink / raw)
To: Andy Lutomirski
Cc: j, Aleksa Sarai, Al Viro, Jeff Layton, J. Bruce Fields,
Arnd Bergmann, David Howells, Eric W. Biederman,
Christian Brauner, Linux API, Jann Horn, David Drysdale,
Linux Containers, Linux FS Devel, LKML, linux-arch
In-Reply-To: <CALCETrURCXjNMBR6DjujVc6HHHS=CbET81kHS+odur+Bm-z7Tg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3446 bytes --]
On 2018-11-23, Andy Lutomirski <luto@kernel.org> wrote:
> > On Nov 23, 2018, at 5:10 AM, Jürg Billeter <j@bitron.ch> wrote:
> >
> > Hi Aleksa,
> >
> >> On Tue, 2018-11-13 at 01:26 +1100, Aleksa Sarai wrote:
> >> * O_BENEATH: Disallow "escapes" from the starting point of the
> >> filesystem tree during resolution (you must stay "beneath" the
> >> starting point at all times). Currently this is done by disallowing
> >> ".." and absolute paths (either in the given path or found during
> >> symlink resolution) entirely, as well as all "magic link" jumping.
> >
> > With open_tree(2) and OPEN_TREE_CLONE, will O_BENEATH still be
> > necessary?
>
> This discussion reminds me of something I’m uncomfortable with in the
> current patches: currently, most of the O_ flags determine some
> property of the returned opened file. The new O_ flags you're adding
> don't -- instead, they affect the lookup of the file. So O_BENEATH
> doesn't return a descriptor that can only be used to loop up files
> beneath it -- it just controls whether open(2) succeeds or fails. It
> might be nice for the naming of the flags to reflect this.
I agree that there is something quite weird about having path resolution
flags in an *open* syscall. The main reason why it's linked to open is
because that's the only way to get O_PATH descriptors (which is what you
would use for most of the extended operations we need -- as well as
reading+writing to files which is what most users would do with this).
And I think O_PATH is another example of an open flag that is just odd
in how it changes the semantics of using open(2).
One of the ideas I pitched in an earlier mail was a hypothetical
resolveat(2) -- which would just be a new way of getting an O_PATH
descriptor. This way, we wouldn't be using up more O_* flag bits with
this feature and we'd be able to play with more radical semantic changes
in the future. I can outline these here if you like, but it's a bit of a
long discussion and I'd prefer not to derail things too much if
resolveat(2) is definitely out of the question.
> I also don't love that we have some magic AT_ flags that work with
> some syscalls and some magic O_ flags that work with others.
I also completely agree. I think that we should have a discussion about
the long-term plan of syscall flags because it's starting to get a
little bit crazy:
* Every "get an fd" syscall has its own brand of O_CLOEXEC. Thankfully,
many of them use the same value (except for memfd_create(2) and a few
other examples).
* AT_* was supposed to be generic across all *at(2) syscalls, but there
are several cases where this isn't really true anymore.
* renameat2(2) only supports RENAME_* flags.
* openat(2) supports only O_* flags.
* Most AT_* flags have O_* counterparts (or are even more of a mess
such as with {AT_SYMLINK_FOLLOW,AT_SYMLINK_NOFOLLOW,O_NOFOLLOW}).
* statx(2) added AT_STATX_* flags, making AT_* no longer generic.
(Also I just want to mention something I noticed while writing this
patch -- openat(2) violates one of the kernel "golden rules" -- that you
reject unknown flags. openat(2) will silently ignore unknown flag bits.
I'm sure there's a really good reason for this, but it's another flag
oddity that I felt fit here.)
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 2/4] namei: O_BENEATH-style path resolution flags
From: Aleksa Sarai @ 2018-11-23 16:52 UTC (permalink / raw)
To: Andy Lutomirski
Cc: j, Aleksa Sarai, Al Viro, Jeff Layton, J. Bruce Fields,
Arnd Bergmann, David Howells, Eric W. Biederman,
Christian Brauner, Linux API, Jann Horn, David Drysdale,
Linux Containers, Linux FS Devel, LKML, linux-arch
In-Reply-To: <20181123164819.skruu23wjwzf47f5@mikami>
[-- Attachment #1: Type: text/plain, Size: 2646 bytes --]
On 2018-11-24, Aleksa Sarai <asarai@suse.de> wrote:
> > >> On Tue, 2018-11-13 at 01:26 +1100, Aleksa Sarai wrote:
> > >> * O_BENEATH: Disallow "escapes" from the starting point of the
> > >> filesystem tree during resolution (you must stay "beneath" the
> > >> starting point at all times). Currently this is done by disallowing
> > >> ".." and absolute paths (either in the given path or found during
> > >> symlink resolution) entirely, as well as all "magic link" jumping.
> > >
> > > With open_tree(2) and OPEN_TREE_CLONE, will O_BENEATH still be
> > > necessary?
> >
> > This discussion reminds me of something I’m uncomfortable with in the
> > current patches: currently, most of the O_ flags determine some
> > property of the returned opened file. The new O_ flags you're adding
> > don't -- instead, they affect the lookup of the file. So O_BENEATH
> > doesn't return a descriptor that can only be used to loop up files
> > beneath it -- it just controls whether open(2) succeeds or fails. It
> > might be nice for the naming of the flags to reflect this.
>
> I agree that there is something quite weird about having path resolution
> flags in an *open* syscall. The main reason why it's linked to open is
> because that's the only way to get O_PATH descriptors (which is what you
> would use for most of the extended operations we need -- as well as
> reading+writing to files which is what most users would do with this).
>
> And I think O_PATH is another example of an open flag that is just odd
> in how it changes the semantics of using open(2).
>
> One of the ideas I pitched in an earlier mail was a hypothetical
> resolveat(2) -- which would just be a new way of getting an O_PATH
> descriptor. This way, we wouldn't be using up more O_* flag bits with
> this feature and we'd be able to play with more radical semantic changes
> in the future. I can outline these here if you like, but it's a bit of a
> long discussion and I'd prefer not to derail things too much if
> resolveat(2) is definitely out of the question.
Sorry, one thing I forgot to mention about returning descriptors that
can only look up files beneath it -- while I think this would be very
useful, I'd be worried about jumping into chroot(2) territory where now
you are giving userspace the opportunity to try to create nested
"beneathfds" and so on. I do think it would be quite useful and
interesting though, but I'm not entirely sure how doable it would be
with the current namei infrastructure.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 2/4] namei: O_BENEATH-style path resolution flags
From: Aleksa Sarai @ 2018-11-23 16:58 UTC (permalink / raw)
To: Jürg Billeter
Cc: Aleksa Sarai, Al Viro, Jeff Layton, J. Bruce Fields,
Arnd Bergmann, David Howells, Eric Biederman, Christian Brauner,
linux-api, Andy Lutomirski, Jann Horn, David Drysdale, containers,
linux-fsdevel, linux-kernel, linux-arch
In-Reply-To: <1ce83cdf6e3168350b69f98f08aaa202bbaa682d.camel@bitron.ch>
[-- Attachment #1: Type: text/plain, Size: 2559 bytes --]
On 2018-11-23, Jürg Billeter <j@bitron.ch> wrote:
> On Tue, 2018-11-13 at 01:26 +1100, Aleksa Sarai wrote:
> > * O_BENEATH: Disallow "escapes" from the starting point of the
> > filesystem tree during resolution (you must stay "beneath" the
> > starting point at all times). Currently this is done by disallowing
> > ".." and absolute paths (either in the given path or found during
> > symlink resolution) entirely, as well as all "magic link" jumping.
>
> With open_tree(2) and OPEN_TREE_CLONE, will O_BENEATH still be
> necessary? As I understand it, O_BENEATH could be replaced by a much
> simpler flag that only disallows absolute paths (incl. absolute
> symlinks). And it would have the benefit that you can actually pass the
> tree/directory fd to another process and escaping would not be possible
> even if that other process doesn't use O_BENEATH (after calling
> mount_setattr(2) to make sure it's locked down).
>
> This approach would also make it easy to restrict writes via a cloned
> tree/directory fd by marking it read-only via mount_setattr(2) (and
> locking down the read-only flag). This would again be especially useful
> when passing tree/directory fds across processes, or for voluntary
> self-lockdown within a process for robustness against security bugs.
>
> This wouldn't affect any of the other flags in this patch. And for full
> equivalence to O_BENEATH you'd have to use O_NOMAGICLINKS in addition
> to O_NOABSOLUTE, or whatever that new flag would be called.
>
> Or is OPEN_TREE_CLONE too expensive for this use case? Or is there
> anything else I'm missing?
OPEN_TREE_CLONE currently requires CAP_SYS_ADMIN in mnt_ns->user_ns,
which requires a fork and unshare -- or at least a vfork and some other
magic -- at which point we're back to just doing a pivot_root(2) for
most operations.
I think open_tree(2) -- which I really should sit down and play around
with -- would be an interesting way of doing O_BENEATH, but I think
you'd still need to have the same race protections we have in the
current O_BENEATH proposal to handle "..".
So really you'd be using open_tree(OPEN_TREE_CLONE) just so that you can
use the "path.mnt" setting code, which I'm not sure is the best way of
doing it (plus the other interesting ideas which you get with the other
mount API changes).
But I am quite hopeful for what cool things we'll be able to make using
the new mount API.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation
From: Mathieu Desnoyers @ 2018-11-23 17:05 UTC (permalink / raw)
To: Rich Felker
Cc: Florian Weimer, carlos, Joseph Myers, Szabolcs Nagy, libc-alpha,
Thomas Gleixner, Ben Maurer, Peter Zijlstra, Paul E. McKenney,
Boqun Feng, Will Deacon, Dave Watson, Paul Turner, linux-kernel,
linux-api
In-Reply-To: <20181123142843.GJ23599@brightrain.aerifal.cx>
----- On Nov 23, 2018, at 9:28 AM, Rich Felker dalias@libc.org wrote:
[...]
>
> Absolutely. As long as it's in libc, implicit destruction will happen.
> Actually I think the glibc code shound unconditionally unregister the
> rseq address at exit (after blocking signals, so no application code
> can run) in case a third-party rseq library was linked and failed to
> do so before thread exit (e.g. due to mismatched ref counts) rather
> than respecting the reference count, since it knows it's the last
> user. This would make potentially-buggy code safer.
OK, let me go ahead with a few ideas/questions along that path.
Let's say our stated goal is to let the "exit" system call from the
glibc thread exit path perform rseq unregistration (without explicit
unregistration beforehand). Let's look at what we need.
First, we need the TLS area to be valid until the exit system call
is invoked by the thread. If glibc defines __rseq_abi as a weak symbol,
I'm not entirely sure we can guarantee the IE model if another library
gets its own global-dynamic weak symbol elected at execution time. Would
it be better to switch to a "strong" symbol for the glibc __rseq_abi
rather than weak ?
If we rely on implicit unregistration by the exit system call, then we
need to be really sure that the __rseq_abi TLS area can be accessed
(load and store) from kernel preemption up to the point where exit
is invoked. If we have that guarantee with the IE model, then we should
be fine. This means the memory area with the __rseq_abi sits can only
be re-used after the tid field in the TLB is set to 0 by the exit system
call. Looking at allocatestack.c, it looks like the FREE_P () macro
does exactly that.
With all the above respected, we could rely on implicit rseq unregistration
by thread exit rather than do an explicit unregister. We could still need
to increment the __rseq_refcount upon thread start however, so we can
ensure early adopter libraries won't unregister rseq while glibc is using
it. No need to bring the refcount back to 0 in glibc though.
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 this,
is it valid to access a IE model TLS variable from a signal handler at
_any_ point where the signal handler nests over thread's execution ?
This includes early start and just before invoking the exit system call.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation
From: Rich Felker @ 2018-11-23 17:30 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Florian Weimer, carlos, Joseph Myers, Szabolcs Nagy, libc-alpha,
Thomas Gleixner, Ben Maurer, Peter Zijlstra, Paul E. McKenney,
Boqun Feng, Will Deacon, Dave Watson, Paul Turner, linux-kernel,
linux-api
In-Reply-To: <1150466925.11664.1542992720871.JavaMail.zimbra@efficios.com>
On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
> ----- On Nov 23, 2018, at 9:28 AM, Rich Felker dalias@libc.org wrote:
> [...]
> >
> > Absolutely. As long as it's in libc, implicit destruction will happen.
> > Actually I think the glibc code shound unconditionally unregister the
> > rseq address at exit (after blocking signals, so no application code
> > can run) in case a third-party rseq library was linked and failed to
> > do so before thread exit (e.g. due to mismatched ref counts) rather
> > than respecting the reference count, since it knows it's the last
> > user. This would make potentially-buggy code safer.
>
> OK, let me go ahead with a few ideas/questions along that path.
^^^^^^^^^^^^^^^
>
> Let's say our stated goal is to let the "exit" system call from the
> glibc thread exit path perform rseq unregistration (without explicit
> unregistration beforehand). Let's look at what we need.
This is not "along that path". The above-quoted text is not about
assuming it's safe to make SYS_exit without unregistering the rseq
object, but rather about glibc being able to perform the
rseq-unregister syscall without caring about reference counts, since
it knows no other code that might depend on rseq can run after it.
> First, we need the TLS area to be valid until the exit system call
> is invoked by the thread. If glibc defines __rseq_abi as a weak symbol,
> I'm not entirely sure we can guarantee the IE model if another library
> gets its own global-dynamic weak symbol elected at execution time. Would
> it be better to switch to a "strong" symbol for the glibc __rseq_abi
> rather than weak ?
This doesn't help; still whichever comes first in link order would
override. Either way __rseq_abi would be in static TLS, though,
because any dynamically-loaded library is necessarily loaded after
libc, which is loaded at initial exec time.
> 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 this,
> is it valid to access a IE model TLS variable from a signal handler at
> _any_ point where the signal handler nests over thread's execution ?
> This includes early start and just before invoking the exit system call.
It should be valid to access *any* TLS object like this, but the
standards don't cover it well. Right now access to dynamic TLS from
signal handlers is unsafe in glibc, but static is safe.
Rich
^ permalink raw reply
* Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation
From: Florian Weimer @ 2018-11-23 17:39 UTC (permalink / raw)
To: Rich Felker
Cc: Mathieu Desnoyers, carlos, Joseph Myers, Szabolcs Nagy,
libc-alpha, Thomas Gleixner, Ben Maurer, Peter Zijlstra,
Paul E. McKenney, Boqun Feng, Will Deacon, Dave Watson,
Paul Turner, linux-kernel, linux-api
In-Reply-To: <20181123173019.GK23599@brightrain.aerifal.cx>
* 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 this,
>> is it valid to access a IE model TLS variable from a signal handler at
>> _any_ point where the signal handler nests over thread's execution ?
>> This includes early start and just before invoking the exit system call.
>
> It should be valid to access *any* TLS object like this, but the
> standards don't cover it well.
C++ makes it undefined:
<http://eel.is/c++draft/support.signal#def:evaluation,signal-safe>
Thanks,
Florian
^ permalink raw reply
* Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation
From: Rich Felker @ 2018-11-23 17:44 UTC (permalink / raw)
To: Florian Weimer
Cc: Mathieu Desnoyers, carlos, Joseph Myers, Szabolcs Nagy,
libc-alpha, Thomas Gleixner, Ben Maurer, Peter Zijlstra,
Paul E. McKenney, Boqun Feng, Will Deacon, Dave Watson,
Paul Turner, linux-kernel, linux-api
In-Reply-To: <87zhtzsngn.fsf@oldenburg.str.redhat.com>
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
> >> exits throughout this email thread. Out of curiosity, what code is
> >> responsible for disabling signals in this situation ? Related to this,
> >> is it valid to access a IE model TLS variable from a signal handler at
> >> _any_ point where the signal handler nests over thread's execution ?
> >> This includes early start and just before invoking the exit system call.
> >
> > It should be valid to access *any* TLS object like this, but the
> > standards don't cover it well.
>
> C++ makes it undefined:
>
> <http://eel.is/c++draft/support.signal#def:evaluation,signal-safe>
C also leaves access to pretty much anything from a signal handler
undefined, but that makes signals basically useless. POSIX
inadvertently defines a lot more than it wanted to by ignoring
indirect ways you can access objects using AS-safe functions to pass
around their addresses; there's an open issue for this:
http://austingroupbugs.net/view.php?id=728
I think it's reasonable to say, based on how fond POSIX is of signals
for realtime stuff, that it should allow some reasonable operations,
but just be more careful about what it allows, and disallowing access
to TLS would preclude the only ways to make signals non-awful for
multithreaded processes.
Rich
^ permalink raw reply
* Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation
From: Mathieu Desnoyers @ 2018-11-23 17:52 UTC (permalink / raw)
To: Rich Felker
Cc: Florian Weimer, carlos, Joseph Myers, Szabolcs Nagy, libc-alpha,
Thomas Gleixner, Ben Maurer, Peter Zijlstra, Paul E. McKenney,
Boqun Feng, Will Deacon, Dave Watson, Paul Turner, linux-kernel,
linux-api
In-Reply-To: <20181123173019.GK23599@brightrain.aerifal.cx>
----- On Nov 23, 2018, at 12:30 PM, Rich Felker dalias@libc.org wrote:
> On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
>> ----- On Nov 23, 2018, at 9:28 AM, Rich Felker dalias@libc.org wrote:
>> [...]
>> >
>> > Absolutely. As long as it's in libc, implicit destruction will happen.
>> > Actually I think the glibc code shound unconditionally unregister the
>> > rseq address at exit (after blocking signals, so no application code
>> > can run) in case a third-party rseq library was linked and failed to
>> > do so before thread exit (e.g. due to mismatched ref counts) rather
>> > than respecting the reference count, since it knows it's the last
>> > user. This would make potentially-buggy code safer.
>>
>> OK, let me go ahead with a few ideas/questions along that path.
> ^^^^^^^^^^^^^^^
>>
>> Let's say our stated goal is to let the "exit" system call from the
>> glibc thread exit path perform rseq unregistration (without explicit
>> unregistration beforehand). Let's look at what we need.
>
> This is not "along that path". The above-quoted text is not about
> assuming it's safe to make SYS_exit without unregistering the rseq
> object, but rather about glibc being able to perform the
> rseq-unregister syscall without caring about reference counts, since
> it knows no other code that might depend on rseq can run after it.
When saying "along that path", what I mean is: if we go in that direction,
then we should look into going all the way there, and rely on thread
exit to implicitly unregister the TLS area.
Do you see any reason for doing an explicit unregistration at thread
exit rather than simply rely on the exit system call ?
>
>> First, we need the TLS area to be valid until the exit system call
>> is invoked by the thread. If glibc defines __rseq_abi as a weak symbol,
>> I'm not entirely sure we can guarantee the IE model if another library
>> gets its own global-dynamic weak symbol elected at execution time. Would
>> it be better to switch to a "strong" symbol for the glibc __rseq_abi
>> rather than weak ?
>
> This doesn't help; still whichever comes first in link order would
> override. Either way __rseq_abi would be in static TLS, though,
> because any dynamically-loaded library is necessarily loaded after
> libc, which is loaded at initial exec time.
OK, AFAIU so you argue for leaving the __rseq_abi symbol "weak". Just making
sure I correctly understand your position.
Something can be technically correct based on the current implementation,
but fragile with respect to future changes. We need to carefully distinguish
between the two when exposing ABIs.
>
>> 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 ?
This question is still open.
> Related to this,
>> is it valid to access a IE model TLS variable from a signal handler at
>> _any_ point where the signal handler nests over thread's execution ?
>> This includes early start and just before invoking the exit system call.
>
> It should be valid to access *any* TLS object like this, but the
> standards don't cover it well. Right now access to dynamic TLS from
> signal handlers is unsafe in glibc, but static is safe.
Which is a shame for the lttng-ust tracer, which needs global-dynamic
TLS variables so it can be dlopen'd, but aims at allowing tracing from
signal handlers. It looks like due to limitations of global-dynamic
TLS, tracing from instrumented signal handlers with lttng-ust tracepoints
could crash the process if the signal handler nests early at thread start
or late before thread exit. One way out of this would be to ensure signals
are blocked at thread start/exit, but I can't find the code responsible for
doing this within glibc.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation
From: Florian Weimer @ 2018-11-23 18:01 UTC (permalink / raw)
To: Rich Felker
Cc: Mathieu Desnoyers, carlos, Joseph Myers, Szabolcs Nagy,
libc-alpha, Thomas Gleixner, Ben Maurer, Peter Zijlstra,
Paul E. McKenney, Boqun Feng, Will Deacon, Dave Watson,
Paul Turner, linux-kernel, linux-api
In-Reply-To: <20181123174438.GL23599@brightrain.aerifal.cx>
* 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
>> >> exits throughout this email thread. Out of curiosity, what code is
>> >> responsible for disabling signals in this situation ? Related to this,
>> >> is it valid to access a IE model TLS variable from a signal handler at
>> >> _any_ point where the signal handler nests over thread's execution ?
>> >> This includes early start and just before invoking the exit system call.
>> >
>> > It should be valid to access *any* TLS object like this, but the
>> > standards don't cover it well.
>>
>> C++ makes it undefined:
>>
>> <http://eel.is/c++draft/support.signal#def:evaluation,signal-safe>
>
> C also leaves access to pretty much anything from a signal handler
> undefined, but that makes signals basically useless.
Access to atomic variables of thread storage duration is defined,
though.
Thanks,
Florian
^ permalink raw reply
* Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation
From: Rich Felker @ 2018-11-23 18:35 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Florian Weimer, carlos, Joseph Myers, Szabolcs Nagy, libc-alpha,
Thomas Gleixner, Ben Maurer, Peter Zijlstra, Paul E. McKenney,
Boqun Feng, Will Deacon, Dave Watson, Paul Turner, linux-kernel,
linux-api
In-Reply-To: <865273158.11687.1542995541389.JavaMail.zimbra@efficios.com>
On Fri, Nov 23, 2018 at 12:52:21PM -0500, Mathieu Desnoyers wrote:
> ----- On Nov 23, 2018, at 12:30 PM, Rich Felker dalias@libc.org wrote:
>
> > On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
> >> ----- On Nov 23, 2018, at 9:28 AM, Rich Felker dalias@libc.org wrote:
> >> [...]
> >> >
> >> > Absolutely. As long as it's in libc, implicit destruction will happen.
> >> > Actually I think the glibc code shound unconditionally unregister the
> >> > rseq address at exit (after blocking signals, so no application code
> >> > can run) in case a third-party rseq library was linked and failed to
> >> > do so before thread exit (e.g. due to mismatched ref counts) rather
> >> > than respecting the reference count, since it knows it's the last
> >> > user. This would make potentially-buggy code safer.
> >>
> >> OK, let me go ahead with a few ideas/questions along that path.
> > ^^^^^^^^^^^^^^^
> >>
> >> Let's say our stated goal is to let the "exit" system call from the
> >> glibc thread exit path perform rseq unregistration (without explicit
> >> unregistration beforehand). Let's look at what we need.
> >
> > This is not "along that path". The above-quoted text is not about
> > assuming it's safe to make SYS_exit without unregistering the rseq
> > object, but rather about glibc being able to perform the
> > rseq-unregister syscall without caring about reference counts, since
> > it knows no other code that might depend on rseq can run after it.
>
> When saying "along that path", what I mean is: if we go in that direction,
> then we should look into going all the way there, and rely on thread
> exit to implicitly unregister the TLS area.
>
> Do you see any reason for doing an explicit unregistration at thread
> exit rather than simply rely on the exit system call ?
Whether this is needed is an implementation detail of glibc that
should be permitted to vary between versions. Unless glibc wants to
promise that it would become a public guarantee, it's not part of the
discussion around the API/ABI. Only part of the discussion around
implementation internals of the glibc rseq stuff.
Of course I may be biased thinking application code should not assume
this since it's not true on musl -- for detached threads, the thread
frees its own stack before exiting (and thus has to unregister
set_tid_address and set_robustlist before exiting).
> >> First, we need the TLS area to be valid until the exit system call
> >> is invoked by the thread. If glibc defines __rseq_abi as a weak symbol,
> >> I'm not entirely sure we can guarantee the IE model if another library
> >> gets its own global-dynamic weak symbol elected at execution time. Would
> >> it be better to switch to a "strong" symbol for the glibc __rseq_abi
> >> rather than weak ?
> >
> > This doesn't help; still whichever comes first in link order would
> > override. Either way __rseq_abi would be in static TLS, though,
> > because any dynamically-loaded library is necessarily loaded after
> > libc, which is loaded at initial exec time.
>
> OK, AFAIU so you argue for leaving the __rseq_abi symbol "weak". Just making
> sure I correctly understand your position.
I don't think it matters, and I don't think making it weak is
meaningful or useful (weak in a shared library is largely meaningless)
but maybe I'm missing something here.
> Something can be technically correct based on the current implementation,
> but fragile with respect to future changes. We need to carefully distinguish
> between the two when exposing ABIs.
Yes.
> >> 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 ?
>
> This question is still open.
I can't find it -- maybe it's not done in glibc. It is in musl, and I
assumed glibc would also do it, because otherwise it's possible to see
some inconsistent states from signal handlers. Maybe these are all
undefined due to AS-unsafety of pthread_exit, but I think you can
construct examples where something could be observably wrong without
breaking any rules.
> > Related to this,
> >> is it valid to access a IE model TLS variable from a signal handler at
> >> _any_ point where the signal handler nests over thread's execution ?
> >> This includes early start and just before invoking the exit system call.
> >
> > It should be valid to access *any* TLS object like this, but the
> > standards don't cover it well. Right now access to dynamic TLS from
> > signal handlers is unsafe in glibc, but static is safe.
>
> Which is a shame for the lttng-ust tracer, which needs global-dynamic
> TLS variables so it can be dlopen'd, but aims at allowing tracing from
> signal handlers. It looks like due to limitations of global-dynamic
> TLS, tracing from instrumented signal handlers with lttng-ust tracepoints
> could crash the process if the signal handler nests early at thread start
> or late before thread exit. One way out of this would be to ensure signals
> are blocked at thread start/exit, but I can't find the code responsible for
> doing this within glibc.
Just blocking at start/exit won't solve the problem because
global-dynamic TLS in glibc involves dynamic allocation, which is hard
to make AS-safe and of course can fail, leaving no way to make forward
progress.
Rich
^ permalink raw reply
* Re: Official Linux system wrapper library?
From: Daniel Colascione @ 2018-11-23 20:15 UTC (permalink / raw)
To: Florian Weimer
Cc: Michael Kerrisk-manpages, linux-kernel, Joel Fernandes, Linux API,
Willy Tarreau, Vlastimil Babka, Carlos O'Donell,
GNU C Library
In-Reply-To: <87efbbvrx9.fsf@oldenburg.str.redhat.com>
On Fri, Nov 23, 2018 at 5:34 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Daniel Colascione:
>
> > On Mon, Nov 12, 2018 at 12:11 AM, Florian Weimer <fweimer@redhat.com> 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 system
> >>> call is flawed.
> >>
> >> It's not that simple, I think. What about bdflush? socketcall?
> >> getxpid? osf_gettimeofday? set_robust_list?
> >
> > What about them? Mentioning that these system calls exist is not in
> > itself an argument.
>
> But socketcall does not exist on all architectures. Neither does
> getpid, it's called getxpid on some architectures.
So what? On systems on which a given system call does not exist,
attempts to link against that system call should fail, or attempts to
make that system call should fail at runtime with ENOSYS. That's
completely expected and unsurprising behavior, not some unavoidable
source of catastrophic confusion.
> >> There are quite a few irregularities
> >
> > So?
>
> I think it would be a poor approach to expose application developers to
> these portability issues. We need to abstract over these differences at
> a certain layer, and applications are too late.
And glibc is too early. The purpose of the lowest-level user library
is not to provide an OS-agnostic portability layer. There are other
projects much better-suited to providing portability, including the
excellent GLib, Gnulib, and Qt. The purpose of the lowest-level user
library is to expose the interfaces of the underlying system, whatever
they are. That's a basic tenet of layered interface design.
Due to historical accident, the same library (on most Linux systems)
serves as both the lowest-level user library and an implementation of
some antiquated portability constructs from ANSI C and POSIX. That
this library provides these old portability interfaces is not a reason
for that library to neglect its responsibility as the lowest-level
system interface library. If people find that every attempt to expose
even trivial new kernel interfaces turns into an endless trek through
a swamp of specious objection (see the gettid debacle), then it
becomes perfectly reasonable to find an alternate route over firmer
ground.
Other glibc developers (e.g., Joseph Myers) have expressed support for
adding long-missing system call wrappers, like gettid, as long as the
functions are adequately documented. Would you make a sustained
objection to these additions?
> >> and some editorial discretion appears to be unavoidable.
> >
> > That's an assertion, not an argument, and I strongly disagree. *Why*
> > do you think "editorial discretion" is unavoidable?
>
> We do not want application authors to write code which uses socketcall,
That's an opinion on portability, not an argument for the necessity of
"editorial discretion". That you think an application calling
socketcall would somehow be a bad idea is not a justification for not
providing this interface. Low-level libraries must focus on mechanism,
not policy, if a system is to be flexible enough to accommodate
unanticipated needs.
^ permalink raw reply
* Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation
From: Mathieu Desnoyers @ 2018-11-23 21:09 UTC (permalink / raw)
To: Rich Felker
Cc: Florian Weimer, carlos, Joseph Myers, Szabolcs Nagy, libc-alpha,
Thomas Gleixner, Ben Maurer, Peter Zijlstra, Paul E. McKenney,
Boqun Feng, Will Deacon, Dave Watson, Paul Turner, linux-kernel,
linux-api
In-Reply-To: <20181123183558.GM23599@brightrain.aerifal.cx>
----- On Nov 23, 2018, at 1:35 PM, Rich Felker dalias@libc.org wrote:
> On Fri, Nov 23, 2018 at 12:52:21PM -0500, Mathieu Desnoyers wrote:
>> ----- On Nov 23, 2018, at 12:30 PM, Rich Felker dalias@libc.org wrote:
>>
>> > On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
>> >> ----- On Nov 23, 2018, at 9:28 AM, Rich Felker dalias@libc.org wrote:
>> >> [...]
>> >> >
>> >> > Absolutely. As long as it's in libc, implicit destruction will happen.
>> >> > Actually I think the glibc code shound unconditionally unregister the
>> >> > rseq address at exit (after blocking signals, so no application code
>> >> > can run) in case a third-party rseq library was linked and failed to
>> >> > do so before thread exit (e.g. due to mismatched ref counts) rather
>> >> > than respecting the reference count, since it knows it's the last
>> >> > user. This would make potentially-buggy code safer.
>> >>
>> >> OK, let me go ahead with a few ideas/questions along that path.
>> > ^^^^^^^^^^^^^^^
>> >>
>> >> Let's say our stated goal is to let the "exit" system call from the
>> >> glibc thread exit path perform rseq unregistration (without explicit
>> >> unregistration beforehand). Let's look at what we need.
>> >
>> > This is not "along that path". The above-quoted text is not about
>> > assuming it's safe to make SYS_exit without unregistering the rseq
>> > object, but rather about glibc being able to perform the
>> > rseq-unregister syscall without caring about reference counts, since
>> > it knows no other code that might depend on rseq can run after it.
>>
>> When saying "along that path", what I mean is: if we go in that direction,
>> then we should look into going all the way there, and rely on thread
>> exit to implicitly unregister the TLS area.
>>
>> Do you see any reason for doing an explicit unregistration at thread
>> exit rather than simply rely on the exit system call ?
>
> Whether this is needed is an implementation detail of glibc that
> should be permitted to vary between versions. Unless glibc wants to
> promise that it would become a public guarantee, it's not part of the
> discussion around the API/ABI. Only part of the discussion around
> implementation internals of the glibc rseq stuff.
>
> Of course I may be biased thinking application code should not assume
> this since it's not true on musl -- for detached threads, the thread
> frees its own stack before exiting (and thus has to unregister
> set_tid_address and set_robustlist before exiting).
OK, so on glibc, the implementation could rely on exit side-effect to
implicitly unregister rseq. On musl, based on the scenario you describe,
the library should unregister rseq explicitly before stack reclaim.
Am I understanding the situation correctly ?
>
>> >> First, we need the TLS area to be valid until the exit system call
>> >> is invoked by the thread. If glibc defines __rseq_abi as a weak symbol,
>> >> I'm not entirely sure we can guarantee the IE model if another library
>> >> gets its own global-dynamic weak symbol elected at execution time. Would
>> >> it be better to switch to a "strong" symbol for the glibc __rseq_abi
>> >> rather than weak ?
>> >
>> > This doesn't help; still whichever comes first in link order would
>> > override. Either way __rseq_abi would be in static TLS, though,
>> > because any dynamically-loaded library is necessarily loaded after
>> > libc, which is loaded at initial exec time.
>>
>> OK, AFAIU so you argue for leaving the __rseq_abi symbol "weak". Just making
>> sure I correctly understand your position.
>
> I don't think it matters, and I don't think making it weak is
> meaningful or useful (weak in a shared library is largely meaningless)
> but maybe I'm missing something here.
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.
Using "weak" in a C library is something I'm not sure is a characteristic
we want or need, because I doubt we would ever want to load two libc at the
same time in a given process.
The only reason I see for using "weak" for the __rseq_abi symbol in the
libc is if we want to allow early adopter applications to define
__rseq_abi as a strong symbol, which would make some sense.
>
>> Something can be technically correct based on the current implementation,
>> but fragile with respect to future changes. We need to carefully distinguish
>> between the two when exposing ABIs.
>
> Yes.
>
>> >> 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 ?
>>
>> This question is still open.
>
> I can't find it -- maybe it's not done in glibc. It is in musl, and I
> assumed glibc would also do it, because otherwise it's possible to see
> some inconsistent states from signal handlers. Maybe these are all
> undefined due to AS-unsafety of pthread_exit, but I think you can
> construct examples where something could be observably wrong without
> breaking any rules.
Good to know for the musl case.
>
>> > Related to this,
>> >> is it valid to access a IE model TLS variable from a signal handler at
>> >> _any_ point where the signal handler nests over thread's execution ?
>> >> This includes early start and just before invoking the exit system call.
>> >
>> > It should be valid to access *any* TLS object like this, but the
>> > standards don't cover it well. Right now access to dynamic TLS from
>> > signal handlers is unsafe in glibc, but static is safe.
>>
>> Which is a shame for the lttng-ust tracer, which needs global-dynamic
>> TLS variables so it can be dlopen'd, but aims at allowing tracing from
>> signal handlers. It looks like due to limitations of global-dynamic
>> TLS, tracing from instrumented signal handlers with lttng-ust tracepoints
>> could crash the process if the signal handler nests early at thread start
>> or late before thread exit. One way out of this would be to ensure signals
>> are blocked at thread start/exit, but I can't find the code responsible for
>> doing this within glibc.
>
> Just blocking at start/exit won't solve the problem because
> global-dynamic TLS in glibc involves dynamic allocation, which is hard
> to make AS-safe and of course can fail, leaving no way to make forward
> progress.
How hard would it be to create a async-signal-safe memory pool, which would
be always accessed with signals blocked, so we could fix those corner-cases
for good ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* Re: [PATCH v3 3/4] libbpf: add bpf_prog_test_run_xattr
From: Daniel Borkmann @ 2018-11-23 22:25 UTC (permalink / raw)
To: Lorenz Bauer, ast; +Cc: netdev, linux-api, ys114321
In-Reply-To: <20181122140910.1079-4-lmb@cloudflare.com>
On 11/22/2018 03:09 PM, Lorenz Bauer wrote:
> Add a new function, which encourages safe usage of the test interface.
> bpf_prog_test_run continues to work as before, but should be considered
> unsafe.
>
> Signed-off-by: Lorenz Bauer <lmb@cloudflare.com>
Set looks good to me, thanks! Three small things below:
> ---
> tools/lib/bpf/bpf.c | 27 +++++++++++++++++++++++++++
> tools/lib/bpf/bpf.h | 13 +++++++++++++
> 2 files changed, 40 insertions(+)
>
> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> index 961e1b9fc592..f8518bef6886 100644
> --- a/tools/lib/bpf/bpf.c
> +++ b/tools/lib/bpf/bpf.c
> @@ -424,6 +424,33 @@ int bpf_prog_test_run(int prog_fd, int repeat, void *data, __u32 size,
> return ret;
> }
>
> +int bpf_prog_test_run_xattr(const struct bpf_prog_test_run_attr *test_attr,
> + __u32 *size_out, __u32 *retval, __u32 *duration)
> +{
> + union bpf_attr attr;
> + int ret;
> +
> + if (!test_attr->data_out && test_attr->size_out > 0)
> + return -EINVAL;
> +
> + bzero(&attr, sizeof(attr));
> + attr.test.prog_fd = test_attr->prog_fd;
> + attr.test.data_in = ptr_to_u64(test_attr->data);
> + attr.test.data_out = ptr_to_u64(test_attr->data_out);
> + attr.test.data_size_in = test_attr->size;
> + attr.test.data_size_out = test_attr->size_out;
> + attr.test.repeat = test_attr->repeat;
> +
> + ret = sys_bpf(BPF_PROG_TEST_RUN, &attr, sizeof(attr));
> + if (size_out)
> + *size_out = attr.test.data_size_out;
> + if (retval)
> + *retval = attr.test.retval;
> + if (duration)
> + *duration = attr.test.duration;
> + return ret;
> +}
> +
> int bpf_prog_get_next_id(__u32 start_id, __u32 *next_id)
> {
> union bpf_attr attr;
> diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
> index 26a51538213c..570f19f77f42 100644
> --- a/tools/lib/bpf/bpf.h
> +++ b/tools/lib/bpf/bpf.h
> @@ -110,6 +110,19 @@ LIBBPF_API int bpf_prog_attach(int prog_fd, int attachable_fd,
> LIBBPF_API int bpf_prog_detach(int attachable_fd, enum bpf_attach_type type);
> LIBBPF_API int bpf_prog_detach2(int prog_fd, int attachable_fd,
> enum bpf_attach_type type);
> +
> +struct bpf_prog_test_run_attr {
> + int prog_fd;
> + int repeat;
> + const void *data;
> + __u32 size;
> + void *data_out; /* optional */
> + __u32 size_out;
Small nit: could we name these data_{in,out} and data_size_{in,out} as
well, so it's analog to the ones from the bpf_attr?
> +};
> +
> +LIBBPF_API int bpf_prog_test_run_xattr(const struct bpf_prog_test_run_attr *test_attr,
> + __u32 *size_out, __u32 *retval,
> + __u32 *duration);
> LIBBPF_API int bpf_prog_test_run(int prog_fd, int repeat, void *data,
> __u32 size, void *data_out, __u32 *size_out,
> __u32 *retval, __u32 *duration);
Could we add a comment into the header here stating that we discourage
bpf_prog_test_run()'s use?
It would probably also make sense since we go that route that we would
convert the 10 bpf_prog_test_run() instances under test_progs.c at the
same time so that people extending or looking at BPF kselftests don't
copy discouraged bpf_prog_test_run() api as examples from this point
onwards anymore.
Thanks,
Daniel
^ permalink raw reply
* Re: Official Linux system wrapper library?
From: Dmitry V. Levin @ 2018-11-23 23:19 UTC (permalink / raw)
To: Daniel Colascione
Cc: Michael Kerrisk-manpages, Joel Fernandes, Willy Tarreau,
Vlastimil Babka, GNU C Library, linux-api, linux-kernel
In-Reply-To: <CAKOZuesFZqstO-9K2tLQ1sOOmYsN73QdTHNG0De0a=eq5BT99w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]
On Fri, Nov 23, 2018 at 12:15:39PM -0800, Daniel Colascione wrote:
> On Fri, Nov 23, 2018 at 5:34 AM Florian Weimer wrote:
> > > On Mon, Nov 12, 2018 at 12:11 AM, Florian Weimer wrote:
> > >>
> > >>> 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?
> > >
> > > What about them? Mentioning that these system calls exist is not in
> > > itself an argument.
> >
> > But socketcall does not exist on all architectures. Neither does
> > getpid, it's called getxpid on some architectures.
>
> So what? On systems on which a given system call does not exist,
> attempts to link against that system call should fail, or attempts to
> make that system call should fail at runtime with ENOSYS. That's
> completely expected and unsurprising behavior, not some unavoidable
> source of catastrophic confusion.
I'm sorry but you've just said that getpid() must either be unavailable or
fail on those architectures that provide no syscall with exactly the same
semantics as getpid syscall. Nobody is going to use a libc that doesn't
provide getpid() in a reliable way.
If you really need a 1-1 correspondence between syscalls and C wrappers,
there is syscall(3) with all associated portability issues.
If you need something else, please be more specific, i.e. be ready to give
a detailed answer about every syscall ever supported by the kernel,
on every supported architecture.
My first trivial question is, do you need C wrappers for
__NR_epoll_create, __NR_eventfd, __NR_inotify_init,
and __NR_signalfd syscalls?
--
ldv
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Official Linux system wrapper library?
From: David Newall @ 2018-11-24 3:41 UTC (permalink / raw)
To: Szabolcs Nagy, Florian Weimer, Daniel Colascione
Cc: nd, Michael Kerrisk (man-pages), linux-kernel, Joel Fernandes,
Linux API, Willy Tarreau, Vlastimil Babka, Carlos O'Donell,
libc-alpha@sourceware.org
In-Reply-To: <b0c3ecce-c4d0-246d-d702-21674f950e34@arm.com>
On 24/11/18 1:53 am, Szabolcs Nagy wrote:
> On 23/11/18 14:11, David Newall wrote:
>> On 24/11/18 12:04 am, Florian Weimer wrote:
>>> But socketcall does not exist on all architectures. Neither does
>>> getpid, it's called getxpid on some architectures.
>>> ...
>>> I think it would be a poor approach to expose application developers to
>>> these portability issues. We need to abstract over these differences at
>>> a certain layer, and applications are too late.
>> Interesting. I think the opposite. I think exposing the OS's interfaces is exactly what a c-library should do. It might also provide
>> alternative interfaces that work consistently across different platforms, but in addition to, not instead of the OS interface.
> you don't understand the point of the c language if you think so.
I understand the point of C, thank you very much, and we're talking
about the C library, not the language. I don't understand the point of
your rudeness.
^ permalink raw reply
* Re: RFC: userspace exception fixups
From: Jarkko Sakkinen @ 2018-11-24 17:07 UTC (permalink / raw)
To: Jethro Beekman
Cc: Andy Lutomirski, Dave Hansen, Christopherson, Sean J,
Florian Weimer, Linux API, Jann Horn, Linus Torvalds, X86 ML,
linux-arch, LKML, Peter Zijlstra, Rich Felker, nhorman@redhat.com,
npmccallum@redhat.com, Ayoun, Serge, shay.katz-zamir@intel.com,
linux-sgx@vger.kernel.org, Andy Shevchenko
In-Reply-To: <20181121151734.GA16564@linux.intel.com>
On Wed, Nov 21, 2018 at 05:17:34PM +0200, Jarkko Sakkinen wrote:
> On Wed, Nov 21, 2018 at 05:17:32AM +0000, Jethro Beekman wrote:
> > Jarkko, can you please explain you solution in detail? The CPU receives an
> > exception. This will be handled by the kernel exception handler. What
> > information does the kernel exception handler use to determine whether to
> > deliver the exception as a regular signal to the process, or whether to set
> > the special registers values for userspace and just continue executing the
> > process manually?
>
> Now we throw SIGSEGV when PF_SGX set, right? In my solution that would
> be turned just doing iret to AEP with the extra that three registers get
> exception data (type, reason, addr). No decoding or RIP adjusting
> involved.
>
> That would mean that you would actually have to implement AEP handler
> than just have enclu there.
>
> I've also proposed that perhaps for SGX also #UD should be propagated
> this way because for some instructions you need outside help to emulate
> "non-enclave" environment.
>
> That is all I have drafted together so far. I'll try to finish v18 this
> week with other stuff and refine further next week (unless someone gives
> obvious reason why this doesn't work, which might well be because I
> haven't went too deep with my analysis yet because of lack of time).
The obvious con in this approach is that if you single step the code,
the whole AEP handler would single stepped also everytime. Probably big
enough con that it is better to go with the vDSO approach anyhow...
/Jarkko
^ permalink raw reply
* Re: [PATCH v3 3/4] libbpf: add bpf_prog_test_run_xattr
From: Alexei Starovoitov @ 2018-11-24 22:20 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Lorenz Bauer, ast, netdev, linux-api, ys114321
In-Reply-To: <b4308b6f-5a1d-f015-4e7f-abca1b3902be@iogearbox.net>
On Fri, Nov 23, 2018 at 11:25:11PM +0100, Daniel Borkmann wrote:
> On 11/22/2018 03:09 PM, Lorenz Bauer wrote:
> > Add a new function, which encourages safe usage of the test interface.
> > bpf_prog_test_run continues to work as before, but should be considered
> > unsafe.
> >
> > Signed-off-by: Lorenz Bauer <lmb@cloudflare.com>
>
> Set looks good to me, thanks! Three small things below:
>
> > ---
> > tools/lib/bpf/bpf.c | 27 +++++++++++++++++++++++++++
> > tools/lib/bpf/bpf.h | 13 +++++++++++++
> > 2 files changed, 40 insertions(+)
> >
> > diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> > index 961e1b9fc592..f8518bef6886 100644
> > --- a/tools/lib/bpf/bpf.c
> > +++ b/tools/lib/bpf/bpf.c
> > @@ -424,6 +424,33 @@ int bpf_prog_test_run(int prog_fd, int repeat, void *data, __u32 size,
> > return ret;
> > }
> >
> > +int bpf_prog_test_run_xattr(const struct bpf_prog_test_run_attr *test_attr,
> > + __u32 *size_out, __u32 *retval, __u32 *duration)
> > +{
> > + union bpf_attr attr;
> > + int ret;
> > +
> > + if (!test_attr->data_out && test_attr->size_out > 0)
> > + return -EINVAL;
> > +
> > + bzero(&attr, sizeof(attr));
> > + attr.test.prog_fd = test_attr->prog_fd;
> > + attr.test.data_in = ptr_to_u64(test_attr->data);
> > + attr.test.data_out = ptr_to_u64(test_attr->data_out);
> > + attr.test.data_size_in = test_attr->size;
> > + attr.test.data_size_out = test_attr->size_out;
> > + attr.test.repeat = test_attr->repeat;
> > +
> > + ret = sys_bpf(BPF_PROG_TEST_RUN, &attr, sizeof(attr));
> > + if (size_out)
> > + *size_out = attr.test.data_size_out;
> > + if (retval)
> > + *retval = attr.test.retval;
> > + if (duration)
> > + *duration = attr.test.duration;
> > + return ret;
> > +}
> > +
> > int bpf_prog_get_next_id(__u32 start_id, __u32 *next_id)
> > {
> > union bpf_attr attr;
> > diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
> > index 26a51538213c..570f19f77f42 100644
> > --- a/tools/lib/bpf/bpf.h
> > +++ b/tools/lib/bpf/bpf.h
> > @@ -110,6 +110,19 @@ LIBBPF_API int bpf_prog_attach(int prog_fd, int attachable_fd,
> > LIBBPF_API int bpf_prog_detach(int attachable_fd, enum bpf_attach_type type);
> > LIBBPF_API int bpf_prog_detach2(int prog_fd, int attachable_fd,
> > enum bpf_attach_type type);
> > +
> > +struct bpf_prog_test_run_attr {
> > + int prog_fd;
> > + int repeat;
> > + const void *data;
> > + __u32 size;
> > + void *data_out; /* optional */
> > + __u32 size_out;
>
> Small nit: could we name these data_{in,out} and data_size_{in,out} as
> well, so it's analog to the ones from the bpf_attr?
>
> > +};
> > +
> > +LIBBPF_API int bpf_prog_test_run_xattr(const struct bpf_prog_test_run_attr *test_attr,
> > + __u32 *size_out, __u32 *retval,
> > + __u32 *duration);
can we keep return values in struct bpf_prog_test_run_attr ?
I think the interface will be easier to use and faster. Less pointers
to pass around.
> > LIBBPF_API int bpf_prog_test_run(int prog_fd, int repeat, void *data,
> > __u32 size, void *data_out, __u32 *size_out,
> > __u32 *retval, __u32 *duration);
>
> Could we add a comment into the header here stating that we discourage
> bpf_prog_test_run()'s use?
>
> It would probably also make sense since we go that route that we would
> convert the 10 bpf_prog_test_run() instances under test_progs.c at the
> same time so that people extending or looking at BPF kselftests don't
> copy discouraged bpf_prog_test_run() api as examples from this point
> onwards anymore.
I would keep bpf_prog_test_run() and test_progs.c as-is.
I think the prog_test_run in the current form is actually fine.
I don't find it 'unsafe'.
When it's called on a given bpf prog the user knows what prog
suppose to do. If prog is increasing the packet size the test writer
knows that and should size the output buffer accordingly.
Also there are plenty of tests where progs don't change the packet size
and any test with 'repeat > 1' should have the packet size
return to initial value. Like if the test is doing ipip encap
at the end of the run the bpf prog should remove that encap.
Otherwise 'repeat > 1' will produce wrong results.
^ permalink raw reply
* Re: [PATCH -next 1/2] mm/memfd: make F_SEAL_FUTURE_WRITE seal more robust
From: Andrew Morton @ 2018-11-25 0:42 UTC (permalink / raw)
To: Joel Fernandes
Cc: Andy Lutomirski, Stephen Rothwell, LKML, Hugh Dickins, Jann Horn,
Khalid Aziz, Linux API, open list:KERNEL SELFTEST FRAMEWORK,
Linux-MM, marcandre.lureau, Matthew Wilcox, Mike Kravetz,
Shuah Khan
In-Reply-To: <20181122230906.GA198127@google.com>
On Thu, 22 Nov 2018 15:09:06 -0800 Joel Fernandes <joel@joelfernandes.org> wrote:
> Android uses ashmem for sharing memory regions. We are looking forward to
> migrating all usecases of ashmem to memfd so that we can possibly remove
> the ashmem driver in the future from staging while also benefiting from
> using memfd and contributing to it. Note staging drivers are also not ABI
> and generally can be removed at anytime.
>
> One of the main usecases Android has is the ability to create a region and
> mmap it as writeable, then add protection against making any "future"
> writes while keeping the existing already mmap'ed writeable-region active.
> This allows us to implement a usecase where receivers of the shared
> memory buffer can get a read-only view, while the sender continues to
> write to the buffer. See CursorWindow documentation in Android for more
> details:
> https://developer.android.com/reference/android/database/CursorWindow
>
> This usecase cannot be implemented with the existing F_SEAL_WRITE seal.
> To support the usecase, this patch adds a new F_SEAL_FUTURE_WRITE seal
> which prevents any future mmap and write syscalls from succeeding while
> keeping the existing mmap active.
>
> A better way to do F_SEAL_FUTURE_WRITE seal was discussed [1] last week
> where we don't need to modify core VFS structures to get the same
> behavior of the seal. This solves several side-effects pointed by Andy.
> self-tests are provided in later patch to verify the expected semantics.
>
> [1] https://lore.kernel.org/lkml/20181111173650.GA256781@google.com/
This changelog doesn't have the nifty test case code which was in
earlier versions?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox