Rationale for removing .owner = THIS_MODULE in struct file_operations (Linux v6.4+)

[visitorckw]

The conditional removal of the explicit .owner = THIS_MODULE initialization in recent module examples was introduced in commit 1c31bac ("Fix Linux v6.5 compatibility"):

static struct file_operations fops = {
#if LINUX_VERSION_CODE < KERNEL_VERSION(6, 4, 0)
    .owner = THIS_MODULE,
#endif
    // ...
};

My Questions:

1. What is the specific Linux kernel commit that introduced this change, and what is the technical rationale? (Since struct file_operations::owner still exists in the header, I assume the core kernel now automatically handles module usage counting for file operations, making the explicit setting redundant?)

2. The change was introduced to fix "Linux v6.5 compatibility," but the version check uses < 6.4.0. Could you please clarify the exact version boundary, and whether the condition should potentially be adjusted (e.g., changing < to <= or the version numbers)?

[EricccTaiwan]

1. What is the specific Linux kernel commit that introduced this change, and what is the technical rationale? (Since struct file_operations::owner still exists in the header, I assume the core kernel now automatically handles module usage counting for file operations, making the explicit setting redundant?)

I actually made a similar PR in sysprog21/simrupt#12 , and I think the commit message there already explains your question pretty well!

2. The change was introduced to fix "Linux v6.5 compatibility," but the version check uses < 6.4.0. Could you please clarify the exact version boundary, and whether the condition should potentially be adjusted (e.g., changing < to <= or the version numbers)?

No, because the change was first introduced in v6.4-rc1, so I believe keeping < 6.4 is correct.
That said, I agree the commit title is a bit misleading.

[visitorckw]

1. What is the specific Linux kernel commit that introduced this change, and what is the technical rationale? (Since struct file_operations::owner still exists in the header, I assume the core kernel now automatically handles module usage counting for file operations, making the explicit setting redundant?)

I actually made a similar PR in sysprog21/simrupt#12 , and I think the commit message there already explains your question pretty well!

I don't think that's the correct commit.

The Greg's patch you mentioned cleans up struct class, not struct file_operations. This still doesn't explain why it's safe for file_operations.

From a quick search, several in-tree file_operations definitions still explicitly set .owner = THIS_MODULE.

2. The change was introduced to fix "Linux v6.5 compatibility," but the version check uses < 6.4.0. Could you please clarify the exact version boundary, and whether the condition should potentially be adjusted (e.g., changing < to <= or the version numbers)?

No, because the change was first introduced in v6.4-rc1, so I believe keeping < 6.4 is correct. That said, I agree the commit title is a bit misleading.

OK, I'll proceed with the understanding that the previous commit message description was simply incorrect.

Additionally, even if this change is technically correct, I still doubt the necessity of adding this conditional compilation. It seems setting .owner remains correct and safe in all kernel versions. Introducing a conditional compile block like this only serves to confuse readers, leading them to question if struct file_operations even has the .owner member after v6.4.

[EricccTaiwan]

The Greg's patch you mentioned cleans up struct class, not struct file_operations. This still doesn't explain why it's safe for file_operations.

Oh, I see. Thanks for pointing that out.
I think my PR was wrong and should be reverted.

Edit: @jserv wdyt? If you agree, I'll revert these changes.

[jserv]

If you agree, I'll revert these changes.

Go ahead.