netdev - Re: [PATCH net-next v3 06/15] quic: add stream management

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] [day] [month] [year] [list]

Message-ID: <f89701ce-839e-4032-bb1d-40fb1b67cb70@redhat.com>
Date: Thu, 25 Sep 2025 18:03:26 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Xin Long <lucien.xin@...il.com>
Cc: network dev <netdev@...r.kernel.org>, quic@...ts.linux.dev,
 davem@...emloft.net, kuba@...nel.org, Eric Dumazet <edumazet@...gle.com>,
 Simon Horman <horms@...nel.org>, Stefan Metzmacher <metze@...ba.org>,
 Moritz Buhl <mbuhl@...nbsd.org>, Tyler Fanelli <tfanelli@...hat.com>,
 Pengtao He <hepengtao@...omi.com>, linux-cifs@...r.kernel.org,
 Steve French <smfrench@...il.com>, Namjae Jeon <linkinjeon@...nel.org>,
 Paulo Alcantara <pc@...guebit.com>, Tom Talpey <tom@...pey.com>,
 kernel-tls-handshake@...ts.linux.dev, Chuck Lever <chuck.lever@...cle.com>,
 Jeff Layton <jlayton@...nel.org>, Benjamin Coddington <bcodding@...hat.com>,
 Steve Dickson <steved@...hat.com>, Hannes Reinecke <hare@...e.de>,
 Alexander Aring <aahringo@...hat.com>, David Howells <dhowells@...hat.com>,
 Matthieu Baerts <matttbe@...nel.org>, John Ericson <mail@...nericson.me>,
 Cong Wang <xiyou.wangcong@...il.com>, "D . Wythe"
 <alibuda@...ux.alibaba.com>, Jason Baron <jbaron@...mai.com>,
 illiliti <illiliti@...tonmail.com>, Sabrina Dubroca <sd@...asysnail.net>,
 Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
 Daniel Stenberg <daniel@...x.se>,
 Andy Gospodarek <andrew.gospodarek@...adcom.com>
Subject: Re: [PATCH net-next v3 06/15] quic: add stream management

On 9/23/25 7:57 PM, Xin Long wrote:
> On Tue, Sep 23, 2025 at 9:39 AM Paolo Abeni <pabeni@...hat.com> wrote:
>> On 9/19/25 12:34 AM, Xin Long wrote:
>>> +/* Create and register new streams for sending. */
>>> +static struct quic_stream *quic_stream_send_create(struct quic_stream_table *streams,
>>> +                                                s64 max_stream_id, u8 is_serv)
>>> +{
>>> +     struct quic_stream *stream;
>>> +     s64 stream_id;
>>> +
>>> +     stream_id = streams->send.next_bidi_stream_id;
>>> +     if (quic_stream_id_uni(max_stream_id))
>>> +             stream_id = streams->send.next_uni_stream_id;
>>> +
>>> +     /* rfc9000#section-2.1: A stream ID that is used out of order results in all streams
>>> +      * of that type with lower-numbered stream IDs also being opened.
>>> +      */
>>> +     while (stream_id <= max_stream_id) {
>>> +             stream = kzalloc(sizeof(*stream), GFP_KERNEL);
>>> +             if (!stream)
>>> +                     return NULL;
>>
>> How many streams and connections ID do you foresee per socket? Could
>> such number grow significantly (possibly under misuse/attack)? If so you
>> you likely use GFP_KERNEL_ACCOUNT here (and in conn_id allocation).
> connections ID: 8 (QUIC_CONN_ID_LIMIT) at most per socket.
> streams: 4096 (QUIC_MAX_STREAMS) at most per socket.

Will such limit fit a (very) busy server? I guess it's more a question
those who already run quic workload at scale...

> I can switch to GFP_KERNEL_ACCOUNT in quic_stream_send_create().
> 
> For quic_stream_recv_create(), it’s typically invoked in atomic context.
> Since there’s no predefined GFP_ATOMIC_ACCOUNT, I assume using
> (GFP_ATOMIC | __GFP_ACCOUNT) should be acceptable.

I see there are already a few other allocations using such flags, and I
could not find any explicit limitation/drawback for it. I hope it's not
just cargo cult programming :-P

/P