Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp732147yba; Fri, 26 Apr 2019 07:55:04 -0700 (PDT) X-Google-Smtp-Source: APXvYqzvtFE4pG9nZjw2ilWrclKvEyVsAVDmmtNgN+XLWXSYZ5UU3p6SW10vugy2S6w7wFRqB6cL X-Received: by 2002:a63:e850:: with SMTP id a16mr44399283pgk.195.1556290504828; Fri, 26 Apr 2019 07:55:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556290504; cv=none; d=google.com; s=arc-20160816; b=Dsa4L/2W0b/Cks1cwvuiZzSMRxaeIJnjOxppUU7tlyduCQ6vV5QBGldqPH+LA4uKbf u32R8fek1wPsrN/tDqpqSqJWdZkup5RpCvONxe5N0M942/Z3h1dT9bqqD1ynLPttYIln jibIhSZ+slKVFfHfQyER6FyJ5ALT0/mVt1ERhEegkHCaj6dVMlWaB2U8XrjWNXFb6TpM ocVXCx1+14XVHdbEViFmxvls1oKC40vW5r2rdl/BVKDItZoxAFE9KcnE+h61/AfoUrbs H2U/9BctuM4ZfYRNYggjfVM4PC7G+LeP+BDZX+KVvXq7MX8zCk42ydJ4dI3+tFCziJKE X9Jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=CuKK9yohjLTgSkoKHHc4uN8oBkYp+tDgV6BbjPf9aEY=; b=a94Zh7+m8aGI1+Gkn2/b3j3tXkWVwPrEluc7qaojbIuoUqe6nyrVClyHfFv+wyKIL5 SvLbpqGxX2Mj2Sic8sZZuswlK+mvb7haPHzYxsnGCoBczXfRbtUvfc7ZbZkcyLMwR180 Chnzq4rDFH4s8sTecKTOJKeh8qMmDGwMCxTVnAtzP9fxxdELYo4kPZTjHS1DjTNVc06A O4ZjYvys7jySqYhpTl5+nA46DjV123jMa7BmvPG6+X4FWsIvppylLg2vTQiVl4wjhNXx csWSTHWonUtu5f4QlV0bBdczX3umGnm5RlAGQ2O7hfF0I1J5y2tSVVkle47D8c1lSoSK Z18g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c24si26490107plo.220.2019.04.26.07.54.49; Fri, 26 Apr 2019 07:55:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726495AbfDZOwi (ORCPT + 99 others); Fri, 26 Apr 2019 10:52:38 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:43546 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726039AbfDZOwi (ORCPT ); Fri, 26 Apr 2019 10:52:38 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CF53880D; Fri, 26 Apr 2019 07:52:37 -0700 (PDT) Received: from e103592.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CAF503F5C1; Fri, 26 Apr 2019 07:52:35 -0700 (PDT) Date: Fri, 26 Apr 2019 15:52:33 +0100 From: Dave Martin To: Julien Grall Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, ard.biesheuvel@linaro.org, julien.thierry@arm.com, marc.zyngier@arm.com, catalin.marinas@arm.com, suzuki.poulose@arm.com, will.deacon@arm.com, christoffer.dall@arm.com, james.morse@arm.com Subject: Re: [PATCH v4 3/3] arm64/fpsimd: Don't disable softirq when touching FPSIMD/SVE state Message-ID: <20190426145232.GK3567@e103592.cambridge.arm.com> References: <20190426143740.31973-1-julien.grall@arm.com> <20190426143740.31973-4-julien.grall@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190426143740.31973-4-julien.grall@arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 26, 2019 at 03:37:40PM +0100, Julien Grall wrote: > When the kernel is compiled with CONFIG_KERNEL_MODE_NEON, some part of > the kernel may be able to use FPSIMD/SVE. This is for instance the case > for crypto code. > > Any use of FPSIMD/SVE in the kernel are clearly marked by using the > function kernel_neon_{begin, end}. Furthermore, this can only be used > when may_use_simd() returns true. > > The current implementation of may_use_simd() allows softirq to use > FPSIMD/SVE unless it is currently in use (i.e kernel_neon_busy is true). > When in use, softirqs usually fall back to a software method. > > At the moment, as a softirq may use FPSIMD/SVE, softirqs are disabled > when touching the FPSIMD/SVE context. This has the drawback to disable > all softirqs even if they are not using FPSIMD/SVE. > > Since a softirq is supposed to check may_use_simd() anyway before > attempting to use FPSIMD/SVE, there is limited reason to keep softirq > disabled when touching the FPSIMD/SVE context. Instead, we can simply > disable preemption and mark the FPSIMD/SVE context as in use by setting > CPU's kernel_neon_busy flag. fpsimd_context_busy? > Two new helpers {get, put}_cpu_fpsimd_context is introduced to mark the > area using FPSIMD/SVE context and uses them in replacement of Paragraph mangled during edit? -> "are introduced ... and they are used to replace ..." > local_bh_{disable, enable}. The functions kernel_neon_{begin, end} are > also re-implemented to use the new helpers. > > Additionally, double-underscored versions of the helpers are provided to > be used in function called with interrupt masked. They are used for > sanity and also help to mark place where the FPSIMD context can be > manipulate freely. For the benefit of other readers, this should be more explicit. Also, the distinction between the normal and __ helpers is that the latter can be caller with preemption disabled. To clarify the impact, we can say something like "These are only relevant on paths where irqs are disabled anyway, so they are not needed for correctness in the current code. Let's use them anyway though: this marks the critical sections clearly and will help to avoid mistakes during future maintenance." [...] (Sorry to nitpick) Cheers ---Dave