linux-kernel - Re: [PATCH] drm/atomic: do not branch based on the value of current->comm[0]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <26ef4a7059dd995731e2d4426c2400b2@abrecht.li>
Date:   Wed, 16 Nov 2022 09:48:45 +0100
From:   Daniel Abrecht 
        <freedesktop-linux-dri-devel@...marc.danielabrecht.ch>
To:     "Jason A. Donenfeld" <Jason@...c4.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>
Cc:     dri-devel@...ts.freedesktop.org, linux-api@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Michel Dänzer <michel@...nzer.net>,
        Christian Brauner <brauner@...nel.org>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel.vetter@...el.com>,
        Sultan Alsawaf <sultan@...neltoast.com>,
        Sean Paul <sean@...rly.run>,
        Nicholas Kazlauskas <nicholas.kazlauskas@....com>
Subject: Re: [PATCH] drm/atomic: do not branch based on the value of
 current->comm[0]

Am 2022-11-05 23:20, schrieb Jason A. Donenfeld:
> This reverts 26b1d3b527e7 ("drm/atomic: Take the atomic toys away from 
> X")

I'm in favor of reverting this commit. I've tried to get allowing to 
enable atomic in Xorg again in there in the past: 
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/533

I've no illusions of getting this through though, after all mostly the 
same people control what's merged into Xorg, what drm stuff gets into 
the kernel and who disabled it in the kernel in the first place. And 
there doesn't seem much interest in dealing with anything Xorg either, 
in the merge request I linked, someone even called Xorg "abandonware". 
This is also why I didn't respond here until now.

I do see value in enabling this. When I looked at this 2 years ago, 
there were situations where enabling atomic brought clear improvements, 
and I would expect that it can still improve performance on some special 
systems. I think the users should have the option to use it if they want 
or need to.

There is also the concern that this may cause a regression, but I would 
argue, that there never was a regression to be fixed here in the first 
place. There may have been that one broken application in the past, but 
it was just that, a broken application, not something broken by the 
kernel. I do not think the kernel should modify it's behavior just to 
work around bugs in a specific program, which have always existed, and 
didn't come from a changer in behavior of the kernel APIs. If a program 
was written wrongly, the program should be fixed, and in case of Xorg, I 
think it is fixed already.

This probably won't mean much coming from me, but:
Acked-by: Daniel Abrecht <public@...ielabrecht.ch>