linux-next: duplicate patch in the nolibc tree

linux-next: duplicate patch in the nolibc tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 353 bytes --]

Hi all,

The following commit is also in the vfs-brauner tree as a different commit
(but the same patch):

  ba859b2e419c ("selftests/nolibc: drop test chmod_net")

This is commit

  49319832de90 ("selftests/nolibc: drop test chmod_net")

in the vfs-brauner tree.

This duplication is causing a conflict.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: duplicate patch in the nolibc tree

[Thomas Weißschuh]

On 2023-08-17 13:38:11+1000, Stephen Rothwell wrote:
> The following commit is also in the vfs-brauner tree as a different commit
> (but the same patch):
> 
>   ba859b2e419c ("selftests/nolibc: drop test chmod_net")
> 
> This is commit
> 
>   49319832de90 ("selftests/nolibc: drop test chmod_net")
> 
> in the vfs-brauner tree.

I think we can drop the patch from the nolibc tree.
The patch is only really necessary in combination with
commit 18e66ae67673 ("proc: use generic setattr() for /proc/$PID/net")
which already is and should stay in the vfs tree.

Re: linux-next: duplicate patch in the nolibc tree

[Shuah Khan]

On 8/17/23 10:30, Thomas Weißschuh wrote:
> On 2023-08-17 13:38:11+1000, Stephen Rothwell wrote:
>> The following commit is also in the vfs-brauner tree as a different commit
>> (but the same patch):
>>
>>    ba859b2e419c ("selftests/nolibc: drop test chmod_net")
>>
>> This is commit
>>
>>    49319832de90 ("selftests/nolibc: drop test chmod_net")
>>
>> in the vfs-brauner tree.
> 
> I think we can drop the patch from the nolibc tree.
> The patch is only really necessary in combination with
> commit 18e66ae67673 ("proc: use generic setattr() for /proc/$PID/net")
> which already is and should stay in the vfs tree.

Thomas,

Do the rest of the nolibc patches build without this if we were
to drop this patch? Dorpping requires rebase and please see below.

Willy, Paul,

How do we want to handle this so we can avoid rebasing to keep
the Commit IDs the same as one ones in Willy's nolibc branch?

I would recommend dropping this commit from vfs-brauner if it
doesn't cause problems.

thanks,
-- Shuah

Re: linux-next: duplicate patch in the nolibc tree

[Paul E. McKenney]

On Thu, Aug 17, 2023 at 12:27:46PM -0600, Shuah Khan wrote:
> On 8/17/23 10:30, Thomas Weißschuh wrote:
> > On 2023-08-17 13:38:11+1000, Stephen Rothwell wrote:
> > > The following commit is also in the vfs-brauner tree as a different commit
> > > (but the same patch):
> > > 
> > >    ba859b2e419c ("selftests/nolibc: drop test chmod_net")
> > > 
> > > This is commit
> > > 
> > >    49319832de90 ("selftests/nolibc: drop test chmod_net")
> > > 
> > > in the vfs-brauner tree.
> > 
> > I think we can drop the patch from the nolibc tree.
> > The patch is only really necessary in combination with
> > commit 18e66ae67673 ("proc: use generic setattr() for /proc/$PID/net")
> > which already is and should stay in the vfs tree.
> 
> Thomas,
> 
> Do the rest of the nolibc patches build without this if we were
> to drop this patch? Dorpping requires rebase and please see below.
> 
> Willy, Paul,
> 
> How do we want to handle this so we can avoid rebasing to keep
> the Commit IDs the same as one ones in Willy's nolibc branch?

The usual way would be for Willy to drop the patch, rebase, and republish
his branch.  You would then discard the current branch and pull the
new one.

> I would recommend dropping this commit from vfs-brauner if it
> doesn't cause problems.

It might be good for nolibc patches to be going through Willy's tree.

Or does Christian have some situation where it is necessary to make
a coordinated vfs/nolibc change?

							Thanx, Paul

Re: linux-next: duplicate patch in the nolibc tree

[Thomas Weißschuh]

