On Mon, 20 Nov 2017, Miroslav Benes wrote:
> While working on "immediate" removal, I realized we had the similar
> problem here with modules removal. There is no way out of the rabbit hole.
>
> If a patch is forced, we obviously cannot say there is no task sleeping in
> the old code. This could be disastrous if such old module is then removed
> (either we disabled it and we want to rmmod it, or there is a new "atomic
> replace" patch and we want to remove the old one).
>
> We need something like the following (at least as a starting point)
I agree; the only thing I think really has to be done is putting a comment
there, explaining why forcing implies infinite module reference (and also
perhaps making it therefore even more obvious from documentation, that
this really is a last-resort-"you-know-what-you-are-doing" kind of knob).
On Mon, 20 Nov 2017, Josh Poimboeuf wrote:
> > We can also try to improve later. We could remember all forced tasks
> > and reenable rmmod once those tasks are really migrated ("shadow
> > migration").
>
> NACK :-) Forcing should hopefully be a rare event, not worth the
> trouble to try to keep track of that IMO.
Well, that was my rather random idea when we were discussing this over
lunch today. But I agree, it definitely is a total overkill, and I don't
want it to be atributed to me any more :p
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe live-patching" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
