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
| ||
|
Message-ID: <CAL+tcoD0hXzymHyGJm2Rfk1hnVieFiAP5SY_WqdwE++APkskFA@mail.gmail.com> Date: Wed, 31 May 2023 13:31:55 +0800 From: Jason Xing <kerneljasonxing@...il.com> To: Eric Dumazet <edumazet@...gle.com> Cc: fuyuanli <fuyuanli@...iglobal.com>, "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Neal Cardwell <ncardwell@...gle.com>, ycheng <ycheng@...gle.com>, toke <toke@...e.dk>, netdev@...r.kernel.org, Weiping Zhang <zhangweiping@...iglobal.com>, Tio Zhang <tiozhang@...iglobal.com> Subject: Re: [PATCH net v2] tcp: fix mishandling when the sack compression is deferred On Wed, May 31, 2023 at 12:13 PM Eric Dumazet <edumazet@...gle.com> wrote: > > On Wed, May 31, 2023 at 5:50 AM Jason Xing <kerneljasonxing@...il.com> wrote: > > > > On Tue, May 30, 2023 at 10:51 PM Eric Dumazet <edumazet@...gle.com> wrote: > > > > > > On Tue, May 30, 2023 at 4:32 PM Jason Xing <kerneljasonxing@...il.com> wrote: > > > > > > > > I'm confused. You said in the previous email: > > > > "As a bonus, no need to send one patch for net, and another in net-next, > > > > trying to 'fix' issues that should have been fixed cleanly in a single patch." > > > > > > > > So we added "introducing ICSK_ACK_TIMER flag for sack compression" to > > > > fix them on top of the patch you suggested. > > > > > > > > I can remove the Suggested-by label. For now, I do care about your > > > > opinion on the current patch. > > > > > > > > Well...should I give up introducing that flag and then leave that > > > > 'issue' behind? :S > > > > > > Please let the fix go alone. > > > > > > Then I will look at your patch, but honestly I fail to see the _reason_ for it. > > > > > > In case you missed it, tcp_event_ack_sent() calls > > > inet_csk_clear_xmit_timer(sk, ICSK_TIME_DACK); > > > > Hello Eric, > > > > Sorry, I didn't explain that 'issue' well last night. Let me try it once more: > > > > In the tcp_event_ack_sent(), since we're going to transmit data with > > ack header, we should cancel those timers which could start before to > > avoid sending useless/redundant acks. Right? > > > > But what if the timer, say, icsk_delack_timer, was triggered before > > and had to postpone it in the release cb phrase because currently > > socket (in the tcp sending process) has owned its @owned > > field(sk->sk_lock.owned == 1). > > > > We could avoid sending extra useless ack by removing the > > ICSK_ACK_TIMER flag to stop sending an ack in > > tcp_delack_timer_handler(). > > > > In the current logic, see in the tcp_event_ack_sent(): > > 1) hrtimer_try_to_cancel(&tp->compressed_ack_timer) > > 2) sk_stop_timer(sk, &icsk->icsk_delack_timer) > > Those two statements can prevent the timers from sending a useless ack > > but cannot prevent sending a useless ack in the deferred process. > > > > Does it make any sense? Like I said, it's not a bug, but more like an > > improvement. > > Your patch adds a bug. An skb allocation can fail, and ACK would not be sent. > > Timer handlers are not canceled in TCP stack. > We do not call sk_stop_timer() because include/net/inet_connection_sock.h says > > /* Cancel timers, when they are not required. */ > #undef INET_CSK_CLEAR_TIMERS > > So claiming the following is nonsense: > > <quote> > 2) sk_stop_timer(sk, &icsk->icsk_delack_timer) > Those two statements can prevent ... > </quote> > [...] > We do not send extra ACK, because icsk->icsk_ack.pending (or icsk->icsk_pending) > is cleared in inet_csk_clear_xmit_timer() You're right about this. Thanks for your kind explanation. I missed this key point again :( It is a really happy ending cause I only need to focus on the v3 patch. Please help us review that patch if you're available (no rush) :) Thanks, Jason > > This clearing is happening already at strategic places. > > When tcp_delack_timer_handler() is finally run (when owning socket lock), > it will return early if icsk->icsk_ack.pending was already cleared. > > hrtimer_try_to_cancel(&tp->compressed_ack_timer) has to be called because > we rely on the hrtimer status (hrtimer_is_queued()) in __tcp_ack_snd_check()
Powered by blists - more mailing lists