On Wed, Sep 20, 2017 at 12:40 AM, Abdul Haleem
<abdhalee@xxxxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
