From: Andrew Morton <akpm@linux-foundation.org>
To: Daniel Walker <dwalker@mvista.com>
Cc: rostedt@goodmis.org, linux-kernel@vger.kernel.org,
lucho@ionkov.net, ericvh@gmail.com
Subject: Re: [PATCH] fix flags length in net 9p
Date: Thu, 1 May 2008 15:07:37 -0700 [thread overview]
Message-ID: <20080501150737.3400dffb.akpm@linux-foundation.org> (raw)
In-Reply-To: <1209677160.12461.267.camel@localhost.localdomain>
On Thu, 01 May 2008 14:26:00 -0700
Daniel Walker <dwalker@mvista.com> wrote:
>
> On Thu, 2008-05-01 at 14:19 -0700, Andrew Morton wrote:
> > On Thu, 1 May 2008 17:08:05 -0400 (EDT)
> > Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > > Some files in the net/9p directory uses "int" for flags. This can
> > > cause hard to find bugs on some architectures. This patch converts the
> > > flags to use "long" instead.
> >
> > gargh.
> >
> > > This bug was discovered by doing an allyesconfig make on the -rt kernel
> > > where checks are done to ensure all flags are of size sizeof(long).
> >
> > I was about to suggest that we do something like that...
> >
> > I wonder how messy it is. I long ago lost the ability to follow the
> > convolutions in include/linux/spinlock*.h :( gotta patch?
>
> The check that's in -rt for this uses BUILD_BUG_ON(), and it's extremely
> cryptic when there is a failure .. Most people will be baffled why the
> build stopped. If a check went into mainline it should at least give you
> some sort of idea what's happening ..
>
I think a warning is good enough here. There are all sorts of warnings if,
which ignored, will crash your box.
And there is only one type which we use to hold processor flags and that is
unsigned long.
So a plain old
#define must_be_ulong(p)
do {
if (&p == (unsigned long *)0)
;
} while (0)
(or whatever)
should suffice.
next prev parent reply other threads:[~2008-05-01 22:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-01 21:08 Steven Rostedt
2008-05-01 21:19 ` Andrew Morton
2008-05-01 21:25 ` Steven Rostedt
2008-05-01 21:26 ` Daniel Walker
2008-05-01 21:38 ` Steven Rostedt
2008-05-01 21:41 ` Adrian Bunk
2008-05-01 22:01 ` Daniel Walker
2008-05-01 22:07 ` Andrew Morton [this message]
2008-05-01 22:32 ` Alexey Dobriyan
2008-05-01 21:46 ` Steven Rostedt
2008-05-01 22:29 ` Alexey Dobriyan
2008-05-01 21:50 ` Steven Rostedt
2008-05-01 22:15 ` Andrew Morton
2008-05-01 22:03 ` Christoph Hellwig
2008-05-02 11:39 ` Enrico Weigelt
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=20080501150737.3400dffb.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=dwalker@mvista.com \
--cc=ericvh@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lucho@ionkov.net \
--cc=rostedt@goodmis.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
Powered by JetHome