Re: OpenBSD 7.1/amd64 on APU4D4 - system drops into ddb few times a week
Hi,
just another crash...
After that I upgraded my sys to OpenBSD 7.2-beta (GENERIC.MP) #705: Mon Aug 22
12:25:07 MDT 2022
I'll let you know if anything changes.
ddb{2}> show panic
the kernel did not panic
ddb{2}> trace
tdb_hash(349a9a42,8000225d2b50,32) at tdb_hash+0x9d
gettdb_dir(0,349a9a42,8000225d2b50,32,0) at gettdb_dir+0x85
ipsec_common_input(8000225d2e08,14,9,2,32,0) at ipsec_common_input+0x2f3
esp46_input(8000225d2e08,8000225d2e14,32,2) at esp46_input+0xee
ip_deliver(8000225d2e08,8000225d2e14,32,2) at ip_deliver+0x103
ip_ours(8000225d2e08,8000225d2e14,fd80a642badc,0) at ip_ours+0x184
ip_input_if(8000225d2e08,8000225d2e14,4,0,800ab048) at ip_input
_if+0x19d
ipv4_input(800ab048,fd80c610db00) at ipv4_input+0x39
ether_input(800ab048,fd80c610db00) at ether_input+0x3a2
if_input_process(800ab048,8000225d2ef8) at if_input_process+0x6f
ifiq_process(800ab458) at ifiq_process+0x69
taskq_thread(8002b080) at taskq_thread+0x100
end trace frame: 0x0, count: -12
ddb{2}> mach ddbpcu 0
No such command
ddb{2}> mach ddbcpu 0
Stopped at x86_ipi_db+0x12:leave
ddb{0}> trace
x86_ipi_db(822c6ff0) at x86_ipi_db+0x12
x86_ipi_handler() at x86_ipi_handler+0x80
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23
acpicpu_idle() at acpicpu_idle+0x11f
sched_idle(822c6ff0) at sched_idle+0x280
end trace frame: 0x0, count: -5
ddb{0}> mach ddbcpu 1
Stopped at x86_ipi_db+0x12:leave
ddb{1}> trace
x86_ipi_db(800022408ff0) at x86_ipi_db+0x12
x86_ipi_handler() at x86_ipi_handler+0x80
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23
acpicpu_idle() at acpicpu_idle+0x11f
sched_idle(800022408ff0) at sched_idle+0x280
end trace frame: 0x0, count: -5
ddb{1}> mach ddbcpu 2
Stopped at tdb_hash+0x9d: movzbl 0(%r14),%r8d
ddb{2}> trace
tdb_hash(349a9a42,8000225d2b50,32) at tdb_hash+0x9d
gettdb_dir(0,349a9a42,8000225d2b50,32,0) at gettdb_dir+0x85
ipsec_common_input(8000225d2e08,14,9,2,32,0) at ipsec_common_input+0x2f3
esp46_input(8000225d2e08,8000225d2e14,32,2) at esp46_input+0xee
ip_deliver(8000225d2e08,8000225d2e14,32,2) at ip_deliver+0x103
ip_ours(8000225d2e08,8000225d2e14,fd80a642badc,0) at ip_ours+0x184
ip_input_if(8000225d2e08,8000225d2e14,4,0,800ab048) at ip_input
_if+0x19d
ipv4_input(800ab048,fd80c610db00) at ipv4_input+0x39
ether_input(800ab048,fd80c610db00) at ether_input+0x3a2
if_input_process(800ab048,8000225d2ef8) at if_input_process+0x6f
ifiq_process(800ab458) at ifiq_process+0x69
taskq_thread(8002b080) at taskq_thread+0x100
end trace frame: 0x0, count: -12
ddb{2}> mach ddbcpu 3
Stopped at x86_ipi_db+0x12:leave
ddb{3}> trace
x86_ipi_db(80002241aff0) at x86_ipi_db+0x12
x86_ipi_handler() at x86_ipi_handler+0x80
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23
acpicpu_idle() at acpicpu_idle+0x11f
sched_idle(80002241aff0) at sched_idle+0x280
end trace frame: 0x0, count: -5
ddb{3}> ps
PID TID PPIDUID S FLAGS WAIT COMMAND
75864 281064 42991 74 3 0x1100092 bpf pflogd
42991 25090 1 0 30x80 netio pflogd
72099 365712 1 0 30x100083 ttyin getty
75850 250115 1 0 30x100098 kqreadcron
34840 92342 1 0 30x80 ugenrintr apcupsd
34840 102465 1 0 3 0x488 sigwait apcupsd
34840 507125 1 0 3 0x480 nanoslp apcupsd
53220 174176 1 99 3 0x1100090 kqreadsndiod
99208 383592 1110 30x100090 kqreadsndiod
53667 31408 64688 95 3 0x1100092 kqreadsmtpd
1513 485354 64688103 3 0x1100092 kqreadsmtpd
303817936 64688 95 3 0x1100092 kqreadsmtpd
48867 487651 64688 95 30x100092 kqreadsmtpd
94459 415826 64688 95 3 0x1100092 kqreadsmtpd
39840 345575 64688 95 3 0x1100092 kqreadsmtpd
64688 148096 1 0 30x100080 kqreadsmtpd
27519 138514 1 77 3 0x1100090 kqreaddhcpd
81524 360290 1 0 30x88 kqreadsshd
35735 95051 81607 68 3 0x190 kqreadisakmpd
81607 191046 1 0 30x80 netio isakmpd
36275 457664 1 0 30x100080 kqreadntpd
25071 35250 94020 83 30x100092 kqreadntpd
94020 410848 1 83 3 0x1100092 kqreadntpd
44006 213133 48231 73 3 0x1100090 kqreadsyslogd
48231 256037 1 0 30x100082 netio syslogd
73507 496689 1 0 30x100080 kqreadresolvd
67362 447196 67708 77 30x100092 kqreaddhcpleased
99425 70674 67708 77 30x100092 kqread
Re: Missing and strfmon()/strfmon_l()
On 2022/08/17 11:30, Ingo Schwarze wrote: > QUESTION TO PORTERS: > Would providing , strfmon(3), and strfmon_l(3) > in our libc make porters' lives easier, or are these interfaces > used so rarely in real-world programs that it does not matter? Only Star Traders has a patch to cope with it. I tried searching on codesearch.debian.net for other users but it's hard to find any amongst the many copies of gnulib. It woukdn't hurt to have a basic implementation, but there are more pressing issues (e.g. xlocale).
Re: Missing and strfmon()/strfmon_l()
> Date: Wed, 17 Aug 2022 11:30:04 +0200
> From: Ingo Schwarze
>
> QUESTION TO PORTERS:
> Would providing , strfmon(3), and strfmon_l(3)
> in our libc make porters' lives easier, or are these interfaces
> used so rarely in real-world programs that it does not matter?
Note that these interfaces have been made part of POSIX proper some time ago:
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/monetary.h.html
Given that we aim to be POSIX-compatible, we probably should add a
(minimal) implementation of these functions.
> Hi John,
>
> John Zaitseff wrote on Wed, Aug 17, 2022 at 12:29:20PM +1000:
>
> > Apologies in advance if I am sending this to the wrong list...
>
> Since strfmon(3) is a useless API and this discussion is exclusively
> about compatibility, asking on ports@ would have been better,
> more accurately targetting the intended audience, but bugs@ is not
> outright wrong either because OpenBSD aims to support POSIX unless
> there are specific reasons to not support something, and ,
> strfmon(3), and strfmon_l(3) are specified by POSIX.
>
> However, strfmon(3) is even more ill-designed than other POSIX
> locale-related functions:
>
> - strfmon(3) is designed to interpret the same floating-point
>number differently depending on the user's locale(1).
>But whether a user owns 42.00 Turkish Lira or 42.00 Pound Sterling
>is *not* a matter of personally preferred output conventions.
>Consequently, i can hardly imagine any situation where using
>strfmon*(3) might make any sense. Using this functions will
>usually misrepresent the currency owned by the user, causing
>wrong output.
>
> - Arguably, you can use the "!" flag to suppress the misfeature
>of having the currency symbol depend on the user's locale,
>but then, strfmon(3) mostly duplicates functionality already
>provided by printf(3) with a very small number of gratuitious
>variations, so i see no conceivable motivation for using the
>interface with "!" either.
>
> For those reasons, i think using is a terrible idea in the
> first place and we should not add it to our libc if we can avoid it.
>
> That said, even if an API is abominable (like this one),
> support can sometimes be considered *if* it is used by enough
> ports(7) that its absense causes pain for OpenBSD porters.
> The only condition in such cases is that a dummy version can be
> provided that poses no security risks. I do not doubt that
> would be possible for strfmon(3) and strfmon_l(3).
>
> > A few years ago, Frederic Cambus packaged Star Traders, my simple
> > game of interstellar trading, for OpenBSD ("trader"). In doing so,
> > he bundled FreeBSD's version of strfmon() as that function is
> > required by my program.
>
> My personal recommendation would be to stop using the bad function
> in your program.
>
> > Longer term, however, could OpenBSD include , strfmon()
> > and strfmon_l(), possibly by copying these from the latest version
> > of FreeBSD.
>
> Well, as usual, the FreeBSD version of locale functions is seriously
> bloated, so if porters tell me that lack of the function causes
> pain for them, i would radically strip it down before commit.
>
> Yours,
> Ingo
>
>
Re: rt_ifa_del NULL deref
On Tue, Aug 23, 2022 at 02:16:27PM +0200, Alexander Bluhm wrote:
> On Tue, Aug 23, 2022 at 12:23:05PM +0200, Stefan Sperling wrote:
> > On Tue, Aug 23, 2022 at 11:43:22AM +0200, Alexander Bluhm wrote:
> > > On Tue, Aug 23, 2022 at 10:15:22AM +0200, Stefan Sperling wrote:
> > > > I found one of my amd64 systems running -current, built on 12th of
> > > > August, has crashed as follows.
> > >
> > > I there any chance that the kernel sources are between these commits?
> > > August 12th does not fit exactly, do you remember when you did the
> > > checkout? Or is it a snapshot kernel?
> >
> > Do you want to me provide anything else from ddb?
>
> The ususal:
>
> show panic
> show registers
> trace
> ps
> show struct ifaddr 0x804e9400
> show all routes
> traces from other cpu
>
> I fear that there will be no really usefull info. It looks like a
> use after free. When removing the route, the nd6 timer should have
> been deleted.
Makes sense. Anyway, here is the output:
ddb{2}> show panic
the kernel did not panic
ddb{2}> show registers
rdi 0x804e9400
rsi 0x800100acpi_pdirpa+0x7ebf68
rbp 0x800022d4cea0
rbx0
rdx 0xdeaf0009deafbead
rcx0
rax 0xdeafbeaddeafbead
r8 0
r90x82125101arcturus_feature_mask_map+0x2d1
r10 0x8
r11 0xeb6a1cd605457cff
r12 0xdeaf0009deafbead
r130
r14 0x804e9400
r15 0x800100acpi_pdirpa+0x7ebf68
rip 0x813ef4f9rt_ifa_del+0x39
cs 0x8
rflags 0x10286__ALIGN_SIZE+0xf286
rsp 0x800022d4cd60
ss 0x10
rt_ifa_del+0x39:movb0x1be(%rax),%bl
ddb{2}> trace
rt_ifa_del(804e9400,800100,deaf0009deafbead,0) at rt_ifa_del+0x39
in6_unlink_ifa(804e9400,800da2a8) at in6_unlink_ifa+0xae
in6_purgeaddr(804e9400) at in6_purgeaddr+0x127
nd6_expire(0) at nd6_expire+0x96
taskq_thread(8002c080) at taskq_thread+0x100
end trace frame: 0x0, count: -5
ddb{2}> ps
PID TID PPIDUID S FLAGS WAIT COMMAND
85757 212591 1 0 30x100083 ttyin getty
13844 194231 1 0 30x100083 ttyin getty
52351 462696 1 0 30x100083 ttyin getty
11970 274173 1 0 30x100083 ttyin getty
55817 204799 1 0 30x100083 ttyin getty
55147 459952 1 0 30x100083 ttyin getty
97104 507732 1 0 30x100098 kqreadcron
24934 108341 1 99 3 0x1100090 kqreadsndiod
24851 158785 1110 30x100090 kqreadsndiod
79580 437931 1 0 30x100080 kqreadhttpd
90912 365815 1 67 3 0x1100092 kqreadhttpd
11193 62187 1 67 3 0x1100092 kqreadhttpd
11994 82021 1 67 3 0x1100092 kqreadhttpd
6336 127367 1 67 3 0x1100092 kqreadhttpd
46164 440393 1 67 3 0x1100092 kqreadhttpd
5307 16141 1 67 3 0x1100092 kqreadhttpd
3246 133657 1 67 3 0x1100092 kqreadhttpd
67433 170750 1 67 3 0x1100092 kqreadhttpd
71968 499680 1 67 3 0x1100092 kqreadhttpd
56363 70989 1 67 3 0x1100092 kqreadhttpd
66759 513771 1 67 3 0x1100092 kqreadhttpd
53393 89252 1 67 3 0x1100092 kqreadhttpd
65858 323071 1 67 3 0x1100092 kqreadhttpd
66322 146077 1 67 3 0x1100092 kqreadhttpd
14621 176429 1 67 3 0x1100092 kqreadhttpd
74712 218180 1 67 3 0x1100092 kqreadhttpd
61865 208410 1 67 3 0x1100092 kqreadhttpd
67924 73387 1 67 3 0x1100092 kqreadhttpd
62026 199422 1 67 3 0x1100092 kqreadhttpd
85443 340524 1 67 3 0x1100092 kqreadhttpd
95521 46441 1 67 3 0x1100092 kqreadhttpd
375 324584 1 67 3 0x1100092 kqreadhttpd
18765 359197 1 67 3 0x1100092 kqreadhttpd
60496 158853 1 67 3 0x1100092 kqreadhttpd
70095302 1 67 3 0x1100092 kqreadhttpd
36669 77305 1 67 3 0x1100092 kqreadhttpd
1569 118333 1 67 3 0x1100092 kqreadhttpd
90776 452570 1 67 3 0x1100092 kqreadhttpd
9695 181990 1 67 3 0x1100092 kqreadhttpd
62979 426648 1 67 3 0x1100092 kqreadhttpd
95880 55501
Re: rt_ifa_del NULL deref
On Tue, Aug 23, 2022 at 12:23:05PM +0200, Stefan Sperling wrote: > On Tue, Aug 23, 2022 at 11:43:22AM +0200, Alexander Bluhm wrote: > > On Tue, Aug 23, 2022 at 10:15:22AM +0200, Stefan Sperling wrote: > > > I found one of my amd64 systems running -current, built on 12th of > > > August, has crashed as follows. > > > > I there any chance that the kernel sources are between these commits? > > August 12th does not fit exactly, do you remember when you did the > > checkout? Or is it a snapshot kernel? > > Do you want to me provide anything else from ddb? The ususal: show panic show registers trace ps show struct ifaddr 0x804e9400 show all routes traces from other cpu I fear that there will be no really usefull info. It looks like a use after free. When removing the route, the nd6 timer should have been deleted. > I can tell you exactly what sources I built once I reboot the machine. Except the backout there was no relevant change around that time.
Re: rt_ifa_del NULL deref
On Tue, Aug 23, 2022 at 11:43:22AM +0200, Alexander Bluhm wrote: > On Tue, Aug 23, 2022 at 10:15:22AM +0200, Stefan Sperling wrote: > > I found one of my amd64 systems running -current, built on 12th of > > August, has crashed as follows. > > I there any chance that the kernel sources are between these commits? > August 12th does not fit exactly, do you remember when you did the > checkout? Or is it a snapshot kernel? Do you want to me provide anything else from ddb? I can tell you exactly what sources I built once I reboot the machine. I would have synced the src repository from github on August 12 just before building this kernel. Both changes you mentioned should already be contained in this kernel; the latest was committed on August 9. So I don't think my system hit that particular issue. There should be small wifi driver patches in there, as well as my raid1c boot diffs (since committed). No local changes apart from this.
Re: rt_ifa_del NULL deref
On Tue, Aug 23, 2022 at 10:15:22AM +0200, Stefan Sperling wrote:
> I found one of my amd64 systems running -current, built on 12th of
> August, has crashed as follows.
I there any chance that the kernel sources are between these commits?
August 12th does not fit exactly, do you remember when you did the
checkout? Or is it a snapshot kernel?
revision 1.246
date: 2022/08/09 21:10:03; author: kn; state: Exp; lines: +10 -10;
commitid: 7dnmtpMeiy7k6IOQ;
Backout "Call getuptime() just once per function"
This caused stuck ndp cache entries as found by naddy, sorry.
revision 1.244
date: 2022/08/08 15:56:35; author: kn; state: Exp; lines: +10 -10;
commitid: ILY0HdurUXzwu2qJ;
Call getuptime() just once per function
IPv6 pendant to bluhm's sys/netinet/if_ether.c r1.249:
Instead of calling getuptime() all the time in ARP code, do it only
once per function. This gives a more consistent time value.
OK claudio@ miod@ mvs@
OK bluhm
> I am not sure if this is still relevant; please excuse the noise if
> this has already been found and fixed.
I am not aware of a fix in this area. nd6 is not MP safe, so we
have a big kernel lock around it. I have asked kn@ to look at nd6
locking.
The interaction between rtable SRP locking and MP access to routing
table leaves like nd6 is less than optinal. I expect bugs there.
> kernel: protection fault trap, code=0
> Stopped at rt_ifa_del+0x39:movb0x1be(%rax),%bl
> ddb{2}> bt
> rt_ifa_del(804e9400,800100,deaf0009deafbead,0) at rt_ifa_del+0x39
> in6_unlink_ifa(804e9400,800da2a8) at in6_unlink_ifa+0xae
> in6_purgeaddr(804e9400) at in6_purgeaddr+0x127
> nd6_expire(0) at nd6_expire+0x96
> taskq_thread(8002c080) at taskq_thread+0x100
> end trace frame: 0x0, count: -5
Re: xlock don't take my password anymore
On Sun, Aug 14, 2022 at 01:05:49PM +0200, BESSOT Jean-Michel wrote:
> Hello
>
> Xlock do not take my password since my last snapshot update (well there is
> time since the one before).
>
> I use a bépo keyboard so kdb is set with fr dvorak
>
Hi,
can you try the patch below (already tested by Denis, who provided a
hint on the issue) ?
(get the xenocara tree, apply in app/xlockmore using patch(1) and
rebuild xlockmore by running the following commands in
/usr/xenocara/app/xlockmore :
doas make -f Makefile.bsd-wrapper obj
doas make -f Makefile.bsd-wrapper build
Index: xlock/passwd.c
===
RCS file: /cvs/OpenBSD/xenocara/app/xlockmore/xlock/passwd.c,v
retrieving revision 1.3
diff -u -r1.3 passwd.c
--- xlock/passwd.c 26 Jun 2022 14:09:51 - 1.3
+++ xlock/passwd.c 22 Aug 2022 21:35:49 -
@@ -1279,16 +1279,19 @@
#ifdef USE_PRIVSEP
char*pass;
char*style;
+ int authok;
/* buffer can be in the form style:pass */
if ((pass = strchr(buffer, ':')) != NULL) {
*pass++ = '\0';
style = buffer;
- } else {
- pass = buffer;
- style = NULL;
- }
- return priv_pw_check(user, pass, style);
+ authok = priv_pw_check(user, style, pass);
+ *--pass = ':';
+ } else
+ authok = 0;
+ pass = buffer;
+ style = NULL;
+ return (authok || priv_pw_check(user, pass, style));
#elif defined(BSD_AUTH)
char *pass;
char *style;
--
Matthieu Herrb
rt_ifa_del NULL deref
I found one of my amd64 systems running -current, built on 12th of
August, has crashed as follows.
I am not sure if this is still relevant; please excuse the noise if
this has already been found and fixed.
kernel: protection fault trap, code=0
Stopped at rt_ifa_del+0x39:movb0x1be(%rax),%bl
ddb{2}> bt
rt_ifa_del(804e9400,800100,deaf0009deafbead,0) at rt_ifa_del+0x39
in6_unlink_ifa(804e9400,800da2a8) at in6_unlink_ifa+0xae
in6_purgeaddr(804e9400) at in6_purgeaddr+0x127
nd6_expire(0) at nd6_expire+0x96
taskq_thread(8002c080) at taskq_thread+0x100
end trace frame: 0x0, count: -5
