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 880A1C4321E for ; Tue, 29 Nov 2022 13:32:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 166576B0078; Tue, 29 Nov 2022 08:32:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 116376B007B; Tue, 29 Nov 2022 08:32:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 004296B007D; Tue, 29 Nov 2022 08:32:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id E727A6B0078 for ; Tue, 29 Nov 2022 08:32:15 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 0364F140EA8 for ; Tue, 29 Nov 2022 13:16:47 +0000 (UTC) X-FDA: 80186529696.10.A27D807 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) by imf11.hostedemail.com (Postfix) with ESMTP id 4CE924000A for ; Tue, 29 Nov 2022 13:16:47 +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=ovEN2R1RcoyCmUvaJNV3bgGf54R1/0A9UQvs6JwGjy0=; b=VCDjRvvIL7hZ+3BDLMLNcVcDOc Q/TG09qk+hX2Yc7iYpjtjKWpMAg6QuT66/lUBVoOgG1SJddV/G3hF7s1W3QcWtNWasGbt2RHhhpoB 2dyBRVPwMKFCZomSisy7eREG1MqGSg9E5wAaNvorozi/v7wJuurqY5oAp+kcCiZvLzKgXyODWVMOE Paf9Dp++B5UFZoPw2Lj5us3iPTL7KTVYS6Nf1ORGgDX2ZHkGnIehszlSxGGBNSGJ7DcrEBcC+K3IO DnL/vPlipbptC4Ti4ZCqKulpGHMOshczri78Z0Ozt/hpiLeITr8taocWAF8cNJDgO6DmR45cLA1LJ 0LJ14MBg==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.96 #2 (Red Hat Linux)) id 1p00TM-007fjC-25; Tue, 29 Nov 2022 13:16:28 +0000 Date: Tue, 29 Nov 2022 13:16:28 +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: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669727807; a=rsa-sha256; cv=none; b=Y9yritz/JAwh1dGmULV1tpjJUMlITgJhd5YOKuVcCbE3sb8jPPtBDgSw2PWM1DQ5j7ncNG 5vJkXxUfb3S6si82F+yGVAZQda75VuaQs0KpMzk7uXrTp/2tpHU5ndYPp/VdMwCmMrDT56 ic7OSJwnFN8BVgpPEV041aPJ5Je4nFA= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b=VCDjRvvI; spf=none (imf11.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=1669727807; 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=ovEN2R1RcoyCmUvaJNV3bgGf54R1/0A9UQvs6JwGjy0=; b=ei4QlEiLQkPlftPkD3eo5Qbt7B9gShVIVsHrLF96weToT+twTKIb1eqctnlmsMTE0buLxo 2ouPt94OxuHubuCZE2sdqa1W0+TnqKgIXGSiG9RAN8UjxuWXTtBk1GUFr4ojhGpwTvC4FQ ++ta6X5WjOo6N773H2DJ0Ww0HwM8uh0= X-Stat-Signature: cyzyqym7b91eh4pq16abxyuohf4dkxaq X-Rspamd-Queue-Id: 4CE924000A X-Rspam-User: Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b=VCDjRvvI; spf=none (imf11.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: rspam05 X-HE-Tag: 1669727807-862902 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 12:20:39PM +0000, Al Viro wrote: > ->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. Looking at ntfs3, WTF does it bother with zeroing on short reads (?) in the first place? Anyway, immediate bug there is the assumption that blockdev_direct_IO() won't consume more than its return value; it bloody well might. *IF* you want that logics on reads (again, I'm not at all sure what is it doing there), you want this: } else if (vbo < valid && valid < end) { size_t consumed = iter_count - iov_iter_count(iter); size_t valid_bytes = valid - vbo; iov_iter_revert(iter, consumed - valid_bytes); iov_iter_zero(ret - valid_bytes, iter); } This iov_iter_zero() would better not be an attempt to overwrite some data that shouldn't have been copied to userland; if that's what it is, it's an infoleak - another thread might have observed the data copied there before that zeroing. Oh, and if (end > valid && !S_ISBLK(inode->i_mode)) { several lines above is obvious bollocks - if inode is a block device, we won't be going anywhere near any NTFS address_space_operations or ntfs_direct_IO(). Seriously, what's going on with zeroing there?