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 690C2C2BD09 for ; Sat, 13 Jul 2024 01:18:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D8D6A6B008C; Fri, 12 Jul 2024 21:18:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D3E6B6B0092; Fri, 12 Jul 2024 21:18:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BDD506B0095; Fri, 12 Jul 2024 21:18:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id A1D596B008C for ; Fri, 12 Jul 2024 21:18:27 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1CD43160D68 for ; Sat, 13 Jul 2024 01:18:27 +0000 (UTC) X-FDA: 82332969054.07.989B962 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf28.hostedemail.com (Postfix) with ESMTP id E64EDC0006 for ; Sat, 13 Jul 2024 01:18:23 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AyCwcHDe; spf=pass (imf28.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720833487; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=yg3PnT1gxuKol1jHQF+qBk4w5qitgE0wByJpI44X15g=; b=gnZmYe0ivo2XvYSbTrBlgQOpAknWp7GhmmmPHBWzYxJyf/BRO16/CQpkcTq90vQMpFN4Sf b1eHllDG7K4yIRKaYoDT2mdkpiBr6onQerf6xCQ29LBzFgWaI3JE/CZByYZBdskQ3OXoLK wmqhjjAO6WibnP//CSucIZ68TLPap4Q= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AyCwcHDe; spf=pass (imf28.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720833487; a=rsa-sha256; cv=none; b=gQf/FGKg18sYIGmRfQLM7zdhyNldP0unL68CzMO9AsVpqObUx76ffFn6S466ZTWGshoTwS Bblqc7Ty5EIN24crpH08W1A/82ORwt75W9F6NoO9v8zNGPsCRw9GDS/Ohd8xWUsXHV21/2 J5vcxh45h93kW6BTx3//oW2E6v4uS9w= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1720833503; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=yg3PnT1gxuKol1jHQF+qBk4w5qitgE0wByJpI44X15g=; b=AyCwcHDe32nqHQaYG5xZw5OSw4Wd/0/n4dtpS7uSEnKv/NWEz0X9C4e1lbrUfb3dR9MXpu QfeOukDgIJm9jITTbLCJ2G6RvA7yum2zXZXPJJxaWNmz4t4BL8Lphs1WszHqwBTdv/Gn3X rJhwgyWr/q0EjXxqPo7pQGwUBEQwJ+E= Received: from mail-pl1-f200.google.com (mail-pl1-f200.google.com [209.85.214.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-39-Zi7iL1MUNC6Wh6SiEKNDRg-1; Fri, 12 Jul 2024 21:18:21 -0400 X-MC-Unique: Zi7iL1MUNC6Wh6SiEKNDRg-1 Received: by mail-pl1-f200.google.com with SMTP id d9443c01a7336-1fb294a0915so20004765ad.1 for ; Fri, 12 Jul 2024 18:18:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720833500; x=1721438300; h=content-transfer-encoding:in-reply-to:organization:autocrypt :content-language:from:references:cc:to:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=yg3PnT1gxuKol1jHQF+qBk4w5qitgE0wByJpI44X15g=; b=EaMxjLBwHNiHRorRZMTNqlGLOkSAxQWnda39C/CB99hGbfbmdNO7CXx83LJ6Mbg/rP 7jviEj6diTfHiF5woxbvUILwnKF0BDRsUcO4lCNcbiCwe9/Pd2QTGz5BwjNNxP1KA5k/ U9C4yGczWbA9/jR5rVMVujVJtsRzvopnZ6CVPfIW44x7eHKBXcpVuELusilzJh7UKoFd OfcNOCzleRp/HyX6CpiDQgWf/uvGC1TcebYiG8+yCjV2g+ctnE5zCd9ItaFxNqQmJSuc RI6sf+h8sGNmw02/xQpLi+7ZUzvf7jX8eyn0DAL0zJJcFtGJTIByogk7w4ZeojFDukD6 z91Q== X-Forwarded-Encrypted: i=1; AJvYcCXCbn6vQBL5LRhMSxwCuN3XoOZB5W8aQIeGHNNNktIOoHEywLTNlwgHW7enN4S0XyXmEgGVV8DZF9iB+Pmy0I7Idx0= X-Gm-Message-State: AOJu0YwmtVjFFssu4E/NcyFqeJGtp6msx3Cqv90A5ST5dyKSasZLsgat 2BC4zeCza/x5v7JrVtIh0GwSa8T+fA8LJZtuUb6PXhxj+JWGKGIbpyhazqcmzT9tdArbA76dyCL NEcEcO370DlMdLJZwS+aIM8rQZfpIHBlQPOwNJGWnBkxaPzde X-Received: by 2002:a17:902:e74b:b0:1fb:9cbf:b4e3 with SMTP id d9443c01a7336-1fc0b58dabfmr3965455ad.22.1720833500584; Fri, 12 Jul 2024 18:18:20 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH+1jtEh2mTJyPIQQfuZSo++BlCWGQeaMWBJdJnKzCTi4OX+RWimSnqxG7zdl9lg2VSucVdWg== X-Received: by 2002:a17:902:e74b:b0:1fb:9cbf:b4e3 with SMTP id d9443c01a7336-1fc0b58dabfmr3965175ad.22.1720833500166; Fri, 12 Jul 2024 18:18:20 -0700 (PDT) Received: from [172.20.2.228] ([4.28.11.157]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1fc0bb6fdc9sm661685ad.52.2024.07.12.18.18.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Jul 2024 18:18:19 -0700 (PDT) Message-ID: <52c8e760-1747-4ca2-97bd-77818bcc8926@redhat.com> Date: Sat, 13 Jul 2024 03:18:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/x86/pat: Only untrack the pfn range if unmap region To: Peter Xu , linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: Andrew Morton , Alex Williamson , Jason Gunthorpe , Al Viro , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "Kirill A . Shutemov" , x86@kernel.org, Yan Zhao , Kevin Tian , Pei Li , David Wang <00107082@163.com>, Bert Karwatzki , Sergey Senozhatsky References: <20240712144244.3090089-1-peterx@redhat.com> From: David Hildenbrand Autocrypt: addr=david@redhat.com; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q 9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4 3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs 9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF 89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9 M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A 2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75 7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx 5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3 AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq 3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6 3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8 kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt WNyWQQ== Organization: Red Hat In-Reply-To: <20240712144244.3090089-1-peterx@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: E64EDC0006 X-Stat-Signature: gzxzu7sczb5mt8jdd8i6ifupuw367pac X-HE-Tag: 1720833503-803695 X-HE-Meta: U2FsdGVkX1+nX61nSZmkpIWbIE8E5Extt/JORTQyjFiKY4qs+WHZmHlbg/UKOMdSL/0FMBqizuvv14ikxxlj/Xm89iA2w8AAfyfXJxbW58aIHS6LeMwZrTE1rALKvWb95uj8li3E28C3SBGyrcAZoLiMphxmMI5RJEpPEBfcU7rkEcIRRQceOR/mv+szN18jI5/cBX5onOXZkPxGsqeUafhlkwLWahgRlWQbFdrgjaYeZZiB7n/bLyytZV1e9yRBw2zJ3BAvF8gPBTQ7QqqkrR/MSZ3sGMl6hA4QUNzGwNp4jCkVC3BhxCEOh/UYKTriHXU9XDHJu2GfwBZqK5fKEFN/usphL7leHGWkawGyq7S3XwnnvCe/tldrfXYw6MBq0tF2AiCgAcXbJE0ztTLpasdYvCDainCRO2thac+SnEhSfr3axXngJyeg14wr/U2TK0f2rGKSENy3uTjso+v+Yr1Dcm6nd2B4d9VisUWVCUMrbZx1fELO/6y8G2eMd586eOsNCPG/aR7/LleXVT2NFZnpHGvQyZ5bulpQS93y1DW6eAwzbO1jnMiyBAOAcLJqBHWROncJ0kdUCqPB8azHpNR8HyzaoWgfDgiq0h2EpuF3eOp2/BabnKBNVxMm0kwtYyMDPJJKSGaFL1IbDqL+43uQX+bk/OI/BipkdOaxpOq/Ldz4q2WSeR0aSSTRbE1RP6ZA2h0v9JTS4b0Clm66qFgfapi60nHzMK9uRhcmIcyL1yzTO+aXAEoE4BcIDbo7g6uwd5dXEM0x+dxCiV+2ckhIpQHf1HnIs6hGBfYqYx+6pncjK+nGd0MB8xYa3xas198C32wCQoY4ryG+SwQqM5+fKzDFJ3HryaGJc24933vku0qsruJ5yYximxHJGn5u2YbMZXBFGHRPBnwoF0NewUA0bnWFM08S524ICXo3sSDJbJ/k8McLNzRWZMjR3V10L7xupNKkDMbUdmTbgMd nA+Va0IZ 5+tFDNoSOqwWDEziCxWusdJnbE5SuxtgcuQtS6bobhdcCvD92EQjWjWXLcITR9rkFtqNuHdxzPtnzTXcvc+FHD+w5SZtJY/KWSsrVj7xJApB9t3g8lGsgIIJLS64Q7XyMtMF1NDDBzfOSgpm4o6PHQgiAP1yZ5KGdlJx0tvqP2L3G7uw2dlBsUusC/pLEq75ANuG+G/bP0RjVDBM21bJ6effRzzcM/2LWtPwt+gEVoJCmC85GMQoiqZNb3+HBzVQ2IKSnhWhF0wEmvzS2jVRdYuF5Biz15+7coEqSpCL5oRWr7Z4s8VbTJ5yGtfbvxkLmrJlc6z5mjMo+WWoNwZ4dObtGWten6cMmRGDPC7OtOGoc8bdPgKuXGIng2fdusDKG+rYObStXVratmkGVrKk8PMjZ7zMthL9bXBDURSuCiVi1Rjyu+6leaW3NaXJFxskhCj1yKlpW+dyjAF+N3Vora7Qpt1VzNmsqzvY2VO07x3Tqs1QJy+nW/Zz1KyRt2A57OqP+9+UytPrMYVcMJtkRMU92Pu7eFlbQbEtMju+ssCkl4kNgY9cD+F1F3udbcoQ1aV++RmWQJcEhiJTbQACNIQqupDiv2kvIusdfCN0/LWXvg9gSeJu14mmoa8GuL03mBoN4PZdbPGooRbrxGobK4OZ9mqq25o90VkMC81v6kK9RkHP/anZsiU2zNbRFHNxzh8IGP6x5FhIHkpoXEFUT47u+nb6P8KJtXDHMW5wSLY6t8ogrGwio/61GWLAMM3lI87L4vTLJ9roYrcale2kHT10L1RAWqJZzkABRLytPSqi5GYt9hpoHMyderZpc+8utX5DdXa4cKZhD+Nk= 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: List-Subscribe: List-Unsubscribe: On 12.07.24 16:42, Peter Xu wrote: > This patch is one patch of an old series [1] that got reposted standalone > here, with the hope to fix some reported untrack_pfn() issues reported > recently [2,3], where there used to be other fix [4] but unfortunately > which looks like to cause other issues. The hope is this patch can fix it > the right way. > > X86 uses pfn tracking to do pfnmaps. AFAICT, the tracking should normally > start at mmap() of device drivers, then untracked when munmap(). However > in the current code the untrack is done in unmap_single_vma(). This might > be problematic. > > For example, unmap_single_vma() can be used nowadays even for zapping a > single page rather than the whole vmas. It's very confusing to do whole > vma untracking in this function even if a caller would like to zap one > page. It could simply be wrong. > > Such issue won't be exposed by things like MADV_DONTNEED won't ever work > for pfnmaps and it'll fail the madvise() already before reaching here. > However looks like it can be triggered like what was reported where invoked > from an unmap request from a file vma. > > There's also work [5] on VFIO (merged now) to allow tearing down MMIO > pgtables before an munmap(), in which case we may not want to untrack the > pfns if we're only tearing down the pgtables. IOW, we may want to keep the > pfn tracking information as those pfn mappings can be restored later with > the same vma object. Currently it's not an immediate problem for VFIO, as > VFIO uses UC- by default, but it looks like there's plan to extend that in > the near future. > > IIUC, this was overlooked when zap_page_range_single() was introduced, > while in the past it was only used in the munmap() path which wants to > always unmap the region completely. E.g., commit f5cc4eef9987 ("VM: make > zap_page_range() callers that act on a single VMA use separate helper") is > the initial commit that introduced unmap_single_vma(), in which the chunk > of untrack_pfn() was moved over from unmap_vmas(). > > Recover that behavior to untrack pfnmap only when unmap regions. > > [1] https://lore.kernel.org/r/20240523223745.395337-1-peterx@redhat.com > [2] https://groups.google.com/g/syzkaller-bugs/c/FeQZvSbqWbQ/m/tHFmoZthAAAJ > [3] https://lore.kernel.org/r/20240712131931.20207-1-00107082@163.com > [4] https://lore.kernel.org/all/20240710-bug12-v1-1-0e5440f9b8d3@gmail.com/ > [5] https://lore.kernel.org/r/20240523195629.218043-1-alex.williamson@redhat.com > > Cc: Alex Williamson > Cc: Jason Gunthorpe > Cc: Al Viro > Cc: Dave Hansen > Cc: Andy Lutomirski > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: Borislav Petkov > Cc: Kirill A. Shutemov > Cc: x86@kernel.org > Cc: Yan Zhao > Cc: Kevin Tian > Cc: Pei Li > Cc: David Hildenbrand > Cc: David Wang <00107082@163.com> > Cc: Bert Karwatzki > Cc: Sergey Senozhatsky > Signed-off-by: Peter Xu > --- > > NOTE: I massaged the commit message comparing to the rfc post [1], the > patch itself is untouched. Also removed rfc tag, and added more people > into the loop. Please kindly help test this patch if you have a reproducer, > as I can't reproduce it myself even with the syzbot reproducer on top of > mm-unstable. Instead of further check on the reproducer, I decided to send > this out first as we have a bunch of reproducers on the list now.. > --- > mm/memory.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/mm/memory.c b/mm/memory.c > index 4bcd79619574..f57cc304b318 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -1827,9 +1827,6 @@ static void unmap_single_vma(struct mmu_gather *tlb, > if (vma->vm_file) > uprobe_munmap(vma, start, end); > > - if (unlikely(vma->vm_flags & VM_PFNMAP)) > - untrack_pfn(vma, 0, 0, mm_wr_locked); > - > if (start != end) { > if (unlikely(is_vm_hugetlb_page(vma))) { > /* > @@ -1894,6 +1891,8 @@ void unmap_vmas(struct mmu_gather *tlb, struct ma_state *mas, > unsigned long start = start_addr; > unsigned long end = end_addr; > hugetlb_zap_begin(vma, &start, &end); > + if (unlikely(vma->vm_flags & VM_PFNMAP)) > + untrack_pfn(vma, 0, 0, mm_wr_locked); > unmap_single_vma(tlb, vma, start, end, &details, > mm_wr_locked); > hugetlb_zap_end(vma, &details); Yes, I would prefer that, and it makes sense to me. Should we then have a "Fixes:" tag (at least my commit, maybe the original commit that made this also be called in wrong context)? Acked-by: David Hildenbrand -- Cheers, David / dhildenb