On Wed, Aug 28, 2024 at 1:02 PM Han-Wen Nienhuys <hanwenn@xxxxxxxxx> wrote: > > On Wed, Aug 28, 2024 at 12:48 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > > Similarly, it looks like the first backing ID is usually 1. Is it > > > guaranteed that 0 is never a valid backing ID? I am not sure, and it > > > would certainly help implementation on my side. > > > > No guarantee. > > There was some suggestion about special use for value 0, > > but I don't remember what it was right now. > > In a file system, not all inodes are backed by a file. If 0 would not > be handed out as an ID, then backing ID=0 could mean: this node is not > backed by a file (and doesn't need to unregister the ID on > forget/release). If 0 is a valid ID, I either have to add another > boolean to the inode, or keep calling the ioctl until I get a non-zero > value. > > Reading, the code, the call is > > id = idr_alloc_cyclic(&fc->backing_files_map, fb, 1, 0, GFP_ATOMIC); > > ie. start=1. In other words, if the counter wraps, it will start at 1 > again, and 0 is not handed out. Yes, I understand. I think the rational for reserving 0 as special value was for the future use of FOPEN_PASSTHROUGH response to mean "passthrough to backing inode if one was already mapped during lookup". So yeah, I am personally ok with the backing id handle being > 0 as it is in the code right now. Thanks, Amir.
