On Thu, Aug 21, 2025 at 4:29 PM David Hildenbrand wrote:
> > Because doing a 64-bit shift on x86-32 is like three cycles. Doing a
> > 64-bit signed division by a simple constant is something like ten
> > strange instructions even if the end result is only 32-bit.
>
> I would have thought that the
Oh, an your reply was an invalid email and ended up in my spam-box:
From: David Hildenbrand
but you apparently didn't use the redhat mail system, so the DKIM signing fails
dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE)
header.from=redhat.com
and it gets marked as spam.
I thin
On Thu, 21 Aug 2025 at 16:08, David Hildenbrand wrote:
>
> - page = nth_page(page, offset >> PAGE_SHIFT);
> + page += offset / PAGE_SIZE;
Please keep the " >> PAGE_SHIFT" form.
Is "offset" unsigned? Yes it is, But I had to look at the source code
to make sure, because it wasn't local
On Thu, 31 Jul 2025 at 06:09, Alex Deucher wrote:
>
> I think it may be fixed here:
> https://patchwork.freedesktop.org/patch/663973/
Yes, this patch fixes the problem for me.
I don't know if it's due to the pointer validation (ie this part):
- if (!dsc)
+ if (!dsc || !dsc->ctx || !
On Wed, 30 Jul 2025 at 21:58, Linus Torvalds
wrote:
>
> d7b618bc41ee3d44c070212dff93949702ede997 is the first bad commit
> drm/amd/display: Refactor DSC cap calculations
>
> Let me go see how painful it is to just revert it from top-of-tree.
So with that reverted (didn
On Wed, 30 Jul 2025 at 21:48, Linus Torvalds
wrote:
>
> Well, it's one of these:
>
> 3f2b24a1ef35 drm/amd/display: Monitor patch to ignore EDID audio SAB check
> aef3af22a456 drm/amd/display: Add definitions to support DID Type5
> descriptors
> d7b618bc41ee drm
On Wed, 30 Jul 2025 at 21:36, Dave Airlie wrote:
>
> https://lore.kernel.org/dri-devel/20250717204819.731936-1-mustela@erminea.space/
>
> is the only thing I can see that might not be in the merge.
Well, it's one of these:
3f2b24a1ef35 drm/amd/display: Monitor patch to ignore EDID audio SAB ch
On Wed, 30 Jul 2025 at 21:26, Linus Torvalds
wrote:
>
> The good news is that it's bisecting without any ambiguity. So nowhere
> near as painful as last merge window.
Right now it's in the range 1b556bcc3837..63b8c9fdfb7f.
A few more bisections and I'll have it down to
On Wed, 30 Jul 2025 at 21:21, Dave Airlie wrote:
>
> Okay I don't have an rx580, but I have an rx480 which is pretty close,
> but it is booting fine with your tree at least, DP and HDMI connected,
> so it's not widespread AMD breakage, anything in journalctl/dmesg?
The machine doesn't come up far
On Wed, 30 Jul 2025 at 20:40, Linus Torvalds
wrote:
>
> I'm very unhappy with the end result, because it just results in a
> black screen at boot for me. No signal.
It's not something in the merge, and it's not something in my tree - I
see the same plain "just
On Wed, 30 Jul 2025 at 20:47, Dave Airlie wrote:
>
> Is that the Polaris card still?
Same old boring Radeon RX 580.
lspci calls it "Ellesmere", don't know about the Polaris codename..
Linus
On Wed, 30 Jul 2025 at 20:39, Dave Airlie wrote:
> >
> > But I do think that the drm people are doing actively wrong things
> > with the random cherry-picks back and forth: they cause these
> > conflicts, and I *really* think you should look at maybe using stable
> > fixes branches instead.
> >
>
On Wed, 30 Jul 2025 at 20:05, Linus Torvalds
wrote:
>
> Again: I'm not going to guarantee that I got it right. I *think* I did
> - I'm not feeling particularly unhappy with my merge end result.
I spoke too soon.
I'm very unhappy with the end result, because it just resu
,
On Tue, 29 Jul 2025 at 14:06, Dave Airlie wrote:
>
> I've done a pass at merging mostly taking from drm-tip:
> https://github.com/airlied/linux/tree/drm-next-6.17-rc1-merged
Hmm. My resolution is pretty different, but part of it is that your
test-merge has a different top-of-tree than the tree
On Fri, 25 Jul 2025 at 13:32, Dave Airlie wrote:
>
> Okay this time hopefully in plain text from the start
Apparently your weekend muscle memory theory was indeed correct.
Linus
On Thu, 24 Jul 2025 at 01:50, Jacek Lawrynowicz
wrote:
>
> Such behavior propagates down and makes the community miserable.
Google "friendly ribbing".
Linus
On Wed, 23 Jul 2025 at 17:40, Dave Airlie wrote:
>
> (this time for sure, plain text).
I knew you could do it! Third time's the charm!
I hope I don't need to worry about the branch contents as much as I
apparently need to worry about your email sending capabilities?
Linus
On Fri, 11 Jul 2025 at 14:46, Linus Torvalds
wrote:
>
> I've only tested the previous commit being good twice now, but I'll go
> back to the head of tree and try a revert to verify that this is
> really it. Because maybe it's the now Nth time I found something that
&
On Fri, 11 Jul 2025 at 13:35, Linus Torvalds
wrote:
>
> Indeed. It turns out that the problem actually started somewhere
> between rc4 and rc5, and all my previous bisections never even came
> close, because kernels usually work well enough that I never realized
> that it went bac
On Fri, 11 Jul 2025 at 13:07, Linus Torvalds
wrote:
>
> Oh well. I think I'll just have to go back to bisecting this thing.
> I've tried to do that several times, and it has failed due to being
> too flaky, but I think I've learnt the signs to look out for better
> t
On Fri, 11 Jul 2025 at 12:53, Jakub Kicinski wrote:
>
> Let me keep digging but other than the netlink stuff the rest doesn't
> stand out..
Oh well. I think I'll just have to go back to bisecting this thing.
I've tried to do that several times, and it has failed due to being
too flaky, but I thin
On Fri, 11 Jul 2025 at 12:30, Linus Torvalds
wrote:
>
> So that "Oh, it worked this time" has been tainted by past experience.
> Will do several more boots now in the hope that it's gone for good.
Yeah, no.
There's still something wrong. The second boot looked fine,
On Fri, 11 Jul 2025 at 12:18, Linus Torvalds
wrote:
>
> I spent several hours yesterday chasing all the wrong things (because
> I thought it was in drm), and often thought "Oh, that fixed it". Only
> to then realize that nope, the problem still happens.
>
> I will tes
On Fri, 11 Jul 2025 at 11:54, Linus Torvalds
wrote:
>
> Will do more testing.
Bah. What I thought was a "reliable hang" isn't actually that at all.
It ends up still being very random indeed.
That said, I do think it's related to this netlink issue, because the
sy
On Fri, 11 Jul 2025 at 11:46, Jakub Kicinski wrote:
>
> Hm. I'm definitely okay with reverting. So if you revert these three:
>
> a3c4a125ec72 ("netlink: Fix rmem check in netlink_broadcast_deliver().")
> a3c4a125ec72 ("netlink: Fix rmem check in netlink_broadcast_deliver().")
> ae8f160e7eb2 ("net
On Fri, 11 Jul 2025 at 10:35, Linus Torvalds
wrote:
>
> I'm hoping the login time timeout / hang ends up being due to a known
> netlink regression, and it just happened to look like a drm issue
> because it exposes itself as a hang at the first graphical login
>
> A netlink
[ Added in some drm people too, just to give a heads-up that it isn't
all their fault ]
On Fri, 11 Jul 2025 at 08:10, Jakub Kicinski wrote:
>
> The Netlink fixes (on top of the tree) restore
> operation of iw (WiFi CLI) which uses sillily small recv buffer,
> and is the reason for this "emergenc
On Fri, 11 Jul 2025 at 08:48, Linus Torvalds
wrote:
>
> Background for others: current -git ends up having odd hangs when
> Xwayland starts for me (not at boot, but when I log in). It seems to
> be very timing-dependent, so presumably I'm just unlucky with my
> hardware.
Up
On Fri, 11 Jul 2025 at 02:40, Thomas Zimmermann wrote:
>
> Reverting the whole thing is the only sensible action here.
I'm assuming this is against some current drm tree, not mine, because
it doesn't apply here.
I'll try the smaller set of reverts that Simona suggested for my
testing, and will g
On Tue, 3 Jun 2025 at 10:26, Steven Rostedt wrote:
>
> config DRM_TTM
> tristate
> - depends on DRM && MMU
> + depends on DRM && MMU && SHMEM
Yeah, except I think you should just make it be
depends on DRM && SHMEM
because SHMEM already depends on MMU.
That said,
On Tue, 27 May 2025 at 20:51, Dave Airlie wrote:
>
> I've put a trial merge result at
> https://github.com/airlied/linux/tree/drm-next-6.16-rc1-merged
I have trivial differences due to picking different line ordering for
some things, but your merge also left in a wrong (but ultimately
harmless) d
On Mon, 28 Apr 2025 at 12:54, Josh Poimboeuf wrote:
>
> BTW, I've noticed Clang also generates UB for negative shift values. I
> assume we'd want it to stop checking for those as well.
Yeah, that seems to match the exact same issue.
And again - the correct fix would be for the compiler to not d
On Mon, 28 Apr 2025 at 11:08, Bill Wendling wrote:
>
> This situation is one of the
> easier ones: "do something other than fall into the next function";
Note that the "fall into the next function" is just something that
objtool notices. It *could* be "fall into the next basic block of the
same f
On Sat, 26 Apr 2025 at 16:23, Nathan Chancellor wrote:
>
> Pardon my ignorance though, isn't something like this
> basically just '-fsanitize=undefined -fsanitize-trap=all'?
Sure. Except -fsanitize=undefined is a horrible horrible thing.
Why? Because it pointlessly adds code to *look* for undef
On Sat, 26 Apr 2025 at 13:05, Nathan Chancellor wrote:
>
> KBUILD_CFLAGS += -mllvm -trap-unreachable
Hmm. That certainly builds for me, but yeah, it generates new objtool
warnings, notably
panic() missing __noreturn in .c/.h or NORETURN() in noreturns.h
and I *think* that is because that
On Sat, 26 Apr 2025 at 10:42, Linus Torvalds
wrote:
>
> We had something similar some time ago, where there was a drm
> assertion without error handling, which caused the compiler to see
> that there was a static path where the invalid value was used, and
> then caused other pro
So with clang, I get these drm build warnings
drivers/gpu/drm/amd/amdgpu/../display/dc/basics/fixpt31_32.o:
warning: objtool: dc_fixpt_recip() falls through to next function
dc_fixpt_sinc()
drivers/gpu/drm/amd/amdgpu/../display/dc/sspl/spl_fixpt31_32.o:
warning: objtool: spl_fixpt_r
On Fri, 25 Apr 2025 at 23:54, Dave Airlie wrote:
>
> It seems to have recovered now, but not sure how stable is it, please
> repull the original PR when you get a chance.
Yup, all good now. Thanks,
Linus
On Fri, 25 Apr 2025 at 16:12, Dave Airlie wrote:
>
> Weekly drm fixes, mostly amdgpu, with some exynos cleanups and a
> couple of minor fixes, seems a bit quiet, but probably some lag from
> Easter holidays.
Hmm. Is freedesktop.org feeling a bit under the weather?
I'm getting
remote: GitLab i
On Wed, 9 Apr 2025 at 00:29, Christian König wrote:
>
> I mean open coding the limit checks everywhere certainly works, but as far as
> I can see it would be more defensive if we do that inside kvmalloc_array().
No.
If we add some limit to kvmalloc_array(), I guarantee that people will
just the
On Tue, 8 Apr 2025 at 09:07, Fedor Pchelkin wrote:
>
> > Linus comment is about kvmalloc(), but the code here is using
> > kvmalloc_array() which as far as I know is explicitly made to safely
> > allocate arrays with parameters provided by userspace.
No.
ABSOLUTELY NOTHING CAN ALLOCATE ARRAYS WI
On Tue, 8 Apr 2025 at 01:28, Jani Nikula wrote:
>
> Your goal may be to make everything self-contained, but AFAICS there is
> no agreement on that goal.
Yeah, absolutely not.
I'm not interested in making some general rule that all headers should
be self-contained.
We already have some fairly ob
On Sat, 5 Apr 2025 at 15:34, Linus Torvalds
wrote:
>
> Does any of this happen to fix this (repeated a couple of hundred
> times each time):
>
> [drm] scheduler comp_1.1.1 is not ready, skipping
> [drm] scheduler comp_1.3.0 is not ready, skipping
> [drm] scheduler co
I was going to report this separately, but then the pull came in, so
I'm just replying to that one instead...
On Sat, 5 Apr 2025 at 14:51, Dave Airlie wrote:
>
> amdgpu:
Does any of this happen to fix this (repeated a couple of hundred
times each time):
[drm] scheduler comp_1.1.1 is not ready
On Wed, 2 Apr 2025 at 05:47, Jani Nikula wrote:
>
> Another go at hiding the turds.
The patches look sane to me.
I didn't _test_ them - because that's not how I roll - but they look
like they would do the right thing and not interfere with my odd TAB
lifestyle (I say "odd", because apparently I'
On Tue, 1 Apr 2025 at 05:21, Jani Nikula wrote:
>
> The header checks have existed for uapi headers before, including the,
> uh, turds, but apparently adding them in drm broke the camel's back.
The uapi header test things never caused any problems for me [*],
because they don't actually pollute t
On Mon, 31 Mar 2025 at 03:17, Jani Nikula wrote:
>
> I suggest a Kconfig knob to truly make this opt-in, only for developers
> who actually want it.
So honestly, the thing I *really* hated was the horrendous naming.
I live in auto-complete. I basically never type out file-names, and I
replace ke
On Thu, 27 Mar 2025 at 19:53, Dave Airlie wrote:
>
> This is the main drm pull request for 6.15. Bit late, but my wife was
> away getting a PhD and kids took over my writing summaries time, and
> fd.o was offline last week which slowed me down a small bit.
Grr. I did the pull, resolved the (trivi
Side note: I think you do something while editing or
cutting-and-pasting that loses indentation.
I sometimes have to guess at what the intended grouping is.
In this case, notice the "More catalog fixes" entry for the msm driver.
I *think* it refers to all the following bullet points up until the
On Fri, 7 Feb 2025 at 10:02, Hector Martin wrote:
>
> Meanwhile, for better or worse, much of Linux infra *is* centralized -
> for example, the mailing lists themselves, and a lot of the Git hosting.
The mailing lists are mostly on kernel.org, but the git hosting most
certainly is not centralized
On Thu, 6 Feb 2025 at 01:19, Hector Martin wrote:
>
> If shaming on social media does not work, then tell me what does,
> because I'm out of ideas.
How about you accept the fact that maybe the problem is you.
You think you know better. But the current process works.
It has problems, but problem
On Sun, 2 Feb 2025 at 12:15, Dave Airlie wrote:
>
> Currently FW_CACHE is an optional feature (that distros may or may not
> configure off), where we will cache loaded firmwares to avoid problems
> over suspend/resume (and speed up resume).
>
> I've just discovered a problem in nouveau's suspend c
On Thu, 23 Jan 2025 at 05:56, Vignesh Raman wrote:
>
> Documentation/ci/gitlab-ci/images/drm-vkms.png | Bin 0 -> 73810 bytes
> .../ci/gitlab-ci/images/job-matrix.png | Bin 0 -> 2 bytes
> .../ci/gitlab-ci/images/new-project-runner.png | Bin 0 -> 607737 bytes
> .../ci/gitlab-ci/image
On Tue, 21 Jan 2025 at 14:59, Rodrigo Vivi wrote:
>
> I'm pushing this soon to drm-intel-next, unless Linus want to take
> this one directly to his tree
Let's just go through the proper channels and go through the drm tree.
Unless I've issed something, I think this is only an active issue on
par
On Thu, 12 Dec 2024 at 21:47, Yafang Shao wrote:
>
> Since task->comm is guaranteed to be NUL-terminated, we can print it
> directly without the need to copy it into a separate buffer.
So i think we should do the "without copying into a separate buffer"
part of this series, but I do think we shou
On Sun, 8 Dec 2024 at 10:11, Martin Uecker wrote:
> >
> > A lot of the 'macro business' for min/max is avoiding unexpected
> > conversion of negative values to very large unsigned ones.
> > And no, -Wsign-compare is spectacularly useless.
>
> This is a different topic, but what would be needed her
On Sat, 7 Dec 2024 at 15:52, Martin Uecker wrote:
>
> Can you point me to some horror stories?
So the main issues tended to be about various static verification tools.
Ranging from things like the stackleak plugin for gcc, where handling
VLA's and alloca() (which are pretty much the same thing w
On Sat, 7 Dec 2024 at 11:19, Martin Uecker wrote:
>
> But that all seem solvable issues on the compiler side.
You know, there was a whole *architecture* that was designed and
predicated on "it's all solvable on the compiler side".
That architecture was pure and utter *shit*.
Because no, it's no
On Sat, 7 Dec 2024 at 11:51, Martin Uecker wrote:
>
> Am Samstag, dem 07.12.2024 um 10:19 -0800 schrieb Linus Torvalds:
> >
> > If there is one feature of C I would have liked it is "allow inline
> > functions and statement expressions with constant argument
On Sat, 7 Dec 2024 at 05:07, Martin Uecker wrote:
>
> VLA use *less* stack than a fixed size arrays with fixed bound.
Not really. You end up with tons of problems, not the least of which
is how to actually analyze the stack size. It also gets *very* nasty
to have code that declares the VLA size u
On Sat, 7 Dec 2024 at 04:24, Vincent Mailhol wrote:
>
> > No good - expands everything twice.
>
> And? __is_const_zero() does not evaluate its arguments, so no side effect:
No, the problem is literally the expansion.
Double expansion of these fundamental helpers gets exponential,
because they ar
On Fri, 6 Dec 2024 at 11:07, David Laight wrote:
>
> I'm missing the compiler version and options to generate the error.
Just -Wall with most recent gcc versions seems to do it. At least I
can repro it with gcc-14.2.1 and something silly like this:
$ cat t.c
int fn(int a) { return (a<<2)?1:2
On Fri, 6 Dec 2024 at 10:52, Linus Torvalds
wrote:
>
> This may be a case of "we just need to disable that incorrect compiler
> warning". Or does anybody see a workaround?
Hmm. The "== 0" thing does work, but as mentioned, that causes (more
valid, imho) warnings
On Fri, 6 Dec 2024 at 10:31, Vincent Mailhol wrote:
>
> > causes issues when 'x' is not an integer expression (think
> > "is_const(NULL)" or "is_const(1 == 2)".
>
> But 1 == 2 already has an integer type as proven by:
Yeah, I was confused about exactly what triggers that odd
'-Wint-in-bool-contex
On Thu, 5 Dec 2024 at 18:26, David Laight wrote:
>
> From: Vincent Mailhol
> > ACK. Would adding a suggested--by Linus tag solve your concern?
I'm genberally the one person who doesn't need any more credit ;)
> I actually suspect the first patches to change __is_constexpr() to
> use _Generic wer
On Fri, 29 Nov 2024 at 14:59, Sasha Levin wrote:
>
> I should be able to reuse their config and just add debug info, no?
Sadly, no. Not unless you exactly match their compiler version. And it
looks like you don't, because the line numbers make no sense.
For example, this is the thing I would exp
On Thu, 28 Nov 2024 at 12:42, Dave Airlie wrote:
>
> Merge window fixes, mostly amdgpu and xe, with a few other minor ones,
> all looks fairly normal,
Hmm. I've pulled this, but do note the report by Sasha.
The
if (WARN_ON(!work->func))
return false;
from __flush_work()
On Fri, 25 Oct 2024 at 12:36, Helge Deller wrote:
>
> Do you want me to send a revert for this specific patch?
No, it's in now, more churn this time around just makes it worse. I
just don't want to see these kinds of non-fixes in the future.
Linus
On Fri, 25 Oct 2024 at 09:04, Helge Deller wrote:
>
> It's mostly about build warning fixes with cornercase CONFIG settings
> and one big patch which removes the now unused da8xx fbdev driver.
So I pulled this, but only later noticed that some of the Kconfig
"fixes" are anything but.
At least co
On Thu, 19 Sept 2024 at 09:48, Dave Airlie wrote:
>
> There are some minor conflicts with your tree but none seemed too
> difficult to solve, let me know if there is any problems on your end.
Christ. One of them is due to you guys being horrible at merging.
Your tree had
drm/xe/gt: Remove d
On Mon, 2 Sept 2024 at 03:34, Christian König wrote:
>
> Am 02.09.24 um 11:32 schrieb Thomas Hellström:
> >
> > The remap_pfn_range was last tried, at least in the context of the i915
> > driver IIRC by Christoph Hellwig but had to be ripped out since it
> > requires the mmap_lock in write mode. H
On Fri, 30 Aug 2024 at 14:08, Dave Airlie wrote:
>
> The TTM revert is due to some stuttering graphical apps probably due
> to longer stalls while prefaulting.
Yeah, trying to pre-fault a PMD worth of pages in one go is just crazy talk.
Now, if it was PMD-aligned and you faulted in a single PMD,
On Sat, 17 Aug 2024 at 01:48, Alejandro Colomar wrote:
>
> I would compact the above to:
>
> len = strlen(s);
> buf = kmalloc_track_caller(len + 1, gfp);
> if (buf)
> strcpy(mempcpy(buf, s, len), "");
No, we're not doing this kind of horror.
If _FORTIFY_SO
On Mon, 5 Aug 2024 at 20:01, Yafang Shao wrote:
>
> One concern about removing the BUILD_BUG_ON() is that if we extend
> TASK_COMM_LEN to a larger size, such as 24, the caller with a
> hardcoded 16-byte buffer may overflow.
No, not at all. Because get_task_comm() - and the replacements - would
ne
On Sun, 4 Aug 2024 at 00:56, Yafang Shao wrote:
>
> There is a BUILD_BUG_ON() inside get_task_comm(), so when you use
> get_task_comm(), it implies that the BUILD_BUG_ON() is necessary.
Let's just remove that silly BUILD_BUG_ON(). I don't think it adds any
value, and honestly, it really only make
On Wed, 19 Jun 2024 at 03:44, Pavel Machek wrote:
>
> Ok, so machine is ready to be thrown out of window, again. Trying to
> play 29C3 video should not make machine completely unusable ... as in
> keyboard looses keystrokes in terminal.
Well, that at least sounds like you can bisect it with a ver
On Fri, 14 Jun 2024 at 09:21, Linus Torvalds
wrote:
>
> Let's bring in the actual gpu people.. Dave/Jani/others - does any of
> this sound familiar? Pavel says things have gotten much slower in
> 6.10: "something was very wrong with the performance, likely to do
> with g
On Fri, 14 Jun 2024 at 02:02, Pavel Machek wrote:
>
> If I can get at least basic metric on the gpu (%idle? which process
> use how much time?), it might be feasible. Is there tool similar for
> top?
Let's bring in the actual gpu people.. Dave/Jani/others - does any of
this sound familiar? Pavel
On Thu, 13 Jun 2024 at 14:14, Andrew Morton wrote:
>
> The concept sounds a little strange. If some code takes a copy of a
> string while some other code is altering it, yes, the result will be a
> mess. This is why get_task_comm() exists, and why it uses locking.
The thing is, get_task_comm()
On Tue, 4 Jun 2024 at 11:25, Rodrigo Vivi wrote:
>
> (I believe that the new _match_string(str1, size, str2) deserves a better
> name,
> but since I'm bad with naming stuff, I don't have any good suggestion)
I hated the enormous cc list, so I didn't reply to all. But clearly
everybody else is ju
On Fri, 17 May 2024 at 06:55, Alex Deucher wrote:
>
> Can you try this patch?
> https://patchwork.freedesktop.org/patch/594539/
Ack. This seems to fix it for me - unless the problem is random and
only happens sometimes, and I've just been *very* unlucky until now.
Linus
On Thu, 16 May 2024 at 18:08, Dave Airlie wrote:
>
> Linus, do you see it a boot straight away?
Ok, back at that computer now, and yes, I see those messages right
away. In fact, they seem to happen before gnome even starts up, ie I
see those messages long before the first messages from gnome-sess
On Wed, 15 May 2024 at 19:54, Dave Airlie wrote:
>
> Here is the buddy allocator fix I picked up from the list, please apply.
So I removed my reverts, and am running a kernel that includes the
merge 972a2543e3dd ("Merge tag 'drm-next-2024-05-16' of
https://gitlab.freedesktop.org/drm/kernel";) but
On Wed, 15 May 2024 at 16:51, Dave Airlie wrote:
>
> > Let's see if the machine ends up being stable now. It took several
> > hours for the "scary messages" state to turn into the "hung machine"
> > state, so they *could* have been independent issues, but it seems a
> > bit unlikely.
>
> This worr
On Wed, 15 May 2024 at 16:17, Dave Airlie wrote:
>
> It's also possible it's just that hey there's a few others in the tree
>
> KVM_WERROR not tied to it
> PPC_WERROR (why does CXL uses this?)
Yeah, that should be fixed too, but at least KVM_WERROR predates the
whole-kernel WERROR.
And PPC_WERRO
On Wed, 15 May 2024 at 15:45, Dave Airlie wrote:
>
> The drm subsystem enables more warnings than the kernel default, so
> this config option is disabled by default.
Irrelevant.
If the *main* CONFIG_WERROR is on, then it does NOT MATTER if somebody
sets CONFIG_DRM_WERROR or n
On Tue, 14 May 2024 at 23:21, Dave Airlie wrote:
>
> This is the main pull request for the drm subsystems for 6.10.
.. and now that I look more at this pull request, I find other things wrong.
Why is the DRM code asking if I want to enable -Werror? I have Werror
enabled *already*.
I hate stupid
On Wed, 15 May 2024 at 13:24, Linus Torvalds
wrote:
>
> I have to revert both
>
> a68c7eaa7a8f ("drm/amdgpu: Enable clear page functionality")
> e362b7c8f8c7 ("drm/amdgpu: Modify the contiguous flags behaviour")
>
> to make things build cleanly.
On Wed, 15 May 2024 at 13:21, Linus Torvalds
wrote:
>
> I guess I'll try to revert the later commit that enables it for amdgpu
> (commit a68c7eaa7a8f) and see if it at least makes the horrendous
> messages go away.
I have to revert both
a68c7eaa7a8f ("drm/amd
On Wed, 15 May 2024 at 13:06, Linus Torvalds
wrote:
>
> Hmm. There's something seriously wrong with amdgpu.
>
> I'm getting a ton of__force_merge warnings:
>
> WARNING: CPU: 0 PID: 1069 at drivers/gpu/drm/drm_buddy.c:199
> __force_merge+0x14f/0x180 [drm_buddy]
On Tue, 14 May 2024 at 23:21, Dave Airlie wrote:
>
> In drivers the main thing is a new driver for ARM Mali firmware based
> GPUs, otherwise there are a lot of changes to amdgpu/xe/i915/msm and
> scattered changes to everything else.
Hmm. There's something seriously wrong with amdgpu.
I'm gettin
On Thu, 9 May 2024 at 04:39, Christian Brauner wrote:
>
> Not worth it without someone explaining in detail why imho. First pass
> should be to try and replace kcmp() in scenarios where it's obviously
> not needed or overkill.
Ack.
> I've added a CLASS(fd_raw) in a preliminary patch since we'll
On Wed, 8 May 2024 at 09:19, Linus Torvalds
wrote:
>
> So since we already have two versions of F_DUPFD (the other being
> F_DUPFD_CLOEXEC) I decided that the best thing to do is to just extend
> on that existing naming pattern, and called it F_DUPFD_QUERY instead.
>
> I'm
On Tue, 7 May 2024 at 12:07, Linus Torvalds
wrote:
>
> That example thing shows that we shouldn't make it a FISAME ioctl - we
> should make it a fcntl() instead, and it would just be a companion to
> F_DUPFD.
>
> Doesn't that strike everybody as a *much* cleaner interf
On Tue, 7 May 2024 at 11:04, Daniel Vetter wrote:
>
> On Tue, May 07, 2024 at 09:46:31AM -0700, Linus Torvalds wrote:
>
> > I'd be perfectly ok with adding a generic "FISAME" VFS level ioctl
> > too, if this is possibly a more common thing. and not just DRM w
On Tue, 7 May 2024 at 04:03, Daniel Vetter wrote:
>
> It's really annoying that on some distros/builds we don't have that, and
> for gpu driver stack reasons we _really_ need to know whether a fd is the
> same as another, due to some messy uniqueness requirements on buffer
> objects various driver
On Mon, 6 May 2024 at 10:46, Stefan Metzmacher wrote:
>
> I think it's a very important detail that epoll does not take
> real references. Otherwise an application level 'close()' on a socket
> would not trigger a tcp disconnect, when an fd is still registered with
> epoll.
Yes, exactly.
epoll()
On Sun, 5 May 2024 at 13:30, Al Viro wrote:
>
> 0. special-cased ->f_count rule for ->poll() is a wart and it's
> better to get rid of it.
>
> 1. fs/eventpoll.c is a steaming pile of shit and I'd be glad to see
> git rm taken to it. Short of that, by all means, let's grab reference
> in
On Sun, 5 May 2024 at 13:02, David Laight wrote:
>
> How much is the extra pair of atomics going to hurt performance?
> IIRC a lot of work was done to (try to) make epoll lockless.
If this makes people walk away from epoll, that would be absolutely
*lovely*. Maybe they'd start using io_uring inst
On Sun, 5 May 2024 at 12:46, Al Viro wrote:
>
> I've no problem with having epoll grab a reference, but if we make that
> a universal requirement ->poll() instances can rely upon,
Al, we're note "making that a requirement".
It always has been.
Otgherwise, the docs should have shouted out DAMN L
1 - 100 of 812 matches
Mail list logo
