From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AD57F19FA96 for ; Thu, 11 Jul 2024 22:47:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=140.211.166.137 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720738069; cv=none; b=u2S+axNe8NGgpSEXGK4VfizBC8XHrOw5OonXPMgz0Em0H6TFbp8cty66GJzGoOtbga1tPnre4Dkdxbfr3sHa8zpbUDgU+GHBPa5DJmRaxqdIA9UjaHgd1wL4yoBgmMyWL90FPavQnk9/i0Dgpc2u0WLywM96B0rTmh7u+qyHeVc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720738069; c=relaxed/simple; bh=RVPB+kgxEAOGVrCf+IxrqUC2VKA71l8WoyiFRqAk7bM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: In-Reply-To:Content-Type:Content-Disposition; b=eUK61OCUovLIkvrLuYliSBnXb83dL31AAs/jM8liud7O1CWkoOh8SyWFAndn6/CJuwLRA9aYoyLesE8GzftbYocxc5EbforSEoATFy1HmKJ6JEgbMwF5o2ukgxZhcz/491uwFNq+RQYUjL1wSvOVq0Pw7VPPp0UbxE0A6JFIUk0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=bvttknjC; arc=none smtp.client-ip=140.211.166.137 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="bvttknjC" Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 40A2E41599 for ; Thu, 11 Jul 2024 22:47:48 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id ln6-pzOa9tkC for ; Thu, 11 Jul 2024 22:47:47 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=170.10.129.124; helo=us-smtp-delivery-124.mimecast.com; envelope-from=peterx@redhat.com; receiver= DMARC-Filter: OpenDMARC Filter v1.4.2 smtp4.osuosl.org BC446413B1 Authentication-Results: smtp4.osuosl.org; dmarc=pass (p=none dis=none) header.from=redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org BC446413B1 Authentication-Results: smtp4.osuosl.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=bvttknjC Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by smtp4.osuosl.org (Postfix) with ESMTPS id BC446413B1 for ; Thu, 11 Jul 2024 22:47:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1720738065; 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: in-reply-to:in-reply-to:references:references; bh=jUUE4IEeDu26fE4TU1o+NLYPFE26wbQVbpeOsn3UXXI=; b=bvttknjC2R8JpP+QZEDvtKNSLbeTvlrMWMjpRPaBUEHqVmjgo4ygoj/eoNTLi9R6JAjruw nrkNYrwEJNsWs1gxCyny15H+g/5u1i4VfdxBrWDC+/0Cqk+T23zZfos2/VJlV9Dob1JayR tYG+Mmcr4pW62Z/cm2nK6YnLtgz9QuI= Received: from mail-ot1-f69.google.com (mail-ot1-f69.google.com [209.85.210.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-99-vUs3n6dzOG2QhB9vR_V48A-1; Thu, 11 Jul 2024 18:47:41 -0400 X-MC-Unique: vUs3n6dzOG2QhB9vR_V48A-1 Received: by mail-ot1-f69.google.com with SMTP id 46e09a7af769-7044d09267cso115712a34.2 for ; Thu, 11 Jul 2024 15:47:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720738060; x=1721342860; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=jUUE4IEeDu26fE4TU1o+NLYPFE26wbQVbpeOsn3UXXI=; b=Q9dBfFJx2C22nxONrfpCfk6bv9aoESLzNtPAxuOBAPTDCMvyOSxS7jBWqNHTD7izog Ds19nQqttE2Ohr1QKQ1syuKPEPWRY2p0i7/uIwMSqrPL5gmqdyF5B7didR/YFIsfupkt hSkIJLuqNJ48yakjXZJN0wTffZGFeK/R37vAACzrNdsxpiVZwqI+1XVizfusFgwRAI/n 8K+ncsQuc5c1cTwc7chHQOEvDRZhI/xZ+/6yCWWanZdCobw3EeiP2LYbtiZ2mFj4/EZL TJohHX/VztCyNZdBuDxyi8qSIwLxhK9jVMOH4tf66P07Wn0G11kGVtsztQBjTEnulG8B KaKg== X-Forwarded-Encrypted: i=1; AJvYcCX8FJf6M9jRPETCdaP41JRY1bhSTZM/CFlo/feuMhljOrRShIIYVaOJSv+8ArjCRCvczkGWpsipgCmz9xthK5WVIiZMKgY9O//zLEA27TKJ1yGx18EK025TSYIEtd3g X-Gm-Message-State: AOJu0YxCt7WDlQ2zt2nWu7bz5skt+pZ7EQkRMh0iZnZaUXRmdBjv9z9W v6tOaJy2PAvNl8N7J3PSGHPje9BB3CODO5nGezu+iC+CzTZ5x0CDWhJiSXbXA7xyDMMa804RnJS Crfo+3VmkWea6uGcxBRL0aks6thHTGA/SW49zwVI7GDktLg74XvsY3u3tbT6StUSuFdGkYOBj7V gUO8guuqMuaQ== X-Received: by 2002:a05:6870:b48b:b0:25e:dce:491b with SMTP id 586e51a60fabf-2603a6b1846mr4151084fac.1.1720738060536; Thu, 11 Jul 2024 15:47:40 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGifGQLAfLsA3PvJ0N0vhdzW8eV9Axj5BbRdepNcpr12Y+xwkO3ea+jL3/qN/UDGzQlYNNLpQ== X-Received: by 2002:a05:6870:b48b:b0:25e:dce:491b with SMTP id 586e51a60fabf-2603a6b1846mr4151066fac.1.1720738060089; Thu, 11 Jul 2024 15:47:40 -0700 (PDT) Received: from x1n (pool-99-254-121-117.cpe.net.cable.rogers.com. [99.254.121.117]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7a148df63c1sm107037485a.11.2024.07.11.15.47.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jul 2024 15:47:39 -0700 (PDT) Date: Thu, 11 Jul 2024 18:47:36 -0400 From: Peter Xu To: David Hildenbrand Cc: Pei Li , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, skhan@linuxfoundation.org, syzkaller-bugs@googlegroups.com, linux-kernel-mentees@lists.linuxfoundation.org, syzbot+35a4414f6e247f515443@syzkaller.appspotmail.com Subject: Re: [PATCH] mm: Fix mmap_assert_locked() in follow_pte() Message-ID: References: <20240710-bug12-v1-1-0e5440f9b8d3@gmail.com> <92a2dc30-6e48-44ea-9cde-693b911f200d@redhat.com> <3879ee72-84de-4d2a-93a8-c0b3dc3f0a4c@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel-mentees@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On Thu, Jul 11, 2024 at 11:51:41PM +0200, David Hildenbrand wrote: > On 11.07.24 23:45, David Hildenbrand wrote: > > On 11.07.24 23:33, David Hildenbrand wrote: > > > On 11.07.24 07:13, Pei Li wrote: > > > > This patch fixes this warning by acquiring read lock before entering > > > > untrack_pfn() while write lock is not held. > > > > > > > > syzbot has tested the proposed patch and the reproducer did not > > > > trigger any issue. > > > > > > > > Reported-by: syzbot+35a4414f6e247f515443@syzkaller.appspotmail.com > > > > Closes: https://syzkaller.appspot.com/bug?extid=35a4414f6e247f515443 > > > > Tested-by: syzbot+35a4414f6e247f515443@syzkaller.appspotmail.com > > > > Signed-off-by: Pei Li > > > > --- > > > > Syzbot reported the following warning in follow_pte(): > > > > > > > > WARNING: CPU: 3 PID: 5192 at include/linux/rwsem.h:195 rwsem_assert_held include/linux/rwsem.h:195 [inline] > > > > WARNING: CPU: 3 PID: 5192 at include/linux/rwsem.h:195 mmap_assert_locked include/linux/mmap_lock.h:65 [inline] > > > > WARNING: CPU: 3 PID: 5192 at include/linux/rwsem.h:195 follow_pte+0x414/0x4c0 mm/memory.c:5980 > > > > > > > > This is because we are assuming that mm->mmap_lock should be held when > > > > entering follow_pte(). This is added in commit c5541ba378e3 (mm: > > > > follow_pte() improvements). > > > > > > > > However, in the following call stack, we are not acquring the lock: > > > > follow_phys arch/x86/mm/pat/memtype.c:957 [inline] > > > > get_pat_info+0xf2/0x510 arch/x86/mm/pat/memtype.c:991 > > > > untrack_pfn+0xf7/0x4d0 arch/x86/mm/pat/memtype.c:1104 > > > > unmap_single_vma+0x1bd/0x2b0 mm/memory.c:1819 > > > > zap_page_range_single+0x326/0x560 mm/memory.c:1920 > > > > > > That implies that unmap_vmas() is called without the mmap lock in read > > > mode, correct? > > > > > > Do we know how this happens? > > > > > > * exit_mmap() holds the mmap lock in read mode > > > * unmap_region is documented to hold the mmap lock in read mode > > > > I think this is it (missed the call from zap_page_range_single()): > > > > follow_phys arch/x86/mm/pat/memtype.c:957 [inline] > > get_pat_info+0xf2/0x510 arch/x86/mm/pat/memtype.c:991 > > untrack_pfn+0xf7/0x4d0 arch/x86/mm/pat/memtype.c:1104 > > unmap_single_vma+0x1bd/0x2b0 mm/memory.c:1819 > > zap_page_range_single+0x326/0x560 mm/memory.c:1920 > > unmap_mapping_range_vma mm/memory.c:3684 [inline] > > unmap_mapping_range_tree mm/memory.c:3701 [inline] > > unmap_mapping_pages mm/memory.c:3767 [inline] > > unmap_mapping_range+0x1ee/0x280 mm/memory.c:3804 > > truncate_pagecache+0x53/0x90 mm/truncate.c:731 > > simple_setattr+0xf2/0x120 fs/libfs.c:886 > > notify_change+0xec6/0x11f0 fs/attr.c:499 > > do_truncate+0x15c/0x220 fs/open.c:65 > > handle_truncate fs/namei.c:3308 [inline] > > > > I think Peter recently questioned whether untrack_pfn() should be even > > called from the place, but I might misremember things. > > > > Fix should work (I suspect we are not violating some locking rules?), > > PFNMAP should not happen there too often that we really care. > > ... thinking again, likely we reach this point with "!mm_wr_locked" and the > mmap lock already held in read mode. So I suspect the fix won't work as is. Ah yes, I had one rfc patch for that, I temporarily put that aside as it seemed nobody cared except myself.. it's here: https://lore.kernel.org/all/20240523223745.395337-2-peterx@redhat.com I didn't know it can already cause real trouble. It looks like that patch should fix this. Thanks, -- Peter Xu