RE: [PATCH 1/3] aio: fix oops because of extra IO control block freeing.

[Ananiev, Leonid I]

ZB>If we really decide to remove EIOCBRETRY support we'd get rid of all
ZB>the retry infrastructure and remove the EIOCBRETRY errno so their
ZB>builds failed.

Originally EIOCBRETRY was used in fs/read_write.c for vector IO.
And EIOCBRETRY was deleted from it after.
Now EIOCBRETRY is used in drivers/usb/gadget/inode.c only. And the patch
2/3 proposes to set iocb flag instead of EIOCBRETRY errno in inode.c.
Agree that the name kiocbSetPgBusy() could be better chosen if
kiocbSetPgBusy() is just instead for vector IO. But why other than DIO
developers must continue using EIOCBRETRY? Thay could use the same way
as fs/read_write.c uses?

ZB> I was waiting for them to arrive before responding.
Sorry. I've listed "linux-kernel@xxxxxxxxxxxxxxx;
stern@xxxxxxxxxxxxxxxxxxx" in a single (that is incorrect) thunderbird
'To' line; I have got response from Stern; and thought that mailing was
OK.

ZB>- ext3_releasepage() returns failure if it races with kjournald
ZB>holding a reference while it waits for a transaction to commit.

The patch proposes iterative synchronization way to solve this problem.

ZB>- generic_file_direct_IO() causes an oops if it clobbers -EIOCBQUEUED
ZB>with the return code from invalidate_inode_pages2_range()..-
ZB>releasepage().

After patching invalidate_inode_pages2_range() does not change return
value.

ZB>This fix makes the incorrect assertion that *any* failure from
ZB>invalidate_inode_pages2_range(), which might not have anything to do
ZB>with this race you're currently seeing, is transitory and should
ZB>trigger a retry.  That's wrong, it should be returning the error.

Just patch makes to retry iocb if page is transitory busy for any
reason.
If busy -> do retry IO operation later.
We will get correct errno if mapping was deleted or retry success if
page is dirty or committed.

Leonid
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/