> ok kettenis@
ok deraadt also
> Date: Tue, 11 Jul 2023 15:28:22 -0500
> From: Scott Cheloha
>
> On Mon, Jul 10, 2023 at 10:41:15AM -0500, Scott Cheloha wrote:
> > On Mon, Jul 10, 2023 at 05:19:35PM +0200, Mark Kettenis wrote:
> > > > Date: Mon, 10 Jul 2023 09:57:39 -0500
> > > > From: Scott Cheloha
> > > >
> > > > On Mon,
On Mon, Jul 10, 2023 at 10:41:15AM -0500, Scott Cheloha wrote:
> On Mon, Jul 10, 2023 at 05:19:35PM +0200, Mark Kettenis wrote:
> > > Date: Mon, 10 Jul 2023 09:57:39 -0500
> > > From: Scott Cheloha
> > >
> > > On Mon, Jul 10, 2023 at 07:42:55AM -0600, Theo de Raadt wrote:
> > > > I dare you to
On Mon, Jul 10, 2023 at 05:19:35PM +0200, Mark Kettenis wrote:
> > Date: Mon, 10 Jul 2023 09:57:39 -0500
> > From: Scott Cheloha
> >
> > On Mon, Jul 10, 2023 at 07:42:55AM -0600, Theo de Raadt wrote:
> > > I dare you to write the simplest fix for this, instead of a diff that
> > > scrolls by.
>
Mark Kettenis wrote:
> It is still a bit scary to have cpu_hatch() call _mcount() but I guess
> adding __attribute__((no_profile)) to all of the functions called by
> cpu_hatch() isn't really workable either.
It now immediately returns.
> > + int gmon_state = gmoninit;
>
> No variable
> Date: Mon, 10 Jul 2023 09:57:39 -0500
> From: Scott Cheloha
>
> On Mon, Jul 10, 2023 at 07:42:55AM -0600, Theo de Raadt wrote:
> > I dare you to write the simplest fix for this, instead of a diff that
> > scrolls by.
>
> This patch seems to work. Will need to bang on it for a few more days.
On Mon, Jul 10, 2023 at 07:42:55AM -0600, Theo de Raadt wrote:
> I dare you to write the simplest fix for this, instead of a diff that
> scrolls by.
This patch seems to work. Will need to bang on it for a few more days.
1. Disable gmoninit after sched_stop_scondary_cpus(). The secondary
I dare you to write the simplest fix for this, instead of a diff that
scrolls by.
Scott Cheloha wrote:
> Secondary CPUs are still running at the top of sleep_state(). To
> disable _mcount with gmoninit we would need to wait until after
> secondary CPUs have halted to toggle it off, which is way further into
> sleep_state().
I suspect you are exaggerating the window of time
On Mon, Jul 10, 2023 at 07:09:19AM -0600, Theo de Raadt wrote:
> Mark Kettenis wrote:
>
> > So isn't the real problem that some of the lower-level code involved
> > in the resume path isn't properly marked to not do the
> > instrumentation? Traditionally that was assembly code and we'd use
> >
Mark Kettenis wrote:
> So isn't the real problem that some of the lower-level code involved
> in the resume path isn't properly marked to not do the
> instrumentation? Traditionally that was assembly code and we'd use
> NENTRY() (in amd64) or ENTRY_NP() (on some other architectures) to
>
> Date: Sun, 9 Jul 2023 17:24:41 -0500
> From: Scott Cheloha
>
> On Sun, Jul 09, 2023 at 08:11:43PM +0200, Claudio Jeker wrote:
> > On Sun, Jul 09, 2023 at 12:52:20PM -0500, Scott Cheloha wrote:
> > > This patch fixes resume/unhibernate on GPROF kernels where kgmon(8)
> > > has activated kernel
On Sun, Jul 09, 2023 at 05:24:43PM -0500, Scott Cheloha wrote:
> On Sun, Jul 09, 2023 at 08:11:43PM +0200, Claudio Jeker wrote:
> > On Sun, Jul 09, 2023 at 12:52:20PM -0500, Scott Cheloha wrote:
> > > This patch fixes resume/unhibernate on GPROF kernels where kgmon(8)
> > > has activated kernel
On Sun, Jul 09, 2023 at 08:11:43PM +0200, Claudio Jeker wrote:
> On Sun, Jul 09, 2023 at 12:52:20PM -0500, Scott Cheloha wrote:
> > This patch fixes resume/unhibernate on GPROF kernels where kgmon(8)
> > has activated kernel profiling.
> >
> > I think the problem is that code called from
On Sun, Jul 09, 2023 at 12:52:20PM -0500, Scott Cheloha wrote:
> This patch fixes resume/unhibernate on GPROF kernels where kgmon(8)
> has activated kernel profiling.
>
> I think the problem is that code called from cpu_hatch() does not play
> nicely with _mcount(), so GPROF kernels crash during
15 matches
Mail list logo
