[linux-next][Oops] memory hot-unplug results fault instruction address at /include/linux/list.h:104

Kees Cook keescook at chromium.org
Thu Sep 21 05:54:37 AEST 2017


On Wed, Sep 20, 2017 at 12:40 AM, Abdul Haleem
<abdhalee at linux.vnet.ibm.com> wrote:
> On Tue, 2017-09-12 at 12:11 +0530, abdul wrote:
>> Hi,
>>
>> Memory hot-unplug on PowerVM LPAR running next-20170911 results in
>> Faulting instruction address: 0xc0000000002b56c4
>>
>> which maps to the below code path:
>>
>> 0xc0000000002b56c4 is in __rmqueue (./include/linux/list.h:104).
>> 99     * This is only for internal list manipulation where we know
>> 100    * the prev/next entries already!
>> 101    */
>> 102   static inline void __list_del(struct list_head * prev, struct
>> list_head * next)
>> 103   {
>> 104           next->prev = prev;
>> 105           WRITE_ONCE(prev->next, next);
>> 106   }
>> 107
>> 108   /**
>>
>
> I see another kernel Oops when running transparent hugepages
> de-fragmentation test.
>
> And the faulty instruction address again pointing to same code line
> 0xc00000000026f9f4 is in compaction_alloc (./include/linux/list.h:104)
>
> steps to recreate:
> -----------------
> 1. Enable transparent hugepages ("always")
> 2. Turn off the defrag $ echo 0 > khugepaged/defrag
> 3. Write random to memory path
> 4. Set huge pages numbers
> 5. Turn on defrag $ echo 1 > khugepaged/defrag
>
>
> new trace:
> ----------
> Unable to handle kernel paging request for data at address
> 0x5deadbeef0000108

This looks like use-after-list-removal, that value appears to be LIST_POISON1.

Try enabling CONFIG_DEBUG_LIST to see if you get better details?

-Kees

-- 
Kees Cook
Pixel Security


More information about the Linuxppc-dev mailing list