From: "Petr Vandrovec" <VANDROVE@vc.cvut.cz>
To: Urban Widmark <urban@teststation.com>
Cc: <linux-kernel@vger.kernel.org>, kernel@hollins.edu
Subject: Re: oops in 2.4.1-pre8
Date: Thu, 18 Jan 2001 10:06:36 MET-1 [thread overview]
Message-ID: <12E9172B5107@vcnet.vc.cvut.cz> (raw)
> > Ethernet is compiled into the kernel as is smbfs (not as modules). I've
> > compiled this kernel with 4GB bigmem support (otherwise I only get 8xxMB
> > total).
>
> The smbfs cache code in 2.4.0 doesn't work with bigmem. For now disable
> bigmem or don't use smbfs, it's oopsing all the time.
>
> 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 :-(
You are using 'page_cache_entry()' function three times. But you
are using it on kmap()ped memory (cachep, in this oops example). So
it returns almost random value, which caused 'mapping' to be set
to NULL when doing grab_page_cache(), which caused oops later in
add_to_page_cache_unique...
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?
Same problem is in smb_free_dircache.
You can try using __find_get_page() with index to get 'struct *page'
(it should always suceed, as you have all pages locked...), instead
of page_cache_entry(), but better solution is using couple { page,
page_address } instead of page_address alone.
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)...
And one nonfatal ;-) In smb_add_to_cache you have:
page_off = PAGE_SIZE + (cachep->idx << PAGE_SHIFT);
page = grab_cache_page(mapping, page_off >> PAGE_CACHE_SHIFT);
This does not look correct to me. You should use PAGE_CACHE_SHIFT and
PAGE_CACHE_SIZE, as otherwise you'll receive same page for idx=1 and 2
when cache will use 8KB pages, but CPU 4KB ones. Using only first 4KB
of each cache page is better solution, than using same page for two
different indexes, I think... But as currently PAGE_CACHE_SIZE == PAGE_SIZE...
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
-
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/
next reply other threads:[~2001-01-18 9:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-18 10:06 Petr Vandrovec [this message]
2001-01-18 9:49 ` Urban Widmark
-- strict thread matches above, loose matches on Subject: below --
2001-01-17 21:47 Scott A. Sibert
2001-01-17 22:24 ` Urban Widmark
2001-01-18 16:02 ` Scott A. Sibert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=12E9172B5107@vcnet.vc.cvut.cz \
--to=vandrove@vc.cvut.cz \
--cc=kernel@hollins.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=urban@teststation.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®