On Thu, 20 Apr 2000, Borislav Deianov wrote:
> Sounds like you are having an argument with yourself :)
>
> I'm not sure what is the point of taking the lock for reading. If
> somebody is updating the pointer while we are in the call instruction
> we should either get the old value or the new value, both of which
> should be valid. Different writers can use a normal spinlock to
> protect each other.
well, the trick is (or I thought it was) that in the above you assumed the
sequence of modifying sys_call_table[] atomic. It is true on ia32 but
Linux supports a lot more archs than just ia32 so I don't know if that's
true on all architectures.
So, potentially, if you don't take a read lock, you may end up jumping to
a "half-constructed" address in sys_call_table[] and end up in neither old
nor new implementation. That was the point of my little exercise :)
(if anything like this was atomic we wouldn't have arch-dependent atomic_t
data type)
If someone corrects me that the above is scenario is impossible on ALL
Linux supported architectures, I will agree that there is no point in
taking a read spinlock on each syscall.
Regards,
Tigran.
-
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/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:17 EST