The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Ian Kent <raven@themaw.net>
To: Pavel Emelyanov <xemul@openvz.org>
Cc: autofs mailing list <autofs@linux.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Konstantin Khlebnikov <khlebnikov@openvz.org>
Subject: Re: [PATCH] autofs4: fix 32-bit userspace vs 64-bit kernel	communications
Date: Wed, 11 Jun 2008 21:15:00 +0800	[thread overview]
Message-ID: <1213190100.4994.54.camel@raven.themaw.net> (raw)
In-Reply-To: <484FC94E.1000209@openvz.org>


On Wed, 2008-06-11 at 16:47 +0400, Pavel Emelyanov wrote:
> Ian Kent wrote:
> > On Wed, 2008-06-11 at 13:54 +0400, Pavel Emelyanov wrote:
> >> From: Konstantin Khlebnikov <khlebnikov@openvz.org>
> >>
> >> The struct autofs_v5_packet has only one difference between
> >> 32-bit and 64-bit versions - on 64-bit gcc aligns its size and
> >> it is 4 bytes larger that it is on 32-bit kernel. This confuses
> >> 32-bit user-space daemon, when talking to 64-bit kernel.
> > 
> > No, I don't think that's quite right.
> > 
> > As far as I know this issue arises when a user space program, compiled
> > as a 32-bit application is executed within 64-bit user space.
> 
> What program do mean here? The problem arises right on the kernel-daemon
> boundary - the latter refuses to accept the message with larger length.
> No other software required.
> 
> >> This is very critical for containerized setups, when containers
> >> with <different>-bit tolls are used.
> > 
> > Have you tested different situations with this change?
> > Will this affect the existing check and adjustment the version 5
> > automount daemon does now?
> 
> 64-bit daemons *still* work OK and 32-bit *start* to after this fix :)
> 
> >> Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
> >> Acked-by: Pavel Emelyanov <xemul@openvz.org>
> >>
> >> ---
> >>
> >> diff --git a/fs/autofs4/waitq.c b/fs/autofs4/waitq.c
> >> index 1e4a539..9855b6e 100644
> >> --- a/fs/autofs4/waitq.c
> >> +++ b/fs/autofs4/waitq.c
> >> @@ -132,6 +132,14 @@ static void autofs4_notify_daemon(struct autofs_sb_info *sbi,
> >>  		struct autofs_v5_packet *packet = &pkt.v5_pkt.v5_packet;
> >>  
> >>  		pktsz = sizeof(*packet);
> >> +#if defined(CONFIG_X86_64) && defined(CONFIG_IA32_EMULATION)

Oh .. so maybe the answer to my question is yes?

What about other arches offer 32-bit within a 64-bit environment (has
this been the case on sparc64 at some point)?
What about the compiler padding on these?

Don't get me wrong, I'm not against fixing this, in fact I'd like to,
but I'm concerned it may end up a bit of a can of worms.

> >> +		/*
> >> +		 * On x86_64 autofs_v5_packet struct is padded with 4 bytes
> >> +		 * which breaks 32-bit autofs daemon.
> >> +		 */
> >> +		if (test_thread_flag(TIF_IA32))
> >> +			pktsz -= 4;
> >> +#endif
> >>  
> >>  		packet->wait_queue_token = wq->wait_queue_token;
> >>  		packet->len = wq->len;
> >>
> > 
> > --
> > 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/
> > 
> 


  parent reply	other threads:[~2008-06-11 13:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-11  9:54 [PATCH] autofs4: fix 32-bit userspace vs 64-bit kernel communications Pavel Emelyanov
2008-06-11 12:32 ` Ian Kent
2008-06-11 12:47   ` Pavel Emelyanov
2008-06-11 13:08     ` Ian Kent
2008-06-11 13:15     ` Ian Kent [this message]
2008-06-11 13:25       ` Pavel Emelyanov
2008-06-11 13:40         ` Ian Kent
2008-06-11 14:29       ` Mikael Pettersson
2008-06-12  2:52         ` Ian Kent

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1213190100.4994.54.camel@raven.themaw.net \
    --to=raven@themaw.net \
    --cc=autofs@linux.kernel.org \
    --cc=khlebnikov@openvz.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xemul@openvz.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox