Re: pluart(4): fifo support

On Sun, May 01, 2022 at 04:17:34PM +, Visa Hankala wrote: > On Sat, Apr 30, 2022 at 09:40:24AM +0200, Anton Lindqvist wrote: > > On Sun, Mar 13, 2022 at 04:17:07PM +0100, Mark Kettenis wrote: > > > > Date: Fri, 11 Mar 2022 07:53:13 +0100 > > > > From: Anton Lindqvist > > > > > > > > On Tue, M

Re: unlock pf_purge

Hello, I like this change and I think this should go in as-is. This is OK sashan@ I also think we should revisit a pf.conf(5) manpage where 'interval' (PFTM_INTERVAL) is described. It currently reads as follows: set timeout variable value frag Seconds before an unassemble

Re: bgpd, fix some rtlabel leaks

On Tue, Jun 07, 2022 at 06:21:37PM +0200, Theo Buehler wrote: > On Tue, Jun 07, 2022 at 05:49:53PM +0200, Claudio Jeker wrote: > > The kroute code can leak rtlabel references in various conditions. > > In the end we want to drop the reference before free(). > > So move the unref into kroute_remove(

Re: bgpd, fix some rtlabel leaks

On Tue, Jun 07, 2022 at 05:49:53PM +0200, Claudio Jeker wrote: > The kroute code can leak rtlabel references in various conditions. > In the end we want to drop the reference before free(). > So move the unref into kroute_remove() so it is done mostly in one place. > On top fix a few other places w

Re: bgpd, retire F_RTLABEL flag

On Tue, Jun 07, 2022 at 05:47:52PM +0200, Theo Buehler wrote: > On Tue, Jun 07, 2022 at 05:09:30PM +0200, Claudio Jeker wrote: > > The F_RTLABEL flag does nothing. So just remove it. > > Checking the rtlabelid != 0 is equivalent. > > Doesn't twiddling the F_RTLABEL potentially change the outcome o

bgpd, fix some rtlabel leaks

The kroute code can leak rtlabel references in various conditions. In the end we want to drop the reference before free(). So move the unref into kroute_remove() so it is done mostly in one place. On top fix a few other places where kroutes are freed. This diff is on top of the previous diff (re

Re: bgpd, retire F_RTLABEL flag

On Tue, Jun 07, 2022 at 05:09:30PM +0200, Claudio Jeker wrote: > The F_RTLABEL flag does nothing. So just remove it. > Checking the rtlabelid != 0 is equivalent. Doesn't twiddling the F_RTLABEL potentially change the outcome of the two if (flags != oflags) changed = 1; bi

bgpd, retire F_RTLABEL flag

The F_RTLABEL flag does nothing. So just remove it. Checking the rtlabelid != 0 is equivalent. -- :wq Claudio Index: bgpd.h === RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v retrieving revision 1.426 diff -u -p -r1.426 bgpd.h --- bgpd.h

Re: unlock pf_purge

On 2022/06/07 16:58, David Gwynne wrote: > the main change here is to move pf_purge out from under the kernel lock. > > another part of the change is to limit the amount of work the state > purging does to avoid hogging a cpu too much, and to also avoid holding > NET_LOCK for too long. I'm runnin

Re: @extraunexec usage in pkg_add

On 2022/06/07 09:36, Marc Espie wrote: > I propose eventually replacing them with > @extraglob pattern Very definitely makes sense. So we can avoid surprises if/when we do this, if some developer is using packages from the wrong architecture as part of their workflow please check if those packag

Re: potential memory leak in if_vinput()

On Tue, Jun 07, 2022 at 02:23:07AM +0200, Alexandr Nedvedicky wrote: > Hello, > > I've spotted this glitch while hunting down use after-free > in 'veb' packet path. I believe the issue is rather hypothetical, > there is no evidence the deemed memory leak ever occurred. > > Anyway I believe the if

@extraunexec usage in pkg_add

I've conducted a quick audit of the 300 or so uses of @extraunexec in pkg_add. All but 5 are actually glorified versions of rm -rf I propose eventually replacing them with @extraglob pattern with several advantages: - we have file names that we know - perl itself can expand the glob and dec