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 D4AA5C71153 for ; Mon, 28 Aug 2023 12:30:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 36B71280014; Mon, 28 Aug 2023 08:30:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 31AE0280013; Mon, 28 Aug 2023 08:30:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 20A45280014; Mon, 28 Aug 2023 08:30:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 11966280013 for ; Mon, 28 Aug 2023 08:30:35 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D99971603FE for ; Mon, 28 Aug 2023 12:30:34 +0000 (UTC) X-FDA: 81173446788.16.238EEA0 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf17.hostedemail.com (Postfix) with ESMTP id D0DA44001A for ; Mon, 28 Aug 2023 12:30:32 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=none; dmarc=none; spf=none (imf17.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693225833; a=rsa-sha256; cv=none; b=FO5AvoOFwjkfSssPzfqRSgXHVeSgBjDmVTsk6wLo1U7GDO5lhOqIAKCPh6nORUayD/mkop i5uWGkOMtwLCO6KM683a36fciwj34WUjStzHUUctEaUUZ9H5iLzEwzIjaVQfB3gI5Zxs/g OtKEY48uqUBv8sLOmqKv9AtmNoAYC8A= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; dmarc=none; spf=none (imf17.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693225833; 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; bh=TLnvMQnkyoR7wwCry5GRCKzwjL5P4BV+bNSPRJ9AdUw=; b=pw5iOUjvh3EalsTs31BF9HnDQpKnQxl8oOCEOeI5pJX5FMx+FJ0gZVBODOf8rqGPwerUyh IcX0XOgzmn3FwzwwLCHN67NQzftRuO53jFiTpAsh31c3iCZZDXYNeavj9F4jI5W5wnnPQF c80Kum1aw6u6bLtbRgauMuqcrzs+be0= Received: by verein.lst.de (Postfix, from userid 2407) id 981DA68D05; Mon, 28 Aug 2023 14:30:25 +0200 (CEST) Date: Mon, 28 Aug 2023 14:30:23 +0200 From: Christoph Hellwig To: Al Viro Cc: Christoph Hellwig , Matthew Wilcox , Jens Axboe , Xiubo Li , Ilya Dryomov , Christian Brauner , Theodore Ts'o , Jaegeuk Kim , Chao Yu , Miklos Szeredi , Andreas Gruenbacher , "Darrick J. Wong" , Trond Myklebust , Anna Schumaker , Damien Le Moal , Andrew Morton , linux-block@vger.kernel.org, ceph-devel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com, linux-xfs@vger.kernel.org, linux-nfs@vger.kernel.org, linux-mm@kvack.org, Hannes Reinecke Subject: Re: [PATCH 03/12] filemap: update ki_pos in generic_perform_write Message-ID: <20230828123023.GA11084@lst.de> References: <20230601145904.1385409-1-hch@lst.de> <20230601145904.1385409-4-hch@lst.de> <20230827194122.GA325446@ZenIV> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230827194122.GA325446@ZenIV> User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: D0DA44001A X-Stat-Signature: fdjrac3q7r8zarptqekuqs6re84hx5co X-Rspam-User: X-HE-Tag: 1693225832-92002 X-HE-Meta: U2FsdGVkX1/bmnJ78XRpj5FLT8ul92W7CIaRAAhXknuq6TwMbLE42rxNEz9Iol1Rtcw79lkXxkfgonHwPxooacAe5Ouj//yfF1TlldquWpRxAkCsBFaslsB1zMCcZTzTdDxl9SaeLiNIG+A0bzp/7zBO/EW22zOOoKhD9BVijaNGRVszE5YhTUVukA+6OUSjlQgJtIBj5+AZ0U3B+oBnU+E6YmdJ76U0PB8ABXhir3vYNMznhElteNOnZgBAJBGsiXmpD5I/tNseakc2mZqzPwaKPS59BsW6t24lr2C+bldWC8DKfinvoX4rLlUm186Gx0lNeTQWTOBfRzwmoysn+Bwa8WLJbFtCjcIaKYkpuy0PgFagaBQqDdim4VM+9oOWB64uL5CHKwfcEu1xohWw7MT7Ijgb3+2rl1c6N4Hlwk3JuozXpNuwLa47BbtmyQus5UPLJATNKmRfsdGD1XpF9586DiorfiH9+QfilFCICcle6dYYARQZD5xvTPfHvjtGKVXTK3Y1MsWhRXeKQ+5XxPKuVDKBo0DKvDU3jqoIHAfo9Eeo1BwWve6eRJRq/6Q4kT/rRGUSwLBercdgszD0jhbvh5vjKZvegAKF1RXkJgPeAqDgoBHNIc83RsvzW3hEwCtZKt+xxeqwM9DdAbxXhlUK6TynApMpfy2hgabsD8oOEMzfCuPPnzkPS2QXWVrJajS/TY/I6RVPH2BpW13tO/O0/8hsRQlqx5dzcDH2ga3w1kEtntfNbX76J4SrPXGDf1T5z1/GXRlfGGs//zVP0x7aYwMikkd4M/qOn+ACaWOhdGz6x2AUywUIOJhY5cWnOd3rc0eb4dYSU0mZqtbWxpTMtjd39A4RAt2bpGdugg4h0RtMqdBpGQULAdNcQe61T/IdWsxLdAvBwPY+/BC8qdWgTf/tEVJBR93MPF+Wk5ueKfcebXpy2/x5ukANFdBHXe3uFqUgx7SDy32yK4w +7b2OGrm ywHeeXwOt1vXRFMI7rpsp2DI2xyRhMtx2hVnDkFpSyv9LBVbYKzoaF4n7wPa12orzgHcM0en/pvz8EQS3P4WFMbuDtB/WrQsTXmAzH1BlefEFiJk= 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 Sun, Aug 27, 2023 at 08:41:22PM +0100, Al Viro wrote: > That part is somewhat fishy - there's a case where you return a positive value > and advance ->ki_pos by more than that amount. I really wonder if all callers > of ->write_iter() are OK with that. Consider e.g. this: This should not exist in the latest version merged by Jens. Can you check if you still see issues in the version in the block tree or linux-next. > Suppose ->write_iter() ends up doing returning a positive value smaller than > the increment of kiocb.ki_pos. What do we get? ret is positive, so > kiocb.ki_pos gets copied into *ppos, which is ksys_write's pos and there > we copy it into file->f_pos. > > Is it really OK to have write() return 4096 and advance the file position > by 16K? AFAICS, userland wouldn't get any indication of something > odd going on - just a short write to a regular file, with followup write > of remaining 12K getting quietly written in the range 16K..28K. > > I don't remember what POSIX says about that, but it would qualify as > nasty surprise for any userland program - sure, one can check fsync() > results before closing the sucker and see if everything looks fine, > but the way it's usually discussed could easily lead to assumption that > (synchronous) O_DIRECT writes would not be affected by anything of that > sort. ki_pos should always be updated by the write return value. Everything else is a bug.