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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