Message ID | 3526895.1687960024@warthog.procyon.org.uk |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp8947119vqr; Wed, 28 Jun 2023 07:01:12 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5izRrrgKasGTzAtfTLD/BcQ/hKQpW9FoAMwWh4DIPRrF686ibSRd3HT8s6VPbB6zn9/IFh X-Received: by 2002:a17:907:8a23:b0:988:8a02:457b with SMTP id sc35-20020a1709078a2300b009888a02457bmr1314194ejc.15.1687960871846; Wed, 28 Jun 2023 07:01:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687960871; cv=none; d=google.com; s=arc-20160816; b=XCQi+8Rl0qbzIK/jdk7EX9622w2Jv6g+X7unCv+o7xviB+umtZnGynH5NPOweEWM6G TEuS8ygDYyPTTYlhLwymZkjp/xAKpOhRsLCSHf6zYqCkD7Fj+3S9Rhyl2t8vyX95/aPv dz2N5U7aBNW62aaOZ96nQY+ttfdKDGX1nSkE2ldqdeoPWSepHFzpeZqXWDF9RRCp40rj knCOzT9djqE6Hz8YJhkPRLkCoJJWcX23iEtmGDGcmCDzULx8loq+A39Vzc5zTee1X3FZ DGbj88FsZmOJ0CIU/LBxs58VEu/vocNnEdrVgSTjwIt33OXoNwAIPnlxpXDGhSt85iSO XYYA== 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=Fn/bqfguGzs3lkCA5wKrTQnKBSDaj3bzPZJgusB7pXE=; fh=N23S1vBP9xl2gY8to3CDHaBH+cnULDtBu+nhgxQYUQ4=; b=OeaL8YLGUQMH2MzywemVWtxtMZALbvfZP1BZ6ENoP1+kTRMS8B8oHDjtc6AtEWq279 eeBjq8kcv/T0m1CTMlqogOPGE2WXRivVFOfaKFqtkKZ2fNO6y02S4VRp/14eJk90Scea C3Mx+AY+vycH1bRrFapIhWF6aj5CDutyvt64Fw15h+mYi8vJ0WMGTaLQTUHFspSZm5Kq FCVYeAvqNXmQ7+ajI6MMyPiLhxswxTjzsqGMSlfdk986h0M4089CfgJ2IDlp03wt7bRm AcwoGAcNs9eR/WSNg250NGrQVD3Vv0/LwpspWd1TkXRyTXoiNnl8LjkkDgAMZJemMWLO TI3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=D7MrOkA2; 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 z23-20020a1709064e1700b00989a806b3fasi5685513eju.1031.2023.06.28.07.00.44; Wed, 28 Jun 2023 07:01:11 -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=D7MrOkA2; 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 S231332AbjF1NsP (ORCPT <rfc822;adanhawthorn@gmail.com> + 99 others); Wed, 28 Jun 2023 09:48:15 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:32597 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232215AbjF1NsG (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 28 Jun 2023 09:48:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1687960037; 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=Fn/bqfguGzs3lkCA5wKrTQnKBSDaj3bzPZJgusB7pXE=; b=D7MrOkA2v+dpVPYLBlxnJ6FXdpM47qzSigIua6QZA96p961flgITIW6ZbasBDS0XfWevLt MNWyjCK6wFZe2DXl/0NAGpBPiDmrGNFZsQvCoKlpgPIjwGJHef6To2hbtfTJFCPjLi/ROb hfehA2HxmMB0ubgBU1DxG95bPFxXyBM= 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-669-2BDt8uANN7Kp1jMQTQhbfQ-1; Wed, 28 Jun 2023 09:47:14 -0400 X-MC-Unique: 2BDt8uANN7Kp1jMQTQhbfQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 08CF488D1A1; Wed, 28 Jun 2023 13:47:06 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.42.28.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6C5AC40C2063; Wed, 28 Jun 2023 13:47:05 +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 <dhowells@redhat.com> To: Marc Dionne <marc.dionne@auristor.com> cc: dhowells@redhat.com, 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-Type: text/plain; charset="us-ascii" Content-ID: <3526894.1687960024.1@warthog.procyon.org.uk> Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Jun 2023 14:47:04 +0100 Message-ID: <3526895.1687960024@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1769955259111414223?= X-GMAIL-MSGID: =?utf-8?q?1769955259111414223?= |
Series |
afs: Fix accidental truncation when storing data
|
|
Commit Message
David Howells
June 28, 2023, 1:47 p.m. UTC
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 <marc.dionne@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-afs@lists.infradead.org
cc: linux-fsdevel@vger.kernel.org
---
fs/afs/write.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
Comments
On 6/28/2023 9:47 AM, David Howells wrote: > > 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 <marc.dionne@auristor.com> > Signed-off-by: David Howells <dhowells@redhat.com> > cc: linux-afs@lists.infradead.org > cc: linux-fsdevel@vger.kernel.org > --- > 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) { Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
On Wed, Jun 28, 2023 at 10:47 AM David Howells <dhowells@redhat.com> wrote: > > > 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 <marc.dionne@auristor.com> > Signed-off-by: David Howells <dhowells@redhat.com> > cc: linux-afs@lists.infradead.org > cc: linux-fsdevel@vger.kernel.org > --- > 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) { Looks good to me; the traces where I got a failure indicate that an extending store occurred in a different thread while waiting for the io lock, so this looks like the right fix. Reviewed-by: Marc Dionne <marc.dionne@auristor.com> Marc
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) {