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 09DF9C433E2 for ; Tue, 15 Sep 2020 17:57:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AB83A20936 for ; Tue, 15 Sep 2020 17:57:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600192630; bh=ZkX4IpJVrUUwnYeEwsTuxnlSCIoNpjg5abSoyxEllB0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=VlNS6zgRaoq50ce7HPoTBEISe3/g1voYjgKpbU33zf8ebrapv4DosycH8pv5RDaCO aDpcSthD6nvV/4kc+JPfUoZLPOZiIvz0oKP0rB2yPMa6rxlanIg+fTM3wK9TsqoIpm tAlcbov6Bff54QVWnOJWxTaNAZg8eIKxOL3/maak= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727980AbgIOR5I (ORCPT ); Tue, 15 Sep 2020 13:57:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36058 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727903AbgIORlM (ORCPT ); Tue, 15 Sep 2020 13:41:12 -0400 Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5AF2DC06174A for ; Tue, 15 Sep 2020 10:41:11 -0700 (PDT) Received: by mail-lf1-x143.google.com with SMTP id x77so4046420lfa.0 for ; Tue, 15 Sep 2020 10:41:11 -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=QlBZag9OUdnzHopCd4YjVglgMcQBgDIsub87PVB2Re9/XHmT9yzYQpg+k25p6IYo0F BjhbWPyekXF9NaDWVgwJqbZqqcrQ2QjojtrD/42NVaHg5loKpW1j17kD/ks3ESg0DvPk bnhRl7Rj+HdBcwwjSwk2jCUPBK91VPC42e+P28qc2AWtsKefR1Qm7dIU8CIYEFH3QwaU /IjpCIEnq7Bm198xJn0xVqvekRYYYji0ttA2I2c3ZdfZaSVGJwdpPNw3YfRUsaVDd34/ GdbOxgXWL009RCj1kwwE7XTcl550wsrtJ0ZAx0KVfSu9igjrbi2KqyMjHd6P9RIzE7Ni eHqw== X-Gm-Message-State: AOAM532IZGFQVbA6RYz8ni0EB4v71PJqyEtojjFX2O3Z+JNu83i+Me1f WoLV7ffdlQ60eiWuMeG/0LC9bnYjUwgj2w== X-Google-Smtp-Source: ABdhPJzZgVJfXfjZnBbyJr/JN61EW3omwv7gkoHkJDv83cPfow5juGOjfladz6LEKXmzRkVz+h7DIQ== X-Received: by 2002:ac2:491e:: with SMTP id n30mr5966762lfi.395.1600191669479; Tue, 15 Sep 2020 10:41:09 -0700 (PDT) Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com. [209.85.167.49]) by smtp.gmail.com with ESMTPSA id x5sm4068196lfd.119.2020.09.15.10.41.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Sep 2020 10:41:09 -0700 (PDT) Received: by mail-lf1-f49.google.com with SMTP id d15so3970102lfq.11 for ; Tue, 15 Sep 2020 10:41:09 -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" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 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 2D8A0C2D0E0 for ; Tue, 15 Sep 2020 17:43:46 +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 BE3AF208E4 for ; Tue, 15 Sep 2020 17:43:45 +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="hFeX95/T" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BE3AF208E4 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 29C376E138; Tue, 15 Sep 2020 17:43:45 +0000 (UTC) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8F4C66E138 for ; Tue, 15 Sep 2020 17:43:44 +0000 (UTC) Received: by mail-lj1-x241.google.com with SMTP id v23so3624167ljd.1 for ; Tue, 15 Sep 2020 10:43:44 -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=ESEe0YT9QTP125MyNm0elOjmuoC1C05MVnjkuaVsXREDOEaoP5yBsw2HJcnni9b6qa cfpVwLBqtzFgIcCBvlKeMmZP3+1vkKTGZdXgNQuWvMy7bHYM+fjcnrWdhGXHCF8AYilv wrjUerm0tq2xmO5U4kQ0FNboe1FgILSxoH27dVkuMmANmODxan7pSrWCZSxWC71tGQqe LwbewtMhuDFQHCWkvdMn/Q4foFJom13RlhXSc+nKDFc7jHl4HgDBndLaLACPShhPlu4A IEaDiJJPRVjRjygoOmX19Bu7gx6gctgpaFLWeeQH/vYa20L20szZ2QCEWBqJrBDoPrzC nVLA== X-Gm-Message-State: AOAM533W1WTaryrjC1x99JLsSXd8VtRRATLM5RByi+g9kqgZQT7pLrl+ KuvM0q1dlQy8ssra68XdsO10PTyJWrz/4w== X-Google-Smtp-Source: ABdhPJwyS7+5OEqyfiP6cXmBhkWzhlEfpPsibkXyPlxGXfmaoasMhwnM53LQTKtD79STDTazi+mZmg== X-Received: by 2002:a05:651c:106f:: with SMTP id y15mr7582296ljm.170.1600191822662; Tue, 15 Sep 2020 10:43:42 -0700 (PDT) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com. [209.85.167.54]) by smtp.gmail.com with ESMTPSA id d18sm4062369lfm.178.2020.09.15.10.43.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Sep 2020 10:43:42 -0700 (PDT) Received: by mail-lf1-f54.google.com with SMTP id q8so4015462lfb.6 for ; Tue, 15 Sep 2020 10:43:42 -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 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 , "open list:KERNEL SELFTEST FRAMEWORK" , linux-hexagon@vger.kernel.org, Will Deacon , Ingo Molnar , Anton Ivanov , linux-arch , Vincent Guittot , Herbert Xu , 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 , 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 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 _______________________________________________ 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 433D2C433E2 for ; Tue, 15 Sep 2020 17:43:25 +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 C4A0B208E4 for ; Tue, 15 Sep 2020 17:43:24 +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="hFeX95/T" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C4A0B208E4 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 9992589CAD; Tue, 15 Sep 2020 17:43:23 +0000 (UTC) Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) by gabe.freedesktop.org (Postfix) with ESMTPS id A3ECA89CAD for ; Tue, 15 Sep 2020 17:43:22 +0000 (UTC) Received: by mail-lf1-x141.google.com with SMTP id w11so4050212lfn.2 for ; Tue, 15 Sep 2020 10:43:22 -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=orv+tgp6EB9WeF6gg/ob5uAmGBtIzIdyPb5QKmDQmipzRVQEC6yudIImnWZlHdXn6J ytWa0zDV1HSb0jw7QGmRQ3o744y88U4bT1nMjI8DAju+UsrnmpHHSavC7xWnZU6MY0FG Lm3V4ba1pzoiSsmuhli51hGEPvCNw4OhpSYja9OZWmgwaDRFfWHpa/UgdFtqNWjV5kJr IpqzDrxF+KiYQv/p4fwWpE9Q0frSOr0F1bJCdzk+5bpJVSgRTRmsCHG6Gz3fHhGuzZDo awp/zzE3BlqYZ4RoaoCq6zfYj/Bd3kYtvNBEUKWOUGKCy126gQgYod1Wd17ncEFl6on9 JPJg== X-Gm-Message-State: AOAM530FJ2Yd4N1wxe2ut60c0uwDe1CQGaWczdH8qzZwJkO9LZgbmHSE 3LHQby1XgqQEWwlkde/ZN/Rm2ZodeWHESQ== X-Google-Smtp-Source: ABdhPJxVp/eVd2xo6P0X4ynbThTcTu+E6IHG7/gBX/pyHHaLVmKaiJSbWiflEFw/YKzrDcOPIdvqwQ== X-Received: by 2002:a19:7b14:: with SMTP id w20mr6859837lfc.563.1600191800637; Tue, 15 Sep 2020 10:43:20 -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 v11sm4430096lfg.39.2020.09.15.10.43.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Sep 2020 10:43:20 -0700 (PDT) Received: by mail-lf1-f41.google.com with SMTP id y2so3977910lfy.10 for ; Tue, 15 Sep 2020 10:43:20 -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: To: Thomas Gleixner 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 , "open list:KERNEL SELFTEST FRAMEWORK" , linux-hexagon@vger.kernel.org, Will Deacon , Ingo Molnar , Anton Ivanov , linux-arch , Herbert Xu , 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 , 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 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 _______________________________________________ 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: Tue, 15 Sep 2020 10:35:20 -0700 Message-ID: References: <20200914204209.256266093@linutronix.de> <871rj4owfn.fsf@nanos.tec.linutronix.de> <87bli75t7v.fsf@nanos.tec.linutronix.de> Mime-Version: 1.0 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=0nYcbfWZAApGs9MKHeuMMDYKDYJP/KjXcIMY7yTiRjk=; b=hFeX95/TT9jtwZAL/DonKpuMHGRk/7SCmZequDM1VaRmacKDQZY4lc39NgOcx0VujL ul3l8yb5Ugprhwk3dogs1JqCkfr90spWSTqKGkSLsF9w3lXrIygeRUDRxh1yw1QSoeb3 vUCYW8AmUQyz6zbxknLrsvz9nPCTdNe9Dcd+4= In-Reply-To: <87bli75t7v.fsf@nanos.tec.linutronix.de> Sender: linux-hexagon-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 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