On Thu, 1 Oct 2026 at 20:59, Amir Goldstein <[email protected]> wrote:
> > > All 64 bit values are valid. > > > > Can you reserve id 0? or have a reason to need it? I thought that removing all restrictions on the value would be nice. But okay, zero value we can live without. > > It would feel a little less hacky if we do: > > else > > fuse_backing_files_init_32(fc); > > > > and set > > fc->passthrough = 1; > > > > inside both of them to gate against fuse_backing_files_free() > > called without processing init response, > > or without either FUSE_PASSTHROUGH in the init response. Bigger problem is that IOC_BACKING_OPEN can be done before or during INIT. So we need to take care of that case and the race as well. Fixed by: - leaving the idr initialization fuse_conn_init() - adding fc->backing_id_32 flag which is set by fuse_backing_open() after chekcking that fc->backing_id_64 is not set. All under fc->lock - in process_init_reply() checking fc->backing_id_32 before setting fc->backing_id_64 and failing the connection if so. Also under fc->lock - in fuse_dev_ioctl_backing_create() if fch->initialized is not set return ENOTCONN > Also we should not enable passthrough if rhashtable_init has failed. rhashtable_init() can't fail if parameters are correct since it falls back to __GFP_NOFAIL() for allocation. Thanks, Miklos
