On 29.02.2024 18:04, Jürgen Groß wrote: > On 29.02.24 17:54, Jan Beulich wrote: >> On 29.02.2024 17:45, Juergen Gross wrote: >>> On 29.02.24 17:31, Jan Beulich wrote: >>>> On 29.02.2024 17:29, Jürgen Groß wrote: >>>>> On 29.02.24 16:46, Jan Beulich wrote: >>>>>> On 12.12.2023 10:47, Juergen Gross wrote: >>>>>>> Allow 16 bits per cpu number, which is the limit imposed by >>>>>>> spinlock_tickets_t. >>>>>>> >>>>>>> This will allow up to 65535 cpus, while increasing only the size of >>>>>>> recursive spinlocks in debug builds from 8 to 12 bytes. >>>>>> >>>>>> I think we want to be more conservative here, for the case of there >>>>>> being bugs: The CPU holding a lock may wrongly try to acquire it a >>>>>> 2nd time. That's the 65536th ticket then, wrapping the value. >>>>> >>>>> Is this really a problem? There will be no other cpu left seeing the lock >>>>> as "free" in this case, as all others will be waiting for the head to >>>>> reach >>>>> their private tail value. >>>> >>>> But isn't said CPU then going to make progress, rather than indefinitely >>>> spinning on the lock? >>> >>> No, I don't think so. >> >> Hmm. If CPU0 takes a pristine lock, it'll get ticket 0x0000. All other >> CPUs will get tickets 0x0001 ... 0xffff. Then CPU0 trying to take the lock > > No, they'll get 0x0001 ... 0xfffe (only 65535 cpus are supported). > >> again will get ticket 0x0000 again, which equals what .head still has (no > > And the first cpu will get 0xffff when trying to get the lock again.
Oh, right. Still a little too close to the boundary for my taste ... Jan
