On Mon, Apr 3, 2023 at 1:38 AM Michal Hocko <mhocko@xxxxxxxx> wrote: > > On Fri 31-03-23 12:03:47, Yosry Ahmed wrote: > > On Fri, Mar 31, 2023 at 4:02 AM Michal Hocko <mhocko@xxxxxxxx> wrote: > > > > > > On Thu 30-03-23 01:53:38, Yosry Ahmed wrote: > > > [...] > > > > Maybe we can add a primitive like might_sleep() for this, just food for thought. > > > > > > I do not think it is the correct to abuse might_sleep if the function > > > itself doesn't sleep. If it does might_sleep is already involved. > > > > Oh, sorry if I wasn't clear, I did not mean to reuse might_sleep() -- > > I meant introducing a new similar debug primitive that shouts if irqs > > are disabled. > > This is circling back to original concerns about arbitrary decision to > care about IRQs. Is this really any different from spin locks or preempt > disabled critical sections preventing any scheduling and potentially > triggereing soft lockups? Not really, I am sure there are other code paths that may cause similar problems. At least we can start annotating them so that we don't regress them (e.g. by introducing a caller that disables irqs -- converting them into hard lockups). > -- > Michal Hocko > SUSE Labs