[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 18:31, David Vrabel wrote:
On 17/10/13 11:19, jianhai luan wrote:
On 2013-10-17 17:15, David Vrabel wrote:
On 17/10/13 10:02, jianhai luan 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.
Because
the fact now must be not before than expire, time_before(now, expire)
== true
will 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.
If use time_after_eq64(), expire ,next_credit and other member will must
be u64.
Yes, you'll need to store next_credit as a u64 in vif instead of
calculating it in tx_credit_exceeded from expires (which is only an
unsigned long).
I know that. Even we use u64, time_after_eq() will also do wrong judge
in theory (not in reality because need long long time).
If jiffies_64 has millisecond resolution that would be more than
500,000,000 years.
Yes, I agree the fact.
I think the two better fixed way is below:
- By time_before() to judge if now beyond MAX_ULONG/2
This is broken, so no.
Where is broken? would you like to help me point it out.
David
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
