No. Your argument does not make any sense at all.
Go away, this is not the time to use magic to make kernel patches.
A "atomic_t" _often_ makes sense without having any spinlocks,
_especially_ when used as a reference count. Let me count the ways:
- when you increase the count because you make a copy, you know that
you're already a holder of the count, so you don't need any spinlocks
to protect anything else: you _know_ the area is there.
- when you decrease the count, you use "atomic_dec_and_test()" because
you know that the count was > 0, and you know that only _one_ such
decrementer will get a positive reply for the atomic_dec_and_test. The
one that is successful doesn't need any locking, because he's now the
only owner, and should just release everything.
In short, it has to be atomic, and spinlocks never enter the picture at
all.
Your patches do not make sense. Period. The only thing that makes sense is
to revert the array.c thing to the old one that didn't try to be clever.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/