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
