[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALxfFW4RQmLf9QRdP8VUH0fZU_vUsCqXfxRtjeu6g7QvKAGOmQ@mail.gmail.com>
Date: Wed, 9 Nov 2022 10:59:07 -0500
From: Seth Jenkins <sethjenkins@...gle.com>
To: Jann Horn <jannh@...gle.com>
Cc: David Laight <David.Laight@...lab.com>, Kees Cook <keescook@...omium.org>,
"linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, Greg KH <gregkh@...uxfoundation.org>,
Linus Torvalds <torvalds@...uxfoundation.org>, "Eric W . Biederman" <ebiederm@...ssion.com>,
Andy Lutomirski <luto@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] exit: Put an upper limit on how often we can oops
I'll add to this by noting that it is highly oops dependent. Depending
on what locks and refcounts you had taken at the moment you oops'd, it
may not be possible to clean up the process e.g. if you're holding
your own mmap lock at the moment you oops you're liable to deadlock in
__mmput. But there are certainly empirical cases (not all too isolated
ones) where the kernel really *is* able to clean up the entire
process.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
