On Thu, Mar 30, 2023 at 1:39 AM Michal Hocko <mhocko@xxxxxxxx> wrote: > > 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. We did see hard lockups in extreme cases, and we do have setups with "nmi_watchdog=panic" that will panic when this happens, so we would rather catch the code paths that can lead to that before it actually happens. Maybe we can add a primitive like might_sleep() for this, just food for thought. > -- > Michal Hocko > SUSE Labs
