Hallo mailing list members. I am going through dentry cache internals of an old 2.2 kernel. I got to unexpected conclusions. They are described below. My question is whether these conclusions are correct. If not could You lead me to correct ones. process opened the file /home/paul/p.txt. dentry objects "home", "paul" and "p.txt" have been added to dentry cache. According to sys_open and especially lookup_dentry, d_count field of "p.txt" dentry has value 1, while remaining 2 dentries have value 0 and are put to LRU list, but are not removed from dentry hash map. process keeps p.txt file opened for a longer while and in the meantime free memory becomes scarce. prune_dcache is invoked and it starts going through LRU list, where it meets "home" and "paul" dentries. These dentries are deleted by subsequent invocation of prune_one_dentry, because all conditions to do so are met: "home" and "paul" are on LRU list and their d_count value = 0. The only thing I do not like is that d_parent field of "p.txt" dentry still points to dentry object that has just been removed. From this point I am further going to consider 2 scenarios. Scenario A: file p.txt is closed and then prune_dcache removes its dentry. Scenario B: another process (or even the same) opens /home/paul/p.txt. Scenario A. Now process closes p.txt thus invokes dput function on its dentry: it's d_count value becomes zero, but because it still remains in dentry hash map, recursive invocation is not activated. Further invocation of prune_dcache will just remove "p.txt" dentry from dentry hash map and give it back to slab allocator. Neither prune_dcache nor prune_one_dentry invoked by it uses d_parent field of "p.txt" dentry which is invalid, so everything is ok here. Scenario B. "home" and "paul" dentries have been given back to dentry cache, /home/paul/p.txt is still opened and another process opens it. lookup_dentry recreates "home" and "kwap" dentries and puts them to dentry cache. It also creates another instance of "p.txt" dentry because it has no way to get the previous copy: every dentry is identified by parent dentry address and its name. Name did not change, but the parent dentry address changed. We have to instances of "p.txt", both of them are in dentry hash map, but only one of them has valid parent. It looks tricky for me, but maybe acceptable. best regards -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
