netdev - Re: [PATCH net-next v2 2/2] Re-check for a VIO_DESC_READY data descriptor after short udelay()

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: <20140902163238.GD31516@oracle.com>
Date:	Tue, 2 Sep 2014 12:32:38 -0400
From:	Sowmini Varadhan <sowmini.varadhan@...cle.com>
To:	David L Stevens <david.stevens@...cle.com>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2 2/2] Re-check for a VIO_DESC_READY data
 descriptor after short udelay()

On (09/02/14 12:27), David L Stevens wrote:
> Sowmini,
> 	One of the things I found while looking at the code is that the
> write memory barrier is in the wrong place. I have a patch to fix it, but
> it means the last descriptor will NOT be marked as ready until the cache
> is flushed, which may be delayed.

I see.

I can certainly try that (could you please share that patch offline?)
But this fudge-factored delay (which, fwiw, I too cringed to add)
was actually motivated by some observations on other non-linux OS-es.

> 	That fix may make this one moot. Maybe not, but certainly there is
> an unnecessary delay in notifying the peer because of that bug. The fix is
> simply to move the "wmb()" after, instead of before, setting VIO_DESC_READY.
> I mentioned it in our stand-up last week, which you couldn't attend, because
> I pointed it out for the VDC driver, which also has the same problem.
> 
> 	You may want to retry with that change to see if the delay still
> helps.
--
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