mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Wei Liu <wei.liu2@citrix.com>, Eduardo Otubo <otubo@redhat.com>
Cc: xen-devel@lists.xenproject.org, netdev@vger.kernel.org,
	paul.durrant@citrix.com, linux-kernel@vger.kernel.org,
	vkuznets@redhat.com, cavery@redhat.com, cheshi@redhat.com,
	mgamal@redhat.com, Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [PATCH] xen-netfront: remove warning when unloading module
Date: Mon, 20 Nov 2017 12:17:11 +0100	[thread overview]
Message-ID: <feba2fdd-cab5-6794-6928-278697a5c3ff@suse.com> (raw)
In-Reply-To: <20171120104919.ziq45hikwbzlnvbo@citrix.com>

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@redhat.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

  reply	other threads:[~2017-11-20 11:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-20 10:41 Eduardo Otubo
2017-11-20 10:49 ` Wei Liu
2017-11-20 11:17   ` Juergen Gross [this message]
2017-11-20 12:59     ` Eduardo Otubo
2017-11-20 10:55 ` Paul Durrant
2017-11-20 12:56   ` 'Eduardo Otubo'
2017-11-22 11:44 ` kbuild test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=feba2fdd-cab5-6794-6928-278697a5c3ff@suse.com \
    --to=jgross@suse.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=cavery@redhat.com \
    --cc=cheshi@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgamal@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=otubo@redhat.com \
    --cc=paul.durrant@citrix.com \
    --cc=vkuznets@redhat.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®