On Tue, 8 Sep 2015, Dmitry Vyukov wrote:
> The question arose during work on KernelThreadSanitizer, a kernel data
> race, and in particular caused by the following existing code:
>
> // kernel/pid.c
> if ((atomic_read(&pid->count) == 1) ||
> atomic_dec_and_test(&pid->count)) {
> kmem_cache_free(ns->pid_cachep, pid);
> put_pid_ns(ns);
> }
It frees when there the refcount is one? Should this not be
if (atomic_read(&pid->count) === 0) || ...
>
> //drivers/tty/tty_buffer.c
> while ((next = buf->head->next) != NULL) {
> tty_buffer_free(port, buf->head);
> buf->head = next;
> }
> // Here another thread can concurrently append to the buffer list, and
> tty_buffer_free eventually calls kfree.
>
> Both these cases don't contain proper memory barrier before handing
> off the object to kfree. In my opinion the code should use
> smp_load_acquire or READ_ONCE_CTRL ("control-dependnecy-acquire").
> Otherwise there can be pending memory accesses to the object in other
> threads that can interfere with slab code or the next usage of the
> object after reuse.
There can be pending reads maybe? But a write would require exclusive
acccess to the cachelines.
> Paul McKenney suggested that:
>
> "
> The maintainers probably want this sort of code to be allowed:
> p->a++;
> if (p->b) {
> kfree(p);
> p = NULL;
> }
> And the users even more so.
Sure. What would be the problem with the above code? The write to the
object (p->a++) results in exclusive access to a cacheline being obtained.
So one cpu holds that cacheline. Then the object is freed and reused
either
1. On the same cpu -> No problem.
2. On another cpu. This means that a hand off of the pointer to the object
occurs in the slab allocators. The hand off involves a spinlock and thus
implicit barriers. The other processor will acquire exclusive access to
the cacheline when it initializes the object. At that point the cacheline
ownership will transfer between the processors.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>