From: Ian Pilcher <arequipeno@gmail.com>
To: linux-modules@vger.kernel.org, kernelnewbies@kernelnewbies.org
Subject: Seeking advice on "monkey patching" a driver
Date: Thu, 1 Jul 2021 11:25:49 -0500 [thread overview]
Message-ID: <30faa352-0f60-10b9-887e-b2ee522d0a16@gmail.com> (raw)
I maintain a couple of out-of-tree modules that enable "mainstream"
distributions to be used on the Thecus N5550 NAS.
https://github.com/ipilcher/n5550/tree/master/modules
The disk activity LEDs in this NAS are software controlled, so the
n5550_ahci_leds module exists to "inject" a wrapper around libahci's
qc_issue() function which triggers the correct LED (if any).
https://github.com/ipilcher/n5550/blob/25538096fffd7942be8b7f2c66af580620a422b6/modules/n5550_ahci_leds.c#L225
It's certainly a hack, but it makes use of the modules much simpler, as
there's no need to patch and rebuild libahci, override the distro-
provided module, etc. As long as modprobe is configured to load
n5550_ahci_leds immediately after libahci and before any consumers of
libahci are loaded, things "just work".
The current version of n5550_ahci_leds attempts to ensure that no
libahci consumers are loaded before it modifies libahci's
ahci_ops.qc_issue. It does this by:
* locking module_mutex
* getting a reference to the libahci module (with find_module())
* checking libahci's reference count
* grabbing a reference to *itself* to prevent itself from being
unloaded
* modifying ahci_ops.qc_issue
* unlocking module_mutex
(There similar logic in the n5550_ahci_leds_enabled_store function to
reverse the modifications, if no other libahci consumers are loaded.)
It's very possible that some or all of these precautions are
unnecessary (or that they're inadequate). I am most definitely not an
expert at kernel development or the details of the kernel's module
loading mechanism. I and few others have, however, been successfully
using these modules for a number of years.
I've just discovered that neither module_mutex nor find_module() are
available in recent kernels, and I'm unsure how to proceed. The two
options that I've been able to think of thus far are:
* YOLO! I can simply remove the checks from the module and rely on user
space to ensure that n5550_ahci_leds is loaded before any libahci
consumers load (i.e. before udevd starts).
* kprobes - I have a feeling that this is the "correct" way to do this
(and it would have the benefit of working even if libahci or its
consumers aren't built as modules). OTOH, it isn't clear how I would
go about accessing the arguments passed into the function without
JProbes, and I'm not thrilled with the idea of adding additional
overhead and/or locking to the disk I/O path.
I'd really appreciate any thoughts, advice, ideas, links etc.
Thanks!
--
========================================================================
In Soviet Russia, Google searches you!
========================================================================
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
next reply other threads:[~2021-07-01 16:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-01 16:25 Ian Pilcher [this message]
2021-07-01 17:59 ` Seeking advice on "monkey patching" a driver Greg KH
2021-07-01 20:03 ` Ian Pilcher
2021-07-01 21:04 ` jim.cromie
2021-07-02 4:31 ` Greg KH
2021-07-02 12:05 ` Ian Pilcher
2021-07-02 12:20 ` Greg KH
2021-07-02 15:16 ` Ian Pilcher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=30faa352-0f60-10b9-887e-b2ee522d0a16@gmail.com \
--to=arequipeno@gmail.com \
--cc=kernelnewbies@kernelnewbies.org \
--cc=linux-modules@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox