On Fri, Jun 07, 2024 at 09:15:31PM +0200, Mateusz Guzik wrote: > On Fri, Jun 7, 2024 at 8:43 PM Kent Overstreet > <kent.overstr...@linux.dev> wrote: > > > > On Fri, Jun 07, 2024 at 08:28:07PM +0200, Mateusz Guzik wrote: > > > Well I did a quick skim through, it's probably a no-go: > > > 1. uses bit locks which i'm told would be problematic vs lockdep and > > > rt kernels (see the original patchset by Dave Chinner, linked in my > > > fsdevel post) > > > > The bit spinlocks are confined to the rhashtable code; they're fine. > > > > That's indeed fine then, the worry was about bitlock -> spinlock ordering. > > > > 2. insertions can fail with ENOMEM? for this particular usage that is > > > very iffy to me, but i don't have a voting power in linux vfs > > > > Inode allocation can fail with -ENOMEM, so that's also fine. > > Of course it can fail. I'm saying the fewer failure points for inode > handling the better. > > But this is between you and vfs overlords.
Do you want to just do yet another bandaid, or a proper fix with a real data structure? Fixed size inode hash is a problem, and we need to stop hand rolling data structures. That's why I'm telling you I'm not in favor of your current approach.
