| 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
| ||
|
Message-ID: <87ve94ccnl.fsf@tac.ki.iif.hu> Date: Thu, 18 Oct 2007 23:53:50 +0200 From: Ferenc Wagner <wferi@...f.hu> To: "Jiri Slaby" <jirislaby@...il.com> Cc: linux-kernel@...r.kernel.org Subject: Re: RocketPort Linux driver errors on module reload "Jiri Slaby" <jirislaby@...il.com> writes: > On 10/16/07, Wagner Ferenc <wferi@...f.hu> wrote: > >> Jiri Slaby <jirislaby@...il.com> writes: >> >>> Are you willing to test to-pci-probing patches (i.e. patches which >>> converts the driver to the model introduced in linux 2.4)? >> >> Well yes. We've got a copule of such cards, which raises some >> interest in a proper driver. Just send the patches with some >> instructions along, or point me to a git branch if you prefer. > > Maybe the git with stand-alone module would be better... Sorry, I don't understand this suggestion. I don't read LKML, please don't suppose any prior knowledge of the jargon used here... Do you mean I should use the bleeding edge git source of the kernel? Not something I'm eager to do, but can do, actually. And would you send me patches separately on top of that? >>> If not, I'll only increment the counter on modprobe and decrement it >>> on rmmod, since it would be a safe (in the meaning of not changing >>> that much code) way of fixing the problem. >> >> And what are the drawbacks of this simple solution? > > Nothing, but it's not the proper way -- just a safe fallback. But you > can still say no :). I expected an improper way to have some disadvantages at least. :) Anyway, I can tolerate some glitches during the porting of this module, resulting in interruptions of the serial devices, but leaving the rest of the system mostly stable; it's a production system after all. If the changes are more threatening, I'll use another system for the tests. In short: suggest a method and let's give a chance for the proper solution. Just please enclose some risk assessment. -- Regards, Feri. - 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