Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751216AbbBEW5T (ORCPT ); Thu, 5 Feb 2015 17:57:19 -0500 Received: from mail-ig0-f170.google.com ([209.85.213.170]:38541 "EHLO mail-ig0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750818AbbBEW5S (ORCPT ); Thu, 5 Feb 2015 17:57:18 -0500 MIME-Version: 1.0 In-Reply-To: <1423175834.6835.27.camel@stgolabs.net> References: <54D2AA16.6030706@oracle.com> <1423169986.6835.24.camel@stgolabs.net> <54D3DA75.70402@oracle.com> <1423175834.6835.27.camel@stgolabs.net> Date: Thu, 5 Feb 2015 14:57:17 -0800 X-Google-Sender-Auth: RTPiQFgx-Mtd3rPcxC9FA8LDtYk Message-ID: Subject: Re: sched: memory corruption on completing completions From: Linus Torvalds To: Davidlohr Bueso Cc: Sasha Levin , Waiman Long , Peter Zijlstra , Ingo Molnar , Andrew Morton , Andrey Ryabinin , Dave Jones , LKML , Raghavendra K T Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1925 Lines: 42 On Thu, Feb 5, 2015 at 2:37 PM, Davidlohr Bueso 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/