- Linaro-mm-sig - lists.linaro.org

Re: get_file() unsafe under epoll (was Re: [syzbot] [fs?] [io-uring?] general protection fault in __ep_remove)

by Kees Cook

On Fri, May 03, 2024 at 01:35:09PM -0600, Jens Axboe wrote: > On 5/3/24 1:22 PM, Kees Cook wrote: > > On Fri, May 03, 2024 at 12:49:11PM -0600, Jens Axboe wrote: > >> On 5/3/24 12:26 PM, Kees Cook wrote: > >>> Thanks for doing this analysis! I suspect at least a start of a fix > >>> would be this: > >>> > >>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > >>> index 8fe5aa67b167..15e8f74ee0f2 100644 > >>> --- a/drivers/dma-buf/dma-buf.c > >>> +++ b/drivers/dma-buf/dma-buf.c > >>> @@ -267,9 +267,8 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) > >>> > >>> if (events & EPOLLOUT) { > >>> /* Paired with fput in dma_buf_poll_cb */ > >>> - get_file(dmabuf->file); > >>> - > >>> - if (!dma_buf_poll_add_cb(resv, true, dcb)) > >>> + if (!atomic_long_inc_not_zero(&dmabuf->file) && > >>> + !dma_buf_poll_add_cb(resv, true, dcb)) > >>> /* No callback queued, wake up any other waiters */ > >> > >> Don't think this is sane at all. I'm assuming you meant: > >> > >> atomic_long_inc_not_zero(&dmabuf->file->f_count); > > > > Oops, yes, sorry. I was typed from memory instead of copy/paste. > > Figured :-) > > >> but won't fly as you're not under RCU in the first place. And what > >> protects it from being long gone before you attempt this anyway? This is > >> sane way to attempt to fix it, it's completely opposite of what sane ref > >> handling should look like. > >> > >> Not sure what the best fix is here, seems like dma-buf should hold an > >> actual reference to the file upfront rather than just stash a pointer > >> and then later _hope_ that it can just grab a reference. That seems > >> pretty horrible, and the real source of the issue. > > > > AFAICT, epoll just doesn't hold any references at all. It depends, > > I think, on eventpoll_release() (really eventpoll_release_file()) > > synchronizing with epoll_wait() (but I don't see how this happens, and > > the race seems to be against ep_item_poll() ...?) > > > > I'm really confused about how eventpoll manages the lifetime of polled > > fds. > > epoll doesn't hold any references, and it's got some ugly callback to > deal with that. It's not ideal, nor pretty, but that's how it currently > works. See eventpoll_release() and how it's called. This means that > epoll itself is supposedly safe from the file going away, even though it > doesn't hold a reference to it. Right -- what remains unclear to me is how struct file lifetime is expected to work in the struct file_operations::poll callbacks. Because using get_file() there looks clearly unsafe... > Except that in this case, the file is already gone by the time > eventpoll_release() is called. Which presumably is some interaction with > the somewhat suspicious file reference management that dma-buf is doing. > But I didn't look into that much, outside of noting it looks a bit > suspect. Not yet, though. Here's (one) race state from the analysis. I added lines for the dma_fence_add_callback()/dma_buf_poll_cb() case, since that's the case that would escape any eventpoll_release/epoll_wait synchronization (if it exists?): close(dmabuf->file) __fput_sync (f_count == 1, last ref) f_count-- (f_count == 0 now) __fput epoll_wait vfs_poll(dmabuf->file) get_file(dmabuf->file)(f_count == 1) dma_fence_add_callback() eventpoll_release dmabuf->file deallocation dma_buf_poll_cb() fput(dmabuf->file) (f_count == 1) f_count-- dmabuf->file deallocation Without fences to create a background callback, we just do a double-free: close(dmabuf->file) __fput_sync (f_count == 1, last ref) f_count-- (f_count == 0 now) __fput epoll_wait vfs_poll(dmabuf->file) get_file(dmabuf->file)(f_count == 1) dma_buf_poll_cb() fput(dmabuf->file) (f_count == 1) f_count-- eventpoll_release dmabuf->file deallocation eventpoll_release dmabuf->file deallocation get_file(), via epoll_wait()->vfs_poll()->dma_buf_poll(), has raised f_count again. Then eventpoll_release() is doing things to remove dmabuf->file from the eventpoll lists, but I *think* this is synchronized so that an epoll_wait() will only call .poll handlers with a valid (though possibly f_count==0) file, but I can't figure out where that happens. (If it's not happening, we have a much bigger problem, but I imagine we'd see massive corruption all the time, which we don't.) So, yeah, I can't figure out how eventpoll_release() and epoll_wait() are expected to behave safely for .poll handlers. Regardless, for the simple case: it seems like it's just totally illegal to use get_file() in a poll handler. Is this known/expected? And if so, how can dmabuf possibly deal with that? -- Kees Cook

1 year, 1 month

4
8
0 0

Re: [PATCH] epoll: try to be a _bit_ better about file lifetimes

by Linus Torvalds

On Sun, 5 May 2024 at 03:50, Christian Brauner <brauner(a)kernel.org> wrote: > > And I agree with you that for some instances it's valid to take another > reference to a file from f_op->poll() but then they need to use > get_file_active() imho and simply handle the case where f_count is zero. I think this is (a) practically impossible to find (since most f_count updates are in various random helpers) (b) not tenable in the first place, since *EVERYBODY* does a f_count update as part of the bog-standard pollwait So (b) means that the notion of "warn if somebody increments f_count from zero" is broken to begin with - but it's doubly broken because it wouldn't find anything *anyway*, since this never happens in any normal situation. And (a) means that any non-automatic finding of this is practically impossible. > And we need to document that in Documentation/filesystems/file.rst or > locking.rst. WHY? Why cannot you and Al just admit that the problem is in epoll. Always has been, always will be. The fact is, it's not dma-buf that is violating any rules. It's epoll. It's calling out to random driver functions with a file pointer that is no longer valid. It really is that simple. I don't see why you are arguing for "unknown number of drivers - we know at least *one* - have to be fixed for a bug that is in epoll". If it was *easy* to fix, and if it was *easy* to validate, then sure. But that just isn't the case. In contrast, in epoll it's *trivial* to fix the one case where it does a VFS call-out, and just say "you have to follow the rules". So explain to me again why you want to mess up the driver interface and everybody who has a '.poll()' function, and not just fix the ONE clearly buggy piece of code. Because dammit,. epoll is clearly buggy. It's not enough to say "the file allocation isn't going away", and claim that that means that it's not buggy - when the file IS NO LONGER VALID! Linus

1 year, 1 month

3
4
0 0

Re: get_file() unsafe under epoll (was Re: [syzbot] [fs?] [io-uring?] general protection fault in __ep_remove)

by Kees Cook

On Fri, May 03, 2024 at 12:49:11PM -0600, Jens Axboe wrote: > On 5/3/24 12:26 PM, Kees Cook wrote: > > Thanks for doing this analysis! I suspect at least a start of a fix > > would be this: > > > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > > index 8fe5aa67b167..15e8f74ee0f2 100644 > > --- a/drivers/dma-buf/dma-buf.c > > +++ b/drivers/dma-buf/dma-buf.c > > @@ -267,9 +267,8 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) > > > > if (events & EPOLLOUT) { > > /* Paired with fput in dma_buf_poll_cb */ > > - get_file(dmabuf->file); > > - > > - if (!dma_buf_poll_add_cb(resv, true, dcb)) > > + if (!atomic_long_inc_not_zero(&dmabuf->file) && > > + !dma_buf_poll_add_cb(resv, true, dcb)) > > /* No callback queued, wake up any other waiters */ > > Don't think this is sane at all. I'm assuming you meant: > > atomic_long_inc_not_zero(&dmabuf->file->f_count); Oops, yes, sorry. I was typed from memory instead of copy/paste. > but won't fly as you're not under RCU in the first place. And what > protects it from being long gone before you attempt this anyway? This is > sane way to attempt to fix it, it's completely opposite of what sane ref > handling should look like. > > Not sure what the best fix is here, seems like dma-buf should hold an > actual reference to the file upfront rather than just stash a pointer > and then later _hope_ that it can just grab a reference. That seems > pretty horrible, and the real source of the issue. AFAICT, epoll just doesn't hold any references at all. It depends, I think, on eventpoll_release() (really eventpoll_release_file()) synchronizing with epoll_wait() (but I don't see how this happens, and the race seems to be against ep_item_poll() ...?) I'm really confused about how eventpoll manages the lifetime of polled fds. > > Due to this issue I've proposed fixing get_file() to detect pathological states: > > https://lore.kernel.org/lkml/20240502222252.work.690-kees@kernel.org/ > > I don't think this would catch this case, as the memory could just be > garbage at this point. It catches it just fine! :) I tested it against the published PoC. And for cases where further allocations have progressed far enough to corrupt the freed struct file and render the check pointless, nothing different has happened than what happens today. At least now we have a window to catch the situation across the time frame before it is both reallocated _and_ the contents at the f_count offset gets changed to non-zero. -- Kees Cook

1 year, 1 month

1
0
0 0

Re: [PATCH v3 0/2] drm: Fix dma_resv deadlock at drm object pin time

by Thomas Zimmermann

Hi Am 02.05.24 um 14:00 schrieb Boris Brezillon: > On Thu, 2 May 2024 13:59:41 +0200 > Boris Brezillon <boris.brezillon(a)collabora.com> wrote: > >> Hi Thomas, >> >> On Thu, 2 May 2024 13:51:16 +0200 >> Thomas Zimmermann <tzimmermann(a)suse.de> wrote: >> >>> Hi, >>> >>> ignoring my r-b on patch 1, I'd like to rethink the current patches in >>> general. >>> >>> I think drm_gem_shmem_pin() should become the locked version of _pin(), >>> so that drm_gem_shmem_object_pin() can call it directly. The existing >>> _pin_unlocked() would not be needed any longer. Same for the _unpin() >>> functions. This change would also fix the consistency with the semantics >>> of the shmem _vmap() functions, which never take reservation locks. >>> >>> There are only two external callers of drm_gem_shmem_pin(): the test >>> case and panthor. These assume that drm_gem_shmem_pin() acquires the >>> reservation lock. The test case should likely call drm_gem_pin() >>> instead. That would acquire the reservation lock and the test would >>> validate that shmem's pin helper integrates well into the overall GEM >>> framework. The way panthor uses drm_gem_shmem_pin() looks wrong to me. >>> For now, it could receive a wrapper that takes the lock and that's it. >> I do agree that the current inconsistencies in the naming is >> troublesome (sometimes _unlocked, sometimes _locked, with the version >> without any suffix meaning either _locked or _unlocked depending on >> what the suffixed version does), and that's the very reason I asked >> Dmitry to address that in his shrinker series [1]. So, ideally I'd >> prefer if patches from Dmitry's series were applied instead of >> trying to fix that here (IIRC, we had an ack from Maxime). > With the link this time :-). > > [1]https://lore.kernel.org/lkml/20240105184624.508603-1-dmitry.osipenko@coll… Thanks. I remember these patches. Somehow I thought they would have been merged already. I wasn't super happy about the naming changes in patch 5, because the names of the GEM object callbacks do no longer correspond with their implementations. But anyway. If we go that direction, we should here simply push drm_gem_shmem_pin() and drm_gem_shmem_unpin() into panthor and update the shmem tests with drm_gem_pin(). Panfrost and lima would call drm_gem_shmem_pin_locked(). IMHO we should not promote the use of drm_gem_shmem_object_*() functions, as they are meant to be callbacks for struct drm_gem_object_funcs. (Auto-generating them would be nice.) Best regards Thomas > >> Regards, >> >> Boris -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)

1 year, 1 month

1
0
0 0

Re: [PATCH v3 0/2] drm: Fix dma_resv deadlock at drm object pin time

by Thomas Zimmermann

Hi, ignoring my r-b on patch 1, I'd like to rethink the current patches in general. I think drm_gem_shmem_pin() should become the locked version of _pin(), so that drm_gem_shmem_object_pin() can call it directly. The existing _pin_unlocked() would not be needed any longer. Same for the _unpin() functions. This change would also fix the consistency with the semantics of the shmem _vmap() functions, which never take reservation locks. There are only two external callers of drm_gem_shmem_pin(): the test case and panthor. These assume that drm_gem_shmem_pin() acquires the reservation lock. The test case should likely call drm_gem_pin() instead. That would acquire the reservation lock and the test would validate that shmem's pin helper integrates well into the overall GEM framework. The way panthor uses drm_gem_shmem_pin() looks wrong to me. For now, it could receive a wrapper that takes the lock and that's it. Best regards Thomas Am 01.05.24 um 08:55 schrieb Adrián Larumbe: > This is v3 of https://lore.kernel.org/dri-devel/20240424090429.57de7d1c@collabora.com/ > > The goal of this patch series is fixing a deadlock upon locking the dma reservation > of a DRM gem object when pinning it, at a prime import operation. > > Changes from v2: > - Removed comment explaining reason why an already-locked > pin function replaced the locked variant inside Panfrost's > object pin callback. > - Moved already-assigned attachment warning into generic > already-locked gem object pin function > > Adrián Larumbe (2): > drm/panfrost: Fix dma_resv deadlock at drm object pin time > drm/gem-shmem: Add import attachment warning to locked pin function > > drivers/gpu/drm/drm_gem_shmem_helper.c | 2 ++ > drivers/gpu/drm/lima/lima_gem.c | 2 +- > drivers/gpu/drm/panfrost/panfrost_gem.c | 2 +- > 3 files changed, 4 insertions(+), 2 deletions(-) > > > base-commit: 75b68f22e39aafb22f3d8e3071e1aba73560788c -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)

