[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190522110047.6bc80ca511a1425d8a069110@linux-foundation.org>
Date: Wed, 22 May 2019 11:00:47 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Jan Luebbe <jlu@...gutronix.de>
Cc: Alexey Dobriyan <adobriyan@...il.com>,
John Ogness <john.ogness@...utronix.de>,
Andy Lutomirski <luto@...nel.org>, kernel@...gutronix.de,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] proc: report eip and esp for all threads when
coredumping
On Wed, 22 May 2019 18:16:14 +0200 Jan Luebbe <jlu@...gutronix.de> wrote:
> Commit 0a1eb2d474ed ("fs/proc: Stop reporting eip and esp in
> /proc/PID/stat") stopped reporting eip/esp and commit fd7d56270b52
> ("fs/proc: Report eip/esp in /prod/PID/stat for coredumping")
> reintroduced the feature to fix a regression with userspace core dump
> handlers (such as minicoredumper).
>
> Because PF_DUMPCORE is only set for the primary thread, this didn't fix
> the original problem for secondary threads. This commit checks
> mm->core_state instead, as already done for /proc/<pid>/status in
> task_core_dumping(). As we have a mm_struct available here anyway, this
> seems to be a clean solution.
>
Could we please have an explicit and complete description of the
end-user visible effect of this change?
It sounds like we should be backporting this into -stable but without
the above info it's hard to determine this.
Powered by blists - more mailing lists