Messages in this thread | | | From | Linus Torvalds <> | Date | Mon, 31 May 2021 20:00:08 -1000 | Subject | Re: [RFC 4/9] gfs2: Fix mmap + page fault deadlocks (part 1) |
| |
On Mon, May 31, 2021 at 7:01 AM Andreas Gruenbacher <agruenba@redhat.com> wrote: > > Fix that by recognizing the self-recursion case.
Hmm. I get the feeling that the self-recursion case should never have been allowed to happen in the first place.
IOW, is there some reason why you can't make the user accesses always be doen with page faults disabled (ie using the "atomic" user space access model), and then if you get a partial read (or write) to user space, at that point you drop the locks in read/write, do the "try to make readable/writable" and try again.
IOW, none of this "detect recursion" thing. Just "no recursion in the first place".
That way you'd not have these odd rules at fault time at all, because a fault while holding a lock would never get to the filesystem at all, it would be aborted early. And you'd not have any odd "inner/outer" locks, or lock compatibility rules or anything like that. You'd literally have just "oh, I didn't get everything at RW time while I held locks, so let's drop the locks, try to access user space, and retry".
Wouldn't that be a lot simpler and more robust?
Because what if the mmap is something a bit more complex, like overlayfs or usefaultfd, and completing the fault isn't about gfs2 handling it as a "fault", but about some *other* entity calling back to gfs2 and doing a read/write instead? Now all your "inner/outer" lock logic ends up being entirely pointless, as far as I can tell, and you end up deadlocking on the lock you are holding over the user space access _anyway_.
So I literally think that your approach is
(a) too complicated
(b) doesn't actually fix the issue in the more general case
But maybe I'm missing something.
Linus
Linus
| |