netdev - Re: Pull request: sfc-next 2013-08-25

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: <20130827.123718.732194018797657395.davem@davemloft.net>
Date:	Tue, 27 Aug 2013 12:37:18 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	bhutchings@...arflare.com
Cc:	netdev@...r.kernel.org, linux-net-drivers@...arflare.com
Subject: Re: Pull request: sfc-next 2013-08-25

From: Ben Hutchings <bhutchings@...arflare.com>
Date: Tue, 27 Aug 2013 17:26:08 +0100

> On Tue, 2013-08-27 at 12:18 -0400, David Miller wrote:
>> From: Ben Hutchings <bhutchings@...arflare.com>
>> Date: Sun, 25 Aug 2013 23:56:03 +0100
>> 
>> > The following changes since commit f073dde03b3e8d11050d82f52caaf75fd924e069:
>> > 
>> >   sfc: Make efx_mcdi_init() call efx_mcdi_handle_assertion() (2013-08-21 19:43:09 +0100)
>> > 
>> > are available in the git repository at:
>> > 
>> >   git://git.kernel.org/pub/scm/linux/kernel/git/bwh/sfc-next.git for-davem
>> > 
>> > for you to fetch changes up to f76fe120d81c96fa2a17ae41f0647c963dbb43cd:
>> > 
>> >   sfc: Update and improve kernel-doc for efx_mcdi_state & efx_mcdi_iface (2013-08-21 20:20:41 +0100)
>> > 
>> > 1. Refactoring and cleanup in preparation for new hardware support.
>> > 2. Some bug fixes for firmware completion handling.  (They're not known
>> > to cause real problems, otherwise I'd be submitting these for net and
>> > stable.)
>> > 3. Update to the firmware protocol (MCDI) definitions.
>> 
>> Pulled, but I want to point out an existing issue which is that using
>> an atomic_t for mcdi->state is bogus.  You're only using atomic_set()
>> and atomic_read() on the value, and that provides no "atomicity" per-se.
> 
> Thanks.  I don't know what you looked for, but there are actually two
> atomic_cmpxchg() calls in mcdi.c.

I still think atomic_t is not appropriate, you can use plain xchg() as we
do all over the IPV4 stack, such as in the TCP metrics cache and the
routing code.

Really, if I don't see an atomic_*_and_test() or similar kind of
operation being used, I really don't want to see an atomic_t type in
use.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html