1 year, 1 month

1
0
0 0

Re: [PATCH v3 1/2] drm/panfrost: Fix dma_resv deadlock at drm object pin time

by Thomas Zimmermann

Hi Am 01.05.24 um 08:55 schrieb Adrián Larumbe: > When Panfrost must pin an object that is being prepared a dma-buf > attachment for on behalf of another driver, the core drm gem object pinning > code already takes a lock on the object's dma reservation. > > However, Panfrost GEM object's pinning callback would eventually try taking > the lock on the same dma reservation when delegating pinning of the object > onto the shmem subsystem, which led to a deadlock. > > This can be shown by enabling CONFIG_DEBUG_WW_MUTEX_SLOWPATH, which throws > the following recursive locking situation: > > weston/3440 is trying to acquire lock: > ffff000000e235a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_gem_shmem_pin+0x34/0xb8 [drm_shmem_helper] > but task is already holding lock: > ffff000000e235a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_gem_pin+0x2c/0x80 [drm] > > Fix it by assuming the object's reservation had already been locked by the > time we reach panfrost_gem_pin. Maybe say that the reservation lock has been taken in drm_gem_pin() > > Do the same thing for the Lima driver, as it most likely suffers from the > same issue. Please split this patch into one for panfrost and one for lima. To each patch, you can add Reviewed-by: Thomas Zimmermann <tzimmermann(a)suse.de> Best regards Thomas > > Cc: Thomas Zimmermann <tzimmermann(a)suse.de> > Cc: Dmitry Osipenko <dmitry.osipenko(a)collabora.com> > Cc: Boris Brezillon <boris.brezillon(a)collabora.com> > Cc: Steven Price <steven.price(a)arm.com> > Fixes: a78027847226 ("drm/gem: Acquire reservation lock in drm_gem_{pin/unpin}()") > Signed-off-by: Adrián Larumbe <adrian.larumbe(a)collabora.com> > --- > drivers/gpu/drm/lima/lima_gem.c | 2 +- > drivers/gpu/drm/panfrost/panfrost_gem.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c > index 7ea244d876ca..c4e0f9faaa47 100644 > --- a/drivers/gpu/drm/lima/lima_gem.c > +++ b/drivers/gpu/drm/lima/lima_gem.c > @@ -185,7 +185,7 @@ static int lima_gem_pin(struct drm_gem_object *obj) > if (bo->heap_size) > return -EINVAL; > > - return drm_gem_shmem_pin(&bo->base); > + return drm_gem_shmem_object_pin(obj); > } > > static int lima_gem_vmap(struct drm_gem_object *obj, struct iosys_map *map) > diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c b/drivers/gpu/drm/panfrost/panfrost_gem.c > index d47b40b82b0b..f268bd5c2884 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_gem.c > +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c > @@ -192,7 +192,7 @@ static int panfrost_gem_pin(struct drm_gem_object *obj) > if (bo->is_heap) > return -EINVAL; > > - return drm_gem_shmem_pin(&bo->base); > + return drm_gem_shmem_object_pin(obj); > } > > static enum drm_gem_object_status panfrost_gem_status(struct drm_gem_object *obj) -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)

