[Forwarding reply to [email protected]]
Thank you for interest in these patches. I've actually originally built
kprefcount as a module for testing, but do agree that it doesn't make
sense practically, and MODULE_LICENSE() should be removed from
kprefcount.c, as well as kprefcount_t API generally be improved.
Idea behind kprefcount_t algorithm is to facilitate creation of
live-patches for CVE fixes that add refcount_inc/dec() to existing code,
as this type of live-patches often cause problems because of runtime
ordering of refcount_inc()/refcount_dec()/patch/unpatch.
If implementing such patches with kprefcount_t, only new live-patch code
would be modified, and also patching of functions that call
refcount_dec_and_test() is necessary to instead call
kprefcount_dec_and_test().
Note that "make W=1" will generate a warning if a module doesn't have a
> MODULE_DESCRIPTION().
> I've been fixing the existing warnings tree-wide and am hoping to
> prevent new instances from appearing.
> One way I've been doing this is by searching lore for patches which add
> a MODULE_LICENSE() but which do not add a MODULE_DESCRIPTION() since
> that is a common sign of a missing description.
> But in this specific case it seems the MODULE_LICENSE() may be the issue
> since I don't see how kprefcount.c could ever be built as a module. So
> in this specific case it seems as if the MODULE_LICENSE() should be
removed.
> Note that none of the other kernel/livepatch/*.c files have a
> MODULE_LICENSE(), and CONFIG_LIVEPATCH is a bool and hence does not
> support being built as a module.
/jeff
