On Tuesday, October 10, 2023 4:23:06 AM CEST asmadeus@xxxxxxxxxxxxx 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