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...
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
