On Thu, Mar 02, 2017 at 11:38:45AM +0100, Jan Kara wrote: > On Wed 01-03-17 07:38:57, Christoph Hellwig wrote: > > On Tue, Feb 28, 2017 at 07:46:06PM -0800, Matthew Wilcox wrote: > > > But what's going to kick these pages out of cache? Shouldn't we rather > > > find the pages, kick them out if clean, start writeback if not, and *then* > > > return -EAGAIN? > > > > As pointed out in the last round of these patches I think we really > > need to pass a flags argument to filemap_write_and_wait_range to > > communicate the non-blocking nature and only return -EAGAIN if we'd > > block. As a bonus that can indeed start to kick the pages out. > > Aren't flags to filemap_write_and_wait_range() unnecessary complication? > Realistically, most users wanting performance from AIO DIO so badly that > they bother with this API won't have any pages to write / evict. If they do > by some bad accident, they can fall back to standard "blocking" AIO DIO. > So I don't see much value in teaching filemap_write_and_wait_range() about > a non-blocking mode... That lets me execute a DoS against a user using this API. All I have to do is open the file they're using read-only and read a byte from it. Page goes into page-cache, and they'll only get -EAGAIN from calling this syscall until the page ages out. Also, I don't understand why this is a flag. Isn't the point of AIO to be non-blocking? Why isn't this just a change to how we do AIO? -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
