[Toybox] ls -laZ /dev takes a long time
Rob Landley
rob at landley.net
Sat Oct 17 13:43:57 PDT 2015
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
More information about the Toybox
mailing list