From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f48.google.com (mail-qv1-f48.google.com [209.85.219.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 36FDDEAD0 for ; Mon, 30 Dec 2024 18:31:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735583517; cv=none; b=HRBJLF8s7Bb8trPQGpfkCJNHdYBWdCYw4a8jMa4OI0+kFOQSboYTy91ZQyLhFwZeUy8J+0lJrFnaOsd7X3Oj7mIV0aGafIVkPVUAIZG0rRGgERGwf4aaq1x7Y8T/Bn/dvXG2udPsQJL+nxHvoU8h9a80PP6bD/9GENwiIp833xo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735583517; c=relaxed/simple; bh=xy7Nkz4Ige3kE+ypFD9jXAdo9kQduInWpNmMyoTwsuY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MeF/PiRnw+HaIo5fkc/1lK6wosCD+wL1QCGiC3Si+es4jqZ0x4iGOUeGREKsTc5G2enCgZgTrvc36CaDdZBTTCRiBOdA3lkS6ieePX/1mJ4YQDPds/XodC+3pzfLxYV9pevjBK9SKzIP/PuKyoctUCPR16DzYeE2qWOISEdp/qo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=An6o5y2U; arc=none smtp.client-ip=209.85.219.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="An6o5y2U" Received: by mail-qv1-f48.google.com with SMTP id 6a1803df08f44-6dce7263beaso83004436d6.3 for ; Mon, 30 Dec 2024 10:31:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735583515; x=1736188315; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:from:to:cc:subject:date :message-id:reply-to; bh=Znj6WT/zByf3CnckeyJOMBKUU1iL6sEgvxq3Qt66pRs=; b=An6o5y2UD7nMRibpWBtmZgZ3lV4hJ+ND+TxbhIbCi4BChN6UO4HjDLceoZssgG6pBe Gkklcm+xydWvE4DTjPbUBqecM2ZzNbOcLCP1MO6Vi9NiZdsskYaupLKjoNtIkx69F0pj QjEWSM19fhXfDKN1oBxdIKvoRrYFiM17Ss3JK8rmL3ueixJKNETC111m1oH+jy0RV5ey 15pKVOT5Y915/JwmyaaFApRaKM87sd8Zd5AGxlLPloe2ATRFtJRTrJjny9CJ2/EyIPR3 Rtw6Vt5ReBNxToaugfhwU3hPIMNUuUbL4TuGY3PchpB8thZw8B3TAz1Vo5KAo2xeIGEM foGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735583515; x=1736188315; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Znj6WT/zByf3CnckeyJOMBKUU1iL6sEgvxq3Qt66pRs=; b=vMdlTLtWKzZtV/vKzgCvqeJkrjzIvgAkF4v6EEXTvRyrUu1Eo8Lz23vG8EfM03laQP HidbIen5iRWW1P7+eyFifm/kG4aDBjHD1lJIp/XwGs4dJVXrfrbijw0SF/A2an9hlej4 9WpgWJcUOPgxRDKJM13E2/rUiHLAjESqY6UeibO+zpMygBekGyKm1OJrK+7MNbt1yrVV Z8Uq1ZVwSlw0/N5N42VK1KPgZEpyAd2u5rd7emMJcFCgxY/DhQd56KX7qoBUTy+zPjX+ R3RbIQw717dLIXN/6aq8ewcM7LWZ2YYUENfmy8CgHGGTa6x5lucjaUYAuwJBQmu2qzXo MQpg== X-Forwarded-Encrypted: i=1; AJvYcCUakiNZH4rv4pfA4eCIfz0eOxUfh5CIgu1l3UBTKZFROw+QRy4DxNdfJn2aBP2DAVavo3yXxAOLx9RdwfI=@vger.kernel.org X-Gm-Message-State: AOJu0YxUV+bhvNMOkMRL6bRm7tDNoU58obMd5j+YlYYo9E6H+bfXJ9os uwrwh8GyFxw7mrzW/9FYIYTQwag5SBOGQjIEqdJ/RgPVk5O951Uv X-Gm-Gg: ASbGncs21J+Zty5pkeQmpg+9B8tg0Iiu88c0ii6/ZJvqpQ/J+4Cs4Kz4wChf4Yj1nUl ydbLj74VlhxENPg5oCVmd12AT1Osm2L1ZGAWarQHQ2ZxXsj0UL+eeBViCl/VXeJiu6c+gIfFkwD kPgjyFA4oGj5NrAYwsmgpTQMI3dk2LWkLNkXGJzK2X7+pPzVZ0z8TFY0UNrlSLv2rimK6PD1h5U RzIGz+TguSypbVYmAO/7aE6GI3WDDok3HRWRcs2IQRiITX+qE7qchU6VL4xrp0FaMsANJG5rUhj 4HQ2+Vk62rfgLQ6KtRqrpS2rXxtAzTqLKpQUJnRXprdRoLI= X-Google-Smtp-Source: AGHT+IFV+eJsoDTMPI/oYrVIh0W6q1HPPNWxrDYkLep2Oqo6fjUmYhr2uqMje9O7RHmyy1nMfSMRhA== X-Received: by 2002:a05:6214:8112:b0:6dd:597e:c471 with SMTP id 6a1803df08f44-6dd597ec9b3mr232721546d6.47.1735583515135; Mon, 30 Dec 2024 10:31:55 -0800 (PST) Received: from fauth-a1-smtp.messagingengine.com (fauth-a1-smtp.messagingengine.com. [103.168.172.200]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6dd18137367sm104696626d6.65.2024.12.30.10.31.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Dec 2024 10:31:54 -0800 (PST) Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfauth.phl.internal (Postfix) with ESMTP id 7B258120006E; Mon, 30 Dec 2024 13:31:54 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Mon, 30 Dec 2024 13:31:54 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddruddviedguddugecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddv necuhfhrohhmpeeuohhquhhnucfhvghnghcuoegsohhquhhnrdhfvghnghesghhmrghilh drtghomheqnecuggftrfgrthhtvghrnhephedugfduffffteeutddvheeuveelvdfhleel ieevtdeguefhgeeuveeiudffiedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepsghoqhhunhdomhgvshhmthhprghuthhhphgvrhhsohhnrghl ihhthidqieelvdeghedtieegqddujeejkeehheehvddqsghoqhhunhdrfhgvnhhgpeepgh hmrghilhdrtghomhesfhhigihmvgdrnhgrmhgvpdhnsggprhgtphhtthhopeelpdhmohgu vgepshhmthhpohhuthdprhgtphhtthhopehsuhhrvghnsgesghhoohhglhgvrdgtohhmpd hrtghpthhtohephhgurghnthhonhesshhinhgrrdgtohhmpdhrtghpthhtohepshihiigs ohhtodduudejtddukeefkeguugegvdegvdekrggsjegsfeesshihiihkrghllhgvrhdrrg hpphhsphhothhmrghilhdrtghomhdprhgtphhtthhopehpvghnghhuihhnqdhkvghrnhgv lhesihdqlhhovhgvrdhsrghkuhhrrgdrnhgvrdhjphdprhgtphhtthhopegvughumhgrii gvthesghhoohhglhgvrdgtohhmpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehv ghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqmhhmsehkvhgrtg hkrdhorhhgpdhrtghpthhtohepshihiihkrghllhgvrhdqsghughhssehgohhoghhlvghg rhhouhhpshdrtghomhdprhgtphhtthhopegsohhquhhnsehfihigmhgvrdhnrghmvg X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 30 Dec 2024 13:31:53 -0500 (EST) Date: Mon, 30 Dec 2024 10:31:22 -0800 From: Boqun Feng To: Suren Baghdasaryan Cc: Hillf Danton , syzbot , Tetsuo Handa , edumazet@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com Subject: Re: [syzbot] [net?] possible deadlock in vm_insert_page Message-ID: References: <676ea4aa.050a0220.2f3838.0483.GAE@google.com> <20241228001926.517-1-hdanton@sina.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Dec 30, 2024 at 10:22:27AM -0800, Suren Baghdasaryan wrote: [...] > > > > > > > > Also a quick look seems to suggest that the lock dependency on CPU 1: > > > > > > > > lock(&vma->vm_lock->lock); > > > > lock(sb_pagefaults#4); > > > > > > > > can happen in a page fault with a reader of &vma->vm_lock->lock. > > > > > > The report clearly indicates a call to vma_start_write(), which means > > > vm_lock is being write-locked, not read-locked. That's why I commented > > > that the report does not consider that mmap_write_lock is already > > > taken when vma_start_write() is called. > > > > > > > > > > > do_page_fault(): > > > > lock_vma_under_rcu(): > > > > vma_start_read(): > > > > down_read_trylock(); // read lock &vma->vm_lock_lock here. > > > > ... > > > > handle_mm_fault(): > > > > sb_start_pagefault(); // lock(sb_pagefaults#4); > > > > > > > > if so, an existing reader can block the other writer, so I don't think > > > > the mmap_lock write protection can help here. > > > > > > In your example vma->vm_lock would be read-locked before > > > po->pg_vec_lock but in the report po->pg_vec_lock is locked before > > > vma->vm_lock->lock. I don't think what is reported here is the > > > do_page_fault() path. > > > > > > > You're missing the point, in the report, the current stack is indeed in > > a write path (i.e. &mm->mmap_lock first and then &vma->vm_lock->lock), > > however that's only part of the picture. The deadlock > > possibility is due to that there could be a concurrent do_page_fault() > > which will hold &vma->vm_lock->lock first and wait for another lock that > > eventually has a dependency on a &mm->mmap_lock. > > I need to see a more concrete example. > Note that do_page_fault() does not even read-lock the mmap_lock when > it uses vma->vm_lock, that's the whole point of per-vma locks that we > avoid using mmap_lock. So, even if it later waits on some other lock > that has mm->mmap_lock dependency, that should not block it. > Again, you might be right and there might be a lockdep issue but I > need a more specific example to see if it's real. > Understood. I clearly don't have the whole set of knowledge/skills to make the call ;-) I just tried my best to figure out what lockdep thought in this case (see the other email), it's quite fun to hunt down a "deadlock" possiblity involing 11 locks. Right now, I'm leaning torwards that this is 80% a false positive because one of the dependency was built during initcall, so it may not happen in real code, but I need to defer that to drm folks. Regards, Boqun > > > > Regards, > > Boqun > > [...]