kernel BUG at page_alloc.c

kernel BUG at page_alloc.c

[Studying MTD]

Hello all,

I am getting kernel BUG when i deal with big files :-

kernel BUG at page_alloc.c:203!

I am using 2.4.1 on SH4 and using only 32 MB RAM
without hard-disk, so only thing i am using is 32 MB
RAM .


/* page_alloc.c */
if (BAD_RANGE(zone,page))
	BUG();
DEBUG_ADD_PAGE    <--- line no 203


/* linux/swap.h */

#define DEBUG_ADD_PAGE \
	if (PageActive(page) || PageInactiveDirty(page) || \
	PageInactiveClean(page)) BUG();


Can someone please guide me and let me know the
work-around for this kernel BUG.

Thanks for your help.


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

Re: kernel BUG at page_alloc.c

[Studying MTD]

No, I am not using Nvidia.

Can you please let me know, who can cause this BUG ,
or their is any way to trace or work around for this
BUG :-

#define DEBUG_ADD_PAGE \
if (PageActive(page) || PageInactiveDirty(page) ||
\
 PageInactiveClean(page)) BUG();

Thanks.

--- Ed Tomlinson <tomlins@cam.org> wrote:
> Have you ever loaded any propriority modules on this
> kernel?
> Nvidia is the most common cause of this sort of bug.
>  I which
> case you need to talk to them - only they have the
> source.
> 
> Ed Tomlinson
> 
> Studying MTD wrote:
> 
> > Hello all,
> > 
> > I am getting kernel BUG when i deal with big files
> :-
> > 
> > kernel BUG at page_alloc.c:203!
> > 
> > I am using 2.4.1 on SH4 and using only 32 MB RAM
> > without hard-disk, so only thing i am using is 32
> MB
> > RAM .
> > 
> > 
> > /* page_alloc.c */
> > if (BAD_RANGE(zone,page))
> > BUG();
> > DEBUG_ADD_PAGE    <--- line no 203
> > 
> > 
> > /* linux/swap.h */
> > 
> > #define DEBUG_ADD_PAGE \
> > if (PageActive(page) || PageInactiveDirty(page) ||
> \
> > PageInactiveClean(page)) BUG();
> > 
> > 
> > Can someone please guide me and let me know the
> > work-around for this kernel BUG.
> > 
> > Thanks for your help.
> > 


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

Re: kernel BUG at page_alloc.c

[Studying MTD]

I also want to use latest kernel but new kernels give
many compilation errors and their links are broken for
SH platform.

Thanks.

--- Tomas Szepe <szepe@pinerecords.com> wrote:
> > I am using 2.4.1 on SH4 and using only 32 MB RAM
> > without hard-disk, so only thing i am using is 32
> MB
> > RAM .
> 
> Could you try a more recent kernel?
> 2.4.1 is now almost 2 years old.
> 
> T.


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

Re: kernel BUG at page_alloc.c

[Studying MTD]

I have noticed that difference in 2.4.1 and 2.5.25 is
:-

(2.4.1)
if (BAD_RANGE(zone,page))
	BUG();
DEBUG_ADD_PAGE

(2.2.25)
if (bad_range(zone, page))
      BUG();
prep_new_page(page);


prep_new_page(page) is replaced with DEBUG_ADD_PAGE
and prep_newpage is :-

/*
 * This page is about to be returned from the page
allocator
 */
static inline void prep_new_page(struct page *page)
{
        BUG_ON(page->mapping);
        BUG_ON(PagePrivate(page));
        BUG_ON(PageLocked(page));
        BUG_ON(PageLRU(page));
        BUG_ON(PageActive(page));
        BUG_ON(PageDirty(page));
        BUG_ON(PageWriteback(page));
        page->flags &= ~(1 << PG_uptodate | 1 <<
PG_error |
                        1 << PG_referenced | 1 <<
PG_arch_1 |
                        1 << PG_checked);
        set_page_count(page, 1);
}

vs

#define DEBUG_ADD_PAGE \
if (PageActive(page) || PageInactiveDirty(page) || \
	PageInactiveClean(page)) BUG();

