Hi Eric, On 26/01/23 12:14 am, Eric Biggers wrote:
Hi Harshit, On Wed, Jan 25, 2023 at 07:39:10PM +0530, Harshit Mogalapalli wrote:Thanks for the backports. I have tried backporting the oops_limit patches to LTS 5.15.y and had a similar set of patches, just want to add a note here on an alternate way for backporting this patch without resolving conflicts manually: Here is the sequence: * Patch 12: [panic: Separate sysctl logic from CONFIG_SMP] --> Cherry-pick Commit: 05ea0424f0e2 ("exit: Move oops specific logic from do_exit into make_task_dead") upstream --> Cherry-pick Commit: de77c3a5b95c ("exit: Move force_uaccess back into do_exit") upstream * Patch 13 which is Commit: d4ccd54d28d3 ("exit: Put an upper limit on how often we can oops") upstream, will be a clean cherry-pick. The benefit may be making future backports simpler in make_task_dead(). This was the only difference, so your backport looks good to me.It's certainly an option. The reason why I didn't do it that way is to reduce the impact of any potential bugs where do_exit() is still called when the new make_task_dead() function should be used instead. With my series, the effect is just that oops_limit won't take effect in such cases. If we also backported commit 05ea0424f0e2 ("exit: Move oops specific logic from do_exit into make_task_dead"), then do_exit() will lose various other things, such as panicing when called from an interrupt handler. That would increase the chance of regressions, unless we made absolutely sure that everywhere that should be using make_task_dead() is indeed using it instead of do_exit(). Commit 0e25498f8cd4 ("exit: Add and use make_task_dead."), which I backported, did the vast majority of conversions to make_task_dead(). Some architectures still have uses of do_exit() that got cleaned up later, though. It seems it was mostly unreachable code, and some cases that should have been doing something else such as BUG() or sending a signal to userspace. So, generally not super important cases.
Thanks a lot for explaining!
Still, getting all that would bring in many more patches. We could do that, but since this is already a 20-patch series, I wanted to limit the scope a bit. These extra patches could always be backported later on top of this if desired.
Sure. Regards, Harshit
- Eric
