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 30969C77B7C for ; Thu, 20 Apr 2023 21:11:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 989F8900003; Thu, 20 Apr 2023 17:11:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 93A60900002; Thu, 20 Apr 2023 17:11:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8031C900003; Thu, 20 Apr 2023 17:11:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 70F34900002 for ; Thu, 20 Apr 2023 17:11:19 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 4819A140623 for ; Thu, 20 Apr 2023 21:11:19 +0000 (UTC) X-FDA: 80703015078.24.77CBECA Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) by imf09.hostedemail.com (Postfix) with ESMTP id A0DD8140016 for ; Thu, 20 Apr 2023 21:11:17 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b=vnEtrnm7; spf=none (imf09.hostedemail.com: domain of viro@ftp.linux.org.uk has no SPF policy when checking 62.89.141.173) smtp.mailfrom=viro@ftp.linux.org.uk; dmarc=pass (policy=none) header.from=zeniv.linux.org.uk ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682025077; h=from:from:sender: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=Q7x5kZ5TxiQIaPfXzJFB7ZtvsGLdF/4XT+qLIfeZvEs=; b=HSpiYH4vMkDgeSDxbcwWBtXZ9j/2uJsplsEKrPPHh9vcuTKN+w8oULLlmfrZk5izOhbAiQ dm90MBxFys7Lphacxi6r+1ii4cIqrStZaMBPT/NoVIt02PGEoLh98HPczV/Cg0FQZ3Twrx hobV4em/xjU+5idrJatr/bZG8VPfyuE= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b=vnEtrnm7; spf=none (imf09.hostedemail.com: domain of viro@ftp.linux.org.uk has no SPF policy when checking 62.89.141.173) smtp.mailfrom=viro@ftp.linux.org.uk; dmarc=pass (policy=none) header.from=zeniv.linux.org.uk ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682025077; a=rsa-sha256; cv=none; b=aeFwAORYta42YnpNpFsHGMTjDxxSK2L2vpS09DGloM+YtokRW4j3BJ8v7e4ax7J5KZWDKF e32BP1eMuJFmbgoeL2MT9j7Hj4lJ6hq3fZ3XgoT04n+8IIBXRH+ATZQ+HwCX8K5zaS3rq0 rnxyEJHPryLlAZxIZUQ8g17bpKyLUKs= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Q7x5kZ5TxiQIaPfXzJFB7ZtvsGLdF/4XT+qLIfeZvEs=; b=vnEtrnm74d1qMarGhJIXeyAVZo ha0LcHx6YBNRJx0MyW0aNoe04AR89Kt3V0rRdi3wFRTbhM8Z34te8+7glVcfP5Mn4vNlybMnPjj5b 6w93HXlvAzp/7DCN8417gYM+pqvXI6VsWB3sC9TwH+mIalVIu/2KMVNaKxbF2PKnlM/LneXrjbxC5 cbJbCu4jyuG52xi8Rj3ctLn4sULUtsIeeYudq/zY7oPkaZIHOGlqG5YHnpiFBb7BUC01rzWzK+e5L lMN9T5ywTZ103LfptXfMQ6N/4/UT7yvhe3Ut/FIEF4SU9Noxm62zcaww7d4eywkSoPRmJ5lD+7fdj q5r4SJNw==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.96 #2 (Red Hat Linux)) id 1ppbYV-00Axbx-0F; Thu, 20 Apr 2023 21:11:03 +0000 Date: Thu, 20 Apr 2023 22:11:03 +0100 From: Al Viro To: Tetsuo Handa Cc: syzbot , ntfs3@lists.linux.dev, syzkaller-bugs@googlegroups.com, Mark Fasheh , Christian Brauner , Konstantin Komarov , linux-fsdevel , Hillf Danton , linux-mm , trix@redhat.com, ndesaulniers@google.com, nathan@kernel.org Subject: Re: [PATCH] vfs: allow using kernel buffer during fiemap operation Message-ID: <20230420211103.GQ3390869@ZenIV> References: <000000000000e2102c05eeaf9113@google.com> <00000000000031b80705ef5d33d1@google.com> <20230420210045.GP3390869@ZenIV> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230420210045.GP3390869@ZenIV> X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: A0DD8140016 X-Stat-Signature: i1m4qxft499bh8zkfhqu6a3k37symnpo X-HE-Tag: 1682025077-140255 X-HE-Meta: U2FsdGVkX1/YVKS9V47OTw966JZ/jQhvs3Arh/jdFsL2q1jZL2IU9oNqBz9f/u+vVnRgxbc/rLRtwUphwJeU6xEx1PGErwvr7FM+bmy/KXYAtKEVPyZ4BB/0vbV1Hr4NkxTa7NvA0IizUw4G62mziKB5YAjB4qc1L0QgDUBfiAnN/8SNBZOndc0EAJdgER/cu78cStyz2sL7/HCi+pGEEq3O0NeM+ZiU/SNAJqiEdGwhHbH3ATXnlv652zk0gBZTDAzvS+iYvX4wwpSkCcU9QpiujiPS+0nVchKOP1KhDkgZtCZN2QObnRwJYc8iGwfT1cLgvQkyrDAkysvz4aJ3mD8RK0iBsPA7Zf88CtMIW5tXLsoQ+tJpVeADMAiHAiq+Zw8qxHQViEUtZb4FkKwvMelAdDhtjIjtXEs0S/GvOQtxK+bcJFgPhr/m5WPrz8C3iPvKylJfjQnDt/VHeK3OqSErhF77RluCGWsS8ZLRckHQDBYSlUi+YYO/JJEPhso/5hzki7lvI72KrK6EPae68Aq11W+8UKqGwRQEGea7Ezy/qJD0BGH2NuLCA0oun363waTWSDylmxRlvTFL80y0sDUrwHX3TfQbFzk5p+9z4KdWPXRZsuqz3KoPBIC3b9koL3RR6C1BMRgZaCjE3jVJ8Hbr2DpvCViYebdmrf+6dHGNjILAZJwn1+r7REnqrPk/3REhD0g4yQRg/SllN2OJVMth8dozKPxlhowkkbqJgcbOrzWyEfD1Bswu8nArpuBtHHUVVfQMT9QO8X9nMmc1SIW19InZPt7hvWp/eOx+Cqe6MWfNaN6Z30cVZgdxn7er9UaKFhsoW6g6KE8Ap5upQZIqkVNnL30ZNpRQ8yOXDK642/fUvetzglPyHFCg65sy4ZsuJ3peLPdX/5TZbXX6fdf42TZUCP/wL9NSpL1/6/rS9jbKVlN5zGl5xIneYND0+O+MBUIP3RlH9184P34 t0oQ1sYr 4tDGZj/2bkhZMZSWP0NBAkAS2tDFoE1Zqnb9QnuIJaxrEqckUR/LH2xm7yMI+hGfuKE0gVkpNXIpvy92vZpEApqS442bp8raNegMWuYb1yZlRbstRK/lBaZhwWpSKzZMlViGhxFU4mktUxxRyBk786RZVVlP9HphiwhpOr72WHHjt9zDZ7scoJxUO31EpUe56GC0zZkNllz9qhuP16Mg/BOBrCh4EpyglCl/kTNxnzBqqxVi5NHuBEnHAvNvC8do7RuO1W79VCedJLK1k9nFM1hfB0RmMJ9Q46YNsiG1FNXFJFbmL9J89D2w+Owv+8LH73U9b7lo5qYQiTlNw+O6g0kKfKnc9CbAMzdeMbgNaPWfMqBdzSRhMLUyRU5I1nsjAsiLicOcEFKP7W5BCroectTJKMWSuaKQ+v07SPHHln2e5GBUSdOp1s6lXhA3K36UFslu0 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 Thu, Apr 20, 2023 at 10:00:45PM +0100, Al Viro wrote: > On Mon, Apr 17, 2023 at 11:03:26PM +0900, Tetsuo Handa wrote: > > syzbot is reporting circular locking dependency between ntfs_file_mmap() > > (which has mm->mmap_lock => ni->ni_lock => ni->file.run_lock dependency) > > and ntfs_fiemap() (which has ni->ni_lock => ni->file.run_lock => > > mm->mmap_lock dependency), for commit c4b929b85bdb ("vfs: vfs-level fiemap > > interface") implemented fiemap_fill_next_extent() using copy_to_user() > > where direct mm->mmap_lock dependency is inevitable. > > > > Since ntfs3 does not want to release ni->ni_lock and/or ni->file.run_lock > > in order to make sure that "struct ATTRIB" does not change during > > ioctl(FS_IOC_FIEMAP) request, let's make it possible to call > > fiemap_fill_next_extent() with filesystem locks held. > > > > This patch adds fiemap_fill_next_kernel_extent() which spools > > "struct fiemap_extent" to dynamically allocated kernel buffer, and > > fiemap_copy_kernel_extent() which copies spooled "struct fiemap_extent" > > to userspace buffer after filesystem locks are released. > > Ugh... I'm pretty certain that this is a wrong approach. What is going > on in ntfs_file_mmap() that requires that kind of locking? > > AFAICS, that's the part that looks odd... Details, please. if (ni->i_valid < to) { if (!inode_trylock(inode)) { err = -EAGAIN; goto out; } err = ntfs_extend_initialized_size(file, ni, ni->i_valid, to); inode_unlock(inode); if (err) goto out; } See that inode_trylock() there? That's another sign of the same problem; it's just that their internal locks (taken by ntfs_extend_initialized_size()) are taken without the same kind of papering over the problem. 'to' here is guaranteed to be under the i_size_read(inode); is that some kind of delayed allocation? Or lazy extending truncate(), perhaps? I'm not familiar with ntfs codebase (or ntfs layout, for that matter), so could somebody describe what exactly is going on in that code? Frankly, my impression is that this stuff is done in the wrong place...