[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89iK5D75-SNg28ALi4Zr9JEHnreBpfu_pq0_zLe4jDLT5rw@mail.gmail.com>
Date: Fri, 31 Mar 2023 09:04:47 +0200
From: Eric Dumazet <edumazet@...gle.com>
To: Kuniyuki Iwashima <kuniyu@...zon.com>
Cc: threeearcat@...il.com, davem@...emloft.net, dsahern@...nel.org,
kuba@...nel.org, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, pabeni@...hat.com
Subject: Re: general protection fault in raw_seq_start
On Thu, Mar 30, 2023 at 11:55 PM Kuniyuki Iwashima <kuniyu@...zon.com> wrote:
> Thanks for reporting the issue.
>
> It seems we need to use RCU variant in raw_get_first().
> I'll post a patch.
>
> ---
> diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
> index 3cf68695b40d..fe0d1ad20b35 100644
> --- a/net/ipv4/raw.c
> +++ b/net/ipv4/raw.c
> @@ -957,7 +957,7 @@ static struct sock *raw_get_first(struct seq_file *seq, int bucket)
> for (state->bucket = bucket; state->bucket < RAW_HTABLE_SIZE;
> ++state->bucket) {
> hlist = &h->ht[state->bucket];
> - sk_nulls_for_each(sk, hnode, hlist) {
> + sk_nulls_for_each_rcu(sk, hnode, hlist) {
> if (sock_net(sk) == seq_file_net(seq))
> return sk;
>
No, we do not want this.
You missed that sk_nulls_for_each_rcu() needs a specific protocol
(see Documentation/RCU/rculist_nulls.rst for details)
RCU is needed in the data path, not for this control path.
My patch went too far in the RCU conversion. I did not think about
syzbot harassing /proc files :)
We need raw_seq_start and friends to go back to use the lock.
Powered by blists - more mailing lists