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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.