[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <65ae844c2d5df_308772946c@willemb.c.googlers.com.notmuch>
Date: Mon, 22 Jan 2024 10:05:48 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Eric Dumazet <edumazet@...gle.com>,
"David S . Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>
Cc: David Ahern <dsahern@...nel.org>,
Kuniyuki Iwashima <kuniyu@...zon.com>,
Martin KaFai Lau <kafai@...com>,
Guillaume Nault <gnault@...hat.com>,
netdev@...r.kernel.org,
eric.dumazet@...il.com,
Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH net-next 0/9] inet_diag: remove three mutexes in diag
dumps
Eric Dumazet wrote:
> Surprisingly, inet_diag operations are serialized over a stack
> of three mutexes, giving legacy /proc based files an unfair
> advantage on modern hosts.
>
> This series removes all of them, making inet_diag operations
> (eg iproute2/ss) fully parallel.
>
> 1-2) Two first patches are adding data-race annotations
> and can be backported to stable kernels.
>
> 3-4) inet_diag_table_mutex can be replaced with RCU protection,
> if we add corresponding protection against module unload.
>
> 5-7) sock_diag_table_mutex can be replaced with RCU protection,
> if we add corresponding protection against module unload.
>
> 8) sock_diag_mutex is removed, as the old bug it was
> working around has been fixed more elegantly.
>
> 9) inet_diag_dump_icsk() can skip over empty buckets to reduce
> spinlock contention.
>
> Eric Dumazet (9):
> sock_diag: annotate data-races around sock_diag_handlers[family]
> inet_diag: annotate data-races around inet_diag_table[]
> inet_diag: add module pointer to "struct inet_diag_handler"
> inet_diag: allow concurrent operations
> sock_diag: add module pointer to "struct sock_diag_handler"
> sock_diag: allow concurrent operations
> sock_diag: allow concurrent operation in sock_diag_rcv_msg()
> sock_diag: remove sock_diag_mutex
> inet_diag: skip over empty buckets
For the series:
Reviewed-by: Willem de Bruijn <willemb@...gle.com>
Powered by blists - more mailing lists