Messages in this thread | | | Date | Fri, 3 Sep 2021 18:25:46 +0000 | From | Al Viro <> | Subject | Re: [PATCH v7 00/19] gfs2: Fix mmap + page fault deadlocks |
| |
On Fri, Sep 03, 2021 at 08:52:00AM -0700, Linus Torvalds wrote: > On Wed, Sep 1, 2021 at 12:53 PM Andreas Gruenbacher <agruenba@redhat.com> wrote: > > > > So there's a minor merge conflict between Christoph's iomap_iter > > conversion and this patch queue now, and I should probably clarify the > > description of "iomap: Add done_before argument to iomap_dio_rw" that > > Darrick ran into. Then there are the user copy issues that Al has > > pointed out. Fixing those will create superficial conflicts with this > > patch queue, but probably nothing serious. > > > > So how should I proceed: do you expect a v8 of this patch queue on top > > of the current mainline? > > So if you rebase for fixes, it's going to be a "next merge window" thing again. > > Personally, I'm ok with the series as is, and the conflict isn't an > issue. So I'd take it as is, and then people can fix up niggling > issues later. > > But if somebody screams loudly..
FWIW, my objections regarding the calling conventions are still there.
Out of 3 callers that do want more than "success/failure", one is gone (series by tglx) and one more is broken (regardless of the semantics, btrfs on arm64). Which leaves 1 caller (fault-in for read in FPU handling on x86 sigreturn). That caller turns out to be correct, but IMO there are fairly strong arguments in favour of *not* using the normal fault-in in that case.
"how many bytes can we fault in" is misleading, unless we really poke into every cacheline in the affected area. Which might be a primitive worth having, but it's a lot heavier than needed by the majority of callers.
| |