linux-kernel - Re: [PATCH 1/2] usbatm: Increment module refcount when atm device is opened.

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] [day] [month] [year] [list]

Message-ID: <45DDF3EA.3040407@simon.arlott.org.uk>
Date:	Thu, 22 Feb 2007 19:50:02 +0000
From:	Simon Arlott <simon@...ott.org>
To:	Duncan Sands <duncan.sands@...h.u-psud.fr>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] usbatm: Increment module refcount when atm device
 is opened.

On 22/02/07 09:48, Duncan Sands wrote:
> What for?  Did you see any problems with the way it works right now?

It didn't make sense to be able to unload a module while it's actually in use, how does this work with automatic module loading/unloading (although I can't see how it's going to automatically load one of the sub drivers...)?

> How it works now is that if the module is unloaded while the device is
> in use, then the device is deregistered from the USB and ATM layers
> before the module unload completes.  Thus there should be no problem
> unloading the device at any moment.  
Ok.

> I'm guessing that you want this because of the better proc support you
> would like to add, which adds an extra callback into the module.

Actually it was partly because of the urb warning messages on unload... which the change doesn't even affect.

> This too should cause no problems as long as the appropriate tweaks are
> made to the shutdown code. I plan to make those adjustments, but I didn't
> find time yet - sorry.

I intend to export all the data via sysfs instead, since the current method of using proc (requiring several large enough read()s and no seeking) isn't very good and I can't see any way to improve it without caching the whole output from file open to close which atm doesn't support.

I was thinking that the MAC address/AAL stats should be removed from the proc output since they're already available from the atm devices proc file?

> PS: I plan to work on the drivers this weekend.

I don't expect to require any changes to usbatm to support sysfs, since the attributes should go with the usb device itself (and not the atm device). Perhaps there could be symlinks in each direction between the usb device and the atm device (like dvb/v4l do, e.g. atm:cxacru0 in the usb device)?

-- 
Simon Arlott

Download attachment "signature.asc" of type "application/pgp-signature" (830 bytes)