From: Andrew Morton <akpm@osdl.org>
To: Marco Fais <marco.fais@abbeynet.it>
Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: kernel BUG at page_alloc.c:98 -- compiling with distcc
Date: Fri, 2 Apr 2004 15:36:28 -0800 [thread overview]
Message-ID: <20040402153628.4a09d979.akpm@osdl.org> (raw)
In-Reply-To: <406D3E8F.20902@abbeynet.it>
(linux-2.4.25)
Marco Fais <marco.fais@abbeynet.it> wrote:
>
> kernel BUG at page_alloc.c:98!
>
uh-oh.
>
> > >EIP; c01372ae <__free_pages_ok+26e/280> <=====
>
> > >ebx; c14b3f00 <_end+116e728/204d48a8>
> > >ecx; c14b3f00 <_end+116e728/204d48a8>
> > >edi; dec11340 <_end+1e8cbb68/204d48a8>
> > >ebp; c02f1d04 <init_task_union+1d04/2000>
> > >esp; c02f1cd4 <init_task_union+1cd4/2000>
>
> Trace; c0135a76 <kmem_cache_free_one+f6/210>
> Trace; c021667b <skb_release_data+6b/90>
> Trace; c02166b4 <kfree_skbmem+14/70>
> Trace; c0216816 <__kfree_skb+106/160>
> Trace; c023be39 <tcp_clean_rtx_queue+139/330>
> Trace; c023c385 <tcp_ack+c5/380>
> Trace; c023f51c <tcp_rcv_state_process+19c/a90>
> Trace; c02465a9 <tcp_v4_do_rcv+a9/130>
> Trace; c0246a76 <tcp_v4_rcv+446/560>
> Trace; c022dad0 <ip_local_deliver_finish+0/180>
> Trace; c022dc25 <ip_local_deliver_finish+155/180>
> Trace; c0222780 <nf_hook_slow+b0/170>
> Trace; c022dad0 <ip_local_deliver_finish+0/180>
> Trace; c022d88f <ip_local_deliver+4f/70>
> Trace; c022dad0 <ip_local_deliver_finish+0/180>
> Trace; c022de3a <ip_rcv_finish+1ea/270>
> Trace; e08d7eab <[8139too]rtl8139_rx_interrupt+6b/3b0>
> Trace; c021ad14 <netif_receive_skb+c4/180>
> Trace; c021ae3f <process_backlog+6f/120>
> Trace; c021af5a <net_rx_action+6a/100>
> Trace; c0121cd7 <do_softirq+97/a0>
> Trace; c010a66d <do_IRQ+bd/f0>
distcc uses sendfile(). The 8139too hardware and driver are
zerocopy-capable so the kernel uses zerocopy direct-from-user-pages for
sendfile().
The bug is that the networking layer is releasing the final ref to user
pages from softirq context. Those pages are still on the page LRU so
__free_pages_ok() will take them off.
Problem is, removing these pages from the LRU requires that the
pagemap_lru_lock be taken, and that lock may not be taken from interrupt
context. So we go BUG instead.
This was all discussed fairly extensively a couple of years back and I
thought it ended up being fixed.
next parent reply other threads:[~2004-04-02 23:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <406D3E8F.20902@abbeynet.it>
2004-04-02 23:36 ` Andrew Morton [this message]
2004-04-05 10:47 ` kernel BUG at page_alloc.c:98 -- compiling with distcc Marco Fais
2004-04-05 10:56 ` Andrew Morton
2004-04-05 13:58 ` Marco Fais
2004-04-23 22:33 Carson Gaspar
2004-04-28 2:02 ` Jeff Moyer
2004-04-29 21:09 ` Marcelo Tosatti
2004-04-29 21:28 ` Andrew Morton
2004-04-29 22:49 ` Andrea Arcangeli
2004-04-29 23:26 ` Andrew Morton
2004-04-30 0:15 ` Andrea Arcangeli
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=20040402153628.4a09d979.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marco.fais@abbeynet.it \
--cc=netdev@oss.sgi.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;
as well as URLs for NNTP newsgroup(s).