netdev - Re: [PATCH v1 net-next 4/7] af_unix: Use cached value for SOCK_STREAM in unix_inq

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: <686a7fd16830f_3aa6542947b@willemb.c.googlers.com.notmuch>
Date: Sun, 06 Jul 2025 09:53:21 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Kuniyuki Iwashima <kuniyu@...gle.com>, 
 "David S. Miller" <davem@...emloft.net>, 
 Eric Dumazet <edumazet@...gle.com>, 
 Jakub Kicinski <kuba@...nel.org>, 
 Paolo Abeni <pabeni@...hat.com>
Cc: Simon Horman <horms@...nel.org>, 
 Kuniyuki Iwashima <kuniyu@...gle.com>, 
 Kuniyuki Iwashima <kuni1840@...il.com>, 
 netdev@...r.kernel.org
Subject: Re: [PATCH v1 net-next 4/7] af_unix: Use cached value for SOCK_STREAM
 in unix_inq_len().

Kuniyuki Iwashima wrote:
> Compared to TCP, ioctl(SIOCINQ) for AF_UNIX SOCK_STREAM socket is more
> expensive, as unix_inq_len() requires iterating through the receive queue
> and accumulating skb->len.
> 
> Let's cache the value for SOCK_STREAM to a new field during sendmsg()
> and recvmsg().
> 
> The field is protected by the receive queue lock.

nit: for updates, but the read is taken without the lock held, hence
the WRITE_ONCE/READ_ONCE accessors.

> 
> Note that ioctl(SIOCINQ) for SOCK_DGRAM returns the length of the first
> skb in the queue.
> 
> SOCK_SEQPACKET still requires iterating through the queue because we do
> not touch functions shared with unix_dgram_ops.  But, if really needed,
> we can support it by switching __skb_try_recv_datagram() to a custom
> version.
> 
> Signed-off-by: Kuniyuki Iwashima <kuniyu@...gle.com>

Reviewed-by: Willem de Bruijn <willemb@...gle.com>