netdev - Re: [PATCH net-next] af_packet: convert pending frame counter to atomic

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] [day] [month] [year] [list]

Message-Id: <20190702.140358.359909684176639832.davem@davemloft.net>
Date:   Tue, 02 Jul 2019 14:03:58 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     nhorman@...driver.com
Cc:     netdev@...r.kernel.org, willemb@...gle.com
Subject: Re: [PATCH net-next] af_packet: convert pending frame counter to
 atomic_t

From: Neil Horman <nhorman@...driver.com>
Date: Fri, 28 Jun 2019 10:52:06 -0400

> Given that the socket transmit path is an exclusive path (locked via the
> pg_vec_lock mutex), we do not have the ability to increment this counter
> on multiple cpus in parallel.  This implementation also seems to have
> the potential to be broken, in that, should an skb be freed on a cpu
> other than the one that it was initially transmitted on, we may
> decrement a counter that was not initially incremented, leading to
> underflow.

This isn't a problem.  There is only one valid "read" operation and that
is the "summation" of all of the per-cpu counters.

All of the overflows and underflows cancel out in the situation you
describe, so all is fine.

I'm hesitant to get behind any fiddling in this area.

Thanks Neil.