1 year, 1 month

1
0
0 0

Re: [PATCH v4 05/16] SoC: mediatek: mt8365: support audio clock control

by Mark Brown

On Fri, Apr 26, 2024 at 07:22:34PM +0200, Alexandre Mergnat wrote: > Add audio clock wrapper and audio tuner control. Please submit patches using subject lines reflecting the style for the subsystem, this makes it easier for people to identify relevant patches. Look at what existing commits in the area you're changing are doing and make sure your subject lines visually resemble what they're doing. There's no need to resubmit to fix this alone.

1 year, 1 month

1
0
0 0

Re: [PATCH v4 03/16] dt-bindings: mfd: mediatek: Add codec property for MT6357 PMIC

by Krzysztof Kozlowski

On 26/04/2024 19:22, Alexandre Mergnat wrote: > regulators: > type: object > $ref: /schemas/regulator/mediatek,mt6357-regulator.yaml > @@ -83,6 +111,12 @@ examples: > interrupt-controller; > #interrupt-cells = <2>; > > + audio-codec { > + mediatek,micbias0-microvolt = <1700000>; > + mediatek,micbias1-microvolt = <1700000>; > + vaud28-supply = <&mt6357_vaud28_reg>; And now you should see how odd it looks. Supplies are part of entire chip, not subblock, even if they supply dedicated domain within that chip. That's why I asked to put it in the parent node. Best regards, Krzysztof

1 year, 1 month

1
0
0 0

Re: [PATCH v4 02/16] ASoC: dt-bindings: mediatek,mt8365-mt6357: Add audio sound card document

by Krzysztof Kozlowski

On 26/04/2024 19:22, Alexandre Mergnat wrote: > + link-name: > + description: Indicates dai-link name and PCM stream name > + enum: > + - I2S_IN_BE > + - I2S_OUT_BE > + - PCM1_BE > + - PDM1_BE > + - PDM2_BE > + - PDM3_BE > + - PDM4_BE > + - SPDIF_IN_BE > + - SPDIF_OUT_BE > + - TDM_IN_BE > + - TDM_OUT_BE Feels like BE is redundant. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Best regards, Krzysztof

1 year, 1 month

1
0
0 0

Re: [PATCH v4 01/16] ASoC: dt-bindings: mediatek,mt8365-afe: Add audio afe document

by Krzysztof Kozlowski

On 26/04/2024 19:22, Alexandre Mergnat wrote: > Add MT8365 audio front-end bindings > > Signed-off-by: Alexandre Mergnat <amergnat(a)baylibre.com> > --- Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Best regards, Krzysztof

1 year, 1 month

1
0
0 0

Re: [PATCH v3 03/18] ASoC: dt-bindings: mt6357: Add audio codec document

by Krzysztof Kozlowski

