All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joseph Cheek <joseph@cheek.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: kernel BUG at buffer.c:827 in test12-pre6 and 7
Date: Thu, 07 Dec 2000 18:16:08 -0800	[thread overview]
Message-ID: <3A304468.35E694B@cheek.com> (raw)
In-Reply-To: <3A30125D.5F71110D@cheek.com> <90p9kf$5p3$1@penguin.transmeta.com>

hi,

comments below.

Linus Torvalds wrote:

> In article <3A30125D.5F71110D@cheek.com>,
> Joseph Cheek  <joseph@cheek.com> wrote:
> >copying files off a loopback-mounted vfat filesystem exposes this bug.
> >test11 worked fine.
>
> It's not a new bug - it's an old bug that apparently is uncovered by a
> new stricter test.
>
> Apparently loopback unlocks an already unlocked page - which has always
> been a serious offense, but has never been detected before.
>
> test12-pre6+ detects it, and thus the BUG().
>
> Your stack trace isn't symbolic (see Documentation/oops-tracing.txt), so
> it's impossible to debug, but it's already interesting information to
> see that it seems to be either loopback of vfat.
>
> Can you test some more? In particular, I'd love to hear if this happens
> with vfat even without loopback, or with loopback even without vfat
> (make an ext2 filesystem or similar instead). That woul dnarrow down the
> bug further.

this happens on loopbacked ext2, and not on regular vfat.  so it appears that
the culprit is loopback.  i got ksymoops working, here are the traces from
the vfat-over-loopback [first] and the ext2-over-loopback [second].

again, these are copied by hand, so i give it a 1% chance of
mistranscription.

ksymoops 2.3.5 on i686 2.4.0.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.0/ (default)
     -m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

