Re: [PATCH 3/5] xen-pcifront: handle backend CLOSED without CLOSING

From: Bjorn Helgaas
Date: Fri Nov 30 2012 - 13:42:06 EST


On Fri, Oct 19, 2012 at 6:59 AM, Konrad Rzeszutek Wilk
<konrad.wilk@xxxxxxxxxx> wrote:
> On Thu, Oct 18, 2012 at 11:03:36AM +0100, David Vrabel wrote:
>> From: David Vrabel <david.vrabel@xxxxxxxxxx>
>>
>> Backend drivers shouldn't transistion to CLOSED unless the frontend is
>> CLOSED. If a backend does transition to CLOSED too soon then the
>> frontend may not see the CLOSING state and will not properly shutdown.
>>
>> So, treat an unexpected backend CLOSED state the same as CLOSING.
>>
>> Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx>
>> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
>> ---
>> Cc: linux-pci@xxxxxxxxxxxxxxx
>> Cc: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
>
> Bjorn, do you want me to prep a git pull with this patch
> or can I have your Ack to put it my tree and have it part of my
> git pull to Linus?

Sorry, I missed this. I can put it in my -next branch for the v3.8
merge window. Would that work for you?

>> ---
>> drivers/pci/xen-pcifront.c | 5 ++++-
>> 1 files changed, 4 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
>> index 0aab85a..a0c7312 100644
>> --- a/drivers/pci/xen-pcifront.c
>> +++ b/drivers/pci/xen-pcifront.c
>> @@ -1068,13 +1068,16 @@ static void __init_refok pcifront_backend_changed(struct xenbus_device *xdev,
>> case XenbusStateInitialising:
>> case XenbusStateInitWait:
>> case XenbusStateInitialised:
>> - case XenbusStateClosed:
>> break;
>>
>> case XenbusStateConnected:
>> pcifront_try_connect(pdev);
>> break;
>>
>> + case XenbusStateClosed:
>> + if (xdev->state == XenbusStateClosed)
>> + break;
>> + /* Missed the backend's CLOSING state -- fallthrough */
>> case XenbusStateClosing:
>> dev_warn(&xdev->dev, "backend going away!\n");
>> pcifront_try_disconnect(pdev);
>> --
>> 1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/