Prev: sysfs: make s_count a kref
Next: Problem with multiple hvc consoles via virtio-console
From: Neil Brown on 29 Mar 2010 03:50
On Mon, 29 Mar 2010 15:43:25 +1100
Neil Brown <neilb(a)suse.de> wrote:

> However if we do consider memory ordering guarantees we can describe a clear
> limit to the possibly delay between SYSFS_FLAG_REMOVED being set, and being
> seen. The atomic_inc_not_zero serves as a memory barrier in exactly the same
> way that the current code requires atomic_dec_return. So while
>
> if (likely(sd)
> && (sd->s_flags & SYSFS_FLAG_REMOVED) == 0
> && atomic_inc_not_zero(&sd->s_active)) {
>
> could possibly gain a reference even 'after' SYS_FLAG_REMOVED as been set,
> a second call to this on the same processor will see SYSFS_FLAG_REMOVED.
> So at the absolute most, we could see NCPUS active references gained and
> dropped after SYSFS_FLAG_REMOVED was set - a clear limit which is all we need.

It just occurred to me that this 'proof' isn't quite complete in itself. I
need to also show that there is a suitable memory barrier after
SYSFS_FLAG_REMOVED is set. There is as it is always set under sysfs_mutex,
so the mutex_unlock provides a barrier.
So after sysfs_mutex is unlocked, it is conceivable that each CPU could grant
one active reference against the sysfs_dirent before SYSFS_FLAG_REMOVED was
globally visible.

> I'm still not sure we even need to argue in terms of memory barriers to be
> sure the code is correct, but it seems they are sufficient to give a simple
> proof.

NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2
Prev: sysfs: make s_count a kref
Next: Problem with multiple hvc consoles via virtio-console