lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6205819a-af39-8cd8-db87-f3fe047ff064@gmail.com>
Date:   Thu, 14 Mar 2019 16:52:20 +0200
From:   Oleksandr Andrushchenko <andr2000@...il.com>
To:     Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        netdev@...r.kernel.org, xen-devel@...ts.xenproject.org,
        linux-kernel@...r.kernel.org, jgross@...e.com,
        sstabellini@...nel.org, davem@...emloft.net
Cc:     Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>,
        Volodymyr Babchuk <Volodymyr_Babchuk@...m.com>
Subject: Re: [Xen-devel][PATCH] xen/netfront: Remove unneeded .resume callback

On 3/14/19 4:47 PM, Boris Ostrovsky wrote:
> On 3/14/19 9:17 AM, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>
>>
>> Currently on driver resume we remove all the network queues and
>> destroy shared Tx/Rx rings leaving the driver in its current state
>> and never signaling the backend of this frontend's state change.
>> This leads to the number of consequences:
>> - when frontend withdraws granted references to the rings etc. it cannot
>>    be cleanly done as the backend still holds those (it was not told to
>>    free the resources)
>> - it is not possible to resume driver operation as all the communication
>>    means with the backned were destroyed by the frontend, thus
>>    making the frontend appear to the guest OS as functional, but
>>    not really.
>
> What do you mean? Are you saying that after resume you lose connectivity?
Exactly, if you take a look at the .resume callback as it is now
what it does it destroys the rings etc. and never notifies the backend
of that, e.g. it stays in, say, connected state with communication
channels destroyed. It never goes into any other Xen bus state, so there is
no way its state machine can help recovering.
>
> -boris
>
>
>> Fix this by not destroying communication channels/rings on driver
>> resume.
>>
>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>
>> ---
>>   drivers/net/xen-netfront.c | 17 -----------------
>>   1 file changed, 17 deletions(-)
>>
>> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
>> index c914c24f880b..2ca162048da4 100644
>> --- a/drivers/net/xen-netfront.c
>> +++ b/drivers/net/xen-netfront.c
>> @@ -1422,22 +1422,6 @@ static void xennet_disconnect_backend(struct netfront_info *info)
>>   	}
>>   }
>>   
>> -/**
>> - * We are reconnecting to the backend, due to a suspend/resume, or a backend
>> - * driver restart.  We tear down our netif structure and recreate it, but
>> - * leave the device-layer structures intact so that this is transparent to the
>> - * rest of the kernel.
>> - */
>> -static int netfront_resume(struct xenbus_device *dev)
>> -{
>> -	struct netfront_info *info = dev_get_drvdata(&dev->dev);
>> -
>> -	dev_dbg(&dev->dev, "%s\n", dev->nodename);
>> -
>> -	xennet_disconnect_backend(info);
>> -	return 0;
>> -}
>> -
>>   static int xen_net_read_mac(struct xenbus_device *dev, u8 mac[])
>>   {
>>   	char *s, *e, *macstr;
>> @@ -2185,7 +2169,6 @@ static struct xenbus_driver netfront_driver = {
>>   	.ids = netfront_ids,
>>   	.probe = netfront_probe,
>>   	.remove = xennet_remove,
>> -	.resume = netfront_resume,
>>   	.otherend_changed = netback_changed,
>>   };
>>   

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