linux-kernel - Re: [PATCH net] rds: Fix incorrect statistics counting

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <715EA84D-6ACA-45DE-9EA2-6122E11545E8@oracle.com>
Date:   Wed, 6 Sep 2017 18:12:58 +0200
From:   Håkon Bugge <haakon.bugge@...cle.com>
To:     Santosh Shilimkar <santosh.shilimkar@...cle.com>
Cc:     "David S . Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        OFED mailing list <linux-rdma@...r.kernel.org>,
        rds-devel@....oracle.com, linux-kernel@...r.kernel.org,
        Knut Omang <knut.omang@...cle.com>
Subject: Re: [PATCH net] rds: Fix incorrect statistics counting


> On 6 Sep 2017, at 17:58, Santosh Shilimkar <santosh.shilimkar@...cle.com> wrote:
> 
> On 9/6/2017 8:29 AM, Håkon Bugge wrote:
>> In rds_send_xmit() there is logic to batch the sends. However, if
>> another thread has acquired the lock, it is considered a race and we
>> yield. The code incrementing the s_send_lock_queue_raced statistics
>> counter did not count this event correctly.
>> This commit removes a small race in determining the race and
>> increments the statistics counter correctly.
>> Signed-off-by: Håkon Bugge <haakon.bugge@...cle.com>
>> Reviewed-by: Knut Omang <knut.omang@...cle.com>
>> ---
>>  net/rds/send.c | 16 +++++++++++++---
>>  1 file changed, 13 insertions(+), 3 deletions(-)
> Those counters are not really to give that accurate so
> am not very keen to add additional cycles in send paths
> and add additional code. Have you seen any real issue
> or this is just a observation. s_send_lock_queue_raced
> counter is never used to check for smaller increments
> and hence the question.

Hi Santosh,


Yes, I agree with accuracy of s_send_lock_queue_raced. But the main point is that the existing code counts some partial share of when it is _not_ raced.

So, in the critical path, my patch adds one test_bit(), which hits the local CPU cache, if not raced. If raced, some other thread is in control, so I would not think the added cycles would make any big difference.

I can send a v2 where the race tightening is removed if you like.


Thxs, Håkon