On Tue, Apr 2, 2024 at 10:56 AM zhang warden <zhangwarden@xxxxxxxxx> wrote:
>
>
>
> > On Apr 2, 2024, at 10:27, Yafang Shao <laoar.shao@xxxxxxxxx> 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
