On Thu, Sep 1, 2022 at 3:13 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, 1 Sep 2022 16:02:08 -0300 "Guilherme G. Piccoli" <gpiccoli@xxxxxxxxxx> wrote: > > > On 01/09/2022 15:59, Greg KH wrote: > > > [...] > > > Ick, I don't know, this all feels odd. I want someone else to review > > > this and give their ack on the patch before I'll take it so someone else > > > can share in the blame :) > > > > > > thanks, > > > > > > greg k-h > > > > LOL, that's OK for me! Evan seems to be fine with it BTW. > > > > Let's see if Petr can jump in, also adding Andrew here since he's > > usually merging stuff for panic. > > Are the usual gsmi developers not operational? I'm unsure who that is, I sort of Mr. Beaned my way in here having touched the file recently. A lot of the people who historically touched this file have gone. > > Patch seems sensible to me, although the deadlock sounds pretty > theoretical. A better code comment might be simply > > /* > * Panic callbacks are executed with all other CPUs stopped, so we must > * not attempt to spin waiting for gsmi_dev.lock to be released. > */ > > ? I basically came to the same conclusion as Andrew. It seems like this patch does fix a problem, which is a panic coming in on another CPU and NMIing on top of a CPU doing a normal operation holding this lock. The problem seems pretty theoretical, but I suppose I don't have numbers one way or another since any attempt to gather numbers would be reliant on this very mechanism. My Reviewed-by tag is already on there. -Evan
