From: Andrew Morton <akpm@linux-foundation.org>
To: brm-EoLPgbz1DBzQT0dZR+AlfA@public.gmane.org
Cc: bugme-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org,
Chuck Lever <chuck.lever@oracle.com>, Olaf Kirch <okir@suse.de>,
linux-nfs@vger.kernel.org
Subject: Re: [Bugme-new] [Bug 12995] New: NFS mount from avr32 platform crashes on 2.6.29
Date: Wed, 1 Apr 2009 12:41:13 -0700 [thread overview]
Message-ID: <20090401124113.9026ea09.akpm@linux-foundation.org> (raw)
In-Reply-To: <bug-12995-10286-V0hAGp6uBxO456/isadD/XN4h3HLQggn@public.gmane.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Wed, 1 Apr 2009 12:31:51 GMT
bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=12995
>
> Summary: NFS mount from avr32 platform crashes on 2.6.29
> Product: File System
> Version: 2.5
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: NFS
> AssignedTo: trond.myklebust@fys.uio.no
> ReportedBy: brm-EoLPgbz1DBzQT0dZR+AlfA@public.gmane.org
> Regression: No
>
>
> The problem turns out to be in the recent(ish) changes in lockd.
>
> Specifically this struct definition
>
> struct nsm_handle {
> struct list_head sm_link;
> atomic_t sm_count;
> char *sm_mon_name;
> char *sm_name;
> struct sockaddr_storage sm_addr;
> size_t sm_addrlen;
> unsigned int sm_monitored : 1,
> sm_sticky : 1; /* don't unmonitor */
> struct nsm_private sm_priv;
> char sm_addrbuf[NSM_ADDRBUF];
> };
>
> results in my avr32 compiler (and my ia64 compiler) in aligning the sm_priv
> structure (which is a char array) on an odd boundary. The subsequent use
> of this field typecast to a u64 (nsm_init_private) as part of an nfs mount
> causes a crash with unaligned access.
>
> The compiler only allocates *one byte* to the two bit bitfield.
> Moving the bitfield to the end of the structure fixes the problem in my case.
> It seems to me that one should be very careful with typecasting this sm_priv
> data to anything with larger alignment but especially to a 64 bit type since
> (at least on a 64 bit system) this may demand 64 bit alignment.
>
> In any case it looks like (with newer gcc at least) that bitfields are
> extremely dangerous.
>
> 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?
(Your bug report isn't complete - if it had included the trace then I'd
know where the crash is occurring!)
If so then something like this:
--- a/include/linux/lockd/xdr.h~a
+++ a/include/linux/lockd/xdr.h
@@ -9,6 +9,7 @@
#ifndef LOCKD_XDR_H
#define LOCKD_XDR_H
+#include <linux/compiler.h>
#include <linux/fs.h>
#include <linux/nfs.h>
#include <linux/sunrpc/xdr.h>
@@ -16,9 +17,10 @@
#define SM_MAXSTRLEN 1024
#define SM_PRIV_SIZE 16
+/* suitable comment about the __aligned goes here */
struct nsm_private {
unsigned char data[SM_PRIV_SIZE];
-};
+} __aligned(sizeof(unsigned long));
struct svc_rqst;
would be an appropriate fix, as it actually expresses what's going on.
If you agree then please cook up and test a patch?
Please send the patch via email - we very much try to avoid merging
patches out of bugzilla.
Thanks.
next parent reply other threads:[~2009-04-01 19:44 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 ` Andrew Morton [this message]
2009-04-01 19:50 ` [Bugme-new] [Bug 12995] New: NFS mount from avr32 platform crashes on 2.6.29 Chuck Lever
2009-04-01 20:07 ` Andrew Morton
2009-04-01 20:34 ` Chuck Lever
2009-04-01 20:46 ` Andrew Morton
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=20090401124113.9026ea09.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 \
/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.