Re: remove alloc_vm_area v2
On Wed, Sep 30, 2020 at 4:48 PM Christoph Hellwig wrote: > > On Tue, Sep 29, 2020 at 03:43:30PM +0300, Joonas Lahtinen wrote: > > Hmm, those are both committed after our last -next pull request, so they > > would normally only target next merge window. drm-next closes the merge > > window around -rc5 already. > > > > But, in this specific case those are both Fixes: patches with Cc: stable, > > so they should be pulled into drm-intel-next-fixes PR. > > > > Rodrigo, can you cherry-pick those patches to -next-fixes that you send > > to Dave? > > They still haven't made it to linux-next. I think for now I'll just > rebase without them again and then you can handle the conflicts for > 5.11. Yeah after -rc6 drm is frozen for features, so anything that's stuck in subordinate trees rolls over to the next merge cycle. To avoid upsetting sfr from linux-next we keep those -next branches out of linux-next until after -rc1 again. iow, rebasing onto linux-next and smashing this into 5.10 sounds like the right approach (since everyone else freezes a bunch later afaik). Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: remove alloc_vm_area v2
On Tue, Sep 29, 2020 at 03:43:30PM +0300, Joonas Lahtinen wrote: > Hmm, those are both committed after our last -next pull request, so they > would normally only target next merge window. drm-next closes the merge > window around -rc5 already. > > But, in this specific case those are both Fixes: patches with Cc: stable, > so they should be pulled into drm-intel-next-fixes PR. > > Rodrigo, can you cherry-pick those patches to -next-fixes that you send > to Dave? They still haven't made it to linux-next. I think for now I'll just rebase without them again and then you can handle the conflicts for 5.11.
Re: remove alloc_vm_area v2
Quoting Christoph Hellwig (2020-09-28 15:37:41) > On Mon, Sep 28, 2020 at 01:13:38PM +0300, Joonas Lahtinen wrote: > > I think we have a gap that after splitting the drm-intel-next pull requests > > into > > two the drm-intel/for-linux-next branch is now missing material from > > drm-intel/drm-intel-gt-next. > > > > I think a simple course of action might be to start including > > drm-intel-gt-next > > in linux-next, which would mean that we should update DIM tooling to add > > extra branch "drm-intel/gt-for-linux-next" or so. > > > > Which specific patches are missing in this case? > > The two dependencies required by my series not in mainline are: > > drm/i915/gem: Avoid implicit vmap for highmem on x86-32 > drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not supported > > so it has to be one or both of those. Hmm, those are both committed after our last -next pull request, so they would normally only target next merge window. drm-next closes the merge window around -rc5 already. But, in this specific case those are both Fixes: patches with Cc: stable, so they should be pulled into drm-intel-next-fixes PR. Rodrigo, can you cherry-pick those patches to -next-fixes that you send to Dave? Regards, Joonas
Re: remove alloc_vm_area v2
On Mon, Sep 28, 2020 at 01:13:38PM +0300, Joonas Lahtinen wrote: > I think we have a gap that after splitting the drm-intel-next pull requests > into > two the drm-intel/for-linux-next branch is now missing material from > drm-intel/drm-intel-gt-next. > > I think a simple course of action might be to start including > drm-intel-gt-next > in linux-next, which would mean that we should update DIM tooling to add > extra branch "drm-intel/gt-for-linux-next" or so. > > Which specific patches are missing in this case? The two dependencies required by my series not in mainline are: drm/i915/gem: Avoid implicit vmap for highmem on x86-32 drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not supported so it has to be one or both of those.
Re: remove alloc_vm_area v2
+ Dave and Daniel + Stephen Quoting Christoph Hellwig (2020-09-26 09:29:59) > On Fri, Sep 25, 2020 at 07:43:49PM -0700, Andrew Morton wrote: > > On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig wrote: > > > > > this series removes alloc_vm_area, which was left over from the big > > > vmalloc interface rework. It is a rather arkane interface, basicaly > > > the equivalent of get_vm_area + actually faulting in all PTEs in > > > the allocated area. It was originally addeds for Xen (which isn't > > > modular to start with), and then grew users in zsmalloc and i915 > > > which seems to mostly qualify as abuses of the interface, especially > > > for i915 as a random driver should not set up PTE bits directly. > > > > > > Note that the i915 patches apply to the drm-tip branch of the drm-tip > > > tree, as that tree has recent conflicting commits in the same area. > > > > Is the drm-tip material in linux-next yet? I'm still seeing a non-trivial > > reject in there at present. > > I assumed it was, but the reject imply that they aren't. Tvrtko, do you > know the details? I think we have a gap that after splitting the drm-intel-next pull requests into two the drm-intel/for-linux-next branch is now missing material from drm-intel/drm-intel-gt-next. I think a simple course of action might be to start including drm-intel-gt-next in linux-next, which would mean that we should update DIM tooling to add extra branch "drm-intel/gt-for-linux-next" or so. Which specific patches are missing in this case? Regards, Joonas
Re: remove alloc_vm_area v2
On Fri, Sep 25, 2020 at 07:43:49PM -0700, Andrew Morton wrote: > On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig wrote: > > > this series removes alloc_vm_area, which was left over from the big > > vmalloc interface rework. It is a rather arkane interface, basicaly > > the equivalent of get_vm_area + actually faulting in all PTEs in > > the allocated area. It was originally addeds for Xen (which isn't > > modular to start with), and then grew users in zsmalloc and i915 > > which seems to mostly qualify as abuses of the interface, especially > > for i915 as a random driver should not set up PTE bits directly. > > > > Note that the i915 patches apply to the drm-tip branch of the drm-tip > > tree, as that tree has recent conflicting commits in the same area. > > Is the drm-tip material in linux-next yet? I'm still seeing a non-trivial > reject in there at present. I assumed it was, but the reject imply that they aren't. Tvrtko, do you know the details?
Re: remove alloc_vm_area v2
On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig wrote: > this series removes alloc_vm_area, which was left over from the big > vmalloc interface rework. It is a rather arkane interface, basicaly > the equivalent of get_vm_area + actually faulting in all PTEs in > the allocated area. It was originally addeds for Xen (which isn't > modular to start with), and then grew users in zsmalloc and i915 > which seems to mostly qualify as abuses of the interface, especially > for i915 as a random driver should not set up PTE bits directly. > > Note that the i915 patches apply to the drm-tip branch of the drm-tip > tree, as that tree has recent conflicting commits in the same area. Is the drm-tip material in linux-next yet? I'm still seeing a non-trivial reject in there at present.
remove alloc_vm_area v2
Hi Andrew, this series removes alloc_vm_area, which was left over from the big vmalloc interface rework. It is a rather arkane interface, basicaly the equivalent of get_vm_area + actually faulting in all PTEs in the allocated area. It was originally addeds for Xen (which isn't modular to start with), and then grew users in zsmalloc and i915 which seems to mostly qualify as abuses of the interface, especially for i915 as a random driver should not set up PTE bits directly. Note that the i915 patches apply to the drm-tip branch of the drm-tip tree, as that tree has recent conflicting commits in the same area. A git tree is also available here: git://git.infradead.org/users/hch/misc.git alloc_vm_area Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/alloc_vm_area Changes since v1: - fix a bug in the zsmalloc changes - fix a bug and rebase to include the recent changes in i915 - add a new vmap flag that allows to free the page array and pages using vfree - add a vfree documentation updated from Matthew Diffstat: arch/x86/xen/grant-table.c| 27 -- drivers/gpu/drm/i915/Kconfig |1 drivers/gpu/drm/i915/gem/i915_gem_pages.c | 131 +- drivers/gpu/drm/i915/gt/shmem_utils.c | 76 - drivers/xen/xenbus/xenbus_client.c| 30 +++--- include/linux/vmalloc.h |7 - mm/Kconfig|3 mm/memory.c | 16 ++- mm/nommu.c|7 - mm/vmalloc.c | 123 ++-- mm/zsmalloc.c | 10 +- 11 files changed, 200 insertions(+), 231 deletions(-)
