linux-kernel - Re: [PATCH] xen-netfront: remove warning when unloading module

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]

Date:   Mon, 20 Nov 2017 12:17:11 +0100
From:   Juergen Gross <jgross@...e.com>
To:     Wei Liu <wei.liu2@...rix.com>, Eduardo Otubo <otubo@...hat.com>
Cc:     xen-devel@...ts.xenproject.org, netdev@...r.kernel.org,
        paul.durrant@...rix.com, linux-kernel@...r.kernel.org,
        vkuznets@...hat.com, cavery@...hat.com, cheshi@...hat.com,
        mgamal@...hat.com, Boris Ostrovsky <boris.ostrovsky@...cle.com>
Subject: Re: [PATCH] xen-netfront: remove warning when unloading module

On 20/11/17 11:49, Wei Liu wrote:
> CC netfront maintainers.
> 
> On Mon, Nov 20, 2017 at 11:41:09AM +0100, Eduardo Otubo wrote:
>> When unloading module xen_netfront from guest, dmesg would output
>> warning messages like below:
>>
>>   [  105.236836] xen:grant_table: WARNING: g.e. 0x903 still in use!
>>   [  105.236839] deferring g.e. 0x903 (pfn 0x35805)
>>
>> This problem relies on netfront and netback being out of sync. By the time
>> netfront revokes the g.e.'s netback didn't have enough time to free all of
>> them, hence displaying the warnings on dmesg.
>>
>> The trick here is to make netfront to wait until netback frees all the g.e.'s
>> and only then continue to cleanup for the module removal, and this is done by
>> manipulating both device states.
>>
>> Signed-off-by: Eduardo Otubo <otubo@...hat.com>
>> ---
>>  drivers/net/xen-netfront.c | 11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
>> index 8b8689c6d887..b948e2a1ce40 100644
>> --- a/drivers/net/xen-netfront.c
>> +++ b/drivers/net/xen-netfront.c
>> @@ -2130,6 +2130,17 @@ static int xennet_remove(struct xenbus_device *dev)
>>  
>>  	dev_dbg(&dev->dev, "%s\n", dev->nodename);
>>  
>> +	xenbus_switch_state(dev, XenbusStateClosing);
>> +	while (xenbus_read_driver_state(dev->otherend) != XenbusStateClosing){
>> +		cpu_relax();
>> +		schedule();
>> +	}
>> +	xenbus_switch_state(dev, XenbusStateClosed);
>> +	while (dev->xenbus_state != XenbusStateClosed){
>> +		cpu_relax();
>> +		schedule();
>> +	}

I really don't like the busy waits.

Can't you use e.g. a wait queue and wait_event_interruptible() instead?

BTW: what happens if the device is already in closed state if you enter
xennet_remove()? In case this is impossible, please add a comment to
indicate you've thought about that case.

Other than that: you should run ./scripts/checkpatch.p1 against your
patch to avoid common style problems.


Juergen