From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752140AbdIMNSd (ORCPT ); Wed, 13 Sep 2017 09:18:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57910 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751995AbdIMNSc (ORCPT ); Wed, 13 Sep 2017 09:18:32 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 71EB7806B1 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=aarcange@redhat.com Date: Wed, 13 Sep 2017 15:18:30 +0200 From: Andrea Arcangeli To: Michal Hocko Cc: Andrew Morton , linux-mm@kvack.org, LKML , Michal Hocko Subject: Re: [PATCH] mm, oom_reaper: skip mm structs with mmu notifiers Message-ID: <20170913131830.GA12833@redhat.com> References: <20170913113427.2291-1-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170913113427.2291-1-mhocko@kernel.org> User-Agent: Mutt/1.9.0 (2017-09-02) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 13 Sep 2017 13:18:32 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 13, 2017 at 01:34:27PM +0200, Michal Hocko wrote: > From: Michal Hocko > > Andrea has noticed that the oom_reaper doesn't invalidate the range > via mmu notifiers (mmu_notifier_invalidate_range_start, > mmu_notifier_invalidate_range_end) and that can corrupt the memory > of the kvm guest for example. > > tlb_flush_mmu_tlbonly already invokes mmu notifiers but that is not > sufficient as per Andrea: > : mmu_notifier_invalidate_range cannot be used in replacement of > : mmu_notifier_invalidate_range_start/end. For KVM > : mmu_notifier_invalidate_range is a noop and rightfully so. A MMU > : notifier implementation has to implement either > : ->invalidate_range method or the invalidate_range_start/end > : methods, not both. And if you implement invalidate_range_start/end > : like KVM is forced to do, calling mmu_notifier_invalidate_range in > : common code is a noop for KVM. > : > : For those MMU notifiers that can get away only implementing > : ->invalidate_range, the ->invalidate_range is implicitly called by > : mmu_notifier_invalidate_range_end(). And only those secondary MMUs > : that share the same pagetable with the primary MMU (like AMD > : iommuv2) can get away only implementing ->invalidate_range. > > As the callback is allowed to sleep and the implementation is out > of hand of the MM it is safer to simply bail out if there is an > mmu notifier registered. In order to not fail too early make the > mm_has_notifiers check under the oom_lock and have a little nap before > failing to give the current oom victim some more time to exit. > > Changes since v1 > - move mm_has_notifiers check after we hold mmap_sem to prevent from > any potential races as per Andrea > > Fixes: aac453635549 ("mm, oom: introduce oom reaper") > Noticed-by: Andrea Arcangeli > Cc: stable > Signed-off-by: Michal Hocko > --- > Hi, > I have posted this as an RFC previously [1]. I have updated > the changelog to be more clear about the issue and moved the > mm_has_notifiers after the lock has been take based on Andrea's > suggestion. > > Can we merge this? > > [1] http://lkml.kernel.org/r/20170830084600.17491-1-mhocko@kernel.org > > include/linux/mmu_notifier.h | 5 +++++ > mm/oom_kill.c | 16 ++++++++++++++++ > 2 files changed, 21 insertions(+) Reviewed-by: Andrea Arcangeli