KS2011: Preemption disable and verifiable APIs

As I have explained before this is factually incorrect in many ways. I have talked before with the presenters and they were mostly aware of the following (see the discussion on lkml in the weeks before):

1. The this_cpu apis were primarily created for statistics and not for SLUB.

2. this_cpu operations are independent of preemption and are intended to be used when it does not matter which processors instance is accessed. The typical use case is the increment of a per cpu counter. It does not matter which one is incremented since a sum of all per cpu counters is used to determine the number of events. It just matters that one of the per cpu counters is incremented.

3. People can of course abuse these operations. this_cpu_read and this_cpu_write (which are operations that are rarely used, these are not typical for code using this_cpu operations) can be easily confusing if one expects the processor to remain the same. The this_cpu operations are intended to be used for context in which it does not matter which processor the operation occurs on. Expectations of being on the same cpu later are just contrary to the design of these operations.

4. this_cpu_write() can be used in a correct manner for example when it is sufficient to set a value on any per cpu instance.

The problem with this_cpu ops seems to exist mainly in some peoples heads and the clueless saw two instances where people had similarly wrong expectation of this_cpu ops and generalized from there not bothering to investigate further and not willing to listen to those explaining things to them.

I am all for verification of APIS but the this_cpu operations are designed to do their job regardless of preemption being enabled or disabled. So they are out of scope for preemption verification (__this_cpu_xx operations may be different but those were not mentioned. Those may require some form of serialization which may be provided by disabling preemption).