Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp18812ybk; Fri, 8 May 2020 17:13:02 -0700 (PDT) X-Google-Smtp-Source: APiQypLKwjY9L3nht1C9rq7Ex5+sWKs6rvSiiKXsqi6SOCHvLJ/2Ex9aeHIc9askoA24R74hl4AX X-Received: by 2002:a17:906:7f01:: with SMTP id d1mr4028212ejr.49.1588983182470; Fri, 08 May 2020 17:13:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588983182; cv=none; d=google.com; s=arc-20160816; b=t3gpmd9nIdv3UyywOmCCz6Pqa+dQkTwwFodDt/h0kzjKMmndHHAe+u2qFLqUfAFBal 7qSFuV1/tZcIkkrZDyPT/OryMIA3p7+ChLfBB0VNBvEDjffCeq/n+o83BpUZ6ynqJKE+ QvMr5gO920k3sHOJ1T92Y4ssAE9EstfsozZ3JrIcZ0ogkKawugmDUhk6AXIU7WLbJxA1 I/rD2R+SQX/8D1uXIOQCuJFlfxyfDVJHw4wXu/NfbRk8tEC+cfQ9mFtDSFBQYulcyZpq mtxm3Nv2wQMAQ7u9eHRSPPPcW5nEOXgoKDy6HxhtcpIXAOMKb5qREjQyPTC5VIelWTdM MQkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=DmVMHc7tsGOggEfjZEwHAq1pwch9ewLBlOO4S/89H30=; b=eZ8FQS5TK37jbdLdHAWNGXLerNtq2aMynY7WocXpjEq2XjopmDc0GCgzhwIQlY1B8v /rjXM8Ng3UHu0Le8w2RcMMmyjt0CLwWXLKFQvNA/Lb3I2PX8gkDzyOb0SNJ7QKVxexDn hh/boGaZEGfk9MBDfLfikROPClNBtuGXtou3F9pJTpq6fV+pDojAaAvLkuqyTq178MWU zIQlwfXITfORk4wlg9a03zlg2pt3j4Q6ujLH4fuMbfMdStTCURMYelIWrRGZ0rbLIg2t HW7QNs3JWkZE0iG7Ve+qb38wv/q7BB4zdwt6W9m7qMkL2l/BeXx7A4P6pR8lqZjZnwZv tuQg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=1qEQFAXw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d19si1126268ejc.396.2020.05.08.17.12.39; Fri, 08 May 2020 17:13:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=1qEQFAXw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728392AbgEIAKZ (ORCPT + 99 others); Fri, 8 May 2020 20:10:25 -0400 Received: from mail.kernel.org ([198.145.29.99]:57182 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728361AbgEIAKX (ORCPT ); Fri, 8 May 2020 20:10:23 -0400 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 646BB24967 for ; Sat, 9 May 2020 00:10:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588983022; bh=erSdpvEBA/OBZrmfaYKkP+jqxEzq0wGxMfSHU3w7sVQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=1qEQFAXwYuggWIen30j4GN1aByRgNZ0uMRePYR8b49xv3+tJ8jnvtW/FhNd19UB6G 80o0X7JZPrVoYzbw3QJx7O6pmvCkDn2AR9IT2aE4KxId3dv9f0OP4SFr/5E8FaRtU/ oCg6tVjo3XhV9FVkS02h/BYlQ/nyNLbFJ3voSi+4= Received: by mail-wm1-f44.google.com with SMTP id u127so12529462wmg.1 for ; Fri, 08 May 2020 17:10:22 -0700 (PDT) X-Gm-Message-State: AGi0PubXcpZy2wj40qanfSMUxMeQN7DEFeCeg6HHTeIX/SsTroNPAabf Mdp0WxI043Cp9Ac5ldf1otqZ37tYMjdQX6qt1d7qxg== X-Received: by 2002:a7b:c74d:: with SMTP id w13mr17996836wmk.36.1588983020820; Fri, 08 May 2020 17:10:20 -0700 (PDT) MIME-Version: 1.0 References: <20200505134112.272268764@linutronix.de> <20200505134341.087595319@linutronix.de> In-Reply-To: <20200505134341.087595319@linutronix.de> From: Andy Lutomirski Date: Fri, 8 May 2020 17:10:09 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch V4 part 2 10/18] x86/entry/64: Check IF in __preempt_enable_notrace() thunk To: Thomas Gleixner Cc: LKML , X86 ML , "Paul E. McKenney" , Andy Lutomirski , Alexandre Chartre , Frederic Weisbecker , Paolo Bonzini , Sean Christopherson , Masami Hiramatsu , Petr Mladek , Steven Rostedt , Joel Fernandes , Boris Ostrovsky , Juergen Gross , Brian Gerst , Mathieu Desnoyers , Josh Poimboeuf , Will Deacon Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 5, 2020 at 7:14 AM Thomas Gleixner wrote: > > The preempt_enable_notrace() ASM thunk is called from tracing, entry code > RCU and other places which are already in or going to be in the noinstr > section which protects sensitve code from being instrumented. This text and $SUBJECT agree that you're talking about preempt_enable_notrace(), but: > + THUNK preempt_schedule_notrace_thunk, preempt_schedule_notrace, check_if=1 You actually seem to be changing preempt_schedule_notrace(). The actual code in question has this comment: /** * preempt_schedule_notrace - preempt_schedule called by tracing * * The tracing infrastructure uses preempt_enable_notrace to prevent * recursion and tracing preempt enabling caused by the tracing * infrastructure itself. But as tracing can happen in areas coming * from userspace or just about to enter userspace, a preempt enable * can occur before user_exit() is called. This will cause the scheduler * to be called when the system is still in usermode. * * To prevent this, the preempt_enable_notrace will use this function * instead of preempt_schedule() to exit user context if needed before * calling the scheduler. */ Which is no longer really applicable to x86 -- in the state that this comment nonsensically refers to as "userspace", x86 *always* has IRQs off, which means that preempt_enable() will not schedule. So I'm guessing that the issue you're solving is that we have redundant preempt disable/enable pairs somewhere in the bowels of tracing code that is called with IRQs off, and objtool is now complaining. Could the actual code in question be fixed to assert that IRQs are off instead of disabling preemption? If not, can you fix the $SUBJECT and changelog and perhaps add a comment to the code as to *why* you're checking IF? Otherwise some intrepid programmer is going to notice it down the road, wonder if it's optimizing anything useful at all, and get rid of it.