netdev - Re: [PATCH net-next 2/4] tls: rx: don't consider sock

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: <20220728084244.7c654a6e@kernel.org>
Date:   Thu, 28 Jul 2022 08:42:44 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Paolo Abeni <pabeni@...hat.com>
Cc:     davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
        borisp@...dia.com, john.fastabend@...il.com, maximmi@...dia.com,
        tariqt@...dia.com, vfedorenko@...ek.ru
Subject: Re: [PATCH net-next 2/4] tls: rx: don't consider sock_rcvtimeo()
 cumulative

On Thu, 28 Jul 2022 15:50:03 +0200 Paolo Abeni wrote:
> I have a possibly dumb question: this patch seems to introduce a change
> of behavior (timeo re-arming after every progress vs a comulative one),
> while re-reading the thread linked above it I (mis?)understand that the
> timeo re-arming is the current behavior?
> 
> Could you please clarify/help me understand this better?

There're two places we use timeo - waiting for the exclusive reader 
lock and waiting for data. Currently (net-next as of now) we behave
cumulatively in the former and re-arm in the latter.

That's to say if we have a timeo of 50ms, and spend 10ms on the lock,
the wait for each new data record must be shorter than 40ms.

Does that make more sense?