On Thu, 18 Jan 2001, Petr Vandrovec wrote:
> > Rainer Mager reported the same thing yesterday ("Oops with 4GB memory
> > setting in 2.4.0 stable" if you want to read the thread).
>
> I think that I found source of problem. I have no simple solution :-(
>
I think the source of the problem is that this code was changed without
anyone being capable of actively maintaining it (time, knowledge,
motivation, ...). And later maintainers (me) haven't known or seen
anything wrong with it.
> But I'm not 100% sure, as this would mean that you do not
> kunmap/UnlockPage/page_cache_release any >1GB page at all in
> smb_free_cache_blocks(), as page pointer obtained by page_cache_entry()
> points to some random page (to couple just below 1GB boundary) instead
> of to correct one, so smbfs should die as soon as it finds first highmem
> page... Is it possible?
It sounds possible from the reports, where it has died as soon as it is
touched on a highmem mmachine.
> So your system has couple of chances to deadlock - either on out of
> kmaps, or on locked directory cache root (cachep), or on some of locked
> directory cache pages (blocks)...
Thanks for looking. I haven't begun to verify any of your previous
suggestions.
Copying the ncpfs cache code seems so much better. It's possibly a bigger
change (currently 20k diff -u) than to fix the cache.c code to do whatever
is right but the end result should be a lot better (I hope). Fixed size
cache entries makes lookups simpler, creating dentry/inode from the info
returned by the findfirst/findnext smb calls avoids extra calls on some
common(?) usage patterns.
Assuming your code is correct, and I'm sure it is, this should be a faster
way to do it than for me to figure out how the existing smbfs cahce can be
made to work. The differences are not that great between ncpfs and smbfs,
both are networked dos-ish filesystems. :)
My new code oopsed on me last night (and then I realized what time it
was). But so far the ncpfs code is fitting quite nicely.
/Urban
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jan 23 2001 - 21:00:17 EST