On Thu, Jan 10, 2019 at 02:11:01PM -0800, Linus Torvalds wrote: > And we *can* do sane things about RWF_NOWAIT. For example, we could > start async IO on RWF_NOWAIT, and suddenly it would go from "probe the > page cache" to "probe and fill", and be much harder to use as an > attack vector.. We can only do that if the application submits the read via AIO and has an async IO completion reporting mechanism. Otherwise we have to wait for the IO to complete to copy the data into the user's buffer. And given that the app is using RWF_NOWAIT to explicitly avoid blocking on the IO.... Also, keep in mind that RWF_NOWAIT also prevents blocking on filesystem locks and full request queues. One of the prime drivers of RWF_NOWAIT was to prevent AIO submission from blocking on filesystem locks - it allows userspace to submit other IO while it can't get all the access it requires to a single file or a single block device is congested. Hence I don't think there's a such a simple answer here - blocking for IO breaks RWF_NOWAIT. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
