Null pointer dereference while at ACL limit on v5 XFS
Mark Tinguely
tinguely at sgi.com
Tue Jun 24 13:25:33 CDT 2014
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 at 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.
More information about the xfs
mailing list