On 2023-08-17 12:27:46-0600, Shuah Khan wrote:
> On 8/17/23 10:30, Thomas Weißschuh wrote:
> > On 2023-08-17 13:38:11+1000, Stephen Rothwell wrote:
> > > The following commit is also in the vfs-brauner tree as a different commit
> > > (but the same patch):
> > > 
> > >    ba859b2e419c ("selftests/nolibc: drop test chmod_net")
> > > 
> > > This is commit
> > > 
> > >    49319832de90 ("selftests/nolibc: drop test chmod_net")
> > > 
> > > in the vfs-brauner tree.
> > 
> > I think we can drop the patch from the nolibc tree.
> > The patch is only really necessary in combination with
> > commit 18e66ae67673 ("proc: use generic setattr() for /proc/$PID/net")
> > which already is and should stay in the vfs tree.
> 
> Thomas,
> 
> Do the rest of the nolibc patches build without this if we were
> to drop this patch? Dorpping requires rebase and please see below.

Yes, this patch is completely independent.
It only interacts with the mentioned commit in the vfs tree.

> [..]

Thomas

Re: linux-next: duplicate patch in the nolibc tree

[Willy Tarreau]

On Thu, Aug 17, 2023 at 11:46:57AM -0700, Paul E. McKenney wrote:
> On Thu, Aug 17, 2023 at 12:27:46PM -0600, Shuah Khan wrote:
> > On 8/17/23 10:30, Thomas Weißschuh wrote:
> > > On 2023-08-17 13:38:11+1000, Stephen Rothwell wrote:
> > > > The following commit is also in the vfs-brauner tree as a different commit
> > > > (but the same patch):
> > > > 
> > > >    ba859b2e419c ("selftests/nolibc: drop test chmod_net")
> > > > 
> > > > This is commit
> > > > 
> > > >    49319832de90 ("selftests/nolibc: drop test chmod_net")
> > > > 
> > > > in the vfs-brauner tree.
> > > 
> > > I think we can drop the patch from the nolibc tree.
> > > The patch is only really necessary in combination with
> > > commit 18e66ae67673 ("proc: use generic setattr() for /proc/$PID/net")
> > > which already is and should stay in the vfs tree.
> > 
> > Thomas,
> > 
> > Do the rest of the nolibc patches build without this if we were
> > to drop this patch? Dorpping requires rebase and please see below.
> > 
> > Willy, Paul,
> > 
> > How do we want to handle this so we can avoid rebasing to keep
> > the Commit IDs the same as one ones in Willy's nolibc branch?
> 
> The usual way would be for Willy to drop the patch, rebase, and republish
> his branch.  You would then discard the current branch and pull the
> new one.
> 
> > I would recommend dropping this commit from vfs-brauner if it
> > doesn't cause problems.
> 
> It might be good for nolibc patches to be going through Willy's tree.

It would indeed be more logical as a general rule. However, here I don't
care as I don't see any issue caused by dropping it, I can adapt to what
is most convenient for most of us.

Let's maybe just wait a little bit for Christian to suggest what he
prefers then we can adapt.

> Or does Christian have some situation where it is necessary to make
> a coordinated vfs/nolibc change?

I don't think there's any need for coordination on this one.

Thanks,
willy

Re: linux-next: duplicate patch in the nolibc tree

[Paul E. McKenney]

