>>> On 29.03.16 at 12:36, <[email protected]> wrote: > On Thu, Mar 24, 2016 at 4:19 PM, Jan Beulich <[email protected]> wrote: >>>>> On 24.03.16 at 16:55, <[email protected]> wrote: >>> On 24/03/16 11:30, Jan Beulich wrote: >>>> Recursive locks know their current owner, and since we use the function >>>> solely to determine whether a particular lock is being held by the >>>> current CPU (which so far has been an imprecise check), make actually >>>> check the owner for recusrively acquired locks. >>> >>> What's the expected behaviour of _spin_is_locked() if the lock is held >>> by another CPU? >>> >>> Before it may return true if it is held by another CPU, now it will >>> always return false in this case. >> >> Correct - hence the reference to this only being used for a limited >> set of cases (read: ASSERT()s and alike). > > A bunch of the mm locks add "_by_me" at the end of the function. Did > spin_is_locked() used to have that as well?
I don't think it did. And I think the only other readily visible use case of spin_is_locked() (testing whether a spin lock could be acquired without delay) is bogus anyway, as it would better be performed by doing a try-lock. > In any case I suppose "spin_is_locked_by_someone()" is really pretty > useless information. Indeed, hence I didn't want to alter the functions' names. Jan _______________________________________________ Xen-devel mailing list [email protected] http://lists.xen.org/xen-devel
