linux-kernel - Re: RocketPort Linux driver errors on module reload

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:	Fri, 19 Oct 2007 00:08:24 +0200
From:	Jiri Slaby <jirislaby@...il.com>
To:	Ferenc Wagner <wferi@...f.hu>
CC:	linux-kernel@...r.kernel.org
Subject: Re: RocketPort Linux driver errors on module reload

On 10/18/2007 11:53 PM, Ferenc Wagner wrote:
> "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?

I meant the creating of a git repository with only the module would be the
easiest possible and most comfortable way for you :). Otherwise I can post you a
patch serie.

>>>> 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. :)

Yes, if you have pci hotpluggable motherboard :). Pci probing (the new method)
allows you adding/probing pci devices on the fly, not only when the module is
loading.

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

I did such switches in drivers several times yet, but I can't assure you, that I
won't make any mistake, but this driver seems not to need too many changes.
Maybe functionality regressions would occur rather than instability of system.

Anyway I would rather wait for the changes from comtrol to not break their
upcoming patches (if they post them in some short term) and then do these changes.

thanks,
-- 
Jiri Slaby (jirislaby@...il.com)
Faculty of Informatics, Masaryk University
-
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/