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 41BACC7619A for ; Wed, 12 Apr 2023 13:14:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CEED16B0074; Wed, 12 Apr 2023 09:14:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C9EF6900003; Wed, 12 Apr 2023 09:14:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB559900002; Wed, 12 Apr 2023 09:14:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id AB65A6B0074 for ; Wed, 12 Apr 2023 09:14:13 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7BE0E160109 for ; Wed, 12 Apr 2023 13:14:13 +0000 (UTC) X-FDA: 80672782386.21.8EB7D82 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf04.hostedemail.com (Postfix) with ESMTP id BD5A040017 for ; Wed, 12 Apr 2023 13:14:10 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=fuJmWayp; dmarc=none; spf=none (imf04.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681305251; 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=jhnbfZZJmRmZ+IEFhR2VhfrX2b5999A1n8AJ1gD5lxM=; b=kmTaoVFLZy0yw7YFhakL5I9Lpx3bSHokLSVVd93KA+l3YS0qfHkFAGZzy673MXh58GJzXc OCgNdaBOBlaCaFTJ6sYuiXOIimYH1bydYnzTjZsFC6p4Fy9oC8FC9B+oXlDTU8X47o/U4Y wOViLOtJML4P19/rCI+BsHCrKREwtwA= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=fuJmWayp; dmarc=none; spf=none (imf04.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681305251; a=rsa-sha256; cv=none; b=tus2n8k7jiXpx18wbs4olB9T+P/+e9kWhgxcibsh29Xt+9GXHhoQBczN5n5uoYn6wTSfbK IQgHZGfNQDpRj5sI4lU8vMhZdgDXD8eGCGpwIymUQ4wolzVlazlNkaITXVUpXuuW05Axiz O4qEc/S9Rnaad7n11cc5WpO3ohGZESc= 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=jhnbfZZJmRmZ+IEFhR2VhfrX2b5999A1n8AJ1gD5lxM=; b=fuJmWaypLyPsm8wmSwakd4AtLJ 0ylp0YlkyNAIfNlutNxX3yTN8vLYyE9fuyJQsWNtD649gEuZSj8PWaRVUgM/dcyOmzhffiS93i4Cy vEUBETP/sVTGRA1NtfVaZgQeV4neTcIsIdyH32yDMXTvdM6uYnP9eNxRJQPL/T5sIBeDDzFJNZB8+ B3GRn7z9e+1vk7uY4FD8kgdb/uYhD8E5nhDhX13W+Fkpqxesk9GfStsGntLvXnung9qudYGGCSleI T3ViyMdxrfjVpVzzsMViUXD4QDeqZe9IGmpYpREkkq8kzO4YGpWVNxNBRoXkv0mOo06eFwJRz5sQ7 sypV+wow==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pmaIG-006tKO-VN; Wed, 12 Apr 2023 13:13:49 +0000 Date: Wed, 12 Apr 2023 14:13:48 +0100 From: Matthew Wilcox To: Tetsuo Handa Cc: syzbot , ntfs3@lists.linux.dev, syzkaller-bugs@googlegroups.com, Konstantin Komarov , Hillf Danton , linux-fsdevel , linux-mm , trix@redhat.com, ndesaulniers@google.com, nathan@kernel.org Subject: Re: [PATCH] fs/ntfs3: disable page fault during ntfs_fiemap() Message-ID: 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-Queue-Id: BD5A040017 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: q9smnmmrh5gyjh83u6jzu8meeqbexfjf X-HE-Tag: 1681305250-751607 X-HE-Meta: U2FsdGVkX1/te30ShyL3gRNzpmtkB3Iag5UJt455P0YhpqiZi1OaEMGy+gnisKDAJQ0YnNsDdHeHKqCcYkwvNib9eVb56rxPrZplNsMANnkv03scYIx6pbwFz4Xl6ZrVEXQG2tjOhA0oqpfPkNF7n0QjxUlDKREdwturaDQh44Bq4rQl8UbfZOflmiJzf2E28Kmskra8K4Dycx+fEcaFfNsbU/9IgdYEGXRrOksQEwNstkJDyIB5K+WMxi8xH5QNIh/ZjLR8DM28GFzegskEitjkWwucP017xUmPvJU02E0ydcMZWLR9t/jzRKiFC76iptkrO7gUPZoAWzDtU6wI9ctT3R4VooVyRGkaztztF8AJ2e4RnATqMeWhPWK0NE7VB50jnzum/xl9kwu7fbXaxUMzQuEJwF+Xd8sAGeSTqPHq5vDIFBM3NEDK8AUGAoXnjN7YCMRcPC+BVLgz2v0Xbr0hVfObBZdBBbU+Sy7Z1d75LrH/+JPkMMseOqMOEqlPX5Kf9SwaPlw6AnPCQ7kgeDOqEK1H4WONl7yG3DFw8o9dl/XOtUpbKAF6fLP3V8lwUImP7yiaZ5J3vKwYdmZKW8M0eve2E56uqDTDg8p/eLqdutlKo6FvBZW6NvK6ZmqZPRHuDWaTEIU82glbDHjlELgK99fnWaez9YYbSnR0kkYshSPn0+BTyBQlfMsDnvhsQioDe+bqygR7HFYQMhaGEIFsiYGI4aDcmz2Fu/zxsev2RPwgkYADPsWi/VUPjfqphFNbEW8dZr3Rqa5jG0tdnkM/2xGrZEva0ySrYY7762lrEEdzRBMVAED9w78WnElpY/YuGm1HRZEOp/rIagNpR624e2ID2k4EZUeGXaY2z0la5cmHRZ+YbxWGi29Gj/K7513wjz4h+g9gFh6YV3/+nxaDyLIDKYo8SNNa2akVpNLvXojE3t/wZA36p4iw5ob/EHc/cWvZs0by9Zecf42 MVtuN1li DqQdPMYjxV4IvCspHH+Gfjjw5CzfXf2aTSS2PkmALXn9HgAKifGP3xIuGFnvbTzckFX1su4lcbnohAtlmifRu0yNiZNH9j7cE46Ltb1hTgYBUwO4UPh5vd4jHO1vEqx0kaw3TZR8chSLsis6yDNNaPvRoBM2gZ67GJYXf1JrDqAte59KQ1APuk8CoeXB63qwU3eNYkbSAfKaX9hl3GY2kt2sjiTfz9Rnp9rf5P9VsqWW5WFVTpFT6GyAZLHoNqFcF7osy1kcdvA2LkWH2E+8yKBBCSnL5zF3XHI+ev36CYVVwmLo= 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 Wed, Apr 12, 2023 at 10:11:08PM +0900, Tetsuo Handa wrote: > syzbot is reporting circular locking dependency between ntfs_file_mmap() > (which has mm->mmap_lock => ni->ni_lock dependency) and ntfs_fiemap() > (which has ni->ni_lock => mm->mmap_lock dependency). > > Since ni_fiemap() is called by ioctl(FS_IOC_FIEMAP) via optional > "struct inode_operations"->fiemap callback, I assume that importance of > ni_fiemap() is lower than ntfs_file_mmap(). > > Also, since Documentation/filesystems/fiemap.rst says that "If an error > is encountered while copying the extent to user memory, -EFAULT will be > returned.", I assume that ioctl(FS_IOC_FIEMAP) users can handle -EFAULT > error. What? No, that doesn't mean "You can return -EFAULT because random luck". That means "If you pass it an invalid address, you'll get -EFAULT back". NACK.