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@vger.kernel.org; [EMAIL PROTECTED]" 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
