Messages in this thread |  | | Subject | RE: [PATCH] aio: fix kernel bug when page is temporally busy | Date | Thu, 15 Feb 2007 22:11:15 +0300 | From | "Ananiev, Leonid I" <> |
| |
> It returns -EIOCBRETRY without guaranteeing that kick_iocb() will be > called. This can lead to operations hanging
If EIOCBRETRY then generic_file_aio_write() will be recalled for the same iocb.
> It overwrites -EIOCBQUEUED, leading to an aio_complete() while a > retry is happening.
EIOCBQUEUED or EIOCBRETRY does not lead to aio_complete() call: if (ret != -EIOCBRETRY && ret != -EIOCBQUEUED) { aio_complete(iocb, ret, 0);
> This can lead to reference count confusion. But just reference count confusion was deleted by patch. Isn't it?
Leonid
-----Original Message----- From: Zach Brown [mailto:zach.brown@oracle.com] Sent: Thursday, February 15, 2007 9:25 PM To: Ananiev, Leonid I Cc: Ken Chen; suparna@in.ibm.com; Andrew Morton; linux-kernel@vger.kernel.org; linux-aio; Chris Mason Subject: Re: [PATCH] aio: fix kernel bug when page is temporally busy
> If invalidate_inode_pages2_range() will return EIOCBRETRY as the patch > "aio: fix kernel bug when page is temporally busy"
Sorry Leonid, this patch is not safe.
It returns -EIOCBRETRY without guaranteeing that kick_iocb() will be called. This can lead to operations hanging, both AIO and calls that come through do_sync_{read,write}.
It overwrites -EIOCBQUEUED, leading to an aio_complete() while a retry is happening. This can lead to reference count confusion. Double-frees, referencing freed memory, that kind of thing. This isn't a new problem. The current code that overwrites with -EIO has this problem. But moving to -EIOCBRETRY does introduce new behaviour of aio_complete() and the retry path racing.
I'll have a candidate patch to address the problem of EIO being raised on the way back up from a path which has returned -EIOCBQUEUED.
- z - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |