LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Neil Brown <neilb@suse.de>
To: "Dan Williams" <dan.j.williams@gmail.com>
Cc: "Chuck Ebbert" <cebbert@redhat.com>,
	"Justin Piszcz" <jpiszcz@lucidpixels.com>,
	linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org,
	xfs@oss.sgi.com
Subject: Re: Kernel 2.6.19.2 New RAID 5 Bug (oops when writing Samba -> RAID5)
Date: Tue, 23 Jan 2007 13:06:40 +1100	[thread overview]
Message-ID: <17845.28080.887134.987438@notabene.brown> (raw)
In-Reply-To: message from Dan Williams on Monday January 22

On Monday January 22, dan.j.williams@gmail.com wrote:
> On 1/22/07, Neil Brown <neilb@suse.de> wrote:
> > On Monday January 22, cebbert@redhat.com wrote:
> > > Justin Piszcz wrote:
> > > > My .config is attached, please let me know if any other information is
> > > > needed and please CC (lkml) as I am not on the list, thanks!
> > > >
> > > > Running Kernel 2.6.19.2 on a MD RAID5 volume.  Copying files over Samba to
> > > > the RAID5 running XFS.
> > > >
> > > > Any idea what happened here?
> > ....
> > > >
> > > Without digging too deeply, I'd say you've hit the same bug Sami Farin
> > > and others
> > > have reported starting with 2.6.19: pages mapped with kmap_atomic()
> > > become unmapped
> > > during memcpy() or similar operations.  Try disabling preempt -- that
> > > seems to be the
> > > common factor.
> >
> > That is exactly the conclusion I had just come to (a kmap_atomic page
> > must be being unmapped during memcpy).  I wasn't aware that others had
> > reported it - thanks for that.
> >
> > Turning off CONFIG_PREEMPT certainly seems like a good idea.
> >
> Coming from an ARM background I am not yet versed in the inner
> workings of kmap_atomic, but if you have time for a question I am
> curious as to why spin_lock(&sh->lock)  is not sufficient pre-emption
> protection for copy_data() in this case?
> 

Presumably there is a bug somewhere.
kmap_atomic itself calls inc_preempt_count so that preemption should
be disabled at least until the kunmap_atomic is called.

But apparently not.  The symptoms point exactly to the page getting
unmapped when it shouldn't.  Until that bug is found and fixed, the
work around of turning of CONFIG_PREEMPT seems to make sense.

Of course it would be great if someone who can easily reproduce this
bug could do the 'git bisect' thing to find out where the bug crept
in.....

NeilBrown

  reply	other threads:[~2007-01-23  2:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-20 12:23 Justin Piszcz
2007-01-20 12:46 ` Justin Piszcz
2007-01-22 21:01 ` Chuck Ebbert
2007-01-22 21:59   ` Neil Brown
2007-01-23  1:44     ` Dan Williams
2007-01-23  2:06       ` Neil Brown [this message]
2007-01-23 10:56     ` Justin Piszcz
2007-01-23 11:08       ` Michael Tokarev
2007-01-23 11:59         ` Justin Piszcz
2007-01-23 12:48           ` Michael Tokarev
2007-01-23 13:46             ` Justin Piszcz
2007-01-24 23:37   ` Justin Piszcz
2007-01-26  9:25     ` Andrew Morton
2007-01-26  9:37       ` Justin Piszcz
2007-01-26 12:31       ` Justin Piszcz

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=17845.28080.887134.987438@notabene.brown \
    --to=neilb@suse.de \
    --cc=cebbert@redhat.com \
    --cc=dan.j.williams@gmail.com \
    --cc=jpiszcz@lucidpixels.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=xfs@oss.sgi.com \
    --subject='Re: Kernel 2.6.19.2 New RAID 5 Bug (oops when writing Samba -> RAID5)' \
    /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

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).