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: <alpine.LFD.2.21.1910030146380.29399@eddie.linux-mips.org>
Date:   Thu, 3 Oct 2019 02:29:47 +0100 (BST)
From:   "Maciej W. Rozycki" <macro@...ux-mips.org>
To:     Thomas Bogendoerfer <tsbogend@...ha.franken.de>
cc:     Helge Deller <deller@....de>,
        John David Anglin <dave.anglin@...l.net>,
        Arlie Davis <arlied@...gle.com>, Andrew Lunn <andrew@...n.ch>,
        netdev@...r.kernel.org, linux-parisc@...r.kernel.org,
        linux-alpha@...r.kernel.org
Subject: Re: Bug report (with fix) for DEC Tulip driver (de2104x.c)

On Wed, 18 Sep 2019, Thomas Bogendoerfer wrote:

> > >> Likewise, I'm at a loss for testing with real hardware. It's hard to
> > >> find such things, now.
> > > How does de2104x compare to ds2142/43?  I have a c3750 with ds2142/43 tulip.  Helge
> > > or some others might have a machine with a de2104x.
> > 
> > The machines we could test are
> > * a C240 with a DS21140 tulip chip (Sven has one),
> > * a C3000 or similiar with DS21142 and/or DS21143 (me).
> > 
> > If the patch does not show any regressions, I'd suggest to
> > apply it upstream.
> 
> 2114x chips use a different driver, so it won't help here.

 Asking at `linux-alpha' (cc-ed) might help; these chips used to be 
ubiquitous with older Alpha systems, so someone subscribed there might be 
able to step in and help right away.  Also testing with an Alpha always 
has the advantage of exposing any weak ordering issues.

 Myself I have an AS 300 (or AS 250 really as I suspect a mismatch between 
the enclosure and the MB; the two systems are almost identical anyway) and 
it does have a real 21040 chip on its riser I/O module.  However I have 
never got to setting up Linux on that machine and it may take me a bit to 
get it running suitably to get any verification done I'm afraid.

 NB for the original 21040 part "DECchip 21040 Ethernet LAN Controller for 
PCI Hardware Reference Manual", Order Number: EC-N0752-72, available here:
<ftp://ftp.netbsd.org/pub/NetBSD/misc/dec-docs/ec-n0752-72.ps.gz> is 
probably more relevant, although in the area concerned here it seems the 
same.

 Finally I don't expect any race condition in possibly examining control 
bits in the transmit interrupt handler as this is what the descriptor 
ownership bit guards against -- only when a descriptor is owned by the 
host accesses from the CPU side are allowed, and then it is safe to fiddle 
with any field.

  Maciej

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