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 35BBEC3DA7A for ; Mon, 2 Jan 2023 15:37:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A28148E0002; Mon, 2 Jan 2023 10:37:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B0C08E0001; Mon, 2 Jan 2023 10:37:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 82A608E0002; Mon, 2 Jan 2023 10:37:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 6BFF18E0001 for ; Mon, 2 Jan 2023 10:37:43 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 0EF791C2CE9 for ; Mon, 2 Jan 2023 15:37:43 +0000 (UTC) X-FDA: 80310264006.29.E2433D8 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf24.hostedemail.com (Postfix) with ESMTP id 30844180009 for ; Mon, 2 Jan 2023 15:37:40 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=daE4OMDE; spf=none (imf24.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672673861; a=rsa-sha256; cv=none; b=cOia+zaThEUhf/D5O33WJbzlkc/Y5Te7B+ZOyssKyzcchuJ7yXf2N3ypyR2OPCFWbXd7L1 Dx7YXxUR7dQDGkQ/5zwWqIugKJ2kghVQ8D9Ow+iNMabTV5fP3DECLLhG8B+/n+CQ2sPMlC OfRqLbMmG5dfsWUXu2owLCu6/BXwTbg= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=daE4OMDE; spf=none (imf24.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672673861; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=v1FPN1zhOA/rNihICtkkoeofxrQJhRo5+wZftDoLpWA=; b=Djs/QrEBURwItYkMCVl/HBntcnl9zZopoL0UV8AkZOxt8sY9/2mbkM/VpGjWQa3dve01qT ncBWMT2ykd1nr5jLtF7H4hSHshmcvqrBrYe5AkULsI1gEemr6lxpag/w4nJDQed6hVIQLE K8DonY0Xe8Io0jXMuZCkRPexCx7ef70= 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=v1FPN1zhOA/rNihICtkkoeofxrQJhRo5+wZftDoLpWA=; b=daE4OMDE5CSo0420kntsgynIKZ 8ngW24zDqHnfLO2wI09Qf+5ya79iclgI7eOOjaEju0oK9R5Hb2uxrAFgIaGkwHINKCZmHXQVeRONs UXIvlh4vV/BTKF03gvjMbj1IIGRpiSzFARP1zycXb3UFcJiRlcFH3XTT53erQvUTo8sFQ5ewnOBLB lc1QgYJWik8pnUnaXAh2ExPTdbeFBMPPKWbPPvxTiJbsyx6ZS/6giFtmE75cfgdDYfu82Y7yQG2dk Uv7q3ftQ7VC5r/aIHi3v4Lguv22h/5+/zy0pxRC1t2jA4F/6dW5zHWQiT6A4UOnO9BHyEVahDUXRT CIuPihEQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pCMsW-00DGpH-9K; Mon, 02 Jan 2023 15:37:32 +0000 Date: Mon, 2 Jan 2023 15:37:32 +0000 From: Matthew Wilcox To: Tetsuo Handa Cc: Linus Torvalds , Hillf Danton , syzbot , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Waiman Long , syzkaller-bugs@googlegroups.com Subject: Re: [syzbot] [ntfs3?] INFO: task hung in do_user_addr_fault (3) Message-ID: References: <00000000000060d41f05f139aa44@google.com> <20230102005409.3474-1-hdanton@sina.com> <6383cde5-cf4b-facf-6e07-1378a485657d@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6383cde5-cf4b-facf-6e07-1378a485657d@I-love.SAKURA.ne.jp> X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 30844180009 X-Stat-Signature: ud75nib5ht458grfgxisf3pdjudihoef X-HE-Tag: 1672673860-278092 X-HE-Meta: U2FsdGVkX1/GvWbQNVIsf2ehqKTDPE2zzq5t1Edz+CLz9xfCb/haHwUyduV8JEaCp/mVL/fK8kUSsNb95c3W3pSi4w7k+UfEhtOD3dTkUv9iZ4GHdXWTIudhPcl4Qnd49c3GfkId/cirRvCXdNayFF0uaEL9HWiO43YbKN/2qUZDFMbgVnDD7ntTqUE+nUylMjZaepxD64XI4+3r1rmvSlrb22lpJy0er1SdDZiT/hIzLum3BRgfrYwRnazF+kw6p+WP9VPoEEKcMa3JZj76a+ifxXTAh4ENLBH/ec+AM1pFhkReRf1EAFLmc/Is5W/BrFxZUzTe3qP74dD5kHPscfY0ocXoFA0+fEU+VcopQoM00nXC1fObkPq+Nz6fpQEoKKY+YXiy1bMnI4wYIzx0pIBsHH8gKaf6cV1ELFfwFnctteOx9rZnIVfa4VUyy380CAg6G1s98QMgCaM6cG/FOvHqtllm/bAp0Nr3YkVqnl5Iysy8/dMKphiwRYju+Wc7ZsulthiqtJEzk43trIkxgo7apbVgM5kgC4ReMDNrR9w8ccIvz05ALksii6P8wYQL44RbYcWLKmfCdzZlsMt4qqkulMw1X7M7UQmqGw25dyTl+OZsxQnO0ReGuPQ/1pobZh2Br1HA/LTH6TqZ7wvQCRtgcwc6AyMNaTGXJe90apVVXJI9ETXaDDU41XKlEoGMhKPWAYFbgIzzJhJwkh3E+618hH0Akcy2HvNCQ3kdwed9yy9arslBiw+yGeGw0/PG7NxQeG4xWI51CXRqqAVgR0hus05hYA6qvwqSCPXI8fkUPcyWkMLi0ARJ7MV5bZ80hfRByPyBuw77sx/BDJ0F5MVLDc6LexXGQJ1tPAh8ZaefMZv9YatnprMJAKiXD9hb1RuALmo+kLtNn6aVTgt7BMVtAbhvQhz/BByG8aED6E2jRFF0oek50LexJQcIQwj8zygbUX8hoTBnuO0UxX6 C6pPsmLn 0n1R5hbZf7VmOlaSautpbnSuRMPmTek0JQYCnmIig3aNwldR0UunJ88uINf3+GXtfAYvZ 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 Mon, Jan 02, 2023 at 05:24:24PM +0900, Tetsuo Handa wrote: > Since no lockdep annotation is used for e.g. PG_locked bit, this deadlock > cannot be detected by lockdep... lockdep, unfortunately, cannot track PG_locked. Lockdep requires that the lock is released by the acquirer, and sometimes that's true for PG_locked, but when it's used to do I/O, the PG_locked bit is released in interrupt/BH context. We could maybe fake it by pretending we release the folio lock when we submit the I/O. Then we'll have to figure out how to tell lockdep that it's OK to grab the folio lock multiple times (if within the same inode, ordered by folio->index; if in different inodes, ordered by in-memory address of those inodes), and that submitting an I/O will unlock all of the folios in that I/O. Oh, but there's cases where we only submit part of a folio in an I/O, and the lock will only be released when all of the I/Os targetting that folio have been completed. It's not impossible, but it is a lot of work and needs a lot of understanding of filesystems/mm/io.