On 23/04/2024 19:07, Alexandre Mergnat wrote: > > > On 09/04/2024 17:55, Krzysztof Kozlowski wrote: >>> + >>> +additionalProperties: false >>> + >>> +examples: >>> + - | >>> + codec { >>> + mediatek,micbias0-microvolt = <1900000>; >>> + mediatek,micbias1-microvolt = <1700000>; >>> + mediatek,vaud28-supply = <&mt6357_vaud28_reg>; >> Sorry, this does not work. Change voltage to 1111111 and check the results. > > Actually it's worst ! I've removed the required property (vaud28-supply) but the dt check pass. > Same behavior for some other docs like mt6359.yaml Yeah, the schema is not applied. There is nothing selecting it, so this is no-op schema. I don't know what exactly you want to describe, but usually either you miss compatible or this should be just part of parent node. > > The at24.yaml doc works as expected, then I tried compare an find the issue, without success... > > I've replaced "codec" by "audio-codec", according to [1]. > I've tried multiple manner to implement the example code, without success. I'm wondering if what I > try to do is the correct way or parse-able by the dt_check. > > If I drop this file and implement all these new properties into the MFD PMIC documentation directly, > I've the expected dt_check result (function to good or wrong parameters) Yes. Best regards, Krzysztof

1 year, 1 month

1
0
0 0

Re: [PATCH] drm/panfrost: Fix dma_resv deadlock at drm object pin time

by Dmitry Osipenko

On 4/21/24 19:39, Adrián Larumbe wrote: > When Panfrost must pin an object that is being prepared a dma-buf > attachment for on behalf of another driver, the core drm gem object pinning > code already takes a lock on the object's dma reservation. > > However, Panfrost GEM object's pinning callback would eventually try taking > the lock on the same dma reservation when delegating pinning of the object > onto the shmem subsystem, which led to a deadlock. > > This can be shown by enabling CONFIG_DEBUG_WW_MUTEX_SLOWPATH, which throws > the following recursive locking situation: > > weston/3440 is trying to acquire lock: > ffff000000e235a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_gem_shmem_pin+0x34/0xb8 [drm_shmem_helper] > but task is already holding lock: > ffff000000e235a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_gem_pin+0x2c/0x80 [drm] > > Fix it by assuming the object's reservation had already been locked by the > time we reach panfrost_gem_pin. > > Cc: Thomas Zimmermann <tzimmermann(a)suse.de> > Cc: Dmitry Osipenko <dmitry.osipenko(a)collabora.com> > Cc: Boris Brezillon <boris.brezillon(a)collabora.com> > Cc: Steven Price <steven.price(a)arm.com> > Fixes: a78027847226 ("drm/gem: Acquire reservation lock in drm_gem_{pin/unpin}()") > Signed-off-by: Adrián Larumbe <adrian.larumbe(a)collabora.com> > --- > drivers/gpu/drm/panfrost/panfrost_gem.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c b/drivers/gpu/drm/panfrost/panfrost_gem.c > index d47b40b82b0b..6c26652d425d 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_gem.c > +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c > @@ -192,7 +192,12 @@ static int panfrost_gem_pin(struct drm_gem_object *obj) > if (bo->is_heap) > return -EINVAL; > > - return drm_gem_shmem_pin(&bo->base); > + /* > + * Pinning can only happen in response to a prime attachment request from > + * another driver, but that's already being handled by drm_gem_pin > + */ > + drm_WARN_ON(obj->dev, obj->import_attach); > + return drm_gem_shmem_pin_locked(&bo->base); > } Will be better to use drm_gem_shmem_object_pin() to avoid such problem in future Please also fix the Lima driver -- Best regards, Dmitry

1 year, 1 month

1
0
0 0

Re: [PATCH v3 2/2] misc: sram: Add DMA-BUF Heap exporting of SRAM areas

by Greg Kroah-Hartman

On Tue, Apr 09, 2024 at 02:06:05PM +0200, Pascal FONTAIN wrote: > From: Andrew Davis <afd(a)ti.com> > > This new export type exposes to userspace the SRAM area as a DMA-BUF > Heap, > this allows for allocations of DMA-BUFs that can be consumed by various > DMA-BUF supporting devices. > > Signed-off-by: Andrew Davis <afd(a)ti.com> > Tested-by: Pascal Fontain <pascal.fontain(a)bachmann.info> When sending on a patch from someone else, you too must sign off on it as per our documenation. Please read it and understand what you are agreeing to when you do that for a new version please. > --- > drivers/misc/Kconfig | 7 + > drivers/misc/Makefile | 1 + > drivers/misc/sram-dma-heap.c | 246 +++++++++++++++++++++++++++++++++++ > drivers/misc/sram.c | 6 + > drivers/misc/sram.h | 16 +++ > 5 files changed, 276 insertions(+) > create mode 100644 drivers/misc/sram-dma-heap.c > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > index 9e4ad4d61f06..e6674e913168 100644 > --- a/drivers/misc/Kconfig > +++ b/drivers/misc/Kconfig > @@ -448,6 +448,13 @@ config SRAM > config SRAM_EXEC > bool > > +config SRAM_DMA_HEAP > + bool "Export on-chip SRAM pools using DMA-Heaps" > + depends on DMABUF_HEAPS && SRAM > + help > + This driver allows the export of on-chip SRAM marked as both pool > + and exportable to userspace using the DMA-Heaps interface. What will use this in userspace? thanks, greg k-h

1 year, 1 month

2
2
0 0

Re: [PATCH v2] doc: dma-buf: fix grammar typo

by Christian König

Well checkpatch.pl still complained: ERROR: trailing whitespace #157: FILE: Documentation/driver-api/dma-buf.rst:80: + If llseek on dma-buf FDs isn't supported the kernel will report -ESPIPE for all^M$ That actually looks like you used a Windows line ending. I fixed it up and pushed the patch, but please take a bit more care next time. Thanks, Christian. Am 17.04.24 um 06:59 schrieb Baruch Siach: > Use 'supported' instead of 'support'. 'support' makes no sense in this > context. > > Signed-off-by: Baruch Siach <baruch(a)tkos.co.il> > --- > v2: Add commit log message (Christian König) > --- > Documentation/driver-api/dma-buf.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst > index 0c153d79ccc4..29abf1eebf9f 100644 > --- a/Documentation/driver-api/dma-buf.rst > +++ b/Documentation/driver-api/dma-buf.rst > @@ -77,7 +77,7 @@ consider though: > the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other > llseek operation will report -EINVAL. > > - If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all > + If llseek on dma-buf FDs isn't supported the kernel will report -ESPIPE for all > cases. Userspace can use this to detect support for discovering the dma-buf > size using llseek. >

1 year, 1 month

