[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <874j625j1a.fsf@email.froward.int.ebiederm.org>
Date: Thu, 26 Sep 2024 14:09:21 -0500
From: "Eric W. Biederman" <ebiederm@...ssion.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Vegard Nossum <vegard.nossum@...cle.com>, Kees Cook <kees@...nel.org>,
linux-kernel@...r.kernel.org, Allen Pais <apais@...ux.microsoft.com>,
Brian Mak <makb@...iper.net>, Jeff Xu <jeffxu@...omium.org>, Roman
Kisel <romank@...ux.microsoft.com>, regressions@...ts.linux.dev
Subject: Re: [GIT PULL] execve updates for v6.12-rc1
Linus Torvalds <torvalds@...ux-foundation.org> writes:
> On Thu, 26 Sept 2024 at 11:29, Vegard Nossum <vegard.nossum@...cle.com> wrote:
>>
>> # first bad commit: [fb97d2eb542faf19a8725afbd75cbc2518903210]
>> binfmt_elf, coredump: Log the reason of the failed core dumps
>>
>> I have to admit I don't immediately see what's wrong with the patch.
>
> That commit looks entirely broken.
>
> I *suspect* that the problem is the crazy "get_task_comm()" in that
> takes the task lock inside coredump_report_failure().
>
> But honestly, I'm not going to bother even trying to debug this. The
> whole notion was broken. People who have problems with truncated
> core-files should be looking at their debuggers, not asking the kernel
> for help.
One of the common causes for coredump truncation is weird interactions
between io_uring and the coredump code. (AKA kernel bugs).
That is something you can't ask your debugger to tell you.
So from 10,000 feet I think the idea is sane.
Eric
Powered by blists - more mailing lists