On Thu 30-03-23 01:19:29, Yosry Ahmed wrote: > On Thu, Mar 30, 2023 at 1:15 AM Michal Hocko <mhocko@xxxxxxxx> wrote: > > > > On Thu 30-03-23 01:06:26, Yosry Ahmed wrote: > > [...] > > > If we achieve that, do you think it makes sense to add > > > WARN_ON_ONCE(irqs_disabled()) instead to prevent future users from > > > flushing while disabling irqs or in irq context? > > > > WARN_ON (similar to BUG_ON) will not prevent anybody from doing bad > > things. We already have means to shout about sleepable code being > > invoked from an atomic context and there is no reason to duplicate that. > > As I've said earlier WARN_ON might panic the system in some > > configurations (and yes they are used also in production systems - do > > not ask me why...). So please be careful about that and use that only > > when something really bad (yet recoverable) is going on. > > Thanks for the information (I was about to ask why about production > systems, but okay..). I will avoid WARN_ON completely. For the > purposes of this series I will drop this patch anyway. Thanks! People do strange things sometimes... > Any idea how to shout about "hey this may take too long, why are you > doing it with irqs disabled?!"? Well we have a hard lockup detector. It hits at a much higher stall by default but if you care about IRQ latencies in general then you likely want to lower. Another thing would be IRQ tracing. In any case this code path shouldn't be any special. Sure it can take long on large systems but I bet there are more of those. -- Michal Hocko SUSE Labs
