[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <274c764afe34abdf06abc6a7eaf753a2911c967b.camel@trillion01.com>
Date: Thu, 10 Jun 2021 11:17:11 -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 Thu, 2021-06-10 at 09:26 -0500, Eric W. Biederman wrote:
> Olivier Langlois <olivier@...llion01.com> writes:
>
> > 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...
>
> No. I was just asking to make certain I understood what you said.
>
> I thought you said you were getting a consistent 0 byte coredump,
> and that implied that TIF_NOTIFY_SIGNAL was coming in before
> the coredump even started.
due to the asynchronous nature of the problem, it is all random.
Sometimes, I do get 0 byte coredump.
Most of the times, I get a truncated one
and very rarely (this is why the issue was so annoying), I get a full
coredump.
>
> So I will spin up a good version of my patch (based on your patch)
> so we can unbreak coredumps.
>
That is super nice. I am looking forward it!
Greetings,
Olivier
Powered by blists - more mailing lists