On Mon 02-10-17 17:29:47, Michael S. Tsirkin wrote: > On Mon, Oct 02, 2017 at 04:19:00PM +0200, Michal Hocko wrote: > > On Mon 02-10-17 17:11:55, Michael S. Tsirkin wrote: > > > On Mon, Oct 02, 2017 at 01:50:35PM +0200, Michal Hocko wrote: > > [...] > > > > and some > > > > other call path is allocating while holding the lock. But you seem to be > > > > right and > > > > leak_balloon > > > > tell_host > > > > virtqueue_add_outbuf > > > > virtqueue_add > > > > > > > > can do GFP_KERNEL allocation and this is clearly wrong. Nobody should > > > > try to allocate while we are in the OOM path. Michael, is there any way > > > > to drop this? > > > > > > Yes - in practice it won't ever allocate - that path is never taken > > > with add_outbuf - it is for add_sgs only. > > > > > > IMHO the issue is balloon inflation which needs to allocate > > > memory. It does it under a mutex, and oom handler tries to take the > > > same mutex. > > > > try_lock for the oom notifier path should heal the problem then, righ? > > At least for as a quick fix. > > IMHO it definitely fixes the deadlock. But it does not fix the bug > that balloon isn't sometimes deflated on oom even though the deflate on > oom flag is set. Yes, that would require a more sophisticated fix. And I would argue that would require to drop oom handler and move deflate logic to a shrinker to better scale with the memory pressure rather than act on the very last moment. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