kernel BUG at buffer.c:827!
invalid operand: 0000
CPU: 0
EIP: 0010:[<c013660c>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010082
eax: 0000001c ebx: c1d8fc60 ecx: 00000000 edx: 00000001
esi: c10658e4 edi: 00000002 ebp: c1d8fca8 esp: c1793dc0
ds: 0018 es: 0018 ss: 0018
Process cp (pid 762, stackpage=c1793000)
Stack: c01fe484 c01fe95a 0000033b c1d8fc60 c1cef420 00000001 00000001
c01610e1
       c1d8fc60 00000001 c1cef420 00000000 c1cef420 c02c8ed8 c88df91c
c1cef420
       00000001 c88e0986 00000007 00000000 00000001 c02c8ed8 c02c8ee8
c4f18800
Call Trace: [<c01fe484>] [<c01fe95a>] [<c0130703>] [<c8895de3>]
[<c88df91c>] [<c8894494>] [<c0160d2f>] [<c0160ead>]
       [<c0161011>] [<c0137a49>] [<c0130703>] [<c8895de3>] [<c8894494>]
[<c01284d3>] [<c012887b>] [c0128720>]
       [<c889448d>] [<c01349a7>] [c010b56b>]
Code: 0f 0b 83 c4 0c 8d 5e 28 8d 46 2c 39 46 2c 74 24 b9 01 00 00

>>EIP; c013660c <end_buffer_io_async+e0/11c>   <=====
Trace; c01fe484 <tvecs+4fc0/13968>
Trace; c01fe95a <tvecs+5496/13968>
Trace; c0130703 <__alloc_pages+df/2d4>
Trace; c8895de3 <[fat]fat_readpage+f/14>
Trace; c88df91c <[cdrom]cdrom_read_mech_status+c/4c>
Trace; c8894494 <[fat]fat_get_block+0/e4>
Trace; c0160d2f <__make_request+5cb/648>
Trace; c0160ead <generic_make_request+101/110>
Trace; c0161011 <ll_rw_block+155/1c4>
Trace; c0137a49 <block_read_full_page+1fd/2a8>
Trace; c0130703 <__alloc_pages+df/2d4>
Trace; c8895de3 <[fat]fat_readpage+f/14>
Trace; c8894494 <[fat]fat_get_block+0/e4>
Trace; c01284d3 <do_generic_file_read+337/584>
Trace; c012887b <generic_file_read+5b/74>
Trace; c889448d <[fat]fat_file_read+2d/34>
Trace; c01349a7 <sys_read+8f/c4>
Code;  c013660c <end_buffer_io_async+e0/11c>
0000000000000000 <_EIP>:
Code;  c013660c <end_buffer_io_async+e0/11c>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c013660e <end_buffer_io_async+e2/11c>
   2:   83 c4 0c                  add    $0xc,%esp
Code;  c0136611 <end_buffer_io_async+e5/11c>
   5:   8d 5e 28                  lea    0x28(%esi),%ebx
Code;  c0136614 <end_buffer_io_async+e8/11c>
   8:   8d 46 2c                  lea    0x2c(%esi),%eax
Code;  c0136617 <end_buffer_io_async+eb/11c>
   b:   39 46 2c                  cmp    %eax,0x2c(%esi)
Code;  c013661a <end_buffer_io_async+ee/11c>
   e:   74 24                     je     34 <_EIP+0x34> c0136640
<end_buffer_io_async+114/11c>
Code;  c013661c <end_buffer_io_async+f0/11c>
  10:   b9 01 00 00 00            mov    $0x1,%ecx


1 warning issued.  Results may not be reliable.

ksymoops 2.3.5 on i686 2.4.0.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.0/ (default)
     -m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

kernel BUG at buffer.c:827!
invalid operand: 0000
CPU: 0
EIP: 0010:[<c013660c>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010086
eax: 0000001c ebx: c1d212a0 ecx: 00000000 edx: 00000001
esi: c11274bc edi: 00000002 ebp: c1d212e8 esp: c4f1bddc
ds: 0018 es: 0018 ss: 0018
Process cp (pid 772, stackpage=c4f1b000)
Stack: c01fe484 c01fe95a 0000033b c1d21290 c1983420 00000002 00000001
c01610e1
       c1d212a0 00000001 c1983420 00000000 c1983420 c02c8ed8 c88df91c
c1983420
       00000001 c88e0986 00000007 00000000 00000002 c02c8ed8 c02c8ee8
c4cdf998
Call Trace: [<c01fe484>] [<c01fe95a>] [<c01610e1>] [<c88df91c>] [<c88e0986>]
[<c0160d2f>] [<c0160ead>]
       [<c0161011>] [<c0137a49>] [<c0130703>] [<c0156223>] [<c0155b38>]
[<c012887b>] [c0128720>]
       [<c01349a7>] [c010b56b>]
Code: 0f 0b 83 c4 0c 8d 5e 28 8d 46 2c 39 46 2c 74 24 b9 01 00 00

>>EIP; c013660c <end_buffer_io_async+e0/11c>   <=====
Trace; c01fe484 <tvecs+4fc0/13968>
Trace; c01fe95a <tvecs+5496/13968>
Trace; c01610e1 <end_that_request_first+61/b8>
Trace; c88df91c <[cdrom]cdrom_read_mech_status+c/4c>
Trace; c88e0986 <[cdrom]cdrom_read_block+3a/f8>
Trace; c0160d2f <__make_request+5cb/648>
Trace; c0160ead <generic_make_request+101/110>
Trace; c0161011 <ll_rw_block+155/1c4>
Trace; c0137a49 <block_read_full_page+1fd/2a8>
Trace; c0130703 <__alloc_pages+df/2d4>
Trace; c0156223 <ext2_readpage+f/14>
Trace; c0155b38 <ext2_get_block+0/4e0>
Trace; c012887b <generic_file_read+5b/74>
Trace; c01349a7 <sys_read+8f/c4>
Code;  c013660c <end_buffer_io_async+e0/11c>
0000000000000000 <_EIP>:
Code;  c013660c <end_buffer_io_async+e0/11c>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c013660e <end_buffer_io_async+e2/11c>
   2:   83 c4 0c                  add    $0xc,%esp
Code;  c0136611 <end_buffer_io_async+e5/11c>
   5:   8d 5e 28                  lea    0x28(%esi),%ebx
Code;  c0136614 <end_buffer_io_async+e8/11c>
   8:   8d 46 2c                  lea    0x2c(%esi),%eax
Code;  c0136617 <end_buffer_io_async+eb/11c>
   b:   39 46 2c                  cmp    %eax,0x2c(%esi)
Code;  c013661a <end_buffer_io_async+ee/11c>
   e:   74 24                     je     34 <_EIP+0x34> c0136640
<end_buffer_io_async+114/11c>
Code;  c013661c <end_buffer_io_async+f0/11c>
  10:   b9 01 00 00 00            mov    $0x1,%ecx


1 warning issued.  Results may not be reliable.

--
thanks!

joe

--
Joseph Cheek, Sr Linux Consultant, Linuxcare | http://www.linuxcare.com/
Linuxcare.  Support for the Revolution.      | joseph@linuxcare.com
CTO / Acting PM, Redmond Linux Project       | joseph@redmondlinux.org
425 990-1072 vox [1074 fax] 206 679-6838 pcs | joseph@cheek.com



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  parent reply	other threads:[~2000-12-08  2:47 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-07 22:42 kernel BUG at buffer.c:827 in test12-pre6 and 7 Joseph Cheek
2000-12-07 23:14 ` Keith Owens
2000-12-08  0:22 ` Linus Torvalds
2000-12-08  1:23   ` Joseph Cheek
2000-12-08  3:03     ` Keith Owens
2000-12-08  2:16   ` Joseph Cheek [this message]
2000-12-08  7:27   ` Tom Leete
2000-12-08  9:07 ` David Woodhouse
2000-12-08  9:58   ` [found?] " Alexander Viro
2000-12-08 18:11     ` [PATCH] " Alexander Viro
2000-12-08 18:48       ` Linus Torvalds
2000-12-08 19:13         ` Alexander Viro
2000-12-08 19:39           ` Linus Torvalds
2000-12-08 19:50             ` Daniel Phillips
2000-12-08 21:17               ` Linus Torvalds
2000-12-08 22:30             ` Alexander Viro
2000-12-08 22:42               ` Linus Torvalds
2000-12-09  4:59                 ` Alexander Viro
2000-12-09  8:45                   ` Linus Torvalds
2000-12-09  8:56                     ` Linus Torvalds
2000-12-09 10:40                     ` Alexander Viro
2000-12-09 12:56                       ` Andries Brouwer
2000-12-09 13:11                         ` Alexander Viro
2000-12-09 21:25                           ` Mikulas Patocka
2000-12-10  1:11                             ` Linus Torvalds
2000-12-09 17:28                       ` Linus Torvalds
2000-12-09 18:43                         ` Andi Kleen
2000-12-09 14:00                     ` David S. Miller
2000-12-09 15:37           ` David Woodhouse
2000-12-12  0:54 ` [FIXED!] " Joseph Cheek

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=3A304468.35E694B@cheek.com \
    --to=joseph@cheek.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.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 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.