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: <20140904.223648.559995846094457545.davem@davemloft.net>
Date:	Thu, 04 Sep 2014 22:36:48 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	david.stevens@...cle.com
Cc:	sowmini.varadhan@...cle.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2 2/2] Re-check for a VIO_DESC_READY data
 descriptor after short udelay()

From: David L Stevens <david.stevens@...cle.com>
Date: Tue, 02 Sep 2014 12:27:19 -0400

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

The memory barrier exists in order to make sure the cookies et al. are
globally visible before the VIO_DESC_READY.  We don't want stores to
be reordered such that the VIO_DESC_READY is seen too early.

I'm having a hard time imagining that putting the wmb() afterwards
would help, except by adding a new delay in a different place.

I say that because the TX trigger is going to make a hypervisor call,
and I bet that hypervisor trap syncs the store buffer of invoking cpu
thread.

Thinking further, another issue to consider is that the wmb() might no
be necessary considering all of the above, because the remote entity
should not look at this descriptor until the tx trigger occurs.

Anyways, if the hypervisor trap to signal the tx trigger does not
flush the local cpu thread's store buffer, then yes moving the memory
barrier might make sense.
--
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