[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
<MA0P287MB0217A9BE2B1FAFF20027EC23B8C32@MA0P287MB0217.INDP287.PROD.OUTLOOK.COM>
Date: Sat, 15 Jun 2024 04:51:06 +0000
From: Aditya Garg <gargaditya08@...e.com>
To: Lucas De Marchi <lucas.demarchi@...el.com>
CC: "mcgrof@...nel.org" <mcgrof@...nel.org>, "linux-modules@...r.kernel.org"
<linux-modules@...r.kernel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
Subject: Re: Current status and possible improvements in
CONFIG_MODULE_FORCE_UNLOAD
Thanks for the reply Lucas. It makes sense now!
> On 15 Jun 2024, at 12:18 AM, Lucas De Marchi <lucas.demarchi@...el.com> wrote:
>
> On Thu, Jun 06, 2024 at 06:49:59AM GMT, Aditya Garg wrote:
>> Hi
>>
>> I am Aditya Garg. I often require using out of tree drivers to support various hardwares on Linux. Sometimes the provider doesn't write good drivers, and often they have to be force unloaded. It's a common thing in proprietary drivers. I know the author of the driver should take note of the issues, but still the force unloading of the modules does come in handy many times.
>>
>> Unfortunately if CONFIG_MODULE_FORCE_UNLOAD is not enabled in your kernel, which most probably is not enabled if you are using a Distribution pre compiled kernel, you have to recompile the whole kernel again.
>
> CONFIG_MODULE_FORCE_UNLOAD only ever makes sense on a developer
> environment loading/unloading multiple times his own .ko module. Then
> the developer knows better the state of the driver and hw to judge if
> it's safe to ignore krefs.
>
>>
>> I want wondering if instead of a kernel config option, we could use a kernel parameter to enable/disable this feature, I believe it should act as a better alternative. After all there must be people like me who are forced to recompile the whole linux kernel just for the sake of getting a functionality.
>
> Just allowing it like this is not a good thing. You may have a all kind
> of issues with use after free, dangling pointers etc. That would just
> make life harder for people not involved with proprietary modules.
>
>
>> I hope for a reply and suggestions
>
> I´d ask them to upstream their driver and start sending the issues to
> their side.
>
> Lucas De Marchi
>
>>
>> Regards
>> Aditya
Powered by blists - more mailing lists