netdev - Re: [PATCH net-next-2.6] pcnet32: Remove pointless memory barriers

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, 29 Apr 2009 10:10:57 -0700
From:	Don Fry <pcnet32@...izon.net>
To:	John Dykstra <john.dykstra1@...il.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	jeff@...zik.org
Subject: Re: [PATCH net-next-2.6] pcnet32: Remove pointless memory barriers

My original NAPI implementation did not have the mmiowb() but it was
added because of some comments from Francois Romeiu (2006-06-29/30).  I
do not know if they are required or not.  My feeling was/is that they
are not as the writes are flushed with the unlocking primitives.
However that is not based on knowledge, just "feeling".

How would this be tested on all architectures to find out?

Don

-----Original Message-----
From: John Dykstra <john.dykstra1@...il.com>
To: David Miller <davem@...emloft.net>
Cc: netdev@...r.kernel.org, pcnet32@...izon.net, jeff@...zik.org
Subject: Re: [PATCH net-next-2.6] pcnet32: Remove pointless memory
barriers
Date: Wed, 29 Apr 2009 08:48:17 -0500

On Tue, 2009-04-28 at 22:16 -0700, David Miller wrote:
> Any driver where these things are present usually has them
> there for a reason.  Usually it's because the SGI guys really
> did run into real problems without them on their huge
> machines which can reorder PCI MMIO wrt. real memory operations.

Is that relevant when the driver doesn't do any MMIO operations?  All
pcnet32 register accesses are via PCI I/O space, as implied by the
commit description.

Descriptors and buffers are, of course, in consistent physical memory.
This patch doesn't touch the barriers associated with those structures.

> I don't feel good applying this at all, given that I see no
> evidence that there has been any investigation into how these
> barriers got there in the first place.

Before sending out this patch, I determined that the MMIO barriers were
added as part of NAPI support.  I CCed one of the authors of that patch,
so he could NAK if appropriate.  I've added the other author on this
reply.

I knew there'd be questions about whether removing these two barriers
was safe.  Submitting the patch seemed the best way to understand why
they were needed, if they are.

  --  John

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

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