From: Jim Rees <rees@umich.edu>
To: Jeff Layton <jlayton@redhat.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: shouldn't rpc_pipe_upcall message structs be __attribute__((packed)) ?
Date: Fri, 9 Sep 2011 18:03:12 -0400 [thread overview]
Message-ID: <20110909220312.GA22084@merit.edu> (raw)
In-Reply-To: <20110909171654.3ae6b513@tlielax.poochiereds.net>
Jeff Layton wrote:
On Fri, 9 Sep 2011 15:56:15 -0400
Jim Rees <rees@umich.edu> wrote:
> Jeff Layton wrote:
>
> The blocklayout upcall is even more scary as the width of the status
> field is not explicit:
>
> struct bl_dev_msg {
> int status;
> uint32_t major, minor;
> };
>
> I'll take the blame for that one. I will queue up a fix.
>
> Making the blocklayout upcall struct packed might still be possible since
> it's not officially released until 3.1, but I'm terrified of making changes
> at this point in the release cycle that aren't actual bug fixes.
Thanks, though I guess I also should take some of the blame for not
reviewing and noticing this earlier...
I'd personally call this a bug, and one that's particularly important
to fix sooner rather than later. Changing this will mean ABI breakage
any way you look at it. I think it would be better to go through that
pain now before anyone is really relying on that code.
I'll go with whatever Trond thinks is best (not to shirk the responsibility,
but he's better able to assess the risks than I). Should I send a patch?
It needs to be coordinated with nfs-utils, but that hasn't been released yet
either.
Would packing this struct actually change the layout on either x86 or
x86_64?
While we're looking at this...do we also need to worry about endianness
here? Is it possible we'd ever end up running BE upcall code on a LE
kernel (or vice versa) in some sort of horrid compat mode? If so, it
might be worthwhile to consider making both those fields __be32 or
something and fixing the code to handle that properly as well.
If we're going to go to that much trouble, I think I would ditch the binary
and go with text. The upcall for block layout is not in a performance
critical path.
next prev parent reply other threads:[~2011-09-09 22:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-09 18:36 shouldn't rpc_pipe_upcall message structs be __attribute__((packed)) ? Jeff Layton
2011-09-09 19:56 ` Jim Rees
2011-09-09 21:16 ` Jeff Layton
2011-09-09 22:03 ` Jim Rees [this message]
2011-09-09 22:32 ` Trond Myklebust
2011-09-10 0:14 ` Jeff Layton
2011-09-09 20:03 ` J. Bruce Fields
2011-09-09 21:05 ` Jeff Layton
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=20110909220312.GA22084@merit.edu \
--to=rees@umich.edu \
--cc=jlayton@redhat.com \
--cc=linux-nfs@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).