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@xxxxxxxxxx> 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.
