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.
>
> There is no longer any reason to use this particular limit. Kclock
On Thu, Jun 17, 2021 at 9:48 AM Otto Moerbeek wrote:
> On Thu, Jun 17, 2021 at 10:01:02AM -0600, Gavin Howard wrote:
>
> > Otto,
> >
> > > I think it is interesting. As for the incompatibilites, my memory says
> > > I followed the original dc and bc when deciding on those (GNU chose to
> > >
it's perhaps worth mentioning in the "pros" column that toybox (a
0BSD-licensed busybox which provides most of /bin on Android, which i
maintain) and busybox both use Gavin's bc/dc implementations[1]. so
although the GNU versions are their own thing and i assume likely to stay
that way, "all
Mr. de Raadt,
> Eyes will usually look at the version they are used to, and any effort
> to shink the number of versions will probably fail to re-adapt those
> eyes towards looking at another version with the same focus, as they are
> not familiar with the replacement.
I think you are correct
On Thu, Jun 17, 2021 at 12:07:10PM -0400, Dave Voutila wrote:
>
> Dave Voutila writes:
>
> > The virtio spec has had a de facto command for drivers to read the
> > serial number off a virtual block device. QEMU introduced this feature
> > years ago. Last November, the virtio governing group voted
enh wrote:
> heh. while i know what Theo means -- and his is also a valid philosophical
> standpoint -- this kind of thing is one reason why i personally prefer
> fewer implementations of things and more shared code between them :-)
>
> at least it leads to more consistency, and to having fewer
Having fewer versions of software is not neccessarily a plus.
It is easily considered a negative.
enh wrote:
> it's perhaps worth mentioning in the "pros" column that toybox (a
> 0BSD-licensed busybox which provides most of /bin on Android, which i
> maintain) and busybox both use Gavin's
On Thu, Jun 17, 2021 at 10:01:02AM -0600, Gavin Howard wrote:
> Otto,
>
> > I think it is interesting. As for the incompatibilites, my memory says
> > I followed the original dc and bc when deciding on those (GNU chose to
> > differs in these cases). Bit it has been 18 years since I wrote the
>
Dave Voutila writes:
> The virtio spec has had a de facto command for drivers to read the
> serial number off a virtual block device. QEMU introduced this feature
> years ago. Last November, the virtio governing group voted in favor of
> adopting it officially into v1.2 (the next virtio spec)
Otto,
> I think it is interesting. As for the incompatibilites, my memory says
> I followed the original dc and bc when deciding on those (GNU chose to
> differs in these cases). Bit it has been 18 years since I wrote the
> current versions, so I might misrememeber.
I think that makes sense to
On Thu, Jun 17, 2021 at 01:40:01PM +, Job Snijders wrote:
> On Thu, Jun 17, 2021 at 03:29:38PM +0200, Claudio Jeker wrote:
> > On Thu, Jun 17, 2021 at 01:25:07PM +, Job Snijders wrote:
> > > On Thu, Jun 17, 2021 at 12:24:16PM +0200, Claudio Jeker wrote:
> > > > On Mon, Jun 14, 2021 at
Disabled by default is a good start.
OK job@
On Thu, Jun 17, 2021 at 03:19:11PM +0200, Alexander Bluhm wrote:
> On Thu, Jun 17, 2021 at 10:09:47AM +0200, Martin Pieuchot wrote:
> > It's not clear to me which field is the KERNEL_LOCK() protecting. Is it
> > the access to `swcr_sessions'? Is it a reference? If so grabbing/releasing
> > the
On Thu, Jun 17, 2021 at 03:29:38PM +0200, Claudio Jeker wrote:
> On Thu, Jun 17, 2021 at 01:25:07PM +, Job Snijders wrote:
> > On Thu, Jun 17, 2021 at 12:24:16PM +0200, Claudio Jeker wrote:
> > > On Mon, Jun 14, 2021 at 05:10:07PM +0200, Claudio Jeker wrote:
> > > > On Thu, May 27, 2021 at
On Thu, Jun 17, 2021 at 01:25:07PM +, Job Snijders wrote:
> On Thu, Jun 17, 2021 at 12:24:16PM +0200, Claudio Jeker wrote:
> > On Mon, Jun 14, 2021 at 05:10:07PM +0200, Claudio Jeker wrote:
> > > On Thu, May 27, 2021 at 06:24:06PM +0200, Claudio Jeker wrote:
> > > > Implement RFC 7313 enhanced
On Thu, Jun 17, 2021 at 12:24:16PM +0200, Claudio Jeker wrote:
> On Mon, Jun 14, 2021 at 05:10:07PM +0200, Claudio Jeker wrote:
> > On Thu, May 27, 2021 at 06:24:06PM +0200, Claudio Jeker wrote:
> > > Implement RFC 7313 enhanced route refresh.
> > >
> > > While there also change when graceful
On Thu, Jun 17, 2021 at 10:09:47AM +0200, Martin Pieuchot wrote:
> It's not clear to me which field is the KERNEL_LOCK() protecting. Is it
> the access to `swcr_sessions'? Is it a reference? If so grabbing/releasing
> the lock might not be enough to fix the use-after-free.
I am running the fix
On 6/15/21 4:33 PM, dz...@disroot.org wrote:
> If it only needs access to its lock file,
> why should I give it access to my ssh keys?
I think that it is worth understanding that you can use file and process
permissions, for that.
Unveil is an extra layer, because no matter what ssh key you
On Wed, Jun 16, 2021 at 11:40:08PM -0600, Gavin Howard wrote:
> Hello,
>
> My name is Gavin Howard. I have developed a new bc(1) and dc(1)
> implementation. [0]
>
> I propose replacing the current implementations with mine.
>
> Advantages:
>
> * Performance. [1]
> * Extensions for ease of
On Mon, Jun 14, 2021 at 05:10:07PM +0200, Claudio Jeker wrote:
> On Thu, May 27, 2021 at 06:24:06PM +0200, Claudio Jeker wrote:
> > Implement RFC 7313 enhanced route refresh.
> >
> > While there also change when graceful restart EoR markers are sent.
> > In short the graceful restart marker
On Thu, Jun 17, 2021 at 02:03:03AM +0200, Alexander Bluhm wrote:
> Thanks dlg@ for the hint with the ixl(4) fixes in current. I will
> try so solve my 6.6 problem with that.
>
> On Wed, Jun 16, 2021 at 10:19:03AM +0200, Martin Pieuchot wrote:
> > The diff discussed in this thread reduces the
To not recreate the issue of missing another check in one of the
up_generate_updates() call points factor out the common code into
rde_skip_peer().
I hope this way a similar f-up can be avoided
--
:wq Claudio
? obj
Index: rde.c
===
On 16/06/21(Wed) 22:05, Alexander Bluhm wrote:
> Hi,
>
> I have seen a kernel crash with while forwarding and encrypting
> much traffic through OpenBSD IPsec gateways running iked.
>
> kernel: protection fault trap, code=0
> Stopped at aes_ctr_crypt+0x1e: addb$0x1,0x2e3(%rdi)
>
>
dlg@ asked me for an example output, so here it is:
07:52:52.326084 fe80::fce1:baff:fed2:8886.dhcpv6-client >
ff02::1:2.dhcpv6-server: [udp sum ok] DHCPv6 Solicit xid 0xdc0732
OPTION_CLIENTID: 00:01:00:01:28:5c:b7:1e:e8:6a:64:e8:d5:3f
OPTION_ELAPSED_TIME: 0.00s
24 matches
Mail list logo
