...... It's a zero length range, not a negative value. A debug XFS would have assert failed on it, but it was completely unchecked on production builds. The following patch checks the length of block
On Wed, Jan 21, 2009 at 03:03:06PM +1100, Nick Piggin wrote: On Wednesday 21 January 2009 14:57:03 Dave Chinner wrote: [ 235.250167] --[ cut here ]-- [ 235.250354] kernel BUG at mm/vmalloc.c:164! [
Any reason for reanming this variable? That causes quite a bit of churn. And doesn't prevent this line from needing a linebreak to stay under 80 characters :) Except for these nitpicks it looks fine
Using the image at http://www.cccmz.de/~snakebyte/xfs.254.img.bz2 I was able to produce a pretty similar error with the patch applied [ 227.138277] XFS mounting filesystem loop0 [ 227.142703] --[ cut
Just so it was the same variable name as the other I/O functions around it. It's kind of strange to have one function use num_bblks and another 4 or so related functions use nbblks.... I'll respin it
And now with line breaks. -- [XFS] Check buffer lengths in log recovery Before trying to obtain, read or write a buffer, check that the buffer length is actually valid. If it is not valid, then somet
One word: Ouch. Basically the corruption introduced adds random feature bits into the superblock that aren't actually in use. And hence instead of having valid superblock fields for each of those fea
[XFS] Check buffer lengths in log recovery Before trying to obtain, read or write a buffer, check that the buffer length is actually valid. If it is not valid, then something read in the recovery pr