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 BAC96C77B73 for ; Thu, 20 Apr 2023 21:01:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2FE46900003; Thu, 20 Apr 2023 17:01:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2AE4C900002; Thu, 20 Apr 2023 17:01:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 176A8900003; Thu, 20 Apr 2023 17:01:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 072DB900002 for ; Thu, 20 Apr 2023 17:01:14 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id CD0DB1C66A1 for ; Thu, 20 Apr 2023 21:01:13 +0000 (UTC) X-FDA: 80702989626.05.B79634E Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) by imf27.hostedemail.com (Postfix) with ESMTP id AAE864002E for ; Thu, 20 Apr 2023 21:01:10 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b=C3rLQWwm; spf=none (imf27.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=1682024470; 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=pcN/Tje2VmvMcbOA3u2ULY9TMWv0DmyhFS+rCdsBMdY=; b=GF+uBnXrgrryFZOSsfIqAxBqUkIVevjAteHYfZqSB4SPLzFWGr82r/ih/2+Cgd6NT1glth 0gvVPi2l1ETyLS5S4Ukj13b+nQB81X3ZIW8lq7xd0/3fJNB+wGuGagW2hKjd5yn6+x6kDR 7JO71IPrMYEcqk4k7DlmC6lPPBkvq2E= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b=C3rLQWwm; spf=none (imf27.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=1682024470; a=rsa-sha256; cv=none; b=mrlsKe/Kh2kKZyH/WBg/afou/R5E/lTvArAqCTVNBZCmh/yiWbKEo2vWaC7hEJVrzy0000 VB/0A4/lobKAroQzuDk6jtobsF7Uj38Mq05r0NqMbGZEwRqAS8x98NPWUa8e+T/iBHq3ZP CK7BXAaz3h4mUi5cKXhlms2pTo9743A= 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=pcN/Tje2VmvMcbOA3u2ULY9TMWv0DmyhFS+rCdsBMdY=; b=C3rLQWwm26lG8focs02Dr77541 qKa9auoTft3gRjxu+e9uf7gRiWZFKcaqe/0g8MKCXsHnlMDBf1TvZ73gSeHHz6sKmmak5tTkWx7hA CVc2UKefk9fJHmyg16d7nMt4KGA+wv8HevPa3nArFGUlrXJouUl/oc/bNH5nBEPFWRhEQQQCGnDNE klDC8/Fu5CWhHE9xy/AUgRCd7Z9/a5yKtZn55cXzxQcGZt2vAE/Jfgw7BGfsDBC+SeWyI+aqFb7+L POiherrsI6JelMF+eZunNtT/vTtewnsYlvugxRd76Y+UDTKr9it/EYAGO7bxjIVsue/Lhr1imAeYg hHgaLVBw==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.96 #2 (Red Hat Linux)) id 1ppbOX-00AxUn-0l; Thu, 20 Apr 2023 21:00:45 +0000 Date: Thu, 20 Apr 2023 22:00:45 +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: <20230420210045.GP3390869@ZenIV> References: <000000000000e2102c05eeaf9113@google.com> <00000000000031b80705ef5d33d1@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: AAE864002E X-Rspam-User: X-Stat-Signature: e4anp7atzwk3hd3bn1ijs1z6i85j78t1 X-HE-Tag: 1682024470-970310 X-HE-Meta: U2FsdGVkX1+vAyOloYJWYQiDg6CcXlYDxOvzgK1NTUY4kDOq2f9Q6ia1tyXKqL3ccLnydC+CDVKbvy5CH/e3jbqMJZ56MhJyxLpcFkZY740xYedYr9GFpPSsfg8yadnqqVhApE8zcrP54z7G6Ji3I2iOnYJxzV8ODckOII4xN6Nbfkhd0levyUA5cssowrTqr2MoXIq4UJF5b22br9jaCMvGFGKIhGvFf7vjYsbc8hgde06En20fQtjFT9lPB18SlypBWntiNd/d0OoMH6ySWSnqNNLKaDcn6dT7Qv1viC19EQC9D9auMpcNSomef95j6G98Ez8vv5S8wpG8kR4PqcDy+Z0jbX/dCILiskQ8gv2P3RTWUHoXLlo+JVvQciiIo+i8DXttQx6+yhzD0r4xCyBSlX8uIfLhdn/Ql9v0/nFfBLy8QH1mNatHCTxFcyL6YlHQSDIPp8ks8k35aMTsZcRz892PJ/Se8ntGglR8mD5iB2iVMYyn/pNXm8h9Jep273aTMXYnygwCmwVfK5fmK6lNMIsHvBLHbeu7Yapt+e/ZtOUMiY2KiFccW59pu6A0c/0OXyHNCxPxTLGiDXPHdO5YXY55Hq+o5PqWRJ5qAqQxo8NkkHYdvkY9qmqIPKXIP81UVCk6T3GkoyyE4ojXE6gFX5RClzcM8uAv1iTNJurJbEbLowHRkRNT3nC66t4grvTwKoyxtmXmw+cMCbjcw4vuFLv6C87qGcP3/YhhnvIIf2BPcyBiLQ1xoRdUb2Zm8pURRtE36LGduHWM7NA37PR8xzQOaMZTMsru+DGTqp84dJPak1dZ6dQ7lKyw52CyAAMCBBrc610vYwpJMvkXyyKoliCyq4lhvmLsrnvKpTirkAD6/wXOwOmyZ/ZNgeatJ3uZ+y5KC1hKARFuA0Bc4JaagVA7nL6JCoeyew0Es7joAG8yH22xW9T7jKoB6w/AGFZ7rr7CZ+7EHeSnavj 5NiZcvzu z83VEe1ZcMy1TnLvXQ/2EjsAlZqzxCd2I19JMAZM17IRl9IyN5RLfGFhw3kco0jpDTLkYqXN+fr2XihK0GyxCFTeO56AndNtib+veUmKWyzpYSy1yIo0wLTYlRVhOzQoZAqbKyiu3BGjXGo+mRuN4a0tu9P8B8F7gBT8Q5FUQ667S1s8PF8D/4+ijjtCz8dkpGsGlXkSbiArUOq179vN3W5I01w3q5UgKMqWBKcF7fvYAr4H+iQ3a3W/B4AC+63rGP1/RtjiqBGup4U2iq0sd5/nf4kVdjN396o7DyXg65zcGncSZv5iY4MO0YEEjyXp7BWJ+5CFn0A0Ovfbc5kT+SQ7c4GmiwuxDyIjmY/M5qbjwduaZvTUgjMs6ZHhrf9RU8tYXm/9n8sQR7RXRW0l4+6OdqGhYwf2H5BR56LQXjk9wryaEa+2bMv7eh0B9s+0AndKF 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, 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.