On Mon, May 06, 2019 at 11:36:10AM +0800, yangerkun wrote: > Hi, > > Run process parallel which each code show as below(2T memory), reference > count of root dentry will overflow since allocation of negative dentry > should do count++ for root dentry. Then, another dput of root dentry will > free it, which cause crash of system. I wondered is there anyone has found > this problem? The problem is, in principle, known - it's just that you need an obscene amount of RAM to trigger it (you need 4G objects of some sort to hold those references). _If_ you have that much RAM, there's any number of ways to hit that thing - it doesn't have to be cached results of lookups in directory as in your testcase. E.g. raise /proc/sys/fs/file-nr past 4Gb (you will need a lot of RAM for that, or the thing won't let you go that high) and just keep opening the same file (using enough processes to get around the per-process limit, or playing with SCM_RIGHTS sendmsg to yourself, etc.) I don't think that making dget() able to fail is a feasible approach; there are too many callers and hundreds of brand-new failure exits that will almost never be exercised is _the_ recipe for bitrot from hell. An obvious approach would be to use atomic_long_t; the problem is that it's not atomic_t - it's lockref, which is limited to 32 bits. Doing a wider variant... hell knows - wider cmpxchg variants might be usable, or we could put the upper bits into a separate word, with cmpxchg loops in lockref_get() et.al. treating "lower bits all zero" as "fall back to grabbing spinlock". Linus, lockref is your code, IIRC; which variant would you consider more feasible? We don't have that many places looking at the refcount, fortunately. And most of them are using d_count(dentry) (comparisons or printk). The rest is almost all in fs/dcache.c... So it's not as if we'd been tied to refcount representation by arseloads of code all over the tree.
