[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH net] xen-netback: add the scenario which now beyond the range time_after_eq().
On 2013-10-17 17:26, Jan Beulich wrote: On 17.10.13 at 11:02, jianhai luan <jianhai.luan@xxxxxxxxxx> wrote:On 2013-10-17 16:26, Jan Beulich wrote:On 16.10.13 at 19:22, Jason Luan <jianhai.luan@xxxxxxxxxx> wrote:time_after_eq() only works if the delta is < MAX_ULONG/2. If netfront sends at a very low rate, the time between subsequent calls to tx_credit_exceeded() may exceed MAX_ULONG/2 and the test for timer_after_eq() will be incorrect. Credit will not be replenished and the guest may become unable to send (e.g., if prior to the long gap, all credit was exhausted). We should add the scenario which now beyond next_credit+MAX_UNLONG/2.Becausethe fact now must be not before than expire, time_before(now, expire) ==truewill verify the scenario. time_after_eq(now, next_credit) || time_before (now, expire) == !time_in_range_open(now, expire, next_credit)So first of all this must be with a 32-bit netback. And the not coverable gap between activity is well over 240 days long. _If_ this really needs dealing with, then why is extending this from 240+ to 480+ days sufficient? I.e. why don't you simply change to 64-bit jiffy values, and use time_after_eq64()?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. The issue can be reproduced when now beyond MAX_ULONG/2 (if the gust will send lesser package). Jiffies beyond than MAX_UNLONG/2 will need below time: HZ days 100 248.55 (((0xffffffff/2)/HZ)/3600)/24 250 99.42 (((0xffffffff/2)/HZ)/3600)/24 1000 24.86 (((0xffffffff/2)/HZ)/3600)/24 Because we use 250, the issue be found when uptime large than 100 days. Jason If use time_after_eq64(), expire ,next_credit and other member will must be u64.Exactly - that's what I was telling you to do. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |