lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMuHMdUbesGLdWSh3+JnM2GH_T4TeD3SD-Tb6pwEzYWL4k0g-g@mail.gmail.com>
Date:	Fri, 27 Jan 2012 21:54:22 +0100
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Richard Weinberger <richard@....at>,
	user-mode-linux-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] uml/hostfs: Propagate dirent.d_type to filldir()

Hi Christoph,

On Fri, Jan 27, 2012 at 19:20, Christoph Hellwig <hch@...radead.org> wrote:
> On Fri, Jan 27, 2012 at 07:14:58PM +0100, Geert Uytterhoeven wrote:
>> Currently the (optional) d_type member in struct dirent is always
>> DT_UNKNOWN on hostfs, which may confuse buggy software using readdir().
>> Make sure to propagate its value from the underlying filesystem if it's
>> available there.
>
> What software would that be?  We have lots of filesystems not filling

Something proprietary, which got fixed in the mean time.

> in d_type, and several operating systems don't have it at all.

Almost all filesystems on a typical Ubuntu desktop or Android device fill it in.
Iso9660 is the notable exception.

Several of the more exotic ones probably don't support it. E.g. affs
fills it in for
directories only.

>From getdents(2):
       The d_type field is implemented since Linux 2.6.4.  It occupies a space
       that was previously a zero-filled  padding  byte  in  the  linux_dirent
       structure.   Thus,  on  kernels before 2.6.3, attempting to access this
       field always provides the value 0 (DT_UNKNOWN).

       Currently, only some file systems (among them: Btrfs, ext2,  ext3,  and
       ext4)  have  full  support  for returning the file type in d_type.  All
       applications must properly handle a return of DT_UNKNOWN.

If it's there, it saves lots of stat calls.
So I take it it's a good thing if it gets fixed?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