Received: by 2002:a05:6358:16cd:b0:dc:6189:e246 with SMTP id r13csp3021058rwl; Sat, 5 Nov 2022 15:58:58 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5MXBUjXRsKTzw+acjuUjhYRtuyQcvEL5YC/4xMsHryozjJj0pp926yRYKFF0W0sIVgysVT X-Received: by 2002:a05:6402:3223:b0:461:8635:e5c with SMTP id g35-20020a056402322300b0046186350e5cmr42666756eda.303.1667689138178; Sat, 05 Nov 2022 15:58:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667689138; cv=none; d=google.com; s=arc-20160816; b=qot0+Z15dvwbqgvCMN2atK+BGo7TVsbpqOp7Jfovq1aF4ug5rURrIZOLuyvOaxK013 1b1AS/D1znwge+GGkJiQJCuOomZ0/JZKfHy1IGvVKqfMk7lugWi9E1AHLRu8srb+nDw0 +CzFJqn7C15Zmiz2v/015p5VqSNpMtLKOJ0YsBeR/rbjALt/5HX/YVNmYIwcmtzcEDlV BgecM+9KcSzeZIhA3+2BBBK3Km0hrPMzvTvVnhBxguZQ95z1n6Z/MToEzrXscXV4HYcn ZwMNmBkJef/zmdIlT5xsDeZt9Z6LA5wu39XEkeEIRHZynf0Lkg7Nw67vtZAMbR89ghJX wjfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=GokT8QcZOOF1Sj+w1E78zsAC5vdLp3dZxLPEamRZIQc=; b=BRR5SmjfC6zajUJPurfvzUEfc4/KQygNqmvBAFruSgQmRiw1+/8wKNN5cLpDqBTtTD RRB/XvmdeIlYoOA7XRzp1ljz/PtIU4CjXXQltGVXMnW3zTP78wBZbnnXeuI6CMwWQwGN qBQ7jkCf7RvSExgBEXCSO0aU74BwZZ/DxnDtwblKlRkk8Lw56ZfX4EPYV9hl/7eA4zmC oSgYnuS7tc9aE0m0IHlJTv6hLABYiNGZva9jYTKE2Nl2W1M2WzrvYzYBsZNyFi2lRpjE eE3giTceEMnCiXf7QTT6Z9jj89ruwDD5ZqaRsG2d8yYIKykztHiHnwMOAoDfezBcFK1T BQbQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@zx2c4.com header.s=20210105 header.b=NiluAsAW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=zx2c4.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hz5-20020a1709072ce500b0078c9dd279b6si3458900ejc.345.2022.11.05.15.58.34; Sat, 05 Nov 2022 15:58:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@zx2c4.com header.s=20210105 header.b=NiluAsAW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=zx2c4.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229822AbiKEWVB (ORCPT + 96 others); Sat, 5 Nov 2022 18:21:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44480 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229453AbiKEWVA (ORCPT ); Sat, 5 Nov 2022 18:21:00 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1F02D11470; Sat, 5 Nov 2022 15:20:59 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id D0E4DB80064; Sat, 5 Nov 2022 22:20:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BEF3EC433D7; Sat, 5 Nov 2022 22:20:54 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="NiluAsAW" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1667686852; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=GokT8QcZOOF1Sj+w1E78zsAC5vdLp3dZxLPEamRZIQc=; b=NiluAsAWGU9q2YBTgfIqH7nw2j4QXLI9zVeGdjIIsiTzIQF6J69JxnxlXhrGVgPJYsTlNf m2iE8C353WC3NFDPhvgr3yf7e8dr5Up3F5jyaGu5chUUnWd3HCjhX+7PdW1ogHNlCnFFUk +6XrN1/n8nwHh1xBkhJAboxHjNS2tOg= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 969eda74 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 5 Nov 2022 22:20:52 +0000 (UTC) From: "Jason A. Donenfeld" To: dri-devel@lists.freedesktop.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org Cc: "Jason A. Donenfeld" , Daniel Vetter , Peter Zijlstra , Ilia Mirkin , Maarten Lankhorst , Nicholas Kazlauskas , Christian Brauner , =?UTF-8?q?Michel=20D=C3=A4nzer?= , Alex Deucher , Adam Jackson , Greg Kroah-Hartman , Sean Paul , David Airlie , Rob Clark , Sultan Alsawaf Subject: [PATCH] drm/atomic: do not branch based on the value of current->comm[0] Date: Sat, 5 Nov 2022 23:20:12 +0100 Message-Id: <20221105222012.4226-1-Jason@zx2c4.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This reverts 26b1d3b527e7 ("drm/atomic: Take the atomic toys away from X"), a rootkit-like kludge that has no business being inside of a general purpose kernel. It's the type of debugging hack I'll use momentarily but never commit, or a sort of babbies-first-process-hider malware trick. The backstory is that some userspace code -- xorg-server -- has a modesetting DDX that isn't really coded right. With nobody wanting to maintain X11 anymore, rather than fixing the buggy code, the kernel was adjusted to avoid having to touch X11. A bummer, but fair enough: if the kernel doesn't want to support some userspace API any more, the right thing to do is to arrange for a graceful fallback where userspace thinks it's not available in a manageable way. However, the *way* it goes about doing that is just to check `current->comm[0] == 'X'`, and disable it for only that case. So that means it's *not* simply a matter of the kernel not wanting to support a particular userspace API anymore, but rather it's the kernel not wanting to support xorg-server, in theory, but actually, it turns out, that's all processes that begin with 'X'. Playing games with current->comm like this is obviously wrong, and it's pretty shocking that this ever got committed. Fortunately, since this was committed, somebody did actually disable the userspace side by default in X11: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/180 and this was three years ago. So userspace is mostly fine now for ordinary default usage. And people who opt into this -- since it does actually work fine for many use cases on i915 -- ostensibly know what they're getting themselves into (my case). So let's just revert this `comm[0] == 'X'` business entirely, but still allow for `value == 2`, in case anybody actually started working on that part elsewhere. Fixes: 26b1d3b527e7 ("drm/atomic: Take the atomic toys away from X") Cc: Daniel Vetter Cc: Peter Zijlstra Cc: Ilia Mirkin Cc: Maarten Lankhorst Cc: Nicholas Kazlauskas Cc: Christian Brauner Cc: Michel Dänzer Cc: Alex Deucher Cc: Adam Jackson Cc: Greg Kroah-Hartman Cc: Sean Paul Cc: David Airlie Cc: Rob Clark Cc: Sultan Alsawaf Signed-off-by: Jason A. Donenfeld --- drivers/gpu/drm/drm_ioctl.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c index ca2a6e6101dc..017f31e67179 100644 --- a/drivers/gpu/drm/drm_ioctl.c +++ b/drivers/gpu/drm/drm_ioctl.c @@ -336,11 +336,6 @@ drm_setclientcap(struct drm_device *dev, void *data, struct drm_file *file_priv) case DRM_CLIENT_CAP_ATOMIC: if (!drm_core_check_feature(dev, DRIVER_ATOMIC)) return -EOPNOTSUPP; - /* The modesetting DDX has a totally broken idea of atomic. */ - if (current->comm[0] == 'X' && req->value == 1) { - pr_info("broken atomic modeset userspace detected, disabling atomic\n"); - return -EOPNOTSUPP; - } if (req->value > 2) return -EINVAL; file_priv->atomic = req->value; -- 2.38.1