From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752137AbcGYLJC (ORCPT ); Mon, 25 Jul 2016 07:09:02 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:27770 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751015AbcGYLI4 (ORCPT ); Mon, 25 Jul 2016 07:08:56 -0400 Message-ID: <5795F334.4040106@oracle.com> Date: Mon, 25 Jul 2016 19:08:36 +0800 From: Bob Liu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= CC: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, konrad.wilk@oracle.com, jgross@suse.com Subject: Re: [PATCH 3/3] xen-blkfront: dynamic configuration of per-vbd resources References: <20160721085756.ps4rtdns4xh35yii@mac> <57909F05.9030809@oracle.com> <20160722074506.l5nfcmqg3jzsmxzi@mac> <5791D6AC.1070604@oracle.com> <20160722093409.iwcmlubhou4rjjop@mac> <5791EAC4.2030309@oracle.com> <20160722114538.7un36zw7mrvcueob@mac> <57929BAF.4030304@oracle.com> <20160725092002.madb7j6ryn4jcoho@mac> <5795EA02.2090200@oracle.com> <20160725105314.aatqpi4rxaxntt5b@mac> In-Reply-To: <20160725105314.aatqpi4rxaxntt5b@mac> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/25/2016 06:53 PM, Roger Pau Monné wrote: ..[snip..] >>>> * We get the device lock and blk_mq_freeze_queue() in dynamic_reconfig_device(), >>>> and then have to release in blkif_recover() asynchronously which makes the code more difficult to readable. >>> >>> I'm not sure I'm following here, do you mean that you will pick the lock in >>> dynamic_reconfig_device and release it in blkif_recover? Why wouldn't you >> >> Yes. >> >>> release the lock in dynamic_reconfig_device after doing whatever is needed? >>> >> >> Both 'dynamic configuration' and migration:xenbus_dev_resume() use { blkfront_resume(); blkif_recover() } and depends on the change of xbdev->state. >> If they happen simultaneously, the State machine of xbdev->state is going to be a mess and very difficult to track. >> >> The lock(actually a mutex) is like a big lock to make sure no race would happen at all. > > So the only thing that you should do is set the frontend state to closed and > wait for the backend to also switch to state closed, and then switch the > frontend state to init again in order to trigger a reconnection. > But if migration:xenbus_dev_resume() is triggered at the same time, any state be set might be changed. ===== E.g Dynamic_reconfig_device: Migration:xenbus_dev_resume() Set the frontend state to closed ^^^^ frontend state will be reset to XenbusStateInitialising by xenbus_dev_resume() Wait for the backend to also switch to state closed ===== Similar situation may happen at any other place regarding set the state. > You are right that all this process depends on the state being updated > correctly, but I don't see how's that different from a normal connection or > resume, and we don't seem to have races there. >