Panic after introduction of unveil(2) on system with missing /tmp mount point
A few days ago I did the first reboot after an upgrade from snapshots a couple of weeks ago. The machine panicked with the below message which I've never seen before (transcription from image on my mobile camera) and I had to do a warm reboot: 8< login: syncing disks... panic: kernel diagnostics assertion "vp->v_uvcount == 0" failed: file "/usr/src/sys/kern/kern_unveil.c", line 746 Stopped at db_enter+0x12: popq%r11 TIDPIDUID PRFLAGS PFLAGS CPU COMMAND *489797 51004 0 0x3 00K reboot db_enter() at db_enter+0x12 panic() at panic+0x120 __assert(81256574,80002374eed0,0,ff02cdeb50e8) at __assert+0x24 unveil_removevnode(983a7d3933c3f079) at unveil_removevnode+0xf2 dounmount_leaf(1252bfd8bac9e733,80302c40,0) at dounmount_leaf+0x69 dounmount(602b6b5dc61da66e,80203c40,80203c00) at dounmount+0xfa vfs_unmountall() at vfs_unmountall+0xad vfs_shutdown(0) at vfs_shutdown+0x39 boot(7f7f5d78) at boot+0x59 reboot(80002374f0a0) at reboot+0x5a sys_reboot(9595068f44d5290e,800024b85850,817f7323) at sys_reboot+0x 73 syscall(b0161255ac32403c) at syscall+0x32a Xsyscall(6,37,2,37,2,16fdcac30cf6) at Xsyscall+0x128 end of kernel end trace frame: 0x7f7f5df0, count: 2 https://www.openbsd.org/ddb.html describes the minimum info required in bug --db_more-- >8 Now, the following is embarrasing: It turns out that I for six months have been running with the following in my /etc/fstab without noticing: bffb6e701554bf34.d /mnt (usually assigned to /tmp, right!) It is simply a typo from when I manually disklabeled a fresh install of -current on my main workstation. I didn't notice until today when / suddenly got filled up after I tried editing a large video file. I changed /etc/fstab and did a new reboot, upon which the above panic happened again. Another reboot after that (with /tmp finally properly mounted) went well however. I'm aware this is not a proper bug report. I just thought the transcript might be useful to some developers since it seems to involve unveil(2). Before the introduction of unveil(2) I had no problems rebooting the system with a missing mount of /tmp. Regards, Erling
Re: pf: anchor not honoring quick
On Sat, Sep 29, 2018 at 06:17:05PM +0200, Fabian Mueller-Knapp wrote:
> I have the following pf.conf:
>
> anchor quick {
> pass
> }
> block
>
> # pfctl -sr
> anchor quick all {
> pass all flags S/SA
> }
> block drop all
>
> Because of the 'quick' i assumed, that 'block' is never reached, but it
> is since 6.2.
Indeed, `pfctl -s rules -v' clearly shows how every packet goes through
all three rules.
> man pf.conf(5) states:
>
> "If the anchor itself is marked with the quick option, ruleset
> evaluation will terminate when the anchor is exited if the packet is
> matched by any rule within the anchor."
>
> I tested with fresh installs of 6.1, 6.2, 6.3 and current via vmd and
> 6.1 does in fact behave as i would accept (that is, all packets
> pass). From 6.2 on however, all packets are dropped.
Thanks for your report.
> Do i misread the manpage somehow?
No, this is a bug.
Re: checking source with pvs-studio
Sergey Bronnikov wrote: > Hello! > > openbsd source code was checked by various static analyzers (coverity, > cppcheck, clang analyzer etc). Have someone tried PVS-Studio? > It became free to use for opensource projects [1]. > > [1] https://www.viva64.com/en/b/0457/ which means you can roll up your sleeves and be that someone
checking source with pvs-studio
Hello! openbsd source code was checked by various static analyzers (coverity, cppcheck, clang analyzer etc). Have someone tried PVS-Studio? It became free to use for opensource projects [1]. [1] https://www.viva64.com/en/b/0457/ Sergey Bronnikov
pf: anchor not honoring quick
Hello list,
I have the following pf.conf:
anchor quick {
pass
}
block
# pfctl -sr
anchor quick all {
pass all flags S/SA
}
block drop all
Because of the 'quick' i assumed, that 'block' is never reached, but it
is since 6.2.
man pf.conf(5) states:
"If the anchor itself is marked with the quick option, ruleset
evaluation will terminate when the anchor is exited if the packet is
matched by any rule within the anchor."
I tested with fresh installs of 6.1, 6.2, 6.3 and current via vmd and
6.1 does in fact behave as i would accept (that is, all packets
pass). From 6.2 on however, all packets are dropped.
Do i misread the manpage somehow?
Regards,
Fabian
Re: Keyboard repeats characters way to often
Hey,
i am sorry it took me so long to get back to you on this issue. As it
turns out this laptop has a lot of problems with OpenBSD so it took me a
long time to build your patch.
The patch below works fine and fixes the keyboard issue i had on my
Lenovo ThinkPad E485. Everything else works fine as expected!
Thanks for the patch!
Leo
On 09/19/18 03:29, Jonathan Gray wrote:
I had hoped it was gone with zen/17h. As it is very inconsistent as to
which systems have this problem (ie 16h apu laptop has the problem,
16h pcengines apu2 doesn't) we need to test if tsc is desynchronised
on boot.
Here is the old big hammer diff I had extended for 17h but I don't want
to force hpet in cases where tsc is not desynchronised between cores.
Index: tsc.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/tsc.c,v
retrieving revision 1.10
diff -u -p -r1.10 tsc.c
--- tsc.c 27 Jul 2018 21:11:31 - 1.10
+++ tsc.c 19 Sep 2018 01:16:24 -
@@ -32,6 +32,7 @@ int tsc_recalibrate;
uint64_t tsc_frequency;
int tsc_is_invariant;
+inttsc_desync;
uint tsc_get_timecount(struct timecounter *tc);
@@ -172,7 +173,7 @@ calibrate_tsc_freq(void)
return;
tsc_frequency = freq;
tsc_timecounter.tc_frequency = freq;
- if (tsc_is_invariant)
+ if (tsc_is_invariant && tsc_desync == 0)
tsc_timecounter.tc_quality = 2000;
}
@@ -206,10 +207,25 @@ tsc_timecounter_init(struct cpu_info *ci
tsc_frequency = tsc_freq_cpuid(ci);
tsc_is_invariant = 1;
+#ifdef MULTIPROCESSOR
+ /*
+* TSC often desynchronised between cores on
+* 15h (Bulldozer, Piledriver, Steamroller, Excavator)
+* 16h (Jaguar, Puma)
+* 17h (Zen)
+*/
+ if ((strcmp(cpu_vendor, "AuthenticAMD") == 0) &&
+ ((ci->ci_family == 0x15 && ci->ci_model <= 0x6f) ||
+(ci->ci_family == 0x16 && ci->ci_model <= 0x3f) ||
+(ci->ci_family == 0x17 && ci->ci_model <= 0x1f)))
+ tsc_desync = 1;
+#endif
+
/* Newer CPUs don't require recalibration */
if (tsc_frequency > 0) {
tsc_timecounter.tc_frequency = tsc_frequency;
- tsc_timecounter.tc_quality = 2000;
+ if (tsc_desync == 0)
+ tsc_timecounter.tc_quality = 2000;
} else {
tsc_recalibrate = 1;
tsc_frequency = cpufreq;
Re: Ospf adding new interface
On 2018/09/29 13:36, Simen Stavdal wrote: > Thanks Stuart, > > -vd just said the same, i.e interface unknown, will try -current and report > back :) If it doesn't help, it would also be worth capturing "route -n monitor" output while adding. > Thanks, > Simon > > On Sat, 29 Sep 2018 at 13:06, Stuart Henderson wrote: > > I've had problems at times with ospfd not seeing interfaces properly > after adding them, please try a -current snapshot and see if you can > replicate it, it's possible that a change made in June might help. > > Also maybe try running with ospfd -vd and see if you get anything unusual > logged when the interface is added or when you issue 'reload'. > > >
Re: Ospf adding new interface
Thanks Stuart, -vd just said the same, i.e interface unknown, will try -current and report back :) Thanks, Simon On Sat, 29 Sep 2018 at 13:06, Stuart Henderson wrote: > I've had problems at times with ospfd not seeing interfaces properly > after adding them, please try a -current snapshot and see if you can > replicate it, it's possible that a change made in June might help. > > Also maybe try running with ospfd -vd and see if you get anything unusual > logged when the interface is added or when you issue 'reload'. > > >
Re: Ospf adding new interface
I've had problems at times with ospfd not seeing interfaces properly after adding them, please try a -current snapshot and see if you can replicate it, it's possible that a change made in June might help. Also maybe try running with ospfd -vd and see if you get anything unusual logged when the interface is added or when you issue 'reload'.
Re: Ospf adding new interface
Thanks Remi,
I am doing almost exactly that too
My setup:
mgmt--6.3amd64<-rdomain0->6.3octeon-mgmt
Ospf is running inside rdomain0.
Scenario:
On amd64 : I have a few loopback interfaces running, and routing works ok.
Example, lo17 is advertised as 192.168.17.144/32
On octeon : I can ping 192.168.17.144, and it is showing expected egress
interfaces etc
On amd : cp /etc/hostname.lo17 /etc/hostname.lo13
I give lo13 the address of 192.168.13.144/32
I bring it up with sh /etc/netstart lo13
I ping it locally ok
I add the interface as passive in ospfd.conf like you described above,
syntax is good.
I issue ospfctl reload
In /var/log/messages, it says lo13
Sep 29 12:20:18 4nic2 ospfd[33900]: /etc/ospfd.conf:32: unknown interface
lo13
Sep 29 12:20:18 4nic2 ospfd[33900]: configuration reload failed
On octeon : new interface is obviously not seen.
On amd64 : restart the entire ospfd daemon (as opposed to ospfctl reload),
config file now reads ok, no issue.
On octeon : I now can see the advertised lo13 address, and ping it. routing
table looks as expected.
So, I know my syntax is good, because it works when I restart the daemon,
it just happens when I try reloading it.
My setup may be a little different to yours though.
I have a mangement interface that I use to connect to my lab, running in
routing domain 1.
After logging in, I issue a "route -T0 exec ksh" to work inside routing
domain 0.
I have verified that all processes run in the expected routing domains.
Also, I have issued all daemons and reload processes to be executed in
rdomain 0.
i.e route -T0 exec ospfctl reload
I am wondering why ospfd can't see the new interface while running, but it
does after completely restarting the daemon.
I am starting ospfd from command line, not with rc flags, because I am
still testing.
Have tried daemonized and with "-d" flag - both demonstrate the same issue.
Btw, when I reverse it, i.e creating the lo interfaces on the octeon box, I
see the same problem.
Cheers,
Simon.
On Fri, 28 Sep 2018 at 23:41, Remi Locherer wrote:
> Hi Simon
>
> On Fri, Sep 28, 2018 at 10:22:42PM +0200, Simen Stavdal wrote:
> > Hi all,
> >
> > On 6.3, using both octeon and amd64.
> >
> > While ospfd is running, I would like to add another interface (let’s say
> a
> > loopback if). After adding the loopback if to ospf as passive I reload
> > with ospfctl, but it does not start advertising the new interface. Only
> > when I restart ospfd will it start doing so, but it seems a bit intrusive
> > as all neighbours will recalculate. I am sure that something basic had
> > slipped my mind. Any way to make it register the new if?
> >
> > The config is working since it does pick up the if on ospfd restart.
> >
>
> When I do what you describe the route is immediate seen by other ospf
> router. I quickly checked on amd64 -current VMs. I did this many times
> in the last few years and it always worked for me.
>
> I tested now with this config:
>
> r2# cat /etc/ospfd.conf
> router-id 192.168.250.102
>
> area 0.0.0.0 {
> interface vio0
> interface vlan1
> }
>
>
> Then I started ospfd and created lo33. After that I added this line to
> ospfd.conf:
>interface lo33 { passive }
>
> Then I did "ospfctl reload" and the expectd route appeared in neighbor's
> routing table.
>
> Regards,
> Remi
>
