Re: [External] : pfsync mutex mpfloor

2022-04-13 Thread Alexandr Nedvedicky
On Wed, Apr 13, 2022 at 09:33:52PM +0200, Alexander Bluhm wrote:
> Hi,
> 
> Hrvoje has hit a witness issue in pfsync.
> 
> panic: acquiring blockable sleep lock with spinlock or critical
> section held (kernel_lock) _lock
> 
> panic(81f45bb7) at panic+0xbf
> witness_checkorder(8246e970,9,0) at witness_checkorder+0xb61
> __mp_lock(8246e768) at __mp_lock+0x5f
> kpageflttrap(800020b26dc0,17) at kpageflttrap+0x173
> kerntrap(800020b26dc0) at kerntrap+0x91
> alltraps_kern_meltdown() at alltraps_kern_meltdown+0x7b
> pfsync_q_del(fd875f6336c0) at pfsync_q_del+0x70
> pfsync_delete_state(fd875f6336c0) at pfsync_delete_state+0x118
> 
> pf and pfsync are running without kernel lock, so the mutexes
> must have at least mpfloor spl protection.
> 
> ok?
> 

looks correct to me.

OK sashan



Re: rate limit uvn_flush warning

2022-04-13 Thread Theo de Raadt
I think we should fix the bug and/or DELETE the message entirely



pfsync mutex mpfloor

2022-04-13 Thread Alexander Bluhm
Hi,

Hrvoje has hit a witness issue in pfsync.

panic: acquiring blockable sleep lock with spinlock or critical
section held (kernel_lock) _lock

panic(81f45bb7) at panic+0xbf
witness_checkorder(8246e970,9,0) at witness_checkorder+0xb61
__mp_lock(8246e768) at __mp_lock+0x5f
kpageflttrap(800020b26dc0,17) at kpageflttrap+0x173
kerntrap(800020b26dc0) at kerntrap+0x91
alltraps_kern_meltdown() at alltraps_kern_meltdown+0x7b
pfsync_q_del(fd875f6336c0) at pfsync_q_del+0x70
pfsync_delete_state(fd875f6336c0) at pfsync_delete_state+0x118

pf and pfsync are running without kernel lock, so the mutexes
must have at least mpfloor spl protection.

ok?

bluhm

Index: net/if_pfsync.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/net/if_pfsync.c,v
retrieving revision 1.302
diff -u -p -r1.302 if_pfsync.c
--- net/if_pfsync.c 7 Apr 2022 13:38:54 -   1.302
+++ net/if_pfsync.c 11 Apr 2022 15:51:16 -
@@ -315,7 +315,7 @@ pfsyncattach(int npfsync)
 {
if_clone_attach(_cloner);
pfsynccounters = counters_alloc(pfsyncs_ncounters);
-   mq_init(_mq, 4096, IPL_SOFTNET);
+   mq_init(_mq, 4096, IPL_MPFLOOR);
 }
 
 int
