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 0A099C4321E for ; Tue, 29 Nov 2022 13:36:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8FAB56B007D; Tue, 29 Nov 2022 08:36:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A97A6B007E; Tue, 29 Nov 2022 08:36:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 74C346B0080; Tue, 29 Nov 2022 08:36:44 -0500 (EST) 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 62CFC6B007D for ; Tue, 29 Nov 2022 08:36:44 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 9DB66160EFB for ; Tue, 29 Nov 2022 12:21:03 +0000 (UTC) X-FDA: 80186389206.10.F4640D1 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) by imf13.hostedemail.com (Postfix) with ESMTP id 18A8A20009 for ; Tue, 29 Nov 2022 12:21:01 +0000 (UTC) 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=wo3aQUARnvFFz3/ffXVvv/DF/a1pENBpfxbf9Xt1fwM=; b=KJTHbTIbPVkXCbiycEs5416p02 FtZDbTcFBFwPJznbCyxuFjP6mdBLkBOST6haJGyzOjeVODvjZW/ZWCiErFYVrnn3WOSRnaezdUkF7 HytYXVABQdSFQ1kYYVGN70z6gjMWJQn0tR54eaPdNChu+yY/VNMjhOQD5svbZiEH/ADhLiSSH0WEX aOG+CfEyKKrcWZb0uS8UdgixShctMh4enJ38h6yed1tYWWQ7L3/t3Zft6T/rU69b2T7VPazS4LYCB DWm+wr8IFHqueZGNSEqR4FqWPj0QFxweKEQihig3fIR4ba72YIaAz404owVNI4AYNvP9mRfC3cHNk kUZn0bzA==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.96 #2 (Red Hat Linux)) id 1ozzbL-007f5j-1t; Tue, 29 Nov 2022 12:20:39 +0000 Date: Tue, 29 Nov 2022 12:20:39 +0000 From: Al Viro To: Hillf Danton Cc: syzbot , akpm@linux-foundation.org, dan.j.williams@intel.com, hch@lst.de, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com, willy@infradead.org Subject: Re: [syzbot] WARNING in iov_iter_revert (3) Message-ID: References: <000000000000519d0205ee4ba094@google.com> <000000000000f5ecad05ee8fccf0@google.com> <20221129090831.6281-1-hdanton@sina.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221129090831.6281-1-hdanton@sina.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669724462; a=rsa-sha256; cv=none; b=Nyk92tCgONd3XyGiyFOZYfaz/QkVUe7fRsSNbwVChFJNnKRxAoWA7lE0ej/czQolybiqLZ dkM31iTVx0D9bc0skN/0oEkHirljW/FwZAdVZTaMFHroWQOQggIaKvJk+qIBZmwPi28/SG nE7tVHmCmOFMrESVinVN4nX00W2gGhQ= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b=KJTHbTIb; spf=none (imf13.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=1669724462; 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=wo3aQUARnvFFz3/ffXVvv/DF/a1pENBpfxbf9Xt1fwM=; b=SpkdOk+EeFzwtCVX3Hoq8P554WSKj+RjQsVKdZiIsJkXzHiOmqaDPgtTzd3MmKlrO/qxd1 j29Vy4nR2weiuqW02SW2ziOomWuctwPPWOiLgXLo/uvYR8MQeyKDlXrOUoKx4NSmz70vMm dojgNaCzd1wBMK3ktVOkS4q2dsgWt+U= X-Stat-Signature: oy91pf1686ms9fi1bd5rwnb8jie3nozp Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b=KJTHbTIb; spf=none (imf13.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 X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 18A8A20009 X-Rspam-User: X-HE-Tag: 1669724461-669588 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 Tue, Nov 29, 2022 at 05:08:31PM +0800, Hillf Danton wrote: > On 29 Nov 2022 04:04:35 +0000 Al Viro > > On Mon, Nov 28, 2022 at 02:57:49PM -0800, syzbot wrote: > > > syzbot has found a reproducer for the following issue on: > > > > [snip] > > > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17219fbb880000 > > > > "syz_mount_image$ntfs3(" followed by arseloads of garbage. And the thing > > conspiciously missing? Why, any ntfs3 maintainers in Cc... Or lists, > > for that matter... > > > > > generic_file_read_iter+0x3d4/0x540 mm/filemap.c:2804 > > > do_iter_read+0x6e3/0xc10 fs/read_write.c:796 > > > vfs_readv fs/read_write.c:916 [inline] > > > do_preadv+0x1f4/0x330 fs/read_write.c:1008 > > > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > > > do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 > > > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > > > At a guess - something's screwed in ntfs3 ->direct_IO() (return value, most > > likely). > > 2798 retval = mapping->a_ops->direct_IO(iocb, iter); > 2799 if (retval >= 0) { > 2800 iocb->ki_pos += retval; > 2801 count -= retval; > 2802 } > 2803 if (retval != -EIOCBQUEUED) > 2804 iov_iter_revert(iter, count - iov_iter_count(iter)); > 2805 > 2806 /* > 2807 * Btrfs can have a short DIO read if we encounter > 2808 * compressed extents, so if there was an error, or if > 2809 * we've already read everything we wanted to, or if > 2810 * there was a short read because we hit EOF, go ahead > 2811 * and return. Otherwise fallthrough to buffered io for > 2812 * the rest of the read. Buffered reads will not work for > 2813 * DAX files, so don't bother trying. > 2814 */ > 2815 if (retval < 0 || !count || IS_DAX(inode)) > 2816 return retval; > 2817 if (iocb->ki_pos >= i_size_read(inode)) > 2818 return retval; > > > If ntfs3 is supposed to do nothing wrong with retval set to 5, why is > iov_iter_revert() invoked? Is it correct to check -EIOCBQUEUED only if > the direct_IO callback returns error? ->direct_IO() should return the amount of data actually copied to userland; if that's how much it has consumed from iterator - great, iov_iter_revert(i, 0) is a no-op. If it has consumed more, the caller will take care of that. If it has consumed say 4Kb of data from iterator, but claims that it has managed to store 12Kb into that, it's broken and should be fixed. If it wants to do revert on its own, for whatever reason, it is welcome - nothing will break, as long as you do *not* return the value greater than the amount you ended up taking from iterator. However, I don't understand the reason why ntfs3 wants to bother (and appears to get it wrong, at that); the current rules are such that caller will take care of revert.