Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 30 Mar 2020 21:59:05 -0400
From:      Mark Johnston <markj@freebsd.org>
To:        Li-Wen Hsu <lwhsu@freebsd.org>
Cc:        src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org>
Subject:   Re: svn commit: r359436 - in head/sys: kern net sys
Message-ID:  <20200331015905.GC65028@raichu>
In-Reply-To: <CAKBkRUxrzmqkDrsPXLWr%2B5d6djghR1jbr_Lg5RpvpanAzOxtKw@mail.gmail.com>
References:  <202003301422.02UEMrxL059978@repo.freebsd.org> <CAKBkRUxrzmqkDrsPXLWr%2B5d6djghR1jbr_Lg5RpvpanAzOxtKw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 31, 2020 at 09:40:51AM +0800, Li-Wen Hsu wrote:
> On Mon, Mar 30, 2020 at 10:32 PM Mark Johnston <markj@freebsd.org> wrote:
> >
> > Author: markj
> > Date: Mon Mar 30 14:22:52 2020
> > New Revision: 359436
> > URL: https://svnweb.freebsd.org/changeset/base/359436
> >
> > Log:
> >   Simplify taskqgroup inititialization.
> >
> >   taskqgroup initialization was broken into two steps:
> >
> >   1. allocate the taskqgroup structure, at SI_SUB_TASKQ;
> >   2. initialize taskqueues, start taskqueue threads, enqueue "binder"
> >      tasks to bind threads to specific CPUs, at SI_SUB_SMP.
> >
> >   Step 2 tries to handle the case where tasks have already been attached
> >   to a queue, by migrating them to their intended queue.  In particular,
> >   tasks can't be enqueued before step 2 has completed.  This breaks NFS
> >   mountroot on systems using an iflib-based driver when EARLY_AP_STARTUP
> >   is not defined, since mountroot happens before SI_SUB_SMP in this case.
> >
> >   Simplify initialization: do all initialization except for CPU binding at
> >   SI_SUB_TASKQ.  This means that until CPU binding is completed, group
> >   tasks may be executed on a CPU other than that to which they were bound,
> >   but this should not be a problem for existing users of the taskqgroup
> >   KPIs.
> >
> >   Reported by:  sbruno
> >   Tested by:    bdragon, sbruno
> >   MFC after:    1 month
> >   Sponsored by: The FreeBSD Foundation
> >   Differential Revision:        https://reviews.freebsd.org/D24188
> >
> > Modified:
> >   head/sys/kern/subr_gtaskqueue.c
> >   head/sys/net/iflib.c
> >   head/sys/sys/gtaskqueue.h
> 
> Hi Mark,
> 
> I see many "panic: deadlres_td_sleep_q: possible deadlock detected" in
> the CI after this commit:
> 
> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/14738/consoleFull
> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/14739/consoleFull
> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/14741/consoleFull
> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/14742/consoleFull
> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/14743/console
> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/14744/consoleFull
> 
> It seems could be triggered by sys.netinet6.frag6.*
> sys.netpfil.common.* sbin.pfctl.pfctl_test.* tests, and there are lots
> of test cases timed out.
> 
> Can you help check these?

I see, it is actually caused by r359438.  I'm looking at it now.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200331015905.GC65028>