Re: [PATCH] vfs: move ACL cache lookup into generic code

[Al Viro <viro@ZenIV.linux.org.uk>]

On Sat, Jul 23, 2011 at 04:32:00PM +0100, Al Viro wrote:
> On Sat, Jul 23, 2011 at 04:50:37PM +0200, Christoph Hellwig wrote:
> > On Sat, Jul 23, 2011 at 08:47:22AM +0100, Al Viro wrote:
> > > Anyway, that'll have to wait for tomorrow; I'm going down right now.  This
> > > stuff (plus Tim's "mount lock scalability for internal mounts" patch) is
> > > in #untested in usual place.  Comments/testing/etc. are welcome...
> > 
> > Can't be just pass &inode->i_mode to posix_acl_create for those filesystems
> > that simply write directly into i_mode, instead of keeping it in a local
> > variable?
> 
> umode_t vs. mode_t...

We have some really stunning misuses of mode_t, BTW:
static mode_t
find_smbios_instance_string(struct pci_dev *pdev, char *buf,
                            enum smbios_attr_enum attribute)
{
...
                                        return scnprintf(buf, PAGE_SIZE,
                                                         "%d\n",
...
                                        return scnprintf(buf, PAGE_SIZE,
                                                         "%s\n",
                                                         dmi->name);
...
                        return strlen(dmi->name);
...
        return 0;
}

i.e. that one is misspelled size_t (drivers/pci/pci-label.c).  I don't
like how mode_t and umode_t are mixed up as well...

Why is the latter per-architecture, BTW?  It's unsigned short everywhere
and we'd already got some clowns exposing it in userland ABI (see
include/trace/events/ext4.h).  Is there any good reason for separate
mode_t and umode_t kernel-side?  We use mode_t in some syscall declarations
(not all, BTW - mknod() uses unsigned int), but inside the kernel we
almost immediately lose upper bits on conversions anyway...

And things like ->mkdir() are declare as passing int, treat it as mode_t and
end up storing it in umode_t...  I haven't found any obvious places where
that kind of stuff could cause problems, but that was just a casual look.

umode_t is *old* - it's been introduced in 0.95, back when a bunch of
->i_... got typedefed types.  I never looked into its history and that's
way before my time...