From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 67A0DC11F64 for ; Thu, 1 Jul 2021 16:26:12 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F1F15613E3 for ; Thu, 1 Jul 2021 16:26:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F1F15613E3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.94.2) (envelope-from ) id 1lyzVj-0002iO-4T; Thu, 01 Jul 2021 12:25:55 -0400 Received: from mail-ot1-x333.google.com ([2607:f8b0:4864:20::333]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1lyzVg-0002ge-Ma for kernelnewbies@kernelnewbies.org; Thu, 01 Jul 2021 12:25:52 -0400 Received: by mail-ot1-x333.google.com with SMTP id t24-20020a9d7f980000b029046f4a1a5ec4so7112821otp.1 for ; Thu, 01 Jul 2021 09:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=AFwJc8ho+bs+aAImi2kEPoBHTQSAvoUULI/CUwslYp0=; b=T1oQwkyUAegQHoU8i/DbxGhSazL4v8dZJ7TWdnWZWS4Bsv7XqT/uswiD6by3cYjwHu Hw9kF71AeAUHomog41JoLVs2MGK/0HeeU5xfqYnradFg/X9Jp17nFPMWXY8gnA5PBYpQ 2ZmKUK0LZusPaF8T2pzQPaKCCPpiRW6tfLVGEuVEfHiUHPf2sCvSEugAXGtAOMjP0ag+ YzN0cq+a4gVdHluj2g6rSwtEnU2qIm8rvvnDu8Rgm38Yrntagxugifwzlpq6Qt9AsEEb BWSpnP2cCKWVLAOhExaby8DmRuFxw359QK5jna72MH2exFYG6cEAcrJXwh4MRejiGUZS 6eew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=AFwJc8ho+bs+aAImi2kEPoBHTQSAvoUULI/CUwslYp0=; b=S+bpIFWE3DDM5PAzYBBtJ3T6EewzA+L1rKT1VxjTk7ohKoAj+J0IYRHtdx7CnLcqSr J6FkhAA3BvIhmyfXyCWfK1mKlCcMSoszW8ToyDU8sMyKsmn8ZgdTzwjxsNVK9iSn2AtM aaBKwdj+sQL9sXLQuSAwgeWB8k1+/1ElH/a9jYm67+rh2m3cm8fANIAa/SsGSrz7yQJE eIHy7dsYusWEtziQ8QpH7NqRCp6kcZ6vIgMMseGNCWef/8P0aPjnXzTreKumtLE5/Ial O835wUaYRkayS3PbWrKdJKkJnPzlBV0ekrgDo1UsY22Ccb9uS8VZixtGq4qXnlcxIFQO /kyg== X-Gm-Message-State: AOAM531e/nsVJr4ZTi65EetlJUxjomvBU6lhvD+WqHB7FfF3ev+1hn8G bp0CnZzrSIqDrYf9ndKZf1LGh0oDgPU= X-Google-Smtp-Source: ABdhPJxGe5awT3F/p4PEnEgsPtC7V+bZvUh7qvvFiC/FSwDe/AnHi5oQwo/ZgT2FgekWMzMAw6HZyQ== X-Received: by 2002:a9d:862:: with SMTP id 89mr698252oty.276.1625156751159; Thu, 01 Jul 2021 09:25:51 -0700 (PDT) Received: from ian.penurio.us ([47.184.51.90]) by smtp.gmail.com with ESMTPSA id x3sm81950oie.24.2021.07.01.09.25.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Jul 2021 09:25:50 -0700 (PDT) X-Mozilla-News-Host: news://lore.kernel.org:119 To: linux-modules@vger.kernel.org, kernelnewbies@kernelnewbies.org From: Ian Pilcher Subject: Seeking advice on "monkey patching" a driver Message-ID: <30faa352-0f60-10b9-887e-b2ee522d0a16@gmail.com> Date: Thu, 1 Jul 2021 11:25:49 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Language: en-US X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: kernelnewbies-bounces@kernelnewbies.org 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