Hi, Petr
> On Sep 10, 2024, at 16:01, Petr Mladek wrote:
>
> On Sun 2024-09-08 10:51:14, zhang warden wrote:
>>
>> Hi, Petr
>>>
>>> The 1st patch adds the pointer to struct klp_ops into struct
>>> klp_func. We might check the state a similar way as klp_ftrace_handler().
>>>
>>> I had somethin
On Sun 2024-09-08 10:51:14, zhang warden wrote:
>
> Hi, Petr
> >
> > The 1st patch adds the pointer to struct klp_ops into struct
> > klp_func. We might check the state a similar way as klp_ftrace_handler().
> >
> > I had something like this in mind when I suggested to move the pointer:
> >
> >
Hi, Petr
>
> The 1st patch adds the pointer to struct klp_ops into struct
> klp_func. We might check the state a similar way as klp_ftrace_handler().
>
> I had something like this in mind when I suggested to move the pointer:
>
> static ssize_t using_show(struct kobject *kobj,
> struct kobj_at
Hi, Petr
> On Sep 7, 2024, at 00:39, Petr Mladek wrote:
>
> On Fri 2024-09-06 17:39:46, zhang warden wrote:
>> Hi, John & Miroslav
>>
Would it be possible to just use klp_transition_patch and implement the
logic just in using_show()?
>>>
>>> Yes, containing the logic to the
On Fri 2024-09-06 17:39:46, zhang warden wrote:
> Hi, John & Miroslav
>
> >>
> >> Would it be possible to just use klp_transition_patch and implement the
> >> logic just in using_show()?
> >
> > Yes, containing the logic to the sysfs file sounds a lot better.
>
> Maybe I can try to use the sta
On Thu 2024-09-05 12:23:20, Miroslav Benes wrote:
> Hi,
>
> On Wed, 28 Aug 2024, Wardenjohn wrote:
>
> > One system may contains more than one livepatch module. We can see
> > which patch is enabled. If some patches applied to one system
> > modifing the same function, livepatch will use the func
Hi, John & Miroslav
>>
>> Would it be possible to just use klp_transition_patch and implement the
>> logic just in using_show()?
>
> Yes, containing the logic to the sysfs file sounds a lot better.
Maybe I can try to use the state of klp_transition_patch to update the
function's state instead
On Thu, 5 Sep 2024, Josh Poimboeuf wrote:
> On Thu, Sep 05, 2024 at 12:23:20PM +0200, Miroslav Benes wrote:
> > I am not a fan. Josh wrote most of my objections already so I will not
> > repeat them. I understand that the attribute might be useful but the
> > amount of code it adds to sensitive
On Thu, Sep 05, 2024 at 12:23:20PM +0200, Miroslav Benes wrote:
> I am not a fan. Josh wrote most of my objections already so I will not
> repeat them. I understand that the attribute might be useful but the
> amount of code it adds to sensitive functions like
> klp_complete_transition() is no f
On Thu, Sep 05, 2024 at 10:03:52PM +0800, zhang warden wrote:
> >>Here I can give you an example.
> We are going to fix a problem of io_uring.
> Our team made a livepatch of io_sq_offload_create.
> This livepatch module is deployed to some running servers.
>
> Then, another team make some change t
Hi Miroslav,
>
>
> I am not a fan. Josh wrote most of my objections already so I will not
> repeat them. I understand that the attribute might be useful but the
> amount of code it adds to sensitive functions like
> klp_complete_transition() is no fun.
>
OK, the point I make changes to klp_
Hi, Josh.
> Most of this information is already available in sysfs, with the
> exception of patch stacking order.
>
Well, this is the problem my patch want to fix. But my patch is more simpler,
it just shows the stack top of the target function, which is the only thing
users care.
>
> We wan
Hi,
On Wed, 28 Aug 2024, Wardenjohn wrote:
> One system may contains more than one livepatch module. We can see
> which patch is enabled. If some patches applied to one system
> modifing the same function, livepatch will use the function enabled
> on top of the function stack. However, we can not
On Wed, Sep 04, 2024 at 03:30:22PM +0800, zhang warden wrote:
> > On Sep 4, 2024, at 15:14, Josh Poimboeuf wrote:
> > If there are multiple people applying patches independently from each
> > other (to the same function even!), you are playing with fire, as there
> > could easily be implicit depen
> On Sep 4, 2024, at 15:14, Josh Poimboeuf wrote:
>
> On Wed, Sep 04, 2024 at 02:34:44PM +0800, zhang warden wrote:
>> In the scenario where multiple people work together to maintain the
>> same system, or a long time running system, the patch sets will
>> inevitably be cumulative. I think ker
On Wed, Sep 04, 2024 at 02:34:44PM +0800, zhang warden wrote:
> In the scenario where multiple people work together to maintain the
> same system, or a long time running system, the patch sets will
> inevitably be cumulative. I think kernel can maintain and tell user
> this most accurate informatio
> On Sep 4, 2024, at 12:48, Josh Poimboeuf wrote:
>
> On Wed, Aug 28, 2024 at 10:23:50AM +0800, Wardenjohn wrote:
>> One system may contains more than one livepatch module. We can see
>> which patch is enabled. If some patches applied to one system
>> modifing the same function, livepatch will
On Wed, Aug 28, 2024 at 10:23:50AM +0800, Wardenjohn wrote:
> One system may contains more than one livepatch module. We can see
> which patch is enabled. If some patches applied to one system
> modifing the same function, livepatch will use the function enabled
> on top of the function stack. Howe
> On Aug 28, 2024, at 10:23, Wardenjohn wrote:
>
> One system may contains more than one livepatch module. We can see
> which patch is enabled. If some patches applied to one system
> modifing the same function, livepatch will use the function enabled
> on top of the function stack. However, w
One system may contains more than one livepatch module. We can see
which patch is enabled. If some patches applied to one system
modifing the same function, livepatch will use the function enabled
on top of the function stack. However, we can not excatly know
which function of which patch is now en
20 matches
Mail list logo
