On Tuesday 01 October 2002 16:20, Richard.Zidlicky@stud.informatik.uni-erlangen.de wrote:
> >
> > The theoretical lru race possibly spotted in the wild...
> >
> > >
> > > Now I am wondering if that is just coincidence or why m68k hit that
> > > error so reliably.. is it supposed to have any effect at all on
> > > UP?
> >
> > Are you running UP+preempt?
>
> no preempt or anything fancy, m68k vanila 2.4.19 (well almost).
I'm having real trouble spotting substantive change in the patch that
would affect a UP kernel. I believe you when you say it fixes your
problem, but we don't know why, and it is worth making some effort to
find out why.
Ah wait, I see one candidate, would you like to try:
* the page as well.
*/
if (page->buffers) {
/* avoid to free a locked page */
- get_page(page);
spin_unlock(&pagemap_lru_lock);
+ get_page(page);
and see if your bug comes back? There are a couple of other changes
that could be considered substantive by stretching one's imagination
enough, but this is the leading candidate.
Oh wait, you could also try this, a little further down:
+ page_cache_release(page);
spin_lock(&pagemap_lru_lock);
- put_page_nofree(page);
By the way, the original patch you posted was reversed and your editor
apparently took the liberty of cleaning up some whitespace in the file.
Generally, we try do avoid patch chunks that just, e.g., change bogus
spaces to tabs, and save those for official whitespace patches.
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 07 2002 - 22:00:26 EST