<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/etnaviv, branch v5.10.28</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.10.28</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.10.28'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-03-30T12:31:55+00:00</updated>
<entry>
<title>drm/etnaviv: Use FOLL_FORCE for userptr</title>
<updated>2021-03-30T12:31:55+00:00</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2021-03-01T09:52:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f771b2b3eb2f4c4a2a2456f59b43de3942709c43'/>
<id>urn:sha1:f771b2b3eb2f4c4a2a2456f59b43de3942709c43</id>
<content type='text'>
commit cd5297b0855f17c8b4e3ef1d20c6a3656209c7b3 upstream.

Nothing checks userptr.ro except this call to pup_fast, which means
there's nothing actually preventing userspace from writing to this.
Which means you can just read-only mmap any file you want, userptr it
and then write to it with the gpu. Not good.

The right way to handle this is FOLL_WRITE | FOLL_FORCE, which will
break any COW mappings and update tracking for MAY_WRITE mappings so
there's no exploit and the vm isn't confused about what's going on.
For any legit use case there's no difference from what userspace can
observe and do.

Reviewed-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Cc: stable@vger.kernel.org
Cc: John Hubbard &lt;jhubbard@nvidia.com&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@intel.com&gt;
Cc: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Cc: Russell King &lt;linux+etnaviv@armlinux.org.uk&gt;
Cc: Christian Gmeiner &lt;christian.gmeiner@gmail.com&gt;
Cc: etnaviv@lists.freedesktop.org
Link: https://patchwork.freedesktop.org/patch/msgid/20210301095254.1946084-1-daniel.vetter@ffwll.ch
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'drm-misc-next-2020-09-21' of git://anongit.freedesktop.org/drm/drm-misc into drm-next</title>
<updated>2020-09-22T23:52:24+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2020-09-22T23:49:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6ea6be77086f23d4b346c9946dae24593befda2e'/>
<id>urn:sha1:6ea6be77086f23d4b346c9946dae24593befda2e</id>
<content type='text'>
drm-misc-next for 5.10:

UAPI Changes:

Cross-subsystem Changes:
  - virtio: Merged a PR for patches that will affect drm/virtio

Core Changes:
  - dev: More devm_drm convertions and removal of drm_dev_init
  - atomic: Split out drm_atomic_helper_calc_timestamping_constants of
    drm_atomic_helper_update_legacy_modeset_state
  - ttm: More rework

Driver Changes:
  - i915: selftests improvements
  - panfrost: support for Amlogic SoC
  - vc4: one fix
  - tree-wide: conversions to devm_drm_dev_alloc,
  - ast: simplifications of the atomic modesetting code
  - panfrost: multiple fixes
  - vc4: multiple fixes
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;

From: Maxime Ripard &lt;maxime@cerno.tech&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20200921152956.2gxnsdgxmwhvjyut@gilmour.lan
</content>
</entry>
<entry>
<title>Merge branch 'for-5.10-drm-sg-fix' of https://github.com/mszyprow/linux into drm-next</title>
<updated>2020-09-17T06:07:11+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2020-09-17T04:18:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b40be05ed255d9a0257fb66ab2728ecca2c9d597'/>
<id>urn:sha1:b40be05ed255d9a0257fb66ab2728ecca2c9d597</id>
<content type='text'>
Please pull a set of fixes for various DRM drivers that finally resolve
incorrect usage of the scatterlists (struct sg_table nents and orig_nents
entries), what causes issues when IOMMU is used.

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
From: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20200910080505.24456-1-m.szyprowski@samsung.com
</content>
</entry>
<entry>
<title>Merge drm/drm-next into drm-misc-next</title>
<updated>2020-09-14T16:11:40+00:00</updated>
<author>
<name>Maxime Ripard</name>
<email>maxime@cerno.tech</email>
</author>
<published>2020-09-14T16:11:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=00af6729b52ede86a08173c8d5f2c8cd9fa3390d'/>
<id>urn:sha1:00af6729b52ede86a08173c8d5f2c8cd9fa3390d</id>
<content type='text'>
Paul Cercueil needs some patches in -rc5 to apply new patches for ingenic
properly.

Signed-off-by: Maxime Ripard &lt;maxime@cerno.tech&gt;
</content>
</entry>
<entry>
<title>drm: etnaviv: fix common struct sg_table related issues</title>
<updated>2020-09-10T06:18:35+00:00</updated>
<author>
<name>Marek Szyprowski</name>
<email>m.szyprowski@samsung.com</email>
</author>
<published>2020-04-28T11:08:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=182354a526a0540c9197e03d9fce8a949ffd36ca'/>
<id>urn:sha1:182354a526a0540c9197e03d9fce8a949ffd36ca</id>
<content type='text'>
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_map_sg().

struct sg_table is a common structure used for describing a non-contiguous
memory buffer, used commonly in the DRM and graphics subsystems. It
consists of a scatterlist with memory pages and DMA addresses (sgl entry),
as well as the number of scatterlist entries: CPU pages (orig_nents entry)
and DMA mapped pages (nents entry).

It turned out that it was a common mistake to misuse nents and orig_nents
entries, calling DMA-mapping functions with a wrong number of entries or
ignoring the number of mapped entries returned by the dma_map_sg()
function.

