so{,un}lock_shared() take the shared net lock for PF_INET and PF_INET6
while sticking to the exclusive rwlock elsewhere.
getsockopt(2), getsockname(2) and getpeername(2) (all UNLOCK) do not
write, so the exclusive net lock is overkill here.
Did I miss anything?
Feedback? OK?
diff --git a/sys/ker
Both are initalised with compile-time constants and never written to.
They are part of the Neighbour Discovery machinery and only surface
through the single-user SIOCGIFINFO_IN6:
$ ndp -i lo0
basereachable=30s0ms, reachable=39s, retrans=1s0ms
These values are read-only since 2017
On Mon, Nov 28, 2022 at 07:18:24PM +0100, Claudio Jeker wrote:
> On Mon, Nov 28, 2022 at 06:02:56PM +0100, Theo Buehler wrote:
> > On Mon, Nov 28, 2022 at 05:14:48PM +0100, Claudio Jeker wrote:
> > > On Mon, Nov 28, 2022 at 04:50:24PM +0100, Theo Buehler wrote:
> > > > On Mon, Nov 28, 2022 at 04:02
> Date: Mon, 28 Nov 2022 18:26:47 +0100
> From: Claudio Jeker
>
> On Mon, Nov 28, 2022 at 11:32:32AM -0500, Dave Voutila wrote:
> > tech@ et. al.,
> >
> > When kettenis@ introduced a newer version of BOOTARG_CONSDEV to add
> > additional params for the AMD Ryzen V1000 family, vmd's code that
> >
On Mon, Nov 28, 2022 at 06:02:56PM +0100, Theo Buehler wrote:
> On Mon, Nov 28, 2022 at 05:14:48PM +0100, Claudio Jeker wrote:
> > On Mon, Nov 28, 2022 at 04:50:24PM +0100, Theo Buehler wrote:
> > > On Mon, Nov 28, 2022 at 04:02:11PM +0100, Claudio Jeker wrote:
> > > > Since a long time any problem
On Mon, Nov 28, 2022 at 11:32:32AM -0500, Dave Voutila wrote:
> tech@ et. al.,
>
> When kettenis@ introduced a newer version of BOOTARG_CONSDEV to add
> additional params for the AMD Ryzen V1000 family, vmd's code that
> configures bootargs to support direct booting a ramdisk kernel didn't
> adjust
Subj.
At sockets layer we touch only per-socket data, which is solock()
protected().
At protocol layer, unix(4) and key management sockets have no
(*pr_ctloutput)() handlers. route_ctloutput() touches only per socket
data, which is solock() protected. inet{,6} globals are protected by
netlock, wh
On Mon, Nov 28, 2022 at 11:32:32AM -0500, Dave Voutila wrote:
> tech@ et. al.,
>
> When kettenis@ introduced a newer version of BOOTARG_CONSDEV to add
> additional params for the AMD Ryzen V1000 family, vmd's code that
> configures bootargs to support direct booting a ramdisk kernel didn't
> adjus
On Mon, Nov 28, 2022 at 05:14:48PM +0100, Claudio Jeker wrote:
> On Mon, Nov 28, 2022 at 04:50:24PM +0100, Theo Buehler wrote:
> > On Mon, Nov 28, 2022 at 04:02:11PM +0100, Claudio Jeker wrote:
> > > Since a long time any problem that caused rpki-client to not load a
> > > manifest resulted in the
tech@ et. al.,
When kettenis@ introduced a newer version of BOOTARG_CONSDEV to add
additional params for the AMD Ryzen V1000 family, vmd's code that
configures bootargs to support direct booting a ramdisk kernel didn't
adjust with it.
Mischa Peters found this and shared a simple reproducer on 7.2
On Mon, Nov 28, 2022 at 04:50:24PM +0100, Theo Buehler wrote:
> On Mon, Nov 28, 2022 at 04:02:11PM +0100, Claudio Jeker wrote:
> > Since a long time any problem that caused rpki-client to not load a
> > manifest resulted in the non helpful:
> > rpki-client:
> > rpki.afrinic.net/repository/member_r
Hello,
>
>
> Hi,
>
> here's panic with WITNESS and this diff on tech@
> https://www.mail-archive.com/tech@openbsd.org/msg72582.html
>
> I will stop now because I'm not sure what I'm doing and which diffs I'm
> testing...
>
>
> r620-1# uvm_fault(0x8248ea28, 0x17, 0, 2) -> e
> kernel:
On Mon, Nov 28, 2022 at 04:02:11PM +0100, Claudio Jeker wrote:
> Since a long time any problem that caused rpki-client to not load a
> manifest resulted in the non helpful:
> rpki-client:
> rpki.afrinic.net/repository/member_repository/F36505B2/0569917622D711ED862FD6E0F1222468/0nALpPtwFyntPHjkS8xt
Dead since 2017 sys/netinet6/nd6_rtr.c r1.163
Remove sending of router solicitations and processing of router
advertisements from the kernel. It's handled by slaacd(8) these days.
Multiple prefixes are fine, so sysctl(2) net.inet6.icmp6.nd6_debug does not
warn about it like it does for, e.
Since a long time any problem that caused rpki-client to not load a
manifest resulted in the non helpful:
rpki-client:
rpki.afrinic.net/repository/member_repository/F36505B2/0569917622D711ED862FD6E0F1222468/0nALpPtwFyntPHjkS8xt-VQrqLw.mft:
no valid mft available
This hides in most cases the caus
On Mon, Nov 28, 2022 at 02:54:31PM +0100, Alexander Bluhm wrote:
> > NB: While here, nd6 and frag6 could statically initalise their lists
> > right away (they're both static/local to nd6.c and frag6.c anyway), but
>
> I see no big adavantage of variable initializer over ..._init()
> function. Th
> Date: Wed, 23 Nov 2022 17:33:26 +0100
> From: Martin Pieuchot
>
> On 23/11/22(Wed) 16:34, Mark Kettenis wrote:
> > > Date: Wed, 23 Nov 2022 10:52:32 +0100
> > > From: Martin Pieuchot
> > >
> > > On 22/11/22(Tue) 23:40, Mark Kettenis wrote:
> > > > > Date: Tue, 22 Nov 2022 17:47:44 +
> > >
On Sun, Nov 27, 2022 at 09:23:25PM +, Klemens Nanni wrote:
> Only ip6_init() calls nd6_init(), exactly once, just like it calls
> frag6_init() which on the other hand does not have some fra6_init_done
> to guard against itself.
>
> Like all other domains, ip6_init() is called in domaininit(),
On Sun, Nov 27, 2022 at 06:42:48PM +, Klemens Nanni wrote:
> Using a local `duplicate' variable to defer the actual checks by a few
> lines, interleaved with comments (saying the same thing but negated),
> is harder to follow that neccessary.
>
> Fold the logic and merge comments (remove the l
19 matches
Mail list logo
