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    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site