lib/percpu_counter: percpu_counter_add_batch() overflow/underflow

EXPORT_SYMBOL(percpu_counter_set);

/*

 * This function is both preempt and irq safe. The former is due to explicit

 * preemption disable. The latter is guaranteed by the fact that the slow path

 * is explicitly protected by an irq-safe spinlock whereas the fast patch uses

 * this_cpu_add which is irq-safe by definition. Hence there is no need muck

 * with irq state before calling this one

 * local_irq_save() is needed to make the function irq safe:

 * - The slow path would be ok as protected by an irq-safe spinlock.

 * - this_cpu_add would be ok as it is irq-safe by definition.

 * But:

 * The decision slow path/fast path and the actual update must be atomic, too.

 * Otherwise a call in process context could check the current values and

 * decide that the fast path can be used. If now an interrupt occurs before

 * the this_cpu_add(), and the interrupt updates this_cpu(*fbc->counters),

 * then the this_cpu_add() that is executed after the interrupt has completed

 * can produce values larger than "batch" or even overflows.

 */

void percpu_counter_add_batch(struct percpu_counter *fbc, s64 amount, s32 batch)

{

	s64 count;

	unsigned long flags;

	preempt_disable();

	local_irq_save(flags);

	count = __this_cpu_read(*fbc->counters) + amount;

	if (abs(count) >= batch) {

		unsigned long flags;

		raw_spin_lock_irqsave(&fbc->lock, flags);

		raw_spin_lock(&fbc->lock);

		fbc->count += count;

		__this_cpu_sub(*fbc->counters, count - amount);

		raw_spin_unlock_irqrestore(&fbc->lock, flags);

		raw_spin_unlock(&fbc->lock);

	} else {

		this_cpu_add(*fbc->counters, amount);

	}

	preempt_enable();

	local_irq_restore(flags);

}

EXPORT_SYMBOL(percpu_counter_add_batch);