From: Andrew Morton <akpm@linux-foundation.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: brm-EoLPgbz1DBzQT0dZR+AlfA@public.gmane.org,
bugme-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org,
okir@suse.de, linux-nfs@vger.kernel.org, stable@kernel.org
Subject: Re: [Bugme-new] [Bug 12995] New: NFS mount from avr32 platform crashes on 2.6.29
Date: Wed, 1 Apr 2009 13:46:27 -0700 [thread overview]
Message-ID: <20090401134627.cb950b07.akpm@linux-foundation.org> (raw)
In-Reply-To: <EB32620C-ECA2-490E-A07D-72F0900EBC35@oracle.com>
On Wed, 1 Apr 2009 16:34:53 -0400
Chuck Lever <chuck.lever@oracle.com> wrote:
> On Apr 1, 2009, at 4:07 PM, Andrew Morton wrote:
> > (cc stable)
> >
> > On Wed, 1 Apr 2009 15:50:51 -0400
> > Chuck Lever <chuck.lever@oracle.com> wrote:
> >
> >>>>
> >>>> Perhaps the solution is to malloc the nsm_private data and sm_priv
> >>>> is then a
> >>>> pointer to this data. This would guarantee the correct alignment.
> >>>>
> >>>
> >>> nsm_private is:
> >>>
> >>> struct nsm_private {
> >>> unsigned char data[SM_PRIV_SIZE];
> >>> };
> >>>
> >>> so the compiler is permitted to byte-align this.
> >>>
> >>> I assume that some code somewhere is accessing this with a
> >>> larger-than-one-byte typecast?
> >>
> >> nsm_init_private().
> >>
> >> A patch just went upstream for 2.6.30 that addresses that
> >
> > commit ad5b365c1266b0c9e8e254a3c1cc4ef66bf33cba
> > Author: Mans Rullgard <mans-2StjZFpD7GcAvxtiuMwx3w@public.gmane.org>
> > AuthorDate: Sat Mar 28 19:55:20 2009 +0000
> > Commit: Trond Myklebust <Trond.Myklebust@netapp.com>
> > CommitDate: Wed Apr 1 13:24:14 2009 -0400
> >
> > NSM: Fix unaligned accesses in nsm_init_private()
> >
> > This fixes unaligned accesses in nsm_init_private() when
> > creating nlm_reboot keys.
> >
> > Signed-off-by: Mans Rullgard <mans-2StjZFpD7GcAvxtiuMwx3w@public.gmane.org>
> > Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
> > Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
> >
> > diff --git a/fs/lockd/mon.c b/fs/lockd/mon.c
> > index 5e2c4d5..6d5d4a4 100644
> > --- a/fs/lockd/mon.c
> > +++ b/fs/lockd/mon.c
> > @@ -16,6 +16,8 @@
> > #include <linux/sunrpc/svc.h>
> > #include <linux/lockd/lockd.h>
> >
> > +#include <asm/unaligned.h>
> > +
> > #define NLMDBG_FACILITY NLMDBG_MONITOR
> > #define NSM_PROGRAM 100024
> > #define NSM_VERSION 1
> > @@ -274,10 +276,12 @@ static void nsm_init_private(struct nsm_handle
> > *nsm)
> > {
> > u64 *p = (u64 *)&nsm->sm_priv.data;
> > struct timespec ts;
> > + s64 ns;
> >
> > ktime_get_ts(&ts);
> > - *p++ = timespec_to_ns(&ts);
> > - *p = (unsigned long)nsm;
> > + ns = timespec_to_ns(&ts);
> > + put_unaligned(ns, p);
> > + put_unaligned((unsigned long)nsm, p + 1);
> > }
> >
> > static struct nsm_handle *nsm_create_handle(const struct sockaddr
> > *sap,
> >
> > Is this the best way of fixing it? We'll crash again if some other
> > code starts to access .data with non-byte-sized accesses. What makes
> > this especially risky is that the code will pass testing on x86.
> >
> > __aligned would be one way. But it would be far far cleaner to just
> > do
> >
> >
> > --- a/include/linux/lockd/xdr.h~a
> > +++ a/include/linux/lockd/xdr.h
> > @@ -17,7 +17,7 @@
> > #define SM_PRIV_SIZE 16
> >
> > struct nsm_private {
> > - unsigned char data[SM_PRIV_SIZE];
> > + u64 data[SM_PRIV_SIZE/sizeof(u64)];
> > };
> >
> > struct svc_rqst;
> >
> > all the typecasting and the put_unaligned()s just go away then.
>
> True enough. It should be noted, however, that opaque data types are
> defined as character arrays in most RPC implementations, and by
> automated code generators like rpcgen. The size of an RPC opaque type
> is usually expressed by a number of octets.
>
> In general it may be best to keep that tradition (due to a large body
> of legacy code) and always use __aligned, simply because that clearly
> documents the problem that is being fixed.
>
struct nsm_private {
union {
unsigned char data[SM_PRIV_SIZE];
u64 aligned_data[SM_PRIV_SIZE/sizeof(u64)];
};
};
:)
next prev parent reply other threads:[~2009-04-01 20:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-12995-10286@http.bugzilla.kernel.org/>
[not found] ` <bug-12995-10286-V0hAGp6uBxO456/isadD/XN4h3HLQggn@public.gmane.org/>
2009-04-01 19:41 ` [Bugme-new] [Bug 12995] New: NFS mount from avr32 platform crashes on 2.6.29 Andrew Morton
2009-04-01 19:50 ` Chuck Lever
2009-04-01 20:07 ` Andrew Morton
2009-04-01 20:34 ` Chuck Lever
2009-04-01 20:46 ` Andrew Morton [this message]
2009-04-02 7:48 ` Brian Murphy
[not found] ` <49D46DBD.508-EoLPgbz1DBzQT0dZR+AlfA@public.gmane.org>
2009-04-02 17:04 ` Chuck Lever
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=20090401134627.cb950b07.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=brm-EoLPgbz1DBzQT0dZR+AlfA@public.gmane.org \
--cc=bugme-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=okir@suse.de \
--cc=stable@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