To avoid such issues, lets use a common dma-mapping wrappers operating
directly on the struct sg_table objects and use scatterlist page
iterators where possible. This, almost always, hides references to the
nents and orig_nents entries, making the code robust, easier to follow
and copy/paste safe.

Signed-off-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Reviewed-by: Robin Murphy &lt;robin.murphy@arm.com&gt;
Acked-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>drm: allow limiting the scatter list size.</title>
<updated>2020-09-09T05:58:56+00:00</updated>
<author>
<name>Gerd Hoffmann</name>
<email>kraxel@redhat.com</email>
</author>
<published>2020-09-07T11:24:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=707d561f77b5e2a6f90c9786bee44ee7a8dedc7e'/>
<id>urn:sha1:707d561f77b5e2a6f90c9786bee44ee7a8dedc7e</id>
<content type='text'>
Add drm_device argument to drm_prime_pages_to_sg(), so we can
call dma_max_mapping_size() to figure the segment size limit
and call into __sg_alloc_table_from_pages() with the correct
limit.

This fixes virtio-gpu with sev.  Possibly it'll fix other bugs
too given that drm seems to totaly ignore segment size limits
so far ...

v2: place max_segment in drm driver not gem object.
v3: move max_segment next to the other gem fields.
v4: just use dma_max_mapping_size().

Signed-off-by: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/20200907112425.15610-2-kraxel@redhat.com
</content>
</entry>
<entry>
<title>drm/etnaviv: always start/stop scheduler in timeout processing</title>
<updated>2020-08-24T15:21:21+00:00</updated>
<author>
<name>Lucas Stach</name>
<email>l.stach@pengutronix.de</email>
</author>
<published>2020-08-24T10:55:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=50248a3ec0f5e5debd18033eb2a29f0b793a7000'/>
<id>urn:sha1:50248a3ec0f5e5debd18033eb2a29f0b793a7000</id>
<content type='text'>
The drm scheduler currently expects that the stop/start sequence is always
executed in the timeout handling, as the job at the head of the hardware
execution list is always removed from the ring mirror before the driver
function is called and only inserted back into the list when starting the
scheduler.

This adds some unnecessary overhead if the timeout handler determines
that the GPU is still executing jobs normally and just wished to extend
the timeout, but a better solution requires a major rearchitecture of the
scheduler, which is not applicable as a fix.

Fixes: 135517d3565b ("drm/scheduler: Avoid accessing freed bad job.")
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Tested-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
</content>
</entry>
<entry>
<title>drm/etnaviv: fix external abort seen on GC600 rev 0x19</title>
<updated>2020-08-24T15:20:39+00:00</updated>
<author>
<name>Christian Gmeiner</name>
<email>christian.gmeiner@gmail.com</email>
</author>
<published>2020-08-23T19:09:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2c5bf028ef34745e7b3fe768f9c9355ecc7df101'/>
<id>urn:sha1:2c5bf028ef34745e7b3fe768f9c9355ecc7df101</id>
<content type='text'>
It looks like that this GPU core triggers an abort when
reading VIVS_HI_CHIP_PRODUCT_ID and/or VIVS_HI_CHIP_ECO_ID.

I looked at different versions of Vivante's kernel driver and did
not found anything about this issue or what feature flag can be
used. So go the simplest route and do not read these two registers
on the affected GPU core.

Signed-off-by: Christian Gmeiner &lt;christian.gmeiner@gmail.com&gt;
Reported-by: Josua Mayer &lt;josua.mayer@jm0.eu&gt;
Fixes: 815e45bbd4d3 ("drm/etnaviv: determine product, customer and eco id")
Cc: stable@vger.kernel.org
Tested-by: Josua Mayer &lt;josua.mayer@jm0.eu&gt;
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>Merge branch 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux into drm-next</title>
<updated>2020-07-23T05:28:10+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2020-07-23T05:28:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2646699f4b5139d077186dfd4ca571a0ebb6d419'/>
<id>urn:sha1:2646699f4b5139d077186dfd4ca571a0ebb6d419</id>
<content type='text'>
Nothing too exciting:
- a cleanup of our clock handling and improved error handling in this
area from Lubomir
- conversion to pin_user_pages for long page references from John
- fixed PM runtime API error handling from Navid

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
From: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/d9e2660d71051bf3cab8aa7afc9f62102ac910d9.camel@pengutronix.de
</content>
</entry>
<entry>
<title>drm/etnaviv: fix ref count leak via pm_runtime_get_sync</title>
<updated>2020-07-17T15:10:34+00:00</updated>
<author>
<name>Navid Emamdoost</name>
<email>navid.emamdoost@gmail.com</email>
</author>
<published>2020-06-15T06:12:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c5d5a32ead1e3a61a07a1e59eb52a53e4a6b2a7f'/>
<id>urn:sha1:c5d5a32ead1e3a61a07a1e59eb52a53e4a6b2a7f</id>
<content type='text'>
in etnaviv_gpu_submit, etnaviv_gpu_recover_hang, etnaviv_gpu_debugfs,
and etnaviv_gpu_init the call to pm_runtime_get_sync increments the
counter even in case of failure, leading to incorrect ref count.
In case of failure, decrement the ref count before returning.

Signed-off-by: Navid Emamdoost &lt;navid.emamdoost@gmail.com&gt;
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
</content>
</entry>
</feed>
