From patchwork Tue Jul 4 19:22:15 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Howells X-Patchwork-Id: 115888 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9f45:0:b0:3ea:f831:8777 with SMTP id v5csp1422689vqx; Tue, 4 Jul 2023 12:31:58 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7TKYbbL2jkNyhwEiv7TZhfBv/ykTl2vCs912Q1gf1r5oO4DTkU0hztBhXdGbY1WblGRjhL X-Received: by 2002:a05:6870:3b07:b0:1a3:16af:56e2 with SMTP id gh7-20020a0568703b0700b001a316af56e2mr15313435oab.19.1688499117998; Tue, 04 Jul 2023 12:31:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688499117; cv=none; d=google.com; s=arc-20160816; b=TQKKpO8uxg1bkHVwP8w9m7EODNOGoulnndVsLLxeXdphDM1OcRXnHMUvWMb7ceb7Jt s3favKBbg6CBB3ZJlzR+yOnNPwLsBXGRZI0yXEFiSTOnPYL4vqkdMCIY+2wULbp0I6e3 UgRyywFOWra3662qJ/v/yGNxzXJuFmuQYg1+yY/4ktxGVq0ev4pLiRlDcsurDuaegxLL PAE7j+nH0gu/EX68d/gXF34j6nDboQoFj0y5oShHclmzAVNqK7mY/rIO8LwAWkPfrFXw XatW+FqX1bsA1tmvh9Lqf7xyaC2lCrjAS9tVdPon12WKsccxm31agJyciYlot26M9+EK ashw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:content-transfer-encoding :content-id:mime-version:subject:cc:to:from:organization :dkim-signature; bh=F9uTCmOrCCGGvfYnmrlpJhQABTj4UokRMqWz/zJVKVo=; fh=ij5EC3aIlF+9q8hxPxSFVxzSLI95qlmjRTrwH447/gQ=; b=o4AuVmi6FH1zwGOkTPqgIt5E694wzlWKxE/fgZNsYUds+a+30G0hDyjrhsNUml7Bh6 Q50oIy8t8LVzpM3tvu4L4yWoIuk53YAmP9l4BuJkFfBVmgeSsyhQhPfeeFesGQMmAVaW ll5zQrLEeNmjN18PGq7A++jux1rvAPGn24a7c418wt4Xm9B6oGwaGuKmEDRph8DPIntK g3Nh5q7ifacgU+ZHPZ9Y3su78054jlL7bc13YXJPUjjwFOpK6hx9hqcPCRQDyiL6NbBj SXoThCu6DoQhH9E4sA2alfRupgZvSDDawZeiGgcpipgLmJuvDgpvJzXxwltnu+y+xy3e oE4g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=cNvpSikw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id mw13-20020a17090b4d0d00b002597ed3cc4fsi22867465pjb.189.2023.07.04.12.31.39; Tue, 04 Jul 2023 12:31:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=cNvpSikw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230521AbjGDTXG (ORCPT + 99 others); Tue, 4 Jul 2023 15:23:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37858 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230383AbjGDTXE (ORCPT ); Tue, 4 Jul 2023 15:23:04 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DFA9910D9 for ; Tue, 4 Jul 2023 12:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1688498538; h=from:from: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:content-transfer-encoding; bh=F9uTCmOrCCGGvfYnmrlpJhQABTj4UokRMqWz/zJVKVo=; b=cNvpSikwnP3H6RAiBCZMeCpVzYiwLlfqwQrVkvEg//0SnTIT+qWuMbNiVJxcE5ZXvf4JIZ +ClXDUnslnE73LG/q0QM4HSb8jxfxjeuTpCuNXw+8OuVZhFRegk3LBhUDmN0/gm9Pk1WUL Y+t2+ZjZBebGIlkBalCY2YMlZrx56oQ= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-544-E031IvP4MH22QcHWqEMA_A-1; Tue, 04 Jul 2023 15:22:16 -0400 X-MC-Unique: E031IvP4MH22QcHWqEMA_A-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6897C185A792; Tue, 4 Jul 2023 19:22:16 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.42.28.195]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9A2E12166B31; Tue, 4 Jul 2023 19:22:15 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells To: torvalds@linux-foundation.org cc: dhowells@redhat.com, Jeffrey Altman , Marc Dionne , linux-afs@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] afs: Fix accidental truncation when storing data MIME-Version: 1.0 Content-ID: <1591987.1688498535.1@warthog.procyon.org.uk> Date: Tue, 04 Jul 2023 20:22:15 +0100 Message-ID: <1591988.1688498535@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1770519650796303754?= X-GMAIL-MSGID: =?utf-8?q?1770519650796303754?= Hi Linus, Could you apply this fix please? Thanks, David --- When an AFS FS.StoreData RPC call is made, amongst other things it is given the resultant file size to be. On the server, this is processed by truncating the file to new size and then writing the data. Now, kafs has a lock (vnode->io_lock) that serves to serialise operations against a specific vnode (ie. inode), but the parameters for the op are set before the lock is taken. This allows two writebacks (say sync and kswapd) to race - and if writes are ongoing the writeback for a later write could occur before the writeback for an earlier one if the latter gets interrupted. Note that afs_writepages() cannot take i_mutex and only takes a shared lock on vnode->validate_lock. Also note that the server does the truncation and the write inside a lock, so there's no problem at that end. Fix this by moving the calculation for the proposed new i_size inside the vnode->io_lock. Also reset the iterator (which we might have read from) and update the mtime setting there. Fixes: bd80d8a80e12 ("afs: Use ITER_XARRAY for writing") Reported-by: Marc Dionne Signed-off-by: David Howells Reviewed-by: Jeffrey Altman Reviewed-by: Marc Dionne cc: linux-afs@lists.infradead.org cc: linux-fsdevel@vger.kernel.org Link: https://lore.kernel.org/r/3526895.1687960024@warthog.procyon.org.uk/ --- fs/afs/write.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/fs/afs/write.c b/fs/afs/write.c index 8750b99c3f56..c1f4391ccd7c 100644 --- a/fs/afs/write.c +++ b/fs/afs/write.c @@ -413,17 +413,19 @@ static int afs_store_data(struct afs_vnode *vnode, struct iov_iter *iter, loff_t afs_op_set_vnode(op, 0, vnode); op->file[0].dv_delta = 1; op->file[0].modification = true; - op->store.write_iter = iter; op->store.pos = pos; op->store.size = size; - op->store.i_size = max(pos + size, vnode->netfs.remote_i_size); op->store.laundering = laundering; - op->mtime = vnode->netfs.inode.i_mtime; op->flags |= AFS_OPERATION_UNINTR; op->ops = &afs_store_data_operation; try_next_key: afs_begin_vnode_operation(op); + + op->store.write_iter = iter; + op->store.i_size = max(pos + size, vnode->netfs.remote_i_size); + op->mtime = vnode->netfs.inode.i_mtime; + afs_wait_for_operation(op); switch (op->error) {