From: george anzinger <george@mvista.com>
To: Roger Larsson <roger.larsson@norran.net>
Cc: Arjan Filius <iafilius@xs4all.nl>, Robert Love <rml@tech9.net>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [SMP lock BUG?] Re: Feedback on preemptible kernel patch
Date: Sun, 09 Sep 2001 07:55:43 -0700 [thread overview]
Message-ID: <3B9B82EF.A228F204@mvista.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0109081920540.3542-100000@sjoerd.sjoerdnet> <200109082102.f88L2vo18714@mailb.telia.com>
If the page it is the correct one, when it is found mapped, the code
should just exit, not BUG() IHMO.
George
Roger Larsson wrote:
>
> 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
> -
> 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/
WARNING: multiple messages have this Message-ID (diff)
From: george anzinger <george@mvista.com>
To: Roger Larsson <roger.larsson@norran.net>
Cc: Arjan Filius <iafilius@xs4all.nl>, Robert Love <rml@tech9.net>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [SMP lock BUG?] Re: Feedback on preemptible kernel patch
Date: Sun, 09 Sep 2001 07:55:43 -0700 [thread overview]
Message-ID: <3B9B82EF.A228F204@mvista.com> (raw)
In-Reply-To: 200109082102.f88L2vo18714@mailb.telia.com
If the page it is the correct one, when it is found mapped, the code
should just exit, not BUG() IHMO.
George
Roger Larsson wrote:
>
> 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
> Skelleftea
> Sweden
> -
> 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/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
next prev parent reply other threads:[~2001-09-09 14:56 UTC|newest]
Thread overview: 36+ 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 ` [SMP lock BUG?] " Roger Larsson
2001-09-08 20:58 ` Roger Larsson
2001-09-08 22:18 ` Arjan Filius
2001-09-08 22:18 ` Arjan Filius
2001-09-09 14:55 ` george anzinger [this message]
2001-09-09 14:55 ` george anzinger
2001-09-09 22:25 ` Arjan Filius
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=3B9B82EF.A228F204@mvista.com \
--to=george@mvista.com \
--cc=iafilius@xs4all.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rml@tech9.net \
--cc=roger.larsson@norran.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.