On Thu, Sep 05, 2019 at 03:52:59PM +0200, Petr Mladek wrote:

On Thu 2019-09-05 08:15:02, Josh Poimboeuf wrote:

quoted

On Thu, Sep 05, 2019 at 08:08:32AM -0500, Josh Poimboeuf wrote:

quoted

On Thu, Sep 05, 2019 at 01:09:55PM +0200, Petr Mladek wrote:

quoted

quoted

I don't have a number, but it's very common to patch a function which
uses jump labels or alternatives.

Really? My impression is that both alternatives and jump_labels
are used in hot paths. I would expect them mostly in core code
that is always loaded.

Alternatives are often used in assembly that we are not able
to livepatch anyway.

Or are they spread widely via some macros or inlined functions?

Jump labels are used everywhere.  Looking at vmlinux.o in my kernel:

  Relocation section [19621] '.rela__jump_table' for section [19620] '__jump_table' at offset 0x197873c8 contains 11913 entries:

Each jump label entry has 3 entries, so 11913/3 = 3971 jump labels.

$ readelf -s vmlinux.o |grep FUNC |wc -l
46902

3971/46902 = ~8.5%

~8.5% of functions use jump labels.

Obviously some functions may use more than one jump label so this isn't
exactly bulletproof math.  But it gives a rough idea of how widespread
they are.

It looks scary. I just wonder why we have never met this problem during
last few years.

Who knows what can happen when you disable jump label patching.
Sometimes it may be harmless.  A panic is probably the worst case.
There may be other fail modes which are harder to detect.

My only guess is that most of these functions are either in core
kernel or in code that we do not livepatch.

This is definitely not the case.  We recently introduced jump label
checking in kpatch-build, and it complains a lot.  The workaround is to
replace such uses with static_key_enabled().

-- 
Josh