[lkml]   [2013]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/7] static_key: fix timer bugs & change api (a bit)
Il 17/10/2013 12:10, Radim Krčmář ha scritto:
> While fixing a simple crash on kvm module unload
> 1: rate_limit timer can fire after we free its key's module memory.
> I noticed other deficiencies in jump_label/static_key code
> (The most important is 4.)
> 2: jump_label_rate_limit() uses an initializator and thus cannot be used
> more than once, leaving no good way to change the timeout.
> I have made the API easier on programmers: [1/7]
> * timer is automatically flushed on rmmod
> * jump_label_rate_limit() initializes only once
> - pretty hacky, but we cannot automatically initialize on
> kernel_init/insmod due to insufficient information and while I
> would love getting it through another section, it is probably
> better to do a useless check with this low-rate operation
> * we could flush the timer on change
> * 'init()' + 'set()' (+ 'exit()' ?) would be an alternative ...
> 3: schedule_delayed_work() does not queue the work if one is already
> pending, but atomic_inc(&key->enabled) is called anyway in
> static_key_slow_dec_deferred(), with the false belief it will be
> decreased when the timer fires.
> Fixed in [2,3,4/7], by addition of static_key_slow_inc_deferred().

I think you're doing a bit too much for one series. Let's focus on the
bugfix and perhaps the improvements to the deferred static key API, that
is patches 1/2/3/4.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2013-10-17 13:01    [W:0.068 / U:3.508 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site