From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751375AbeAYJmz (ORCPT ); Thu, 25 Jan 2018 04:42:55 -0500 Received: from mga07.intel.com ([134.134.136.100]:3013 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751265AbeAYJmt (ORCPT ); Thu, 25 Jan 2018 04:42:49 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,411,1511856000"; d="scan'208";a="24616536" Message-ID: <5A69A72F.4000104@intel.com> Date: Thu, 25 Jan 2018 17:45:19 +0800 From: Wei Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Michael S. Tsirkin" CC: virtio-dev@lists.oasis-open.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, kvm@vger.kernel.org, linux-mm@kvack.org, mhocko@kernel.org, akpm@linux-foundation.org, pbonzini@redhat.com, liliang.opensource@gmail.com, yang.zhang.wz@gmail.com, quan.xu0@gmail.com, nilal@redhat.com, riel@redhat.com Subject: Re: [PATCH v24 2/2] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT References: <1516790562-37889-1-git-send-email-wei.w.wang@intel.com> <1516790562-37889-3-git-send-email-wei.w.wang@intel.com> <20180124183349-mutt-send-email-mst@kernel.org> In-Reply-To: <20180124183349-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/25/2018 01:15 AM, Michael S. Tsirkin wrote: > On Wed, Jan 24, 2018 at 06:42:42PM +0800, Wei Wang wrote: >> >> >> What is this doing? Basically handling the case where vq is broken? >> It's kind of ugly to tweak feature bits, most code assumes they never >> change. Please just return an error to caller instead and handle it >> there. >> >> You can then avoid sprinking the check for the feature bit >> all over the code. >> > > One thing I don't like about this one is that the previous request > will still try to run to completion. > > And it all seems pretty complex. > > How about: > - pass cmd id to a queued work > - queued work gets that cmd id, stores a copy and uses that, > re-checking periodically - stop if cmd id changes: > will replace report_free_page too since that's set to > stop. > > This means you do not reuse the queued cmd id also > for the buffer - which is probably for the best. Thanks for the suggestion. Please have a check how it's implemented in v25. Just a little reminder that work queue has internally ensured that there is no re-entrant of the same queued function. Best, Wei