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 13:25:33 -0500 [thread overview]
Message-ID: <53A9C29D.8080006@sgi.com> (raw)
In-Reply-To: <53A9A7FE.7060008@sgi.com>
On 06/24/14 11:31, Mark Tinguely wrote:
> 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.
PS. I don't know if this will help but I followed the xfs_log_items
backwards to xfs_ail and that is okay. The prev pointer on the ail is
pointing to a corrupted chain:
crash> xfs_ail ddc81d80
struct xfs_ail {
xa_mount = 0xddd6b800,
xa_task = 0xddec5580,
xa_ail = {
next = 0xdb04b210,
prev = 0xddca60d0
},
..
crash> xfs_log_item ddca60d0
struct xfs_log_item {
li_ail = {
next = 0xddc81d88, <- correct, the xfs_ail
prev = 0xdb5bf580
},
...
crash> xfs_log_item db5bf580
struct xfs_log_item {
li_ail = {
next = 0xdbab6000, <- wrong, points to a small xfs_item loop.
prev = 0xde92fcf0
},
...
small loop:
crash> xfs_log_item de92fcf0
struct xfs_log_item {
li_ail = {
next = 0xdb5bf580,
prev = 0xdb04b370
},
crash> xfs_log_item db04b370
struct xfs_log_item {
li_ail = {
next = 0xde92fcf0,
prev = 0xdb04b420
},
crash> xfs_log_item db04b420
struct xfs_log_item {
li_ail = {
next = 0xdb04b370,
prev = 0xdb5bf630
},
crash> xfs_log_item db5bf630
struct xfs_log_item {
li_ail = {
next = 0xdb04b420,
prev = 0xdbab6000 <- !!
},
crash> xfs_log_item dbab6000
struct xfs_log_item {
li_ail = {
next = 0xdb5bf630,
prev = 0xdb5bf580 <- end of small loop.
},
something is happening in an ail insert or delete.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-06-24 18:25 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
2014-06-24 18:25 ` Mark Tinguely [this message]
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=53A9C29D.8080006@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox