Subject: Re: [PATCH 6/6] net: Free skbs from irqs when possible.

From: [email-masked] (Eric W. Biederman)
Date: Thu, 27 Mar 2014 16:02:09 -0700

David Miller <[email-masked]> writes:

> From: [email-masked] (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