All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Tinguely <tinguely@sgi.com>
To: "Michael L. Semon" <mlsemon35@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: Null pointer dereference while at ACL limit on v5 XFS
Date: Tue, 24 Jun 2014 11:31:58 -0500	[thread overview]
Message-ID: <53A9A7FE.7060008@sgi.com> (raw)
In-Reply-To: <53A8F1AC.90109@gmail.com>

On 06/23/14 22:34, Michael L. Semon wrote:
> On 06/23/2014 06:13 PM, Mark Tinguely wrote:
>> On 06/23/14 17:08, Mark Tinguely wrote:
>>> On 06/23/14 16:48, Michael L. Semon wrote:
>>>> At the ACL limit of v5-superblock XFS--with a directory filled with
>>>> both default
>>>> and access ACL entries--I'm getting a null pointer dereference on x86
>>>> after
>>>> creating the directory successfully.
>>>>
>>>> Disclaimer: There's some current issues on 32-bit x86 that, for
>>>> instance, can
>>>> make badblocks see phantom bad blocks on a read test. My apologies in
>>>> advance
>>>> if this turns out to be a false alarm bug report.
>>>>
>>>> My first encounter with this issue involved fsstress. Here's part of a
>>>> `crash`
>>>> session from the fsstress run.
>>>>
>>>> root@oldsvrhw:/mnt/crashdump/xfs-fsstress-max-acl-2# crash vmlinux
>>>> System.map vmcore
>>>> crash 7.0.4
>> ...
>>>> Thanks!
>>>>
>>>> Michael
>>>>
>>>
>>> Michael, do you have the vmcore dump for this or was this just from the
>>> messages.
>>>
>>> Thanks.
>>>
>>> --Mark.
>>
>> ummm, duh me. you were running crash ...
>>
>> Can I look at the core?
>>
>> --Mark.
>
> Sure!  I've uploaded two sets of core dumps (vmcore, vmlinux, System.map,
> config, sample crash session) and put them here for a short time:
>

Both are buffer - like your trace shows that is was updating on the AIL 
and it really is but in both crashes the log item ail next link has been 
NULLed:

xfs-fsstress-max-acl-2:
crash> xfs_buf_log_item dde37370
struct xfs_buf_log_item {
   bli_item = {
     li_ail = {
       next = 0x0,
       prev = 0xdc01d6e8

xfs-fsstress-max-acl-3:
crash> xfs_buf_log_item db5bf0b0
struct xfs_buf_log_item {
   bli_item = {
     li_ail = {
       next = 0x0,
       prev = 0xdb5bf4d0
     },

not good.

--Mark.

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

  parent reply	other threads:[~2014-06-24 16:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-23 21:48 Null pointer dereference while at ACL limit on v5 XFS Michael L. Semon
2014-06-23 22:08 ` Mark Tinguely
2014-06-23 22:13   ` Mark Tinguely
2014-06-24  3:34     ` Michael L. Semon
2014-06-24  4:04       ` Dave Chinner
2014-06-24 13:31         ` Michael L. Semon
2014-07-01 22:27         ` Michael L. Semon
2014-07-03 11:56           ` Jeff Liu
2014-06-24 16:31       ` Mark Tinguely [this message]
2014-06-24 18:25         ` Mark Tinguely
2014-06-24  2:18 ` Dave Chinner

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=53A9A7FE.7060008@sgi.com \
    --to=tinguely@sgi.com \
    --cc=mlsemon35@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.