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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 4 May 2020 05:23:17 -0600
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     syzbot <syzbot+0251e883fe39e7a0cb0a@...kaller.appspotmail.com>,
        David Miller <davem@...emloft.net>,
        Florian Fainelli <f.fainelli@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Jiří Pírko <jiri@...nulli.us>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Jakub Kicinski <kuba@...nel.org>, kvalo@...eaurora.org,
        leon@...nel.org, LKML <linux-kernel@...r.kernel.org>,
        linux-kselftest@...r.kernel.org, Netdev <netdev@...r.kernel.org>,
        Shuah Khan <shuah@...nel.org>, syzkaller-bugs@...glegroups.com,
        Thomas Gleixner <tglx@...utronix.de>, vivien.didelot@...il.com,
        Cong Wang <xiyou.wangcong@...il.com>
Subject: Re: INFO: rcu detected stall in wg_packet_tx_worker

So in spite of this Syzkaller bug being unrelated in the end, I've
continued to think about the stacktrace a bit, and combined with some
other [potentially false alarm] bug reports I'm trying to wrap my head
around, I'm a bit a curious about ideal usage for the udp_tunnel API.

All the uses I've seen in the kernel (including wireguard) follow this pattern:

rcu_read_lock_bh();
sock = rcu_dereference(obj->sock);
...
udp_tunnel_xmit_skb(..., sock, ...);
rcu_read_unlock_bh();

udp_tunnel_xmit_skb calls iptunnel_xmit, which winds up in the usual
ip_local_out path, which eventually winds up calling some other
devices' ndo_xmit, or gets queued up in a qdisc. Calls to
udp_tunnel_xmit_skb aren't exactly cheap. So I wonder: is holding the
rcu lock for all that time really a good thing?

A different pattern that avoids holding the rcu lock would be:

rcu_read_lock_bh();
sock = rcu_dereference(obj->sock);
sock_hold(sock);
rcu_read_unlock_bh();
...
udp_tunnel_xmit_skb(..., sock, ...);
sock_put(sock);

This seems better, but I wonder if it has some drawbacks too. For
example, sock_put has some comment that warns against incrementing it
in response to forwarded packets. And if this isn't necessary to do,
it's marginally more costly than the first pattern.

Any opinions about this?

Jason

Powered by blists - more mailing lists