All of lore.kernel.org
 help / color / mirror / Atom feed
From: Damien Riegel <damien.riegel@savoirfairelinux.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: linux-watchdog@vger.kernel.org, Wim Van Sebroeck <wim@iguana.be>,
	kernel@savoirfairelinux.com
Subject: Re: [PATCH] watchdog: core: factorize register error paths
Date: Tue, 24 Nov 2015 17:40:14 -0500	[thread overview]
Message-ID: <20151124224014.GA26851@localhost> (raw)
In-Reply-To: <20151124204548.GA14059@roeck-us.net>

On Tue, Nov 24, 2015 at 12:45:48PM -0800, Guenter Roeck wrote:
> Hi Damien,
> 
> On Tue, Nov 24, 2015 at 03:15:35PM -0500, Damien Riegel wrote:
> > The commit adding the reboot notifier in the core introduced a new error
> > path in __watchdog_register_device, making error paths quite redondant.
> > 
> s/redondant/redundant/
> 
> > This commit factorizes all error paths that do some cleanup.
> > 
> > Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
> > ---
> >  drivers/watchdog/watchdog_core.c | 27 +++++++++++++++------------
> >  1 file changed, 15 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/watchdog/watchdog_core.c b/drivers/watchdog/watchdog_core.c
> > index 551af04..aff17b1 100644
> > --- a/drivers/watchdog/watchdog_core.c
> > +++ b/drivers/watchdog/watchdog_core.c
> > @@ -241,20 +241,16 @@ static int __watchdog_register_device(struct watchdog_device *wdd)
> >  		wdd->id = id;
> >  
> >  		ret = watchdog_dev_register(wdd);
> > -		if (ret) {
> > -			ida_simple_remove(&watchdog_ida, id);
> > -			return ret;
> > -		}
> > +		if (ret)
> > +			goto remove_ida;
> >  	}
> >  
> >  	devno = wdd->cdev.dev;
> >  	wdd->dev = device_create(watchdog_class, wdd->parent, devno,
> >  					wdd, "watchdog%d", wdd->id);
> >  	if (IS_ERR(wdd->dev)) {
> > -		watchdog_dev_unregister(wdd);
> > -		ida_simple_remove(&watchdog_ida, id);
> >  		ret = PTR_ERR(wdd->dev);
> > -		return ret;
> > +		goto unregister_device;
> >  	}
> >  
> >  	if (test_bit(WDOG_STOP_ON_REBOOT, &wdd->status)) {
> > @@ -264,11 +260,7 @@ static int __watchdog_register_device(struct watchdog_device *wdd)
> >  		if (ret) {
> >  			dev_err(wdd->dev, "Cannot register reboot notifier (%d)\n",
> >  				ret);
> > -			watchdog_dev_unregister(wdd);
> > -			device_destroy(watchdog_class, devno);
> > -			ida_simple_remove(&watchdog_ida, wdd->id);
> > -			wdd->dev = NULL;
> > -			return ret;
> > +			goto unregister_device;
> >  		}
> >  	}
> >  
> > @@ -282,6 +274,17 @@ static int __watchdog_register_device(struct watchdog_device *wdd)
> >  	}
> >  
> >  	return 0;
> > +
> > +unregister_device:
> > +	watchdog_dev_unregister(wdd);
> > +	if (!IS_ERR(wdd->dev)) {
> > +		device_destroy(watchdog_class, devno);
> > +		wdd->dev = NULL;
> 
> Oddly enough this leaves wdd->dev in place if it is an ERR_PTR.
> While that was the case before, it might be better and more
> consistent to always set it to NULL.
> 
> I also wonder if it is really necessary to call watchdog_dev_unregister()
> first. Something like
> 
> destroy_device:
> 	device_destroy(watchdog_class, devno);
> unregister_watchdog:
> 	wdd->dev = NULL;
> 	watchdog_dev_unregister(wdd);
> 
> would be cleaner. Wonder why it isn't done in that order to start with.
> It should be possible; after all, the device is created only after 
> watchdog_dev_register() succeeded, so one should think that it makes
> sense to remove it first. Any idea ?

No idea why the device_destroy was done after watchdog_dev_unregister in
__watchdog_unregister_device, I think there is no reasons for that, and
it seems safe to reorder them.

  reply	other threads:[~2015-11-24 22:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-24 20:15 [PATCH] watchdog: core: factorize register error paths Damien Riegel
2015-11-24 20:45 ` Guenter Roeck
2015-11-24 22:40   ` Damien Riegel [this message]
2015-11-24 23:23     ` Guenter Roeck

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=20151124224014.GA26851@localhost \
    --to=damien.riegel@savoirfairelinux.com \
    --cc=kernel@savoirfairelinux.com \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=wim@iguana.be \
    /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.