From: Vineet Gupta <vineet.gupta1@synopsys.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: "linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 2/2] ARC: show_regs: fix lockdep splat for good
Date: Thu, 20 Dec 2018 18:45:48 +0000 [thread overview]
Message-ID: <C2D7FE5348E1B147BCA15975FBA23075014642389B@US01WEMBX2.internal.synopsys.com> (raw)
In-Reply-To: <20181220130450.GB17350@dhcp22.suse.cz>
On 12/20/18 5:04 AM, Michal Hocko wrote:
> On Tue 18-12-18 10:53:59, Vineet Gupta wrote:
>> signal handling core calls ARCH show_regs() with preemption disabled
>> which causes __might_sleep functions such as mmput leading to lockdep
>> splat. Workaround by re-enabling preemption temporarily.
>>
>> This may not be as bad as it sounds since the preemption disabling
>> itself was introduced for a supressing smp_processor_id() warning in x86
>> code by commit 3a9f84d354ce ("signals, debug: fix BUG: using
>> smp_processor_id() in preemptible code in print_fatal_signal()")
> The commit you are referring to here sounds dubious in itself.
Indeed that was my thought as well, but it did introduce the preemption disabling
logic aroung core calling show_regs() !
> We do not
> want to stick a preempt_disable just to silence a warning.
I presume you are referring to original commit, not my anti-change in ARC code,
which is actually re-enabling it.
> show_regs is
> called from preemptible context at several places (e.g. __warn).
Right, but do we have other reports which show this, perhaps not too many distros
have CONFIG__PREEMPT enabled ?
> Maybe
> this was not the case in 2009 when the change was introduced but this
> seems like a relict from the past. So can we fix the actual problem
> rather than build on top of it instead?
The best/correct fix is to remove the preempt diabling in core code, but that
affects every arch out there and will likely trip dormant land mines, needed
localized fixes like I'm dealing with now.
-Vineet
next prev parent reply other threads:[~2018-12-20 18:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-18 18:53 [PATCH 0/2] ARC show_regs fixes Vineet Gupta
2018-12-18 18:53 ` [PATCH 1/2] ARC: show_regs: avoid page allocator Vineet Gupta
2018-12-19 17:04 ` Eugeniy Paltsev
2018-12-19 17:36 ` Vineet Gupta
2018-12-20 1:16 ` Vineet Gupta
2018-12-20 13:30 ` Tetsuo Handa
2018-12-20 18:36 ` Vineet Gupta
2018-12-20 18:43 ` Vineet Gupta
2018-12-19 20:46 ` William Kucharski
2018-12-19 21:36 ` Vineet Gupta
2018-12-20 12:57 ` Michal Hocko
2018-12-20 18:38 ` Vineet Gupta
2018-12-18 18:53 ` [PATCH 2/2] ARC: show_regs: fix lockdep splat for good Vineet Gupta
2018-12-20 13:04 ` Michal Hocko
2018-12-20 18:45 ` Vineet Gupta [this message]
2018-12-21 13:04 ` Michal Hocko
2018-12-21 13:27 ` Michal Hocko
2018-12-21 17:55 ` Vineet Gupta
2018-12-21 17:55 ` Vineet Gupta
2018-12-24 19:10 ` Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C2D7FE5348E1B147BCA15975FBA23075014642389B@US01WEMBX2.internal.synopsys.com \
--to=vineet.gupta1@synopsys.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=mhocko@kernel.org \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox