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