From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail78-36.sinamail.sina.com.cn (mail78-36.sinamail.sina.com.cn [219.142.78.36]) (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 A4E8D41A8F for ; Sat, 28 Dec 2024 11:02:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=219.142.78.36 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735383745; cv=none; b=VwnvQsQRiEVN8osWiKP0gnXhszJ91Ce+Db0fmaB1ffHt+LuJF5p5bKNLfdSOoskY3d1xjt9RXe99qO5XqC3MEEO2GmN01P4FrG35LR0p0HjSSR/KLkX2sBMP3aZEJtwP8VqUMh1hj0i1UUJnIz8l6hNVsYa860s1UnVDz5vE0ZQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735383745; c=relaxed/simple; bh=g95lCVO2spJsxHE8fPH8tANZzYp66guHJHjTkdGpUHY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=huT7rUUHmndWTOmjn5tl3V1AtkP/sW46Gr5S0warUDmeeS2rYciDc6wo9o1ehyz2PBy1lNKZqdfOs0maA4zY/6ZlUnlhL0Yb1068x/YQCkqA/NDPol/d2YEG81vAME6hjGG7MEsC74uFq3OA/L+d8+88oit3FEnDQQvkdlOPZAo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com; spf=pass smtp.mailfrom=sina.com; arc=none smtp.client-ip=219.142.78.36 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sina.com X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([113.88.50.127]) by sina.com (10.185.250.24) with ESMTP id 676FDAAD00002D74; Sat, 28 Dec 2024 19:02:07 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com Authentication-Results: sina.com; spf=none smtp.mailfrom=hdanton@sina.com; dkim=none header.i=none; dmarc=none action=none header.from=hdanton@sina.com X-SMAIL-MID: 99816710748251 X-SMAIL-UIID: 8845007C218C447AA257D80EC2133FD8-20241228-190207-1 From: Hillf Danton To: Boqun Feng Cc: Suren Baghdasaryan , 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 Date: Sat, 28 Dec 2024 19:01:51 +0800 Message-ID: <20241228110207.593-1-hdanton@sina.com> In-Reply-To: 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=UTF-8 Content-Transfer-Encoding: 8bit On Sat, 28 Dec 2024 01:52:28 -0800 Boqun Feng > On Fri, Dec 27, 2024 at 06:03:45PM -0800, Suren Baghdasaryan wrote: > > On Fri, Dec 27, 2024 at 4:19 PM Hillf Danton wrote: > > > On Fri, 27 Dec 2024 04:59:22 -0800 > > > > > > > > CPU0 CPU1 > > > > ---- ---- > > > > lock(&po->pg_vec_lock); > > > > lock(&mm->mmap_lock); > > > > lock(&po->pg_vec_lock); > > > > lock(&vma->vm_lock->lock); > > > > > > > > *** DEADLOCK *** > > > > > > > > 2 locks held by syz.8.396/8273: > > > > #0: ffff0000d6a2cc10 (&mm->mmap_lock){++++}-{4:4}, at: mmap_write_lock_killable include/linux/mmap_lock.h:122 [inline] > > > > #0: ffff0000d6a2cc10 (&mm->mmap_lock){++++}-{4:4}, at: vm_mmap_pgoff+0x154/0x38c mm/util.c:578 > > > > #1: ffff0000d4aa2868 (&po->pg_vec_lock){+.+.}-{4:4}, at: packet_mmap+0x9c/0x4c8 net/packet/af_packet.c:4650 > > > > > > > Given &mm->mmap_lock and &po->pg_vec_lock in same locking order on both sides, > > > this deadlock report is bogus. Due to lockdep glitch? > > What do you mean by "both sides"? Note that, here is the report saying CPU0/1 in the lockdep diagram above. > the locks that are already held by the current task, and that current > task is going to acquire &vma->vm_lock->lock, so lockdep finds new > dependency: Note the current task acquires &po->pg_vec_lock after taking &mm->mmap_lock, and it is the &mm->mmap_lock (ignored by lockdep?) that makes the report look bogus. > > &po->pg_vec_lock --> &vma->vm_lock->lock > > and there will be a circular dependency because (see above) lockdep > recorded a dependency chain that: > > &vma->vm_lock->lock --> ... --> &po->pg_vec_lock