[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7b201ca7-dd1d-61be-8586-5dbf7a3c9333@cybernetics.com>
Date: Thu, 12 Aug 2021 09:53:21 -0400
From: Tony Battersby <tonyb@...ernetics.com>
To: Jens Axboe <axboe@...nel.dk>,
Olivier Langlois <olivier@...llion01.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Oleg Nesterov <oleg@...hat.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>,
"Pavel Begunkov>" <asml.silence@...il.com>
Subject: Re: [PATCH] coredump: Limit what can interrupt coredumps
On 8/11/21 9:55 PM, Jens Axboe wrote:
>
> That is very interesting. Like Olivier mentioned, it's not that actual
> commit, but rather the change of behavior implemented by it. Before that
> commit, we'd hit the async workers more often, whereas after we do the
> correct retry method where it's driven by the wakeup when the page is
> unlocked. This is purely speculation, but perhaps the fact that the
> process changes state potentially mid dump is why the dump ends up being
> truncated?
>
> I'd love to dive into this and try and figure it out. Absent a test
> case, at least the above gives me an idea of what to try out. I'll see
> if it makes it easier for me to create a case that does result in a
> truncated core dump.
>
If it helps, a "good" coredump from my program is about 350 MB
compressed down to about 7 MB by bzip2. A truncated coredump varies in
size from about 60 KB to about 2 MB before compression. The program
that receives the coredump uses bzip2 to compress the data before
writing it to disk.
Tony
Powered by blists - more mailing lists