Skip to contentSkip to conversation

ser_gigaset: return -ENOMEM on error instead of success

PATCH In review Dan Carpenter 4 participants 7 messages Dec 7, 2016 – Dec 9, 2016

Subsystems (3)
Networking Network drivers Kernel janitors
lore
Share & tools
lore

Dan Carpenter

author
#0 lore raw

PATCH 1/1 ser_gigaset: return -ENOMEM on error instead of success

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 <[email protected]>

---
Ancient code.

drivers/isdn/gigaset/ser-gigaset.c +3 -1
index d1f8ab915b15..b90776ef56ec 100644
@@ -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) {
#1 lore raw
Quoted 2 lines · Dan Carpenter

If we can't allocate the resources in gigaset_initdriver() then we should return -ENOMEM instead of zero.

That's entirely correct.

Quoted 4 lines
Fixes 2869b23e4b95 ("[PATCH] drivers/isdn/gigaset: new M101 driver (v2)")
Signed-off-by Dan Carpenter <[email protected]>

---
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

#2 lore raw

Am 07.12.2016 um 20:06 schrieb Paul Bolle:

Quoted 5 lines · Dan Carpenter
Quoted 2 lines

If we can't allocate the resources in gigaset_initdriver() then we should return -ENOMEM instead of zero.

That's entirely correct.

Agree.

Quoted 4 lines

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

Signature · 3 lines
Tilman Schmidt                              E-Mail: [email protected]
Bonn, Germany
Nous, on a des fleurs et des bougies pour nous protéger.
#3 lore raw

Hi Tilman,

Quoted 6 lines · Tilman Schmidt

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

#4 lore raw

Hi Paul,

Am 07.12.2016 um 22:08 schrieb Paul Bolle:

Quoted 8 lines · Tilman Schmidt
Quoted 6 lines

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.

Quoted 5 lines

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

Signature · 3 lines
Tilman Schmidt                              E-Mail: [email protected]
Bonn, Germany
Nous, on a des fleurs et des bougies pour nous protéger.
#5 lore raw
Quoted 2 lines · Tilman Schmidt

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