netdev - Re: [PATCH net v2] tcp: fix mishandling when the sack compression is deferred

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL+tcoDYZhDkH+oK+7KrmdWA03aY356UPBOGZOnbUiYKZ5q9YQ@mail.gmail.com>
Date: Wed, 31 May 2023 11:49: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 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.

Thanks,
Jason