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 34E22C433E2 for ; Tue, 15 Sep 2020 17:42:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BC333208E4 for ; Tue, 15 Sep 2020 17:42:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="hFeX95/T" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BC333208E4 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 15A05900074; Tue, 15 Sep 2020 13:42:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 10AA8900066; Tue, 15 Sep 2020 13:42:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F3BFA900074; Tue, 15 Sep 2020 13:42:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0157.hostedemail.com [216.40.44.157]) by kanga.kvack.org (Postfix) with ESMTP id D8125900066 for ; Tue, 15 Sep 2020 13:42:14 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 99A35180AD807 for ; Tue, 15 Sep 2020 17:42:14 +0000 (UTC) X-FDA: 77266014588.11.sail42_140d4e327113 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id 5D9C4180F8B86 for ; Tue, 15 Sep 2020 17:42:14 +0000 (UTC) X-HE-Tag: sail42_140d4e327113 X-Filterd-Recvd-Size: 6873 Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com [209.85.208.67]) by imf46.hostedemail.com (Postfix) with ESMTP for ; Tue, 15 Sep 2020 17:42:13 +0000 (UTC) Received: by mail-ed1-f67.google.com with SMTP id l17so3850082edq.12 for ; Tue, 15 Sep 2020 10:42:13 -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=0nYcbfWZAApGs9MKHeuMMDYKDYJP/KjXcIMY7yTiRjk=; b=hFeX95/TT9jtwZAL/DonKpuMHGRk/7SCmZequDM1VaRmacKDQZY4lc39NgOcx0VujL ul3l8yb5Ugprhwk3dogs1JqCkfr90spWSTqKGkSLsF9w3lXrIygeRUDRxh1yw1QSoeb3 vUCYW8AmUQyz6zbxknLrsvz9nPCTdNe9Dcd+4= 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=0nYcbfWZAApGs9MKHeuMMDYKDYJP/KjXcIMY7yTiRjk=; b=kOF+/xrxvXg2E1DqsjWWf1ZgyBEqfiaysxxnyhvPMDfVn3cjmJZeB9hA5l6T2SKrGr gttRNkZaDaP9dNstIloNf7gIX8rjbLFxyIiwKw7/Fv/dTs+lU08kDS3oUaFPkuBpAxO+ uIO4UgSRjNDtSpGy8kc2jiU8IlKZuDcBGaoSVdlxV01d8x3MZzQzH82QxFUR9f/4xa3t gOhKxnD1DUVcuAcIaaqPAShbS4X0vXN3P7DvxaCXxH5TB4ZQrNVnEZuVovfJGuRb0vLd 6EOhOophFsVcNUGojlMlkYWJqWu9BTRF2gKQEEHOF7tt1aCMDWE/LKe7D1US5iG7WEwK zcuw== X-Gm-Message-State: AOAM533cyJ3+E8fWRgFm1Y76XLx6kZ9VMqI7bUpm1PHoEdmlzlbdkveW 8/DuE5k7/gXka8h5aLZ/2/gkRWT6PZvSnw== X-Google-Smtp-Source: ABdhPJyhsyIB7vJQpY8UUd+HAumks3qzHoaT07opxsSRmqRbFPkKnhk88ENI78h0yCH7WmCwNE8Q7g== X-Received: by 2002:a50:fe82:: with SMTP id d2mr22870352edt.86.1600191732111; Tue, 15 Sep 2020 10:42:12 -0700 (PDT) Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com. [209.85.221.46]) by smtp.gmail.com with ESMTPSA id ly16sm10780290ejb.58.2020.09.15.10.42.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Sep 2020 10:42:11 -0700 (PDT) Received: by mail-wr1-f46.google.com with SMTP id z1so4248562wrt.3 for ; Tue, 15 Sep 2020 10:42:11 -0700 (PDT) X-Received: by 2002:ac2:5594:: with SMTP id v20mr6798322lfg.344.1600191336149; Tue, 15 Sep 2020 10:35:36 -0700 (PDT) MIME-Version: 1.0 References: <20200914204209.256266093@linutronix.de> <871rj4owfn.fsf@nanos.tec.linutronix.de> <87bli75t7v.fsf@nanos.tec.linutronix.de> In-Reply-To: <87bli75t7v.fsf@nanos.tec.linutronix.de> From: Linus Torvalds Date: Tue, 15 Sep 2020 10:35:20 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch 00/13] preempt: Make preempt count unconditional To: Thomas Gleixner Cc: Ard Biesheuvel , Herbert Xu , 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, "open list:KERNEL SELFTEST FRAMEWORK" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 5D9C4180F8B86 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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 Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner wrote: > > OTOH, having a working 'preemptible()' or maybe better named > 'can_schedule()' check makes tons of sense to make decisions about > allocation modes or other things. No. I think that those kinds of decisions about actual behavior are always simply fundamentally wrong. Note that this is very different from having warnings about invalid use. THAT is correct. It may not warn in all configurations, but that doesn't matter: what matters is that it warns in common enough configurations that developers will catch it. So having a warning in "might_sleep()" that doesn't always trigger, because you have a limited configuration that can't even detect the situation, that's fine and dandy and intentional. But having code like if (can_schedule()) .. do something different .. is fundamentally complete and utter garbage. It's one thing if you test for "am I in hardware interrupt context". Those tests aren't great either, but at least they make sense. But a driver - or some library routine - making a difference based on some nebulous "can I schedule" is fundamentally and basically WRONG. If some code changes behavior, it needs to be explicit to the *caller* of that code. So this is why GFP_ATOMIC is fine, but "if (!can_schedule()) do_something_atomic()" is pure shite. And I am not IN THE LEAST interested in trying to help people doing pure shite. We need to fix them. Like the crypto code is getting fixed. Linus