Oops with 4GB memory setting in 2.4.0 stable
Quoted 15 lines · Urban Widmark
Quoted 5 lines · Rainer Mager
Hi all,
I have a 100% reproducable bug in all of the 2.4.0 kernels including the
latest stable one. The issue is that if I compile the kernel to support 4GB RAM (I have 1 GB) and then try to access a samba mount I get an oops. ThisI'll have a look tonight or so. It works for you on non-bigmem?
Quoted 4 lines
ALWAYS happens. Usually after this the system is frozen (although the magic SYSREQ still works). If the system isn't frozen then any commands that access the disk will freeze. Fortunately GPM worked and I was able to paste the oops to a file via telnet.
Quoted 5 lines
smb_renamesuggests mv, but the process is ls ... er? What commands where you running on smbfs when it crashed?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?
smb_get_dircache looks suspicious to me, as it can try to map unlimited number of pages with kmap. And kmaps are not unlimited resource... You have 512 kmaps, but one SMBFS cache page can contain about 504 pages... So two smbfs cached directories can consume all your kmaps, dying then in endless loop in mm/highmem.c:map_new_virtual().
Also, smb_add_to_cache looks suspicious:
cachep->idx++;
if (cachep->idx > NINDEX) goto out_full;
cannot idx grow over any limit?
get_block:
cachep->pages++;
...
if (page) {
block = kmap(page);
...}
Should not you increment cachep->pages only if grab_cache_page succeeded? This can cause that smb_find_in_cache finds NULL index->block, which then oopses...
smb_find_in_cache should verify index->block == NULL anyway, as smb_get_dircache can return couple of index->block == NULL when system decided to throw out one of cache pages connected to directory.
But I personally do not use neither smbfs nor PAE, so what I can say...
Best regards,
Petr Vandrovec [email protected]
BTW: For ncpfs PAE testing I was using patch which needed kmap() for all memory above 32MB... It was very educational...
-
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 5 lines · Petr Vandrovec
smb_get_dircachelooks suspicious to me, as it can try to map unlimited number of pages with kmap. And kmaps are not unlimited resource... You have 512 kmaps, but one SMBFS cache page can contain about 504 pages... So two smbfs cached directories can consume all your kmaps, dying then in endless loop in mm/highmem.c:map_new_virtual().
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.
The ncpfs code puts 'struct dentry *' in it's cache pages. Fixed size entries makes it easy to know which page you need to start reading from, so only one kmap is needed. That looks simpler so I want to steal it, except ...
ncpfs ends up calling d_validate to verify that the dentry is sane. But how can it know that the dentry is the right one? I thought that dentries could be removed/reused by someone at will (d_count will be 0 because of the dput in ncp_fill_cache, no?). Why isn't it possible for someone to write a new dentry where the old one was.
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_validate verifies that d_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?
Quoted 1 line
But I personally do not use neither smbfs nor PAE, so what I can say...
A whole lot, thanks. Especially for the kmap info.
Now if someone could explain the dentry pointers ... what am I missing?
/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/