| Message ID | 20161207112203.GC5507@elgon.mountain |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
On Wed, 2016-12-07 at 14:22 +0300, Dan Carpenter wrote: > If we can't allocate the resources in gigaset_initdriver() then we > should return -ENOMEM instead of zero. That's entirely correct. > Fixes: 2869b23e4b95 ("[PATCH] drivers/isdn/gigaset: new M101 driver (v2)") > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> > --- > Ancient code. For ancient hardware. I'll be back (probably tomorrow) after a short test to see whether this really needs to go into stable. It almost certainly should, but I'd like to first see the mess the current code leaves behind once gigaset_initdriver() fails before saying so. Thanks for reporting this! Paul Bolle
Am 07.12.2016 um 20:06 schrieb Paul Bolle: > On Wed, 2016-12-07 at 14:22 +0300, Dan Carpenter wrote: >> If we can't allocate the resources in gigaset_initdriver() then we >> should return -ENOMEM instead of zero. > > That's entirely correct. Agree. > I'll be back (probably tomorrow) after a short test to see whether this really > needs to go into stable. It almost certainly should, but I'd like to first see > the mess the current code leaves behind once gigaset_initdriver() fails before > saying so. Not much of a mess, I reckon. Everything that has been allocated and registered up to that point is properly deallocated and unregistered. The code just fails to tell the kernel that module initialization has failed, so the module remains loaded even though it can never be called because it isn't hooked anywhere. That's a nuisance and a waste of RAM, but not much more. HTH Tilman
Hi Tilman, On Wed, 2016-12-07 at 21:57 +0100, Tilman Schmidt wrote: > Not much of a mess, I reckon. Everything that has been allocated and > registered up to that point is properly deallocated and unregistered. > The code just fails to tell the kernel that module initialization has > failed, so the module remains loaded even though it can never be > called because it isn't hooked anywhere. That's a nuisance and a > waste of RAM, but not much more. Yes. But then the removal of the module, which is the only reasonable thing to do after all this has happened, seems to trigger a WARN in driver_unregister(). And it's that WARN that I think requires the entire stable song and dance. Otherwise it would be, as far as I can tell, a hard to hit problem in an obscure driver without any side effects. Paul Bolle
Hi Paul, Am 07.12.2016 um 22:08 schrieb Paul Bolle: > On Wed, 2016-12-07 at 21:57 +0100, Tilman Schmidt wrote: >> Not much of a mess, I reckon. Everything that has been allocated and >> registered up to that point is properly deallocated and unregistered. >> The code just fails to tell the kernel that module initialization has >> failed, so the module remains loaded even though it can never be >> called because it isn't hooked anywhere. That's a nuisance and a >> waste of RAM, but not much more. > > Yes. > > But then the removal of the module, which is the only reasonable thing to do > after all this has happened, seems to trigger a WARN in driver_unregister(). > And it's that WARN that I think requires the entire stable song and dance. Ah, yes, of course, because driver_unregister() has already been run in the failure path of module_init and is now called a second time. Not sure how much evil that does beyond the WARN, but I agree it's worth investigating. Best regards, Tilman
From: Dan Carpenter <dan.carpenter@oracle.com> Date: Wed, 7 Dec 2016 14:22:03 +0300 > If we can't allocate the resources in gigaset_initdriver() then we > should return -ENOMEM instead of zero. > > Fixes: 2869b23e4b95 ("[PATCH] drivers/isdn/gigaset: new M101 driver (v2)") > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Applied and queued up for -stable, thanks.
On Wed, 2016-12-07 at 23:04 +0100, Tilman Schmidt wrote: > Not sure how much evil that does beyond the WARN, but I agree it's > worth investigating. For the record: NULL pointer dereference in tty_unregister_ldisc() on module unload. rmmod got killed, module refcount set -1, etc. My test box locked up twice some random period after all that. So quite a bit of a mess, all in all. Paul Bolle
diff --git a/drivers/isdn/gigaset/ser-gigaset.c b/drivers/isdn/gigaset/ser-gigaset.c index d1f8ab915b15..b90776ef56ec 100644 --- a/drivers/isdn/gigaset/ser-gigaset.c +++ b/drivers/isdn/gigaset/ser-gigaset.c @@ -755,8 +755,10 @@ static int __init ser_gigaset_init(void) driver = gigaset_initdriver(GIGASET_MINOR, GIGASET_MINORS, GIGASET_MODULENAME, GIGASET_DEVNAME, &ops, THIS_MODULE); - if (!driver) + if (!driver) { + rc = -ENOMEM; goto error; + } rc = tty_register_ldisc(N_GIGASET_M101, &gigaset_ldisc); if (rc != 0) {
If we can't allocate the resources in gigaset_initdriver() then we should return -ENOMEM instead of zero. Fixes: 2869b23e4b95 ("[PATCH] drivers/isdn/gigaset: new M101 driver (v2)") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> --- Ancient code.