[Toybox] ls -laZ /dev takes a long time

[Rob Landley]

On 10/17/2015 12:47 PM, enh wrote:
> On Sat, Oct 17, 2015 at 9:21 AM, Rich Felker <dalias at libc.org> wrote:
>> On Fri, Oct 16, 2015 at 12:56:01PM -0700, enh wrote:
>>> at the moment, ls.c has this:
>>>
>>>   if (flags & FLAG_Z) {
>>>     if (!CFG_TOYBOX_LSM_NONE) {
>>>       int fd;
>>>
>>>       // Why not just openat(O_PATH|(O_NOFOLLOW*!!(toys.optflags&FLAG_L))) and
>>>       // lsm_fget_context() on that filehandle? Because the kernel is broken,
>>>       // and won't let us read this "metadata" from the filehandle unless we
>>>       // have permission to read the data. We _can_ read the same data in
>>>       // by path, we just can't do it through an O_PATH filehandle, because
>>>       // reasons. So as a bug workaround for the broken kernel, we do it
>>>       // both ways.
>>>       //
>>>       // The O_NONBLOCK is there to avoid triggering automounting (there's
>>>       // a rush of nostalgia for you) on directories we don't descend into,
>>>       // which O_PATH would have done for us but see "the kernel is broken".
>>>       if (S_ISSOCK(new->st.st_mode) ||
>>>           (S_ISLNK(new->st.st_mode) && !(toys.optflags & FLAG_L)) ||
>>>           -1 == (fd = openat(dirtree_parentfd(new), new->name,
>>>                              O_RDONLY|O_NONBLOCK|O_NOATIME)))
>>
>> I don't know about this specific case, but generally you can work
>> around all the situations where O_PATH misbehaves when operating on
>> the resulting fd by using the function that takes a pathname and
>> passing /proc/self/fd/%d with the O_PATH fd filled-in instead.
> 
> yeah, that's what bionic's *xattr functions do (which was apparently
> the only part of the linked-to patch rob didn't look at :-) --- the
> direct link to that file is
> https://android-review.googlesource.com/#/c/152663/4/libc/bionic/fgetxattr.cpp
> ).

Sigh. If it's only for -Z, then fine. I'm ok with having ls do that.
(Having normal ls behavior depend on /proc being mounted is creepy, but
xattrs are abnormal.)

And this is _clearly_ a workaround for a kernel bug by exploiting what
looks like another kernel bug. Can somebody smack the kernel guys?
Seriously?

> that was what i intended as option 2: basically copy that code into
> toybox.

Works for me.

Thanks,

Rob

 1445114637.0