It would depend on how
spin_lock_irqsave() have been implemented.
For example, it's possible that they determine if the lock was already locked by the same CPU and increment a counter if it is; then (when the lock is released) decrement the counter and only release the lock if the counter becomes zero. That way the same CPU could acquire the lock multiple times and it wouldn't cause deadlocks.
It would also be possible for
spin_lock_irqsave() to be something that only disables IRQs, that doesn't actually acquire the lock (e.g. something that assumes/expects
spin_lock() to have been called beforehand). In this case, the lock
&x may just be a convenient place to store/track the fact that IRQs were/are disabled (and maybe
spin_unlock() checks some flag and enables IRQs again if they were disabled).
However, I can't think of a reason for
spin_lock_irqsave() to need a second parameter (
Another possibility is that the names of these functions are misleading and have nothing to do with what they actually do at all. For example; the
spin_lock() function might order a pizza and the
spin_lock_irqsave() function might display football results.
Basically, there's no information about these functions other than their names, and therefore it's impossible to determine what they do (or if there is or isn't a deadlock).