On Sat, Apr 26, 2025 at 10:11:07AM -0400, Nathan Chancellor wrote:

On Sat, Apr 26, 2025 at 06:33:24AM -0700, Kees Cook wrote:

...

On April 26, 2025 6:25:09 AM PDT, Sasha Levin sashal@kernel.org wrote:

...

This is a note to let you know that I've just added the patch titled

lib/Kconfig.ubsan: Remove 'default UBSAN' from UBSAN_INTEGER_WRAP

to the 6.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git%3Ba=su...

The filename of the patch is: lib-kconfig.ubsan-remove-default-ubsan-from-ubsan_in.patch and it can be found in the queue-6.14 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let stable@vger.kernel.org know about it.

Please drop this; it's fixing the other patch that should not be backported. :)

This one is still technically needed but I already sent a manual backport for this...

https://lore.kernel.org/stable/20250423172241.1135309-2-nathan@kernel.org/ https://lore.kernel.org/stable/20250423172504.1334237-2-nathan@kernel.org/

Sasha, it is a little insulting to me to have my manual backports ignored while you pull in extra unnecessary changes to make them apply

Appologies: this is a case where some things falls through the cracks between Greg and myself. Let me explain...

Greg is usually picking up patches from the mailing list. I have the annoying bot (which you might have seen) that tests backports folks send over, but in reality I would rarely apply a backport someone sent over (even if only so we won't step on each other's toes).

On the other hand, I have some automation in place that after a few days, it combs through the FAILED: mails that Greg sends out and will attempt to automatically resolve conflicts by bringing in dependencies and build testing the code.

I promise I haven't "manually" ignored your backports :)

cleanly, especially since I sent them straight to you. I already spent the effort to account for the conflict, which was not big or nasty enough to justify pulling in the upstream solution, especially when it is still not ready for prime time, hence this change...

I'll go drop my backports and queue up yours.

On Sat, Apr 26, 2025 at 11:12:48AM -0400, Nathan Chancellor wrote:

On Sat, Apr 26, 2025 at 10:52:32AM -0400, Sasha Levin wrote:

...

On Sat, Apr 26, 2025 at 10:11:07AM -0400, Nathan Chancellor wrote:

...

Sasha, it is a little insulting to me to have my manual backports ignored while you pull in extra unnecessary changes to make them apply

Appologies: this is a case where some things falls through the cracks between Greg and myself. Let me explain...

Greg is usually picking up patches from the mailing list. I have the annoying bot (which you might have seen) that tests backports folks send over, but in reality I would rarely apply a backport someone sent over (even if only so we won't step on each other's toes).

On the other hand, I have some automation in place that after a few days, it combs through the FAILED: mails that Greg sends out and will attempt to automatically resolve conflicts by bringing in dependencies and build testing the code.

Maybe that automation could look to see if a patch has already been sent to the FAILED thread? Greg's instructions tell people to use '--in-reply-to' with the FAILED message ID so it would probably cover the vast majority of cases of manually backport.

Yeah, it could be improved like you've suggested.

One of the reasons I'm not tackling it yet is because it's a bit "old" and I need to rework it to use the lore/lei infra we now have and I'm a bit overloaded to try and tackle that.

I think that ignoring any "FAILED:" mails that have any replies makes sense here.

...

I promise I haven't "manually" ignored your backports :)

Sorry, I did not mean for that to sound as harsh and accusatory as it was and I appreciate the additional clarification around the process so that it can potentially be improved :) thanks for all the work you and Greg do.

No worries, thanks for the backports! :)