Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757351AbbBFM24 (ORCPT ); Fri, 6 Feb 2015 07:28:56 -0500 Received: from e23smtp09.au.ibm.com ([202.81.31.142]:53952 "EHLO e23smtp09.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751850AbbBFM2x (ORCPT ); Fri, 6 Feb 2015 07:28:53 -0500 Message-ID: <54D4B3C3.3080507@linux.vnet.ibm.com> Date: Fri, 06 Feb 2015 17:59:55 +0530 From: Raghavendra K T Organization: IBM User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Davidlohr Bueso CC: Linus Torvalds , Sasha Levin , Waiman Long , Peter Zijlstra , Ingo Molnar , Andrew Morton , Andrey Ryabinin , Dave Jones , LKML Subject: Re: sched: memory corruption on completing completions References: <54D2AA16.6030706@oracle.com> <1423169986.6835.24.camel@stgolabs.net> <54D3DA75.70402@oracle.com> <1423175834.6835.27.camel@stgolabs.net> In-Reply-To: <1423175834.6835.27.camel@stgolabs.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15020612-0033-0000-0000-00000106A3A9 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2343 Lines: 63 On 02/06/2015 04:07 AM, Davidlohr Bueso wrote: > On Thu, 2015-02-05 at 13:34 -0800, Linus Torvalds wrote: >> On Thu, Feb 5, 2015 at 1:02 PM, Sasha Levin wrote: >>> >>> Interestingly enough, according to that article this behaviour seems to be >>> "by design": >> >> Oh, it's definitely by design, it's just that the design looked at >> spinlocks without the admittedly very subtle issue of lifetime vs >> unlocking. >> >> Spinlocks (and completions) are special - for other locks we have >> basically allowed lifetimes to be separate from the lock state, and if >> you have a data structure with a mutex in it, you'll have to have some >> separate lifetime rule outside of the lock itself. But spinlocks and >> completions have their locking state tied into their lifetime. > > For spinlocks I find this very much a virtue. Tight lifetimes allow the > overall locking logic to be *simple* - keeping people from being "smart" > and bloating up spinlocks. Similarly, I hate how the paravirt > alternative blends in with regular (sane) bare metal code. What was > preventing this instead?? > > #ifdef CONFIG_PARAVIRT_SPINLOCKS > static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) > { > if (!static_key_false(¶virt_ticketlocks_enabled)) > return; > > add_smp(&lock->tickets.head, TICKET_LOCK_INC); > /* Do slowpath tail stuff... */ > } > #else > static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) > { > __add(&lock->tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX); > } > #endif > > I just don't see the point to all this TICKET_SLOWPATH_FLAG: > > #ifdef CONFIG_PARAVIRT_SPINLOCKS > #define __TICKET_LOCK_INC 2 > #define TICKET_SLOWPATH_FLAG ((__ticket_t)1) > #else > #define __TICKET_LOCK_INC 1 > #define TICKET_SLOWPATH_FLAG ((__ticket_t)0) > #endif > > when it is only for paravirt -- and the word slowpath implies the > general steps as part of the generic algorithm. Lets keep code for > simple locks simple. > Good point, I will send this as a separate cleanup once I test the patch I have to correct the current problem. -- 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/