Re: `cwm`: custom `bind-key` for `command term` don't work
> > There are 2 special `command`s: `term` and `lock`. > > No, there are two special commands: 'terminal' and 'lock'. > > You probably want: > > bind-key M-Return terminal I see, so there are https://man.openbsd.org/cwmrc#command command term ... command lock ... but https://man.openbsd.org/cwmrc#BIND_FUNCTION_LIST bind-key ... terminal bind-key ... lock lock is lock, term is terminal. Unexpected, TBH, and confusing... That works, thank you Crystal
Re: panic with softdep and softraid crypto on USB stick
On Tue, 24 May 2022, Sven M. Hallberg wrote: ... > >Description: > I have a 64 GB USB stick which holds a single softraid partition which > holds a CRYPTO volume which holds a single FFS partition. I had this > mounted with softdep and was running chromium with HOME set to the > mountpoint of the USB stick. It had a number of modern (TM) web apps > open, including Slack and Google Docs. Other processes on the system > included Firefox with a remote conferencing app open, but the > environment untouched. > I left the system unattended for about 30 minutes to find a kernel > panic upon my return. The attached screenshot appears to show it in > chrome filesystem activity, in softdep_deallocate_dependencies(). > I have used this setup previously without issue for several hours at a > time. The only thing notably different this time around may have been > the concurrent workload in the otherwise unrelated Firefox. As your first image showed, there was an unrecoverable I/O error. I.e., your USB stick has at least one bad block. Time to switch to your backup USB stick and throw out this one. The reason OpenBSD paniced in this case instead of just failing the specific involved operation is that you were using softdeps: there are cases where softdeps can delay an operation to a point where the write out for other operations depend on it such that if the I/O for that first operation fails, the dependent operations cannot be undone and the failure propagated up safely. Rather than continue and keep buffering unsavable data after claiming that the operations succeeded when they haven't, the softdeps code will panic. You can stop using softdeps and maybe you'll be able to get some more use out of that USB stick, but I wouldn't trust it for anything important. Philip Guenther
Re: `cwm`: custom `bind-key` for `command term` don't work
On Tue, May 24, 2022 at 11:18:59PM +0300, u...@mailo.com wrote: > There are 2 special `command`s: `term` and `lock`. No, there are two special commands: 'terminal' and 'lock'. You probably want: bind-key M-Return terminal
`cwm`: custom `bind-key` for `command term` don't work
>Synopsis: `cwm`: custom `bind-key` for `command term` don't work
>Category: user
>Environment:
System : OpenBSD 7.1
Details : OpenBSD 7.1 (GENERIC) #1: Tue May 3 08:27:33 MDT 2022
r...@syspatch-71-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
Architecture: OpenBSD.i386
Machine : i386
>Description:
The default `CM-Return` does work,
with both default `xterm` and a custom one, tried:
command term lxterminal
command term leafpad# editor, not a terminal, launches as expected
Custom `bind-key` though doesn't launch:
bind-key 4-t term# nope
bind-key M4-t lxterminal # yep
unbind CM-Return
does unbind the default hotkey but doesn't help a custom one
There are 2 special `command`s: `term` and `lock`.
There are no problems with `lock` - custom `bind-key` work fine.
>How-To-Repeat:
1. Backup your `~/.cwmrc`
2. `rm -v ~/.cwmrc`
3. Load `cwm`, with no `~/.cwmrc` it loads default configuration
4. Press `CM-Return` (Ctrl + Alt + Enter) to launch `xterm`;
press `CM-Delete` (Ctrl + Alt + Delete) to lock screen with `xlock`
to check that the default keybindings work.
5. Create `~/.cwmrc` and make it look like this:
__
bind-key 4-t term # keybinding to launch via `command term`
bind-key 4-l lock # keybinding to launch via `command lock`
bind-key M4-t xterm # keybinding to launch directly
bind-key M4-l xlock # keybinding to launch directly
``
Run `cwm -n` to validate `~/.cwmrc`.
6. Restart `cwm` - press `CMS-r` (Ctrl + Alt + Shift + r)
7. As in #4, to check that the default keybindings work:
Press `CM-Return` (Ctrl + Alt + Enter) to launch `xterm`;
press `CM-Delete` (Ctrl + Alt + Delete) to lock screen with `xlock`
Press `4-t` (Windows + t) to try to launch xterm - NOPE.
Press `M4-t` (Alt + Windows + t) tolaunch xterm - yep.
Press `4-l` (Windows + l) to lock screen with `xlock` - yep.
Press `M4-l` (Alt + Windows + l) to lock screen with `xlock` - yep.
That's it.
8. Make `~/.cwmrc` look like this:
__
command term lxterminal # or any other terminal you have
command lock i3lock # or any other screen locker you have
bind-key 4-t term # keybinding to launch via `command term`
bind-key 4-l lock # keybinding to launch via `command lock`
bind-key M4-t lxterminal # keybinding to launch directly
bind-key M4-l i3lock # keybinding to launch directly
``
Run `cwm -n` to validate `~/.cwmrc`.
9. Restart `cwm` - `CMS-r` (Ctrl + Alt + Shift + r)
10. As in #4 & #7, to check that the default keybindings work:
Press `CM-Return` (Ctrl + Alt + Enter) to launch `lxterminal`;
press `CM-Delete` (Ctrl + Alt + Delete) to lock screen with `i3lock`
Press `4-t` (Windows + t) to try to launch lxterminal - NOPE.
Press `M4-t` (Alt + Windows + t) tolaunch lxterminal - yep.
Press `4-l` (Windows + l) to lock screen with `i3lock` - yep.
Press `M4-l` (Alt + Windows + l) to lock screen with `i3lock` - yep.
That's it again.
11. Restore your backupped `~/.cwmrc`
12. Restart `cwm` or replace it with your wm
dmesg:
OpenBSD 7.1 (GENERIC) #1: Tue May 3 08:27:33 MDT 2022
r...@syspatch-71-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem = 1055670272 (1006MB)
avail mem = 1019658240 (972MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 09/02/03, BIOS32 rev. 0 @ 0xfc03d, SMBIOS rev. 2.3 @
0xec000 (35 entries)
bios0: vendor TOSHIBA version "Version 1.30" date 09/02/2003
bios0: TOSHIBA Satellite A10
acpi0 at bios0: ACPI 2.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP DBGP BOOT
acpi0: wakeup devices MPC0(S3) MPC1(S3) LAN_(S4) VIY0(S3) USB1(S3) USB4(S3)
AMDM(S3) LID_(S4) PWRB(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PCIB)
"PNP0A03" at acpi0 not configured
acpicmos0 at acpi0
acpibtn0 at acpi0: LID_
acpibat0 at acpi0: BAT1 not present
acpibtn1 at acpi0: PWRB
acpiac0 at acpi0: AC unit online
acpitoshiba0 at acpi0
"TOS6202" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
acpipwrres0 at acpi0: PFAN, resource for FAN_
acpitz0 at acpi0: critical temperature is 109 degC
acpivideo0 at acpi0: VGA_
acpivout0 at acpivideo0: LCD_
bios0: ROM list: 0xc/0x1 0xe/0x1!
cpu0 at mainbus0: (uniprocessor)
cpu0: Mobile Intel(R) Pentium(R) 4 - M CPU 2.20GHz ("GenuineIntel" 686-class)
2.20 GHz, 0f-02-09
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,CNXT-ID,xTPR,PERF,MELTDOWN
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
0:30:0: bridge io address conflict
Re: [PATCH] Over-eager inclusion of man pages by makewhatis?
Hi Matthew, Matthew King wrote on Tue, May 24, 2022 at 07:57:31AM -: > While writing some documentation I noticed backup files turning up > in my mandoc.db and chased it down to what appears to be an oversight > when checking filename extensions in makewhatis. That is not an oversight be very intentional. > The current behaviour allows anything to follow the section name > part of each page's filename. Perhaps this is to allow compressed > manpages No, that is not related to compressed manual pages. Some other operating systems other than OpenBSD are in the habit of putting some manual pages into places like man1foo/name.1foo man1foo/name.1 man1/name.1foo and some use large numbers of different "foo" suffixes. Examples of such systems include Illumos and some Linux distributions that use mandoc. Since we keep the OpenBSD manual page trees very clean, supporting both clean paths like "man1foo/name.1foo" and unclean paths like "man1foo/name.1" and "man1/name.1foo" does not cause problems on OpenBSD. Also, i like to keep the mandoc code on OpenBSD and the portable version as close together as possible, both to ease maintenance and reduce the risk of bugs and at the same time to allow viewing the manual page trees of all supported systems on any supported system. For example, it is not unusual for me to look at the tree of FreeBSD manual pages, or to look at subtrees of manual pages from Linux distributions, while running OpenBSD. The code to support the various variants of such suffixed directory and file names has seen many iterations and fixes during the last few years. Touching it lightly is not a good idea because testing changes is very hard. It basically requires testing in real-world trees of several different operating systems. > but I couldn't find any overt reference to such a feature > in mandoc's documentation but rather it seemed to imply that the > section in the filename must exactly match that in the directory > name: > > The mandoc.db(5) database is used for looking up manual page > entries. In cases where the database is absent, outdated, or > corrupt, man falls back to looking for files called name.section. That is from the man(1) manual page. You might argue the statement is outdated because some years ago, man(1) also started showing files with suffixes if they exist. Then gain, it is an important goal to not overburden the man(1) manual page with implementation details and instead keep it concise and readable for beginners. So i would hesitate to spell out the full rules here regarding which files are accepted. On top of that, most systems that have unclean names like "man1foo/name.1" and "man1/name.1foo" do not particularly like these names themselves and would probably like to get rid of them and consistently use the clean form "man1foo/name.1foo", in which case the man(1) manual would be exact again. At least, i feel the man(1) manual should not give the impression of encouraging unclean names. > By default, makewhatis creates a database in each dir using > the files mansection/[arch/]title.section and > catsection/[arch/]title.0 in that directory. That is from makewhatis(8). More precise information could probably be added here with no significant downside. > The included patch fixes my issue by warning and rejecting a backup > file alongside a manpage's source but does so by changing the > behaviour of makewhatis to reject all files (by default) without a > precisely matching section name. The patch is not acceptable because it removes features that are intentionally supported and that various systems rely on. Besides, it is usually necessary to keep the makewhatis(8) lookup code in mandocdb.c in sync with the fallback lookup code of man(1) in main.c, and your patch touches only one of the two. It is not possible to make both lookup codes behave in exactly the same way because that would slow down man(1) too much, so there are a few subtle differences that can't be helped, but your change would make the two totally different, resulting in egregious inconsistencies in behaviour with and without mandoc,db files. Yours, Ingo
Re: [PATCH] Over-eager inclusion of man pages by makewhatis?
On 2022/05/24 14:17, Matthew King wrote: > > That strictness will break things for quite a lot of packages. > > I am open to suggestions for a better patch --- my original plan > was specifically to stop files ending in ~ but this route seemed like > a better idea once I'd seen the code and checked the documentaion. > > Are you sure though? The only file referenced in any PLIST that > doesn't match the directory it's in is a @comment in emulators/xnp2: > > @comment @man man/man1/xnp2.1j > > Also makewhatis already has the -a option which will include such > non-conforming files: > > -a Use all directories and files found below dir Playing with pkglocate man/man | grep I see various man#/somename.#[foxcp] It seems a bit unusual to have backup files in the directories where manuals are _installed_ to anyway though?
t460s laptop/Xorg freeze/crash when opening web browser/playing video in mpv
>Synopsis: Xorg freezes/crash when opening web browser or playing videos >in mpv. >Category: system kernel amd64 >Environment: System : OpenBSD 7.1 Details : OpenBSD 7.1-current (GENERIC.MP) #540: Sun May 22 10:09:33 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: I have been having this issue since around 6.9, I never took time to investigate it more deeply until now. What is happening: The screen freezes and becomes unresponsive to the keyboard, I can't switch to the terminals, nothing happens. The mouse continues to be responsive (it can move around but can't click or trigger any events). If the crash happens while a video/audio is playing, the audio continues playing fine. I am even able to ssh in my laptop after the crash and still access a prompt and that's where I just ran sendbug(1). Something weird is that I just ran sendbug(1) but the attached dmesg is missing key information, it shows the dmesg output before the crash, if I run dmesg now I see a few more lines than what is reported by sendbug(1), those are the missing lines: iridium[67539]: pledge "inet", syscall 97 __await_execution: stub __await_execution: stub __await_execution: stub Asynchronous wait on fence :Xorg[47164]:f74 timed out (hint:0x8133cd80s) After trying to make my computer freeze that way a few times, the "pledge" line only appeared once, after the previous freezes/crashes it didn't appear. The "__await_execution" lines doesn't necessarily appear on 3 lines, could be only 1 line or 2 lines as well. And the "Asynchronous wait.." line always appears last. I had the same issue on 2 completely different laptop (both t460s) with different motherboards, different hard drives etc... On the latest laptop it's a new OpenBSD install (1 day ago) on a hard drive that shows no issue in its S.M.A.R.T. data and the ram is fine since it passes the MemTest86 without errors. >How-To-Repeat: On a Thinkpad t460s, start iridium web browser, it's not consistent, sometimes it crashes, sometimes it doesn't. Sometimes the issues also arises when starting other webkitgtk web browsers. At other times my laptop freezes/crashes randomly in the same way while simply watching a video on mpv, sometimes I can watch a few episodes without any issues, sometimes it crashes half-way through the first episode I start watching. >Fix: I haven't found any way to stop this from happening... I will be really grateful for any help regarding this! dmesg: OpenBSD 7.1-current (GENERIC.MP) #540: Sun May 22 10:09:33 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8287989760 (7904MB) avail mem = 8019456000 (7647MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xcf081000 (65 entries) bios0: vendor LENOVO version "N1CET86W (1.54 )" date 12/06/2021 bios0: LENOVO 20FAS2WE1B acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI SSDT SSDT ECDT HPET APIC MCFG SSDT DBGP DBG2 BOOT BATB SLIC SSDT SSDT MSDM DMAR ASF! FPDT UEFI acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz, 1197.21 MHz, 06-4e-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz, 962.50 MHz, 06-4e-03 cpu1:
Re: boot froze after upgrade to 7.1
On 2022-05-24 5:44, anoduck wrote: > To: bugs@openbsd.org > Subject: froze after upgrade > From: anod...@protonmail.com > Cc: > Reply-To: anod...@protonmail.com > > >Synopsis:After upgrading to 7.1 from 7.0, system immediately froze after > >disk checks were successfully completed. > >Category:amd64, system > >Environment: > System : OpenBSD 7.1 > Details : OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 18:03:57 MDT > 2022 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > After successful upgrade to 7.1 to 7.0, system was rebooted. During the > boot process, immediately after the disks > were checked to ensure they were clean, the system froze up. The > keyboard was completely unresponsive, and the only > way of bringing down the machine was by performing a hard boot. The > system was booted again into single user mode with > debugging enabled, but this time with a filesystem marked dirty. The > filesystem was cleaned with `fsck` using the `-f` > flag. All partitions were successfully cleaned, and marked as such. > Regardless, the system still froze in exactly the > same location. > Fresh installation media was acquired in case of previous corruption, > and another upgrade was performed. Unfortunately, > this did not resolve the issue, and the system continued to fail during > boot. Finally, a fresh install using 7.1 was > performed on a usb storage device. When booted from this device, the > system continued to freeze in the exact same > location. > Realising this was an issue with hardware compatibility or driver, the > system was downgraded from 7.1 back to 7.0. This > downgrade booted successfully and allowed the system to get back online > and return to functionality. > It was then unclear how to further debug and diagnose the problem any > further, so a bug submission has been placed. > --> Please note: the filesystem was not marked clean during the > generation of this sendbug output. <-- This sounds very much like the issue I reported this weekend. https://marc.info/?t=16531222112=1=2 My solution was to boot the upgraded 7.1 system into single user mode, edit /etc/rc and comment out the following line: ttyflags -a this let the boot proceed for me. .jh > > >How-To-Repeat: > Since the error is assumed to have resulted from either loss of > hardware compatibility or driver error, a comparable system > will be needed in order to achieve the same results. The hardware for > the machine has remained the same for numerous years > and undergone numerous updates to OpenBSD releases. It still possesses > all the same hardware that came with it when originally > purchased from Best Buy as a Gateway GT5694. > >Fix: > Unknown > > SENDBUG: dmesg, pcidump, acpidump and usbdevs are attached. > SENDBUG: Feel free to delete or use the -D flag if they contain sensitive > information. > > dmesg: > OpenBSD 7.0 (GENERIC.MP) #232: Thu Sep 30 14:25:29 MDT 2021 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 4009295872 (3823MB) > avail mem = 3871764480 (3692MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f400 (29 entries) > bios0: vendor American Megatrends Inc. version "7B3P081G" date 05/05/2008 > bios0: Gateway GT5694 > acpi0 at bios0: ACPI 2.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC MCFG SLIC OEMB HPET ASF! > acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PCE7(S4) > PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) PS2K(S3) UAR1(S3) UAR2(S3) > P0PC(S4) UHC1(S3) [...] > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+, 2300.48 MHz, 0f-6b-02 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP > cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB > 64b/line 16-way L2 cache > cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative > cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 200MHz > cpu1 at mainbus0: apid 1 (application processor) > cpu1: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+, 2300.13 MHz, 0f-6b-02 > cpu1: >
Re: [External] : Re: ip6 forwarding with pf and pfsync over veb/vport
On 24.5.2022. 9:01, Alexandr Nedvedicky wrote:
> interesting. I went through mbuf handling in if_veb.c
> I just could find a single nit, which is most likely unrelated,
> however I think it's still worth to give it a try a diff below.
>
> basically all calls to veb_pf() read as follows:
> m = veb_pf(ifp, ..., m);
> except the one in veb_broadcast(), which readsa as:
> m = veb_pf(ifp, ..., m0);
> I think it is a bug, veb_pf() caller should continue to run
> with packet returned by veb_pf().
>
> thanks and
> regards
> sashan
Hi,
and with this diff i can panic box the same way as before... ip6
forwarding, pf and veb/vport
panic:
r620-1# panuicvm:_ f paoulotl(_0caxcffhfef_iftfeffm8_2ma2gfi13ca_c8h, e
ck :m bu f p
l cp uf r
e0ex1 7 , l i 0s,t 2 ) - > e
mkoedrnieflie: d : i t e m a dd r0 xf f f ff d 8 0 a 42 0 e
5 00 + 2 4 0x 6
a b 22 4 5 9 6 1e e 9 8 5c ! = 0 x 6 ab 2 2 4 5
9pcadge0 a f8 5 c
Stopped at db_enter+0x10: popq%rbp
TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
418374 46077 0 0x14000 0x2003 softnet
355064 80120 0 0x14000 0x2002K softnet
*401307 69853 0 0x14000 0x2005 softnet
db_enter() at db_enter+0x10
panic(81f3c6f5) at panic+0xbf
pool_cache_get(82483608) at pool_cache_get+0x25b
pool_get(82483608,2) at pool_get+0x61
m_get(2,1) at m_get+0x3f
m_copym(fd80a3b50900,0,40,2) at m_copym+0xd8
ip6_forward(fd80a3b50900,fd842ce9c708,0) at ip6_forward+0x1cc
ip6_input_if(800022c6b728,800022c6b734,29,0,8074b000) at
ip6_input_if+0x80a
ipv6_input(8074b000,fd80a3b50900) at ipv6_input+0x39
ether_input(8074b000,fd80a3b50900) at ether_input+0x3ad
vport_if_enqueue(8074b000,fd80a3b50900) at vport_if_enqueue+0x19
veb_port_input(80095048,fd80a3b50900,ecf4bbdaf7f8,80747300)
at veb_port_input+0x5b0
ether_input(80095048,fd80a3b50900) at ether_input+0x100
if_input_process(80095048,800022c6b938) at if_input_process+0x6f
end trace frame: 0x800022c6b980, count: 0
https://www.openbsd.org/ddb.html describes the minimum info required in
bug reports. Insufficient info makes it difficult to find and fix bugs.
ddb{5}> show panic
*cpu5: pool_cache_item_magic_check: mbufpl cpu free list modified: item
addr 0x
fd80a420e500+24 0x6ab2245961ee985c!=0x6ab22459cd0af85c
cpu2: uvm_fault(0x822f13a8, 0x17, 0, 2) -> e
ddb{5}>
Re: macppc panic: vref used where vget required
On 19/05/22(Thu) 13:33, Alexander Bluhm wrote:
> On Tue, May 17, 2022 at 05:43:02PM +0200, Martin Pieuchot wrote:
> > Andrew, Alexander, could you test this and report back?
>
> Panic "vref used where vget required" is still there. As usual it
> needs a day to reproduce. This time I was running without the vref
> history diff.
Thanks for testing. Apparently calling uvm_vnp_terminate() in
getnewvnode() isn't good enough. I suppose that in your case below the
pdaemon is trying to flush the pages before the vnode has been recycled,
so before uvm_vnp_terminate() has been called.
So either we prevent the vnode from being put on the free list or we get
rid of the persisting mechanism. I don't fully understand what could be
the impact of always flushing the pages and why this hasn't been done in
the first place. It seems the CANPERSIST logic has been"inherited from
44BSD's original vm.
On the other hand I feel even less comfortable with preventing vnodes
from being recycled until the pdaemon has freed related pages.
Diff below has been lightly tested, it get rids of the extra CANPERSIST
referenced. That means pages associated to a vnode will now always be
flushed when uvn_detach() is called. This turns uvm_vnp_uncache() into
a noop and open the possibility of further simplifications.
I'd be happy to hear if this has any impact of the bug we're chasing.
Please do note that this change can introduce/expose other issues.
Index: uvm/uvm_vnode.c
===
RCS file: /cvs/src/sys/uvm/uvm_vnode.c,v
retrieving revision 1.124
diff -u -p -r1.124 uvm_vnode.c
--- uvm/uvm_vnode.c 3 May 2022 21:20:35 - 1.124
+++ uvm/uvm_vnode.c 20 May 2022 09:04:08 -
@@ -162,12 +162,9 @@ uvn_attach(struct vnode *vp, vm_prot_t a
* add it to the writeable list, and then return.
*/
if (uvn->u_flags & UVM_VNODE_VALID) { /* already active? */
+ KASSERT(uvn->u_obj.uo_refs > 0);
rw_enter(uvn->u_obj.vmobjlock, RW_WRITE);
- /* regain vref if we were persisting */
- if (uvn->u_obj.uo_refs == 0) {
- vref(vp);
- }
uvn->u_obj.uo_refs++; /* bump uvn ref! */
rw_exit(uvn->u_obj.vmobjlock);
@@ -234,7 +231,7 @@ uvn_attach(struct vnode *vp, vm_prot_t a
KASSERT(uvn->u_obj.uo_refs == 0);
uvn->u_obj.uo_refs++;
oldflags = uvn->u_flags;
- uvn->u_flags = UVM_VNODE_VALID|UVM_VNODE_CANPERSIST;
+ uvn->u_flags = UVM_VNODE_VALID;
uvn->u_nio = 0;
uvn->u_size = used_vnode_size;
@@ -247,7 +244,7 @@ uvn_attach(struct vnode *vp, vm_prot_t a
/*
* add a reference to the vnode. this reference will stay as long
* as there is a valid mapping of the vnode. dropped when the
-* reference count goes to zero [and we either free or persist].
+* reference count goes to zero.
*/
vref(vp);
if (oldflags & UVM_VNODE_WANTED)
@@ -320,16 +317,6 @@ uvn_detach(struct uvm_object *uobj)
*/
vp->v_flag &= ~VTEXT;
- /*
-* we just dropped the last reference to the uvn. see if we can
-* let it "stick around".
-*/
- if (uvn->u_flags & UVM_VNODE_CANPERSIST) {
- /* won't block */
- uvn_flush(uobj, 0, 0, PGO_DEACTIVATE|PGO_ALLPAGES);
- goto out;
- }
-
/* its a goner! */
uvn->u_flags |= UVM_VNODE_DYING;
@@ -379,7 +366,6 @@ uvn_detach(struct uvm_object *uobj)
/* wake up any sleepers */
if (oldflags & UVM_VNODE_WANTED)
wakeup(uvn);
-out:
rw_exit(uobj->vmobjlock);
/* drop our reference to the vnode. */
@@ -495,8 +481,8 @@ uvm_vnp_terminate(struct vnode *vp)
}
/*
-* done. now we free the uvn if its reference count is zero
-* (true if we are zapping a persisting uvn). however, if we are
+* done. now we free the uvn if its reference count is zero.
+* however, if we are
* terminating a uvn with active mappings we let it live ... future
* calls down to the vnode layer will fail.
*/
@@ -504,14 +490,14 @@ uvm_vnp_terminate(struct vnode *vp)
if (uvn->u_obj.uo_refs) {
/*
* uvn must live on it is dead-vnode state until all references
-* are gone. restore flags.clear CANPERSIST state.
+* are gone. restore flags.
*/
uvn->u_flags &= ~(UVM_VNODE_DYING|UVM_VNODE_VNISLOCKED|
- UVM_VNODE_WANTED|UVM_VNODE_CANPERSIST);
+ UVM_VNODE_WANTED);
} else {
/*
* free the uvn now. note that the vref reference is already
-* gone [it is dropped when we enter the persist state].
+* gone.
Re: [PATCH] Over-eager inclusion of man pages by makewhatis?
That strictness will break things for quite a lot of packages. -- Sent from a phone, apologies for poor formatting. On 24 May 2022 08:58:46 "Matthew King" wrote: While writing some documentation I noticed backup files turning up in my mandoc.db and chased it down to what appears to be an oversight when checking filename extensions in makewhatis. The current behaviour allows anything to follow the section name part of each page's filename. Perhaps this is to allow compressed manpages but I couldn't find any overt reference to such a feature in mandoc's documentation but rather it seemed to imply that the section in the filename must exactly match that in the directory name: The mandoc.db(5) database is used for looking up manual page entries. In cases where the database is absent, outdated, or corrupt, man falls back to looking for files called name.section. And By default, makewhatis creates a database in each dir using the files mansection/[arch/]title.section and catsection/[arch/]title.0 in that directory. The included patch fixes my issue by warning and rejecting a backup file alongside a manpage's source but does so by changing the behaviour of makewhatis to reject all files (by default) without a precisely matching section name. I did not check filescan thoroughly enough to determine for sure whether it would also need a similar change but it doesn't look like it. I'm also not sure that I've got the indentation right. Cheers, Matthew ps. The diff is not included inline to avoid copy pasta issues as I have an unrelated problem which forces me to post through webmail.
Re: [External] : Re: ip6 forwarding with pf and pfsync over veb/vport
Hello Hrvoje, On Mon, May 23, 2022 at 06:34:07PM +0200, Hrvoje Popovski wrote: > On 23.5.2022. 10:41, Hrvoje Popovski wrote: > > On 23.5.2022. 8:34, Alexandr Nedvedicky wrote: > >> looks like kind of memory corruption. my bet is use-after-free. > >> will try to get to it later today. > >> > >> does it mean there is no such panic, when we handle IPv4 traffic only? > > > > Hi, > > > > yes, it seems that i can't trigger panic with ip4 only traffic, at least > > the same way i can with ip6 traffic > > > > All day I'm trying to trigger panic with ip4 and I just can't interesting. I went through mbuf handling in if_veb.c I just could find a single nit, which is most likely unrelated, however I think it's still worth to give it a try a diff below. basically all calls to veb_pf() read as follows: m = veb_pf(ifp, ..., m); except the one in veb_broadcast(), which readsa as: m = veb_pf(ifp, ..., m0); I think it is a bug, veb_pf() caller should continue to run with packet returned by veb_pf(). thanks and regards sashan 8<---8<---8<--8< diff --git a/sys/net/if_veb.c b/sys/net/if_veb.c index 67185fde228..30a002f95a2 100644 --- a/sys/net/if_veb.c +++ b/sys/net/if_veb.c @@ -944,7 +944,7 @@ veb_broadcast(struct veb_softc *sc, struct veb_port *rp, struct mbuf *m0, * let pf look at it, but use the veb interface as a proxy. */ if (ISSET(ifp->if_flags, IFF_LINK1) && - (m = veb_pf(ifp, PF_OUT, m0)) == NULL) + (m0 = veb_pf(ifp, PF_OUT, m0)) == NULL) return; #endif