On Thu, Aug 17, 2023 at 09:39:09PM +0200, Willy Tarreau wrote:
> On Thu, Aug 17, 2023 at 11:46:57AM -0700, Paul E. McKenney wrote:
> > On Thu, Aug 17, 2023 at 12:27:46PM -0600, Shuah Khan wrote:
> > > On 8/17/23 10:30, Thomas Weißschuh wrote:
> > > > On 2023-08-17 13:38:11+1000, Stephen Rothwell wrote:
> > > > > The following commit is also in the vfs-brauner tree as a different commit
> > > > > (but the same patch):
> > > > > 
> > > > >    ba859b2e419c ("selftests/nolibc: drop test chmod_net")
> > > > > 
> > > > > This is commit
> > > > > 
> > > > >    49319832de90 ("selftests/nolibc: drop test chmod_net")
> > > > > 
> > > > > in the vfs-brauner tree.
> > > > 
> > > > I think we can drop the patch from the nolibc tree.
> > > > The patch is only really necessary in combination with
> > > > commit 18e66ae67673 ("proc: use generic setattr() for /proc/$PID/net")
> > > > which already is and should stay in the vfs tree.
> > > 
> > > Thomas,
> > > 
> > > Do the rest of the nolibc patches build without this if we were
> > > to drop this patch? Dorpping requires rebase and please see below.
> > > 
> > > Willy, Paul,
> > > 
> > > How do we want to handle this so we can avoid rebasing to keep
> > > the Commit IDs the same as one ones in Willy's nolibc branch?
> > 
> > The usual way would be for Willy to drop the patch, rebase, and republish
> > his branch.  You would then discard the current branch and pull the
> > new one.
> > 
> > > I would recommend dropping this commit from vfs-brauner if it
> > > doesn't cause problems.
> > 
> > It might be good for nolibc patches to be going through Willy's tree.
> 
> It would indeed be more logical as a general rule. However, here I don't
> care as I don't see any issue caused by dropping it, I can adapt to what
> is most convenient for most of us.
> 
> Let's maybe just wait a little bit for Christian to suggest what he
> prefers then we can adapt.
> 
> > Or does Christian have some situation where it is necessary to make
> > a coordinated vfs/nolibc change?
> 
> I don't think there's any need for coordination on this one.

It is always good when either option can be make to work.  ;-)

							Thanx, Paul

Re: linux-next: duplicate patch in the nolibc tree

[Christian Brauner]

On Thu, Aug 17, 2023 at 01:41:45PM -0700, Paul E. McKenney wrote:
> On Thu, Aug 17, 2023 at 09:39:09PM +0200, Willy Tarreau wrote:
> > On Thu, Aug 17, 2023 at 11:46:57AM -0700, Paul E. McKenney wrote:
> > > On Thu, Aug 17, 2023 at 12:27:46PM -0600, Shuah Khan wrote:
> > > > On 8/17/23 10:30, Thomas Weißschuh wrote:
> > > > > On 2023-08-17 13:38:11+1000, Stephen Rothwell wrote:
> > > > > > The following commit is also in the vfs-brauner tree as a different commit
> > > > > > (but the same patch):
> > > > > > 
> > > > > >    ba859b2e419c ("selftests/nolibc: drop test chmod_net")
> > > > > > 
> > > > > > This is commit
> > > > > > 
> > > > > >    49319832de90 ("selftests/nolibc: drop test chmod_net")
> > > > > > 
> > > > > > in the vfs-brauner tree.
> > > > > 
> > > > > I think we can drop the patch from the nolibc tree.
> > > > > The patch is only really necessary in combination with
> > > > > commit 18e66ae67673 ("proc: use generic setattr() for /proc/$PID/net")
> > > > > which already is and should stay in the vfs tree.
> > > > 
> > > > Thomas,
> > > > 
> > > > Do the rest of the nolibc patches build without this if we were
> > > > to drop this patch? Dorpping requires rebase and please see below.
> > > > 
> > > > Willy, Paul,
> > > > 
> > > > How do we want to handle this so we can avoid rebasing to keep
> > > > the Commit IDs the same as one ones in Willy's nolibc branch?
> > > 
> > > The usual way would be for Willy to drop the patch, rebase, and republish
> > > his branch.  You would then discard the current branch and pull the
> > > new one.
> > > 
> > > > I would recommend dropping this commit from vfs-brauner if it
> > > > doesn't cause problems.
> > > 
> > > It might be good for nolibc patches to be going through Willy's tree.
> > 
> > It would indeed be more logical as a general rule. However, here I don't
> > care as I don't see any issue caused by dropping it, I can adapt to what
> > is most convenient for most of us.
> > 
> > Let's maybe just wait a little bit for Christian to suggest what he
> > prefers then we can adapt.
> > 
> > > Or does Christian have some situation where it is necessary to make
> > > a coordinated vfs/nolibc change?
> > 
> > I don't think there's any need for coordination on this one.
> 
> It is always good when either option can be make to work.  ;-)

The patch in the vfs tree will make the test fail so it makes sense to
have both go in together. I would normally be happy to drop it but I'm
rather unenthusiastic in this particular case because I replied to this
almost 5 weeks ago on Thursday, July 13 and since then this has been in
-next.

