All of lore.kernel.org
 help / color / mirror / Atom feed
From: Liang Li <liang.li@windriver.com>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: netdev@vger.kernel.org, avorontsov@ru.mvista.com,
	davem@davemloft.net, linuxppc-dev@ozlabs.org
Subject: Re: [v2 PATCH] ucc_geth: fix ethtool set ring param bug
Date: Fri, 3 Sep 2010 09:20:29 +0800	[thread overview]
Message-ID: <20100903012029.GB9901@localhost> (raw)
In-Reply-To: <1283450699.2272.18.camel@achroite.uk.solarflarecom.com>

On Thu, Sep 02, 2010 at 07:04:59PM +0100, Ben Hutchings wrote:
> On Fri, 2010-09-03 at 00:02 +0800, Liang Li wrote:
> > It's common sense that when we should do change to driver ring
> > desc/buffer etc only after 'stop/shutdown' the device. When we
> > do change while devices/driver is running, kernel oops occur:
> [...]
> > +		printk(KERN_INFO "Reactivating interface %s.\n", netdev->name);
> > +		ret = ucc_geth_open(netdev);
> > +		if (ret) {
> > +			printk(KERN_WARNING "uec_set_ringparam: set ring param for running"
> > +					" interface %s failed. Please try again.\n", netdev->name);
> > +			dev_close(netdev);
> [...]
> 
> If ucc_geth_open() failed you MUST NOT call ucc_geth_close(), but that
> is what dev_close() is going to do.  But the device is still flagged as
> running so 'ifconfig down' is going to call dev_close() as well.  There
> is no way out.

dev_close is safe enough IMHO. Call dev_close repeatly won't cause
problem though.

> 
> This is why I said you must call dev_close() and then dev_open()
> instead.  Then if dev_open() fails, just print the error, e.g.:
> 
>                dev_close(netdev);
>                ret = dev_open(netdev);
>                if (ret)
>                        netdev_err(netdev,
>                                   "uec_set_ringparam: failed to restart"
>                                   " interface with new ring parameters\n");
> 
> (And I think this really is a serious error, hence the 'err' rather than
> 'warning' severity.)

I checked NIC drivers in drivers/net, there is no such:

	dev_close(netdev);
	ret = dev_open(netdev)
	if (ret)
		netdev_err(...);

Instead, there are:

	nic_driver_close/down(netdev);
	ret = nic_driver_open/restart(netdev);
	if (ret) {
		waring;
		dev_close(netdev);
	}

> 
> (By the way, I noticed there are other places where ucc_geth_close() and
> ucc_geth_open() are called, without error checking.  These are also
> bugs, but that doesn't justify adding new bugs.)

I think I did not invite new bugs, as I mentioned before, can you show
scenario that the reopen fail and perfect cleanup way?

Thanks,
				-Liang Li

> 
> Ben.
> 
> -- 
> Ben Hutchings, Senior Software Engineer, Solarflare Communications
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.

WARNING: multiple messages have this Message-ID (diff)
From: Liang Li <liang.li@windriver.com>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: leoli@freescale.com, davem@davemloft.net,
	avorontsov@ru.mvista.com, netdev@vger.kernel.org,
	linuxppc-dev@ozlabs.org
Subject: Re: [v2 PATCH] ucc_geth: fix ethtool set ring param bug
Date: Fri, 3 Sep 2010 09:20:29 +0800	[thread overview]
Message-ID: <20100903012029.GB9901@localhost> (raw)
In-Reply-To: <1283450699.2272.18.camel@achroite.uk.solarflarecom.com>

On Thu, Sep 02, 2010 at 07:04:59PM +0100, Ben Hutchings wrote:
> On Fri, 2010-09-03 at 00:02 +0800, Liang Li wrote:
> > It's common sense that when we should do change to driver ring
> > desc/buffer etc only after 'stop/shutdown' the device. When we
> > do change while devices/driver is running, kernel oops occur:
> [...]
> > +		printk(KERN_INFO "Reactivating interface %s.\n", netdev->name);
> > +		ret = ucc_geth_open(netdev);
> > +		if (ret) {
> > +			printk(KERN_WARNING "uec_set_ringparam: set ring param for running"
> > +					" interface %s failed. Please try again.\n", netdev->name);
> > +			dev_close(netdev);
> [...]
> 
> If ucc_geth_open() failed you MUST NOT call ucc_geth_close(), but that
> is what dev_close() is going to do.  But the device is still flagged as
> running so 'ifconfig down' is going to call dev_close() as well.  There
> is no way out.

dev_close is safe enough IMHO. Call dev_close repeatly won't cause
problem though.

> 
> This is why I said you must call dev_close() and then dev_open()
> instead.  Then if dev_open() fails, just print the error, e.g.:
> 
>                dev_close(netdev);
>                ret = dev_open(netdev);
>                if (ret)
>                        netdev_err(netdev,
>                                   "uec_set_ringparam: failed to restart"
>                                   " interface with new ring parameters\n");
> 
> (And I think this really is a serious error, hence the 'err' rather than
> 'warning' severity.)

I checked NIC drivers in drivers/net, there is no such:

	dev_close(netdev);
	ret = dev_open(netdev)
	if (ret)
		netdev_err(...);

Instead, there are:

	nic_driver_close/down(netdev);
	ret = nic_driver_open/restart(netdev);
	if (ret) {
		waring;
		dev_close(netdev);
	}

> 
> (By the way, I noticed there are other places where ucc_geth_close() and
> ucc_geth_open() are called, without error checking.  These are also
> bugs, but that doesn't justify adding new bugs.)

I think I did not invite new bugs, as I mentioned before, can you show
scenario that the reopen fail and perfect cleanup way?

Thanks,
				-Liang Li

> 
> Ben.
> 
> -- 
> Ben Hutchings, Senior Software Engineer, Solarflare Communications
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.

  reply	other threads:[~2010-09-03  1:18 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-30 14:47 [PATCH] ucc_geth: fix ethtool set ring param bug Liang Li
2010-08-31 14:41 ` Ben Hutchings
2010-08-31 14:41   ` Ben Hutchings
2010-08-31 15:16   ` Liang Li
2010-08-31 15:23     ` Ben Hutchings
2010-08-31 15:23       ` Ben Hutchings
2010-09-01  1:43 ` [v1 PATCH] " Liang Li
2010-09-01 13:42   ` Ben Hutchings
2010-09-01 13:42     ` Ben Hutchings
2010-09-02  0:50     ` Liang Li
2010-09-02  0:50       ` Liang Li
2010-09-02 11:11       ` Ben Hutchings
2010-09-02 11:11         ` Ben Hutchings
2010-09-02 15:48         ` Liang Li
2010-09-02 15:48           ` Liang Li
2010-09-02 16:32           ` Ben Hutchings
2010-09-02 16:32             ` Ben Hutchings
2010-09-02 16:02   ` [v2 " Liang Li
2010-09-02 18:04     ` Ben Hutchings
2010-09-02 18:04       ` Ben Hutchings
2010-09-03  1:20       ` Liang Li [this message]
2010-09-03  1:20         ` Liang Li
2010-09-06 20:22     ` David Miller
2010-09-06 20:22       ` David Miller

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=20100903012029.GB9901@localhost \
    --to=liang.li@windriver.com \
    --cc=avorontsov@ru.mvista.com \
    --cc=bhutchings@solarflare.com \
    --cc=davem@davemloft.net \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=netdev@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.