AMD drm patch workflow is broken for stable trees

Hi all,

As some of you have noticed, there's a TON of failure messages being sent out for AMD gpu driver commits that are tagged for stable backports. In short, you all are doing something really wrong with how you are tagging these.

Please fix it up to NOT have duplicates in multiple branches that end up in Linus's tree at different times. Or if you MUST do that, then give us a chance to figure out that it IS a duplicate. As-is, it's not working at all, and I think I need to just drop all patches for this driver that are tagged for stable going forward and rely on you all to provide a proper set of backported fixes when you say they are needed.

Again, what you are doing today is NOT ok and is broken. Please fix.

greg k-h

Quoted 6 lines · Greg KH

Hi all,

As some of you have noticed, there's a TON of failure messages being sent out for AMD gpu driver commits that are tagged for stable backports. In short, you all are doing something really wrong with how you are tagging these.

Hi Greg,

I got notifications about one KFD patch failing to apply on six branches (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you already applied this patch on two branches back in May. The emails had a suspicious looking date in the header (Sep 17, 2001). I wonder if there was some date glitch that caused a whole bunch of patches to be re-sent to stable somehow:

    ------------------ original commit in Linus's tree
    ------------------ From 24e82654e98e96cece5d8b919c522054456eeec6 Mon
    Sep 17 00:00:00 2001 From: Alex Deucher
    <[email protected]>Date: Sun, 14 Apr 2024 13:06:39 -0400
    Subject: [PATCH] drm/amdkfd: don't allow mapping the MMIO HDP page
    with large pages ...

On 6.1 and 6.6, the patch was already applied by you in May:

    $ git log --pretty=fuller stable/linux-6.6.y --grep "drm/amdkfd: don't allow mapping the MMIO HDP page with large pages"
    commit 4b4cff994a27ebf7bd3fb9a798a1cdfa8d01b724
    Author:     Alex Deucher <[email protected]>
    AuthorDate: Sun Apr 14 13:06:39 2024 -0400
    Commit:     Greg Kroah-Hartman <[email protected]>
    CommitDate: Fri May 17 12:02:34 2024 +0200

drm/amdkfd: don't allow mapping the MMIO HDP page with large pages
...

On 6.10 it was already upstream.

On 5.4-5.15 it doesn't apply because of conflicts. I can resolve those and send the fixed patches out for you.

Regards,
Felix

Quoted 11 lines

Please fix it up to NOT have duplicates in multiple branches that end up in Linus's tree at different times. Or if you MUST do that, then give us a chance to figure out that it IS a duplicate. As-is, it's not working at all, and I think I need to just drop all patches for this driver that are tagged for stable going forward and rely on you all to provide a proper set of backported fixes when you say they are needed.

Again, what you are doing today is NOT ok and is broken. Please fix.

greg k-h

Quoted 8 lines · Felix Kuehling

Quoted 6 lines · Greg KH

Hi all,

As some of you have noticed, there's a TON of failure messages being sent out for AMD gpu driver commits that are tagged for stable backports. In short, you all are doing something really wrong with how you are tagging these.

Quoted 8 lines

Hi Greg,

I got notifications about one KFD patch failing to apply on six branches (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you already applied this patch on two branches back in May. The emails had a suspicious looking date in the header (Sep 17, 2001). I wonder if there was some date glitch that caused a whole bunch of patches to be re-sent to stable somehow:

I think the crux of the problem is that sometimes patches go into -next with stable tags and they end getting taken into -fixes as well so after the merge window they end up getting picked up for stable again. Going forward, if they land in -next, I'll cherry-pick -x the changes into -fixes so there is better traceability.

Quoted 18 lines · Alex Deucher

Quoted 8 lines · Felix Kuehling

Quoted 6 lines · Greg KH

Hi all,

As some of you have noticed, there's a TON of failure messages being sent out for AMD gpu driver commits that are tagged for stable backports. In short, you all are doing something really wrong with how you are tagging these.

Quoted 8 lines

Hi Greg,

I got notifications about one KFD patch failing to apply on six branches (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you already applied this patch on two branches back in May. The emails had a suspicious looking date in the header (Sep 17, 2001). I wonder if there was some date glitch that caused a whole bunch of patches to be re-sent to stable somehow:

Quoted 5 lines

I think the crux of the problem is that sometimes patches go into -next with stable tags and they end getting taken into -fixes as well so after the merge window they end up getting picked up for stable again. Going forward, if they land in -next, I'll cherry-pick -x the changes into -fixes so there is better traceability.

Please do so, and also work to not have duplicate commits like this in different branches. Git can handle merges quite well, please use it.

If this shows up again in the next -rc1 merge window without any changes, I'll have to just blackhole all amd drm patches going forward until you all tell me you have fixed your development process.

thanks,

greg k-h

Quoted 29 lines · Greg KH

Quoted 18 lines · Alex Deucher

Quoted 8 lines · Felix Kuehling

Quoted 6 lines · Greg KH

Hi all,

As some of you have noticed, there's a TON of failure messages being sent out for AMD gpu driver commits that are tagged for stable backports. In short, you all are doing something really wrong with how you are tagging these.

Quoted 8 lines

Hi Greg,

I got notifications about one KFD patch failing to apply on six branches (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you already applied this patch on two branches back in May. The emails had a suspicious looking date in the header (Sep 17, 2001). I wonder if there was some date glitch that caused a whole bunch of patches to be re-sent to stable somehow:

Quoted 5 lines

I think the crux of the problem is that sometimes patches go into -next with stable tags and they end getting taken into -fixes as well so after the merge window they end up getting picked up for stable again. Going forward, if they land in -next, I'll cherry-pick -x the changes into -fixes so there is better traceability.

Please do so, and also work to not have duplicate commits like this in different branches. Git can handle merges quite well, please use it.

Quoted 3 lines

If this shows up again in the next -rc1 merge window without any changes, I'll have to just blackhole all amd drm patches going forward until you all tell me you have fixed your development process.

Just a heads up, you will see some of these when the 6.12 merge window due to what is currently in -next and the fixes that went into 6.11, but going forward we have updated our process and it should be better.

Quoted 34 lines · Alex Deucher

Quoted 32 lines · Greg KH

Quoted 18 lines · Alex Deucher

Quoted 8 lines · Felix Kuehling

Quoted 6 lines · Greg KH

Hi all,

As some of you have noticed, there's a TON of failure messages being sent out for AMD gpu driver commits that are tagged for stable backports. In short, you all are doing something really wrong with how you are tagging these.

Quoted 8 lines

Hi Greg,

I got notifications about one KFD patch failing to apply on six branches (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you already applied this patch on two branches back in May. The emails had a suspicious looking date in the header (Sep 17, 2001). I wonder if there was some date glitch that caused a whole bunch of patches to be re-sent to stable somehow:

Quoted 5 lines

I think the crux of the problem is that sometimes patches go into -next with stable tags and they end getting taken into -fixes as well so after the merge window they end up getting picked up for stable again. Going forward, if they land in -next, I'll cherry-pick -x the changes into -fixes so there is better traceability.

Please do so, and also work to not have duplicate commits like this in different branches. Git can handle merges quite well, please use it.

If this shows up again in the next -rc1 merge window without any changes, I'll have to just blackhole all amd drm patches going forward until you all tell me you have fixed your development process.

Quoted 3 lines

Just a heads up, you will see some of these when the 6.12 merge window due to what is currently in -next and the fixes that went into 6.11, but going forward we have updated our process and it should be better.

Can you give me a list of the git ids that I should be ignoring for 6.12-rc1? Otherwise again, it's a huge waste of time on my side trying to sift through them and figure out if the rejection is real or not...

thanks,

greg k-h

Quoted 36 lines · Greg KH

Quoted 34 lines · Alex Deucher

Quoted 32 lines · Greg KH

Quoted 18 lines · Alex Deucher

Quoted 8 lines · Felix Kuehling

Quoted 6 lines · Greg KH

Hi all,

As some of you have noticed, there's a TON of failure messages being sent out for AMD gpu driver commits that are tagged for stable backports. In short, you all are doing something really wrong with how you are tagging these.

Quoted 8 lines

Hi Greg,

I got notifications about one KFD patch failing to apply on six branches (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you already applied this patch on two branches back in May. The emails had a suspicious looking date in the header (Sep 17, 2001). I wonder if there was some date glitch that caused a whole bunch of patches to be re-sent to stable somehow:

Quoted 5 lines

I think the crux of the problem is that sometimes patches go into -next with stable tags and they end getting taken into -fixes as well so after the merge window they end up getting picked up for stable again. Going forward, if they land in -next, I'll cherry-pick -x the changes into -fixes so there is better traceability.

Please do so, and also work to not have duplicate commits like this in different branches. Git can handle merges quite well, please use it.

If this shows up again in the next -rc1 merge window without any changes, I'll have to just blackhole all amd drm patches going forward until you all tell me you have fixed your development process.

Quoted 7 lines

Quoted 3 lines

Just a heads up, you will see some of these when the 6.12 merge window due to what is currently in -next and the fixes that went into 6.11, but going forward we have updated our process and it should be better.

Can you give me a list of the git ids that I should be ignoring for 6.12-rc1? Otherwise again, it's a huge waste of time on my side trying to sift through them and figure out if the rejection is real or not...

8151a6c13111 drm/amd/display: Skip Recompute DSC Params if no Stream on Link fbfb5f034225 drm/amdgpu: fix contiguous handling for IB parsing v2 ec0d7abbb0d4 drm/amd/display: Fix Potential Null Dereference 332315885d3c drm/amd/display: Remove ASSERT if significance is zero in math_ceil2
295d91cbc700 drm/amd/display: Check for NULL pointer
6472de66c0aa drm/amd/amdgpu: Fix uninitialized variable warnings 93381e6b6180 drm/amdgpu: fix a possible null pointer dereference 7a38efeee6b5 drm/radeon: fix null pointer dereference in radeon_add_common_modes

Quoted 45 lines · Alex Deucher

Quoted 36 lines · Greg KH

Quoted 34 lines · Alex Deucher

Quoted 32 lines · Greg KH

Quoted 18 lines · Alex Deucher

Quoted 8 lines · Felix Kuehling

Quoted 6 lines · Greg KH

Hi all,

As some of you have noticed, there's a TON of failure messages being sent out for AMD gpu driver commits that are tagged for stable backports. In short, you all are doing something really wrong with how you are tagging these.

Quoted 8 lines

Hi Greg,

I got notifications about one KFD patch failing to apply on six branches (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you already applied this patch on two branches back in May. The emails had a suspicious looking date in the header (Sep 17, 2001). I wonder if there was some date glitch that caused a whole bunch of patches to be re-sent to stable somehow:

Quoted 5 lines

I think the crux of the problem is that sometimes patches go into -next with stable tags and they end getting taken into -fixes as well so after the merge window they end up getting picked up for stable again. Going forward, if they land in -next, I'll cherry-pick -x the changes into -fixes so there is better traceability.

Please do so, and also work to not have duplicate commits like this in different branches. Git can handle merges quite well, please use it.

If this shows up again in the next -rc1 merge window without any changes, I'll have to just blackhole all amd drm patches going forward until you all tell me you have fixed your development process.

Quoted 7 lines

Quoted 3 lines

Just a heads up, you will see some of these when the 6.12 merge window due to what is currently in -next and the fixes that went into 6.11, but going forward we have updated our process and it should be better.

Can you give me a list of the git ids that I should be ignoring for 6.12-rc1? Otherwise again, it's a huge waste of time on my side trying to sift through them and figure out if the rejection is real or not...

Quoted 9 lines

8151a6c13111 drm/amd/display: Skip Recompute DSC Params if no Stream on Link fbfb5f034225 drm/amdgpu: fix contiguous handling for IB parsing v2 ec0d7abbb0d4 drm/amd/display: Fix Potential Null Dereference 332315885d3c drm/amd/display: Remove ASSERT if significance is zero in math_ceil2
295d91cbc700 drm/amd/display: Check for NULL pointer
6472de66c0aa drm/amd/amdgpu: Fix uninitialized variable warnings 93381e6b6180 drm/amdgpu: fix a possible null pointer dereference 7a38efeee6b5 drm/radeon: fix null pointer dereference in radeon_add_common_modes

Please resend this after -rc1 is out, so we don't have to hunt for it again.

thanks,

greg k-h

Resending now that rc1 is out. These should be ignored for stable.

8151a6c13111 drm/amd/display: Skip Recompute DSC Params if no Stream on Link fbfb5f034225 drm/amdgpu: fix contiguous handling for IB parsing v2 ec0d7abbb0d4 drm/amd/display: Fix Potential Null Dereference 332315885d3c drm/amd/display: Remove ASSERT if significance is zero in math_ceil2
295d91cbc700 drm/amd/display: Check for NULL pointer
6472de66c0aa drm/amd/amdgpu: Fix uninitialized variable warnings 93381e6b6180 drm/amdgpu: fix a possible null pointer dereference 7a38efeee6b5 drm/radeon: fix null pointer dereference in radeon_add_common_modes

Quoted 11 lines · Alex Deucher

Resending now that rc1 is out. These should be ignored for stable.

8151a6c13111 drm/amd/display: Skip Recompute DSC Params if no Stream on Link fbfb5f034225 drm/amdgpu: fix contiguous handling for IB parsing v2 ec0d7abbb0d4 drm/amd/display: Fix Potential Null Dereference 332315885d3c drm/amd/display: Remove ASSERT if significance is zero in math_ceil2
295d91cbc700 drm/amd/display: Check for NULL pointer
6472de66c0aa drm/amd/amdgpu: Fix uninitialized variable warnings 93381e6b6180 drm/amdgpu: fix a possible null pointer dereference 7a38efeee6b5 drm/radeon: fix null pointer dereference in radeon_add_common_modes

Thanks, that helped a lot.

However the following two commits did not apply, is that because they are already in the tree or do they need someone to properly backport them?

c2ed7002c061 ("drm/amd/display: Use SDR white level to calculate matrix coefficients") b74571a83fd3 ("drm/amd/display: Use full update for swizzle mode change")

thanks,

greg k-h

Quoted 6 lines · Greg KH

Hi all,

As some of you have noticed, there's a TON of failure messages being sent out for AMD gpu driver commits that are tagged for stable backports. In short, you all are doing something really wrong with how you are tagging these.

Hi Greg,

I got notifications about one KFD patch failing to apply on six branches (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you already applied this patch on two branches back in May. The emails had a suspicious looking date in the header (Sep 17, 2001). I wonder if there was some date glitch that caused a whole bunch of patches to be re-sent to stable somehow:

   ------------------ original commit in Linus's tree
   ------------------ From 24e82654e98e96cece5d8b919c522054456eeec6 Mon
   Sep 17 00:00:00 2001 From: Alex Deucher
   <[email protected]>Date: Sun, 14 Apr 2024 13:06:39 -0400

Subject: [PATCH] drm/amdkfd: don't allow mapping the MMIO HDP page with large pages ...

On 6.1 and 6.6, the patch was already applied by you in May:

   $ git log --pretty=fuller stable/linux-6.6.y --grep "drm/amdkfd: don't allow mapping the MMIO HDP page with large pages"
   commit 4b4cff994a27ebf7bd3fb9a798a1cdfa8d01b724
   Author:     Alex Deucher <[email protected]>
   AuthorDate: Sun Apr 14 13:06:39 2024 -0400
   Commit:     Greg Kroah-Hartman <[email protected]>
   CommitDate: Fri May 17 12:02:34 2024 +0200

drm/amdkfd: don't allow mapping the MMIO HDP page with large pages
...

On 6.10 it was already upstream.

On 5.4-5.15 it doesn't apply because of conflicts. I can resolve those and send the fixed patches out for you.