Re: 2.3.42 fs corruption

[Mike Galbraith]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [e-mail] for more info.

--432202577-713589950-949941170=:446
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 4 Feb 2000, Andrea Arcangeli wrote:

> I would be interested to know if people who experienced fs corruption with
> the late 2.3.x is able to reproduce after applying this patch on the top
> of 2.3.42:
> 
> 	ftp://ftp.*.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.3/2.3.42aa2.gz
> 
> The interesting bit is this:
> 
> 	ftp://ftp.*.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.3/2.3.42aa2/buffer-4.gz
> 
> I am now running under heavy fs/dentry load 2.3.42aa2 on alpha and I am
> waiting to reproduce. If you have hints on how to exploit the corruption
> your're welcome ;).

I know an excellent way to create corruption :)  Use the loop device
on an fs-in-a-box created with mke2fs -Fqb ${BLKSIZE} ${BOX} ${BLOCKS}.
What corruption happens is dependant on what blocksize the host fs is.
It gets more interesting when you use the same dirctory/file names on
two different fs with two different blocksizes.

Your buffer-4 fixed 99% of the trouble :) Replacing invalidate_buffers()
with destroy_buffers() got rid of the crumbs it was leaving around.

	-Mike

<sigh> P.S.
With the attached diag-diff, it almost works perfectly now.  (seems
to be a bit racy if you reuse too soon.  the hunk that seems likely
to make your facial expression change is why I'm attaching it.  I
really don't understand why it has to start with blocksize=PAGE_SIZE
to work right.. almost.. and hope some reader may know why:)

--432202577-713589950-949941170=:446
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=xx
Content-Transfer-Encoding: BASE64
Content-ID: <[e-mail]>
Content-Description: 
Content-Disposition: attachment; filename=xx

LS0tIGRyaXZlcnMvYmxvY2svbG9vcC5jLm9yZwlXZWQgRmViICAyIDA3OjE2
OjE1IDIwMDANCisrKyBkcml2ZXJzL2Jsb2NrL2xvb3AuYwlNb24gRmViICA3
IDE2OjM5OjEzIDIwMDANCkBAIC00MzUsNiArNDM1LDcgQEANCiAJbG8tPmxv
X2RlbnRyeSA9IGRnZXQoZmlsZS0+Zl9kZW50cnkpOw0KIAlsby0+dHJhbnNm
ZXIgPSBOVUxMOw0KIAlsby0+aW9jdGwgPSBOVUxMOw0KKwlzZXRfYmxvY2tz
aXplKE1LREVWKE1BSk9SX05SLGxvLT5sb19udW1iZXIpLCBQQUdFX1NJWkUp
Ow0KIAlmaWd1cmVfbG9vcF9zaXplKGxvKTsNCiANCiBvdXRfcHV0ZjoNCkBA
IC01MDYsNyArNTA3LDggQEANCiAJbWVtc2V0KGxvLT5sb19lbmNyeXB0X2tl
eSwgMCwgTE9fS0VZX1NJWkUpOw0KIAltZW1zZXQobG8tPmxvX25hbWUsIDAs
IExPX05BTUVfU0laRSk7DQogCWxvb3Bfc2l6ZXNbbG8tPmxvX251bWJlcl0g
PSAwOw0KLQlpbnZhbGlkYXRlX2J1ZmZlcnMoZGV2KTsNCisJbG9vcF9ibGtz
aXplc1tsby0+bG9fbnVtYmVyXSA9IDA7DQorCWRlc3Ryb3lfYnVmZmVycyhk
ZXYpOw0KIAlNT0RfREVDX1VTRV9DT1VOVDsNCiAJcmV0dXJuIDA7DQogfQ0K
QEAgLTc1NywxMCArNzU5LDEwIEBADQogCX0NCiAJbWVtc2V0KGxvb3Bfc2l6
ZXMsIDAsIG1heF9sb29wICogc2l6ZW9mKGludCkpOw0KIAltZW1zZXQobG9v
cF9ibGtzaXplcywgMCwgbWF4X2xvb3AgKiBzaXplb2YoaW50KSk7DQotCWJs
a19zaXplW01BSk9SX05SXSA9IGxvb3Bfc2l6ZXM7DQogCWJsa3NpemVfc2l6
ZVtNQUpPUl9OUl0gPSBsb29wX2Jsa3NpemVzOw0KIAlmb3IgKGk9MDsgaSA8
IG1heF9sb29wOyBpKyspDQogCQlyZWdpc3Rlcl9kaXNrKE5VTEwsIE1LREVW
KE1BSk9SX05SLGkpLCAxLCAmbG9fZm9wcywgMCk7DQorCWJsa19zaXplW01B
Sk9SX05SXSA9IGxvb3Bfc2l6ZXM7DQogDQogCXJldHVybiAwOw0KIH0NCkBA
IC03NzEsNiArNzczLDkgQEANCiAJaWYgKHVucmVnaXN0ZXJfYmxrZGV2KE1B
Sk9SX05SLCAibG9vcCIpICE9IDApDQogCQlwcmludGsoS0VSTl9XQVJOSU5H
ICJsb29wOiBjYW5ub3QgdW5yZWdpc3RlciBibGtkZXZcbiIpOw0KIA0KKwli
bGtzaXplX3NpemVbTUFKT1JfTlJdID0gTlVMTDsNCisJYmxrX3NpemVbTUFK
T1JfTlJdID0gTlVMTDsNCisNCiAJa2ZyZWUgKGxvb3BfZGV2KTsNCiAJa2Zy
ZWUgKGxvb3Bfc2l6ZXMpOw0KIAlrZnJlZSAobG9vcF9ibGtzaXplcyk7DQo=
--432202577-713589950-949941170=:446--