|
About ::
TODO ::
Blog ::
RSS ::
Old blog ::
Projects ::
GIT ::
Gallery ::
Notes
Wed, 28 Feb 2007
How does run-time skb = alloc_skb(size, flags); kfree(skb); // instead of correct kfree_skb(skb);They are based on the fact, that every allocated object hosts an information about which struct kmem_cache was used
for allocation (and kmalloc() is just a set of special pools),
so we can detect that object must be returned into kmalloc()
pool or not in run-time.First attempt was just to check every kmalloc() pool against
data "embedded" in the freed object.Eric Dumazet suggested another variant - to mark kmalloc() pool
with special bit and only check that bit in the kfree().Although slba bits are generic nd not specially related to some specific pools, so it might be wrong, I decided to implement it too. In theory that would be trivial, but practice shows some absolutely unpredictible results. When second patch is applied, x86_64 APIC code fails to detect a timer, so system can not boot (it does though if 'noapic' parameter is set): ..MP-BIOS bug: 8254 timer not connected to IO-APIC IO-APIC+timer do not workSo I started to dig into x86_64 APIC code (which looks like it was copied as is from i386 one), and eventually increased timer detection timeout, which allows system to boot with kfree() run-time check (btw,
it is additional check, there are plenty of others there, and still system worked),
but I think it smells rather badly.I'm puzzled how that things are related to each other, so I posted detaileddescription of the problem and my patch to netdev@ so other hackers could shed some light on it. /devel/other :: Link / Comments () |