linux-kernel - Re: [PATCH 1/3] usbatm: Allow sub-drivers to handle calls to atm_proc

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]

Date:	Wed, 31 Jan 2007 15:48:12 +0100
From:	Duncan Sands <duncan.sands@...h.u-psud.fr>
To:	Simon Arlott <601753fa5bab1585521hc0qm0003olph@...nder.lp0.eu>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] usbatm: Allow sub-drivers to handle calls to atm_proc_read.

> usbatm only outputs basic information via the per-device /proc/net/atm/ file,
> this patch allows the device specific USB ATM drivers to replace the
> atm_proc_read function with their own.  

I'm still meditating on this.  The reason I didn't do this originally is
because of potential problems with modem disconnection and/or module
unloading (the cxacru module can be unloaded at any time - it's the usbatm
module that can't be unloaded when a connection is open - so you've got to
be careful that no-one can call into cxacru after or while it's being
destroyed).  I think it will be OK as long as usbatm calls unbind after
shutting down the ATM layer (since otherwise your read method could be
called after you've freed your cxacru private data) which is not the case
right now, but should be easy to arrange.  Horrible things may happen
if proc_read can still be running after atm_dev_deregister has returned,
but, if so, horrible things can already happen right now.  I don't understand
why this is impossible; maybe it is possible.  The worst that will happen
(given that none of the proc_read methods sleeps) is that freed memory will
be accessed and the contents spat out in the proc file (if proc_read sleeps,
that could result in trying to run code inside a destroyed module).

Ciao,

Duncan.
-
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/