Can i also replace DEBUG_ADD_PAGE with prep_new_page
in 2.4.1. Is it OK ?

Thank you very much for your help.


--- Tomas Szepe <szepe@pinerecords.com> wrote:
> > I am using 2.4.1 on SH4 and using only 32 MB RAM
> > without hard-disk, so only thing i am using is 32
> MB
> > RAM .
> 
> Could you try a more recent kernel?
> 2.4.1 is now almost 2 years old.
> 
> T.


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

Re: kernel BUG at page_alloc.c

[Tomas Szepe]

I reckon you'll have to get in touch with the SH port maintainers
and ask them directly. Have a peek in $linuxsrc/MAINTAINERS.

Have you tried any of the kernels available from
http://www.m17n.org/linux-sh/
?

T.


> I have noticed that difference in 2.4.1 and 2.5.25 is
> :-
> 
> (2.4.1)
> if (BAD_RANGE(zone,page))
> 	BUG();
> DEBUG_ADD_PAGE
> 
> (2.2.25)
> if (bad_range(zone, page))
>       BUG();
> prep_new_page(page);
> 
> 
> prep_new_page(page) is replaced with DEBUG_ADD_PAGE
> and prep_newpage is :-
> 
> /*
>  * This page is about to be returned from the page
> allocator
>  */
> static inline void prep_new_page(struct page *page)
> {
>         BUG_ON(page->mapping);
>         BUG_ON(PagePrivate(page));
>         BUG_ON(PageLocked(page));
>         BUG_ON(PageLRU(page));
>         BUG_ON(PageActive(page));
>         BUG_ON(PageDirty(page));
>         BUG_ON(PageWriteback(page));
>         page->flags &= ~(1 << PG_uptodate | 1 <<
> PG_error |
>                         1 << PG_referenced | 1 <<
> PG_arch_1 |
>                         1 << PG_checked);
>         set_page_count(page, 1);
> }
> 
> vs
> 
> #define DEBUG_ADD_PAGE \
> if (PageActive(page) || PageInactiveDirty(page) || \
> 	PageInactiveClean(page)) BUG();
> 
> Can i also replace DEBUG_ADD_PAGE with prep_new_page
> in 2.4.1. Is it OK ?
> 
> Thank you very much for your help.
> 
> 
> --- Tomas Szepe <szepe@pinerecords.com> wrote:
> > > I am using 2.4.1 on SH4 and using only 32 MB RAM
> > > without hard-disk, so only thing i am using is 32
> > MB
> > > RAM .
> > 
> > Could you try a more recent kernel?
> > 2.4.1 is now almost 2 years old.
> > 
> > T.
> 
> 
> __________________________________________________
> Do You Yahoo!?
> HotJobs - Search Thousands of New Jobs
> http://www.hotjobs.com

