On Fri, Nov 15, 2019 at 06:06:42PM +0100, Remi Locherer wrote:
> On Mon, Nov 04, 2019 at 02:01:57PM +0200, Kapetanakis Giannis wrote:
> > On 25/10/2019 13:57, Remi Locherer wrote:
> > > Hi tech@,
> > >
> > > earlier this year I sent a diff that allowed to change an interface
> > > from broadcast
On Mon, Nov 04, 2019 at 02:01:57PM +0200, Kapetanakis Giannis wrote:
> On 25/10/2019 13:57, Remi Locherer wrote:
> > Hi tech@,
> >
> > earlier this year I sent a diff that allowed to change an interface
> > from broadcast to point-to-point.
> >
> >
Hello,
> > Here are three patches fixing small issues in configuration handling.
> > I hope the patch format is ok for the list, thanks for your time!
>
> Just making sure those weren't lost during the release period.
No interest there?
Hello,
> > Now I had a look at our cp.c, our cp(1) and at POSIX:
> >
> > -f For each existing destination pathname, remove it and
> > create a new file, without prompting for confirmation, regardless of
> > its permissions. The -f option overrides any previous -i options.
> >
> > POSIX says
Hi,
here's another improvement for iked logging.
The diff adds a new print when a new flow is enabled and when a new pair
of child SAs is loaded into the kernel:
0xf172af722de8de1a: recv IKE_AUTH res 1 peer 10.0.1.34:500 local 10.0.1.33:500,
516 bytes, policy 'test'
spi=0xf172af722de8de1a:
> I'm sorry, it was a bit irresponsible of me to put msg_sa everywhere
> in my diff. In fact, almost all of the code in this file uses 'sa'
> so it would be consistent with other functions if 'sa' would be used
> instead of 'msg_sa'. If you don't mind changing it to 'sa', I would
> appreciate
On Fri, Nov 15 2019 15:24:57 +0200, Lauri Tirkkonen wrote:
> Your points are valid and I agree with them completely. There are
> clearly problems with lock contention,
and I should mention here that I would probably not have observed the
magnitude of these problems had I not made make start more
On Fri, Nov 15 2019 14:16:44 +0100, Martin Pieuchot wrote:
> > Yes, that was my point exactly. Less jobs didn't fare any better (well,
> > it had less spin time, but took around the same real time), so the
> > conclusion I arrived at was that something in my setup was eventually
> > contending on
On 15/11/19(Fri) 15:03, Lauri Tirkkonen wrote:
> On Thu, Nov 14 2019 17:57:20 +0100, Martin Pieuchot wrote:
> > On 14/11/19(Thu) 17:30, Lauri Tirkkonen wrote:
> > > [...]
> > > The first test I made was on a beefy virtual machine under Hyper-V,
> > > with 32 vCPUs on a Threadripper 2950X. With
Hi Martin,
On Thu, Nov 14 2019 17:57:20 +0100, Martin Pieuchot wrote:
> On 14/11/19(Thu) 17:30, Lauri Tirkkonen wrote:
> > [...]
> > The first test I made was on a beefy virtual machine under Hyper-V,
> > with 32 vCPUs on a Threadripper 2950X. With and without this patch (and
> > the followup
On 14/11/19(Thu) 17:30, Lauri Tirkkonen wrote:
> [...]
> The first test I made was on a beefy virtual machine under Hyper-V,
> with 32 vCPUs on a Threadripper 2950X. With and without this patch (and
> the followup for share/mk), I did make -j32 -C /usr/src/usr.bin. The
> results were very
Tobias Heider writes:
> On Thu, Nov 14, 2019 at 09:57:27AM -0700, Theo de Raadt wrote:
>> >
>> > The problem here is that log_warn can change errno,
>>
>> No, it specifically avoids touching errno.
>>
>> log_warn(const char *emsg, ...)
>> {
>> char*nfmt;
>>
12 matches
Mail list logo
