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 for Android: free password hash cracker in your pocket

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

Message-ID: <0daf062cb59776a19b142eeb48b46db0878cc353.camel@redhat.com>
Date:   Thu, 28 Jul 2022 22:04:13 +0200
From:   Paolo Abeni <pabeni@...hat.com>
To:     Jakub Kicinski <kuba@...nel.org>
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, 2022-07-28 at 08:42 -0700, Jakub Kicinski wrote:
> 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.

I see it now, thanks for the pointers.
> 
> 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?

Yes.

For the records, I feared a change of behavior that could break
existing user-space applications expecting/dependending on blocking
recvmsg() completing in ~timeo (yep, modulo timer precision - which is
reasonably good for "short" timers), but it looks like there is no
actual overall behaviour change.

So I'm fine with this patch.

Thanks!

Paolo