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

Message-ID: <1377622356.13272.24.camel@bwh-desktop.uk.level5networks.com>
Date:	Tue, 27 Aug 2013 17:52:36 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	David Miller <davem@...emloft.net>
CC:	<netdev@...r.kernel.org>, <linux-net-drivers@...arflare.com>
Subject: Re: Pull request: sfc-next 2013-08-25

On Tue, 2013-08-27 at 12:37 -0400, David Miller wrote:
> 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.

We definitely need some variant on cmpxchg() rather than xchg(), but
you're right that we don't need to use atomic_t for that.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
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