Bad news everyone,
gyes from GNU coreutils in ports seems to top out at ~185 MB/s when
writing to /dev/null on my otherwise idle laptop (per sysutils/pv from
ports):
$ doas nice -n -20 gyes | pv > /dev/null
921MiB 0:00:05 [ 185MiB/s] [<=> ]
1.80GiB
On Thu, Jun 17, 2021 at 08:41:39PM -0500, Scott Cheloha wrote:
> On Fri, Jun 11, 2021 at 12:17:02PM -0500, Scott Cheloha wrote:
> > Hi,
> >
> > setitimer(2) has a one hundred million second upper bound for timers.
> > Any timer interval larger than this is considered invalid and we set
> >
> Date: Fri, 18 Jun 2021 09:29:44 +0200
> From: Claudio Jeker
>
> On Thu, Jun 17, 2021 at 08:41:39PM -0500, Scott Cheloha wrote:
> > On Fri, Jun 11, 2021 at 12:17:02PM -0500, Scott Cheloha wrote:
> > > Hi,
> > >
> > > setitimer(2) has a one hundred million second upper bound for timers.
> > >
On Fri, Jun 18, 2021 at 09:29:44AM +0200, Claudio Jeker wrote:
> On Thu, Jun 17, 2021 at 08:41:39PM -0500, Scott Cheloha wrote:
> > On Fri, Jun 11, 2021 at 12:17:02PM -0500, Scott Cheloha wrote:
> > > Hi,
> > >
> > > setitimer(2) has a one hundred million second upper bound for timers.
> > > Any
On Tue, 15 Jun 2021 20:22:53 -0500, Scott Cheloha wrote:
> After that is committed, I'm unclear whether alarm(3) can fail anymore
> on OpenBSD. The only remaining plausible failure case I can see is
> EFAULT. But I'm unsure if that's possible. Can we get an EFAULT if
> both arguments point to
On Fri, Jun 18, 2021 at 07:18:53PM +0200, Alexander Bluhm wrote:
> On Thu, Jun 17, 2021 at 12:27:42PM +0300, Vitaliy Makkoveev wrote:
> > > Is this the correct version of the diff? Not tested yet.
>
> It survived a full regress run.
>
> > Hypothetically we could have the driver for the old NIC
I'm lurking in crypto(9) and I found 'cryptocap' structure has unused
members. Do we want to keep them or they could gone?
We don't export this structure so this diff doesn't break ABI.
Index: sys/crypto/crypto.c
===
RCS file:
On Fri, 18 Jun 2021 12:02:18 -0600, "Theo de Raadt" wrote:
> But I dislike this text since it doesn't speak to the underlying
> mechanism.
>
> The
> .Fn alarm
> function configures the process
> .Va ITIMER_REAL
> interval timer with
> .Xr setitimer 2
> to deliver a
> .Va SIGALRM
> signal in the
Todd C. Miller wrote:
> On Fri, 18 Jun 2021 12:02:18 -0600, "Theo de Raadt" wrote:
>
> > But I dislike this text since it doesn't speak to the underlying
> > mechanism.
> >
> > The
> > .Fn alarm
> > function configures the process
> > .Va ITIMER_REAL
> > interval timer with
> > .Xr setitimer 2
On Fri, 18 Jun 2021 12:13:54 -0600, "Theo de Raadt" wrote:
> I don't understand what you are solving.
>
> The way I look at it... you want to convert one kind of bug into a
> different kind of bug?
>
> In the end, the program quits, noone looks at the corefile, or is it
> in a privsep program and
Todd C. Miller wrote:
> On Fri, 18 Jun 2021 12:13:54 -0600, "Theo de Raadt" wrote:
>
> > I don't understand what you are solving.
> >
> > The way I look at it... you want to convert one kind of bug into a
> > different kind of bug?
> >
> > In the end, the program quits, noone looks at the
Scott Cheloha wrote:
> I want to improve the alarm(3) manpage. Here's a first attempt:
>
> - Correct the initial behavior description. alarm(3) does not "wait".
> It schedules signal delivery at a point in the future.
you are right about this.
> The
> .Fn alarm
> +function causes the
Scott Cheloha wrote:
> On Fri, Jun 18, 2021 at 09:15:31AM -0600, Todd C. Miller wrote:
> > On Tue, 15 Jun 2021 20:22:53 -0500, Scott Cheloha wrote:
> >
> > > After that is committed, I'm unclear whether alarm(3) can fail anymore
> > > on OpenBSD. The only remaining plausible failure case I can
On Thu, Jun 17, 2021 at 12:27:42PM +0300, Vitaliy Makkoveev wrote:
> > Is this the correct version of the diff? Not tested yet.
It survived a full regress run.
> Hypothetically we could have the driver for the old NIC which relies
> on disabled interrupts on this ioctl() sequence.
ifioctl()
Hi,
I want to improve the alarm(3) manpage. Here's a first attempt:
- Correct the initial behavior description. alarm(3) does not "wait".
It schedules signal delivery at a point in the future.
- If alarm(3) is not itself "asserting" the signal we need to specify
who the signal is
On Fri, Jun 18, 2021 at 09:15:31AM -0600, Todd C. Miller wrote:
> On Tue, 15 Jun 2021 20:22:53 -0500, Scott Cheloha wrote:
>
> > After that is committed, I'm unclear whether alarm(3) can fail anymore
> > on OpenBSD. The only remaining plausible failure case I can see is
> > EFAULT. But I'm
On Fri, Jun 18, 2021 at 12:46:38PM -0600, Theo de Raadt wrote:
> Todd C. Miller wrote:
>
> > On Fri, 18 Jun 2021 12:02:18 -0600, "Theo de Raadt" wrote:
> >
> > > But I dislike this text since it doesn't speak to the underlying
> > > mechanism.
> > >
> > > The
> > > .Fn alarm
> > > function
On Fri, 18 Jun 2021 16:27:36 -0500, Scott Cheloha wrote:
> Maybe this?
>
> The
> .Fn alarm
> function schedules the
> .Dv SIGALRM
> signal for delivery to the calling process after the given number of
> .Fa seconds
> have elapsed.
>
> I've also added a CAVEATS section.
>
> I've also tweaked the
On Fri, Jun 18, 2021 at 04:27:36PM -0500, Scott Cheloha wrote:
>
> I've also added a CAVEATS section.
>
> I've also tweaked the .Nd summary:
>
> .Nd schedule SIGALRM delivery
>
> Thoughts?
>
reads ok to me. one possible tweak inline:
> Index: alarm.3
>
On Fri, Jun 18, 2021 at 12:27:13PM -0600, Theo de Raadt wrote:
> Todd C. Miller wrote:
>
> > On Fri, 18 Jun 2021 12:13:54 -0600, "Theo de Raadt" wrote:
> >
> > > I don't understand what you are solving.
> > >
> > > The way I look at it... you want to convert one kind of bug into a
> > >
On Fri, 18 Jun 2021 16:02:20 -0500, Scott Cheloha wrote:
> If we're going to just return an arbitrary value shouldn't we keep
> returning UINT_MAX as we always have? This would preserve compat with
> the other BSD libc implementations, too.
I think that a return value of 0 is less likely to
Todd C. Miller wrote:
> On Fri, 18 Jun 2021 16:02:20 -0500, Scott Cheloha wrote:
>
> > If we're going to just return an arbitrary value shouldn't we keep
> > returning UINT_MAX as we always have? This would preserve compat with
> > the other BSD libc implementations, too.
>
> I think that a
On Fri, 18 Jun 2021 15:05:52 -0600, "Theo de Raadt" wrote:
> Without considering the cases where an incorrect value is passed in...
>
> How many pieces of code have you found that inspect the return value?
Very few. My concern is for those that use the return value when
determining how much
Todd C. Miller wrote:
> On Fri, 18 Jun 2021 15:17:47 -0600, "Theo de Raadt" wrote:
>
> > OK. How any pieces of code were found which do that?
> >
> > I mean, code search for ' = alarm('
>
> In our tree? Just ksh.
>
> static void
> alarm_catcher(int sig)
> {
> int errno_ = errno;
>
On Fri, 18 Jun 2021 15:22:05 -0600, "Theo de Raadt" wrote:
> Todd C. Miller wrote:
>
> > On Fri, 18 Jun 2021 15:17:47 -0600, "Theo de Raadt" wrote:
> >
> > > OK. How any pieces of code were found which do that?
> > >
> > > I mean, code search for ' = alarm('
> >
> > In our tree? Just ksh.
>
Todd C. Miller wrote:
> On Fri, 18 Jun 2021 15:05:52 -0600, "Theo de Raadt" wrote:
>
> > Without considering the cases where an incorrect value is passed in...
> >
> > How many pieces of code have you found that inspect the return value?
>
> Very few. My concern is for those that use the
On Fri, 18 Jun 2021 15:17:47 -0600, "Theo de Raadt" wrote:
> OK. How any pieces of code were found which do that?
>
> I mean, code search for ' = alarm('
In our tree? Just ksh.
static void
alarm_catcher(int sig)
{
int errno_ = errno;
if (ksh_tmout_state == TMOUT_READING) {
Hello,
skip reading if you are not interested in L2 switching combined
with bluhm's diff [1], which enables parallel forwarding.
Hrvoje gave it a try and soon discovered some panics. Diff below
fixes a panic indicated by stack as follows:
login: panic: kernel diagnostic assertion
28 matches
Mail list logo
