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 "smr->smr_f
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, 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 .N
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 confi
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: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: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) {
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 retur
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 time
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 re
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 caus
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
> > > differen
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: /cvs/s
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 w
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: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 fu
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 corefi
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
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 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 unsur
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 async
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 delivered
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() cal
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 s
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 t
> 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.
> > > An
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
> > EINVAL.
27 matches
Mail list logo
