Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751653AbdLKXKD (ORCPT ); Mon, 11 Dec 2017 18:10:03 -0500 Received: from mail-it0-f47.google.com ([209.85.214.47]:44139 "EHLO mail-it0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750836AbdLKXKB (ORCPT ); Mon, 11 Dec 2017 18:10:01 -0500 X-Google-Smtp-Source: ACJfBosm6QufIA9B19gwlMFNMzWWzcoeRcN0xBJLKgHnnQw/4FDeva8TyBDlmZM5SlVyVpI+ATY7Jw== Date: Mon, 11 Dec 2017 15:09:58 -0800 (PST) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Paolo Bonzini cc: Andrew Morton , Michal Hocko , Andrea Arcangeli , Benjamin Herrenschmidt , Paul Mackerras , Oded Gabbay , Alex Deucher , =?UTF-8?Q?Christian_K=C3=B6nig?= , David Airlie , Joerg Roedel , Doug Ledford , Jani Nikula , Mike Marciniszyn , Sean Hefty , Dimitri Sivanich , Boris Ostrovsky , =?UTF-8?Q?J=C3=A9r=C3=B4me_Glisse?= , =?UTF-8?Q?Radim_Kr=C4=8Dm=C3=A1=C5=99?= , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [patch 1/2] mm, mmu_notifier: annotate mmu notifiers with blockable invalidate callbacks In-Reply-To: <40828fec-a375-fb90-f4f1-fc647651c2f7@redhat.com> Message-ID: References: <40828fec-a375-fb90-f4f1-fc647651c2f7@redhat.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1244 Lines: 29 On Mon, 11 Dec 2017, Paolo Bonzini wrote: > > Commit 4d4bbd8526a8 ("mm, oom_reaper: skip mm structs with mmu notifiers") > > prevented the oom reaper from unmapping private anonymous memory with the > > oom reaper when the oom victim mm had mmu notifiers registered. > > > > The rationale is that doing mmu_notifier_invalidate_range_{start,end}() > > around the unmap_page_range(), which is needed, can block and the oom > > killer will stall forever waiting for the victim to exit, which may not > > be possible without reaping. > > > > That concern is real, but only true for mmu notifiers that have blockable > > invalidate_range_{start,end}() callbacks. This patch adds a "flags" field > > for mmu notifiers that can set a bit to indicate that these callbacks do > > block. > > Why not put the flag in the ops, since the same ops should always be > either blockable or unblockable? > Hi Paolo, It certainly can be in mmu_notifier_ops, the only rationale for putting the flags member in mmu_notifier was that it may become generally useful later for things other than callbacks. I'm indifferent to where it is placed and will happily move it if that's desired, absent any other feedback on other parts of the patchset. Thanks.