1
0
0 0

Re: [PATCH v5 1/9] drm/mediatek/uapi: Add DRM_MTK_GEM_CREATE_ENCRYPTED flag

by Nicolas Dufresne

Hi, Le mercredi 03 avril 2024 à 18:26 +0800, Shawn Sung a écrit : > From: "Jason-JH.Lin" <jason-jh.lin(a)mediatek.com> > > Add DRM_MTK_GEM_CREATE_ENCRYPTED flag to allow user to allocate Is "ENCRYPTED" a proper naming ? My expectation is that this would hold data in a PROTECTED memory region but that no cryptographic algorithm will be involved. Nicolas > a secure buffer to support secure video path feature. > > Signed-off-by: Jason-JH.Lin <jason-jh.lin(a)mediatek.com> > Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.com> > --- > include/uapi/drm/mediatek_drm.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/uapi/drm/mediatek_drm.h b/include/uapi/drm/mediatek_drm.h > index b0dea00bacbc4..e9125de3a24ad 100644 > --- a/include/uapi/drm/mediatek_drm.h > +++ b/include/uapi/drm/mediatek_drm.h > @@ -54,6 +54,7 @@ struct drm_mtk_gem_map_off { > > #define DRM_MTK_GEM_CREATE 0x00 > #define DRM_MTK_GEM_MAP_OFFSET 0x01 > +#define DRM_MTK_GEM_CREATE_ENCRYPTED 0x02 > > #define DRM_IOCTL_MTK_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + \ > DRM_MTK_GEM_CREATE, struct drm_mtk_gem_create)

1 year, 1 month

2
1
0 0

Re: [PATCH] dma-buf: Do not build debugfs related code when !CONFIG_DEBUG_FS

by Maíra Canal

Hi Tvrtko, On 4/1/24 10:21, Tvrtko Ursulin wrote: > > On 01/04/2024 13:45, Christian König wrote: >> Am 01.04.24 um 14:39 schrieb Tvrtko Ursulin: >>> >>> On 29/03/2024 00:00, T.J. Mercier wrote: >>>> On Thu, Mar 28, 2024 at 7:53 AM Tvrtko Ursulin <tursulin(a)igalia.com> >>>> wrote: >>>>> >>>>> From: Tvrtko Ursulin <tursulin(a)ursulin.net> >>>>> >>>>> There is no point in compiling in the list and mutex operations >>>>> which are >>>>> only used from the dma-buf debugfs code, if debugfs is not compiled >>>>> in. >>>>> >>>>> Put the code in questions behind some kconfig guards and so save >>>>> some text >>>>> and maybe even a pointer per object at runtime when not enabled. >>>>> >>>>> Signed-off-by: Tvrtko Ursulin <tursulin(a)ursulin.net> >>>> >>>> Reviewed-by: T.J. Mercier <tjmercier(a)google.com> >>> >>> Thanks! >>> >>> How would patches to dma-buf be typically landed? Via what tree I >>> mean? drm-misc-next? >> >> That should go through drm-misc-next. >> >> And feel free to add Reviewed-by: Christian König >> <christian.koenig(a)amd.com> as well. > > Thanks! > > Maarten if I got it right you are handling the next drm-misc-next pull - > could you merge this one please? Applied to drm-misc/drm-misc-next! Best Regards, - Maíra > > Regards, > > Tvrtko

1 year, 1 month

1
0
0 0

Re: [PATCH] doc: dma-buf: fix grammar typo

by Christian König

Am 14.04.24 um 15:07 schrieb Baruch Siach: > Signed-off-by: Baruch Siach <baruch(a)tkos.co.il> > --- > Documentation/driver-api/dma-buf.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst > index 0c153d79ccc4..29abf1eebf9f 100644 > --- a/Documentation/driver-api/dma-buf.rst > +++ b/Documentation/driver-api/dma-buf.rst > @@ -77,7 +77,7 @@ consider though: > the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other > llseek operation will report -EINVAL. > > - If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all > + If llseek on dma-buf FDs isn't supported the kernel will report -ESPIPE for all Looks valid of hand, but checkpatch.pl complains about 2 errors (missing commit message for example) and a warning. Please fix and resend. Thanks, Christian. > cases. Userspace can use this to detect support for discovering the dma-buf > size using llseek. >

1 year, 1 month

1
0
0 0

Re: [PATCH net-next v9 0/3] Add minimal XDP support to TI AM65 CPSW Ethernet driver

by patchwork-bot+netdevbpf＠kernel.org

Hello: This series was applied to netdev/net-next.git (main) by David S. Miller <davem(a)davemloft.net>: On Fri, 12 Apr 2024 17:38:31 +0200 you wrote: > This patch adds XDP support to TI AM65 CPSW Ethernet driver. > > The following features are implemented: NETDEV_XDP_ACT_BASIC, > NETDEV_XDP_ACT_REDIRECT, and NETDEV_XDP_ACT_NDO_XMIT. > > Zero-copy and non-linear XDP buffer supports are NOT implemented. > > [...] Here is the summary with links: - [net-next,v9,1/3] net: ethernet: ti: Add accessors for struct k3_cppi_desc_pool members https://git.kernel.org/netdev/net-next/c/cd8ff81f747f - [net-next,v9,2/3] net: ethernet: ti: Add desc_infos member to struct k3_cppi_desc_pool https://git.kernel.org/netdev/net-next/c/84d767a3c0b5 - [net-next,v9,3/3] net: ethernet: ti: am65-cpsw: Add minimal XDP support https://git.kernel.org/netdev/net-next/c/8acacc40f733 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html

1 year, 1 month

1
0
0 0

Re: [PATCH] dmabuf: fix dmabuf file poll uaf issue

by Christian König

Am 15.04.24 um 12:35 schrieb zhiguojiang: > 在 2024/4/12 14:39, Christian König 写道: >> [Some people who received this message don't often get email from >> christian.koenig(a)amd.com. Learn why this is important at >> https://aka.ms/LearnAboutSenderIdentification ] >> >> Am 12.04.24 um 08:19 schrieb zhiguojiang: >>> [SNIP] >>> -> Here task 2220 do epoll again where internally it will get/put then >>> start to free twice and lead to final crash. >>> >>> Here is the basic flow: >>> >>> 1. Thread A install the dma_buf_fd via dma_buf_export, the fd refcount >>> is 1 >>> >>> 2. Thread A add the fd to epoll list via epoll_ctl(EPOLL_CTL_ADD) >>> >>> 3. After use the dma buf, Thread A close the fd, then here fd refcount >>> is 0, >>> and it will run __fput finally to release the file >> >> Stop, that isn't correct. >> >> The fs layer which calls dma_buf_poll() should make sure that the file >> can't go away until the function returns. >> >> Then inside dma_buf_poll() we add another reference to the file while >> installing the callback: >> >> /* Paired with fput in dma_buf_poll_cb */ >> get_file(dmabuf->file); > Hi, > > The problem may just occurred here. > > Is it possible file reference count already decreased to 0 and fput > already being in progressing just before calling > get_file(dmabuf->file) in dma_buf_poll()? No, exactly that isn't possible. If a function gets a dma_buf pointer or even more general any reference counted pointer which has already decreased to 0 then that is a major bug in the caller of that function. BTW: It's completely illegal to work around such issues by using file_count() or RCU functions. So when you suggest stuff like that it will immediately face rejection. Regards, Christian. > >> >> This reference is only dropped after the callback is completed in >> dma_buf_poll_cb(): >> >> /* Paired with get_file in dma_buf_poll */ >> fput(dmabuf->file); >> >> So your explanation for the issue just seems to be incorrect. >> >>> >>> 4. Here Thread A not do epoll_ctl(EPOLL_CTL_DEL) manunally, so it >>> still resides in one epoll_list. >>> Although __fput will call eventpoll_release to remove the file from >>> binded epoll list, >>> but it has small time window where Thread B jumps in. >> >> Well if that is really the case then that would then be a bug in >> epoll_ctl(). >> >>> >>> 5. During the small window, Thread B do the poll action for >>> dma_buf_fd, where it will fget/fput for the file, >>> this means the fd refcount will be 0 -> 1 -> 0, and it will call >>> __fput again. >>> This will lead to __fput twice for the same file. >>> >>> 6. So the potenial fix is use get_file_rcu which to check if file >>> refcount already zero which means under free. >>> If so, we just return and no need to do the dma_buf_poll. >> >> Well to say it bluntly as far as I can see this suggestion is completely >> nonsense. >> >> When the reference to the file goes away while dma_buf_poll() is >> executed then that's a massive bug in the caller of that function. >> >> Regards, >> Christian. >> >>> >>> Here is the race condition: >>> >>> Thread A Thread B >>> dma_buf_export >>> fd_refcount is 1 >>> epoll_ctl(EPOLL_ADD) >>> add dma_buf_fd to epoll list >>> close(dma_buf_fd) >>> fd_refcount is 0 >>> __fput >>> dma_buf_poll >>> fget >>> fput >>> fd_refcount is zero again >>> >>> Thanks >>> >> >

1 year, 1 month

1
0
0 0

Re: [PATCH v5 2/9] drm/mediatek: Add secure buffer control flow to mtk_drm_gem

by Maxime Ripard

On Wed, Apr 03, 2024 at 06:26:54PM +0800, Shawn Sung wrote: > From: "Jason-JH.Lin" <jason-jh.lin(a)mediatek.com> > > Add secure buffer control flow to mtk_drm_gem. > > When user space takes DRM_MTK_GEM_CREATE_ENCRYPTED flag and size > to create a mtk_drm_gem object, mtk_drm_gem will find a matched size > dma buffer from secure dma-heap and bind it to mtk_drm_gem object. > > Signed-off-by: Jason-JH.Lin <jason-jh.lin(a)mediatek.com> > Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.com> > --- > drivers/gpu/drm/mediatek/mtk_gem.c | 85 +++++++++++++++++++++++++++++- > drivers/gpu/drm/mediatek/mtk_gem.h | 4 ++ > 2 files changed, 88 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/mediatek/mtk_gem.c b/drivers/gpu/drm/mediatek/mtk_gem.c > index e59e0727717b7..ec34d02c14377 100644 > --- a/drivers/gpu/drm/mediatek/mtk_gem.c > +++ b/drivers/gpu/drm/mediatek/mtk_gem.c > @@ -4,6 +4,8 @@ > */ > > #include <linux/dma-buf.h> > +#include <linux/dma-heap.h> > +#include <uapi/linux/dma-heap.h> > #include <drm/mediatek_drm.h> > > #include <drm/drm.h> > @@ -102,6 +104,81 @@ struct mtk_gem_obj *mtk_gem_create(struct drm_device *dev, > return ERR_PTR(ret); > } > > +struct mtk_gem_obj *mtk_gem_create_from_heap(struct drm_device *dev, > + const char *heap, size_t size) > +{ > + struct mtk_drm_private *priv = dev->dev_private; > + struct mtk_gem_obj *mtk_gem; > + struct drm_gem_object *obj; > + struct dma_heap *dma_heap; > + struct dma_buf *dma_buf; > + struct dma_buf_attachment *attach; > + struct sg_table *sgt; > + struct iosys_map map = {}; > + int ret; > + > + mtk_gem = mtk_gem_init(dev, size); > + if (IS_ERR(mtk_gem)) > + return ERR_CAST(mtk_gem); > + > + obj = &mtk_gem->base; > + > + dma_heap = dma_heap_find(heap); > + if (!dma_heap) { > + DRM_ERROR("heap find fail\n"); > + goto err_gem_free; > + } > + dma_buf = dma_heap_buffer_alloc(dma_heap, size, > + O_RDWR | O_CLOEXEC, DMA_HEAP_VALID_HEAP_FLAGS); > + if (IS_ERR(dma_buf)) { > + DRM_ERROR("buffer alloc fail\n"); > + dma_heap_put(dma_heap); > + goto err_gem_free; > + } > + dma_heap_put(dma_heap); > + > + attach = dma_buf_attach(dma_buf, priv->dma_dev); > + if (IS_ERR(attach)) { > + DRM_ERROR("attach fail, return\n"); > + dma_buf_put(dma_buf); > + goto err_gem_free; > + } > + > + sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL); > + if (IS_ERR(sgt)) { > + DRM_ERROR("map failed, detach and return\n"); > + dma_buf_detach(dma_buf, attach); > + dma_buf_put(dma_buf); > + goto err_gem_free; > + } > + obj->import_attach = attach; > + mtk_gem->dma_addr = sg_dma_address(sgt->sgl); > + mtk_gem->sg = sgt; > + mtk_gem->size = dma_buf->size; > + > + if (!strcmp(heap, "mtk_svp") || !strcmp(heap, "mtk_svp_cma")) { > + /* secure buffer can not be mapped */ > + mtk_gem->secure = true; > + } else { > + ret = dma_buf_vmap(dma_buf, &map); > + mtk_gem->kvaddr = map.vaddr; > + if (ret) { > + DRM_ERROR("map failed, ret=%d\n", ret); > + dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL); > + dma_buf_detach(dma_buf, attach); > + dma_buf_put(dma_buf); > + mtk_gem->kvaddr = NULL; > + } > + } > + > + return mtk_gem; > + > +err_gem_free: > + drm_gem_object_release(obj); > + kfree(mtk_gem); > + return ERR_PTR(-ENOMEM); > +} > + > void mtk_gem_free_object(struct drm_gem_object *obj) > { > struct mtk_gem_obj *mtk_gem = to_mtk_gem_obj(obj); > @@ -229,7 +306,9 @@ struct drm_gem_object *mtk_gem_prime_import_sg_table(struct drm_device *dev, > if (IS_ERR(mtk_gem)) > return ERR_CAST(mtk_gem); > > + mtk_gem->secure = !sg_page(sg->sgl); > mtk_gem->dma_addr = sg_dma_address(sg->sgl); > + mtk_gem->size = attach->dmabuf->size; > mtk_gem->sg = sg; > > return &mtk_gem->base; > @@ -304,7 +383,11 @@ int mtk_gem_create_ioctl(struct drm_device *dev, void *data, > struct drm_mtk_gem_create *args = data; > int ret; > > - mtk_gem = mtk_gem_create(dev, args->size, false); > + if (args->flags & DRM_MTK_GEM_CREATE_ENCRYPTED) > + mtk_gem = mtk_gem_create_from_heap(dev, "mtk_svp_cma", args->size); That heap doesn't exist upstream either. Also, I'm wondering if it's the right solution there. From what I can tell, you want to allow to create encrypted buffers from the TEE. Why do we need this as a DRM ioctl at all? A heap seems like the perfect solution to do so, and then you just have to import it into DRM. I'm also not entirely sure that not having a SG list is enough to consider the buffer secure. Wouldn't a buffer allocated without a kernel mapping also be in that situation? Maxime

1 year, 1 month

1
0
0 0

Re: [PATCH v5 1/9] drm/mediatek/uapi: Add DRM_MTK_GEM_CREATE_ENCRYPTED flag

by Maxime Ripard

Hi, On Wed, Apr 03, 2024 at 06:26:53PM +0800, Shawn Sung wrote: > From: "Jason-JH.Lin" <jason-jh.lin(a)mediatek.com> > > Add DRM_MTK_GEM_CREATE_ENCRYPTED flag to allow user to allocate > a secure buffer to support secure video path feature. > > Signed-off-by: Jason-JH.Lin <jason-jh.lin(a)mediatek.com> > Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.com> > --- > include/uapi/drm/mediatek_drm.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/uapi/drm/mediatek_drm.h b/include/uapi/drm/mediatek_drm.h > index b0dea00bacbc4..e9125de3a24ad 100644 > --- a/include/uapi/drm/mediatek_drm.h > +++ b/include/uapi/drm/mediatek_drm.h > @@ -54,6 +54,7 @@ struct drm_mtk_gem_map_off { > > #define DRM_MTK_GEM_CREATE 0x00 > #define DRM_MTK_GEM_MAP_OFFSET 0x01 > +#define DRM_MTK_GEM_CREATE_ENCRYPTED 0x02 > > #define DRM_IOCTL_MTK_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + \ > DRM_MTK_GEM_CREATE, struct drm_mtk_gem_create) That flag doesn't exist in drm-misc-next, which tree is this based on? Maxime

1 year, 1 month

1
0
0 0

Re: [PATCH v3 01/18] ASoC: dt-bindings: mediatek,mt8365-afe: Add audio afe document

by Krzysztof Kozlowski

On 10/04/2024 11:29, Alexandre Mergnat wrote: > > > On 09/04/2024 17:46, Krzysztof Kozlowski wrote: >>> + soc { >>> + #address-cells = <2>; >>> + #size-cells = <2>; >>> + >>> + afe@11220000 { >> Did you implement the comment or decided to keep afe? >> > > Though it was clear according to [1]: > " > Audio Front End, this is the same name used for other MTK SoC, to be > consistent. > > Cook a new patch serie to change "afe" by "audio-controller" for all MTK > SoC would be great. > " > > I want to keep it and fix it later with ALL other MTK SoC. > You didn't answer after that, I though it was ok for you... Then no, I don't agree. If you add code, which you already plan to fix, it means the code is not correct somehow. Then just add correct code in the beginning. Best regards, Krzysztof

1 year, 1 month

1
0
0 0

Re: [PATCH] dmabuf: fix dmabuf file poll uaf issue

by Christian König

Am 12.04.24 um 08:19 schrieb zhiguojiang: > [SNIP] > -> Here task 2220 do epoll again where internally it will get/put then > start to free twice and lead to final crash. > > Here is the basic flow: > > 1. Thread A install the dma_buf_fd via dma_buf_export, the fd refcount > is 1 > > 2. Thread A add the fd to epoll list via epoll_ctl(EPOLL_CTL_ADD) > > 3. After use the dma buf, Thread A close the fd, then here fd refcount > is 0, > and it will run __fput finally to release the file Stop, that isn't correct. The fs layer which calls dma_buf_poll() should make sure that the file can't go away until the function returns. Then inside dma_buf_poll() we add another reference to the file while installing the callback: /* Paired with fput in dma_buf_poll_cb */ get_file(dmabuf->file); This reference is only dropped after the callback is completed in dma_buf_poll_cb(): /* Paired with get_file in dma_buf_poll */ fput(dmabuf->file); So your explanation for the issue just seems to be incorrect. > > 4. Here Thread A not do epoll_ctl(EPOLL_CTL_DEL) manunally, so it > still resides in one epoll_list. > Although __fput will call eventpoll_release to remove the file from > binded epoll list, > but it has small time window where Thread B jumps in. Well if that is really the case then that would then be a bug in epoll_ctl(). > > 5. During the small window, Thread B do the poll action for > dma_buf_fd, where it will fget/fput for the file, > this means the fd refcount will be 0 -> 1 -> 0, and it will call > __fput again. > This will lead to __fput twice for the same file. > > 6. So the potenial fix is use get_file_rcu which to check if file > refcount already zero which means under free. > If so, we just return and no need to do the dma_buf_poll. Well to say it bluntly as far as I can see this suggestion is completely nonsense. When the reference to the file goes away while dma_buf_poll() is executed then that's a massive bug in the caller of that function. Regards, Christian. > > Here is the race condition: > > Thread A Thread B > dma_buf_export > fd_refcount is 1 > epoll_ctl(EPOLL_ADD) > add dma_buf_fd to epoll list > close(dma_buf_fd) > fd_refcount is 0 > __fput > dma_buf_poll > fget > fput > fd_refcount is zero again > > Thanks >

1 year, 1 month

1
0
0 0

Re: [PATCH] dma-buf: add DMA_BUF_IOCTL_SYNC_PARTIAL support

by T.J. Mercier

On Thu, Apr 11, 2024 at 1:21 AM Rong Qianfeng <11065417(a)vivo.com> wrote: > > > 在 2024/4/10 0:37, T.J. Mercier 写道: > > [You don't often get email from tjmercier(a)google.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > > > On Tue, Apr 9, 2024 at 12:34 AM Rong Qianfeng <11065417(a)vivo.com> wrote: > >> > >> 在 2024/4/8 15:58, Christian König 写道: > >>> Am 07.04.24 um 09:50 schrieb Rong Qianfeng: > >>>> [SNIP] > >>>>> Am 13.11.21 um 07:22 schrieb Jianqun Xu: > >>>>>> Add DMA_BUF_IOCTL_SYNC_PARTIAL support for user to sync dma-buf with > >>>>>> offset and len. > >>>>> You have not given an use case for this so it is a bit hard to > >>>>> review. And from the existing use cases I don't see why this should > >>>>> be necessary. > >>>>> > >>>>> Even worse from the existing backend implementation I don't even see > >>>>> how drivers should be able to fulfill this semantics. > >>>>> > >>>>> Please explain further, > >>>>> Christian. > >>>> Here is a practical case: > >>>> The user space can allocate a large chunk of dma-buf for > >>>> self-management, used as a shared memory pool. > >>>> Small dma-buf can be allocated from this shared memory pool and > >>>> released back to it after use, thus improving the speed of dma-buf > >>>> allocation and release. > >>>> Additionally, custom functionalities such as memory statistics and > >>>> boundary checking can be implemented in the user space. > >>>> Of course, the above-mentioned functionalities require the > >>>> implementation of a partial cache sync interface. > >>> Well that is obvious, but where is the code doing that? > >>> > >>> You can't send out code without an actual user of it. That will > >>> obviously be rejected. > >>> > >>> Regards, > >>> Christian. > >> In fact, we have already used the user-level dma-buf memory pool in the > >> camera shooting scenario on the phone. > >> > >> From the test results, The execution time of the photo shooting > >> algorithm has been reduced from 3.8s to 3s. > >> > > For phones, the (out of tree) Android version of the system heap has a > > page pool connected to a shrinker. That allows you to skip page > > allocation without fully pinning the memory like you get when > > allocating a dma-buf that's way larger than necessary. If it's for a > > camera maybe you need physically contiguous memory, but it's also > > possible to set that up. > > > > https://android.googlesource.com/kernel/common/+/refs/heads/android14-6.1/d… > > > Thank you for the reminder. > > The page pool of the system heap can meet the needs of most scenarios, > but the camera shooting scenario is quite special. > > Why the camera shooting scenario needs to have a dma-buf memory pool in > the user-level？ > > (1) The memory demand is extremely high and time requirements are > stringent. Preallocating for this makes sense to me, whether it is individual buffers or one large one. > (2) The memory in the page pool(system heap) is easily reclaimed or used > by other apps. Yeah, by design I guess. I have seen an implementation where the page pool is proactively refilled after it has been empty for some time which would help in scenarios where the pool is often reclaimed and low/empty. You could add that in a vendor heap. > (3) High concurrent allocation and release (with deferred-free) lead to > high memory usage peaks. Hopefully this is not every frame? I saw enough complaints about the deferred free of pool pages that it hasn't been carried forward since Android 13, so this should be less of a problem on recent kernels. > Additionally, after the camera exits, the shared memory pool can be > released, with minimal impact. Why do you care about the difference here? In one case it's when the buffer refcount goes to 0 and memory is freed immediately, and in the other it's the next time reclaim runs the shrinker. I don't want to add UAPI for DMA_BUF_IOCTL_SYNC_PARTIAL to Android without it being in the upstream kernel. I don't think we can get that without an in-kernel user of dma_buf_begin_cpu_access_partial first, even though your use case wouldn't rely on that in-kernel usage. :\ So if you want to add this to phones for your camera app, then I think your best option is to add a vendor driver which implements this IOCTL and calls the dma_buf_begin_cpu_access_partial functions which are already exported. Best, T.J.

1 year, 1 month

1
0
0 0

Re: [PATCH] dma-buf: add DMA_BUF_IOCTL_SYNC_PARTIAL support

by T.J. Mercier

On Tue, Apr 9, 2024 at 12:34 AM Rong Qianfeng <11065417(a)vivo.com> wrote: > > > 在 2024/4/8 15:58, Christian König 写道: > > Am 07.04.24 um 09:50 schrieb Rong Qianfeng: > >> [SNIP] > >>> Am 13.11.21 um 07:22 schrieb Jianqun Xu: > >>>> Add DMA_BUF_IOCTL_SYNC_PARTIAL support for user to sync dma-buf with > >>>> offset and len. > >>> > >>> You have not given an use case for this so it is a bit hard to > >>> review. And from the existing use cases I don't see why this should > >>> be necessary. > >>> > >>> Even worse from the existing backend implementation I don't even see > >>> how drivers should be able to fulfill this semantics. > >>> > >>> Please explain further, > >>> Christian. > >> Here is a practical case: > >> The user space can allocate a large chunk of dma-buf for > >> self-management, used as a shared memory pool. > >> Small dma-buf can be allocated from this shared memory pool and > >> released back to it after use, thus improving the speed of dma-buf > >> allocation and release. > >> Additionally, custom functionalities such as memory statistics and > >> boundary checking can be implemented in the user space. > >> Of course, the above-mentioned functionalities require the > >> implementation of a partial cache sync interface. > > > > Well that is obvious, but where is the code doing that? > > > > You can't send out code without an actual user of it. That will > > obviously be rejected. > > > > Regards, > > Christian. > > In fact, we have already used the user-level dma-buf memory pool in the > camera shooting scenario on the phone. > > From the test results, The execution time of the photo shooting > algorithm has been reduced from 3.8s to 3s. > For phones, the (out of tree) Android version of the system heap has a page pool connected to a shrinker. That allows you to skip page allocation without fully pinning the memory like you get when allocating a dma-buf that's way larger than necessary. If it's for a camera maybe you need physically contiguous memory, but it's also possible to set that up. https://android.googlesource.com/kernel/common/+/refs/heads/android14-6.1/d… > To be honest, I didn't understand your concern "...how drivers should be > able to fulfill this semantics." Can you please help explain it in more > detail? > > Thanks, > > Rong Qianfeng. > > > > >> > >> Thanks > >> Rong Qianfeng. > > >

1 year, 1 month

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig