* Christian Brauner <brauner@xxxxxxxxxx> [241209 08:47]: > Hey, > > Ok, I wanted to give this another try as I'd really like to rely on the > maple tree supporting ULONG_MAX when BITS_PER_LONG is 64 as it makes > things a lot simpler overall. > > As Willy didn't want additional users relying on an external lock I made > it so that we don't have to and can just use the mtree lock. > > However, I need an irq safe variant which is why I added support for > this into the maple tree. > > This is pullable from > https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git work.pidfs.maple_tree I've been meaning to respond to this thread. I believe the flag is to tell the internal code what lock to use. If you look at mas_nomem(), there is a retry loop that will drop the lock to allocate and retry the operation. That function needs to support the flag and use the correct lock/unlock. The mas_lock()/mas_unlock() needs a mas_lock_irq()/mas_unlock_irq() variant, which would be used in the correct context. Does that make sense? Thanks, Liam > > Thanks! > Christian > > --- > Christian Brauner (2): > maple_tree: make MT_FLAGS_LOCK_IRQ do something > pidfs: use maple tree > > fs/pidfs.c | 52 +++++++++++++++++++++++++++------------------- > include/linux/maple_tree.h | 16 ++++++++++++-- > kernel/pid.c | 34 +++++++++++++++--------------- > 3 files changed, 62 insertions(+), 40 deletions(-) > --- > base-commit: 963c8e506c6d4769d04fcb64d4bf783e4ef6093e > change-id: 20241206-work-pidfs-maple_tree-b322ff5399b7 >
