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

Powered by Openwall GNU/*/Linux Powered by OpenVZ