On Thu, Sep 06, 2012 at 03:06:53PM +0200, Borislav Petkov wrote: > On Thu, Sep 06, 2012 at 05:30:48AM -0700, Dan Carpenter wrote: > > > #define list_for_each_entry_reverse(pos, head, member) \ > > > for (pos = list_entry((head)->prev, typeof(*pos), member); \ > > > &pos->member != (head); \ <--- DEREF. > > > > No. That's not what I'm talking about. (And also that's not a > > dereference, it just gives you the address of the struct member). > > > > > pos = list_entry(pos->member.prev, typeof(*pos), member)) > > ^^^^^ > > Here is the dereference. We have already freed "pos" at this point. > > Ok, I see it now, thanks for pointing it out exactly. > > One last thing remains: why didn't I hit this during testing at all? > Timings, or some other out-of-order x86 reason I'm unable to see now? > You wouldn't see it unless something called kmalloc() on another CPU and reused the freed memory. Or if you had CONFIG_DEBUG_SLAB enabled then I believe that will poison freed memory immediately. (Btw, I haven't tested this code either before or after my patch because I don't have any AMD systems). regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