-- 
T.
       ,
    . ~ ~ .
  .'@ )) .. '..~
  > - ~`  '~\{   ejm'97

Re: kernel BUG at page_alloc.c

[Marcelo Tosatti]

On Wed, Sep 15, 2004 at 02:25:14PM +0200, Marcin Ro?ek wrote:
> Hi,
> here's what i can see in syslog (Mandrake 10 Official with kernel 2.4.27 
> and grsecurity patch)
> 
> kernel: kernel BUG at page_alloc.c:144!
> kernel: invalid operand: 0000
> kernel: CPU:    1
> kernel: EIP:    0010:[__free_pages_ok+82/784]    Not tainted
> kernel: EIP:    0010:[<c01d4a62>]    Not tainted
> kernel: EFLAGS: 00010286
> kernel: eax: 00000000   ebx: c13ae7e8   ecx: c13ae7e8   edx: 00000000
> kernel: esi: 00000008   edi: 00000000   ebp: c01037c0   esp: c2fdfe3c
> kernel: ds: 0018   es: 0018   ss: 0018
> kernel: Process smbd (pid: 30808, stackpage=c2fdf000)
> kernel: Stack: c01d48ff 00000000 00141000 c1149a9c c1149a9c c01d5ad8 
> c01037c0 00141100
> kernel:        dfe8dbf0 00000002 00000008 00141000 de305160 c01c6ff0 
> 00141100 c2fdfe7c
> kernel:        00001411 00000000 00141000 dd9490c0 c01c715f 00141000 
> 86838614 26838614
> kernel: Call Trace:    [rw_swap_page+63/96] [read_swap_cache_async+104/199] 
> [swapin_readahead+48/112] [do_swap_page+303/368] [handle_mm_fault+385/608]
> kernel: Call Trace:    [<c01d48ff>] [<c01d5ad8>] [<c01c6ff0>] [<c01c715f>] 
> [<c01c76a1>]
> kernel:   [do_page_fault+1264/1856] [generic_file_write+276/352] 
> [ext3_file_write+57/192] [sys_write+279/368] [do_page_fault+0/1856] 
> [error_code+52/64]
> kernel:   [<c01b0d90>] [<c01ce6c4>] [<c020d659>] [<c01dd027>] [<c01b08a0>] 
> [<c01a2304>]
> kernel:
> kernel: Code: 0f 0b 90 00 28 76 3b c0 8b 35 90 14 16 c0 89 d8 29 f0 c1 f8

Its the third or fourth report like this I see, all of them with the 
grsecurity patch applied.

Have you tried a stock 2.4.27?

kernel BUG at page_alloc.c

[Marcin Rożek]

Hi,
here's what i can see in syslog (Mandrake 10 Official with kernel 2.4.27 and 
grsecurity patch)

kernel: kernel BUG at page_alloc.c:144!
kernel: invalid operand: 0000
kernel: CPU:    1
kernel: EIP:    0010:[__free_pages_ok+82/784]    Not tainted
kernel: EIP:    0010:[<c01d4a62>]    Not tainted
kernel: EFLAGS: 00010286
kernel: eax: 00000000   ebx: c13ae7e8   ecx: c13ae7e8   edx: 00000000
kernel: esi: 00000008   edi: 00000000   ebp: c01037c0   esp: c2fdfe3c
kernel: ds: 0018   es: 0018   ss: 0018
kernel: Process smbd (pid: 30808, stackpage=c2fdf000)
kernel: Stack: c01d48ff 00000000 00141000 c1149a9c c1149a9c c01d5ad8 c01037c0 
00141100
kernel:        dfe8dbf0 00000002 00000008 00141000 de305160 c01c6ff0 00141100 
c2fdfe7c
kernel:        00001411 00000000 00141000 dd9490c0 c01c715f 00141000 86838614 
26838614
kernel: Call Trace:    [rw_swap_page+63/96] [read_swap_cache_async+104/199] 
[swapin_readahead+48/112] [do_swap_page+303/368] [handle_mm_fault+385/608]
kernel: Call Trace:    [<c01d48ff>] [<c01d5ad8>] [<c01c6ff0>] [<c01c715f>] 
[<c01c76a1>]
kernel:   [do_page_fault+1264/1856] [generic_file_write+276/352] 
[ext3_file_write+57/192] [sys_write+279/368] [do_page_fault+0/1856] 
[error_code+52/64]
kernel:   [<c01b0d90>] [<c01ce6c4>] [<c020d659>] [<c01dd027>] [<c01b08a0>] 
[<c01a2304>]
kernel:
kernel: Code: 0f 0b 90 00 28 76 3b c0 8b 35 90 14 16 c0 89 d8 29 f0 c1 f8



kernel: kernel BUG at page_alloc.c:144!
kernel: invalid operand: 0000
kernel: CPU:    1
kernel: EIP:    0010:[__free_pages_ok+82/784]    Not tainted
kernel: EIP:    0010:[<c01d4a62>]    Not tainted
kernel: EFLAGS: 00010286
kernel: eax: 00000000   ebx: c13ae7e8   ecx: c01039d8   edx: c0103820
kernel: esi: c13ae7e8   edi: 00000000   ebp: c01037c0   esp: c1591f08
kernel: ds: 0018   es: 0018   ss: 0018
kernel: Process kswapd (pid: 5, stackpage=c1591000)
kernel: Stack: 00000001 00000286 00000003 c8f9ae40 c8f9ae40 c8f9ae40 c13ae7e8 
c01e1eeb
kernel:        c8f9ae40 00000000 c13ae7e8 c01038fc 00004a6a c01d4074 c13ae7e8 
000001d0
kernel:        00000c80 000001d0 00000020 00000020 000001d0 c01038fc c01038fc 
c01d42ea
kernel: Call Trace:    [try_to_free_buffers+235/368] [shrink_cache+884/1072] 
[shrink_caches+74/96] [try_to_free_pages_zone+88/256] [schedule+738/1344]
kernel: Call Trace:    [<c01e1eeb>] [<c01d4074>] [<c01d42ea>] [<c01d4358>] 
[<c01b2052>]
kernel:   [kswapd_balance_pgdat+86/176] [kswapd_balance+40/64] [kswapd+152/185] 
[arch_kernel_thread+46/64] [kswapd+0/185]
kernel:   [<c01d4516>] [<c01d4598>] [<c01d46d8>] [<c01a068e>] [<c01d4640>]
kernel:
kernel: Code: 0f 0b 90 00 28 76 3b c0 8b 35 90 14 16 c0 89 d8 29 f0 c1 f8

Output from scripts/ver_linux
Linux blabla 2.4.27-grsec3 #1 SMP pon wrz 13 17:57:49 CEST 2004 i686 unknown 
unknown GNU/Linux
Gnu C                  3.3.2
Gnu make               3.80
util-linux             2.12
mount                  2.12
modutils               2.4.26
e2fsprogs              1.34
Linux C Library        2.3.3
Dynamic linker (ldd)   2.3.3
Procps                 3.1.15
Net-tools              1.60
Console-tools          0.2.3
Sh-utils               5.1.2
Modules Loaded

I can't reproduce this. It just 'happens'.

Regards,
Marcin

Re: kernel BUG at page_alloc.c

[Marcelo Tosatti]

On Wed, Sep 15, 2004 at 03:33:57PM +0200, Marcin Ro?ek wrote:
> Marcelo Tosatti wrote:
> >Its the third or fourth report like this I see, all of them with the 
> >grsecurity patch applied.
> >
> >Have you tried a stock 2.4.27?
> No.
> Is that bug serious? Should i move to clean 2.4.27?

Yes it is quite serious... the VM is trying to free a page with ->mapping 
set (probably a pagecache page) which is not valid thing to happen (thus the BUG).

You can move to v2.4.27 to confirm you see or do not see the problem there.

> Strange is that previously i've been running (for quite long time) Mandrake 
> 9.1 on the same machine with 2.4.27-grsec (but with enabled 
> CONFIG_GRKERNSEC_PAX_MPROTECT) and i don't remember seeing such BUG...A

Search the archives for "grsecurity and 2.4.27" and take a look 
at the other reports.

Re: kernel BUG at page_alloc.c

[Marcin Rożek]

Marcelo Tosatti wrote:
> Its the third or fourth report like this I see, all of them with the 
> grsecurity patch applied.
> 
> Have you tried a stock 2.4.27?
No.
Is that bug serious? Should i move to clean 2.4.27?

Strange is that previously i've been running (for quite long time) Mandrake 9.1 
on the same machine with 2.4.27-grsec (but with enabled 
CONFIG_GRKERNSEC_PAX_MPROTECT) and i don't remember seeing such BUG...

Here're my grsecurity settings:

CONFIG_GRKERNSEC=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_SHA256=y
# CONFIG_GRKERNSEC_LOW is not set
# CONFIG_GRKERNSEC_MID is not set
# CONFIG_GRKERNSEC_HI is not set
CONFIG_GRKERNSEC_CUSTOM=y
CONFIG_GRKERNSEC_PAX_EI_PAX=y
CONFIG_GRKERNSEC_PAX_PT_PAX_FLAGS=y
CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS=y
# CONFIG_GRKERNSEC_PAX_HAVE_ACL_FLAGS is not set
# CONFIG_GRKERNSEC_PAX_HOOK_ACL_FLAGS is not set
CONFIG_GRKERNSEC_PAX_NOEXEC=y
# CONFIG_GRKERNSEC_PAX_PAGEEXEC is not set
CONFIG_GRKERNSEC_PAX_SEGMEXEC=y
# CONFIG_GRKERNSEC_PAX_EMUTRAMP is not set
# CONFIG_GRKERNSEC_PAX_MPROTECT is not set
CONFIG_GRKERNSEC_PAX_ASLR=y
# CONFIG_GRKERNSEC_PAX_RANDKSTACK is not set
CONFIG_GRKERNSEC_PAX_RANDUSTACK=y
CONFIG_GRKERNSEC_PAX_RANDMMAP=y
# CONFIG_GRKERNSEC_KMEM is not set
# CONFIG_GRKERNSEC_IO is not set
CONFIG_GRKERNSEC_PROC_MEMMAP=y
CONFIG_GRKERNSEC_BRUTE=y
CONFIG_GRKERNSEC_HIDESYM=y
CONFIG_GRKERNSEC_ACL_HIDEKERN=y
CONFIG_GRKERNSEC_ACL_MAXTRIES=3
CONFIG_GRKERNSEC_ACL_TIMEOUT=30
CONFIG_GRKERNSEC_PROC=y
CONFIG_GRKERNSEC_PROC_USER=y
CONFIG_GRKERNSEC_PROC_ADD=y
CONFIG_GRKERNSEC_LINK=y
CONFIG_GRKERNSEC_FIFO=y
CONFIG_GRKERNSEC_CHROOT=y
CONFIG_GRKERNSEC_CHROOT_MOUNT=y
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
CONFIG_GRKERNSEC_CHROOT_PIVOT=y
CONFIG_GRKERNSEC_CHROOT_CHDIR=y
CONFIG_GRKERNSEC_CHROOT_CHMOD=y
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
CONFIG_GRKERNSEC_CHROOT_MKNOD=y
# CONFIG_GRKERNSEC_CHROOT_SHMAT is not set
CONFIG_GRKERNSEC_CHROOT_UNIX=y
# CONFIG_GRKERNSEC_CHROOT_FINDTASK is not set
# CONFIG_GRKERNSEC_CHROOT_NICE is not set
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
# CONFIG_GRKERNSEC_CHROOT_CAPS is not set
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set
# CONFIG_GRKERNSEC_EXECLOG is not set
# CONFIG_GRKERNSEC_RESLOG is not set
# CONFIG_GRKERNSEC_CHROOT_EXECLOG is not set
# CONFIG_GRKERNSEC_AUDIT_CHDIR is not set
# CONFIG_GRKERNSEC_AUDIT_MOUNT is not set
# CONFIG_GRKERNSEC_AUDIT_IPC is not set
CONFIG_GRKERNSEC_SIGNAL=y
CONFIG_GRKERNSEC_FORKFAIL=y
CONFIG_GRKERNSEC_TIME=y
# CONFIG_GRKERNSEC_PROC_IPADDR is not set
CONFIG_GRKERNSEC_EXECVE=y
CONFIG_GRKERNSEC_DMESG=y
CONFIG_GRKERNSEC_RANDPID=y
# CONFIG_GRKERNSEC_TPE is not set
CONFIG_GRKERNSEC_RANDNET=y
CONFIG_GRKERNSEC_RANDISN=y
CONFIG_GRKERNSEC_RANDID=y
CONFIG_GRKERNSEC_RANDSRC=y
CONFIG_GRKERNSEC_RANDRPC=y
# CONFIG_GRKERNSEC_SOCKET is not set
# CONFIG_GRKERNSEC_SYSCTL is not set
CONFIG_GRKERNSEC_FLOODTIME=10
CONFIG_GRKERNSEC_FLOODBURST=4

Re: kernel BUG at page_alloc.c

[Marcin Rożek]

Marcelo Tosatti wrote:
> Yes it is quite serious... the VM is trying to free a page with ->mapping 
> set (probably a pagecache page) which is not valid thing to happen (thus the BUG).
> 
> You can move to v2.4.27 to confirm you see or do not see the problem there.
It's a grsecurity bug: http://forums.grsecurity.net/viewtopic.php?t=933
On clean 2.4.27 everything works fine.
It happens only when MPROTECT is turned off in the kernel.

Regards,
Marcin