Re: [PATCH 2/2] ARC: show_regs: fix lockdep splat for good

[Vineet Gupta <vineet.gupta1@synopsys.com>]

On 12/21/18 5:04 AM, Michal Hocko wrote:
>> I presume you are referring to original commit, not my anti-change in ARC code,
>> which is actually re-enabling it.
> 
> Yes, but you are building on a broken concept I believe.

Not sure where this is heading. Broken concept was introduced by disabling
preemption around show_regs() to silence x86 smp_processor_id() splat in 2009.

> What
> implications does re-enabling really have ? Now you could reschedule and> you can move to another CPU. Is this really safe?

>From initial testing, none so far. show_regs() is simply pretty printing the
passed pt_regs and decoding the current task, which agreed could move to a
different CPU (likely will due to console/printk calls), but I don't see how that
could mess up its mm or othe rinternal plumbing which it prints.


> I believe that yes
> because the preemption disabling is simply bogus. Which doesn't sound
> like a proper justification, does it?

[snip]

> I do not follow. If there is some path to require show_regs to run with
> preemption disabled while others don't then something is clearly wrong.

[snip]

> Yes, the fix might be more involved but I would much rather prefer a
> correct code which builds on solid assumptions.

Right so the first step is reverting the disabled semantics for ARC and do some
heavy testing to make sure any fallouts are addressed etc. And if that works, then
propagate this change to core itself. Low risk strategy IMO - agree ?

Thx,
-Vineet