Re: [PATCH 5.15 13/20] exit: Put an upper limit on how often we can oops

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux