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

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

On Sat, Jul 23, 2011 at 10:53:37PM +0100, Al Viro wrote:
> 	That's about it - shouldn't be a problem to switch mode_t in ABI to
> __kernel_mode_t (equivalent, since mode_t is typedefed to __kernel_mode_t)
> and we are free to do whatever we want with internal mode_t.  I suspect
> that starting with centralized typedef for umode_t (always u16) it wouldn't
> take much to drive all internal uses to umode_t (or size_t, in at least one
> case ;-), then replace all remaining (part of ABI) instances with
> __kernel_mode_t and rename umode_t to mode_t.  I'll try to put such a series
> together tonight; will push to #mode_t once done...

And that has immediately caught a lovely bug on jffs2 with ACLs - any
big-endian platform with 16bit mode_t is fucked, since we have
jffs2_new_inode(..., int mode, ...) do
        ret = jffs2_init_acl_pre(dir_i, inode, &mode);
The latter expects int *, which is what it gets.  The it explicitly casts
that to mode_t * and passes to posix_acl_create_masq() (directly in current
mainline, through posix_acl_create() in #untested).  Back in jffs2_new_inode()
we use the damn thing afterwards.  Moreover, posix_acl_create_masq() uses
the value pointed to by mode_t * it gets.  And expects normal S_IF... in
it.

IOW, on sparc32 (at least) it's screwed - it'll see 0 what's actually upper
16 bits of jffs2_new_inode() mode argument instead of what should've seen
(the lower 16 bits).  It will leave them 0, so the caller won't notice anything
weird going on, but ACL will be buggered and mode won't be adjusted.

Also screwed: avr32, frv, h8300, m68k, parisc, s390 and, in their big-endian
variants, arm, m32r, microblaze and sh.

Fucked-up-by: commit cfc8dc6f6f69ede939e09c2af06a01adee577285