search for: tx_credit_exceeded

time_after_eq() only works if the delta is < MAX_ULONG/2. For a 32bit Dom0, if netfront sends packets 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 packets (e.g., if prior to the long gap, all credit was exhausted). Use jiffies_64 variant to mitigate this problem for 32bit Dom0. Suggested-by: Ja...

...ruct xenvif *vif) +{ + vif->remaining_packets = vif->credit_packets; +} + static void tx_credit_callback(unsigned long data) { struct xenvif *vif = (struct xenvif *)data; tx_add_credit(vif); + tx_add_packets(vif); xen_netbk_check_rx_xenvif(vif); } @@ -1419,6 +1425,38 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size) return false; } +static bool tx_packets_exceeded(struct xenvif *vif) +{ + unsigned long now = jiffies; + unsigned long next_credit = + vif->credit_timeout.expires + + msecs_to_jiffies(vif->credit_usec / 1000); + + /* Timer could already be pending in...

...t;> been working on the issue from that time. I find that DomU''s network > >> interface, which send lesser package, will hung if Dom0 running > >> 32bit and DomU''s up-time is very long. I think that one jiffies > >> overflow bug exist in the function tx_credit_exceeded(). > >> I know the inline function time_after_eq(a,b) will process jiffies > >> overflow, but the function have one limit a should little that (b + > >> MAX_SIGNAL_LONG). If a large than the value, time_after_eq will > >> return false. The MAX_SINGNAL_LONG sho...