On Fri, Jul 3, 2020 at 11:47 AM Klemens Nanni wrote:
> Is there any particular reason why an interface's *public* key is only
> shown to the root user in ifconfig?
Yes, there is a reason for this.
The WireGuard protocol has a property called "identity hiding". See
section 3.4 and 4.3.4 lemma 7 o
Hi,
I want to run the lapic timer in one-shot mode on amd64 as we do with
other interrupt clocks on other platforms. I aim to make the clock
interrupt code MD where possible.
However, nobody is going to test my MD clock interrupt work unless
amd64 is ready to use it. amd64 doesn't run in onesho
On 2020-07-03, Scott Cheloha wrote:
> Are we doing powerpc, arm64, and sparc64 separately?
hppa can de done as well, but somebody with access to a machine
needs to investigate/ensure that the S bit in the processor status
register is appropriately set to allow userland access to the
Interval Tim
Mark Kettenis wrote:
> I did not add the LFENCE to tc_get_timecount() itself. We probably
> should, but in the past some networking folks complained about slow
> timecounters affecting network performance, so I wanted confirmation
> that this didn't cause problems.
I don't see how a more precis
În 3 iulie 2020 20:57:52 EEST, Mark Kettenis a scris:
>> Date: Fri, 3 Jul 2020 12:42:58 -0500
>> From: Scott Cheloha
>>
>> On Fri, Jul 03, 2020 at 02:34:20PM +0300, Paul Irofti wrote:
>> > On 2020-07-03 00:40, Scott Cheloha wrote:
>> > > On Fri, Jun 26, 2020 at 04:53:14PM +0300, Paul Irofti w
> Date: Fri, 3 Jul 2020 12:42:58 -0500
> From: Scott Cheloha
>
> On Fri, Jul 03, 2020 at 02:34:20PM +0300, Paul Irofti wrote:
> > On 2020-07-03 00:40, Scott Cheloha wrote:
> > > On Fri, Jun 26, 2020 at 04:53:14PM +0300, Paul Irofti wrote:
> > > > On Wed, Jun 24, 2020 at 11:53:23AM +0200, Robert N
Scott Cheloha wrote:
> I was under the impression kettenis@ had added an lfence to the kernel
> TSC's tc_get_timecount(), but I was mistaken.
>
> We can deal with that separately.
the question was asked, but I guess not answered definitively
I think we should *always* lfence, because in the en
Is there any particular reason why an interface's *public* key is only
shown to the root user in ifconfig?
Similar to `wgport', I'd like to see the public key as non-root user as
well for convenience:
$ ifconfig wg0
wg0: flags=80c3 mtu 1420
index 5 priority 0 llpri
On Fri, Jul 03, 2020 at 02:34:20PM +0300, Paul Irofti wrote:
> On 2020-07-03 00:40, Scott Cheloha wrote:
> > On Fri, Jun 26, 2020 at 04:53:14PM +0300, Paul Irofti wrote:
> > > On Wed, Jun 24, 2020 at 11:53:23AM +0200, Robert Nagy wrote:
> > > > On 22/06/20 19:12 +0300, Paul Irofti wrote:
> > > > >
În 3 iulie 2020 18:45:29 EEST, Scott Cheloha a scris:
>On Fri, Jul 03, 2020 at 06:36:39PM +0300, Paul Irofti wrote:
>>
>>
>> ??n 3 iulie 2020 17:55:25 EEST, Mark Kettenis
> a scris:
>> >> Date: Fri, 3 Jul 2020 15:13:22 +0200
>> >> From: Robert Nagy
>> >>
>> >> On 02/07/20 00:31 +0100, Stuar
On 2020-07-03, Mark Kettenis wrote:
> Are the issue that naddy@ saw solved?
Yes, they were understood and fixed.
I'll defer to you and Scott regarding the TSC synchronization issues;
aside from that I'm okaying the diff.
--
Christian "naddy" Weisgerber na...@mips.inka
On Fri, Jul 03, 2020 at 06:36:39PM +0300, Paul Irofti wrote:
>
>
> ??n 3 iulie 2020 17:55:25 EEST, Mark Kettenis a
> scris:
> >> Date: Fri, 3 Jul 2020 15:13:22 +0200
> >> From: Robert Nagy
> >>
> >> On 02/07/20 00:31 +0100, Stuart Henderson wrote:
> >> > running on 38 of these, btw.
> >>
> >
În 3 iulie 2020 17:55:25 EEST, Mark Kettenis a scris:
>> Date: Fri, 3 Jul 2020 15:13:22 +0200
>> From: Robert Nagy
>>
>> On 02/07/20 00:31 +0100, Stuart Henderson wrote:
>> > running on 38 of these, btw.
>>
>> been running with this on all my workstations and laptops and on 3
>build
>> serve
> Date: Fri, 3 Jul 2020 15:13:22 +0200
> From: Robert Nagy
>
> On 02/07/20 00:31 +0100, Stuart Henderson wrote:
> > running on 38 of these, btw.
>
> been running with this on all my workstations and laptops and on 3 build
> servers as well
Are the issue that naddy@ saw solved?
Did anybody do a
ping?
> On 1 Jul 2020, at 22:42, Vitaliy Makkoveev wrote:
>
> pipex(4) has 2 mbuf queues: `pipexinq' and `pipexoutq'. When mbuf passed
> to pipex it goes to one of these queues and pipexintr() will be
> scheduled to process them. pipexintr() called from `netisr' context.
>
> It's true for pppac
ping?
> On 1 Jul 2020, at 00:02, Vitaliy Makkoveev wrote:
>
> On Tue, Jun 30, 2020 at 03:48:22PM +0300, Vitaliy Makkoveev wrote:
>> On Tue, Jun 30, 2020 at 12:08:03PM +0200, Martin Pieuchot wrote:
>>> On 29/06/20(Mon) 11:59, Vitaliy Makkoveev wrote:
[...]
I reworked tool for reproduce
On 02/07/20 00:31 +0100, Stuart Henderson wrote:
> running on 38 of these, btw.
been running with this on all my workstations and laptops and on 3 build
servers as well
On Fri, Jun 26, 2020 at 04:48:53PM +0200, Klemens Nanni wrote:
> The internal handle used to pass process information is a needless
> abstraction, after previously removing an unused member, it now only has
> one member pointing to a pointer to a process struct, i.e. a simple list
> of processes.
>
On 2020-07-03 00:40, Scott Cheloha wrote:
On Fri, Jun 26, 2020 at 04:53:14PM +0300, Paul Irofti wrote:
On Wed, Jun 24, 2020 at 11:53:23AM +0200, Robert Nagy wrote:
On 22/06/20 19:12 +0300, Paul Irofti wrote:
New iteration:
- ps_timekeep should not coredump, pointed by deraadt@
- set ps_
Hi Martijn,
sorry for the delay, now i finally looked at the function
smi_displayhint_os() from the line "if (MB_CUR_MAX > 1) {" to the
end of the corresponding else clause. IIUC, what that code is
trying to do is iterate the input buffer "const char *buf" of length
"size_t buflen".
Before start
On Thu, Jul 02, 2020 at 08:27:58PM -0500, Scott Cheloha wrote:
> Hi,
>
> When we recompute the scaling factor during tc_windup() there is an
> opportunity for arithmetic overflow/underflow when we add the NTP
> adjustment into the scale:
>
>649 scale = (u_int64_t)1 << 63;
>650
21 matches
Mail list logo