On Thu, Dec 24, 2020 at 12:24:01AM +0100, Patrick Wildt wrote:
> Am Wed, Dec 23, 2020 at 05:04:23PM -0600 schrieb Scott Cheloha:
> > On Wed, Dec 23, 2020 at 02:42:18PM -0700, Theo de Raadt wrote:
> > > I agree. This chunk below is really gross and does not follow the
> > > special wakeup channel
Am Wed, Dec 23, 2020 at 11:32:58PM +0100 schrieb Frederic Cambus:
> Hi Mark,
>
> On Fri, Dec 18, 2020 at 10:33:52PM +0100, Mark Kettenis wrote:
>
> > The diff below disables the optimized functions on little-endian
> > architectures such that we always use rasops1_putchar(). This makes
> >
Am Wed, Dec 23, 2020 at 05:04:23PM -0600 schrieb Scott Cheloha:
> On Wed, Dec 23, 2020 at 02:42:18PM -0700, Theo de Raadt wrote:
> > I agree. This chunk below is really gross and does not follow the
> > special wakeup channel metaphor.
> >
> > It is *entirely clear* that a called "nowake" has
On Wed, Dec 23, 2020 at 02:42:18PM -0700, Theo de Raadt wrote:
> I agree. This chunk below is really gross and does not follow the
> special wakeup channel metaphor.
>
> It is *entirely clear* that a called "nowake" has no wakeup.
> Like duh.
>
> > +/*
> > + * nowake is a global sleep channel
Hi Mark,
On Fri, Dec 18, 2020 at 10:33:52PM +0100, Mark Kettenis wrote:
> The diff below disables the optimized functions on little-endian
> architectures such that we always use rasops1_putchar(). This makes
> ssdfb(4) work with the default 8x16 font on arm64.
I noticed it was committed
On 2020/12/15 17:49, Florian Obser wrote:
>
>
> On 15 December 2020 14:56:41 CET, Stuart Henderson
> wrote:
> >On 2020/12/15 10:18, Solene Rapenne wrote:
> >> This is a small change to acme-client(1) because I find
> >> the explanation of -F flag not being obvious that you
> >> need it when
On 2020/12/23 18:09, Florian Obser wrote:
> First fulfil all challenges then tell the CA that it should check.
>
> With a CSR with multiple SANs acme-client would write one challenge,
> tell the CA, write the next challenge and so on.
>
> For http-01 this doesn't matter but I think this will be
I agree. This chunk below is really gross and does not follow the
special wakeup channel metaphor.
It is *entirely clear* that a called "nowake" has no wakeup.
Like duh.
> +/*
> + * nowake is a global sleep channel for threads that do not want
> + * to receive wakeup(9) broadcasts.
> + */
>
> Date: Wed, 23 Dec 2020 14:59:02 -0600
> From: Scott Cheloha
>
> Okay, let's try one more time.
>
> This patch adds a global sleep channel, "nowake", for sleeping threads
> that don't want to receive wakeup(9) broadcasts.
>
> You use it like this:
>
> #include
>
>
On Tue, Dec 15, 2020 at 09:15:31AM -0300, Martin Pieuchot wrote:
> On 11/12/20(Fri) 19:17, Scott Cheloha wrote:
> > Here's another sleep that doesn't need lbolt.
> >
> > The idea here is to call apm_periodic_check() once a second.
> > We can do that without lbolt.
> >
> > Is there some other
Okay, let's try one more time.
This patch adds a global sleep channel, "nowake", for sleeping threads
that don't want to receive wakeup(9) broadcasts.
You use it like this:
#include
tsleep(nowake, ...);
I've added additional assertions to tsleep, msleep, and rwsleep that
On 23.12.2020. 18:24, Mark Kettenis wrote:
> Diff below switches the i386 pmap to use the modern km_alloc(9)
> functions and uses IPL_VM for the pmap pool, following the example of
> amd64.
>
> Don't have easy access to an i386 machine right now, so this has only
> been compile tested.
>
> ok
enc(4) does not use the ifqueue API at all; IPsec packets are directly
transformed in the IP input/output routines.
enc_start() is never called (by design) so I'd like to remove it for
clarity - similar to lo(4) does not have a start routine defined either.
Tested with various iked(8) tunnels
Diff below switches the i386 pmap to use the modern km_alloc(9)
functions and uses IPL_VM for the pmap pool, following the example of
amd64.
Don't have easy access to an i386 machine right now, so this has only
been compile tested.
ok (if it works)?
Index: arch/i386/i386/pmap.c
On Fri, Dec 11, 2020 at 05:32:54PM -0600, Scott Cheloha wrote:
> On Fri, Dec 11, 2020 at 07:52:45PM +0100, Mark Kettenis wrote:
> > > Date: Fri, 11 Dec 2020 11:51:54 -0600
> > > From: Scott Cheloha
> > >
> > > On Fri, Dec 11, 2020 at 09:49:07AM -0300, Martin Pieuchot wrote:
> > > >
> > > > I'm
On Wed, 23 Dec 2020 17:35:36 +0100
Patrick Wildt wrote:
> Am Wed, Dec 23, 2020 at 10:44:21AM +0100 schrieb Marcus Glocker:
> > On Wed, 23 Dec 2020 09:47:44 +0100
> > Marcus Glocker wrote:
> >
> > > On Tue, 22 Dec 2020 20:55:41 +0100
> > > Marcus Glocker wrote:
> > >
> > > > > > Did you
First fulfil all challenges then tell the CA that it should check.
With a CSR with multiple SANs acme-client would write one challenge,
tell the CA, write the next challenge and so on.
For http-01 this doesn't matter but I think this will be nicer for dns-01
because there are propagation delays
The following diff:
* renames existing functions klist_insert() and klist_remove() to
klist_insert_locked() and klist_remove_locked(), respectively.
These functions expect that the caller has acquired the klist lock.
* adds new functions klist_insert() and klist_remove() that acquire the
Am Wed, Dec 23, 2020 at 10:44:21AM +0100 schrieb Marcus Glocker:
> On Wed, 23 Dec 2020 09:47:44 +0100
> Marcus Glocker wrote:
>
> > On Tue, 22 Dec 2020 20:55:41 +0100
> > Marcus Glocker wrote:
> >
> > > > > Did you consider incrementing xx->ntrb instead?
> > >
> > > >That doesn't work
On Wed, Dec 23, 2020 at 04:13:04PM +0100, Alexander Bluhm wrote:
> On Wed, Dec 16, 2020 at 05:24:50PM +0100, Claudio Jeker wrote:
> > On Wed, Dec 16, 2020 at 03:54:04PM +, Stuart Henderson wrote:
> > > On 2020/12/16 16:43, Salvatore Cuzzilla wrote:
> > > > Hi folks,
> > > >
> > > > is there
On Wed, Dec 16, 2020 at 05:24:50PM +0100, Claudio Jeker wrote:
> On Wed, Dec 16, 2020 at 03:54:04PM +, Stuart Henderson wrote:
> > On 2020/12/16 16:43, Salvatore Cuzzilla wrote:
> > > Hi folks,
> > >
> > > is there any process associated with this netstat record?
> > > btw, what's the meaning
> Date: Wed, 23 Dec 2020 10:58:16 -0300
> From: Martin Pieuchot
>
> On 22/12/20(Tue) 23:43, Mark Kettenis wrote:
> > > Date: Mon, 21 Dec 2020 16:46:32 -0300
> > > From: Martin Pieuchot
> > >
> > > During a page fault multiples counters are updated. They fall into two
> > > categories "fault
In bgpd statements like
network inet static
or
network rtlabel "exportme"
will skip routes that use 127.0.0.1 as nexthop. This makes sense for
network connected and network static but for rtlabel and even priority
based selection this makes less sense.
Especially using rtlabel to
On 22/12/20(Tue) 23:43, Mark Kettenis wrote:
> > Date: Mon, 21 Dec 2020 16:46:32 -0300
> > From: Martin Pieuchot
> >
> > During a page fault multiples counters are updated. They fall into two
> > categories "fault counters" and "global statistics" both of which are
> > currently represented by
On 23/12/20(Wed) 07:18, Visa Hankala wrote:
> This fixes a recent regression in kqueue_scan() where the function can
> mistakenly return EWOULDBLOCK.
>
> Currently, kqueue_scan() does one more scan attempt after a timeout.
> Usually, this gives no new events and the function bails out through
>
On 2020/12/17 20:50, Jan Klemkow wrote:
> ping
>
> On Fri, Nov 06, 2020 at 01:10:52AM +0100, Jan Klemkow wrote:
> > Hi,
> >
> > bluhm and I make some network performance measurements and kernel
> > profiling.
I've been running this on my workstation since you sent it out - lots
of long-running
Hello,
The following diff plugs a memory leak in regex lookups.
Cheers,
diff --git a/usr.sbin/smtpd/table.c b/usr.sbin/smtpd/table.c
index 4691..d1578403 100644
--- a/usr.sbin/smtpd/table.c
+++ b/usr.sbin/smtpd/table.c
@@ -470,6 +470,7 @@ table_regex_match(const char *string, const char
On Wed, Dec 23, 2020 at 12:35:46PM +0800, Kevin Lo wrote:
> Hi,
>
> This diff implements WoL support in rge(4). I can wakeup the machine with WoL
> after suspending it through `zzz` or powering off it through `halt -p`.
Thanks! This works as expected in my testing.
-Otto
>
> Index:
On Wed, 23 Dec 2020 09:47:44 +0100
Marcus Glocker wrote:
> On Tue, 22 Dec 2020 20:55:41 +0100
> Marcus Glocker wrote:
>
> > > > Did you consider incrementing xx->ntrb instead?
> >
> > >That doesn't work either, because the status completion code needs
> > >xx->ntrb to be correct for the
On Tue, 22 Dec 2020 20:55:41 +0100
Marcus Glocker wrote:
> > > Did you consider incrementing xx->ntrb instead?
>
> >That doesn't work either, because the status completion code needs
> >xx->ntrb to be correct for the data TD to be handled correctly.
> >Incrementing xx->ntrb means the number
Committed, thanks.
On Wed, 2020-12-23 at 08:54 +0100, Gilles CHEHADE wrote:
> Hello,
>
> The following diff plugs a memory leak in regex lookups.
>
> Cheers,
>
>
> diff --git a/usr.sbin/smtpd/table.c b/usr.sbin/smtpd/table.c
> index 4691..d1578403 100644
> --- a/usr.sbin/smtpd/table.c
>
31 matches
Mail list logo
