On Mon, Oct 10, 2016 at 7:03 AM, Christoph Lameter <cl@xxxxxxxxx> wrote:
>
> Hmm.. Then get_freepointer_safe may not be ok. Should not trigger any
> faults.
So the reason seems to be that SLUB doesn't actually react well to
double-freeing bugs.
I'm not sure how to fix that. I think the optimistic load that SLUB
does is actually important, since it is what allows the whole
lock-free double_cmpxchg() approach.
But the fact that it reacts _so_ badly to double-freeing issues when
the freelist has become corrupted due to an object being free'd and
then modified is clearly very fragile and not great.
Doing a google search for "kmalloc", "oops" and "cmpxchg16b" does show
that it happens: you can tell by how the trapping instruction is a
load just before the cmpxchg16b instruction in the oops disassembly.
Maybe we should just make "get_freepointer()" always handle traps.
Right now it does that "probe_kernel_read()" conditionally, and it's a
fairly costly operation, but we *could* make it cheaper. It's really
just a single instruction with an exception entry (kind of like
load_unaligned_zeropad() that we wrote for the dcache case).
I dunno.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
