Re: [PATCH] mm: fix lazy vmap purging (use-after-free error)
From: Vegard Nossum
Date: Sat Feb 21 2009 - 14:21:33 EST
2009/2/21 Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>:
> Is this behavior recent, or does it apply to earlier 2.6.29-rc kernels
> as well? Does it happen with CONFIG_CLASSIC_RCU as well? (From the
> trace above, I suspect that it might well do so, but if not, that will
> be valuable information as well.)
I don't know -- I haven't tried earlier kernels.
I just compiled a CONFIG_CLASSIC_RCU kernel, and it does happen there too:
[ 1.061138] traversing list {
[ 1.062281] __free_vmap_area(c7803a40)
[ 1.063177] __free_vmap_area(c7803a80)
[ 1.065217] __free_vmap_area(c7803ac0)
[ 1.066255] __free_vmap_area(c7803b00)
[ 1.067156] kfree(c7803a40)
[ 1.068292] __free_vmap_area(c7803b40)
[ 1.069094] __free_vmap_area(c7803b80)
[ 1.071051] kfree(c7803a80)
[ 1.072138] __free_vmap_area(c7803bc0)
[ 1.073101] __free_vmap_area(c7803c00)
[ 1.074065] kfree(c7803ac0)
[ 1.077126] kfree(c7803b00)
[ 1.078124] __free_vmap_area(c7803c40)
[ 1.079079] __free_vmap_area(c7803c80)
...
[ 4.645118] __free_vmap_area(c7853440)
[ 4.646099] __free_vmap_area(c7853480)
[ 4.646507] __free_vmap_area(c78534c0)
[ 4.647049] kfree(c7853340)
[ 4.648058] kfree(c7853380)
[ 4.650090] };
[ 4.652061] kfree(c78533c0)
[ 4.653055] kfree(c7853400)
[ 4.656109] kfree(c7853440)
[ 4.656482] kfree(c7853480)
[ 4.656760] kfree(c78534c0)
[ 5.541885] traversing list {
[ 5.543081] __free_vmap_area(c7853380)
[ 5.544071] __free_vmap_area(c7853340)
...
[ 8.977412] __free_vmap_area(c7822400)
[ 8.977723] __free_vmap_area(c7822440)
[ 8.978045] kfree(c7822200)
[ 8.978569] kfree(c7822240)
[ 8.979054] kfree(c7822280)
[ 8.979389] };
[ 8.981051] kfree(c78222c0)
[ 8.983055] kfree(c7822300)
[ 8.984089] kfree(c7822340)
[ 8.984640] Freeing SMP alternatives: 20k freed
[ 8.985146] ACPI: Core revision 20081204
[ 8.986060] kfree(c7822380)
[ 8.987057] kfree(c78223c0)
[ 8.988052] kfree(c7822400)
[ 8.990045] kfree(c7822440)
[ 9.021526] ..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1
The only difference I can see is that they're clumped together more
closely (4-5 calls of one kind, then 4-5 calls of the other) than with
the Tree RCU.
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/