În 11 iulie 2020 02:27:50 EEST, Mark Kettenis a scris:
>> From p...@irofti.net Sat Jul 11 01:23:20 2020
>> Date: Sat, 11 Jul 2020 02:22:33 +0300
>>
>> În 11 iulie 2020 02:15:27 EEST, Mark Kettenis
> a scris:
>> >> Date: Fri, 10 Jul 2020 19:03:58 -0400
>> >> From: George Koehler
>> >>
>> >>
> From p...@irofti.net Sat Jul 11 01:23:20 2020
> Date: Sat, 11 Jul 2020 02:22:33 +0300
>
> În 11 iulie 2020 02:15:27 EEST, Mark Kettenis a
> scris:
> >> Date: Fri, 10 Jul 2020 19:03:58 -0400
> >> From: George Koehler
> >>
> >> On Wed, 8 Jul 2020 14:26:02 +0200 (CEST)
> >> Mark Kettenis
În 11 iulie 2020 02:15:27 EEST, Mark Kettenis a scris:
>> Date: Fri, 10 Jul 2020 19:03:58 -0400
>> From: George Koehler
>>
>> On Wed, 8 Jul 2020 14:26:02 +0200 (CEST)
>> Mark Kettenis wrote:
>>
>> > > From: Paul Irofti
>> > > Reads OK to me. Please make the adjustments to static functions
> Date: Fri, 10 Jul 2020 19:03:58 -0400
> From: George Koehler
>
> On Wed, 8 Jul 2020 14:26:02 +0200 (CEST)
> Mark Kettenis wrote:
>
> > > From: Paul Irofti
> > > Reads OK to me. Please make the adjustments to static functions that
> > > kettenis@ mentioned in the alpha thread.
> >
> > To
On Wed, 8 Jul 2020 14:26:02 +0200 (CEST)
Mark Kettenis wrote:
> > From: Paul Irofti
> > Reads OK to me. Please make the adjustments to static functions that
> > kettenis@ mentioned in the alpha thread.
>
> To add to that:
>
> * TC_LAST isn't needed, so kill that
> * tc_get_timecount
>
>
On Wed, 8 Jul 2020 11:32:09 -0500
Scott Cheloha wrote:
> On Wed, Jul 08, 2020 at 09:36:03AM -0600, Theo de Raadt wrote:
> > Ugly test program (not showing it) seems to show syncronized clocks on
> > powerpc, or at least closely sycronized. It might be one register.
>
> I guess I'll share mine,
On Wed, Jul 08, 2020 at 09:36:03AM -0600, Theo de Raadt wrote:
> Christian Weisgerber wrote:
>
> > On 2020-06-26, George Koehler wrote:
> >
> > > Here's macppc again. My macppc isn't using your newest diff but does
> > > now need to define TC_TB in .
> >
> > Crucial question: How confident
Christian Weisgerber wrote:
> On 2020-06-26, George Koehler wrote:
>
> > Here's macppc again. My macppc isn't using your newest diff but does
> > now need to define TC_TB in .
>
> Crucial question: How confident are we that TB is in sync on
> multiprocessor machines?
Ugly test program (not
Christian Weisgerber wrote:
> On 2020-06-26, George Koehler wrote:
>
> > Here's macppc again. My macppc isn't using your newest diff but does
> > now need to define TC_TB in .
>
> Crucial question: How confident are we that TB is in sync on
> multiprocessor machines?
A few small test
On 2020-06-26, George Koehler wrote:
> Here's macppc again. My macppc isn't using your newest diff but does
> now need to define TC_TB in .
Crucial question: How confident are we that TB is in sync on
multiprocessor machines?
--
Christian "naddy" Weisgerber
> From: Paul Irofti
> Date: Wed, 8 Jul 2020 12:05:04 +0300
>
> On 2020-06-26 06:22, George Koehler wrote:
> > On Mon, 22 Jun 2020 19:12:22 +0300
> > Paul Irofti wrote:
> >
> >> New iteration:
> >>
> >>- ps_timekeep should not coredump, pointed by deraadt@
> >>- set ps_timekeep to 0
On 2020-07-08 01:09, Theo de Raadt wrote:
The /sys/arch/powerpc/include/timetc.h in your diff never gets used,
because there is no #include . On macppc,
I am fixing this issue for all the architectures, just being careful
by doing builds first.
Thank you for handling this.
On 2020-06-26 06:22, George Koehler wrote:
On Mon, 22 Jun 2020 19:12:22 +0300
Paul Irofti wrote:
New iteration:
- ps_timekeep should not coredump, pointed by deraadt@
- set ps_timekeep to 0 before user uvm_map for randomization
- map timekeep before fixup. confirmed by naddy@ that
> The /sys/arch/powerpc/include/timetc.h in your diff never gets used,
> because there is no #include . On macppc,
I am fixing this issue for all the architectures, just being careful
by doing builds first.
Hi George,
On Thu, 25 Jun 2020 23:22:36 -0400
George Koehler wrote:
> On Mon, 22 Jun 2020 19:12:22 +0300
> Paul Irofti wrote:
>
> > New iteration:
> >
> > - ps_timekeep should not coredump, pointed by deraadt@
> > - set ps_timekeep to 0 before user uvm_map for randomization
> > - map
Sorry for late reaction. At least VirtualBox based virtual machines
started to panic with the recent kernel. I reverted your diff and panics
stopped.
Screenshot attached.
> On 5 Jul 2020, at 20:31, Paul Irofti wrote:
>
> 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
Ah, it was seen.
But everyone has too much memory these days.
Vitaliy Makkoveev wrote:
> Sorry for late reaction. At least VirtualBox based virtual machines
> started to panic with the recent kernel. I reverted your diff and panics
> stopped.
> Screenshot attached.
> From: Vitaliy Makkoveev
> Date: Tue, 7 Jul 2020 01:34:33 +0300
>
> > On 5 Jul 2020, at 20:31, Paul Irofti wrote:
> >
> > 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
On Sun, Jul 05, 2020 at 08:31:19PM +0300, Paul Irofti wrote:
> 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
> Date: Sun, 5 Jul 2020 20:31:19 +0300
> From: Paul Irofti
>
> 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
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.
> >>
>
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
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
Î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
> 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
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
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,
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
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
>>
> 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
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 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
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_timekeep to 0
running on 38 of these, btw.
OpenBSD 6.7-current (GENERIC.MP) #0: Sat Jun 27 21:15:58 BST 2020
sthen@...:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4169592832 (3976MB)
avail mem = 4028198912 (3841MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
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_timekeep to 0 before user uvm_map for randomization
> > - map timekeep before fixup.
On Mon, 22 Jun 2020 19:12:22 +0300
Paul Irofti wrote:
> New iteration:
>
> - ps_timekeep should not coredump, pointed by deraadt@
> - set ps_timekeep to 0 before user uvm_map for randomization
> - map timekeep before fixup. confirmed by naddy@ that it fixes NULL init
> - initialize va.
On 22/06/20 19:12 +0300, Paul Irofti wrote:
> New iteration:
>
> - ps_timekeep should not coredump, pointed by deraadt@
> - set ps_timekeep to 0 before user uvm_map for randomization
> - map timekeep before fixup. confirmed by naddy@ that it fixes NULL init
> - initialize va. clarified by
New iteration:
- ps_timekeep should not coredump, pointed by deraadt@
- set ps_timekeep to 0 before user uvm_map for randomization
- map timekeep before fixup. confirmed by naddy@ that it fixes NULL init
- initialize va. clarified by kettenis@
How's the magical max skew value research
Christian Weisgerber wrote:
> Christian Weisgerber:
>
> > If I move
> >
> > vaddr_t ps_timekeep;/* User pointer to timekeep */
> >
> > up into the zeroed area, I get a properly randomized _timekeep in
> > userland.
>
> Also note that exec_sigcode_map() has this
>
>
On Mon, Jun 22, 2020 at 09:46:13AM -0600, Theo de Raadt wrote:
> Christian Weisgerber wrote:
>
> > Paul Irofti:
> >
> > > 683 /* map the process's timekeep page */
> > > 684 if (exec_timekeep_map(pr))
> > > 685 goto free_pack_abort;
> > > 686 /* setup new
On Mon, Jun 22, 2020 at 05:35:48PM +0200, Christian Weisgerber wrote:
> Paul Irofti:
>
> > 683 /* map the process's timekeep page */
> > 684 if (exec_timekeep_map(pr))
> > 685 goto free_pack_abort;
> > 686 /* setup new registers and do misc. setup. */
> >
Christian Weisgerber wrote:
> Paul Irofti:
>
> > 683 /* map the process's timekeep page */
> > 684 if (exec_timekeep_map(pr))
> > 685 goto free_pack_abort;
> > 686 /* setup new registers and do misc. setup. */
> > 687 if (pack.ep_emul->e_fixup !=
Christian Weisgerber:
> If I move
>
> vaddr_t ps_timekeep;/* User pointer to timekeep */
>
> up into the zeroed area, I get a properly randomized _timekeep in
> userland.
Also note that exec_sigcode_map() has this
pr->ps_sigcode = 0; /* no hint */
Paul Irofti:
> 683 /* map the process's timekeep page */
> 684 if (exec_timekeep_map(pr))
> 685 goto free_pack_abort;
> 686 /* setup new registers and do misc. setup. */
> 687 if (pack.ep_emul->e_fixup != NULL) {
> 688 if
Paul Irofti wrote:
> So I don't know why the address is not randomized, but I bet if I print
> pr->ps_sigcode somehow from userland, it will be the same.
I just checked that.
60 out of 68 processes have a unique UVA for sigtramp, the other 8 processes
are fork's without execve.
Paul Irofti wrote:
> So I don't know why the address is not randomized, but I bet if I print
> pr->ps_sigcode somehow from userland, it will be the same.
echo kern.allowkmem=1 >> /etc/sysctl.conf
reboot
Then procmap can be run on all processes, to see what VA the sigtramp
and timekeep land at.
On Sun, Jun 21, 2020 at 05:42:55PM -0600, Theo de Raadt wrote:
> Paul Irofti wrote:
>
> >
> >
> >
> > ??n 22 iunie 2020 01:26:16 EEST, Christian Weisgerber
> > a scris:
> > >Christian Weisgerber:
> > >
> > >> I tweaked the patch locally to make _timekeep a visible global
> > >> symbol in
> Date: Mon, 22 Jun 2020 13:53:25 +0300
> From: Paul Irofti
>
> > Still uses uint instead of u_int in places. Still has the pointless
> > extra NULL and 0 for timecounters in files that are otherwise
>
> If you don't like uint, then let's fix what's in the tree in amd64
> (which is how uint
> Still uses uint instead of u_int in places. Still has the pointless
> extra NULL and 0 for timecounters in files that are otherwise
If you don't like uint, then let's fix what's in the tree in amd64
(which is how uint got used in my diff too). OK?
diff --git sys/arch/amd64/amd64/tsc.c
On Mon, Jun 22, 2020 at 01:27:22AM +0200, Mark Kettenis wrote:
> > Date: Mon, 22 Jun 2020 02:06:39 +0300
> > From: Paul Irofti
> >
> > În 22 iunie 2020 00:15:59 EEST, Christian Weisgerber a
> > scris:
> > >Paul Irofti:
> > >
> > >[Unrelated, just to mark where we're at]
> > >> Right. Just
Paul Irofti wrote:
>
>
>
> Ãn 22 iunie 2020 01:26:16 EEST, Christian Weisgerber a
> scris:
> >Christian Weisgerber:
> >
> >> I tweaked the patch locally to make _timekeep a visible global
> >> symbol in libc.
> >>
> >> Printing its value has revealed two issues:
> >>
> >> * The timekeep
> Date: Mon, 22 Jun 2020 02:06:39 +0300
> From: Paul Irofti
>
> În 22 iunie 2020 00:15:59 EEST, Christian Weisgerber a
> scris:
> >Paul Irofti:
> >
> >[Unrelated, just to mark where we're at]
> >> Right. Just reproduced it here. This moves the check at the top so
> >that
> >> each CPU checks
În 22 iunie 2020 01:26:16 EEST, Christian Weisgerber a
scris:
>Christian Weisgerber:
>
>> I tweaked the patch locally to make _timekeep a visible global
>> symbol in libc.
>>
>> Printing its value has revealed two issues:
>>
>> * The timekeep page is mapped to the same address for every
În 22 iunie 2020 00:15:59 EEST, Christian Weisgerber a
scris:
>Paul Irofti:
>
>[Unrelated, just to mark where we're at]
>> Right. Just reproduced it here. This moves the check at the top so
>that
>> each CPU checks its own skew and disables tc_user if necessary.
>
>I tweaked the patch locally
Christian Weisgerber:
> I tweaked the patch locally to make _timekeep a visible global
> symbol in libc.
>
> Printing its value has revealed two issues:
>
> * The timekeep page is mapped to the same address for every process.
> It changes across reboots, but once running, it's always the
Paul Irofti:
[Unrelated, just to mark where we're at]
> Right. Just reproduced it here. This moves the check at the top so that
> each CPU checks its own skew and disables tc_user if necessary.
I tweaked the patch locally to make _timekeep a visible global
symbol in libc.
Printing its value has
On Sun, Jun 21, 2020 at 08:18:57PM +0200, Christian Weisgerber wrote:
> Paul Irofti:
>
> > Can't test right now, but if you enable the TSC_DEBUG in cpu.c or if you
> > put a printf in the CPU_INFO_FOREACH you will probably see the correct
> > skew values.
>
> It's worse: CPU_INFO_FOREACH() only
Paul Irofti:
> > b) Revert _timekeep init (breaks naddy@'s machine)
>
> Robert helped properly track down this issue to a silly null-ref.
If that was indeed the problem...
> --- lib/libc/dlfcn/init.c
> +++ lib/libc/dlfcn/init.c
> @@ -105,6 +107,14 @@ _libc_preinit(int argc, char **argv, char
Paul Irofti:
> Can't test right now, but if you enable the TSC_DEBUG in cpu.c or if you
> put a printf in the CPU_INFO_FOREACH you will probably see the correct
> skew values.
It's worse: CPU_INFO_FOREACH() only sees cpu0. The others aren't
attached yet.
--
Christian "naddy" Weisgerber
On Sun, Jun 21, 2020 at 05:44:36PM +0200, Christian Weisgerber wrote:
> Paul Irofti:
>
> > This also handles negative skew values that my prevoius diff did not.
>
> > --- sys/arch/amd64/amd64/tsc.c
> > +++ sys/arch/amd64/amd64/tsc.c
> > @@ -216,6 +217,8 @@ tsc_get_timecount(struct timecounter
Paul Irofti:
> This also handles negative skew values that my prevoius diff did not.
> --- sys/arch/amd64/amd64/tsc.c
> +++ sys/arch/amd64/amd64/tsc.c
> @@ -216,6 +217,8 @@ tsc_get_timecount(struct timecounter *tc)
> void
> tsc_timecounter_init(struct cpu_info *ci, uint64_t cpufreq)
> {
> +
This also handles negative skew values that my prevoius diff did not.
For the last coulpe of weeks people told me that this thread is hard to
follow sometimes. You can always get the latest changes here where the
actual development takes place. (PR's accepted.)
> b) Revert _timekeep init (breaks naddy@'s machine)
Robert helped properly track down this issue to a silly null-ref. This
new diff addresses this and also does not initialize _timekeep as Mark
wanted.
diff --git lib/libc/arch/aarch64/gen/Makefile.inc
lib/libc/arch/aarch64/gen/Makefile.inc
Hi,
New iteration that addresses the issues raised by Scott and Mark.
a) Use sys/time.h defs by adding _LIBC
b) Revert _timekeep init (breaks naddy@'s machine)
c) Add TSC_SKEW_MAX thresholding when enabling tc_user
d) uint->u_int
Item c) adds the code needed for what Mark requested. The
On 2020-06-20, Christian Weisgerber wrote:
> I can't get this revision of the diff to work on amd64:
> * patch source
> * build and install kernel, reboot
> * make build
> * reboot -> "Process (pid 1) got signal 11"
>
> I'm at a loss. As part of the "make build", the new libc is installed
> and
> From: Christian Weisgerber
> Date: Sat, 20 Jun 2020 19:57:06 - (UTC)
>
> On 2020-06-19, Paul Irofti wrote:
>
> > I have addressed your comments bellow, except for the CPU skew one. That
> > code disables TSC for all CPUs, not just for PRIMARY. Would you like to
> > walk and add code for
On 2020-06-19, Paul Irofti wrote:
> I have addressed your comments bellow, except for the CPU skew one. That
> code disables TSC for all CPUs, not just for PRIMARY. Would you like to
> walk and add code for every CPU to check the drift and then disable the
> TSC? It seems a little too much...
>
> From: Christian Weisgerber
> Date: Sat, 20 Jun 2020 01:20:33 - (UTC)
>
> On 2020-06-19, Mark Kettenis wrote:
>
> > I'm talking about *skew*, not drift. If there is a significant drift
> > you already knock out the TSC.
> >
> > What's needed is:
> >
> > 1. A bit of research of what an
On 2020-06-19, Mark Kettenis wrote:
> I'm talking about *skew*, not drift. If there is a significant drift
> you already knock out the TSC.
>
> What's needed is:
>
> 1. A bit of research of what an acceptable skew is. My hypothesis is
>that on many machines with a single socket the TSCs
> On Jun 19, 2020, at 12:40, Paul Irofti wrote:
>
> [...]
>
> +
> +static inline void
> +bintimeaddfrac(const struct bintime *bt, uint64_t x, struct bintime *ct)
> +{
> +ct->sec = bt->sec;
> +if (bt->frac > bt->frac + x)
> +ct->sec++;
> +ct->frac = bt->frac + x;
> +}
> +
>
On 2020/06/19 20:28, Paul Irofti wrote:
> On Fri, Jun 19, 2020 at 06:52:40PM +0200, Mark Kettenis wrote:
> > I don't expect userland processes to call CLOCK_UPTIME in a loop like
> > they tend to do do for CLOCK_MONOTONIC and CLOCK_REALTIME. Linux
> > doesn't have it ;).
>
> I don't care
În 19 iunie 2020 23:37:28 EEST, Mark Kettenis a scris:
>> Date: Fri, 19 Jun 2020 23:16:26 +0300
>> From: Paul Irofti
>>
>> În 19 iunie 2020 22:49:32 EEST, Mark Kettenis
> a scris:
>> >> Date: Fri, 19 Jun 2020 20:28:58 +0300
>> >> From: Paul Irofti
>> >>
>> >> On Fri, Jun 19, 2020 at
> Date: Fri, 19 Jun 2020 23:16:26 +0300
> From: Paul Irofti
>
> În 19 iunie 2020 22:49:32 EEST, Mark Kettenis a
> scris:
> >> Date: Fri, 19 Jun 2020 20:28:58 +0300
> >> From: Paul Irofti
> >>
> >> On Fri, Jun 19, 2020 at 06:52:40PM +0200, Mark Kettenis wrote:
> >> > > Date: Fri, 19 Jun 2020
În 19 iunie 2020 22:49:32 EEST, Mark Kettenis a scris:
>> Date: Fri, 19 Jun 2020 20:28:58 +0300
>> From: Paul Irofti
>>
>> On Fri, Jun 19, 2020 at 06:52:40PM +0200, Mark Kettenis wrote:
>> > > Date: Fri, 19 Jun 2020 14:31:17 +0300
>> > > From: Paul Irofti
>> > >
>> > > Hi,
>> > >
>> > >
> Date: Fri, 19 Jun 2020 20:28:58 +0300
> From: Paul Irofti
>
> On Fri, Jun 19, 2020 at 06:52:40PM +0200, Mark Kettenis wrote:
> > > Date: Fri, 19 Jun 2020 14:31:17 +0300
> > > From: Paul Irofti
> > >
> > > Hi,
> > >
> > > Here is another iteration of the diff that addresses all issues raised
> From: "Todd C. Miller"
> Date: Fri, 19 Jun 2020 12:24:33 -0600
>
> On Fri, 19 Jun 2020 18:52:40 +0200, Mark Kettenis wrote:
>
> > There is one other issue that I wanted to raise. An that is whether
> > we really need to implement CLOCK_UPTINME as a userland clock. If we
> > don't do that we
On Fri, 19 Jun 2020 18:52:40 +0200, Mark Kettenis wrote:
> There is one other issue that I wanted to raise. An that is whether
> we really need to implement CLOCK_UPTINME as a userland clock. If we
> don't do that we can drop tk_naptime from the shared struct. I
> mention this because
On Fri, Jun 19, 2020 at 06:52:40PM +0200, Mark Kettenis wrote:
> > Date: Fri, 19 Jun 2020 14:31:17 +0300
> > From: Paul Irofti
> >
> > Hi,
> >
> > Here is another iteration of the diff that addresses all issues raised
> > in the meantime:
> >
> > - Switch tc to uint
>
> The request was to
> Date: Fri, 19 Jun 2020 14:31:17 +0300
> From: Paul Irofti
>
> Hi,
>
> Here is another iteration of the diff that addresses all issues raised
> in the meantime:
>
> - Switch tc to uint
The request was to use u_int, like we de in the kernel. The uint type
should not be used in OpenBSD
On Fri, Jun 19, 2020 at 05:20:24PM +0300, Paul Irofti wrote:
> Hi Lucas,
>
> Will reply inline.
>
> > As a matter of syntax, there are quite some places with functions
> > without parameters defined as `f()` instead of `f(void)`.
>
> Sure. Good catch.
>
> > > + if (tc == NULL || tk_user < 1 ||
Hi Lucas,
Will reply inline.
As a matter of syntax, there are quite some places with functions
without parameters defined as `f()` instead of `f(void)`.
Sure. Good catch.
+ if (tc == NULL || tk_user < 1 || tk_user > TC_LAST)
Shouldn't you check for >= TC_LAST in here? Otherwise
Hi Paul,
I'm just a bystander that likes to read diffs. I can't speak about how
the diff fits in the kernel, but I can do some basic checks of
correctness.
As a matter of syntax, there are quite some places with functions
without parameters defined as `f()` instead of `f(void)`.
Paul Irofti
Hi,
Here is another iteration of the diff that addresses all issues raised
in the meantime:
- Switch tc to uint
- Check for version at init and switch to machite/timetc.h defs
- Remove tk_nclocks
- Switch to single version and ditch minor/major
- Do not enable user TSC for large skew
George Koehler:
> --- lib/libc/arch/powerpc/gen/usertc.c.before Sat Jun 13 21:28:50 2020
> +++ lib/libc/arch/powerpc/gen/usertc.cSat Jun 13 21:38:52 2020
> @@ -18,4 +18,19 @@
> #include
> #include
>
> -int (*const _tc_get_timecount)(struct timekeep *, uint64_t *) = NULL;
> +int
>
This is macppc, goes on top of your diff from
Thu, 11 Jun 2020 16:27:03 +0300.
Do integrate this small diff into your big diff. If you need to
change the macppc code but can't build it, then do the change, and
allow me or someone else to build it. I'm gkoehler@.
macppc is a simple arch: there
> From: Paul Irofti
> Date: Fri, 12 Jun 2020 12:30:22 +0300
>
> On 12.06.2020 10:48, Robert Nagy wrote:
> > On 11/06/20 20:10 +0200, Mark Kettenis wrote:
> >>> Date: Thu, 11 Jun 2020 19:38:48 +0200
> >>> From: Christian Weisgerber
> >>>
> >>> Theo de Raadt:
> >>>
> The diff is growing
On 12.06.2020 10:48, Robert Nagy wrote:
On 11/06/20 20:10 +0200, Mark Kettenis wrote:
Date: Thu, 11 Jun 2020 19:38:48 +0200
From: Christian Weisgerber
Theo de Raadt:
The diff is growing complexity to support a future which wouldn't
exist if attempts at *supporting all* architectures
On 11/06/20 20:10 +0200, Mark Kettenis wrote:
> > Date: Thu, 11 Jun 2020 19:38:48 +0200
> > From: Christian Weisgerber
> >
> > Theo de Raadt:
> >
> > > The diff is growing complexity to support a future which wouldn't
> > > exist if attempts at *supporting all* architectures received priority.
Mark Kettenis wrote:
> suggestion to have an MD header file actually helps. With that file
> we can easily avoid the function pointer and it becomes easier adding
> new timecounters in the kernel (which happens from time to time).
When does this happen?
If it happens, what's the fuss? The
> Date: Thu, 11 Jun 2020 19:38:48 +0200
> From: Christian Weisgerber
>
> Theo de Raadt:
>
> > The diff is growing complexity to support a future which wouldn't
> > exist if attempts at *supporting all* architectures received priority.
>
> Adding support for more archs is very simple, since you
Theo de Raadt:
> The diff is growing complexity to support a future which wouldn't
> exist if attempts at *supporting all* architectures received priority.
Adding support for more archs is very simple, since you just need
to copy the corresponding get_timecounter function from the kernel.
Mark Kettenis wrote:
> > Date: Thu, 11 Jun 2020 17:29:44 +0200
> > From: Christian Weisgerber
> >
> > Paul Irofti:
> >
> > > > Paul, that tk_nclocks addition isn't useful. You need to do the
> > > > bounds checking against the number of clocks you have implemented in
> > > > libc. How many
> Date: Thu, 11 Jun 2020 17:29:44 +0200
> From: Christian Weisgerber
>
> Paul Irofti:
>
> > > Paul, that tk_nclocks addition isn't useful. You need to do the
> > > bounds checking against the number of clocks you have implemented in
> > > libc. How many clocks the kernel has implemented
Paul Irofti:
> > Paul, that tk_nclocks addition isn't useful. You need to do the
> > bounds checking against the number of clocks you have implemented in
> > libc. How many clocks the kernel has implemented doesn't matter.
>
> What you are saying is that we could be in a situation where the
Paul Irofti:
[lib/libc/arch/*/gen/usertc.c]
> +int (*const _tc_get_timecount)(struct timekeep *, uint64_t *) = NULL;
[lib/libc/sys/microtime.c]
> +static inline int
> +tc_delta(struct timekeep *tk, u_int *delta)
> +{
> + uint64_t tc;
> + if (delta == NULL || _tc_get_timecount(tk, ))
Paul Irofti wrote:
> > I want to see this diff support 3-4 architectures before commit.
>
> Sure. Whenever you feel confident. As I said numerous times now here,
> nobody is pressuring this with a commit.
>
> I think we support already 3 architectures: amd64, macppc, sparc64
> (kettenis?).
I
Paul Irofti wrote:
> On Thu, Jun 11, 2020 at 02:05:44PM +0200, Marc Espie wrote:
> > On Thu, Jun 11, 2020 at 01:13:07PM +0300, Paul Irofti wrote:
> > > On 2020-06-11 02:46, Christian Weisgerber wrote:
> > > > Paul Irofti:
> > > >
> > > > > This iteration of the diff adds bounds checking for
1 - 100 of 201 matches
Mail list logo
