On Fri, Oct 04, 2019 at 05:02:20PM +0100, Al Viro wrote: > * (possibly) cifs hitting the same on eviction by memory pressure alone > (no locked inodes anywhere in sight). Possibly == if cifs IPC$ share happens to > show up non-empty (e.g. due to server playing silly buggers). > * (possibly) cifs hitting *another* lovely issue - lookup in one subdirectory > of IPC$ root finding an alias for another subdirectory of said root, triggering > d_move() of dentry of the latter. IF the name happens to be long enough to be > externally allocated and if dcache_readdir() on root is currently copying it to > userland, Bad Things(tm) will happen. That one almost certainly depends upon the > server playing silly buggers and might or might not be possible. I'm not familiar > enough with CIFS to tell. BTW, I would really appreciate somebody familiar with CIFS giving a braindump on that. Questions: 1) What's normally (== without malicious/broken server) seen when you mount an IPC$ share? 2) Does it ever have subdirectories (i.e. can we fail a lookup in its root if it looks like returning a subdirectory)? 3) If it can be non-empty, is there way to ask the server about its contents? Short of "look every possible name up", that is... As it is, the thing is abusing either cifs_lookup() (if it really shouldn't have any files in it) or dcache_readdir(). Sure, dcache_readdir() can (and should) pin a dentry while copying the name to userland, but WTF kind of semantics it is? "ls will return the things you'd guessed to look up, until there's enough memory pressure to have them forgotten, which can happen at any point with no activity on server"?
