[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b8434a8987672ab16f9fb755c1fc4d51e0f4004a.camel@trillion01.com>
Date: Wed, 09 Jun 2021 17:26:30 -0400
From: Olivier Langlois <olivier@...llion01.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
io-uring <io-uring@...r.kernel.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Jens Axboe <axboe@...nel.dk>,
"Pavel Begunkov>" <asml.silence@...il.com>,
Oleg Nesterov <oleg@...hat.com>
Subject: Re: [RFC] coredump: Do not interrupt dump for TIF_NOTIFY_SIGNAL
On Wed, 2021-06-09 at 16:05 -0500, Eric W. Biederman wrote:
> >
> > So the TIF_NOTIFY_SIGNAL does get set WHILE the core dump is
> > written.
>
> Did you mean?
>
> So the TIF_NOTIFY_SIGNAL does _not_ get set WHILE the core dump is
> written.
>
>
Absolutely not. I did really mean what I have said. Bear with me that,
I am not qualifying myself as an expert kernel dev yet so feel free to
correct me if I say some heresy...
io_uring is placing my task in my TCP socket wait queue because it
wants to read data from it.
The task returns to user space and core dump with a SEGV.
now my understanding is that the code that is waking up tasks, it is
the NIC driver interrupt handler which can occur while the core dump is
written.
does that make sense?
my testing is telling me that this is exactly what happens...
Powered by blists - more mailing lists