Date: Wed, 8 Jul 2015 08:37:06 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org Subject: FreeBSD_HEAD-tests - Build #1166 - Still Failing Message-ID: <106065565.132.1436344626789.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <920175061.129.1436325903607.JavaMail.jenkins@jenkins-9.freebsd.org> References: <920175061.129.1436325903607.JavaMail.jenkins@jenkins-9.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
FreeBSD_HEAD-tests - Build #1166 - Still Failing: Check console output at https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1166/ to view the results. From owner-freebsd-current@freebsd.org Wed Jul 8 09:09:34 2015 Return-Path: <owner-freebsd-current@freebsd.org> Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 963619954D4 for <freebsd-current@mailman.ysv.freebsd.org>; Wed, 8 Jul 2015 09:09:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0B2C711E0 for <freebsd-current@freebsd.org>; Wed, 8 Jul 2015 09:09:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t6899SMe010214 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 8 Jul 2015 12:09:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t6899SMe010214 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t6899Sf3010213; Wed, 8 Jul 2015 12:09:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 8 Jul 2015 12:09:28 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Ryan Stone <rysto32@gmail.com> Cc: Jack Vogel <jfvogel@gmail.com>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: How should a driver shutdown a taskqueue on detach? Message-ID: <20150708090928.GV2080@kib.kiev.ua> References: <CAFMmRNxLV0Uk9iT+U8rrPvn6aanSfEA6p577McM=_4xypaZr5w@mail.gmail.com> <CAFOYbckF7brPikTPaf+Zhdm-R9d0WzygY9-eUxnrmi3p+BFBoQ@mail.gmail.com> <CAFMmRNzLL-K0kw_cj==kWpiocOcBLzxU2o6ONGaZRiv5tdSHxQ@mail.gmail.com> <20150701213241.GG2080@kib.kiev.ua> <CAFMmRNyeEp0gccRAspkJNT_tFWZvJWEczNitB8nCyOzSWKZBWA@mail.gmail.com> <20150702070828.GH2080@kib.kiev.ua> <CAFMmRNxGqdmrfLc3U9BW4BWzM_PxN0NO0i0NNrbC_Qsgf=2wUw@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CAFMmRNxGqdmrfLc3U9BW4BWzM_PxN0NO0i0NNrbC_Qsgf=2wUw@mail.gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>; List-Post: <mailto:freebsd-current@freebsd.org> List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=subscribe> X-List-Received-Date: Wed, 08 Jul 2015 09:09:34 -0000 On Tue, Jul 07, 2015 at 07:52:56PM -0400, Ryan Stone wrote: > On Thu, Jul 2, 2015 at 3:08 AM, Konstantin Belousov <kostikbel@gmail.com> > wrote: > > > Having taskqueue_enqueue() which could silently (?) not enqueue the given > > task is huge and IMO risky change to the KPI. If doing it, I think > > that there should be a new function to enqueue, which is allowed to > > fail, unlike taskqueue_enqueue(). > > > > BTW, the man page for taskqueue(9) is wrong, taskqueue_enqueue(9) > > always succeed now and always returns 0 (ignoring the ushort overflow). > > > > That's fair, but I feel that a new enqueue function would be rather > intrusive for existing drivers. Maybe we should attach this from a > different angle. How about a taskqueue_quiesce() function, which must be > called on a blocked taskqueue (by taskqueue_block() ). taskqueue_quiesce() > would block until the taskqueue's thread has stopped running. Then I can > do: > > taskqueue_block() > taskqueue_quiesce() > taskqueue_cancel() > //... > taskqueue_free() I do not understand this. Might be it is something that I do not understand in the block mechanism. taskqueue_block() only prevents wakeups from taskqueue_enqueue() to happen. The enqueued task is still put in the task list, or its pending count is increased. If the taskqueue thread is running, and, in your case, the task reschedules itself (this might not exactly describe your case, but your case could sometimes reduces to this, I think), then your algorithm would livelock. I.e., I do not like the possibility of enqueueing the tasks after you started the shutdown sequence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?106065565.132.1436344626789.JavaMail.jenkins>