Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
From:   Christian Schoenebeck <linux_oss@crudebyte.com>
To:     asmadeus@codewreck.org
Cc:     ericvh@kernel.org, lucho@ionkov.net, Su Hui <suhui@nfschina.com>,
        v9fs@lists.linux.dev, linux-kernel@vger.kernel.org,
        kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] fs/9p/xattr.c: avoid format-overflow warning
Date:   Tue, 10 Oct 2023 09:59:11 +0200
Message-ID: <1795281.aKYqWbn8Tv@silver>
In-Reply-To: <ZSS1irFMxC35cg01@codewreck.org>
References: <20231008060138.517057-1-suhui@nfschina.com> <13910281.Zj71IQSfG8@silver>
 <ZSS1irFMxC35cg01@codewreck.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

On Tuesday, October 10, 2023 4:23:06 AM CEST asmadeus@codewreck.org wrote:
> Christian Schoenebeck wrote on Mon, Oct 09, 2023 at 08:34:15PM +0200:
> > > +++ b/fs/9p/xattr.c
> > > @@ -139,7 +139,7 @@ int v9fs_fid_xattr_set(struct p9_fid *fid, const char *name,
> > >  
> > >  ssize_t v9fs_listxattr(struct dentry *dentry, char *buffer, size_t buffer_size)
> > >  {
> > > -	return v9fs_xattr_get(dentry, NULL, buffer, buffer_size);
> > > +	return v9fs_xattr_get(dentry, "", buffer, buffer_size);
> > >  }
> > >  
> > >  static int v9fs_xattr_handler_get(const struct xattr_handler *handler,
> > > 
> > 
> > Mmm, that's not the same is it? Have you tested this change?
> > 
> > Currently this function causes a 'Txattrwalk' 9p message to be sent to 9p
> > server with its name[s] field being NULL, and the latter being the magical
> > hint to 9p server to not send an attribute, but rather the list of attributes.
> > 
> > With your change I would assume that it would rather ask server for one
> > attribute called "". I have not tested myself, just worrying that it might
> > break behaviour.
> 
> p9pdu_vwritef should output the same (just a 0 length) for both NULL and
> "" so I think it should be ok, but it definitely needs testing.
> 
> I'll try to find time to check (getfattr -d should be enough) later this
> week and add it to the pile

Yeah, I think you are right Dominique, it should end up the same as both cases
result in a string length of 0.

/Christian