netdev - Re: [PATCH net-next] sunvnet: improve error handling when a remote crashes

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <54C6A3BA.3060004@oracle.com>
Date:	Mon, 26 Jan 2015 15:29:46 -0500
From:	Sowmini Varadhan <sowmini.varadhan@...cle.com>
To:	David L Stevens <david.stevens@...cle.com>
CC:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] sunvnet: improve error handling when a remote
 crashes

On 01/26/2015 03:19 PM, David L Stevens wrote:

>> I think you'll have a higher reclaim rate for finding !READY if you
>> started at dr->cons instead: dr->cons is the one that was last ACK'ed,
>> and that ack would only have been sent after the peer had marked the
>> descriptor as DONE. (consumer would have had a chance to read more
>> descriptors, by the time the tx-reclaim loop goes around)
   :
> The descriptors indices we look at are unchanged by this patch.

Understood, and what I suggested was an optimization for tx-reclaim.


> 	It should only happen if there is active traffic when a remote
> crashes, but if a remote is giving us garbage in other cases, I think an
> admin would want to check that out.

This allows one DomU to spam up everyone else's log file by crashing
periodically.

In any case, the contents of the message do not in any way suggest
that an admin (of the DomU, who probably has no control over
other DomU's anyway) should go and baby-sit some other DomU that
just crashed.

ymmv.

--Sowmini

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