Re: Fw: [Bug 219766] New: Garbage Ethernet Frames

[Ido Schimmel <idosch@idosch.org>]

On Mon, Feb 17, 2025 at 05:31:16PM -0500, Xin Long wrote:
> On Sat, Feb 15, 2025 at 3:47 PM Ido Schimmel <idosch@idosch.org> wrote:
> > Another possible solution is to have the blackhole device consume the
> > packets instead of letting them go out without an Ethernet header [4].
> > Doesn't seem great as the packets disappear without telling anyone
> > (before 22600596b675 an error was returned).
> This looks fine to me. The fix in commit 22600596b675 was specifically
> intended to prevent an error from being returned in these cases, as it
> would break userspace UDP applications.

Yes, I later realized that this is fine as well. Packets are already
discarded today via dst_discard_out() if dst_dev_put() was called on a
dst entry before calling dst_output():

# bpftrace -e 'k:dst_discard_out { @[kstack()] = count(); }'
Attaching 1 probe...
^C

@[
    dst_discard_out+5
    ip_send_skb+25
    udp_send_skb+376
    udp_sendmsg+2516
    sock_write_iter+365
    vfs_write+937
    ksys_write+200
    do_syscall_64+158
    entry_SYSCALL_64_after_hwframe+119
]: 2034

While running the reproducer I shared earlier.

> If you prefer to avoid silent drops, you could add a warning like:
> 
>   net_warn_ratelimited("%s(): Dropping skb.\n", __func__);
> 
> similar to how blackhole_netdev_xmit() handles it.

I would like to avoid spamming the kernel log with these messages. I
checked and we see these messages on a few machines while running the
IPv6 torture tests in fib_nexthops.sh. Maybe in net-next I will add a
new drop reason for these scenarios.

> Thanks.

Thanks. I will run this patch through regression and post later this
week if everything is fine.