Re: [pull] amdgpu drm-fixes-6.4

On Fri, 23 Jun 2023 at 14:18, Alex Deucher wrote: > > are available in the Git repository at: > > https://gitlab.freedesktop.org/agd5f/linux.git > tags/amd-drm-fixes-6.4-2023-06-23 That's not a valid signed tag. Yes, it's a tag. But it doesn't actually have any cryptographic signing, and

Re: [Intel-gfx] [BUG 6.3-rc1] Bad lock in ttm_bo_delayed_delete()

On Wed, Mar 15, 2023 at 5:22 PM Steven Rostedt wrote: > > I hope that this gets in by -rc3, as I want to start basing my next branch > on that tag. My tree should have it now as commit c00133a9e87e ("drm/ttm: drop extra ttm_bo_put in ttm_bo_cleanup_refs"). Linus

Fwd: amdgpu: update from 5.10.145 to 5.10.146...149 breaks boot on Ryzen based computers

This was sent to me, but should have gone to other people. It may already be fixed, but note how the report is about -stable kernels, including apparently the current 5.10 stable version (149(. Linus -- Forwarded message - From: Kevin Torkelson Date: Thu, Oct 20,

Re: [PATCH] drm/amd/display: Fix build breakage with CONFIG_DEBUG_FS=n

On Fri, Oct 14, 2022 at 8:22 AM Nathan Chancellor wrote: > > After commit 8799c0be89eb ("drm/amd/display: Fix vblank refcount in vrr > transition"), a build with CONFIG_DEBUG_FS=n is broken due to a > misplaced brace, along the lines of: Thanks, applied. Linus

Re: mainline build failure due to 5d8c3e836fc2 ("drm/amd/display: fix array-bounds error in dc_stream_remove_writeback()")

On Thu, Oct 6, 2022 at 1:50 PM Sudip Mukherjee wrote: > > > And it looks like Sudip's proposed fix for this particular code is > > additionally fixing unsigned vs signed as well. I think -Warray-bounds > > did its job (though, with quite a confusing index range in the report). > > Not my.

Re: mainline build failure due to 5d8c3e836fc2 ("drm/amd/display: fix array-bounds error in dc_stream_remove_writeback()")

On Thu, Oct 6, 2022 at 1:51 AM Sudip Mukherjee (Codethink) wrote: > > This is only seen with gcc-11, gcc-12 builds are ok. Hmm. This seems to be some odd gcc issue. I *think* that what is going on is that the test j = 0 ; j < MAX_DWB_PIPES makes gcc decide that "hey, j is in the range

Re: Linux 6.0-rc5

On Mon, Sep 12, 2022 at 7:59 AM Sudip Mukherjee wrote: > > clang build failure as reported in [1] is still there. Nathan has > posted a patch series at [2] to fix it, but it has not landed yet.Alex > Deucher > > [1]. https://lore.kernel.org/lkml/YuwRyQYPCb1FD+mr@debian/#t > [2].

Re: mainline build failure for x86_64 allmodconfig with clang

On Sun, Aug 7, 2022 at 10:36 AM David Laight wrote: > > Or just shoot the software engineer who thinks 100 arguments > is sane. :-) I suspect the issue is that it's not primarily a software engineer who wrote that code. Hardware people writing code are about as scary as software engineers with

Re: mainline build failure for x86_64 allmodconfig with clang

On Thu, Aug 4, 2022 at 11:37 AM Sudip Mukherjee (Codethink) wrote: > > git bisect points to 3876a8b5e241 ("drm/amd/display: Enable building new > display engine with KCOV enabled"). Ahh. So that was presumably why it was disabled before - because it presumably does disgusting things that make

Re: mainline build failure for x86_64 allmodconfig with clang

On Thu, Aug 4, 2022 at 1:43 PM Nathan Chancellor wrote: > > I do note that commit 1b54a0121dba ("drm/amd/display: Reduce stack size > in the mode support function") did have a workaround for GCC. It appears > clang will still inline mode_support_configuration(). If I mark it as > 'noinline', the

Re: mainline build failure due to 6fdd2077ec03 ("drm/amd/amdgpu: add memory training support for PSP_V13")

On Thu, Aug 4, 2022 at 12:35 AM Sudip Mukherjee (Codethink) wrote: > > I will be happy to test any patch or provide any extra log if needed. It sounds like that file just needs to get a #include there, and for some reason architectures other than alpha and mips end up getting it

Re: [PATCH] drm/amdgpu: Re-enable DCN for 64-bit powerpc

On Mon, Jul 25, 2022 at 5:39 AM Michael Ellerman wrote: > > Further digging shows that the build failures only occur with compilers > that default to 64-bit long double. Where the heck do we have 'long double' things anywhere in the kernel? I tried to grep for it, and failed miserably. I found

Re: Linux 5.19-rc6

On Thu, Jul 14, 2022 at 10:24 AM Guenter Roeck wrote: > > We can't use virt_to_phys() and phys_to_virt() because they are defined for > the underlying architecture. Would uml_to_phys() and uml_to_virt() be > acceptable ? If so, I'll submit a patch. Sure, that would be good, and make th uml

Re: Linux 5.19-rc6

On Thu, Jul 14, 2022 at 12:23 AM Geert Uytterhoeven wrote: > > Oh, it's not just this one. The lists of build regressions between v5.18 > and v5.19-rc1 [1] resp. v5.19-rc6 [2] look surprisingly similar :-( > > [1] https://lore.kernel.org/all/20220606082201.2792145-1-ge...@linux-m68k.org > [2]

Re: Linux 5.19-rc6

On Wed, Jul 13, 2022 at 2:36 PM Sudip Mukherjee wrote: > > > > > > > https://lore.kernel.org/all/20220524025139.40212-1-wangkefeng.w...@huawei.com/ > > > > That patch looks sane to me, but I guess Guenter would need to check > > I still see the failure in my builds with this patch. But

Re: Linux 5.19-rc6

On Wed, Jul 13, 2022 at 2:01 PM Alex Deucher wrote: > > If you want to apply Guenter's patch original patch: > https://patchwork.freedesktop.org/patch/490184/ > That's fine with me. Honestly, by this time I feel that it's too little, too late. The ppc people apparently didn't care at all about

Re: Linux 5.19-rc6

On Wed, Jul 13, 2022 at 1:46 PM Guenter Roeck wrote: > > It does, but I can't imagine that the drm or ppc people would be happy > about it. When something has been reported as not building for five weeks? I have zero f's to give at that point about their "happiness". Linus

Re: Linux 5.19-rc6

On Wed, Jul 13, 2022 at 1:40 PM Guenter Roeck wrote: > > That patch is (and has been) in linux-next for a long time, > as commit d2ca1fd2bc70, and with the following tags. > > Fixes: 7719a68b2fa4 ("ARM: 9192/1: amba: fix memory leak in > amba_device_try_add()") > Reported-by: Guenter

Re: Linux 5.19-rc6

On Wed, Jul 13, 2022 at 12:53 PM Alex Deucher wrote: > > Does this patch fix it? > https://patchwork.freedesktop.org/patch/493799/ Guenter? Willing to check this one too for your setup, and we can hopefully close down both issues? Linus

Re: Linux 5.19-rc6

On Wed, Jul 13, 2022 at 12:49 PM Russell King (Oracle) wrote: > > There may be a patch that solves that, but it's never been submitted to > my patch system: > > https://lore.kernel.org/all/20220524025139.40212-1-wangkefeng.w...@huawei.com/ That patch looks sane to me, but I guess Guenter would

Re: Linux 5.19-rc6

On Tue, Jul 12, 2022 at 10:07 PM Guenter Roeck wrote: > > Same problems as every week. > > Building powerpc:allmodconfig ... failed Ok, this has been going on since -rc1, which is much too long. >From your patch submission that that was rejected: > The problem was introduced with commit

Re: Annoying AMDGPU boot-time warning due to simplefb / amdgpu resource clash

On Mon, Jun 27, 2022 at 1:02 AM Javier Martinez Canillas wrote: > > The flag was dropped because it was causing drivers that requested their > memory resource with pci_request_region() to fail with -EBUSY (e.g: the > vmwgfx driver): > > https://www.spinics.net/lists/dri-devel/msg329672.html See,

Annoying AMDGPU boot-time warning due to simplefb / amdgpu resource clash

So this has been going on for a while, and it's quite annoying. At bootup, my main desktop (Threadripper 3970X with radeon graphics) now complains about resource sanity check: requesting [mem 0xd000-0xdfff], which spans more than BOOTFB [mem 0xd000-0xd02f] and then gives me a

Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Wed, Mar 2, 2022 at 12:07 PM Kees Cook wrote: > > I've long wanted to change kfree() to explicitly set pointers to NULL on > free. https://github.com/KSPP/linux/issues/87 We've had this discussion with the gcc people in the past, and gcc actually has some support for it, but it's sadly tied

Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Tue, Mar 1, 2022 at 3:19 PM David Laight wrote: > > Having said that there are so few users of list_entry_is_head() > it is reasonable to generate two new names. Well, the problem is that the users of list_entry_is_head() may be few - but there are a number of _other_ ways to check "was that

Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Tue, Mar 1, 2022 at 2:58 PM David Laight wrote: > > Can it be resolved by making: > #define list_entry_is_head(pos, head, member) ((pos) == NULL) > and double-checking that it isn't used anywhere else (except in > the list macros themselves). Well, yes, except for the fact that then the name

Re: [PATCH 6/6] treewide: remove check of list iterator against head past the loop body

So looking at this patch, I really reacted to the fact that quite often the "use outside the loop" case is all kinds of just plain unnecessary, but _used_ to be a convenience feature. I'll just quote the first chunk in it's entirely as an example - not because I think this chunk is particularly

Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Tue, Mar 1, 2022 at 11:06 AM Linus Torvalds wrote: > > So instead of that simple "if (!entry)", we'd effectively have to > continue to use something that still works with the old world order > (ie that "if (list_entry_is_head())" model). Just to prove my

Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Tue, Mar 1, 2022 at 10:14 AM Kees Cook wrote: > > The first big glitch with -Wshadow was with shadowed global variables. > GCC 4.8 fixed that, but it still yells about shadowed functions. What > _almost_ works is -Wshadow=local. Heh. Yeah, I just have long memories of "-Wshadow was a

Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Mon, Feb 28, 2022 at 2:29 PM James Bottomley wrote: > > However, if the desire is really to poison the loop variable then we > can do > > #define list_for_each_entry(pos, head, member) \ > for (pos = list_first_entry(head, typeof(*pos), member);\ >

Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Mon, Feb 28, 2022 at 4:38 PM Segher Boessenkool wrote: > > In C its scope is the rest of the declaration and the entire loop, not > anything after it. This was the same in C++98 already, btw (but in > pre-standard versions of C++ things were like you remember, yes, and it > was painful).

Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Mon, Feb 28, 2022 at 3:26 PM Matthew Wilcox wrote: > > #define ___PASTE(a, b) a##b > #define __PASTE(a, b) ___PASTE(a, b) > #define _min(a, b, u) ({ \ Yeah, except that's ugly beyond belief, plus it's literally not what we do in the kernel. Really. The "-Wshadow doesn't work on the

Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Mon, Feb 28, 2022 at 1:47 PM Jakob Koschel wrote: > > The goal of this is to get compiler warnings right? This would indeed be > great. Yes, so I don't mind having a one-time patch that has been gathered using some automated checker tool, but I don't think that works from a long-term

Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Mon, Feb 28, 2022 at 4:45 PM Linus Torvalds wrote: > > Yeah, except that's ugly beyond belief, plus it's literally not what > we do in the kernel. (Of course, I probably shouldn't have used 'min()' as an example, because that is actually one of the few places where we do exactly th

Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Mon, Feb 28, 2022 at 12:29 PM Johannes Berg wrote: > > If we're willing to change the API for the macro, we could do > > list_for_each_entry(type, pos, head, member) > > and then actually take advantage of -Wshadow? See my reply to Willy. There is no way -Wshadow will ever happen. I

Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Mon, Feb 28, 2022 at 12:16 PM Matthew Wilcox wrote: > > Then we can never use -Wshadow ;-( I'd love to be able to turn it on; > it catches real bugs. Oh, we already can never use -Wshadow regardless of things like this. That bridge hasn't just been burned, it never existed in the first

Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Mon, Feb 28, 2022 at 12:10 PM Linus Torvalds wrote: > > We can do > > typeof(pos) pos > > in the 'for ()' loop, and never use __iter at all. > > That means that inside the for-loop, we use a _different_ 'pos' than outside. The thing that makes me th

Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Mon, Feb 28, 2022 at 11:56 AM Linus Torvalds wrote: > > I do wish we could actually poison the 'pos' value after the loop > somehow - but clearly the "might be uninitialized" I was hoping for > isn't the way to do it. Side note: we do need *some* way to do it. Because

Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Mon, Feb 28, 2022 at 12:03 PM Linus Torvalds wrote: > > Side note: we do need *some* way to do it. Ooh. This patch is a work of art. And I mean that in the worst possible way. We can do typeof(pos) pos in the 'for ()' loop, and never use __iter at all. That means that

Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Mon, Feb 28, 2022 at 4:19 AM Christian König wrote: > > I don't think that using the extra variable makes the code in any way > more reliable or easier to read. So I think the next step is to do the attached patch (which requires that "-std=gnu11" that was discussed in the original thread).

Re: [git pull] drm for 5.17-rc1 (pre-merge window pull)

On Tue, Jan 11, 2022 at 7:38 AM Harry Wentland wrote: > > Attached is a v2 of the buggy patch that should get this right. > If you have a chance to try it out let us know I can confirm that I do not see the horribly flickering behavior with this patch. I didn't look at what the actual

Re: [git pull] drm for 5.17-rc1 (pre-merge window pull)

On Mon, Jan 10, 2022 at 6:22 PM Linus Torvalds wrote: > > and I guess I'll do the few more bisections to pick out the exact one. a896f870f8a5f23ec961d16baffd3fda1f8be57c is the first bad commit. Attaching ther BISECT_LOG in case anybody cares. I'll double-check to see if a revert

Re: [git pull] drm for 5.17-rc1 (pre-merge window pull)

On Mon, Jan 10, 2022 at 5:21 PM Linus Torvalds wrote: > > I'll see if I can bisect it at least partially. It seems to be very reliable. I can see the flickering even at early boot before gdb has started - the graphical screen where you type the encrypted disk password at boot already

Re: [git pull] drm for 5.17-rc1 (pre-merge window pull)

On Mon, Jan 10, 2022 at 6:44 PM Linus Torvalds wrote: > > I'll double-check to see if a revert fixes it at the top of my tree. Yup. It reverts cleanly, and the end result builds and works fine, and doesn't show the horrendous flickering. I have done that revert, and will continue the

Re: [git pull] drm for 5.17-rc1 (pre-merge window pull)

On Mon, Jan 10, 2022 at 5:21 PM Linus Torvalds wrote: > > It also seems to depend a bit on the screen contents - or possibly on > what else is going on. Hiding the browser window makes it happen less, > I think. But I suspect that's about "less gpu activity" than anyt

Re: [git pull] drm for 5.17-rc1 (pre-merge window pull)

On Mon, Jan 10, 2022 at 5:11 PM Alex Deucher wrote: > > We are putting together a system to try and repro the issue. Does it > happen with a single monitor or only with two? Nope. With a single monitor everything seems to look fine. And when I plug in the second monitor, it immediately starts

Re: [git pull] drm for 5.17-rc1 (pre-merge window pull)

On Mon, Jan 10, 2022 at 2:13 PM Alex Deucher wrote: > > Sounds like something related to watermarks. That said, we haven't > really touched the display code for DCE11 cards in quite a while. Can > you provide your dmesg output? I'm not seeing anything that would look interesting, but here's

Re: Expecting to revert commit 55285e21f045 "fbdev/efifb: Release PCI device ..."

ut it is then broken on amdgpu. Absolutely nothing odd in my setup. Two monitors, one GPU. PCI ID 1002:67df rev e7, subsystem ID 1da2:e353. I'd expect pretty much any amdgpu person to see this. On Mon, Dec 20, 2021 at 2:04 PM Linus Torvalds wrote: > > Note: on my machine, I get that > >

Re: [PATCH] Enable '-Werror' by default for all kernel builds

On Wed, Sep 8, 2021 at 10:59 PM Christoph Hellwig wrote: > > While we're at it, with -Werror something like this is really futile: Yeah, I'm thinking we could do -Wno-error=cpp to at least allow the cpp warnings to come through without being fatal. Because while they can be annoying too,

Re: [PATCH] Enable '-Werror' by default for all kernel builds

On Thu, Sep 9, 2021 at 4:43 AM Marco Elver wrote: > > Sure, but the reality is that the real stack size is already doubled > for KASAN. And that should be reflected in Wframe-larger-than. I don't think that's true. Quite the reverse, in fact. Yes, the *dynamic* stack size is doubled due to

Re: [PATCH] Enable '-Werror' by default for all kernel builds

On Tue, Sep 7, 2021 at 10:10 AM Linus Torvalds wrote: > > Do I know why? No. I do note that that code is disgusting. > > It's passing one of those structs around by value, for example. That's > a 72-byte structure that is copied on the stack due to stupid calling > conven

Re: [PATCH] Enable '-Werror' by default for all kernel builds

On Tue, Sep 7, 2021 at 8:52 PM Harry Wentland wrote: > > Attached patches fix these x86_64 ones reported by Nick: Hmm. You didn't seem to fix up the calling convention for print__xyz(), which still take those xyz structs as pass-by-value. Obviously it would be good to do things incrementally,

Re: [git pull] drm fixes for 5.14-rc4

This might possibly have been fixed already by the previous drm pull, but I wanted to report it anyway, just in case. It happened after an uptime of over a week, so it might not be trivial to reproduce. It's a NULL pointer dereference in dc_stream_retain() with the code being lock xadd

Re: [PATCH v3 3/3] drm/amdgpu: Change type of module param `ppfeaturemask` to hexint

On Fri, Jul 24, 2020 at 12:54 AM Christian König wrote: > > But since you already addressed Linus comments and it looks rather clean > I think I can just push it to drm-misc-next on Monday if nobody objects > over the weekend. Yeah, no objections from me. Add a note to it to the pull request,

Re: [PATCH 1/2] moduleparams: Add hex type parameter

On Thu, Jul 2, 2020 at 7:42 AM Christian König wrote: > > I'm just not sure how well this is received upstream because it only > covers u32 > > On the other hand that is probably also the most used. Not necessarily true. I'd argue that "unsigned long" is equally possible for some bit mask (or

Re: [GIT PULL] Please pull hmm changes

On Wed, Dec 18, 2019 at 10:37 AM Jason Gunthorpe wrote: > > I think this is what you are looking for? I think that with these names, I would have had an easier time reading the original patch that made me go "Eww", yes. Of course, now that it's just a rename patch, it's not like the patch is

Re: [GIT PULL] Please pull hmm changes

On Wed, Dec 18, 2019 at 6:59 AM Jason Gunthorpe wrote: > > Do you think calling it 'mmn_subscriptions' is clear? Why do you want that "mmn"? Guys, the "mmn" part is clear from the _context_. The function name is When the function name is something like "mmu_interval_read_begin()", and the

Re: [GIT PULL] Please pull hmm changes

On Sat, Nov 30, 2019 at 10:03 AM Linus Torvalds wrote: > > I'll try to figure the code out, but my initial reaction was "yeah, > not in my VM". Why is it ok to sometimes do WRITE_ONCE(mni->invalidate_seq, cur_seq); (to pair with the unlocked READ_ONCE), and some

Re: [GIT PULL] Please pull hmm changes

On Mon, Nov 25, 2019 at 12:42 PM Jason Gunthorpe wrote: > > Here is this batch of hmm updates, I think we are nearing the end of this > project for now, although I suspect there will be some more patches related to > hmm_range_fault() in the next cycle. I've ended up pulling this, but I'm not

Re: [GIT PULL] Please pull hmm changes

On Mon, Nov 25, 2019 at 12:42 PM Jason Gunthorpe wrote: > > You will probably be most interested in the patch "mm/mmu_notifier: add an > interval tree notifier". I'm trying to read that patch, and I'm completely unable to by the absolutely *horrid* variable names. There are zero excuses for

Re: [GIT PULL] Please pull hmm changes

On Tue, Jul 9, 2019 at 12:24 PM Jason Gunthorpe wrote: > > I'm sending it early as it is now a dependency for several patches in > mm's quilt. .. but I waited to merge it until I had time to review it more closely, because I expected the review to be painful. I'm happy to say that I was overly

Re: Possible use_mm() mis-uses

On Wed, Aug 22, 2018 at 11:16 PM Zhenyu Wang wrote: > > yeah, that's the clear way to fix this imo. We only depend on guest > life cycle to access guest memory properly. Here's proposed fix, will > verify and integrate it later. Thanks, this looks sane to me, Linus

Re: Possible use_mm() mis-uses

On Wed, Aug 22, 2018 at 12:44 PM Felix Kuehling wrote: > > You're right, but that's a bit fragile and convoluted. I'll fix KFD to > handle this more robustly. See the attached (untested) patch. Yes, this patch that makes the whole "has to use current mm" or uses "get_task_mm()" looks good from a

Re: Possible use_mm() mis-uses

On Wed, Aug 22, 2018 at 12:37 PM Oded Gabbay wrote: > > Having said that, I think we *are* protected by the mmu_notifier > release because if the process suddenly dies, we will gracefully clean > the process's data in our driver and on the H/W before returning to > the mm core code. And before we

Possible use_mm() mis-uses

Guys and gals, this is a *very* random list of people on the recipients list, but we had a subtle TLB shootdown issue in the VM, and that brought up some issues when people then went through the code more carefully. I think we have a handle on the TLB shootdown bug itself. But when people were

Re: Possible use_mm() mis-uses

On Wed, Aug 22, 2018 at 11:33 AM Linus Torvalds wrote: > > On Wed, Aug 22, 2018 at 11:21 AM Paolo Bonzini wrote: > > > > Yes, KVM is correct but the i915 bits are at least fishy. It's probably > > as simple as adding a mmget/mmput pair respectively in kvmgt_guest_init

Re: Possible use_mm() mis-uses

On Wed, Aug 22, 2018 at 11:21 AM Paolo Bonzini wrote: > > Yes, KVM is correct but the i915 bits are at least fishy. It's probably > as simple as adding a mmget/mmput pair respectively in kvmgt_guest_init > and kvmgt_guest_exit, or maybe mmget_not_zero. Definitely mmget_not_zero(). If it was

Re: [PATCH 00/13] mmu_notifier kill invalidate_page callback

On Tue, Aug 29, 2017 at 4:54 PM, Jérôme Glisse wrote: > > Note this is barely tested. I intend to do more testing of next few days > but i do not have access to all hardware that make use of the mmu_notifier > API. Thanks for doing this. > First 2 patches convert existing