linux-kernel - Re: [PATCH] drm/lima: Mark simple

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]
Message-ID: <7d1c35d6829f00fa62ea39b6fee656be@manjaro.org>
Date: Fri, 26 Jul 2024 10:03:45 +0200
From: Dragan Simic <dsimic@...jaro.org>
To: Qiang Yu <yuq825@...il.com>
Cc: Maxime Ripard <mripard@...nel.org>, dri-devel@...ts.freedesktop.org,
 lima@...ts.freedesktop.org, maarten.lankhorst@...ux.intel.com,
 tzimmermann@...e.de, airlied@...il.com, daniel@...ll.ch,
 linux-kernel@...r.kernel.org, Philip Muller <philm@...jaro.org>, Oliver
 Smith <ollieparanoid@...tmarketos.org>, Daniel Smith <danct12@...root.org>,
 stable@...r.kernel.org
Subject: Re: [PATCH] drm/lima: Mark simple_ondemand governor as softdep

Hello Qiang Yu,

On 2024-07-26 08:07, Qiang Yu wrote:
> Yeah, I agree weakdep is a better choice here. It solves the confusion
> of softdep which the depend module is optional.

Thanks, I'm glad that you agree.

> But I prefer using weakdep directly instead of creating an aliasing of
> it which has no actual difference.

Just checking, did you have a chance to read what I wrote in my earlier
response on the linux-modules mailing list, [7] which includes a rather
elaborate explanation of the intent behind MODULE_HARDDEP being 
currently
just a proposed alias for MODULE_WEAKDEP?  It also describes why using
this alias might save use some time and effort in the future.

[7] 
https://lore.kernel.org/linux-modules/0720a516416a92a8f683053d37ee9481@manjaro.org/

> On Thu, Jul 25, 2024 at 4:21 PM Dragan Simic <dsimic@...jaro.org> 
> wrote:
>> 
>> Hello Qiang,
>> 
>> On 2024-06-26 08:49, Dragan Simic wrote:
>> > On 2024-06-26 03:11, Qiang Yu wrote:
>> >> On Wed, Jun 26, 2024 at 2:15 AM Dragan Simic <dsimic@...jaro.org>
>> >> wrote:
>> >>> Just checking, any further thoughts about this patch?
>> >>>
>> >> I'm OK with this as a temp workaround because it's simple and do no
>> >> harm
>> >> even it's not perfect. If no other better suggestion for short term,
>> >> I'll submit
>> >> this at weekend.
>> >
>> > Thanks.  Just as you described it, it's far from perfect, but it's
>> > still
>> > fine until there's a better solution, such as harddeps.  I'll continue
>> > my
>> > research about the possibility for adding harddeps, which would
>> > hopefully
>> > replace quite a few instances of the softdep (ab)use.
>> 
>> Another option has become available for expressing additional module
>> dependencies, weakdeps. [1][2]  Long story short, weakdeps are similar
>> to softdeps, in the sense of telling the initial ramdisk utilities to
>> include additional kernel modules, but weakdeps result in no module
>> loading being performed by userspace.
>> 
>> Maybe "weak" isn't the best possible word choice (arguably, "soft" 
>> also
>> wasn't the best word choice), but weakdeps should be a better choice 
>> for
>> use with Lima and governor_simpleondemand, because weakdeps provide 
>> the
>> required information to the utilities used to generate initial 
>> ramdisk,
>> while the actual module loading is left to the kernel.
>> 
>> The recent addition of weakdeps renders the previously mentioned
>> harddeps
>> obsolete, because weakdeps actually do what we need.  Obviously, 
>> "weak"
>> doesn't go along very well with the actual nature of the dependency
>> between
>> Lima and governor_simpleondemand, but it's pretty much just the 
>> somewhat
>> unfortunate word choice.
>> 
>> The support for weakdeps has been already added to the kmod [3][4] and
>> Dracut [5] userspace utilities.  I'll hopefully add support for 
>> weakdeps
>> to mkinitcpio [6] rather soon.
>> 
>> Maybe we could actually add MODULE_HARDDEP() as some kind of syntactic
>> sugar, which would currently be an alias for MODULE_WEAKDEP(), so the
>> actual hard module dependencies could be expressed properly, and
>> possibly
>> handled differently in the future, with no need to go back and track 
>> all
>> such instances of hard module dependencies.
>> 
>> With all this in mind, here's what I'm going to do:
>> 
>> 1) Submit a patch that adds MODULE_HARDDEP() as syntactic sugar
>> 2) Implement support for weakdeps in Arch Linux's mkinitcpio [6]
>> 3) Depending on what kind of feedback the MODULE_HARDDEP() patch
>> receives,
>>     I'll submit follow-up patches for Lima and Panfrost, which will 
>> swap
>>     uses of MODULE_SOFTDEP() with MODULE_HARDDEP() or MODULE_WEAKDEP()
>> 
>> Looking forward to your thoughts.
>> 
>> [1] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/linux/module.h?id=61842868de13aa7fd7391c626e889f4d6f1450bf
>> [2] 
>> https://lore.kernel.org/linux-kernel/20240724102349.430078-1-jtornosm@redhat.com/T/#u
>> [3] 
>> https://github.com/kmod-project/kmod/commit/05828b4a6e9327a63ef94df544a042b5e9ce4fe7
>> [4] 
>> https://github.com/kmod-project/kmod/commit/d06712b51404061eef92cb275b8303814fca86ec
>> [5] 
>> https://github.com/dracut-ng/dracut-ng/commit/8517a6be5e20f4a6d87e55fce35ee3e29e2a1150
>> [6] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio