David Miller <davem@xxxxxxxxxxxxx> writes: > From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman) > Date: Tue, 18 Mar 2014 10:47:36 -0700 > >> Most of the destructors today are fine (which doubly makes the warning >> confusing). > > Not true by my estimation. We absolutely do not want socket state being > modified from hardware interrupts, and that's the most common destructor, > releasing socket memory. I definitely was not and am not suggesting that we change this. I was just pointing out the difference between hard irq and soft irq state for code is very slight, and I do not see anything that stands out as hard irq unsafe. Here is what I see when I read the destructors: sock_rmem_free is an antomic operation which is safe in all contexts. sock_wfree appears safe in hard irq contect assuming the comment about of sk_free being safe in hard irq context is correct. sock_rfree except for changing sk_foward_alloc without any kind of apparent serialization in sk_mem_uncharge appears safe. sock_edemux This just calls sock_put and inet_twsk_put sock_put just calls sk_put (which is documented as hard irq safe) Nothing in inet_twsk_put appears unsafe in hard irq context. There are other destructors out there that definitely do things such as call local_bh_disable that are unambiguously unsafe in hard irq context but I had to look hard to find them. Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html