@@ -333,21 +333,21 @@ pfsync_clone_create(struct if_clone *ifc
sc = malloc(sizeof(*pfsyncif), M_DEVBUF, M_WAITOK|M_ZERO);
for (q = 0; q < PFSYNC_S_COUNT; q++)
TAILQ_INIT(>sc_qs[q]);
-   mtx_init_flags(>sc_st_mtx, IPL_SOFTNET, "st_mtx", 0);
+   mtx_init(>sc_st_mtx, IPL_MPFLOOR);
 
-   pool_init(>sc_pool, PFSYNC_PLSIZE, 0, IPL_SOFTNET, 0, "pfsync",
+   pool_init(>sc_pool, PFSYNC_PLSIZE, 0, IPL_MPFLOOR, 0, "pfsync",
NULL);
TAILQ_INIT(>sc_upd_req_list);
-   mtx_init(>sc_upd_req_mtx, IPL_SOFTNET);
+   mtx_init(>sc_upd_req_mtx, IPL_MPFLOOR);
TAILQ_INIT(>sc_deferrals);
-   mtx_init(>sc_deferrals_mtx, IPL_SOFTNET);
+   mtx_init(>sc_deferrals_mtx, IPL_MPFLOOR);
timeout_set_proc(>sc_deferrals_tmo, pfsync_deferrals_tmo, sc);
task_set(>sc_ltask, pfsync_syncdev_state, sc);
task_set(>sc_dtask, pfsync_ifdetach, sc);
sc->sc_deferred = 0;
 
TAILQ_INIT(>sc_tdb_q);
-   mtx_init(>sc_tdb_mtx, IPL_SOFTNET);
+   mtx_init(>sc_tdb_mtx, IPL_MPFLOOR);
 
sc->sc_len = PFSYNC_MINPKT;
sc->sc_maxupdates = 128;



rate limit uvn_flush warning

2022-04-13 Thread Alexander Bluhm
Hi,

If /usr fills up during relinking kernel, the console spits out
masses of these warnings.

uvn_flush: obj=0x0, offset=0x476.  error during pageout.
uvn_flush: WARNING: changes to page may be lost!
uvn_flush: obj=0x0, offset=0x476.  error during pageout.
uvn_flush: WARNING: changes to page may be lost!
uvn_flush: obj=0x0, offset=0x476.  error during pageout.
uvn_flush: WARNING: changes to page may be lost!

The machine becomes unusable for several minutes.

I think we should rate limit the printf.  As this is not a hot path,
kernel lock seems best to protect struct timeval lasttime.

ok?

bluhm

Index: uvm/uvm_vnode.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/uvm/uvm_vnode.c,v
retrieving revision 1.121
diff -u -p -r1.121 uvm_vnode.c
--- uvm/uvm_vnode.c 15 Dec 2021 12:53:53 -  1.121
+++ uvm/uvm_vnode.c 13 Apr 2022 15:10:40 -
@@ -744,7 +744,7 @@ ReTry:
 */
 #ifdef DIAGNOSTIC
if (flags & PGO_SYNCIO)
-   panic("uvn_flush: PGO_SYNCIO return 'try again' error (impossible)");
+   panic("%s: PGO_SYNCIO return 'try again' error (impossible)", __func__);
 #endif
flags |= PGO_SYNCIO;
if (flags & PGO_FREE)
@@ -808,14 +808,22 @@ ReTry:
} else if (flags & PGO_FREE &&
result != VM_PAGER_PEND) {
if (result != VM_PAGER_OK) {
-   printf("uvn_flush: obj=%p, "
-  "offset=0x%llx.  error "
-  "during pageout.\n",
-   pp->uobject,
-   (long long)pp->offset);
-   printf("uvn_flush: WARNING: "
-   "changes to page may be "
-   "lost!\n");
+   static struct timeval lasttime;
+   static const struct timeval interval =
+   { 5, 0 };
+
+   KERNEL_LOCK()
+   if (ratecheck(, )) {
+   printf("%s: obj=%p, "
+  "offset=0x%llx.  error "
+  "during pageout.\n",
+   __func__, pp->uobject,
+   (long long)pp->offset);
+   printf("%s: WARNING: "
+   "changes to page may be "
+   "lost!\n", __func__);
+   }
+   KERNEL_UNLOCK()
retval = FALSE;
}
pmap_page_protect(ptmp, PROT_NONE);



OpenBGPD 7.3 released

2022-04-13 Thread Claudio Jeker
We have released OpenBGPD 7.3, which will be arriving in the
OpenBGPD directory of your local OpenBSD mirror soon.

This release includes the following changes to the previous release:

* Macro expansion in the config file is improved. It is now possible
  to expand 'set large-community $myAS:$location:$transit'.

* Add initial FIB support for Linux. Routes can be added and removed.
  Nexthop tracking and dynamic interface detection are not yet implemented. 

* Major refactoring in the RIB codebase to add multipath support in
  an upcoming release.

OpenBGPD-portable is known to compile and run on FreeBSD, and
the Linux distributions Alpine, Debian, Fedora, RHEL/CentOS and Ubuntu.
It is our hope that packagers take interest and help adapt OpenBGPD-portable
to more distributions.

We welcome feedback and improvements from the broader community.
Thanks to all of the contributors who helped make this release
possible.



Re: const openpty et al.

2022-04-13 Thread Theo Buehler
On Thu, Apr 07, 2022 at 06:11:45PM -0500, Matthew Martin wrote:
> const the termp and winp arguments for openpty and related. This matches
> the prototypes for openpty and forkpty in glibc and musl libc.

This looks correct to me. I ran this through an amd64 bulk with no
fallout.

ok tb