On Sun, 24 Apr 2022 at 10:29, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > > On Thu, Apr 21, 2022 at 05:36:02PM +0200, Miklos Szeredi wrote: > > On Fri, 15 Apr 2022 at 13:54, Bernd Schubert <bschubert@xxxxxxx> wrote: > > > > > > This is just a safety precaution to avoid checking flags > > > on memory that was initialized on the user space side. > > > libfuse zeroes struct fuse_init_out outarg, but this is not > > > guranteed to be done in all implementations. Better is to > > > act on flags and to only apply flags2 when FUSE_INIT_EXT > > > is set. > > > > > > There is a risk with this change, though - it might break existing > > > user space libraries, which are already using flags2 without > > > setting FUSE_INIT_EXT. > > > > > > The corresponding libfuse patch is here > > > https://github.com/libfuse/libfuse/pull/662 > > > > > > > > > Signed-off-by: Bernd Schubert <bschubert@xxxxxxx> > > > > Agreed, this is a good change. Applied. > > > > Just one comment: please consider adding "Fixes:" and "Cc: > > <stable@....>" tags next time. I added them now. > > I am afraid that this probably will break both C and rust version of > virtiofsd. I had a quick look and I can't seem to find these > implementations setting INIT_EXT flag in reply to init. > > I am travelling. Will check it more closely when I return next week. > If virtiofsd implementations don't set INIT_EXT, I would rather prefer > to not do this change and avoid breaking it. Okay, let's postpone this kernel patch until libfuse and virtiofsd implementations are updated. Thanks, Miklos
