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

[Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>]

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