[Top] [All Lists]

Re: Kernel New RAID 5 Bug (oops when writing Samba -> RAID5)

To: "Neil Brown" <neilb@xxxxxxx>
Subject: Re: Kernel New RAID 5 Bug (oops when writing Samba -> RAID5)
From: "Dan Williams" <dan.j.williams@xxxxxxxxx>
Date: Mon, 22 Jan 2007 18:44:11 -0700
Cc: "Chuck Ebbert" <cebbert@xxxxxxxxxx>, "Justin Piszcz" <jpiszcz@xxxxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, linux-raid@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YyPyqkif8t9RDwskczse5LiMPC6QKh4KCunEEhev/m5UCY6L5HrffWLTZehiTS+g+69dBURTq5ETIaxomAk3IZaO/Z7eLSL6b7LTpIht17I1Lz5JK1bBBf98/M1UmgCo8w1SlEo0m3bpFLmYGIZD6/+3fGqcNwCg+FIN+cNCeM4=
In-reply-to: <17845.13256.284461.992275@xxxxxxxxxxxxxx>
References: <Pine.LNX.4.64.0701200718290.29223@xxxxxxxxxxxxxxxx> <45B5261B.1050104@xxxxxxxxxx> <17845.13256.284461.992275@xxxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
On 1/22/07, Neil Brown <neilb@xxxxxxx> wrote:
On Monday January 22, cebbert@xxxxxxxxxx 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 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?



<Prev in Thread] Current Thread [Next in Thread>