XXX Not sure if testing tp->t_template is the right way to discern
this -- I just reached for it because the downstream crash is a panic
on tp->t_template == NULL in tcp_output.
XXX In principle this could try connecting to the address, except
it's not passed down from the logic in uipc_socket.c to tcp_sendoob.
Reported-by: syzbot+a01f4cfec72790855ce2@syzkaller.appspotmail.com
You should always be able to bind to the unspecified address even if
no addresses have been configured on any interface.
For example, a DHCP client could be started before the loopback interface
has been fully configured.
These were originally made failable back in 2017 when if_initialize
allocated a softint in every interface for link state changes, so
that it could fail gracefully instead of panicking:
https://mail-index.NetBSD.org/source-changes/2017/10/23/msg089053.html
However, this spawned many seldom- or never-tested error branches,
which are risky to have around. And that softint in every interface
has since been replaced by a single global workqueue, because link
state changes require thread context but not low latency or high
throughput:
https://mail-index.NetBSD.org/source-changes/2020/02/06/msg113759.html
So there is no longer any reason for if_initialize to fail. (The
subroutine if_stats_init can't fail because percpu_alloc can't fail
either.)
There is a snag: the softint_establish in if_percpuq_create could
fail, potentially leading to bad consequences later on trying to use
the softint. This change doesn't introduce any new bugs because of
the snag -- if_percpuq_attach was already broken. However, the snag
can be better addressed without spawning error branches, either by
using a single softint or making softints less scarce.
(Separate commit will change the signatures of if_attach and
if_initialize to return void, scheduled to ride whatever is the next
convenient kernel bump.)
Patch and testing on amd64 and evbmips64-eb by maya@; commit message
soliloquy, and compile-testing on evbppc/i386/earmv7hf, by me.
riastradh