From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752013AbcAEOt1 (ORCPT ); Tue, 5 Jan 2016 09:49:27 -0500 Received: from mx2.suse.de ([195.135.220.15]:38399 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751104AbcAEOtU (ORCPT ); Tue, 5 Jan 2016 09:49:20 -0500 Date: Tue, 5 Jan 2016 15:49:18 +0100 From: Petr Mladek To: "Michael S. Tsirkin" Cc: Tejun Heo , Rusty Russell , Jeff Epler , Jiri Kosina , virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 2/2] virtio_balloon: Use a workqueue instead of "vballoon" kthread Message-ID: <20160105144918.GF3178@pathway.suse.cz> References: <1449236271-10133-1-git-send-email-pmladek@suse.com> <1449236271-10133-3-git-send-email-pmladek@suse.com> <20160101121432-mutt-send-email-mst@redhat.com> <20160102114316.GC3660@htj.duckdns.org> <20160102213603.GA1703@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160102213603.GA1703@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat 2016-01-02 23:36:03, Michael S. Tsirkin wrote: > On Sat, Jan 02, 2016 at 06:43:16AM -0500, Tejun Heo wrote: > > On Fri, Jan 01, 2016 at 12:18:17PM +0200, Michael S. Tsirkin wrote: > > > > My initial idea was to use a dedicated workqueue. Michael S. Tsirkin > > > > @@ -563,7 +534,7 @@ static void virtballoon_remove(struct virtio_device *vdev) > > > > struct virtio_balloon *vb = vdev->priv; > > > > > > > > unregister_oom_notifier(&vb->nb); > > > > - kthread_stop(vb->thread); > > > > + cancel_work_sync(&vb->wq_work); > > > > > > OK but since job requeues itself, cancelling like this might not be enough. > > > > As long as there's no further external queueing, cancel_work_sync() is > > guaranteed to kill a self-requeueing work item. > > > > Thanks. > > I didn't realise this. Thanks! > > Unfortunately in this case, there can be further requeueing > if a stats request arrives. Please, is there any point where the stat requests are disabled for sure? I am not 100% sure but it might be after the reset() call: vb->vdev->config->reset(vb->vdev); Then we could split the kthread into two works: resizing and stats. The resizing work still must be canceled before leaking the balloon. But the stats work might be canceled after the reset() call. In fact, the solution with the two works looks even cleaner. Thanks for feedback, Petr