Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp333374imm; Tue, 24 Jul 2018 20:33:25 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdX8rnCpg1Y96PWT5Q6PBztVW7VbGz5+oHsymaxboTju64dogs/uOEm3iTnhNgHuDfjSW8M X-Received: by 2002:a65:6203:: with SMTP id d3-v6mr18820842pgv.420.1532489605820; Tue, 24 Jul 2018 20:33:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532489605; cv=none; d=google.com; s=arc-20160816; b=hxvk5Evr1nQeepMFKMHjHbEGhaLPhHYB4wyFreEf5daye2CJdUq2GiuToJi1fimafm zyW2HOp1OYIFzkpWJsTpzL+kpeaBdp1K2FhbH3N+Ykw/R2NtSIZBS4qYFHl7nrX9zdxB nwbP3RYvicFdwYdGPeV8PevPlS/o+ogf+OXXk40hMgDl/A1kekbG9HWXsw3lRFFqHAOW Nh66d5U0i8worXBwqu+63ddOZFsY22OtQNMh59XJs7TYBGFxUMs6QtpVOK1+ulZNS6SO 5m1wYiC/gB5F8IeDNCuLyRakphIWLyum6RIiWEib62iF92Ek88/lNqJxX5F0YgEDkM1O kdUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=33EInsPU4qFKDf97nUAj0cdeoaLFuSrQ83Z29qPH/rI=; b=A3aspHFEuXDaQGzCjfq+e/M0aR19GmsOCvfn6lL8dKqb/Obnr0tsubYr/64e3At7bj Y+lCzOsreR5hRrNshL0fHr2FgC2vtpwf/GroVypzaFwsI5a9gAhR7tmgN5ajCRvWe4pE FfSNrv8rVss/6vz00Yl323ARy62hvXFK/K3HMRypkwkXqoTLSMxtmMkOSAZh7vNSH6Ow TbmB1n0KVfDs6Lfnw+C+M0GL5Ys58w/tLxRxUPjBFqxu3QG3IhZiXPC7enVZgmn6/8/d wOFCXpxjSUy9EPY5/cybHQ3r6KqEiY9gHZAHQkxr/APx8CuIPkez/TlpGnXvgeEUgbLp bq7A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y38-v6si12015193pgl.73.2018.07.24.20.33.10; Tue, 24 Jul 2018 20:33:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727852AbeGYEl4 (ORCPT + 99 others); Wed, 25 Jul 2018 00:41:56 -0400 Received: from nautica.notk.org ([91.121.71.147]:51309 "EHLO nautica.notk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726878AbeGYElz (ORCPT ); Wed, 25 Jul 2018 00:41:55 -0400 Received: by nautica.notk.org (Postfix, from userid 1001) id 87AC8C009; Wed, 25 Jul 2018 05:32:15 +0200 (CEST) Date: Wed, 25 Jul 2018 05:32:00 +0200 From: Dominique Martinet To: piaojun Cc: "akpm@linux-foundation.org" , Eric Van Hensbergen , Ron Minnich , Latchesar Ionkov , Linux Kernel Mailing List , v9fs-developer@lists.sourceforge.net, groug@kaod.org Subject: Re: [PATCH] fs/9p/xattr.c: catch the error of p9_client_clunk when setting xattr failed Message-ID: <20180725033200.GA29865@nautica> References: <5B57EACC.2060900@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5B57EACC.2060900@huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org piaojun wrote on Wed, Jul 25, 2018: > In my testing, v9fs_fid_xattr_set will return successfully even if the > backend ext4 filesystem has no space to store xattr key-value. That will > cause inconsistent behavior between front end and back end. The reason is > that lsetxattr will be triggered by p9_client_clunk, and unfortunately we > did not catch the error. This patch will catch the error to notify upper > caller. > > p9_client_clunk (in 9p) > p9_client_rpc(clnt, P9_TCLUNK, "d", fid->fid); > v9fs_clunk (in qemu) > put_fid > free_fid > v9fs_xattr_fid_clunk > v9fs_co_lsetxattr > s->ops->lsetxattr > ext4_xattr_user_set (in host ext4 filesystem) > > Signed-off-by: Jun Piao Good catch! LGTM on its own but see comment below for further error checking. Please let me know if you want to do this in a v2 or submit a separate patch altogether, I can pick this one up as it is. > --- > fs/9p/xattr.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/fs/9p/xattr.c b/fs/9p/xattr.c > index f329eee..352abc3 100644 > --- a/fs/9p/xattr.c > +++ b/fs/9p/xattr.c > @@ -105,7 +105,7 @@ int v9fs_fid_xattr_set(struct p9_fid *fid, const char *name, > { > struct kvec kvec = {.iov_base = (void *)value, .iov_len = value_len}; > struct iov_iter from; > - int retval; > + int retval, err; > > iov_iter_kvec(&from, WRITE | ITER_KVEC, &kvec, 1, value_len); > > @@ -126,7 +126,9 @@ int v9fs_fid_xattr_set(struct p9_fid *fid, const char *name, > retval); > else > p9_client_write(fid, 0, &from, &retval); I'm not sure what to do about this but it's also possible for p9_client_write to not write the full length without setting and error. We should probably compare the return value of p9_client_write and value_len to detect short writes and return an error in this case. > - p9_client_clunk(fid); > + err = p9_client_clunk(fid); > + if (!retval && err) > + retval = err; > return retval; > } > > --