From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 32412C433F5 for ; Thu, 3 Mar 2022 14:23:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8A85A8D0002; Thu, 3 Mar 2022 09:23:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 858B38D0001; Thu, 3 Mar 2022 09:23:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 748648D0002; Thu, 3 Mar 2022 09:23:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 61AD68D0001 for ; Thu, 3 Mar 2022 09:23:58 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 34B3D2545B for ; Thu, 3 Mar 2022 14:23:58 +0000 (UTC) X-FDA: 79203294156.01.F6DC127 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf18.hostedemail.com (Postfix) with ESMTP id 6C0751C0012 for ; Thu, 3 Mar 2022 14:23:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=xhpDNXXrUENoRW8oouM6cOT2aBxbIx77sOMKklVUAFQ=; b=ijiJ7KGrUpn+dfSISyWBMQjjC4 kp1GjP6Ap/LG4Z+OB4w3m8TMtAIfVKALFyY8V+/vF3FZneFdBhq9PyE+scYyzITTFqMsLlgKJjjnj WaEr1Csw18MQZNaKR7sS8Rg77uMacrBznpECmiF3gBQJo78xcSfZTz35e0pr6ldhpC3WgGoa4wN/9 QfdVY9cE/H7LcRRRI3HItC1OavLuPWkE3dGo21cdHRGKMB3JlWCu6pfYl3eVekO+hi7ehlw0ERCby JdkUIeYt9WLASGGhUTRsTcDYKXp0I1MUoefxM4m9LvtZzM2BT97GPL0sqIId07F0Os22gQaAgwpN+ pCfqOnYg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nPmMz-00BiCQ-0o; Thu, 03 Mar 2022 14:23:53 +0000 Date: Thu, 3 Mar 2022 14:23:52 +0000 From: Matthew Wilcox To: Hugh Dickins Cc: Andrew Morton , Vlastimil Babka , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH mmotm] mm/munlock: mlock_vma_folio() check against VM_SPECIAL Message-ID: References: <9b95d366-1719-f8e2-a5a3-429f9e808288@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9b95d366-1719-f8e2-a5a3-429f9e808288@google.com> X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 6C0751C0012 X-Stat-Signature: fwcmc1rrhtxop9ipibgb4qgswj5it8kk Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ijiJ7KGr; spf=none (imf18.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-HE-Tag: 1646317437-282431 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Mar 02, 2022 at 05:35:30PM -0800, Hugh Dickins wrote: > Although mmap_region() and mlock_fixup() take care that VM_LOCKED > is never left set on a VM_SPECIAL vma, there is an interval while > file->f_op->mmap() is using vm_insert_page(s), when VM_LOCKED may > still be set while VM_SPECIAL bits are added: so mlock_vma_folio() > should ignore VM_LOCKED while any VM_SPECIAL bits are set. > > This showed up as a "Bad page" still mlocked, when vfree()ing pages > which had been vm_inserted by remap_vmalloc_range_partial(): while > release_pages() and __page_cache_release(), and so put_page(), catch > pages still mlocked when freeing (and clear_page_mlock() caught them > when unmapping), the vfree() path is unprepared for them: fix it? > but these pages should not have been mlocked in the first place. > > I assume that an mlockall(MCL_FUTURE) had been done in the past; or > maybe the user got to specify MAP_LOCKED on a vmalloc'ing driver mmap. > > Signed-off-by: Hugh Dickins > --- > Diffed against top of next-20220301 or mmotm 2022-02-28-14-45. > This patch really belongs as a fix to the mm/munlock series in > Matthew's tree, so he might like to take it in there (but the patch > here is the foliated version, so easiest to place it after foliation). It looks like it fixes "mm/munlock: mlock_pte_range() when mlocking or munlocking", so I'll fold it into that patch? > mm/internal.h | 11 +++++++++-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > --- a/mm/internal.h > +++ b/mm/internal.h > @@ -421,8 +421,15 @@ extern int mlock_future_check(struct mm_struct *mm, unsigned long flags, > static inline void mlock_vma_folio(struct folio *folio, > struct vm_area_struct *vma, bool compound) > { > - /* VM_IO check prevents migration from double-counting during mlock */ > - if (unlikely((vma->vm_flags & (VM_LOCKED|VM_IO)) == VM_LOCKED) && > + /* > + * The VM_SPECIAL check here serves two purposes. > + * 1) VM_IO check prevents migration from double-counting during mlock. > + * 2) Although mmap_region() and mlock_fixup() take care that VM_LOCKED > + * is never left set on a VM_SPECIAL vma, there is an interval while > + * file->f_op->mmap() is using vm_insert_page(s), when VM_LOCKED may > + * still be set while VM_SPECIAL bits are added: so ignore it then. > + */ > + if (unlikely((vma->vm_flags & (VM_LOCKED|VM_SPECIAL)) == VM_LOCKED) && > (compound || !folio_test_large(folio))) > mlock_folio(folio); > }