commit 49319832de90f1943264e5c573b072947af6ae26
Author:     Thomas Weißschuh <linux@weissschuh.net>
AuthorDate: Sat Jun 24 12:30:46 2023 +0200
Commit:     Christian Brauner <brauner@kernel.org>
CommitDate: Thu Jul 13 13:55:14 2023 +0200

    selftests/nolibc: drop test chmod_net

Re: linux-next: duplicate patch in the nolibc tree

[Shuah Khan]

On 8/18/23 07:27, Christian Brauner wrote:
> On Thu, Aug 17, 2023 at 01:41:45PM -0700, Paul E. McKenney wrote:
>> On Thu, Aug 17, 2023 at 09:39:09PM +0200, Willy Tarreau wrote:
>>> On Thu, Aug 17, 2023 at 11:46:57AM -0700, Paul E. McKenney wrote:
>>>> On Thu, Aug 17, 2023 at 12:27:46PM -0600, Shuah Khan wrote:
>>>>> On 8/17/23 10:30, Thomas Weißschuh wrote:
>>>>>> On 2023-08-17 13:38:11+1000, Stephen Rothwell wrote:
>>>>>>> The following commit is also in the vfs-brauner tree as a different commit
>>>>>>> (but the same patch):
>>>>>>>
>>>>>>>     ba859b2e419c ("selftests/nolibc: drop test chmod_net")
>>>>>>>
>>>>>>> This is commit
>>>>>>>
>>>>>>>     49319832de90 ("selftests/nolibc: drop test chmod_net")
>>>>>>>
>>>>>>> in the vfs-brauner tree.
>>>>>>
>>>>>> I think we can drop the patch from the nolibc tree.
>>>>>> The patch is only really necessary in combination with
>>>>>> commit 18e66ae67673 ("proc: use generic setattr() for /proc/$PID/net")
>>>>>> which already is and should stay in the vfs tree.
>>>>>
>>>>> Thomas,
>>>>>
>>>>> Do the rest of the nolibc patches build without this if we were
>>>>> to drop this patch? Dorpping requires rebase and please see below.
>>>>>
>>>>> Willy, Paul,
>>>>>
>>>>> How do we want to handle this so we can avoid rebasing to keep
>>>>> the Commit IDs the same as one ones in Willy's nolibc branch?
>>>>
>>>> The usual way would be for Willy to drop the patch, rebase, and republish
>>>> his branch.  You would then discard the current branch and pull the
>>>> new one.
>>>>
>>>>> I would recommend dropping this commit from vfs-brauner if it
>>>>> doesn't cause problems.
>>>>
>>>> It might be good for nolibc patches to be going through Willy's tree.
>>>
>>> It would indeed be more logical as a general rule. However, here I don't
>>> care as I don't see any issue caused by dropping it, I can adapt to what
>>> is most convenient for most of us.
>>>
>>> Let's maybe just wait a little bit for Christian to suggest what he
>>> prefers then we can adapt.
>>>
>>>> Or does Christian have some situation where it is necessary to make
>>>> a coordinated vfs/nolibc change?
>>>
>>> I don't think there's any need for coordination on this one.
>>
>> It is always good when either option can be make to work.  ;-)
> 
> The patch in the vfs tree will make the test fail so it makes sense to
> have both go in together. I would normally be happy to drop it but I'm
> rather unenthusiastic in this particular case because I replied to this
> almost 5 weeks ago on Thursday, July 13 and since then this has been in
> -next.
> 

I totally understand you being unenthusiastic. Considering summer
vacation schedules and all, emails get missed at times.

I sincerely request you to consider dropping as it is the simpler route
for all involved.

thanks,
-- Shuah
  

Re: linux-next: duplicate patch in the nolibc tree

[Shuah Khan]

