Oops with 4GB memory setting in 2.4.0 stable
Quoted 6 lines · Urban Widmark
The smbfs dircache needs to find/kmap all of its cache pages since the entries in it are variable length and the way it is called. It would be nice to change that.
I haven't looked at all your detailed comments yet. They may not matter if the many kmaps are a problem.
I think that too many kmaps could explain reported 'silent hang'... (if my memory serves good, there was some report about silent PAE hang during last 7 days, yes?). Not-checking ->block for NULL looks like bug which can be triggered without kmap too.
Quoted 5 lines
how can it know that the dentry is the right one? I thought that dentries could be removed/reused by someone at will (
d_countwill be 0 because of the dput inncp_fill_cache, no?). Why isn't it possible for someone to write a new dentry where the old one was.
Quoted 7 lines
fs/ncpfs/dir.c:ncp_d_validate() calls
valid =d_validate(dentry, dentry->d_parent, dentry->d_name.hash, len);all values are taken from the dentry pointer on the cache page (including len).
d_validateverifies thatd_hash()points to a list and it searches the list for dentry. How do you know that it is the same dentry that was put in the cache and not someone elses dentry?
Before calling d_validate it checks whethern dentry->d_parent == parent (readdir-ed directory). And if dentry is in directory we read, it is in dentry d_hash, and even d_fsdata matches its position in directory, I bet that it is valid dentry...
If there is new dentry, which is at fpos postion, and it is child of readdir-ed directory, we should return it anyway, no? There must not be two ncpfs dentries with same d_parent and d_fsdata if d_fsdata != 0, as each dentry can be in only one directory.
This looked as reasonable limitation to me ;-)
Best regards,
Petr Vandrovec [email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 6 lines · Petr Vandrovec
If there is new dentry, which is at fpos postion, and it is child of readdir-ed directory, we should return it anyway, no? There must not be two ncpfs dentries with same
d_parentandd_fsdataifd_fsdata!= 0, as each dentry can be in only one directory.This looked as reasonable limitation to me ;-)
Right. I chose not to read those tests for some reason ... good.
The parent test should be ok. d_fsdata is only set in ncpfs if it is put in the cache and d_alloc sets it to 0. Works for me (whatever that may be worth).
Rewriting the smbfs cache code allows for a nice speedup too.
In ncpfs when reading a directory you create dentries and inodes at once. I assume that when reading the dir list from the server that you get all the info you need in one go.
I think smbfs gets all needed info on all protocol versions it supports, so that should be a nice speedup for readdir() + stat()-each file (ls -l). Currently it only caches name info and then does a remote call for each entry.
Too bad this is 2.4.0, the biggest problem may be sneaking it past Linus. oh well ... :)
/Urban
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Hi again,
It looks like some progress is being made, *wonderful*, as to some earlier
questions...
Quoted 1 line
I'll have a look tonight or so. It works for you on non-bigmem?
Yes. Absolutely no problems on non-bigmem.
Quoted 2 lines
smb_renamesuggests mv, but the process is ls ... er? What commands where you running on smbfs when it crashed?
It seems that ANY access to the smbfs has this affect. Definitely confirmed
are: ls, tab completion from bash, cat [some file], and usually df.
Quoted 3 lines
Could this be a symbol mismatch? Keith Owens suggested a less manual way to get module symbol output. Do you get the same results using that?
I'll try to do this and report back.
--Rainer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/