On Fri, Mar 13, 2020 at 05:50:51PM -0700, Linus Torvalds wrote:> On Fri, Mar 13, 2020 at 4:53 PM Al Viro <viro@zeniv.linux.org.uk> wrote:> >> > Review and testing would be _very_ welcome;> > I didn't notice anythign else than the few things I sent out to> individual patches.> > But I have to say, 69 patches is too long of a series to review. I> think you could send them out as multiple series (you describe them> that way anyway - parts 1-7) with a day in between.

A week of fun? OK...

> Because my eyes were starting to glaze over about halfway in the series.> > But don't do it for this version. If you do a #5. But it would be good> to be in -next regardless of whether you do a #5 or not.

FWIW, I've dealt with bisect hazards and I'll probably reorder #56 after#57/#58, to get the stuff that deals with stack allocation (#56, #59..61)together, without "reduce the exposure to weird struct path instances"(57 and 58) mixed in the middle of that.

As for the rest... I'm not sure that choose_mountpoint{,_rcu}()is inserted into the right place in text - might be better next tofollow_up(). There's also a couple of pick_link() pieces worth separatehelpers, but I'd rather leave that for the next cycle - the series isbloody long as it is.

I'm not going to throw the immediate prereqs for ->atomic_open() callingconventions change into that pile - they don't harm anything, but theyare unmotivated without the next step (method signature change) and it'sreally too late in the cycle for that. That's going to be a separateseries, probably for the next cycle. Changes to instances are nothuge; ceph is the worst by far and that's only +27/-22 lines. So I don'tthink there will be a lot of conflicts to cope with in the next cycle,especially since ceph side of things looks like we want to do somerefactoring first, with much smaller changeover on top of that. Thatrefactoring itself won't have prereqs at all, so that can be dealt withsanely and that'll soak most of the potential conflicts in.

There are other potential refactorings/cleanups, but that's definitelynot for this cycle. So... short of regressions found in that seriesthat's probably close to what I'll have for the coming window inthis branch. If I see something else in there that can be usefullycleaned up, I'll keep it for after -rc1...

Next: context switch to uaccess series and getting that patchbomb ready.Oh, well...