lkml.org 
[lkml]   [2012]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: compat: autofs v5 packet size ambiguity - update
    On Wed, Feb 22, 2012 at 4:45 AM, Ian Kent <raven@themaw.net> wrote:
    > diff --git a/fs/autofs4/dev-ioctl.c b/fs/autofs4/dev-ioctl.c
    > index 76741d8..85f1fcd 100644
    > --- a/fs/autofs4/dev-ioctl.c
    > +++ b/fs/autofs4/dev-ioctl.c
    > @@ -385,6 +385,7 @@ static int autofs_dev_ioctl_setpipefd(struct file *fp,
    >                sbi->pipefd = pipefd;
    >                sbi->pipe = pipe;
    >                sbi->catatonic = 0;
    > +               sbi->compat_daemon = is_compat_task();
    >        }
    >  out:
    >        mutex_unlock(&sbi->wq_mutex);

    Yes, this part should do the reconnect correctly (assuming it's the
    daemon that does that itself, but I assume it is).

    But

    > diff --git a/fs/autofs4/inode.c b/fs/autofs4/inode.c
    > index e16980b..06858d9 100644
    > --- a/fs/autofs4/inode.c
    > +++ b/fs/autofs4/inode.c
    > @@ -224,6 +225,7 @@ int autofs4_fill_super(struct super_block *s, void *data, int silent)
    >        set_autofs_type_indirect(&sbi->type);
    >        sbi->min_proto = 0;
    >        sbi->max_proto = 0;
    > +       sbi->compat_daemon = is_compat_task();
    >        mutex_init(&sbi->wq_mutex);
    >        mutex_init(&sbi->pipe_mutex);
    >        spin_lock_init(&sbi->fs_lock);

    the above really is wrong, at least for the autofs sources I looked at.

    Because autofs does "spawn()" to fork+exec the mount() system call,
    the is_compat_task() check really will be checking the wrong binary.

    Now, it's true that in *most* cases you'd hope that 'mount' and
    'autofs' both come from the same distro, and have been the compiled
    for the same model. So it probably works in practice, and might be
    good enough.

    But I could easily see somebody building their own 'autofs' tools (or
    building their own 'mount', although that sounds less likely to me)
    and if they started out with a 32-bit distro but are slowly upgrading
    (like they've upgraded the kernel) the above would get that wrong.

    I could also imagine a 64-bit environment wanting to "cross" compile
    (and test) a 32-bit binary, and trying that. In fact, I suspect that
    is something that you could test yourself: I assume you build your own
    'autofs' daemon on a system where you don't build everything else, and
    just adding "-m32" to the build should do this and show the problem.

    Linus
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2012-02-22 17:23    [W:4.210 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site