All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Reviewed-by: John Hubbard
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc
The exynos g2d interface is very unusual, but it looks like the
userptr objects are persistent. Hence they need FOLL_LONGTERM.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc
It's the only user. This also garbage collects the CONFIG_FRAME_VECTOR
symbol from all over the tree (well just one place, somehow omap media
driver still had this in its Kconfig, despite not using it).
Reviewed-by: John Hubbard
Acked-by: Mauro Carvalho Chehab
Signed-off-by: Daniel Vetter
Cc
is loaded and using it.
Fix this by adding the same iomem_is_exclusive() check we already have
on the sysfs side in pci_mmap_resource().
References: 90a545e98126 ("restrict /dev/mem to idle io memory ranges")
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Wi
section as suggested by Jason.
By relying entirely on the vma checks in pin_user_pages and follow_pfn
(for vm_flags and vma_is_fsdax) we can also streamline the code a lot.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
ype1
iommu). For now annotate these as unsafe and splat appropriately.
This patch adds an unsafe_follow_pfn, which later patches will then
roll out to all appropriate places.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Reviewed-by: John Hubbard
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan
-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
--
v2: Fix inversion in the retry check (John).
v4: While at it, use offset_in_page (Chris Wilson)
---
include/linux/mm.h | 3 ++-
mm/memory.c| 46 +++-
up an mmu_notifier ... somehow. Probably means any
invalidate is a fatal fault for this vfio device, but then this
shouldn't ever happen if userspace is reasonable.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme
/resource.c.
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung
mmap support
allowing to adjust the ->f_mapping makes no sense.
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
C
rt io userptr operations on io memory").
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: lin
map through a
special pfn range and not through magic pte attributes. Aliasing is
therefore not a problem.
The only difference in access checks left is that sysfs PCI mmap does
not check for CAP_RAWIO. I'm not really sure whether that should be
added or not.
Signed-off-by: Daniel Vetter
Cc: Jas
bits
are all kinda connnected probably simplest if it all goes through -mm.
Cheers, Daniel
Daniel Vetter (15):
drm/exynos: Stop using frame_vector helpers
drm/exynos: Use FOLL_LONGTERM for g2d cmdlists
misc/habana: Stop using frame_vector helpers
misc/habana: Use FOLL_LONGTERM for userptr
These are persistent, not just for the duration of a dma operation.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung
ner, since in e.g. drivers/gpu we
don't do that. Per Dan this seems to be copypasta from places which do
care about pagecache consistency, but not needed. Hence remove it for
slightly less confusion.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
, void
> > > *data,
> > > if (ret)
> > > goto out;
> > >
> > > - ret = submit_fence_sync(submit, !!(args->flags &
> > > MSM_SUBMIT_NO_IMPLICIT));
> > > + ret = submit_fence_sync(submit, (gpu->nr_rings > 1) &&
> > > + !(args->flags & MSM_SUBMIT_NO_IMPLICIT));
> > > if (ret)
> > > goto out;
> > >
> >
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ence.
>*/
> - if (current->memalloc_noio)
> + if (current->memalloc_nowait)
> + flags &= ~__GFP_DIRECT_RECLAIM;
> + else if (current->memalloc_noio)
> flags &= ~(__GFP_IO | __GFP_FS);
> else if (current->memalloc_nofs)
> flags &= ~__GFP_FS;
> --
> 2.27.0
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Hi Oded,
Did testing on your end turn up anything, or can I put an
ack from you on the two habana patches for the next round?
Thanks, Daniel
On Wed, Oct 21, 2020 at 10:57 AM Daniel Vetter wrote:
>
> These are persistent, not just for the duration of a dma operation.
>
> Signed-of
dgpu_atombios.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8
> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 4 ++--
> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 4 ++--
> 5 files changed, 10 insertions
On Thu, Oct 22, 2020 at 1:43 PM Jason Gunthorpe wrote:
>
> On Thu, Oct 22, 2020 at 09:00:44AM +0200, Daniel Vetter wrote:
> > On Thu, Oct 22, 2020 at 1:20 AM Jason Gunthorpe wrote:
> > >
> > > On Wed, Oct 21, 2020 at 09:24:08PM +0200, Daniel Vetter wrote:
> >
ed was waiting for v3. Hence the delay.
Cheers, Daniel
>
> Best regards,
> Niklas Schnelle
>
> On 10/12/20 4:19 PM, Daniel Vetter wrote:
> > On Mon, Oct 12, 2020 at 04:03:28PM +0200, Niklas Schnelle wrote:
> ... snip
> >>> Cc: Jason Gunthorpe
> >&g
On Thu, Oct 22, 2020 at 1:20 AM Jason Gunthorpe wrote:
>
> On Wed, Oct 21, 2020 at 09:24:08PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 21, 2020 at 6:37 PM Jason Gunthorpe wrote:
> > >
> > > On Wed, Oct 21, 2020 at 05:54:54PM +0200, Daniel Vetter wr
On Wed, Oct 21, 2020 at 8:59 PM Dan Williams wrote:
>
> On Wed, Oct 21, 2020 at 1:57 AM Daniel Vetter wrote:
> >
> > We want all iomem mmaps to consistently revoke ptes when the kernel
> > takes over and CONFIG_IO_STRICT_DEVMEM is enabled. This includes the
> > p
On Wed, Oct 21, 2020 at 6:37 PM Jason Gunthorpe wrote:
>
> On Wed, Oct 21, 2020 at 05:54:54PM +0200, Daniel Vetter wrote:
>
> > The trouble is that io_remap_pfn adjust vma->pgoff, so we'd need to
> > split that. So ideally ->mmap would never set up any ptes.
>
&g
On Wed, Oct 21, 2020 at 5:13 PM Jason Gunthorpe wrote:
>
> On Wed, Oct 21, 2020 at 04:42:11PM +0200, Daniel Vetter wrote:
>
> > Uh yes. In drivers/gpu this isn't a problem because we only install
> > ptes from the vm_ops->fault handler. So no races. And I don
On Wed, Oct 21, 2020 at 2:50 PM Jason Gunthorpe wrote:
>
> On Wed, Oct 21, 2020 at 10:56:51AM +0200, Daniel Vetter wrote:
> > There's three ways to access PCI BARs from userspace: /dev/mem, sysfs
> > files, and the old proc interface. Two check against
> > iomem_is_e
On Wed, Oct 21, 2020 at 11:38 AM Niklas Schnelle wrote:
>
>
>
> On 10/21/20 10:56 AM, Daniel Vetter wrote:
> > Way back it was a reasonable assumptions that iomem mappings never
> > change the pfn range they point at. But this has changed:
> >
> > - gpu dri
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Reviewed-by: John Hubbard
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan
, Daniel
Daniel Vetter (16):
drm/exynos: Stop using frame_vector helpers
drm/exynos: Use FOLL_LONGTERM for g2d cmdlists
misc/habana: Stop using frame_vector helpers
misc/habana: Use FOLL_LONGTERM for userptr
mm/frame-vector: Use FOLL_LONGTERM
media: videobuf2: Move frame_vector into media
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Reviewed-by: John Hubbard
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc
it message (Niklas)
Reviewed-by: Gerald Schaefer
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Dan Williams
Cc: Kees Cook
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
The exynos g2d interface is very unusual, but it looks like the
userptr objects are persistent. Hence they need FOLL_LONGTERM.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc
-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Signed-off-by: Daniel Vetter
--
v2: Fix inversion in the retry check (John).
---
include/linux/mm.h | 3 ++-
mm/memory.c| 44 ++--
2 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/inclu
ner, since in e.g. drivers/gpu we
don't do that. Per Dan this seems to be copypasta from places which do
care about pagecache consistency, but not needed. Hence remove it for
slightly less confusion.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
map through a
special pfn range and not through magic pte attributes. Aliasing is
therefore not a problem.
The only difference in access checks left is that sysfs PCI mmap does
not check for CAP_RAWIO. I'm not really sure whether that should be
added or not.
Signed-off-by: Daniel Vetter
Cc: Jas
is loaded and using it.
Fix this by adding the same iomem_is_exclusive() check we already have
on the sysfs side in pci_mmap_resource().
References: 90a545e98126 ("restrict /dev/mem to idle io memory ranges")
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Wi
ype1
iommu). For now annotate these as unsafe and splat appropriately.
This patch adds an unsafe_follow_pfn, which later patches will then
roll out to all appropriate places.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
mmap support
allowing to adjust the ->f_mapping makes no sense.
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
C
/resource.c.
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung
It's the only user. This also garbage collects the CONFIG_FRAME_VECTOR
symbol from all over the tree (well just one place, somehow omap media
driver still had this in its Kconfig, despite not using it).
Reviewed-by: John Hubbard
Acked-by: Mauro Carvalho Chehab
Signed-off-by: Daniel Vetter
Cc
up an mmu_notifier ... somehow. Probably means any
invalidate is a fatal fault for this vfio device, but then this
shouldn't ever happen if userspace is reasonable.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme
These are persistent, not just for the duration of a dma operation.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung
rt io userptr operations on io memory").
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: lin
section as suggested by Jason.
By relying entirely on the vma checks in pin_user_pages and follow_pfn
(for vm_flags and vma_is_fsdax) we can also streamline the code a lot.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
On Tue, Oct 20, 2020 at 01:26:29PM -0700, Rob Clark wrote:
> On Tue, Oct 20, 2020 at 11:14 AM Daniel Vetter wrote:
> >
> > On Tue, Oct 20, 2020 at 7:23 PM Rob Clark wrote:
> > >
> > > On Tue, Oct 20, 2020 at 10:02 AM Daniel Vetter wrote:
> > > >
>
On Tue, Oct 20, 2020 at 7:23 PM Rob Clark wrote:
>
> On Tue, Oct 20, 2020 at 10:02 AM Daniel Vetter wrote:
> >
> > On Tue, Oct 20, 2020 at 5:08 PM Rob Clark wrote:
> > >
> > > On Tue, Oct 20, 2020 at 7:29 AM Daniel Vetter wrote:
> > > >
> >
On Tue, Oct 20, 2020 at 5:08 PM Rob Clark wrote:
>
> On Tue, Oct 20, 2020 at 7:29 AM Daniel Vetter wrote:
> >
> > On Tue, Oct 20, 2020 at 4:01 PM Rob Clark wrote:
> > >
> > > On Tue, Oct 20, 2020 at 1:24 AM Daniel Vetter wrote:
> > > >
>
On Tue, Oct 20, 2020 at 4:01 PM Rob Clark wrote:
>
> On Tue, Oct 20, 2020 at 1:24 AM Daniel Vetter wrote:
> >
> > On Mon, Oct 19, 2020 at 02:10:50PM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > In particular, converting the async
On Tue, Oct 20, 2020 at 1:24 PM Viresh Kumar wrote:
>
> On 20-10-20, 12:56, Daniel Vetter wrote:
> > Yeah that's bad practice. Generally you shouldn't need to hold locks
> > in setup/teardown code, since there's no other thread which can
> > possible hold a reference t
On Tue, Oct 20, 2020 at 11:07 AM Viresh Kumar wrote:
>
> On 12-10-20, 08:43, Rob Clark wrote:
> > On Mon, Oct 12, 2020 at 7:35 AM Daniel Vetter wrote:
> > >
> > > On Sun, Oct 11, 2020 at 07:09:34PM -0700, Rob Clark wrote:
> > > > From: Rob
| 13 +++---
> drivers/gpu/drm/msm/msm_kms.h | 23 ++---
> 13 files changed, 104 insertions(+), 43 deletions(-)
>
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
>
On Mon, Oct 19, 2020 at 11:43:53AM +0800, Kever Yang wrote:
> Hi Daniel,
>
> On 2020/10/15 下午11:23, Daniel Vetter wrote:
> > On Wed, Oct 14, 2020 at 09:48:43AM +0800, Kever Yang wrote:
> > > Hi Maintainers,
> > >
> > > Does this patch ready to merge
se. The value 'name' can be any of the
> - compiled-in fonts: 10x18, 6x10, 7x14, Acorn8x8, MINI4x6,
> + compiled-in fonts: 10x18, 6x10, 6x8, 7x14, Acorn8x8, MINI4x6,
> PEARL8x8, ProFont6x11, SUN12x22, SUN8x16, TER16x32, VGA8x16, VGA8x8.
>
> Note, not all drivers c
maintainer-tools/committer-drm-misc.html#where-do-i-apply-my-patch
Cheers, Daniel
>
> When you apply to drm-misc-fixes include a Fixes: tag so the tooling
> will pick the patches automagically.
>
> In hindsight the patches should have carried a Fixes: tag from a start
> and should have been applied to drm-misc-fixes from a start too.
>
> I have done something like above once or twice but anyway reach out if
> you have questions. Or ask at #dri-devel.
>
> Sam
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Sun, Oct 18, 2020 at 10:45 PM Peilin Ye wrote:
>
> On Sun, Oct 18, 2020 at 10:33:11PM +0200, Daniel Vetter wrote:
> > On Sun, Oct 18, 2020 at 10:18 PM Peilin Ye wrote:
> > > 2/2 is just updating the fb documentation:
> > >
> > > [PATCH 2/2] docs: fb: A
On Sun, Oct 18, 2020 at 10:18 PM Peilin Ye wrote:
>
> On Sun, Oct 18, 2020 at 10:09:06PM +0200, Daniel Vetter wrote:
> > Adding dri-devel too, not sure anyone is still listening on linux-fbdev.
>
> I see, thanks!
>
> > On Sun, Oct 18, 2020 at 8:13 PM Peilin Ye
truct font_desc font_6x8 = {
> .idx= FONT6x8_IDX,
> .name = "6x8",
> .width = 6,
> .height = 8,
> - .data = fontdata_6x8,
> + .data = fontdata_6x8.data,
> .pref = 0,
> };
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Oct 16, 2020 at 9:54 AM John Hubbard wrote:
>
> On 10/9/20 12:59 AM, Daniel Vetter wrote:
> ...
> > @@ -48,40 +47,25 @@ int get_vaddr_frames(unsigned long start, unsigned int
> > nr_frames,
> >
> > start = untagged_addr(start);
> >
> > -
emoved the patches that depend on material
> currently found only at linux-next.
Was a bit tricky to find the cover letter here and that you plan to
send these out this merge window. I think we'll have some confusion
now with Alex from amd having picked up a few already.
Anyway Acked-by:
addresses directly or ignore them if it knows they're
> > overridden by its own IOMMU mapping.
>
> I'd be happy to review patches for this.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Oct 15, 2020 at 2:09 AM Jason Gunthorpe wrote:
>
> On Fri, Oct 09, 2020 at 11:28:54AM -0700, Dan Williams wrote:
> > On Fri, Oct 9, 2020 at 7:32 AM Jason Gunthorpe wrote:
> > >
> > > On Fri, Oct 09, 2020 at 04:24:45PM +0200, Daniel Vetter wrote:
> >
int_of_node(port, ep) {
> > + if (!of_device_is_available(ep))
> > + continue;
> > +
> > remote_port = of_graph_get_remote_port(ep);
> > if (!remote_port) {
> > of_node_put(ep);
>
> Looks good to me.
>
>
> Reviewed-by: Kever Yang
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Oct 13, 2020 at 6:15 PM Rob Clark wrote:
>
> On Tue, Oct 13, 2020 at 4:08 AM Daniel Vetter wrote:
> >
> > On Mon, Oct 12, 2020 at 08:07:38AM -0700, Rob Clark wrote:
> > > On Mon, Oct 12, 2020 at 7:40 AM Daniel Vetter wrote:
> > > >
> > >
On Thu, Oct 15, 2020 at 9:52 AM Daniel Vetter wrote:
>
> On Thu, Oct 15, 2020 at 2:09 AM Jason Gunthorpe wrote:
> >
> > On Fri, Oct 09, 2020 at 11:28:54AM -0700, Dan Williams wrote:
> > > On Fri, Oct 9, 2020 at 7:32 AM Jason Gunthorpe wrote:
> > > >
>
On Thu, Oct 15, 2020 at 2:09 AM Jason Gunthorpe wrote:
>
> On Fri, Oct 09, 2020 at 11:28:54AM -0700, Dan Williams wrote:
> > On Fri, Oct 9, 2020 at 7:32 AM Jason Gunthorpe wrote:
> > >
> > > On Fri, Oct 09, 2020 at 04:24:45PM +0200, Daniel Vetter wrote:
> >
On Mon, Oct 12, 2020 at 08:07:38AM -0700, Rob Clark wrote:
> On Mon, Oct 12, 2020 at 7:40 AM Daniel Vetter wrote:
> >
> > On Sun, Oct 11, 2020 at 07:09:49PM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > Any cross-devi
t;fctx,
> @@ -768,7 +768,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> if (ret)
> goto out;
>
> - ret = submit_fence_sync(submit, !!(args->flags &
> MSM_SUBMIT_NO_IMPLICIT));
> + ret = submit_fence_sync(submit, (gpu-&
ww_class);
> @@ -825,6 +834,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
>
>
> out:
> + pm_runtime_put(>pdev->dev);
> +out_pre_pm:
> submit_cleanup(submit);
> if (has_ww_ticket)
> ww_acquire_fini(>ticket);
> --
> 2.26.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
f you confirm there I can do the fixups when applying or you can resend.
>
> On 10/9/20 9:59 AM, Daniel Vetter wrote:
> > Way back it was a reasonable assumptions that iomem mappings never
> > change the pfn range they point at. But this has changed:
> >
> > - gpu dr
genic: Add option to mmap GEM buffers
> cached""
> Signed-off-by: Paul Cercueil
Acked-by: Daniel Vetter
And yes if you use git cherry-pick it'll do a 3 way merge, and
occasionally it's very tricky to resolve that properly. Especially when
you're not used to it.
What I tend to d
it might be enough for CMA drivers though (but
there's more that's possible here).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Sat, Oct 10, 2020 at 10:27 PM Oded Gabbay wrote:
>
> On Fri, Oct 9, 2020 at 10:59 AM Daniel Vetter wrote:
> >
> > All we need are a pages array, pin_user_pages_fast can give us that
> > directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
> >
On Sat, Oct 10, 2020 at 11:32 PM Daniel Vetter wrote:
>
> On Sat, Oct 10, 2020 at 10:27 PM Oded Gabbay wrote:
> >
> > On Fri, Oct 9, 2020 at 10:59 AM Daniel Vetter
> > wrote:
> > >
> > > All we need are a pages array, pin_user_pages_fast can giv
On Sat, Oct 10, 2020 at 11:36 PM Laurent Pinchart
wrote:
>
> Hi Tomasz,
>
> On Sat, Oct 10, 2020 at 07:22:48PM +0200, Tomasz Figa wrote:
> > On Fri, Oct 9, 2020 at 7:52 PM Daniel Vetter wrote:
> > > On Fri, Oct 9, 2020 at 2:48 PM Jason Gunthorpe wrote:
> > >
bout. Imo that patch simply should never
have landed, and instead dma-buf support prioritized.
Cheers, Daniel
On Sat, Oct 10, 2020 at 11:21 AM Mauro Carvalho Chehab
wrote:
>
> Em Fri, 9 Oct 2020 19:52:05 +0200
> Daniel Vetter escreveu:
>
> > On Fri, Oct 9, 2020 at 2:48 PM Jaso
On Sat, Oct 10, 2020 at 1:39 PM Mauro Carvalho Chehab
wrote:
>
> Em Sat, 10 Oct 2020 12:53:49 +0200
> Daniel Vetter escreveu:
>
> > Hi Mauro,
> >
> > You might want to read the patches more carefully, because what you're
> > demanding
On Fri, Oct 09, 2020 at 12:49:44PM -0700, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> These kmap() calls in the gpu stack are localized to a single thread.
> To avoid the over head of global PKRS updates use the new kmap_thread()
> call.
>
> Cc: David Airlie
>
On Fri, Oct 9, 2020 at 8:01 PM Jason Gunthorpe wrote:
>
> On Fri, Oct 09, 2020 at 07:52:05PM +0200, Daniel Vetter wrote:
>
> > > > If this is the case, the proper fix seems to have a GFP_NOT_MOVABLE
> > > > flag that it would be denying the core mm code to set __
ened before :( It took 4 years for RDMA to undo the uAPI
> breakage caused by a security fix for something that was a 15 years
> old bug.
Yeah we have a bunch of these on the drm side too. Some of them are
really just "you have to upgrade userspace", and there's no real fix
for the security nightmare without that.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Oct 09, 2020 at 12:14:17PM +0200, Mauro Carvalho Chehab wrote:
> Em Fri, 9 Oct 2020 09:59:23 +0200
> Daniel Vetter escreveu:
>
> > It's the only user. This also garbage collects the CONFIG_FRAME_VECTOR
> > symbol from all over the tree (well just one place, somehow
On Fri, Oct 9, 2020 at 6:24 PM Daniel Vetter wrote:
>
> On Fri, Oct 09, 2020 at 05:03:42PM +0200, Christian König wrote:
> > We have reoccurring requests on this so better document that
> > this approach doesn't work and dma_buf_mmap() needs to be used instead.
> >
&
atches 3-5:
Acked-by: Daniel Vetter
This one looks good, but you have it on a strange baseline. This doesn't
contain the sg walking fixes from Marek, so reintroduces the bugs.
Probably need to request a backmerge chain, first of -rc8 into drm-next,
and then that into drm-misc-next.
Everything
On Fri, Oct 9, 2020 at 2:31 PM Jason Gunthorpe wrote:
>
> On Fri, Oct 09, 2020 at 09:59:31AM +0200, Daniel Vetter wrote:
>
> > +struct address_space *iomem_get_mapping(void)
> > +{
> > + return iomem_inode->i_mapping;
>
> This should pa
On Fri, Oct 9, 2020 at 12:42 PM Ville Syrjälä
wrote:
>
> On Fri, Oct 09, 2020 at 12:01:39PM +0200, Daniel Vetter wrote:
> > On Fri, Oct 9, 2020 at 11:47 AM Ville Syrjälä
> > wrote:
> > >
> > > On Fri, Oct 09, 2020 at 09:59:34AM +0200, Daniel Vetter w
On Fri, Oct 9, 2020 at 11:47 AM Ville Syrjälä
wrote:
>
> On Fri, Oct 09, 2020 at 09:59:34AM +0200, Daniel Vetter wrote:
> > When trying to test my CONFIG_IO_STRICT_DEVMEM changes I realized they
> > do nothing for i915. Because i915 doesn't request any regions, like
> >
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof
These are persistent, not just for the duration of a dma operation.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung
section as suggested by Jason.
By relying entirely on the vma checks in pin_user_pages and follow_pfn
(for vm_flags and vma_is_fsdax) we can also streamline the code a lot.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
The exynos g2d interface is very unusual, but it looks like the
userptr objects are persistent. Hence they need FOLL_LONGTERM.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc
n and make sure
we drop the locks only after we've done. The write function also needs
the copy_from_user move, since we can't take userspace faults while
holding the mmap sem.
Reviewed-by: Gerald Schaefer
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Dan Williams
Cc: Kees Cook
Cc: And
is loaded and using it.
Fix this by adding the same iomem_is_exclusive() check we already have
on the sysfs side in pci_mmap_resource().
References: 90a545e98126 ("restrict /dev/mem to idle io memory ranges")
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Wi
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux
It's the only user. This also garbage collects the CONFIG_FRAME_VECTOR
symbol from all over the tree (well just one place, somehow omap media
driver still had this in its Kconfig, despite not using it).
Reviewed-by: John Hubbard
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Pawel Osciak
ype1
iommu). For now annotate these as unsafe and splat appropriately.
This patch adds an unsafe_follow_pfn, which later patches will then
roll out to all appropriate places.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
/resource.c.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me
mmap support
allowing to adjust the ->f_mapping makes no sense.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infrade
map through a
special pfn range and not through magic pte attributes. Aliasing is
therefore not a problem.
The only difference in access checks left is that sysfs PCI mmap does
not check for CAP_RAWIO. I'm not really sure whether that should be
added or not.
Signed-off-by: Daniel Vetter
Cc: Jas
kernel.org
Cc: linux-me...@vger.kernel.org
Signed-off-by: Daniel Vetter
--
v2: Fix inversion in the retry check (John).
---
include/linux/mm.h | 3 ++-
mm/memory.c| 44 ++--
2 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/include/linux/mm
in the
fake agp driver.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc
401 - 500 of 6575 matches
Mail list logo
