lkml.org 
[lkml]   [2012]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: compat: autofs v5 packet size ambiguity - update
    From
    Date
    Am Mittwoch, den 22.02.2012, 13:57 +0800 schrieb Ian Kent:
    > On Wed, 2012-02-22 at 13:53 +0800, Ian Kent wrote:
    > > On Wed, 2012-02-22 at 13:43 +0800, Ian Kent wrote:
    > > > On Tue, 2012-02-21 at 20:56 -0800, Linus Torvalds wrote:
    > >
    > > Ahh ... forgot to set the file_operations structure member .. oops
    > >
    > > >
    > > > +static int autofs4_root_dir_open(struct inode *inode, struct file *file)
    > > > +{
    > > > + struct autofs_sb_info *sbi= autofs4_sbi(file->f_path.dentry->d_sb);
    > > > + if (sbi->compat_daemon < 0)
    > > > + sbi->compat_daemon = is_compat_task();
    > > > + return dcache_dir_open(inode, file);
    > > > +}
    > > > +
    > >
    >
    > Lets try that again.
    >
    > autofs: work around unhappy compat problem on x86-64
    >
    > From: Ian Kent <raven@themaw.net>
    >
    > When the autofs protocol version 5 packet type was added in commit
    > 5c0a32fc2cd0 ("autofs4: add new packet type for v5 communications"), it
    > obvously tried quite hard to be word-size agnostic, and uses explicitly
    > sized fields that are all correctly aligned.
    >
    > However, with the final "char name[NAME_MAX+1]" array at the end, the
    > actual size of the structure ends up being not very well defined:
    > because the struct isn't marked 'packed', doing a "sizeof()" on it will
    > align the size of the struct up to the biggest alignment of the members
    > it has.
    >
    > And despite all the members being the same, the alignment of them is
    > different: a "__u64" has 4-byte alignment on x86-32, but native 8-byte
    > alignment on x86-64. And while 'NAME_MAX+1' ends up being a nice round
    > number (256), the name[] array starts out a 4-byte aligned.
    >
    > End result: the "packed" size of the structure is 300 bytes: 4-byte, but
    > not 8-byte aligned.
    >
    > As a result, despite all the fields being in the same place on all
    > architectures, sizeof() will round up that size to 304 bytes on
    > architectures that have 8-byte alignment for u64.
    >
    > Note that this is *not* a problem for 32-bit compat mode on POWER, since
    > there __u64 is 8-byte aligned even in 32-bit mode. But on x86, 32-bit
    > and 64-bit alignment is different for 64-bit entities, and as a result
    > the structure that has exactly the same layout has different sizes.
    >
    > So on x86-64, but no other architecture, we will just subtract 4 from
    > the size of the structure when running in a compat task. That way we
    > will write the properly sized packet that user mode expects.
    >
    > Not pretty. Sadly, this very subtle, and unnecessary, size difference
    > has been encoded in user space that wants to read packets of *exactly*
    > the right size, and will refuse to touch anything else.
    >
    > Reported-and-tested-by: Thomas Meyer <thomas@m3y3r.de>
    > Cc: Ian Kent <raven@themaw.net>
    > ---

    works for me on top of 3.2.7.




    \
     
     \ /
      Last update: 2012-02-25 12:31    [W:0.026 / U:90.828 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site