linux-kernel - Re: [PATCH 0/7] static_key: fix timer bugs & change api (a bit)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <525FBF5A.3040307@redhat.com>
Date:	Thu, 17 Oct 2013 12:43:38 +0200
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Radim Krčmář <rkrcmar@...hat.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: [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.

Paolo

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/