[GIT PULL] Modules fixes for v6.15-rc6

[GIT PULL] Modules fixes for v6.15-rc6

[Petr Pavlu]

The following changes since commit 92a09c47464d040866cf2b4cd052bc60555185fb:

  Linux 6.15-rc5 (2025-05-04 13:55:04 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git/ tags/modules-6.15-rc6

for you to fetch changes up to a6aeb739974ec73e5217c75a7c008a688d3d5cf1:

  module: ensure that kobject_put() is safe for module type kobjects (2025-05-07 20:24:59 +0200)

----------------------------------------------------------------
Modules fixes for v6.15-rc6

A single fix to prevent use of an uninitialized completion pointer when
releasing a module_kobject in specific situations.

This addresses a latent bug exposed by commit f95bbfe18512 ("drivers: base:
handle module_kobject creation"), which was merged in 6.15-rc5. The fix has
been on modules-next only since yesterday but should be safe.

----------------------------------------------------------------
Dmitry Antipov (1):
      module: ensure that kobject_put() is safe for module type kobjects

 kernel/params.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Re: [GIT PULL] Modules fixes for v6.15-rc6

[Linus Torvalds]

On Fri, 9 May 2025 at 08:09, Petr Pavlu <petr.pavlu@suse.com> wrote:
>
> The fix has been on modules-next only since yesterday but should be safe.

Hmm.

At a minimum, the *description* of this bug is garbage.

It talks about an "uninitialized completion pointer", but then the fix
actually depends on it being initialized - just initialized to NULL.

I do believe that it always is initialized, and I have pulled this.
but I really think the explanations here are actively misleading.

Because there's a big difference between "uninitialized" and "not
pointing to a completion".

               Linus

Re: [GIT PULL] Modules fixes for v6.15-rc6

[pr-tracker-bot]

The pull request you sent on Fri, 9 May 2025 17:09:54 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git/ tags/modules-6.15-rc6

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/29fe5d50dfa6b61043e2e89206389ae56b5596eb

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] Modules fixes for v6.15-rc6

[Petr Pavlu]

On 5/9/25 18:19, Linus Torvalds wrote:
> On Fri, 9 May 2025 at 08:09, Petr Pavlu <petr.pavlu@suse.com> wrote:
>>
>> The fix has been on modules-next only since yesterday but should be safe.
> 
> Hmm.
> 
> At a minimum, the *description* of this bug is garbage.
> 
> It talks about an "uninitialized completion pointer", but then the fix
> actually depends on it being initialized - just initialized to NULL.
> 
> I do believe that it always is initialized, and I have pulled this.
> but I really think the explanations here are actively misleading.
> 
> Because there's a big difference between "uninitialized" and "not
> pointing to a completion".

Right, the description is in this aspect misleading, my bad.

-- Petr

Re: [GIT PULL] Modules fixes for v6.15-rc6

[Dmitry Antipov]

On 5/9/25 7:19 PM, Linus Torvalds wrote:

> At a minimum, the *description* of this bug is garbage.
> 
> It talks about an "uninitialized completion pointer", but then the fix
> actually depends on it being initialized - just initialized to NULL.
> 
> I do believe that it always is initialized, and I have pulled this.
> but I really think the explanations here are actively misleading.
> 
> Because there's a big difference between "uninitialized" and "not
> pointing to a completion".

Technically speaking you're right, and I will take notice on that for
further commits. OTOH replying with "please adjust commit message and
send v2" could be the way faster.

Dmitry

Re: [GIT PULL] Modules fixes for v6.15-rc6

[Linus Torvalds]

On Mon, 12 May 2025 at 11:14, Dmitry Antipov <dmantipov@yandex.ru> wrote:
>
> Technically speaking you're right, and I will take notice on that for
> further commits. OTOH replying with "please adjust commit message and
> send v2" could be the way faster.

I suspect it ends up depending on the people.

Personally, I tend to dislike being on the receiving end of the
back-and-forth of "fix this nit before I'll apply things", so I
generally try to avoid doing that to others.

Yes, I will do it for things that I think matter, where I really don't
want to have some bad thing show up to then be fixed later.

But I feel we sometimes have *too* much of that code review attitude
going on, where you end up with patch series that go on for multiple
versions because people keep reacting to various small details.

So most of the time, I'd rather just get the code fixed - get it over
with and leave the issue behind.

I'll point out something I think was wrong, but not fatal to the
codebase, and hopefully just make people aware and avoid future
occurrences.

IOW, I didn't expect my comment to result in any particular action
this time, just a "please think more about the explanations".

              Linus