At Snap Appliance, we were running into appeared to be random oops
when setting/reading large attributes. Trevor Heathorn was able to
trace the problem down to the function xfs_buf_iomove() in linux-2.6-
xfs/xfs_buf.c. The size of the copy within the loop is calculated as
a minimum of the page size and bp->b_count_desired, minus the
applicable offsets. This can result in a copy size greater than the
remaining size of the data length, which in the case of a read caused
whatever else is in the buffer to be written past the end of the data
area we had allocated. He found that this fix prevented the oops:
--- xfs_buf.c 17 Sep 2009 00:19:49 -0000 1.4
+++ xfs_buf.c 31 Jan 2011 20:22:59 -0000 1.5
@@ -1313,6 +1313,7 @@
PAGE_CACHE_SIZE-cpoff, bp->b_count_desired-boff);
ASSERT(((csize + cpoff) <= PAGE_CACHE_SIZE));
+ csize = min(csize, (bend - boff));
switch (mode) {
case XBRW_ZERO:
This fix also keeps the write from copying past the end of the buffer,
though at least in that case it won't be written to unallocated
memory. It also may keep the zero from zeroing to the end of the
buffer if the bsize passed in doesn't justify it, though I'm not sure
if there are any callers of this function that do not want it zeroed
to the end.
Dale J. Stephenson
dstephenson@xxxxxxxxxxxxxxxxxxx
dalestephenson@xxxxxxx
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
