Messages in this thread | | | From | Linus Torvalds <> | Date | Thu, 1 Jul 2021 17:44:24 -0700 | Subject | Re: [PATCH] gfs2: Fix mmap + page fault deadlocks |
| |
On Thu, Jul 1, 2021 at 5:30 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > > Of course, if you ask for more data than the file has, that's another > thing, but who really does that with direct-IO? And if they do, why > should we care about their silly behavior?
Now, if the issue is that people do IO for bigger areas than you have memory for, then I think that's a chunking issue. I don't think the ITER_IOVEC necessarily needs to be converted to an ITER_BVEC in one single go. That would indeed be painful if somebody tries to do some huge direct-IO when they just don't have the memory for it.
But the fact is, direct-IO has been an incredible pain-point for decades, because it's (a) unusual, (b) buggy and (c) has very little overall design and common code.
The three issues are likely intimately tied together.
The iomap code at least has tried to make for much more common code, but I really think some direct-IO people should seriously reconsider how they are doing things when there are fundamental deadlocks in the design.
And I do think that a ITER_IOVEC -> ITER_BVEC conversion function might be a really really good idea to solve this problem. There's even a very natural chunking algorithm: try to do as much as possible with get_user_pages_fast() - so that if you already *have* the memory, you can do the full IO (or at least a big part of it).
And if get_user_pages_fast() only gives you a small area - or nothing at all - you chunk it down aggressively, and realize that "oh, doing direct-IO when user space is paged out might not be the most optimal case".
Linus
| |