On Tue, Oct 19, 2021 at 3:42 AM Andreas Gruenbacher <agruenba@xxxxxxxxxx> wrote:
>
> From my point of view, the following questions remain:
>
> * I hope these patches will be merged for v5.16, but what process
> should I follow for that? The patch queue contains mm and iomap
> changes, so a pull request from the gfs2 tree would be unusual.
Oh, I'd much rather get these as one pull request from the author and
from the person that actually ended up testing this.
It might be "unusual", but it's certainly not unheard of, and trying
to push different parts of the series through different maintainers
would just cause lots of extra churn.
Yes, normally I'd expect filesystem changes to have a diffstat that
clearly shows that "yes, it's all local to this filesystem", and when
I see anything else it raises red flags.
But it raises red flags not because it would be wrong to have changes
to other parts, but simply because when cross-subsystem development
happens, it needs to be discussed and cleared with people. And you've
done that.
So I'd take this as one pull request from you. You've been doing the
work, you get the questionable glory of being in charge of it all.
You'll get the blame too ;)
> * Will Catalin Marinas's work for supporting arm64 sub-page faults
> be queued behind these patches? We have an overlap in
> fault_in_[pages_]readable fault_in_[pages_]writeable, so one of
> the two patch queues will need some adjustments.
I think that on the whole they should be developed separately, I don't
think it's going to be a particularly difficult conflict.
That whole discussion does mean that I suspect that we'll have to
change fault_in_iov_iter_writeable() to do the "every 16 bytes" or
whatever thing, and make it use an actual atomic "add zero" or
whatever rather than walk the page tables. But that's a conceptually
separate discussion from this one, I wouldn't actually want to mix up
the two issues too much.
Sure, they touch the same code, so there is _that_ overlap, but one is
about "the hardware rules are a-changing" and the other is about
filesystem use of - and expansion of - the things we do. Let's keep
them separate until ready, and then fix up the fallout at that point
(either as a merge resolution, or even partly after-the-fact).
Linus
