On Thu, 29 May 2025 20:05:32 -0700 Kuniyuki Iwashima <kuni1840@xxxxxxxxx> wrote: > From: David Laight <david.laight.linux@xxxxxxxxx> > Date: Thu, 29 May 2025 22:29:11 +0100 > > On Mon, 26 May 2025 07:30:13 +0200 > > Christoph Hellwig <hch@xxxxxx> wrote: > > > > > On Fri, May 23, 2025 at 11:21:08AM -0700, Kuniyuki Iwashima wrote: > > > > Let's rename sock_create_kern() to __sock_create_kern() as a special > > > > API and add a fat documentation. > > > > > > > > The next patch will add sock_create_kern() that holds netns refcnt. > > > > > > Maybe do this before patch 1 to reduce the churn of just touching a > > > lot of the same callers again? > > > > You also really want untouched source files to fail to compile. > > If nothing else it'll stop backports going badly awry. > > I didn't get what you wanted to say, but I remember the series > passed make all{yes,mod}config. One effect of the series seems to be changing sock_create_kern() so that it 'holds' the network namespace. Now if I backport one of the changed files to an old kernel version it will still compile but won't work properly. (Maybe you've removed the call where it acquired the 'hold'.) So while the patch series bisects (assuming it all goes through one tree - and it really needs to go through several) you are relying on any backports picking up the changes. (And also the changes to sock_create_kern() not being picked up without all the other changes.) Now backports ought to pick up the required dependant patches, but it is much better to generate compile fails when patches are missing. Obscure run-time backport issues are annoying. David