linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ian Kent <raven@themaw.net>
To: Christoph Hellwig <hch@infradead.org>
Cc: Andrew Morton <akpm@osdl.org>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	autofs mailing list <autofs@linux.kernel.org>
Subject: Re: [PATCH] autofs4 - fix comms packet struct size
Date: Mon, 20 Feb 2006 09:05:59 +0800 (WST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0602200856300.2355@eagle.themaw.net> (raw)
In-Reply-To: <20060219141517.GA7942@infradead.org>

On Sun, 19 Feb 2006, Christoph Hellwig wrote:

> On Sun, Feb 19, 2006 at 10:11:31PM +0800, Ian Kent wrote:
> > 
> > Set userspace communication struct fields to fixed size.
> > 
> > Signed-off-by: Ian Kent <raven@themaw.net>
> > 
> > --- linux-2.6.16-rc3-mm1/include/linux/auto_fs4.h.fix-v5-packet-size	2006-02-17 19:15:49.000000000 +0800
> > +++ linux-2.6.16-rc3-mm1/include/linux/auto_fs4.h	2006-02-17 19:12:09.000000000 +0800
> > @@ -65,10 +65,10 @@ struct autofs_v5_packet {
> >  	autofs_wqt_t wait_queue_token;
> 
> Hiding types in user visible structures behind typedefs is bad.
> What type is behind this?  If this is not an __u32 you have
> a padding issue.

This has been an occassion problem for a long time.
Since it dates back to way before version 4 I have always been reluctant 
to change it. I'd rather leave it as is unless you really can't accept it.

> 
> >  	__u32 dev;
> >  	__u64 ino;
> > -	uid_t uid;
> > -	gid_t gid;
> > -	pid_t pid;
> > -	pid_t tgid;
> > +	__u64 uid;
> > +	__u64 gid;
> > +	__u64 pid;
> > +	__u64 tgid;
> 
> These should be 32bit values.

OK. But will they be 32 bit for the life of this struct?

Once userspace programs are using this it can't ever change.

> 
> >  	int len;
> 
> this should become a fixed-size type aswell.

OK. That shouldn't cause a problem. I'll change that also.

> 
> >  	char name[NAME_MAX+1];
> >  };
> > --- linux-2.6.16-rc3-mm1/fs/autofs4/autofs_i.h.fix-v5-packet-size	2006-02-17 19:17:03.000000000 +0800
> > +++ linux-2.6.16-rc3-mm1/fs/autofs4/autofs_i.h	2006-02-17 19:17:25.000000000 +0800
> > @@ -79,10 +79,10 @@ struct autofs_wait_queue {
> >  	char *name;
> >  	u32 dev;
> >  	u64 ino;
> > -	uid_t uid;
> > -	gid_t gid;
> > -	pid_t pid;
> > -	pid_t tgid;
> > +	u64 uid;
> > +	u64 gid;
> > +	u64 pid;
> > +	u64 tgid;
> >  	/* This is for status reporting upon return */
> >  	int status;
> >  	atomic_t notified;
> 
> This is an in-kernel structure, isn't it?  No need to use u64 here.

Yes, I was thinking the same thing when I did it.
I'll fix that.

Thanks Christoph.

Ian


  reply	other threads:[~2006-02-20  1:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-19 14:11 [PATCH] autofs4 - fix comms packet struct size Ian Kent
2006-02-19 14:15 ` Christoph Hellwig
2006-02-20  1:05   ` Ian Kent [this message]
2006-02-20 16:00     ` Christoph Hellwig

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=Pine.LNX.4.64.0602200856300.2355@eagle.themaw.net \
    --to=raven@themaw.net \
    --cc=akpm@osdl.org \
    --cc=autofs@linux.kernel.org \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).