public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Roger Larsson <roger.larsson@norran.net>
To: Arjan Filius <iafilius@xs4all.nl>, Robert Love <rml@tech9.net>
Cc: <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>
Subject: [SMP lock BUG?] Re: Feedback on preemptible kernel patch
Date: Sat, 8 Sep 2001 22:58:18 +0200	[thread overview]
Message-ID: <200109082102.f88L2vo18714@mailb.telia.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0109081920540.3542-100000@sjoerd.sjoerdnet>
In-Reply-To: <Pine.LNX.4.33.0109081920540.3542-100000@sjoerd.sjoerdnet>

Hi,

This is interesting. [Assumes UP Athlon - correct]
Note that all BUGs out in highmem.h:95 (kmap_atomic)
and that test is only on if you have enabled HIGHMEM_DEBUG
[my analyze is done with a 2.4.10-pre2 kernel, but I checked with
later patches and I do not think they fix it either...]

The preemptive kernel puts more SMP stress on the kernel than
running with multiple CPUs.

So this might be a potential bug in the kernel proper, running with
a SMP computer.

If I understand the bug correctly, a process gets a page fault.
Starts to map in the page. But before the final part it checks -
and the page is already there!!! Correct?

On Saturday den 8 September 2001 19:33, Arjan Filius wrote:
> Hello Robert,
>
>
> I tried 2.4.10-pre4 with patch-rml-2.4.10-pre4-preempt-kernel-1.
> But it seems to hit highmem (see below) (i do have 1.5GB ram)
> 2.4.10-pre4 plain runs just fine.
>
> With the kernel option mem=850M the patched kernel boots an seems to run
> fine. However i didn't do any stress testing yet, but i still notice
> hickups while playing mp3 files at -10 nice level with mpg123 on a 1.1GHz
> Athlon, and removing for example a _large_ file (reiser-on-lvm).
>
> My syslog output with highmem:
>
> Sep  8 18:10:16 sjoerd kernel: kernel BUG at
> /usr/src/linux-2.4.10-pre4/include/asm/highmem.h:95! Sep  8 18:10:16 sjoerd
> kernel: invalid operand: 0000
> Sep  8 18:10:16 sjoerd kernel: CPU:    0
> Sep  8 18:10:16 sjoerd kernel: EIP:    0010:[do_wp_page+636/1088]
> [- - -]
> sjoerd kernel: Call Trace: [handle_mm_fault+141/224]
> [do_page_fault+375/1136] [do_page_fault+0/1136] [__mmdrop+58/64]
> [do_exit+595/640] Sep  8 18:10:16 sjoerd kernel:    [error_code+52/64]

Lets look at this example. You need to add some inline functions...

handle_mm_fault
	takes the mm->page_table_lock [this should prevent reschedules]
	allocs pmd
	allocs pte
	handle_pte_fault(...)
handle_pte_fault [inline, most likely path]
	pte is present
	it is a write access
	but the pte is not writeable  - call do_wp_page
do_wp_page
	plays some games with the lock...
	finally calls copy_cow_page [inline] with the page_table_lock
	UNLOCKED!
copy_cow_page
	calls clear_user_highpage or copy_user_highpage
both clear_user_highpage and copy_user_highpage
	calls kmap_atomic
kmap_atomic
	page is a highmem page
	but during the time this process was unlocked some other
	thread has allocated the page in question... BUG out.

So somewere between the UNLOCK (might be a lot later) and the
BUG test in kmap_atomic the process running in kernel got preempted.
(most likely during the page copy since it will take some time)

Another process (thread) started to run - hit the same page fault
but succeeded in its alloc.

Back to the first process it continues, finally checks - the page
is there... and BUGS.

Note that this can happen in a pure SMP kernel.

But let the processes (threads) run on two CPUs. And let the
first get an interrupt/bh after unlock - the other can pass
and add the page before the first one can continue - same
result!

/RogerL

-- 
Roger Larsson
Skellefteå
Sweden

  parent reply	other threads:[~2001-09-08 21:03 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-08  5:22 Feedback on preemptible kernel patch grue
2001-09-08  5:47 ` Robert Love
2001-09-08 17:33   ` Arjan Filius
2001-09-08 18:22     ` safemode
2001-09-08 20:58     ` Roger Larsson [this message]
2001-09-08 22:18       ` [SMP lock BUG?] " Arjan Filius
2001-09-09 14:55       ` george anzinger
2001-09-09 22:25         ` Arjan Filius
2001-09-09  4:40     ` Robert Love
2001-09-09 17:09       ` Robert Love
2001-09-09 21:07         ` Arjan Filius
2001-09-09 21:26           ` Robert Love
2001-09-09 21:23         ` Arjan Filius
2001-09-09 21:37           ` Robert Love
2001-09-10  3:24             ` Daniel Phillips
2001-09-10  3:37               ` Jeremy Zawodny
2001-09-10  5:09               ` Robert Love
2001-09-10 18:25                 ` Daniel Phillips
2001-09-10 21:29                 ` Arjan Filius
2001-09-13 17:27                   ` Robert Love
2001-09-14  7:30                     ` george anzinger
2001-09-14 15:01                       ` Robert Love
2001-09-11 19:47             ` Arjan Filius
2001-09-09 18:57   ` grue
2001-09-09 21:44     ` Robert Love
  -- strict thread matches above, loose matches on Subject: below --
2001-09-08 23:11 [SMP lock BUG?] " Manfred Spraul
2001-09-09  3:44 ` Robert Love
2001-09-09  7:38   ` Manfred Spraul
     [not found]   ` <001a01c1390262c7f30/mnt/sendme10411ac@local>
2001-09-14  9:15     ` Pavel Machek
2001-09-17 22:40       ` Manfred Spraul
2001-09-18  0:19         ` Robert Love
2001-09-17 22:41       ` Robert Love

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=200109082102.f88L2vo18714@mailb.telia.com \
    --to=roger.larsson@norran.net \
    --cc=iafilius@xs4all.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rml@tech9.net \
    /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