public inbox for linux-xfs@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox