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 Wed, 26 Mar 2025 at 15:00, Bert Karwatzki wrote:
>
> As Balbir Singh found out this memory comes from amdkfd
> (kgd2kfd_init_zone_device()) with CONFIG_HSA_AMD_SVM=y. The memory gets placed
> by devm_request_free_mem_region() which places the memory at the end of the
> physical address space (D
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 I'm
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
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, 2
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
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. Linus's.
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
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]. https://lore.ker
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 a
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 KC
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 w
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 accidental
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 s
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 helper
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] http
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 surprisingl
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 t
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
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 Ro
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
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 ne
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 41b7a34
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,
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 n
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 to
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 t
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 i
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 im
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
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 disaster"
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);\
>
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).
Yeah
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 k
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 maintena
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 plac
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 conside
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
place.
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 ma
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 d
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
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).
T
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 difference
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 re
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
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 co
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
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 ha
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 the
rk, but 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
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, they
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 KASA
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
&
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, s
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 %
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, so
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 ot
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 all
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 filen
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
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 ent
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 name
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 p
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
__
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
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
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 di
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_
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 just
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 call of mmu_notifier_in
71 matches
Mail list logo
