On Fri, Oct 25 2019, J. Bruce Fields wrote: > >> Also, should we put a cond_resched() in some or all of those loops in >> __destroy_client() ?? > > Looks like it helped find a bug in this case.... > > Destroying a client that has a ton of active state should be an unusual > situation. > > I don't know, maybe? I'm sure this isn't the only spinlock-protected > kernel code where we don't have a strict bound on a loop, what's been > the practice elsewhere? Worst case, the realtime code allows preempting > spinlocks, right? git grep cond_resched_lock But most of __destroy_client isn't protected by a spinlock.... I dunno - maybe it doesn't matter. > Might be nice to have some sort of limits on the number of objects (like > stateowners) that can be created. But it's a pain when we get one of > those limits wrong. (See > git log -L :nfsd4_get_drc_mem:fs/nfsd/nfs4state.c.) Grin... > NeilBrown
Attachment:
signature.asc
Description: PGP signature
