> > It is even more complicated and it is not connected only to atomic replace
> > patch (I realized this while reading the first part of your email and
> > then you confirmed it with this paragraph). The consistency model is
> > broken with respect to immediate patches.
>
> Indeed. I came to
On Wed, 18 Oct 2017, Petr Mladek wrote:
> On Wed 2017-10-18 11:10:09, Miroslav Benes wrote:
> > On Tue, 17 Oct 2017, Jason Baron wrote:
> > > If the atomic replace patch does
> > > not contain any immediates, then we can drop the reference on the
> > > immediately preceding patch only. That is bec
On Thu 2017-10-19 17:44:32, Jason Baron wrote:
> So for atomic replace, it seems as if we don't want to allow replaced
> patches to be re-enabled but instead, allow them to rmmod/insmod'ed to
> allow revert.
>
> In your above proposed model around immediate, if all patches are
> immediate then the
On 10/18/2017 05:10 AM, Miroslav Benes wrote:
> On Tue, 17 Oct 2017, Jason Baron wrote:
>
>>
>>
>> On 10/17/2017 09:50 AM, Miroslav Benes wrote:
>>> On Tue, 17 Oct 2017, Miroslav Benes wrote:
>>>
On Tue, 10 Oct 2017, Jason Baron wrote:
>
>
> On 10/06/2017 06:32 PM, Josh Poi
On 10/18/2017 07:25 AM, Petr Mladek wrote:
> On Wed 2017-10-18 11:10:09, Miroslav Benes wrote:
>> On Tue, 17 Oct 2017, Jason Baron wrote:
>>> If the atomic replace patch does
>>> not contain any immediates, then we can drop the reference on the
>>> immediately preceding patch only. That is becaus
On Thu, Oct 19, 2017 at 10:30:24AM +0200, Miroslav Benes wrote:
> On Wed, 18 Oct 2017, Josh Poimboeuf wrote:
>
> > On Wed, Oct 18, 2017 at 03:36:42PM +0200, Jiri Kosina wrote:
> > > On Wed, 18 Oct 2017, Miroslav Benes wrote:
> > >
> > > > 3. Drop immediate. It causes problems only and its advanta
On Wed, 18 Oct 2017, Josh Poimboeuf wrote:
> On Wed, Oct 18, 2017 at 03:36:42PM +0200, Jiri Kosina wrote:
> > On Wed, 18 Oct 2017, Miroslav Benes wrote:
> >
> > > 3. Drop immediate. It causes problems only and its advantages on x86_64
> > > are theoretical. You would still need to solve the inte
On Wed, Oct 18, 2017 at 03:36:42PM +0200, Jiri Kosina wrote:
> On Wed, 18 Oct 2017, Miroslav Benes wrote:
>
> > 3. Drop immediate. It causes problems only and its advantages on x86_64
> > are theoretical. You would still need to solve the interaction with atomic
> > replace on other architecture
On Wed, 18 Oct 2017, Miroslav Benes wrote:
> 3. Drop immediate. It causes problems only and its advantages on x86_64
> are theoretical. You would still need to solve the interaction with atomic
> replace on other architecture with immediate preserved, but that may be
> easier. Or we can be aggr
On Wed, 18 Oct 2017, Josh Poimboeuf wrote:
> On Wed, Oct 18, 2017 at 11:10:09AM +0200, Miroslav Benes wrote:
> > 3. Drop immediate. It causes problems only and its advantages on x86_64
> > are theoretical. You would still need to solve the interaction with atomic
> > replace on other architectur
On Wed 2017-10-18 11:10:09, Miroslav Benes wrote:
> On Tue, 17 Oct 2017, Jason Baron wrote:
> > If the atomic replace patch does
> > not contain any immediates, then we can drop the reference on the
> > immediately preceding patch only. That is because there may have been
> > previous transitions t
On Wed, Oct 18, 2017 at 11:10:09AM +0200, Miroslav Benes wrote:
> 3. Drop immediate. It causes problems only and its advantages on x86_64
> are theoretical. You would still need to solve the interaction with atomic
> replace on other architecture with immediate preserved, but that may be
> easie
On Tue, 17 Oct 2017, Jason Baron wrote:
>
>
> On 10/17/2017 09:50 AM, Miroslav Benes wrote:
> > On Tue, 17 Oct 2017, Miroslav Benes wrote:
> >
> >> On Tue, 10 Oct 2017, Jason Baron wrote:
> >>
> >>>
> >>>
> >>> On 10/06/2017 06:32 PM, Josh Poimboeuf wrote:
> On Wed, Sep 27, 2017 at 11:41:3
On 10/17/2017 09:50 AM, Miroslav Benes wrote:
> On Tue, 17 Oct 2017, Miroslav Benes wrote:
>
>> On Tue, 10 Oct 2017, Jason Baron wrote:
>>
>>>
>>>
>>> On 10/06/2017 06:32 PM, Josh Poimboeuf wrote:
On Wed, Sep 27, 2017 at 11:41:30PM -0400, Jason Baron wrote:
> Since 'atomic replace' has
On Tue 2017-10-17 11:02:29, Miroslav Benes wrote:
> On Tue, 10 Oct 2017, Jason Baron wrote:
> > On 10/06/2017 06:32 PM, Josh Poimboeuf wrote:
> > > I don't really like allowing a previously replaced patch to replace the
> > > current patch. It's just more unnecessary complexity.
I am sorry to say
On Tue, 17 Oct 2017, Miroslav Benes wrote:
> On Tue, 10 Oct 2017, Jason Baron wrote:
>
> >
> >
> > On 10/06/2017 06:32 PM, Josh Poimboeuf wrote:
> > > On Wed, Sep 27, 2017 at 11:41:30PM -0400, Jason Baron wrote:
> > >> Since 'atomic replace' has completely replaced all previous livepatch
> > >>
On Tue, 10 Oct 2017, Jason Baron wrote:
>
>
> On 10/06/2017 06:32 PM, Josh Poimboeuf wrote:
> > On Wed, Sep 27, 2017 at 11:41:30PM -0400, Jason Baron wrote:
> >> Since 'atomic replace' has completely replaced all previous livepatch
> >> modules, it explicitly disables all previous livepatch modu
On 10/06/2017 06:32 PM, Josh Poimboeuf wrote:
> On Wed, Sep 27, 2017 at 11:41:30PM -0400, Jason Baron wrote:
>> Since 'atomic replace' has completely replaced all previous livepatch
>> modules, it explicitly disables all previous livepatch modules. However,
>> previous livepatch modules that have
On Wed, Sep 27, 2017 at 11:41:30PM -0400, Jason Baron wrote:
> Since 'atomic replace' has completely replaced all previous livepatch
> modules, it explicitly disables all previous livepatch modules. However,
> previous livepatch modules that have been replaced, can be re-enabled
> if they have the
Sometimes we would like to revert a particular fix. This is currently
not easy because we want to keep all other fixes active and we could
revert only the last applied patch.
One solution would be to apply new patch that implemented all
the reverted functions like in the original code. It would wo
20 matches
Mail list logo
