All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: hank peng <pengxihan@gmail.com>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: [BUG report]xfs_btree_make_block_unfull generated an OOPS
Date: Mon, 14 Dec 2009 21:15:09 -0600	[thread overview]
Message-ID: <4B26FF3D.2020500@sandeen.net> (raw)
In-Reply-To: <389deec70912141756k23776aajbc90c6d7e3fc8d4b@mail.gmail.com>

hank peng wrote:
> 2009/12/15 Dave Chinner <david@fromorbit.com>:
>> On Tue, Dec 15, 2009 at 08:49:37AM +0800, hank peng wrote:
>>> Hi, Eric:
>>> I add some code like this:
>>> if (*stat) {
>>>                 printk("*stat = 0x%08x, oindex = %p, index = %p\n",
>>>                                 *stat, oindex, index);
>>>                 if (oindex == NULL || index == NULL) {
>> This won't catch bad non-NULL pointers like you are seeing.
>>
>>>                         printk("BUG occured!\n");
>>>                         printk("oindex = %p, index = %p\n", oindex, index);
>>>                         BUG();
>>>                 }
>>>                 *oindex = *index = cur->bc_ptrs[level];
>>>                 return 0;
>>>         }
>>>
>>> And the same OOPS happened again but a little different, kernel messages are:
>>>
>>> <snip>
>>> *stat = 0x00000001, oindex = e87d7bf8, index = e87d7bfc
>>> *stat = 0x00000001, oindex = e87d7bf8, index = e87d7bfc
>>> *stat = 0x00000001, oindex = e87d7bf8, index = e87d7bfc
>>> *stat = 0x00000001, oindex = e87d7bf8, index = e87d7bfc
>>> *stat = 0x00000001, oindex = 00000501, index = 22008424
>>> Unable to handle kernel paging request for data at address 0x22008424

Are you using any of the xfs userspace prior to this error, or is it a
fresh boot and just normal IO?

I ask because libxfs calls sys_ustat() which at one point was corrupting
userspace, at least, with 32-bit userspace on a 64-bit kernel:
https://bugzilla.redhat.com/show_bug.cgi?id=472795

Even with that fixed there were still some reports of odd behavior
on ppc... I don't know if things might be going wrong in kernelspace
as well...

https://bugzilla.redhat.com/show_bug.cgi?id=517994
and I haven't gotten to the bottom of that yet ...

Very few things actually use sys_ustat, but xfs userspace does...
just a random thought.

-eric

>> Given that oindex and index are stack varibles, this indicates some
>> thing is probably smashing the stack. Possibly a buffer overrun. To
>> narrow down the possible cause, can you add the debug:
>>
>>        printk("%s:%s: oindex = %p, index = %p\n",
>>                        __func__, __LINE__, oindex, index);
>>
>> throughout the xfs_btree_make_block_unfull() function? i.e. at
>> first entry, before the xfs_btree_rshift() call, before the
>> xfs_btree_lshift() call, etc, to see if any of the parameters
>> are being modified during execution of the function?
>>
>> If the variables being passed into xfs_btree_make_block_unfull() are
>> already bad, then do the same thing for the caller
>> xfs_btree_insert(). This may help narrow down where the problem
>> is coming from....
>>
> Thanks for your reply!
> As you said, I added some code like this:
> /* First, try shifting an entry to the right neighbor. */
>         printk("%s: before xfs_btree_rshift, oindex = %p, index = %p\n",
>                         __func__, oindex, index);
>         error = xfs_btree_rshift(cur, level, stat);
>         if (error || *stat)
>                 return error;
> 
>         /* Next, try shifting an entry to the left neighbor. */
>         printk("%s: before xfs_btree_lshift, oindex = %p, index = %p\n",
>                         __func__, oindex, index);
>         error = xfs_btree_lshift(cur, level, stat);
>         if (error)
>                 return error;
> 
>         if (*stat) {
>                 printk("*stat = 0x%08x, oindex = %p, index = %p\n",
>                                 *stat, oindex, index);
>                 if (oindex == NULL || index == NULL) {
>                         printk("BUG occured!\n");
>                         printk("oindex = %p, index = %p\n", oindex, index);
>                         BUG();
>                 }
>                 *oindex = *index = cur->bc_ptrs[level];
>                 return 0;
>         }
> 
> 
> xfs_btree_set_ptr_null(cur, &nptr);
>         if (numrecs == cur->bc_ops->get_maxrecs(cur, level)) {
>                 printk("%s: before calling
> xfs_btree_make_block_unfull, &optr = %p, &ptr = %p\n",
>                                 __func__, &optr, &ptr);
>                 error = xfs_btree_make_block_unfull(cur, level, numrecs,
>                                         &optr, &ptr, &nptr, &ncur, &nrec, stat);
>                 if (error || *stat == 0)
>                         goto error0;
>         }
> 
> 
> We are waiting for OOPS to happen.
> 
> I hope it will nerver be memory corrupt problem which is nightmare for
> me to debug.
> 
>> Cheers,
>>
>> Dave.
>> --
>> Dave Chinner
>> david@fromorbit.com
>>
> 
> 
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2009-12-15  3:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-09  1:58 [BUG report]xfs_btree_make_block_unfull generated an OOPS hank peng
2009-12-09  2:57 ` Eric Sandeen
2009-12-09  3:18   ` hank peng
     [not found]     ` <4B1F18C4.3060704@sandeen.net>
     [not found]       ` <389deec70912082053v4310057dg479f6d4b6c4b46f7@mail.gmail.com>
     [not found]         ` <4B1F31FD.3020705@sandeen.net>
     [not found]           ` <389deec70912082220pcb3b5d1q516ac197d31502c5@mail.gmail.com>
     [not found]             ` <389deec70912082230g38987576pc48d7699f23844c5@mail.gmail.com>
     [not found]               ` <389deec70912140119q40ed91cao62fe9c9ebdf13601@mail.gmail.com>
2009-12-14 15:56                 ` Eric Sandeen
2009-12-15  0:49                   ` hank peng
2009-12-15  0:58                     ` hank peng
2009-12-15  1:26                     ` Dave Chinner
2009-12-15  1:56                       ` hank peng
2009-12-15  3:15                         ` Eric Sandeen [this message]
2009-12-15  3:22                           ` hank peng
2009-12-15  5:36                       ` hank peng
2010-01-13  1:11                       ` hank peng

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=4B26FF3D.2020500@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=pengxihan@gmail.com \
    --cc=xfs@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 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.