On 8/18/23 07:59, Shuah Khan wrote:
> On 8/18/23 07:27, Christian Brauner wrote:
>> On Thu, Aug 17, 2023 at 01:41:45PM -0700, Paul E. McKenney wrote:
>>> On Thu, Aug 17, 2023 at 09:39:09PM +0200, Willy Tarreau wrote:
>>>> On Thu, Aug 17, 2023 at 11:46:57AM -0700, Paul E. McKenney wrote:
>>>>> On Thu, Aug 17, 2023 at 12:27:46PM -0600, Shuah Khan wrote:
>>>>>> On 8/17/23 10:30, Thomas Weißschuh wrote:
>>>>>>> On 2023-08-17 13:38:11+1000, Stephen Rothwell wrote:
>>>>>>>> The following commit is also in the vfs-brauner tree as a different commit
>>>>>>>> (but the same patch):
>>>>>>>>
>>>>>>>>     ba859b2e419c ("selftests/nolibc: drop test chmod_net")
>>>>>>>>
>>>>>>>> This is commit
>>>>>>>>
>>>>>>>>     49319832de90 ("selftests/nolibc: drop test chmod_net")
>>>>>>>>
>>>>>>>> in the vfs-brauner tree.
>>>>>>>
>>>>>>> I think we can drop the patch from the nolibc tree.
>>>>>>> The patch is only really necessary in combination with
>>>>>>> commit 18e66ae67673 ("proc: use generic setattr() for /proc/$PID/net")
>>>>>>> which already is and should stay in the vfs tree.
>>>>>>
>>>>>> Thomas,
>>>>>>
>>>>>> Do the rest of the nolibc patches build without this if we were
>>>>>> to drop this patch? Dorpping requires rebase and please see below.
>>>>>>
>>>>>> Willy, Paul,
>>>>>>
>>>>>> How do we want to handle this so we can avoid rebasing to keep
>>>>>> the Commit IDs the same as one ones in Willy's nolibc branch?
>>>>>
>>>>> The usual way would be for Willy to drop the patch, rebase, and republish
>>>>> his branch.  You would then discard the current branch and pull the
>>>>> new one.
>>>>>
>>>>>> I would recommend dropping this commit from vfs-brauner if it
>>>>>> doesn't cause problems.
>>>>>
>>>>> It might be good for nolibc patches to be going through Willy's tree.
>>>>
>>>> It would indeed be more logical as a general rule. However, here I don't
>>>> care as I don't see any issue caused by dropping it, I can adapt to what
>>>> is most convenient for most of us.
>>>>
>>>> Let's maybe just wait a little bit for Christian to suggest what he
>>>> prefers then we can adapt.
>>>>
>>>>> Or does Christian have some situation where it is necessary to make
>>>>> a coordinated vfs/nolibc change?
>>>>
>>>> I don't think there's any need for coordination on this one.
>>>
>>> It is always good when either option can be make to work.  ;-)
>>
>> The patch in the vfs tree will make the test fail so it makes sense to
>> have both go in together. I would normally be happy to drop it but I'm
>> rather unenthusiastic in this particular case because I replied to this
>> almost 5 weeks ago on Thursday, July 13 and since then this has been in
>> -next.
>>
> 
> I totally understand you being unenthusiastic. Considering summer
> vacation schedules and all, emails get missed at times.
> 
> I sincerely request you to consider dropping as it is the simpler route
> for all involved.
> 

Christian,

Please let us know if my request failed to raise your enthusiasm level.
We will go to our plan b of having Willy drop the patch, resend the
pull request to me ....


thanks,
-- Shuah

Re: linux-next: duplicate patch in the nolibc tree

[Christian Brauner]

> We will go to our plan b of having Willy drop the patch, resend the
> pull request to me ....

No, I didn't drop it so I appreciate it if you went with your plan.
If I drop it now I'd be causing churn after having this sit in -next for
over 5 weeks and I'll send a pr in the middle of this week.

Thanks!

Re: linux-next: duplicate patch in the nolibc tree

[Willy Tarreau]

Hi,

On Mon, Aug 21, 2023 at 06:07:45PM +0200, Christian Brauner wrote:
> > We will go to our plan b of having Willy drop the patch, resend the
> > pull request to me ....
> 
> No, I didn't drop it so I appreciate it if you went with your plan.
> If I drop it now I'd be causing churn after having this sit in -next for
> over 5 weeks and I'll send a pr in the middle of this week.

I personally don't care about dropping it, but the whole process is
unclear to me and I'm unsure about what I can/have to do if at all
to help here.

Thanks,
Willy