Re: sched: memory corruption on completing completions

[Linus Torvalds]

On Thu, Feb 5, 2015 at 2:37 PM, Davidlohr Bueso <dave@xxxxxxxxxxxx> wrote:
>>
>> It is possible that the paravirt spinlocks could be saved by:
>>
>>  - moving the clearing of TICKET_SLOWPATH_FLAG into the fastpath locking code.
>
> Ouch, to avoid deadlocks they explicitly need the unlock to occur before
> the slowpath tail flag is read.

Well, just make the unlock do the actual real unlock operation
("fastpath"), leaving the TICKET_SLOWPATH_FLAG alone. The unlock path
can *test* the flag and do whatever kicking it needs to get people
started again, but not clear it again.

Then, the clearing could be done by the lockers. That way the unlock
path at least doesn't change the spinlock any more - sicne the
spinlock might have been free'd at any time after the actual unlock.

Or something. I'm handwaving. I really dislike all the paravirt crap
we do. It tends to be really ugly, and I'm not just talking about
spinlocks. TLB flushing etc tends to get interesting too.

> Yeah, you just cannot have a slowpath without reads or writes :D

Well, you *could* do the slow-path while holding the lock, and making
the actual ock release be the last part of the operation (and do the
final unlock with a "cmpxchg" that fails and re-does the slowpath if
something changed). Then the slowpath can read and write the lock all
it wants.

But people generally want to avoid that, since it makes the hold times
longer. So the "drop the lock, *then* test if we should do some slow
path fixup" tends to be the preferred model, it's just that that model
is broken due to the lifetime rules. Making it read-only would at
least make it a lot less broken..

                             Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/