Message ID | 20240805102554.154464-1-andi.shyti@linux.intel.com (mailing list archive) |
---|---|
Headers | show |
Series | Fix mmap memory boundary calculation | expand |
Hi Greg, > Andi Shyti (2): > drm/i915/gem: Adjust vma offset for framebuffer mmap offset > drm/i915/gem: Fix Virtual Memory mapping boundaries calculation I have forgotten to Cc the stable mailing list here. These two patches need to be merged together even if only the second patch has the "Fixes:" tag. Is there anything I should still do here? I could have used the "Requires:" tag, but the commit id would change in between merges and rebases. Andi
On Mon, Aug 05, 2024 at 11:05:22PM +0100, Andi Shyti wrote: > Hi Greg, > > > Andi Shyti (2): > > drm/i915/gem: Adjust vma offset for framebuffer mmap offset > > drm/i915/gem: Fix Virtual Memory mapping boundaries calculation > > I have forgotten to Cc the stable mailing list here. These two > patches need to be merged together even if only the second patch > has the "Fixes:" tag. > > Is there anything I should still do here? > > I could have used the "Requires:" tag, but the commit id would > change in between merges and rebases. <formletter> This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly. </formletter>
Hi Greg, same question without the stable mailing list not to trigger the automatic reply. > Andi Shyti (2): > drm/i915/gem: Adjust vma offset for framebuffer mmap offset > drm/i915/gem: Fix Virtual Memory mapping boundaries calculation I have forgotten to actually Cc the stable mailing list here. These two patches need to be merged together even if only the second patch has the "Fixes:" tag. I could have used the "Requires:" tag, but the commit id would change in between merges and rebases. Is there anything I should still do here? Do you want me to take care and send the backports for kernels starting from 4.19? Thanks, Andi
Quoting Andi Shyti (2024-08-06 12:46:07) > Hi Greg, > > same question without the stable mailing list not to trigger the > automatic reply. > > > Andi Shyti (2): > > drm/i915/gem: Adjust vma offset for framebuffer mmap offset > > drm/i915/gem: Fix Virtual Memory mapping boundaries calculation > > I have forgotten to actually Cc the stable mailing list here. > These two patches need to be merged together even if only the > second patch has the "Fixes:" tag. > > I could have used the "Requires:" tag, but the commit id would > change in between merges and rebases. The patches were the top two in drm-intel-gt-next and committed only few hours ago so I fixed up the patches adding Cc: stable and Requires: Regards, Joonas > > Is there anything I should still do here? Do you want me to > take care and send the backports for kernels starting from 4.19? > > Thanks, > Andi
On Tue, Aug 6, 2024 at 2:08 PM Joonas Lahtinen <joonas.lahtinen@linux.intel.com> wrote: > Quoting Andi Shyti (2024-08-06 12:46:07) > > Hi Greg, > > > > same question without the stable mailing list not to trigger the > > automatic reply. > > > > > Andi Shyti (2): > > > drm/i915/gem: Adjust vma offset for framebuffer mmap offset > > > drm/i915/gem: Fix Virtual Memory mapping boundaries calculation > > > > I have forgotten to actually Cc the stable mailing list here. > > These two patches need to be merged together even if only the > > second patch has the "Fixes:" tag. > > > > I could have used the "Requires:" tag, but the commit id would > > change in between merges and rebases. > > The patches were the top two in drm-intel-gt-next and committed > only few hours ago so I fixed up the patches adding Cc: stable > and Requires: I'm not very familiar with how the DRM trees work - shouldn't fixes in i915 go on the separate drm-intel-fixes branch so that they don't have to wait for a merge window?
On Fri, Aug 9, 2024 at 4:48 PM Jann Horn <jannh@google.com> wrote: > On Tue, Aug 6, 2024 at 2:08 PM Joonas Lahtinen > <joonas.lahtinen@linux.intel.com> wrote: > > Quoting Andi Shyti (2024-08-06 12:46:07) > > > Hi Greg, > > > > > > same question without the stable mailing list not to trigger the > > > automatic reply. > > > > > > > Andi Shyti (2): > > > > drm/i915/gem: Adjust vma offset for framebuffer mmap offset > > > > drm/i915/gem: Fix Virtual Memory mapping boundaries calculation > > > > > > I have forgotten to actually Cc the stable mailing list here. > > > These two patches need to be merged together even if only the > > > second patch has the "Fixes:" tag. > > > > > > I could have used the "Requires:" tag, but the commit id would > > > change in between merges and rebases. > > > > The patches were the top two in drm-intel-gt-next and committed > > only few hours ago so I fixed up the patches adding Cc: stable > > and Requires: > > I'm not very familiar with how the DRM trees work - shouldn't fixes in > i915 go on the separate drm-intel-fixes branch so that they don't have > to wait for a merge window? Ah, nevermind, I see it is already in drm-intel-fixes. Sorry for the noise.
Quoting Jann Horn (2024-08-09 18:40:45) > On Fri, Aug 9, 2024 at 4:48 PM Jann Horn <jannh@google.com> wrote: > > On Tue, Aug 6, 2024 at 2:08 PM Joonas Lahtinen > > <joonas.lahtinen@linux.intel.com> wrote: > > > Quoting Andi Shyti (2024-08-06 12:46:07) > > > > Hi Greg, > > > > > > > > same question without the stable mailing list not to trigger the > > > > automatic reply. > > > > > > > > > Andi Shyti (2): > > > > > drm/i915/gem: Adjust vma offset for framebuffer mmap offset > > > > > drm/i915/gem: Fix Virtual Memory mapping boundaries calculation > > > > > > > > I have forgotten to actually Cc the stable mailing list here. > > > > These two patches need to be merged together even if only the > > > > second patch has the "Fixes:" tag. > > > > > > > > I could have used the "Requires:" tag, but the commit id would > > > > change in between merges and rebases. > > > > > > The patches were the top two in drm-intel-gt-next and committed > > > only few hours ago so I fixed up the patches adding Cc: stable > > > and Requires: > > > > I'm not very familiar with how the DRM trees work - shouldn't fixes in > > i915 go on the separate drm-intel-fixes branch so that they don't have > > to wait for a merge window? > > Ah, nevermind, I see it is already in drm-intel-fixes. Sorry for the noise. Yeah, the DRM subsystem has a rather specific process. Jann, do you consider the fix released already now that it is in -rc3 or will you start the 30 day count from when 6.11 gets released? I hope the latter, but just want to make sure there are no surprises. Regards, Joonas
On Mon, Aug 12, 2024 at 11:19 AM Joonas Lahtinen <joonas.lahtinen@linux.intel.com> wrote: > Quoting Jann Horn (2024-08-09 18:40:45) > > On Fri, Aug 9, 2024 at 4:48 PM Jann Horn <jannh@google.com> wrote: > > > On Tue, Aug 6, 2024 at 2:08 PM Joonas Lahtinen > > > <joonas.lahtinen@linux.intel.com> wrote: > > > > Quoting Andi Shyti (2024-08-06 12:46:07) > > > > > Hi Greg, > > > > > > > > > > same question without the stable mailing list not to trigger the > > > > > automatic reply. > > > > > > > > > > > Andi Shyti (2): > > > > > > drm/i915/gem: Adjust vma offset for framebuffer mmap offset > > > > > > drm/i915/gem: Fix Virtual Memory mapping boundaries calculation > > > > > > > > > > I have forgotten to actually Cc the stable mailing list here. > > > > > These two patches need to be merged together even if only the > > > > > second patch has the "Fixes:" tag. > > > > > > > > > > I could have used the "Requires:" tag, but the commit id would > > > > > change in between merges and rebases. > > > > > > > > The patches were the top two in drm-intel-gt-next and committed > > > > only few hours ago so I fixed up the patches adding Cc: stable > > > > and Requires: > > > > > > I'm not very familiar with how the DRM trees work - shouldn't fixes in > > > i915 go on the separate drm-intel-fixes branch so that they don't have > > > to wait for a merge window? > > > > Ah, nevermind, I see it is already in drm-intel-fixes. Sorry for the noise. > > Yeah, the DRM subsystem has a rather specific process. > > Jann, do you consider the fix released already now that it is in -rc3 or will > you start the 30 day count from when 6.11 gets released? I hope the latter, > but just want to make sure there are no surprises. I will count the issue as fixed and start the 30 day count starting from when a fix lands in any upstream release - either a mainline release or a stable release. Since the fix has now been queued up for 6.6 and 6.10, I expect that to happen in a few days.