Re: panic booting with if_tap_load="YES" in loader.conf
On Sat, May 18, 2019 at 12:57:29PM -0600, Warner Losh wrote: > On Sat, May 18, 2019, 9:48 AM Mark Johnston wrote: > > > On Sat, May 18, 2019 at 05:45:47PM +0300, Konstantin Belousov wrote: > > > On Sat, May 18, 2019 at 05:38:15PM +0300, Konstantin Belousov wrote: > > > > On Sat, May 18, 2019 at 10:24:36AM -0400, Mark Johnston wrote: > > > > > On Sat, May 18, 2019 at 11:55:46AM +0300, Konstantin Belousov wrote: > > > > > > On Sat, May 18, 2019 at 01:33:28AM -0400, Mark Johnston wrote: > > > > > > > On Fri, May 17, 2019 at 10:18:57PM -0600, Rebecca Cran wrote: > > > > > > > > I just updated from r346856 to r347950 and ran into a new > > panic, caused > > > > > > > > by having if_tap_load="YES" in /boot/loader.conf - because > > it's already > > > > > > > > built-in to the kernel: > > > > > > > > > > > > > > I think this patch should fix the panic, but I only > > compile-tested it. > > > > > > > I considered having the logic live in preload_delete_name() > > instead, but > > > > > > > the boot-time ucode code must still defer the deletion somewhat. > > > > > > > > > > > > Try this instead. I will revert r347931 after this landed, or > > could keep > > > > > > it alone. > > > > > > > > > > I have no strong feeling either way. > > > > > > > > > > > diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c > > > > > > index 1cf09dc5cb7..03fe8a5d096 100644 > > > > > > --- a/sys/amd64/amd64/machdep.c > > > > > > +++ b/sys/amd64/amd64/machdep.c > > > > > > @@ -1616,6 +1616,13 @@ hammer_time(u_int64_t modulep, u_int64_t > > physfree) > > > > > > bzero((void *)thread0.td_kstack, kstack0_sz); > > > > > > physfree += kstack0_sz; > > > > > > > > > > > > + /* > > > > > > +* Initialize enough of thread0 for delayed invalidation to > > > > > > +* work very early. Rely on thread0.td_base_pri > > > > > > +* zero-initialization, it is reset to PVM at proc0_init(). > > > > > > +*/ > > > > > > + pmap_thread_init_invl_gen(); > > > > > > + > > > > > > > > > > I think pmap_thread_init_invl_gen() also needs to initialize > > > > > invl_gen->saved_pri to 0. > > > > It is zero-initialized, same as td_base_pri. The call to > > > > pmap_thread_init_invl_gen() is needed because _INVALID bit must be set, > > > > which is cleared by default. > > > I now think that you mean something else, that invl_gen.saved_pri must > > > be set on each entry to invl_start_u(). Otherwise invl_finish_u() might > > > act on the priority from the previous DI block. > > > > That is not what I was thinking about, but I agree. thread0's saved_pri > > should be zero-initialized, but I don't see how any other thread's > > saved_pri is initialized - td_md is not in the zero or copy region of > > the thread structure. Your patch should address this as well, but maybe > > I am still missing something about how saved_pri gets initialized. The > > patch looks right to me. > > > > Could this crash on other architectures? Do we need fixes there as well... The lock-less DI only exists on amd64. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic booting with if_tap_load="YES" in loader.conf
On Sat, May 18, 2019, 9:48 AM Mark Johnston wrote:
> On Sat, May 18, 2019 at 05:45:47PM +0300, Konstantin Belousov wrote:
> > On Sat, May 18, 2019 at 05:38:15PM +0300, Konstantin Belousov wrote:
> > > On Sat, May 18, 2019 at 10:24:36AM -0400, Mark Johnston wrote:
> > > > On Sat, May 18, 2019 at 11:55:46AM +0300, Konstantin Belousov wrote:
> > > > > On Sat, May 18, 2019 at 01:33:28AM -0400, Mark Johnston wrote:
> > > > > > On Fri, May 17, 2019 at 10:18:57PM -0600, Rebecca Cran wrote:
> > > > > > > I just updated from r346856 to r347950 and ran into a new
> panic, caused
> > > > > > > by having if_tap_load="YES" in /boot/loader.conf - because
> it's already
> > > > > > > built-in to the kernel:
> > > > > >
> > > > > > I think this patch should fix the panic, but I only
> compile-tested it.
> > > > > > I considered having the logic live in preload_delete_name()
> instead, but
> > > > > > the boot-time ucode code must still defer the deletion somewhat.
> > > > >
> > > > > Try this instead. I will revert r347931 after this landed, or
> could keep
> > > > > it alone.
> > > >
> > > > I have no strong feeling either way.
> > > >
> > > > > diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
> > > > > index 1cf09dc5cb7..03fe8a5d096 100644
> > > > > --- a/sys/amd64/amd64/machdep.c
> > > > > +++ b/sys/amd64/amd64/machdep.c
> > > > > @@ -1616,6 +1616,13 @@ hammer_time(u_int64_t modulep, u_int64_t
> physfree)
> > > > > bzero((void *)thread0.td_kstack, kstack0_sz);
> > > > > physfree += kstack0_sz;
> > > > >
> > > > > + /*
> > > > > +* Initialize enough of thread0 for delayed invalidation to
> > > > > +* work very early. Rely on thread0.td_base_pri
> > > > > +* zero-initialization, it is reset to PVM at proc0_init().
> > > > > +*/
> > > > > + pmap_thread_init_invl_gen();
> > > > > +
> > > >
> > > > I think pmap_thread_init_invl_gen() also needs to initialize
> > > > invl_gen->saved_pri to 0.
> > > It is zero-initialized, same as td_base_pri. The call to
> > > pmap_thread_init_invl_gen() is needed because _INVALID bit must be set,
> > > which is cleared by default.
> > I now think that you mean something else, that invl_gen.saved_pri must
> > be set on each entry to invl_start_u(). Otherwise invl_finish_u() might
> > act on the priority from the previous DI block.
>
> That is not what I was thinking about, but I agree. thread0's saved_pri
> should be zero-initialized, but I don't see how any other thread's
> saved_pri is initialized - td_md is not in the zero or copy region of
> the thread structure. Your patch should address this as well, but maybe
> I am still missing something about how saved_pri gets initialized. The
> patch looks right to me.
>
Could this crash on other architectures? Do we need fixes there as well...
Warner
> diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
> > index 1cf09dc5cb7..03fe8a5d096 100644
> > --- a/sys/amd64/amd64/machdep.c
> > +++ b/sys/amd64/amd64/machdep.c
> > @@ -1616,6 +1616,13 @@ hammer_time(u_int64_t modulep, u_int64_t physfree)
> > bzero((void *)thread0.td_kstack, kstack0_sz);
> > physfree += kstack0_sz;
> >
> > + /*
> > + * Initialize enough of thread0 for delayed invalidation to
> > + * work very early. Rely on thread0.td_base_pri
> > + * zero-initialization, it is reset to PVM at proc0_init().
> > + */
> > + pmap_thread_init_invl_gen();
> > +
> > /*
> >* make gdt memory segments
> >*/
> > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> > index 7997a9f65dc..89ba9da19d8 100644
> > --- a/sys/amd64/amd64/pmap.c
> > +++ b/sys/amd64/amd64/pmap.c
> > @@ -700,16 +700,17 @@ pmap_delayed_invl_start_u(void)
> > invl_gen = >td_md.md_invl_gen;
> > PMAP_ASSERT_NOT_IN_DI();
> > lock_delay_arg_init(, _delay);
> > - thread_lock(td);
> > + invl_gen->saved_pri = 0;
> > pri = td->td_base_pri;
> > - if (pri < PVM) {
> > - invl_gen->saved_pri = 0;
> > - } else {
> > - invl_gen->saved_pri = pri;
> > - sched_prio(td, PVM);
> > + if (pri > PVM) {
> > + thread_lock(td);
> > + pri = td->td_base_pri;
> > + if (pri > PVM) {
> > + invl_gen->saved_pri = pri;
> > + sched_prio(td, PVM);
> > + }
> > + thread_unlock(td);
> > }
> > - thread_unlock(td);
> > -
> > again:
> > PV_STAT(i = 0);
> > for (p = _invl_gen_head;; p = prev.next) {
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any
Re: panic booting with if_tap_load="YES" in loader.conf
On Sat, May 18, 2019 at 05:45:47PM +0300, Konstantin Belousov wrote:
> On Sat, May 18, 2019 at 05:38:15PM +0300, Konstantin Belousov wrote:
> > On Sat, May 18, 2019 at 10:24:36AM -0400, Mark Johnston wrote:
> > > On Sat, May 18, 2019 at 11:55:46AM +0300, Konstantin Belousov wrote:
> > > > On Sat, May 18, 2019 at 01:33:28AM -0400, Mark Johnston wrote:
> > > > > On Fri, May 17, 2019 at 10:18:57PM -0600, Rebecca Cran wrote:
> > > > > > I just updated from r346856 to r347950 and ran into a new panic,
> > > > > > caused
> > > > > > by having if_tap_load="YES" in /boot/loader.conf - because it's
> > > > > > already
> > > > > > built-in to the kernel:
> > > > >
> > > > > I think this patch should fix the panic, but I only compile-tested it.
> > > > > I considered having the logic live in preload_delete_name() instead,
> > > > > but
> > > > > the boot-time ucode code must still defer the deletion somewhat.
> > > >
> > > > Try this instead. I will revert r347931 after this landed, or could
> > > > keep
> > > > it alone.
> > >
> > > I have no strong feeling either way.
> > >
> > > > diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
> > > > index 1cf09dc5cb7..03fe8a5d096 100644
> > > > --- a/sys/amd64/amd64/machdep.c
> > > > +++ b/sys/amd64/amd64/machdep.c
> > > > @@ -1616,6 +1616,13 @@ hammer_time(u_int64_t modulep, u_int64_t
> > > > physfree)
> > > > bzero((void *)thread0.td_kstack, kstack0_sz);
> > > > physfree += kstack0_sz;
> > > >
> > > > + /*
> > > > +* Initialize enough of thread0 for delayed invalidation to
> > > > +* work very early. Rely on thread0.td_base_pri
> > > > +* zero-initialization, it is reset to PVM at proc0_init().
> > > > +*/
> > > > + pmap_thread_init_invl_gen();
> > > > +
> > >
> > > I think pmap_thread_init_invl_gen() also needs to initialize
> > > invl_gen->saved_pri to 0.
> > It is zero-initialized, same as td_base_pri. The call to
> > pmap_thread_init_invl_gen() is needed because _INVALID bit must be set,
> > which is cleared by default.
> I now think that you mean something else, that invl_gen.saved_pri must
> be set on each entry to invl_start_u(). Otherwise invl_finish_u() might
> act on the priority from the previous DI block.
That is not what I was thinking about, but I agree. thread0's saved_pri
should be zero-initialized, but I don't see how any other thread's
saved_pri is initialized - td_md is not in the zero or copy region of
the thread structure. Your patch should address this as well, but maybe
I am still missing something about how saved_pri gets initialized. The
patch looks right to me.
> diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
> index 1cf09dc5cb7..03fe8a5d096 100644
> --- a/sys/amd64/amd64/machdep.c
> +++ b/sys/amd64/amd64/machdep.c
> @@ -1616,6 +1616,13 @@ hammer_time(u_int64_t modulep, u_int64_t physfree)
> bzero((void *)thread0.td_kstack, kstack0_sz);
> physfree += kstack0_sz;
>
> + /*
> + * Initialize enough of thread0 for delayed invalidation to
> + * work very early. Rely on thread0.td_base_pri
> + * zero-initialization, it is reset to PVM at proc0_init().
> + */
> + pmap_thread_init_invl_gen();
> +
> /*
>* make gdt memory segments
>*/
> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> index 7997a9f65dc..89ba9da19d8 100644
> --- a/sys/amd64/amd64/pmap.c
> +++ b/sys/amd64/amd64/pmap.c
> @@ -700,16 +700,17 @@ pmap_delayed_invl_start_u(void)
> invl_gen = >td_md.md_invl_gen;
> PMAP_ASSERT_NOT_IN_DI();
> lock_delay_arg_init(, _delay);
> - thread_lock(td);
> + invl_gen->saved_pri = 0;
> pri = td->td_base_pri;
> - if (pri < PVM) {
> - invl_gen->saved_pri = 0;
> - } else {
> - invl_gen->saved_pri = pri;
> - sched_prio(td, PVM);
> + if (pri > PVM) {
> + thread_lock(td);
> + pri = td->td_base_pri;
> + if (pri > PVM) {
> + invl_gen->saved_pri = pri;
> + sched_prio(td, PVM);
> + }
> + thread_unlock(td);
> }
> - thread_unlock(td);
> -
> again:
> PV_STAT(i = 0);
> for (p = _invl_gen_head;; p = prev.next) {
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic booting with if_tap_load="YES" in loader.conf
On Sat, May 18, 2019 at 05:38:15PM +0300, Konstantin Belousov wrote:
> On Sat, May 18, 2019 at 10:24:36AM -0400, Mark Johnston wrote:
> > On Sat, May 18, 2019 at 11:55:46AM +0300, Konstantin Belousov wrote:
> > > On Sat, May 18, 2019 at 01:33:28AM -0400, Mark Johnston wrote:
> > > > On Fri, May 17, 2019 at 10:18:57PM -0600, Rebecca Cran wrote:
> > > > > I just updated from r346856 to r347950 and ran into a new panic,
> > > > > caused
> > > > > by having if_tap_load="YES" in /boot/loader.conf - because it's
> > > > > already
> > > > > built-in to the kernel:
> > > >
> > > > I think this patch should fix the panic, but I only compile-tested it.
> > > > I considered having the logic live in preload_delete_name() instead, but
> > > > the boot-time ucode code must still defer the deletion somewhat.
> > >
> > > Try this instead. I will revert r347931 after this landed, or could keep
> > > it alone.
> >
> > I have no strong feeling either way.
> >
> > > diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
> > > index 1cf09dc5cb7..03fe8a5d096 100644
> > > --- a/sys/amd64/amd64/machdep.c
> > > +++ b/sys/amd64/amd64/machdep.c
> > > @@ -1616,6 +1616,13 @@ hammer_time(u_int64_t modulep, u_int64_t physfree)
> > > bzero((void *)thread0.td_kstack, kstack0_sz);
> > > physfree += kstack0_sz;
> > >
> > > + /*
> > > + * Initialize enough of thread0 for delayed invalidation to
> > > + * work very early. Rely on thread0.td_base_pri
> > > + * zero-initialization, it is reset to PVM at proc0_init().
> > > + */
> > > + pmap_thread_init_invl_gen();
> > > +
> >
> > I think pmap_thread_init_invl_gen() also needs to initialize
> > invl_gen->saved_pri to 0.
> It is zero-initialized, same as td_base_pri. The call to
> pmap_thread_init_invl_gen() is needed because _INVALID bit must be set,
> which is cleared by default.
I now think that you mean something else, that invl_gen.saved_pri must
be set on each entry to invl_start_u(). Otherwise invl_finish_u() might
act on the priority from the previous DI block.
diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
index 1cf09dc5cb7..03fe8a5d096 100644
--- a/sys/amd64/amd64/machdep.c
+++ b/sys/amd64/amd64/machdep.c
@@ -1616,6 +1616,13 @@ hammer_time(u_int64_t modulep, u_int64_t physfree)
bzero((void *)thread0.td_kstack, kstack0_sz);
physfree += kstack0_sz;
+ /*
+* Initialize enough of thread0 for delayed invalidation to
+* work very early. Rely on thread0.td_base_pri
+* zero-initialization, it is reset to PVM at proc0_init().
+*/
+ pmap_thread_init_invl_gen();
+
/*
* make gdt memory segments
*/
diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
index 7997a9f65dc..89ba9da19d8 100644
--- a/sys/amd64/amd64/pmap.c
+++ b/sys/amd64/amd64/pmap.c
@@ -700,16 +700,17 @@ pmap_delayed_invl_start_u(void)
invl_gen = >td_md.md_invl_gen;
PMAP_ASSERT_NOT_IN_DI();
lock_delay_arg_init(, _delay);
- thread_lock(td);
+ invl_gen->saved_pri = 0;
pri = td->td_base_pri;
- if (pri < PVM) {
- invl_gen->saved_pri = 0;
- } else {
- invl_gen->saved_pri = pri;
- sched_prio(td, PVM);
+ if (pri > PVM) {
+ thread_lock(td);
+ pri = td->td_base_pri;
+ if (pri > PVM) {
+ invl_gen->saved_pri = pri;
+ sched_prio(td, PVM);
+ }
+ thread_unlock(td);
}
- thread_unlock(td);
-
again:
PV_STAT(i = 0);
for (p = _invl_gen_head;; p = prev.next) {
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic booting with if_tap_load="YES" in loader.conf
On Sat, May 18, 2019 at 10:24:36AM -0400, Mark Johnston wrote: > On Sat, May 18, 2019 at 11:55:46AM +0300, Konstantin Belousov wrote: > > On Sat, May 18, 2019 at 01:33:28AM -0400, Mark Johnston wrote: > > > On Fri, May 17, 2019 at 10:18:57PM -0600, Rebecca Cran wrote: > > > > I just updated from r346856 to r347950 and ran into a new panic, caused > > > > by having if_tap_load="YES" in /boot/loader.conf - because it's already > > > > built-in to the kernel: > > > > > > I think this patch should fix the panic, but I only compile-tested it. > > > I considered having the logic live in preload_delete_name() instead, but > > > the boot-time ucode code must still defer the deletion somewhat. > > > > Try this instead. I will revert r347931 after this landed, or could keep > > it alone. > > I have no strong feeling either way. > > > diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c > > index 1cf09dc5cb7..03fe8a5d096 100644 > > --- a/sys/amd64/amd64/machdep.c > > +++ b/sys/amd64/amd64/machdep.c > > @@ -1616,6 +1616,13 @@ hammer_time(u_int64_t modulep, u_int64_t physfree) > > bzero((void *)thread0.td_kstack, kstack0_sz); > > physfree += kstack0_sz; > > > > + /* > > +* Initialize enough of thread0 for delayed invalidation to > > +* work very early. Rely on thread0.td_base_pri > > +* zero-initialization, it is reset to PVM at proc0_init(). > > +*/ > > + pmap_thread_init_invl_gen(); > > + > > I think pmap_thread_init_invl_gen() also needs to initialize > invl_gen->saved_pri to 0. It is zero-initialized, same as td_base_pri. The call to pmap_thread_init_invl_gen() is needed because _INVALID bit must be set, which is cleared by default. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic booting with if_tap_load="YES" in loader.conf
On Sat, May 18, 2019 at 11:55:46AM +0300, Konstantin Belousov wrote:
> On Sat, May 18, 2019 at 01:33:28AM -0400, Mark Johnston wrote:
> > On Fri, May 17, 2019 at 10:18:57PM -0600, Rebecca Cran wrote:
> > > I just updated from r346856 to r347950 and ran into a new panic, caused
> > > by having if_tap_load="YES" in /boot/loader.conf - because it's already
> > > built-in to the kernel:
> >
> > I think this patch should fix the panic, but I only compile-tested it.
> > I considered having the logic live in preload_delete_name() instead, but
> > the boot-time ucode code must still defer the deletion somewhat.
>
> Try this instead. I will revert r347931 after this landed, or could keep
> it alone.
I have no strong feeling either way.
> diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
> index 1cf09dc5cb7..03fe8a5d096 100644
> --- a/sys/amd64/amd64/machdep.c
> +++ b/sys/amd64/amd64/machdep.c
> @@ -1616,6 +1616,13 @@ hammer_time(u_int64_t modulep, u_int64_t physfree)
> bzero((void *)thread0.td_kstack, kstack0_sz);
> physfree += kstack0_sz;
>
> + /*
> + * Initialize enough of thread0 for delayed invalidation to
> + * work very early. Rely on thread0.td_base_pri
> + * zero-initialization, it is reset to PVM at proc0_init().
> + */
> + pmap_thread_init_invl_gen();
> +
I think pmap_thread_init_invl_gen() also needs to initialize
invl_gen->saved_pri to 0.
> /*
>* make gdt memory segments
>*/
> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> index 7997a9f65dc..ecd701399fc 100644
> --- a/sys/amd64/amd64/pmap.c
> +++ b/sys/amd64/amd64/pmap.c
> @@ -700,9 +700,12 @@ pmap_delayed_invl_start_u(void)
> invl_gen = >td_md.md_invl_gen;
> PMAP_ASSERT_NOT_IN_DI();
> lock_delay_arg_init(, _delay);
> + pri = td->td_base_pri;
> + if (pri <= PVM)
> + goto again;
> thread_lock(td);
> pri = td->td_base_pri;
> - if (pri < PVM) {
> + if (pri <= PVM) {
> invl_gen->saved_pri = 0;
> } else {
> invl_gen->saved_pri = pri;
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic booting with if_tap_load="YES" in loader.conf
On 2019-05-18 02:55, Konstantin Belousov wrote: > Try this instead. I will revert r347931 after this landed, or could keep > it alone. That works - thanks! -- Rebecca Cran ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic booting with if_tap_load="YES" in loader.conf
On Sat, May 18, 2019 at 01:33:28AM -0400, Mark Johnston wrote:
> On Fri, May 17, 2019 at 10:18:57PM -0600, Rebecca Cran wrote:
> > I just updated from r346856 to r347950 and ran into a new panic, caused
> > by having if_tap_load="YES" in /boot/loader.conf - because it's already
> > built-in to the kernel:
>
> I think this patch should fix the panic, but I only compile-tested it.
> I considered having the logic live in preload_delete_name() instead, but
> the boot-time ucode code must still defer the deletion somewhat.
Try this instead. I will revert r347931 after this landed, or could keep
it alone.
diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
index 1cf09dc5cb7..03fe8a5d096 100644
--- a/sys/amd64/amd64/machdep.c
+++ b/sys/amd64/amd64/machdep.c
@@ -1616,6 +1616,13 @@ hammer_time(u_int64_t modulep, u_int64_t physfree)
bzero((void *)thread0.td_kstack, kstack0_sz);
physfree += kstack0_sz;
+ /*
+* Initialize enough of thread0 for delayed invalidation to
+* work very early. Rely on thread0.td_base_pri
+* zero-initialization, it is reset to PVM at proc0_init().
+*/
+ pmap_thread_init_invl_gen();
+
/*
* make gdt memory segments
*/
diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
index 7997a9f65dc..ecd701399fc 100644
--- a/sys/amd64/amd64/pmap.c
+++ b/sys/amd64/amd64/pmap.c
@@ -700,9 +700,12 @@ pmap_delayed_invl_start_u(void)
invl_gen = >td_md.md_invl_gen;
PMAP_ASSERT_NOT_IN_DI();
lock_delay_arg_init(, _delay);
+ pri = td->td_base_pri;
+ if (pri <= PVM)
+ goto again;
thread_lock(td);
pri = td->td_base_pri;
- if (pri < PVM) {
+ if (pri <= PVM) {
invl_gen->saved_pri = 0;
} else {
invl_gen->saved_pri = pri;
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic booting with if_tap_load="YES" in loader.conf
On Fri, May 17, 2019 at 10:18:57PM -0600, Rebecca Cran wrote:
> I just updated from r346856 to r347950 and ran into a new panic, caused
> by having if_tap_load="YES" in /boot/loader.conf - because it's already
> built-in to the kernel:
I think this patch should fix the panic, but I only compile-tested it.
I considered having the logic live in preload_delete_name() instead, but
the boot-time ucode code must still defer the deletion somewhat.
diff --git a/sys/kern/link_elf.c b/sys/kern/link_elf.c
index 6ceb34d66b74..10b28d5d375c 100644
--- a/sys/kern/link_elf.c
+++ b/sys/kern/link_elf.c
@@ -1179,11 +1179,41 @@ link_elf_unload_file(linker_file_t file)
free(ef->typoff, M_LINKER);
}
+struct pending_unload {
+ charpathname[MAXPATHLEN];
+ SLIST_ENTRY(pending_unload) next;
+};
+SLIST_HEAD(, pending_unload) pending = SLIST_HEAD_INITIALIZER(pending);
+
static void
-link_elf_unload_preload(linker_file_t file)
+link_elf_unload_pending(void *arg __unused)
{
- if (file->pathname != NULL)
+ struct pending_unload *file;
+
+ while ((file = SLIST_FIRST()) != NULL) {
preload_delete_name(file->pathname);
+ SLIST_REMOVE_HEAD(, next);
+ free(file, M_LINKER);
+ }
+}
+SYSINIT(unload_pending, SI_SUB_CONFIGURE + 1, SI_ORDER_ANY,
+link_elf_unload_pending, NULL);
+
+static void
+link_elf_unload_preload(linker_file_t lf)
+{
+ struct pending_unload *file;
+
+ if (lf->pathname != NULL) {
+ if (!cold) {
+ preload_delete_name(lf->pathname);
+ return;
+ }
+ file = malloc(sizeof(*file), M_LINKER, M_WAITOK);
+ (void)strlcpy(file->pathname, lf->pathname,
+ sizeof(file->pathname));
+ SLIST_INSERT_HEAD(, file, next);
+ }
}
static const char *
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
