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
| ||
|
Date: Fri, 18 Oct 2013 16:14:16 +0800 From: annie li <annie.li@...cle.com> To: Jan Beulich <JBeulich@...e.com> CC: wei.liu2@...rix.com, ian.campbell@...rix.com, netdev@...r.kernel.org, david.vrabel@...rix.com, xen-devel@...ts.xenproject.org, jianhai luan <jianhai.luan@...cle.com> Subject: Re: [Xen-devel] [PATCH net] xen-netback: add the scenario which now beyond the range time_after_eq(). On 2013-10-18 15:43, Jan Beulich wrote: >>>> On 17.10.13 at 18:38, annie li <annie.li@...cle.com> wrote: >> On 2013-10-17 17:26, Jan Beulich wrote: >>>> Yes, the issue only can be reproduced in 32-bit Dom0 (Beyond >>>> MAX_ULONG/2 in 64-bit will need long long time) >>>> >>>> I think the gap should be think all environment even now extending 480+. >>>> if now fall in the gap, one timer will be pending and replenish will be >>>> in time. Please run the attachment test program. >>> Not sure what this is supposed to tell me. I recognize that there >>> are overflow conditions not handled properly, but (a) I have a >>> hard time thinking of a sensible guest that sits idle for over 240 >>> days (host uptime usually isn't even coming close to that due to >>> maintenance requirements) and (b) if there is such a sensible >>> guest, then I can't see why dealing with one being idle for over >>> 480 days should be required too. >>> >> If the guest contains multiple NICs, that situation probably happens >> when one NIC keeps idle and others work under load. BTW, how do you get >> the 240? > 2^31 / 100 / 60 / 60 / 24 > > Obviously with HZ=1000 the span would be smaller by a factor > of 10, which would make it even more clear that doubling the > span doesn't really help. My understanding is this patch does not simply double the span, it is just stricter than the original one. Please check my previous comments, I paste it here. The main change of this patch is copied here too, if (!time_in_range_open(now, vif->credit_timeout.expires, next_credit)) comments: ----------expires-------now-------credit---------- is the only case where we need to add a timer. Other cases like following would match the if condition above, then no timer is added. ----------expires----------credit------now------ -----now-----expires----------credit---------- Or we can consider the extreme condition, when the rate control does not exist, "credit_usec" is zero, and "next_credit" is equal to "expires". The above if condition would cover all conditions, and no rate control really happens. If credit_usec is not zero, the "if condition" would cover the range outside of that from expires to next_credit. Even if "now" is wrapped again into the range from "expires" to "next_credit", the "next_credit" that is set in __mod_timer is reasonable value(this can be gotten from credit_usec), and the timer would be hit soon. Thanks Annie -- 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
Powered by blists - more mailing lists