Linux-Renesas-SoC Archive on lore.kernel.org
 help / color / Atom feed
From: Ulrich Hecht <uli@fpond.eu>
To: David Miller <davem@davemloft.net>, uli+renesas@fpond.eu
Cc: linux-renesas-soc@vger.kernel.org, netdev@vger.kernel.org,
	sergei.shtylyov@cogentembedded.com,
	niklas.soderlund@ragnatech.se, wsa@the-dreams.de,
	horms@verge.net.au, magnus.damm@gmail.com
Subject: Re: [PATCH v2] ravb: implement MTU change while device is up
Date: Fri, 14 Jun 2019 17:28:09 +0200 (CEST)
Message-ID: <1736739012.636692.1560526089090@webmail.strato.com> (raw)
In-Reply-To: <20190605.190825.2245741686094611389.davem@davemloft.net>


> On June 6, 2019 at 4:08 AM David Miller <davem@davemloft.net> wrote:
> 
> 
> From: Ulrich Hecht <uli+renesas@fpond.eu>
> Date: Wed,  5 Jun 2019 17:14:20 +0200
> 
> > @@ -1811,11 +1811,14 @@ static int ravb_do_ioctl(struct net_device *ndev, struct ifreq *req, int cmd)
> >  static int ravb_change_mtu(struct net_device *ndev, int new_mtu)
> >  {
> >  	if (netif_running(ndev))
> > -		return -EBUSY;
> > +		ravb_close(ndev);
> >  
> >  	ndev->mtu = new_mtu;
> >  	netdev_update_features(ndev);
> >  
> > +	if (netif_running(ndev))
> > +		return ravb_open(ndev);
> > +
> 
> And if ravb_open() fails?  The user sees a failure, but to the user the failure
> means the MTU change can't be done, yet the device has the new MTU set still.
> 
> This really is terrible behavior.
> 
> If you must do a prepare/commit kind of sequence for this to work properly if
> you are going to go down the road of taking the device down to change the MTU
> when the device is UP.

So would rolling back the MTU change in case of a re-open failure be acceptable?

If so, is there additional action that needs to be taken if a device unexpectedly goes down as a side-effect of an MTU change?

CU
Uli

      reply index

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-05 15:14 Ulrich Hecht
2019-06-05 15:16 ` Geert Uytterhoeven
2019-06-05 17:27 ` Sergei Shtylyov
2019-06-06  2:08 ` David Miller
2019-06-14 15:28   ` Ulrich Hecht [this message]

Reply instructions:

You may reply publically 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=1736739012.636692.1560526089090@webmail.strato.com \
    --to=uli@fpond.eu \
    --cc=davem@davemloft.net \
    --cc=horms@verge.net.au \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=niklas.soderlund@ragnatech.se \
    --cc=sergei.shtylyov@cogentembedded.com \
    --cc=uli+renesas@fpond.eu \
    --cc=wsa@the-dreams.de \
    /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

Linux-Renesas-SoC Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-renesas-soc/0 linux-renesas-soc/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-renesas-soc linux-renesas-soc/ https://lore.kernel.org/linux-renesas-soc \
		linux-renesas-soc@vger.kernel.org linux-renesas-soc@archiver.kernel.org
	public-inbox-index linux-renesas-soc


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-renesas-soc


AGPL code for this site: git clone https://public-inbox.org/ public-inbox