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: <CAKGbVbukwz5naLwe7oW+UU8Ghtz6PmTjZ8k0PNZr2+h1Y20Qzw@mail.gmail.com>
Date: Fri, 26 Jul 2024 16:54:52 +0800
From: Qiang Yu <yuq825@...il.com>
To: Dragan Simic <dsimic@...jaro.org>
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

On Fri, Jul 26, 2024 at 4:03 PM Dragan Simic <dsimic@...jaro.org> wrote:
>
> 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/
>
Yeah, I've seen that mail. But I haven't seen clearly how weakdep will change
in the future which could break our usage here. As an interface exposed to other
users, I expect it should be stable.

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