Re: git: b75062f23431 - main - riscv: Fix thread0.td_kstack_pages init

On Wed, Jan 18, 2023 at 3:07 PM Mitchell Horne <mhorne@freebsd.org> wrote:

>
>
> On 1/17/23 12:38, Brooks Davis wrote:
> > The branch main has been updated by brooks:
> >
> > URL:
> https://cgit.FreeBSD.org/src/commit/?id=b75062f23431fbabef1e7d665cae270b144f71b1
> >
> > commit b75062f23431fbabef1e7d665cae270b144f71b1
> > Author:     Brooks Davis <brooks@FreeBSD.org>
> > AuthorDate: 2023-01-17 16:36:15 +0000
> > Commit:     Brooks Davis <brooks@FreeBSD.org>
> > CommitDate: 2023-01-17 16:37:42 +0000
> >
> >      riscv: Fix thread0.td_kstack_pages init
> >
> >      Commit 0ef3ca7ae37c70e9dc83475dc2e68e98e1c2a418 initialized
> >      thread0.td_kstack_pages to KSTACK_PAGES.  Due to the lack of an
> >      include of opt_kstack_pages.h it used the fallback value of 4 from
> >      machine/param.h.
>
> Does this mean that we could/should include opt_kstack_pages.h within
> machine/param.h (under #ifdef _KERNEL)? This header is both a consumer
> and provider of the KSTACK_PAGES definition, by virtue of the #ifndef. I
> think the hidden dependency should be avoided, if possible.
>

No. Including opt_XXXX.h is never OK in our .h files. They are used in too
many places, some of which "cheat" and define _KERNEL becuse, well, they
need to get to the kernel bits....  That will break...

I do agree, however, that the current interface is less than ideal...


> Of course, the problem at hand has been fixed and we want to keep direct
> consumers of KSTACK_PAGES to a minimum, but I think the point still stands.
>

I think it's a good point, but the current way is likely the least-bad way
to accomplish things.

It would be much better if we could remove it from machine/param.h and
opt_XXX.h always defines it, even the default value when it's not otherwise
specified. However, we don't (currently) have a way to set default values
in config(8). We could add it, since the efforts at config++ have thus far
fallen flat....

Warner


> Mitchell
>
> >      This meant that increasing KSTACK_PAGES in the kernel
> >      config resulted in a panic in _epoch_enter_preempt as the following
> >      assertion was false during network stack setup:
> >
> >              MPASS((vm_offset_t)et >= td->td_kstack &&
> >                  (vm_offset_t)et + sizeof(struct epoch_tracker) <=
> >                  td->td_kstack + td->td_kstack_pages * PAGE_SIZE);
> >
> >      Switch to initializing with kstack_pages following other
> architectures.
> >
> >      Reviewed by:    imp, markj
> >      Sponsored by:   DARPA, AFRL
> >      Differential Revision:  https://reviews.freebsd.org/D38049
> > ---
> >   sys/riscv/riscv/machdep.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/sys/riscv/riscv/machdep.c b/sys/riscv/riscv/machdep.c
> > index b03d45b018ec..0821a29d11c1 100644
> > --- a/sys/riscv/riscv/machdep.c
> > +++ b/sys/riscv/riscv/machdep.c
> > @@ -291,7 +291,7 @@ init_proc0(vm_offset_t kstack)
> >
> >       proc_linkup0(&proc0, &thread0);
> >       thread0.td_kstack = kstack;
> > -     thread0.td_kstack_pages = KSTACK_PAGES;
> > +     thread0.td_kstack_pages = kstack_pages;
> >       thread0.td_pcb = (struct pcb *)(thread0.td_kstack +
> >           thread0.td_kstack_pages * PAGE_SIZE) - 1;
> >       thread0.td_pcb->pcb_fpflags = 0;
>