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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f9566605-c4f8-0306-7f07-86b9e0abebfd@oracle.com>
Date:   Thu, 26 Jan 2023 00:29:11 +0530
From:   Harshit Mogalapalli <harshit.m.mogalapalli@...cle.com>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     stable@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Kees Cook <keescook@...omium.org>,
        SeongJae Park <sj@...nel.org>,
        Seth Jenkins <sethjenkins@...gle.com>,
        Jann Horn <jannh@...gle.com>,
        "Eric W . Biederman" <ebiederm@...ssion.com>,
        linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org,
        Luis Chamberlain <mcgrof@...nel.org>,
        Vegard Nossum <vegard.nossum@...cle.com>,
        Darren Kenny <darren.kenny@...cle.com>
Subject: Re: [PATCH 5.15 13/20] exit: Put an upper limit on how often we can
 oops

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