Thread (6 messages) 6 messages, 5 authors, 2023-03-31

Re: general protection fault in raw_seq_start

From: Eric Dumazet <edumazet@google.com>
Date: 2023-03-31 07:05:43
Also in: lkml

On Thu, Mar 30, 2023 at 11:55 PM Kuniyuki Iwashima [off-list ref] wrote:
quoted hunk ↗ jump to hunk
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help