Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH] skbuff: fix a data race in skb_queue_len()
To:     Qian Cai <cai@lca.pw>, Eric Dumazet <eric.dumazet@gmail.com>
Cc:     davem@davemloft.net, kuba@kernel.org, elver@google.com,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org
References: <648d6673-bbd8-6634-0174-f9b77194ecfd@gmail.com>
 <D743FB35-3736-45E9-9DE1-8E81929D67C1@lca.pw>
From:   Eric Dumazet <eric.dumazet@gmail.com>
Message-ID: <126aa227-2383-efdd-742c-6ccf85ae7ba4@gmail.com>
Date:   Mon, 3 Feb 2020 12:28:52 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <D743FB35-3736-45E9-9DE1-8E81929D67C1@lca.pw>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 2/3/20 12:19 PM, Qian Cai wrote:
> 
> 
>> On Feb 3, 2020, at 2:42 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>
>> We do not want to add READ_ONCE() for all uses of skb_queue_len()
>>
>> This could hide some real bugs, and could generate slightly less
>> efficient code in the cases we have the lock held.
> 
> Good point. I should have thought about that. How about introducing 2 new helpers.
> 
> skb_queue_len_once()
> unix_recvq_full_once()
> 
> which will have a READ_ONCE() there, and then unix_dgram_sendmsg() could use that instead?
> 

We added recently skb_queue_empty_lockless() helper, to use in these contexts.

The fact that we use READ_ONCE() is more of an implementation detail I think.

Also, addressing load-stearing issues without making sure the write side
is using WRITE_ONCE() might be not enough (even if KCSAN warnings disappear)