From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C1C5CC433E2 for ; Tue, 15 Sep 2020 06:44:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7832E20897 for ; Tue, 15 Sep 2020 06:44:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600152298; bh=XlhPQhFrX0A/aql6pX2YgbW2X9pXKFj7GYWfRrmIPak=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=e0SyVbEcbMEt8l5IKjPS7pvREiGp9uDsJUtIfXGRsdekSo3bzI3XvEL6htRH0Ou2q kdUNIHGyq7kulptsDFrAhpEj3OYjaRSOoHsJ+1tYURel66SeERmcctMCAuHYv1OfDU 265igfgBPx352LK+5j/pIOhzxCZDKMh/96/Cm/GQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726123AbgIOGo5 (ORCPT ); Tue, 15 Sep 2020 02:44:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47022 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726031AbgIOGow (ORCPT ); Tue, 15 Sep 2020 02:44:52 -0400 Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 829C1C06174A for ; Mon, 14 Sep 2020 23:44:51 -0700 (PDT) Received: by mail-lj1-x244.google.com with SMTP id r24so1810056ljm.3 for ; Mon, 14 Sep 2020 23:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7AZvvtnOCrBJ0y7Ea7nJQgHCW8PeMBJ8MoPUyYrAJro=; b=Gqovwkb5A8FW/jwlWWxLLQ/avI7lnDibBgUBcgb3YHy5ole3D6O2HF9xebthy2Sa7D pdxdxxmQzGYxo9HEtGYBgkQkdY49pjUNwIF0aUEETd48RydGVCxehC4UHZ1aoiJMH2WY rTXUOrEKNo5NyWYCWs4UE3XuCPJLSnSLauj5I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7AZvvtnOCrBJ0y7Ea7nJQgHCW8PeMBJ8MoPUyYrAJro=; b=ekhtcFnez+eDc5xsRieG9tKdrmg20I/uAJIA1sR2LmVL34PfD/PUCIwIZU88uK3Gb0 XN+2xlJYFujs05e070yExd5RpYBsKgrhcMHT1QmgAtmJhvCFljx8RDq+DrrltNlPan9u /WDU6Ejz4vbHDTpXuV1JYGbV9xG3icY4xB+mT6948d8oNHia6rKExzMTqmtzCwItee7g ThggfxxuqkoSty1Lws283pKdk+apDAln04PpDcEza4PG88yLzam+/BwSSOfvhhkOhqzs tlCBVXdXVWwi67C0ITGD56dgs2BofOR9NYjIVgEMAWZ2oAHamdwcDxq8ab9/gWPRvr02 j7sQ== X-Gm-Message-State: AOAM531+14jBfS8I5bq/R1bAYKrzCtTNQCAac3JTxV1q16ChVFws4bCJ /lKPFZaAuN4Qa9MYFE+JrrA2EJcqQsf1xw== X-Google-Smtp-Source: ABdhPJxyY9krnkg7bSRHWoB+vz02jxpFvkmHF0IIvIJtsmc1AJzpc+kh2tVtba/3EIGB6lUXm671eA== X-Received: by 2002:a2e:a0c3:: with SMTP id f3mr5898372ljm.87.1600152289697; Mon, 14 Sep 2020 23:44:49 -0700 (PDT) Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com. [209.85.167.41]) by smtp.gmail.com with ESMTPSA id b16sm4509701ljh.34.2020.09.14.23.44.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2020 23:44:49 -0700 (PDT) Received: by mail-lf1-f41.google.com with SMTP id x77so1938494lfa.0 for ; Mon, 14 Sep 2020 23:44:49 -0700 (PDT) X-Received: by 2002:a19:8907:: with SMTP id l7mr5566265lfd.105.1600151970683; Mon, 14 Sep 2020 23:39:30 -0700 (PDT) MIME-Version: 1.0 References: <20200914204209.256266093@linutronix.de> <871rj4owfn.fsf@nanos.tec.linutronix.de> <20200915062253.GA26275@gondor.apana.org.au> In-Reply-To: <20200915062253.GA26275@gondor.apana.org.au> From: Linus Torvalds Date: Mon, 14 Sep 2020 23:39:14 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch 00/13] preempt: Make preempt count unconditional To: Herbert Xu Cc: Ard Biesheuvel , Thomas Gleixner , LKML , linux-arch , Sebastian Andrzej Siewior , Valentin Schneider , Richard Henderson , Ivan Kokshaysky , Matt Turner , alpha , Jeff Dike , Richard Weinberger , Anton Ivanov , linux-um , Brian Cain , linux-hexagon@vger.kernel.org, Geert Uytterhoeven , linux-m68k , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Will Deacon , Andrew Morton , Linux-MM , Ingo Molnar , Russell King , Linux ARM , Chris Zankel , Max Filippov , linux-xtensa@linux-xtensa.org, Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , Daniel Vetter , intel-gfx , dri-devel , "Paul E. McKenney" , Josh Triplett , Mathieu Desnoyers , Lai Jiangshan , Shuah Khan , rcu@vger.kernel.org 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 Mon, Sep 14, 2020 at 11:24 PM Herbert Xu wrote: > > On Tue, Sep 15, 2020 at 09:20:59AM +0300, Ard Biesheuvel wrote: > > > > The documentation of kmap_atomic() states the following: > > > > * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap > > * gives a more generic (and caching) interface. But kmap_atomic can > > * be used in IRQ contexts, so in some (very limited) cases we need > > * it. > > > > so if this is no longer accurate, perhaps we should fix it? > > This hasn't been accurate for at least ten years :) Yeah, that used to be true a long long time ago, but the comment is very stale. > > But another reason I tried to avoid kmap_atomic() is that it disables > > preemption unconditionally, even on 64-bit architectures where HIGHMEM > > is irrelevant. So using kmap_atomic() here means that the bulk of > > WireGuard packet encryption runs with preemption disabled, essentially > > for legacy reasons. > > Agreed. We should definitely fix that. Well, honestly, one big reason for that is debugging. The *semantics* of the kmap_atomic() is in the name - you can't sleep in between it and the kunmap_atomic(). On any sane architecture, kmap_atomic() ends up being a no-op from an implementation standpoint, and sleeping would work just fine. But we very much want to make sure that people don't then write code that doesn't work on the bad old 32-bit machines where it really needs that sequence to be safe from preemption. So it's mostly a debug thing. I say "mostly", because there might be small other details too, like shared code, and perhaps even a couple of users out in the wild that depend on the pagefault_disable() inherent in the current kmap_atomic(), who knows.. So no, the preemption disabling isn't inherent in the operation itself. But it does have some argument for it. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2B5C2C43461 for ; Tue, 15 Sep 2020 06:45:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A5D3620665 for ; Tue, 15 Sep 2020 06:45:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="Gqovwkb5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A5D3620665 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EA949900017; Tue, 15 Sep 2020 02:45:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E32DF6B009F; Tue, 15 Sep 2020 02:45:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C6630900017; Tue, 15 Sep 2020 02:45:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0155.hostedemail.com [216.40.44.155]) by kanga.kvack.org (Postfix) with ESMTP id AA3F26B009E for ; Tue, 15 Sep 2020 02:45:01 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 6549A2C12 for ; Tue, 15 Sep 2020 06:45:01 +0000 (UTC) X-FDA: 77264358402.14.quill21_410dd5e2710f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin14.hostedemail.com (Postfix) with ESMTP id 359B718229818 for ; Tue, 15 Sep 2020 06:45:01 +0000 (UTC) X-HE-Tag: quill21_410dd5e2710f X-Filterd-Recvd-Size: 7296 Received: from mail-ej1-f66.google.com (mail-ej1-f66.google.com [209.85.218.66]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Tue, 15 Sep 2020 06:45:00 +0000 (UTC) Received: by mail-ej1-f66.google.com with SMTP id o8so3355276ejb.10 for ; Mon, 14 Sep 2020 23:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7AZvvtnOCrBJ0y7Ea7nJQgHCW8PeMBJ8MoPUyYrAJro=; b=Gqovwkb5A8FW/jwlWWxLLQ/avI7lnDibBgUBcgb3YHy5ole3D6O2HF9xebthy2Sa7D pdxdxxmQzGYxo9HEtGYBgkQkdY49pjUNwIF0aUEETd48RydGVCxehC4UHZ1aoiJMH2WY rTXUOrEKNo5NyWYCWs4UE3XuCPJLSnSLauj5I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7AZvvtnOCrBJ0y7Ea7nJQgHCW8PeMBJ8MoPUyYrAJro=; b=XXFtACKVBxP9gZuPDOsqsitWxwDIbmkfr8SCrMG56o9QwU3m86K1gq/1bisgt4WznF ZJUHLv1NAhI2o/j5w4M12WHNJYPSZo035idgMjwnikgecFR8txlsW7ZeyNeR5SY7KtQ+ KaILIaoKLi4dXqHiOY7pC1Pn3gsIR8j/HsfFzUs/cJnTT8VdXcY9qcAlR9uS4FCQsPXv NTsPpaB4hZi5sFV3CJas7em+LYRfxxtOSeJrdksHYambMUq2ak0mt2PiWXkU7m0Z5txE +iNUShSNw1wVlDF4O+HTWVJDPRyuIV233MmnlBJw1ifL5n+Xe7KqVTvxsOhDs16DY05p n7Qg== X-Gm-Message-State: AOAM531q6CcZN1GG711IV8TU/sAuyO4OmAfGy5moj61zmQu0PpGV1g0I vFF4amo7+f742Vt9CqSNXYPn0ElMEncUug== X-Google-Smtp-Source: ABdhPJxLfWh8+nuQi+Mikm+Sugj+bXHKamUBnmELfrUlKgdUrsD2bnpKlX97wFsCChkhlpvF1e9QGg== X-Received: by 2002:a17:906:cb98:: with SMTP id mf24mr19195166ejb.90.1600152299064; Mon, 14 Sep 2020 23:44:59 -0700 (PDT) Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com. [209.85.218.43]) by smtp.gmail.com with ESMTPSA id z18sm9536307ejb.92.2020.09.14.23.44.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2020 23:44:58 -0700 (PDT) Received: by mail-ej1-f43.google.com with SMTP id z22so3366941ejl.7 for ; Mon, 14 Sep 2020 23:44:58 -0700 (PDT) X-Received: by 2002:a19:8907:: with SMTP id l7mr5566265lfd.105.1600151970683; Mon, 14 Sep 2020 23:39:30 -0700 (PDT) MIME-Version: 1.0 References: <20200914204209.256266093@linutronix.de> <871rj4owfn.fsf@nanos.tec.linutronix.de> <20200915062253.GA26275@gondor.apana.org.au> In-Reply-To: <20200915062253.GA26275@gondor.apana.org.au> From: Linus Torvalds Date: Mon, 14 Sep 2020 23:39:14 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch 00/13] preempt: Make preempt count unconditional To: Herbert Xu Cc: Ard Biesheuvel , Thomas Gleixner , LKML , linux-arch , Sebastian Andrzej Siewior , Valentin Schneider , Richard Henderson , Ivan Kokshaysky , Matt Turner , alpha , Jeff Dike , Richard Weinberger , Anton Ivanov , linux-um , Brian Cain , linux-hexagon@vger.kernel.org, Geert Uytterhoeven , linux-m68k , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Will Deacon , Andrew Morton , Linux-MM , Ingo Molnar , Russell King , Linux ARM , Chris Zankel , Max Filippov , linux-xtensa@linux-xtensa.org, Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , Daniel Vetter , intel-gfx , dri-devel , "Paul E. McKenney" , Josh Triplett , Mathieu Desnoyers , Lai Jiangshan , Shuah Khan , rcu@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 359B718229818 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Sep 14, 2020 at 11:24 PM Herbert Xu wrote: > > On Tue, Sep 15, 2020 at 09:20:59AM +0300, Ard Biesheuvel wrote: > > > > The documentation of kmap_atomic() states the following: > > > > * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap > > * gives a more generic (and caching) interface. But kmap_atomic can > > * be used in IRQ contexts, so in some (very limited) cases we need > > * it. > > > > so if this is no longer accurate, perhaps we should fix it? > > This hasn't been accurate for at least ten years :) Yeah, that used to be true a long long time ago, but the comment is very stale. > > But another reason I tried to avoid kmap_atomic() is that it disables > > preemption unconditionally, even on 64-bit architectures where HIGHMEM > > is irrelevant. So using kmap_atomic() here means that the bulk of > > WireGuard packet encryption runs with preemption disabled, essentially > > for legacy reasons. > > Agreed. We should definitely fix that. Well, honestly, one big reason for that is debugging. The *semantics* of the kmap_atomic() is in the name - you can't sleep in between it and the kunmap_atomic(). On any sane architecture, kmap_atomic() ends up being a no-op from an implementation standpoint, and sleeping would work just fine. But we very much want to make sure that people don't then write code that doesn't work on the bad old 32-bit machines where it really needs that sequence to be safe from preemption. So it's mostly a debug thing. I say "mostly", because there might be small other details too, like shared code, and perhaps even a couple of users out in the wild that depend on the pagefault_disable() inherent in the current kmap_atomic(), who knows.. So no, the preemption disabling isn't inherent in the operation itself. But it does have some argument for it. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6E03AC43461 for ; Tue, 15 Sep 2020 06:39:41 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 04F992076C for ; Tue, 15 Sep 2020 06:39:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="Gqovwkb5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 04F992076C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 20A896E83D; Tue, 15 Sep 2020 06:39:38 +0000 (UTC) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7097E6E83C for ; Tue, 15 Sep 2020 06:39:36 +0000 (UTC) Received: by mail-lj1-x242.google.com with SMTP id u4so1750853ljd.10 for ; Mon, 14 Sep 2020 23:39:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7AZvvtnOCrBJ0y7Ea7nJQgHCW8PeMBJ8MoPUyYrAJro=; b=Gqovwkb5A8FW/jwlWWxLLQ/avI7lnDibBgUBcgb3YHy5ole3D6O2HF9xebthy2Sa7D pdxdxxmQzGYxo9HEtGYBgkQkdY49pjUNwIF0aUEETd48RydGVCxehC4UHZ1aoiJMH2WY rTXUOrEKNo5NyWYCWs4UE3XuCPJLSnSLauj5I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7AZvvtnOCrBJ0y7Ea7nJQgHCW8PeMBJ8MoPUyYrAJro=; b=hGslPCvW71dV/YQx0iy9jW/0ORP0MlHRQmfSVzo71wDA+OT+u7H1ah+wciT8yLPBx1 xkoIJux6fz9dlBHm5PMg9fcdFjmQN66vY5q1vpglw3t3VN12giNHzmPXW4SHOjEduf78 9U53nWjGBSkRYWdL4FRXH6UiMCfCD1I+8aUuYXQ4RcwuRpn+KUlQ7u5aKs966i/qePid n5GZVLduoSwmZ0CkVigqQgUmhlnu6XXj39Ma/UmqIleldlKxV0Ttz1UzC/rLzOpcyxFc n258XxWqxnkugObK/bgmNAA+rEveyHxtSjavsOHekkM1DyIYb3kbP6C36ArPVu38xw7w WYfQ== X-Gm-Message-State: AOAM533fPQmRMXO2k0MglBdfG7EfVZcJxAezAGpbqt+FAeMeJCZ/l0W7 n6nW7FOMvXJ3GoeQJXlCr4EzzecJZJO8Xw== X-Google-Smtp-Source: ABdhPJy1fg6vMvkX4itK/pn0d+nL+22lNiFnGBTyRRbReM57aMf5iGb/iDdYd+JGsTHJE74bXGGBWA== X-Received: by 2002:a05:651c:1284:: with SMTP id 4mr6394000ljc.76.1600151974263; Mon, 14 Sep 2020 23:39:34 -0700 (PDT) Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com. [209.85.167.50]) by smtp.gmail.com with ESMTPSA id h22sm4529825ljl.101.2020.09.14.23.39.32 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2020 23:39:33 -0700 (PDT) Received: by mail-lf1-f50.google.com with SMTP id b22so1831173lfs.13 for ; Mon, 14 Sep 2020 23:39:32 -0700 (PDT) X-Received: by 2002:a19:8907:: with SMTP id l7mr5566265lfd.105.1600151970683; Mon, 14 Sep 2020 23:39:30 -0700 (PDT) MIME-Version: 1.0 References: <20200914204209.256266093@linutronix.de> <871rj4owfn.fsf@nanos.tec.linutronix.de> <20200915062253.GA26275@gondor.apana.org.au> In-Reply-To: <20200915062253.GA26275@gondor.apana.org.au> From: Linus Torvalds Date: Mon, 14 Sep 2020 23:39:14 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch 00/13] preempt: Make preempt count unconditional To: Herbert Xu X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Juri Lelli , Peter Zijlstra , Sebastian Andrzej Siewior , Lai Jiangshan , dri-devel , Ben Segall , Linux-MM , linux-hexagon@vger.kernel.org, Will Deacon , Ingo Molnar , Anton Ivanov , linux-arch , Vincent Guittot , Brian Cain , Richard Weinberger , Russell King , Ard Biesheuvel , David Airlie , Ingo Molnar , Geert Uytterhoeven , Mel Gorman , intel-gfx , Matt Turner , Valentin Schneider , linux-xtensa@linux-xtensa.org, Shuah Khan , "Paul E. McKenney" , Jeff Dike , linux-um , Josh Triplett , Steven Rostedt , rcu@vger.kernel.org, linux-m68k , Ivan Kokshaysky , Rodrigo Vivi , Thomas Gleixner , Dietmar Eggemann , Linux ARM , Richard Henderson , Chris Zankel , Max Filippov , LKML , alpha , Mathieu Desnoyers , Andrew Morton , Daniel Bristot de Oliveira Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Mon, Sep 14, 2020 at 11:24 PM Herbert Xu wrote: > > On Tue, Sep 15, 2020 at 09:20:59AM +0300, Ard Biesheuvel wrote: > > > > The documentation of kmap_atomic() states the following: > > > > * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap > > * gives a more generic (and caching) interface. But kmap_atomic can > > * be used in IRQ contexts, so in some (very limited) cases we need > > * it. > > > > so if this is no longer accurate, perhaps we should fix it? > > This hasn't been accurate for at least ten years :) Yeah, that used to be true a long long time ago, but the comment is very stale. > > But another reason I tried to avoid kmap_atomic() is that it disables > > preemption unconditionally, even on 64-bit architectures where HIGHMEM > > is irrelevant. So using kmap_atomic() here means that the bulk of > > WireGuard packet encryption runs with preemption disabled, essentially > > for legacy reasons. > > Agreed. We should definitely fix that. Well, honestly, one big reason for that is debugging. The *semantics* of the kmap_atomic() is in the name - you can't sleep in between it and the kunmap_atomic(). On any sane architecture, kmap_atomic() ends up being a no-op from an implementation standpoint, and sleeping would work just fine. But we very much want to make sure that people don't then write code that doesn't work on the bad old 32-bit machines where it really needs that sequence to be safe from preemption. So it's mostly a debug thing. I say "mostly", because there might be small other details too, like shared code, and perhaps even a couple of users out in the wild that depend on the pagefault_disable() inherent in the current kmap_atomic(), who knows.. So no, the preemption disabling isn't inherent in the operation itself. But it does have some argument for it. Linus _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CA497C433E2 for ; Tue, 15 Sep 2020 06:39:38 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 426442076C for ; Tue, 15 Sep 2020 06:39:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="Gqovwkb5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 426442076C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4D5586E83A; Tue, 15 Sep 2020 06:39:37 +0000 (UTC) Received: from mail-ej1-x642.google.com (mail-ej1-x642.google.com [IPv6:2a00:1450:4864:20::642]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6E5E06E83A for ; Tue, 15 Sep 2020 06:39:36 +0000 (UTC) Received: by mail-ej1-x642.google.com with SMTP id p9so3360187ejf.6 for ; Mon, 14 Sep 2020 23:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7AZvvtnOCrBJ0y7Ea7nJQgHCW8PeMBJ8MoPUyYrAJro=; b=Gqovwkb5A8FW/jwlWWxLLQ/avI7lnDibBgUBcgb3YHy5ole3D6O2HF9xebthy2Sa7D pdxdxxmQzGYxo9HEtGYBgkQkdY49pjUNwIF0aUEETd48RydGVCxehC4UHZ1aoiJMH2WY rTXUOrEKNo5NyWYCWs4UE3XuCPJLSnSLauj5I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7AZvvtnOCrBJ0y7Ea7nJQgHCW8PeMBJ8MoPUyYrAJro=; b=joCqNrO2dOef0YJIrgH6GZ1zKeDUm6YEAM89QrX13LkoAtFspYpr7ol781zyGdHTXo zQm/7YgjxQdorBIpWBEs++rrP1hNbkMYxADHtOb8P6DPyJQcG/uvI9n5/Kz77OAnBOOU bBfYKzzG5PvGi3i0JE12MNh5BYdEmROoAEljEMMZSNEhufTjza8YVhltfwciYvlsIncI +f6CFJed19IAnvtjotJzBUApl1wv1h7LhLFwDDh62p/NLc5Z2meLwhVWHr80+vTAJQln 7zxHkXUUfH0RoQUqjuoVaQijts+Ya8/S8ZA5YHCaKEksgUQDeGaBQnD5z0ZGsx6djeDt cZ+Q== X-Gm-Message-State: AOAM5309QDAtYDSqimkA9I7TKb9XYU/UOEbvp4lQpu0LkU5x1pScb6SF nj9NqCEL9G6baLLdwwsiHLDhsqAJhmEVjg== X-Google-Smtp-Source: ABdhPJzdui1w89HhnhRLxCVYJZB38hm0S/WzsELTW73J43lD8iYyMaUXLSQ39jl5/25nOQvp6vbnAA== X-Received: by 2002:a17:906:1e11:: with SMTP id g17mr17474053ejj.298.1600151974337; Mon, 14 Sep 2020 23:39:34 -0700 (PDT) Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com. [209.85.221.49]) by smtp.gmail.com with ESMTPSA id p17sm3783892edw.10.2020.09.14.23.39.32 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2020 23:39:33 -0700 (PDT) Received: by mail-wr1-f49.google.com with SMTP id e16so2023784wrm.2 for ; Mon, 14 Sep 2020 23:39:32 -0700 (PDT) X-Received: by 2002:a19:8907:: with SMTP id l7mr5566265lfd.105.1600151970683; Mon, 14 Sep 2020 23:39:30 -0700 (PDT) MIME-Version: 1.0 References: <20200914204209.256266093@linutronix.de> <871rj4owfn.fsf@nanos.tec.linutronix.de> <20200915062253.GA26275@gondor.apana.org.au> In-Reply-To: <20200915062253.GA26275@gondor.apana.org.au> From: Linus Torvalds Date: Mon, 14 Sep 2020 23:39:14 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Herbert Xu Subject: Re: [Intel-gfx] [patch 00/13] preempt: Make preempt count unconditional X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Juri Lelli , Peter Zijlstra , Sebastian Andrzej Siewior , Lai Jiangshan , dri-devel , Ben Segall , Linux-MM , linux-hexagon@vger.kernel.org, Will Deacon , Ingo Molnar , Anton Ivanov , linux-arch , Brian Cain , Richard Weinberger , Russell King , Ard Biesheuvel , David Airlie , Ingo Molnar , Geert Uytterhoeven , Mel Gorman , intel-gfx , Matt Turner , Valentin Schneider , linux-xtensa@linux-xtensa.org, Shuah Khan , "Paul E. McKenney" , Jeff Dike , linux-um , Josh Triplett , Steven Rostedt , rcu@vger.kernel.org, linux-m68k , Ivan Kokshaysky , Thomas Gleixner , Dietmar Eggemann , Linux ARM , Richard Henderson , Chris Zankel , Max Filippov , LKML , alpha , Mathieu Desnoyers , Andrew Morton , Daniel Bristot de Oliveira Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Mon, Sep 14, 2020 at 11:24 PM Herbert Xu wrote: > > On Tue, Sep 15, 2020 at 09:20:59AM +0300, Ard Biesheuvel wrote: > > > > The documentation of kmap_atomic() states the following: > > > > * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap > > * gives a more generic (and caching) interface. But kmap_atomic can > > * be used in IRQ contexts, so in some (very limited) cases we need > > * it. > > > > so if this is no longer accurate, perhaps we should fix it? > > This hasn't been accurate for at least ten years :) Yeah, that used to be true a long long time ago, but the comment is very stale. > > But another reason I tried to avoid kmap_atomic() is that it disables > > preemption unconditionally, even on 64-bit architectures where HIGHMEM > > is irrelevant. So using kmap_atomic() here means that the bulk of > > WireGuard packet encryption runs with preemption disabled, essentially > > for legacy reasons. > > Agreed. We should definitely fix that. Well, honestly, one big reason for that is debugging. The *semantics* of the kmap_atomic() is in the name - you can't sleep in between it and the kunmap_atomic(). On any sane architecture, kmap_atomic() ends up being a no-op from an implementation standpoint, and sleeping would work just fine. But we very much want to make sure that people don't then write code that doesn't work on the bad old 32-bit machines where it really needs that sequence to be safe from preemption. So it's mostly a debug thing. I say "mostly", because there might be small other details too, like shared code, and perhaps even a couple of users out in the wild that depend on the pagefault_disable() inherent in the current kmap_atomic(), who knows.. So no, the preemption disabling isn't inherent in the operation itself. But it does have some argument for it. Linus _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [patch 00/13] preempt: Make preempt count unconditional Date: Mon, 14 Sep 2020 23:39:14 -0700 Message-ID: References: <20200914204209.256266093@linutronix.de> <871rj4owfn.fsf@nanos.tec.linutronix.de> <20200915062253.GA26275@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7AZvvtnOCrBJ0y7Ea7nJQgHCW8PeMBJ8MoPUyYrAJro=; b=Gqovwkb5A8FW/jwlWWxLLQ/avI7lnDibBgUBcgb3YHy5ole3D6O2HF9xebthy2Sa7D pdxdxxmQzGYxo9HEtGYBgkQkdY49pjUNwIF0aUEETd48RydGVCxehC4UHZ1aoiJMH2WY rTXUOrEKNo5NyWYCWs4UE3XuCPJLSnSLauj5I= In-Reply-To: <20200915062253.GA26275@gondor.apana.org.au> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Herbert Xu Cc: Juri Lelli , Peter Zijlstra , Sebastian Andrzej Siewior , Lai Jiangshan , dri-devel , Ben Segall , Linux-MM , linux-hexagon@vger.kernel.org, Will Deacon , Ingo Molnar , Anton Ivanov , linux-arch , Brian Cain , Richard Weinberger , Russell King , Ard Biesheuvel , David Airlie , Ingo Molnar , Geert Uytterhoeven , Mel Gorman , intel-gfx , Matt Turner , Valentin Schneider , linux-xtensa@li On Mon, Sep 14, 2020 at 11:24 PM Herbert Xu wrote: > > On Tue, Sep 15, 2020 at 09:20:59AM +0300, Ard Biesheuvel wrote: > > > > The documentation of kmap_atomic() states the following: > > > > * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap > > * gives a more generic (and caching) interface. But kmap_atomic can > > * be used in IRQ contexts, so in some (very limited) cases we need > > * it. > > > > so if this is no longer accurate, perhaps we should fix it? > > This hasn't been accurate for at least ten years :) Yeah, that used to be true a long long time ago, but the comment is very stale. > > But another reason I tried to avoid kmap_atomic() is that it disables > > preemption unconditionally, even on 64-bit architectures where HIGHMEM > > is irrelevant. So using kmap_atomic() here means that the bulk of > > WireGuard packet encryption runs with preemption disabled, essentially > > for legacy reasons. > > Agreed. We should definitely fix that. Well, honestly, one big reason for that is debugging. The *semantics* of the kmap_atomic() is in the name - you can't sleep in between it and the kunmap_atomic(). On any sane architecture, kmap_atomic() ends up being a no-op from an implementation standpoint, and sleeping would work just fine. But we very much want to make sure that people don't then write code that doesn't work on the bad old 32-bit machines where it really needs that sequence to be safe from preemption. So it's mostly a debug thing. I say "mostly", because there might be small other details too, like shared code, and perhaps even a couple of users out in the wild that depend on the pagefault_disable() inherent in the current kmap_atomic(), who knows.. So no, the preemption disabling isn't inherent in the operation itself. But it does have some argument for it. Linus