[patch] ser_gigaset: return -ENOMEM on error instead of success

[patch] ser_gigaset: return -ENOMEM on error instead of success

[Dan Carpenter]

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.

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

Re: [patch] ser_gigaset: return -ENOMEM on error instead of success

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

> 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

Re: [patch] ser_gigaset: return -ENOMEM on error instead of success

[Tilman Schmidt]

[-- Attachment #1.1: Type: text/plain, Size: 1067 bytes --]

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

-- 
Tilman Schmidt                              E-Mail: tilman@imap.cc
Bonn, Germany
Nous, on a des fleurs et des bougies pour nous protéger.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [patch] ser_gigaset: return -ENOMEM on error instead of success

[Paul Bolle]

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

Re: [patch] ser_gigaset: return -ENOMEM on error instead of success

[Tilman Schmidt]

[-- Attachment #1.1: Type: text/plain, Size: 1173 bytes --]

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

-- 
Tilman Schmidt                              E-Mail: tilman@imap.cc
Bonn, Germany
Nous, on a des fleurs et des bougies pour nous protéger.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [patch] ser_gigaset: return -ENOMEM on error instead of success

[David Miller]

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.

Re: [patch] ser_gigaset: return -ENOMEM on error instead of success

[Paul Bolle]

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