From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751260AbcEMGkQ (ORCPT ); Fri, 13 May 2016 02:40:16 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:57049 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750784AbcEMGkO (ORCPT ); Fri, 13 May 2016 02:40:14 -0400 To: peterz@infradead.org, tglx@linutronix.de From: Vikram Mulukutla Subject: Additional compiler barrier required in sched_preempt_enable_no_resched? Cc: linux-kernel@vger.kernel.org Message-ID: <573576B3.50908@codeaurora.org> Date: Thu, 12 May 2016 23:39:47 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, I came across a piece of engineering code that looked like: preempt_disable(); /* --cut, lots of code-- */ preempt_enable_no_resched(); put_user() preempt_disable(); (If you wish to seriously question the usage of the preempt API in this manner, I unfortunately have no comment since I didn't write the code.) This particular block of code was causing lockups and crashes on a certain ARM64 device. The generated assembly revealed that the compiler was simply optimizing out the increment and decrement of the preempt count, allowing put_user to run without preemption enabled, causing all sorts of badness. Since put_user doesn't actually access the preempt count and translates to just a few instructions without any branching, I suppose that the compiler figured it was OK to optimize. The immediate solution is to add a compiler barrier to the code above, but should sched_preempt_enable_no_resched have an additional compiler barrier after (has one before already) the preempt-count decrement to prevent this sort of thing? Thanks, Vikram -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project