On Tue, Apr 2, 2024 at 10:56 AM zhang warden <[email protected]> wrote:
>
>
>
> > On Apr 2, 2024, at 10:27, Yafang Shao <[email protected]> wrote:
> >
> > df1e98f2c74
>
> Hi Yafang!
>
> To my first question, from your patch, klp_free_patch_finish may not affect
> non-livpatch module. However, if my reading is right, your patch make changes
> to SYSCALL of delete_module. Making changes to sys call may effect
> non-livepatch module, I think.
I can't get your point here. Impact on what? The performance?
>
> Tell you the truth, in my production env, I don’t use klp replace mode
> because my livepatch fixing process dose’t adjust the logic of replacing the
> previous patches. Therefore, klp-replace mode is not suitable in my
> situation. The reason why I ask for safety is that this patch seems to change
> the syscall, which may cause some other effects.
Most code modifications within the kernel have the potential to
directly or indirectly alter one or more syscalls.
>
> For the commit ("kpatch: rmmod module of the same name before loading a
> module”) in patch userspace, it seems to fix this issue, while this commit is
> working in userspace, under kpatch’s control.
It appears there may have been a misunderstanding regarding the commit
("kpatch: rmmod module of the same name before loading a module"). I
recommend trying it out first before drawing any conclusions.
>
> What’s more, your patch seems to be malformed when I try to patch it. Is
> there any thing wrong when I copying your patch?
I don't know what happened. Probably I should rebase it on the lastest
live-patching tree.
>
> This is only my own option in reading your patch. Thanks!
>
> --
> Regards
> Warden
>
--
Regards
Yafang
