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]
Date:   Wed, 14 Feb 2018 21:36:33 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     "Michael, Alice" <alice.michael@...el.com>,
        Guenter Roeck <linux@...ck-us.net>,
        James Hogan <jhogan@...nel.org>
CC:     Ralf Baechle <ralf@...ux-mips.org>,
        "linux-mips@...ux-mips.org" <linux-mips@...ux-mips.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
        Shannon Nelson <shannon.nelson@...cle.com>
Subject: RE: [RFC PATCH] MIPS: Provide cmpxchg64 for 32-bit builds

> -----Original Message-----
> From: Michael, Alice
> Sent: Wednesday, February 14, 2018 1:03 PM
> To: Guenter Roeck <linux@...ck-us.net>; James Hogan <jhogan@...nel.org>;
> Keller, Jacob E <jacob.e.keller@...el.com>
> Cc: Ralf Baechle <ralf@...ux-mips.org>; linux-mips@...ux-mips.org; linux-
> kernel@...r.kernel.org; Kirsher, Jeffrey T <jeffrey.t.kirsher@...el.com>; Shannon
> Nelson <shannon.nelson@...cle.com>
> Subject: RE: [RFC PATCH] MIPS: Provide cmpxchg64 for 32-bit builds
> 
> As has previously been said, we're going to be removing the need for cmpxchg64.
> But it takes a little bit of time and work to do so.  I'm adding the dev that is taking
> care of the work back onto this email thread as well so he can see any concerns with
> it.
> 
> Alice
> 
> -----Original Message-----
> From: Guenter Roeck [mailto:groeck7@...il.com] On Behalf Of Guenter Roeck
> Sent: Monday, February 12, 2018 3:57 PM
> To: James Hogan <jhogan@...nel.org>
> Cc: Ralf Baechle <ralf@...ux-mips.org>; linux-mips@...ux-mips.org; linux-
> kernel@...r.kernel.org; Michael, Alice <alice.michael@...el.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@...el.com>; Shannon Nelson <shannon.nelson@...cle.com>
> Subject: Re: [RFC PATCH] MIPS: Provide cmpxchg64 for 32-bit builds
> 
> On Mon, Feb 12, 2018 at 11:42:02PM +0000, James Hogan wrote:
> > Hi Guenter,
> >
> > On Mon, Feb 12, 2018 at 02:37:01PM -0800, Guenter Roeck wrote:
> > > Since commit 60f481b970386 ("i40e: change flags to use 64 bits"),
> > > the i40e driver uses cmpxchg64(). This causes mips:allmodconfig
> > > builds to fail with
> > >
> > > drivers/net/ethernet/intel/i40e/i40e_ethtool.c:
> > > 	In function 'i40e_set_priv_flags':
> > > drivers/net/ethernet/intel/i40e/i40e_ethtool.c:4443:2: error:
> > > 	implicit declaration of function 'cmpxchg64'
> > >
> > > Implement a poor-mans-version of cmpxchg64() to fix the problem for
> > > 32-bit mips builds. The code is derived from sparc32, but only uses
> > > a single spinlock.
> >
> > Will this be implemened for all 32-bit architectures which are
> > currently missing cmpxchg64()?
> >
> No idea.
> 
> > If so, any particular reason not to do it in generic code?
> >
> Again, no idea. When the problem was previously seen on sparc32, it was
> implemented there.
> 
> > If not then I think that driver should be fixed to either depend on
> > some appropriate Kconfig symbol or to not use this API since it
> > clearly isn't portable at the moment.
> >
> Good point.
> 
> > See also Shannon's comment about that specific driver:
> > https://lkml.kernel.org/r/e7c934d7-e5f4-ee1b-0647-c31a98d9e944@oracle.
> > com
> >
> 
> Well, this was an RFC only. Feel free to ignore it.
> 
> FWIW, this is the second time that the call was introduced in the i40 driver.
> After the first time the code was rewritten to avoid the problem, but now it came
> back. Someone must really like it ;-). For my part, I may just blacklist the offending
> driver in my builds; that is less than perfect, but much easier than having to deal with
> the same problem over and over again. Guess I'll wait for a while and do just that if
> the problem isn't fixed in a later RC.
> 
> Guenter

Hi,

I've been working on re-writing some of the code so that the need for a compare-and-exchange in the i40e_set_priv_flags() is not necessary. This mostly involved moving many flags out into an atomic bitops field instead, it should be posted to IWL soon.

Thanks,
Jake

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