lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ADE657CA350FB648AAC2C43247A983F0020698F2EECE@AUSP01VMBX24.collaborationhost.net>
Date:	Mon, 2 Jul 2012 10:57:22 -0500
From:	H Hartley Sweeten <hartleys@...ionengravers.com>
To:	Ian Abbott <abbotti@....co.uk>,
	Devendra Naga <devendra.aaru@...il.com>
CC:	Ian Abbott <ian.abbott@....co.uk>,
	Mori Hess <fmhess@...rs.sourceforge.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/2] staging/comedi/drivers: release allocated I/O
 region if alloc_private fails

On Monday, July 02, 2012 1:41 AM, Ian Abbott wrote:
> No.  The I/O region will be deallocated in fl512_detach() because 
> dev->iobase has been set non-zero.  fl512_detach() will be called by the 
> comedi core if fl512_attach() returns an error.  This is an unusual 
> aspect of the comedi drivers.

I have been wondering if that aspect should be "fixed".

It's more typical for kernel drivers to clean up after themselves if
the probe/attach/init/etc. fails. And the release/detach/exit/etc.
is only called if the driver has successfully loaded.

With the comedi drivers, the "detach" is always called if the "attach"
failed. And, of course the "detach" is called when the device is removed.

Because of this the "detach" routines need to do all the checks to
see what needs to be cleaned up. Not a big deal but it does create
some confusion as this patch shows.

Ian, what's your opinion on this? Do you think we should refactor all
the driver "attach" routines so they clean up on failure and fix the
core so the "detach" is only called after a successful "attach"?

This would be a pretty big patch since it affects every driver as well
as the core. 

We could break it up by introducing a temporary flag in the comedi_driver
struct that indicates if the driver has been "fixed". The core could then
work as-is for non-updated drivers. Once all the drivers have been updated
we then fix the core and remove the flag from all the drivers.

Regards,
Hartley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