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: <CANn89i+vOXgKw+2ahJuhtu3-1MDSK4uDdCrK5CQ432QOhVn-PQ@mail.gmail.com>
Date:   Thu, 28 Jul 2022 17:47:36 +0200
From:   Eric Dumazet <edumazet@...gle.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Paolo Abeni <pabeni@...hat.com>,
        David Miller <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Boris Pismenny <borisp@...dia.com>,
        John Fastabend <john.fastabend@...il.com>,
        Maxim Mikityanskiy <maximmi@...dia.com>,
        Tariq Toukan <tariqt@...dia.com>, vfedorenko@...ek.ru
Subject: Re: [PATCH net-next 2/4] tls: rx: don't consider sock_rcvtimeo() cumulative

On Thu, Jul 28, 2022 at 5:42 PM Jakub Kicinski <kuba@...nel.org> 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.
>
> 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.

s/must/could/    because timers can expire later than expected.

>
> Does that make more sense?