On 7/19/24 12:52 PM, Michal Hocko wrote: > On Fri 19-07-24 12:10:13, Vlastimil Babka wrote: >> On 7/19/24 11:33 AM, Michal Hocko wrote: >> > On Fri 19-07-24 10:50:07, Vlastimil Babka wrote: >> > [...] >> >> That wouldn't mean the busy loop is a correct and supported practice. It >> >> would just mean it's the least bad of the bad options we have to deal with >> >> an allocation that's wrong but we didn't catch soon enough in the development. >> > >> > So you want to make those potential BUG_ONs hard/soft lockups (not sure >> > all arches have a reliable detection) instead? >> >> I'd expect on a SMP machine there's fair chance of being rescued by kswapd >> or other direct reclaimer. > > I would expect hard/soft lockups... Anyway, the question remains. What > is the preferred way to express this is not really supported scenario. The documentation and warnings? I don't think the warnings are failing us fundamentally. We could limit the corner cases where the are not being reached in case a buggy code is being executed (maybe only in some debug config if the checks would be too intrusive for a fast path otherwise). That would leave the corner cases where the buggy code is executed rarely. Maybe Christoph's suggestion for a build-time check would catch some of those.
