Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

9 participants
3131 discussions

Deploying new iterator interface for dma-buf

by Christian König

Hi guys, a few more bug fixes, looks like the more selftests I add the more odies I find. Assuming the CI tests now pass I will start pushing patches I've already got an rb for to drm-misc-next. Please review and/or comment, Christian.

4 years

Re: [Linaro-mm-sig] [PATCH v3] dma-buf: remove restriction of IOCTL:DMA_BUF_SET_NAME

by Christian König

Am 26.10.21 um 13:52 schrieb guangming.cao(a)mediatek.com: > From: Guangming Cao <Guangming.Cao(a)mediatek.com> > > On Tue, 2021-10-26 at 13:18 +0200, Christian König wrote: >> Am 14.10.21 um 12:25 schrieb guangming.cao(a)mediatek.com: >>> From: Guangming Cao <Guangming.Cao(a)mediatek.com> >>> >>> In this patch(https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat…;reserved=0), >>> it add a new IOCTL to support dma-buf user to set debug name. >>> >>> But it also added a limitation of this IOCTL, it needs the >>> attachments of dmabuf should be empty, otherwise it will fail. >>> >>> For the original series, the idea was that allowing name change >>> mid-use could confuse the users about the dma-buf. >>> However, the rest of the series also makes sure each dma-buf have a >>> unique >>> inode(https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat…;reserved=0), and any >>> accounting >>> should probably use that, without relying on the name as much. >>> >>> So, removing this restriction will let dma-buf userspace users to >>> use it >>> more comfortably and without any side effect. >>> >>> Signed-off-by: Guangming Cao <Guangming.Cao(a)mediatek.com> >> We could now cleanup the return value from dma_buf_set_name() into a >> void since that function can't fail any more as far as I can see. >> >> But that isn't mandatory I think, patch is Reviewed-by: Christian >> König >> <christian.koenig(a)amd.com> >> > So, here is no need to check return value of 'strndup_user', > just return without error code if the almost impossible error occurs? Good point, totally missed that one. In that case I'm going to push the patch to drm-misc-next as is. Regards, Christian. > > Guangming. > >> Regards, >> Christian. >> >>> --- >>> drivers/dma-buf/dma-buf.c | 17 +++-------------- >>> 1 file changed, 3 insertions(+), 14 deletions(-) >>> >>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c >>> index 511fe0d217a0..5fbb3a2068a3 100644 >>> --- a/drivers/dma-buf/dma-buf.c >>> +++ b/drivers/dma-buf/dma-buf.c >>> @@ -325,10 +325,8 @@ static __poll_t dma_buf_poll(struct file >>> *file, poll_table *poll) >>> >>> /** >>> * dma_buf_set_name - Set a name to a specific dma_buf to track >>> the usage. >>> - * The name of the dma-buf buffer can only be set when the dma-buf >>> is not >>> - * attached to any devices. It could theoritically support >>> changing the >>> - * name of the dma-buf if the same piece of memory is used for >>> multiple >>> - * purpose between different devices. >>> + * It could support changing the name of the dma-buf if the same >>> + * piece of memory is used for multiple purpose between different >>> devices. >>> * >>> * @dmabuf: [in] dmabuf buffer that will be renamed. >>> * @buf: [in] A piece of userspace memory that contains >>> the name of >>> @@ -341,25 +339,16 @@ static __poll_t dma_buf_poll(struct file >>> *file, poll_table *poll) >>> static long dma_buf_set_name(struct dma_buf *dmabuf, const char >>> __user *buf) >>> { >>> char *name = strndup_user(buf, DMA_BUF_NAME_LEN); >>> - long ret = 0; >>> >>> if (IS_ERR(name)) >>> return PTR_ERR(name); >>> >>> - dma_resv_lock(dmabuf->resv, NULL); >>> - if (!list_empty(&dmabuf->attachments)) { >>> - ret = -EBUSY; >>> - kfree(name); >>> - goto out_unlock; >>> - } >>> spin_lock(&dmabuf->name_lock); >>> kfree(dmabuf->name); >>> dmabuf->name = name; >>> spin_unlock(&dmabuf->name_lock); >>> >>> -out_unlock: >>> - dma_resv_unlock(dmabuf->resv); >>> - return ret; >>> + return 0; >>> } >>> >>> static long dma_buf_ioctl(struct file *file, >>

4 years

Re: [Linaro-mm-sig] [PATCH v3] dma-buf: remove restriction of IOCTL:DMA_BUF_SET_NAME

by Christian König

Am 14.10.21 um 12:25 schrieb guangming.cao(a)mediatek.com: > From: Guangming Cao <Guangming.Cao(a)mediatek.com> > > In this patch(https://patchwork.freedesktop.org/patch/310349), > it add a new IOCTL to support dma-buf user to set debug name. > > But it also added a limitation of this IOCTL, it needs the > attachments of dmabuf should be empty, otherwise it will fail. > > For the original series, the idea was that allowing name change > mid-use could confuse the users about the dma-buf. > However, the rest of the series also makes sure each dma-buf have a unique > inode(https://patchwork.freedesktop.org/patch/310387/), and any accounting > should probably use that, without relying on the name as much. > > So, removing this restriction will let dma-buf userspace users to use it > more comfortably and without any side effect. > > Signed-off-by: Guangming Cao <Guangming.Cao(a)mediatek.com> We could now cleanup the return value from dma_buf_set_name() into a void since that function can't fail any more as far as I can see. But that isn't mandatory I think, patch is Reviewed-by: Christian König <christian.koenig(a)amd.com> Regards, Christian. > --- > drivers/dma-buf/dma-buf.c | 17 +++-------------- > 1 file changed, 3 insertions(+), 14 deletions(-) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 511fe0d217a0..5fbb3a2068a3 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -325,10 +325,8 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) > > /** > * dma_buf_set_name - Set a name to a specific dma_buf to track the usage. > - * The name of the dma-buf buffer can only be set when the dma-buf is not > - * attached to any devices. It could theoritically support changing the > - * name of the dma-buf if the same piece of memory is used for multiple > - * purpose between different devices. > + * It could support changing the name of the dma-buf if the same > + * piece of memory is used for multiple purpose between different devices. > * > * @dmabuf: [in] dmabuf buffer that will be renamed. > * @buf: [in] A piece of userspace memory that contains the name of > @@ -341,25 +339,16 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) > static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf) > { > char *name = strndup_user(buf, DMA_BUF_NAME_LEN); > - long ret = 0; > > if (IS_ERR(name)) > return PTR_ERR(name); > > - dma_resv_lock(dmabuf->resv, NULL); > - if (!list_empty(&dmabuf->attachments)) { > - ret = -EBUSY; > - kfree(name); > - goto out_unlock; > - } > spin_lock(&dmabuf->name_lock); > kfree(dmabuf->name); > dmabuf->name = name; > spin_unlock(&dmabuf->name_lock); > > -out_unlock: > - dma_resv_unlock(dmabuf->resv); > - return ret; > + return 0; > } > > static long dma_buf_ioctl(struct file *file,

4 years

Re: [Linaro-mm-sig] [PATCH] dma-buf: st: fix error handling in test_get_fences()

by Christian König

Am 26.10.21 um 10:34 schrieb Arnd Bergmann: > From: Arnd Bergmann <arnd(a)arndb.de> > > The new driver incorrectly unwinds after errors, as clang points out: > > drivers/dma-buf/st-dma-resv.c:295:7: error: variable 'i' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] > if (r) { > ^ > drivers/dma-buf/st-dma-resv.c:336:9: note: uninitialized use occurs here > while (i--) > ^ > drivers/dma-buf/st-dma-resv.c:295:3: note: remove the 'if' if its condition is always false > if (r) { > ^~~~~~~~ > drivers/dma-buf/st-dma-resv.c:288:6: error: variable 'i' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] > if (r) { > ^ > drivers/dma-buf/st-dma-resv.c:336:9: note: uninitialized use occurs here > while (i--) > ^ > drivers/dma-buf/st-dma-resv.c:288:2: note: remove the 'if' if its condition is always false > if (r) { > ^~~~~~~~ > drivers/dma-buf/st-dma-resv.c:280:10: note: initialize the variable 'i' to silence this warning > int r, i; > ^ > = 0 > > Skip cleaning up the bits that have not been allocated at this point. > > Fixes: 1d51775cd3f5 ("dma-buf: add dma_resv selftest v4") > Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> I already send out a patch to fix this up, but forgot to fix both gotos. Going to add my rb and using that one here instead. Thanks, Christian. > --- > I'm not familiar with these interfaces, so I'm just guessing where > we should jump after an error, please double-check and fix if necessary. > --- > drivers/dma-buf/st-dma-resv.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/dma-buf/st-dma-resv.c b/drivers/dma-buf/st-dma-resv.c > index 6f3ba756da3e..bc32b3eedcb6 100644 > --- a/drivers/dma-buf/st-dma-resv.c > +++ b/drivers/dma-buf/st-dma-resv.c > @@ -287,7 +287,7 @@ static int test_get_fences(void *arg, bool shared) > r = dma_resv_lock(&resv, NULL); > if (r) { > pr_err("Resv locking failed\n"); > - goto err_free; > + goto err_resv; > } > > if (shared) { > @@ -295,7 +295,7 @@ static int test_get_fences(void *arg, bool shared) > if (r) { > pr_err("Resv shared slot allocation failed\n"); > dma_resv_unlock(&resv); > - goto err_free; > + goto err_resv; > } > > dma_resv_add_shared_fence(&resv, f); > @@ -336,6 +336,7 @@ static int test_get_fences(void *arg, bool shared) > while (i--) > dma_fence_put(fences[i]); > kfree(fences); > +err_resv: > dma_resv_fini(&resv); > dma_fence_put(f); > return r;

4 years

Re: [Linaro-mm-sig] [RFC 06/13] soc: mediatek: apu: Add apu core driver

by Randy Dunlap

Hi, On 10/23/21 4:14 AM, Flora Fu wrote: > diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig > index d9bac2710494..074b0cf24c44 100644 > --- a/drivers/soc/mediatek/Kconfig > +++ b/drivers/soc/mediatek/Kconfig > @@ -24,6 +24,24 @@ config MTK_APU_PM > APU power domain shall be enabled before accessing the > internal sub modules. > > +config MTK_APU > + tristate "MediaTek APUSYS Support" > + select REGMAP > + select MTK_APU_PM > + select MTK_SCP > + help > + Say yes here to add support for the APU tinysys. The tinsys is tinysys runs on > + running on a micro processor in APU. a microprocessor in the APU. > + Its firmware is load and boot from Kernel side. Kernel and tinysys use is loaded and booted > + IPI to tx/rx messages. to send/receive messages. > + > +config MTK_APU_DEBUG > + tristate "MediaTek APUSYS debug functions" > + depends on MTK_APU > + help > + Say yes here to enalbe debug on APUSYS. enable > + Disable it if you don't need them. -- ~Randy

4 years

[PATCH 0/2] dma-buf: Fix breakages from dma_resv_iter conversion.

by Maarten Lankhorst

Urgent fixes! dma_resv_test_signaled is completely broken, dma_resv_wait_timeout kind of broken. Maarten Lankhorst (2): dma-buf: Fix dma_resv_wait_timeout handling of timeout = 0. dma-buf: Fix dma_resv_test_signaled. drivers/dma-buf/dma-resv.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) -- 2.33.0

4 years

Re: [Linaro-mm-sig] [PATCH] dma-buf: add attachments empty check for dma_buf_release

by Daniel Vetter

On Tue, Oct 19, 2021 at 08:23:45PM +0800, guangming.cao(a)mediatek.com wrote: > From: Guangming Cao <Guangming.Cao(a)mediatek.com> > > Since there is no mandatory inspection for attachments in dma_buf_release. > There will be a case that dma_buf already released but attachment is still > in use, which can points to the dmabuf, and it maybe cause > some unexpected issues. > > With IOMMU, when this cases occurs, there will have IOMMU address > translation fault(s) followed by this warning, > I think it's useful for dma devices to debug issue. > > Signed-off-by: Guangming Cao <Guangming.Cao(a)mediatek.com> This feels a lot like hand-rolling kobject debugging. If you want to do this then I think adding kobject debug support to dma_buf/dma_buf_attachment would be better than hand-rolling something bespoke here. Also on the patch itself: You don't need the trylock. For correctly working code non one else can get at the dma-buf, so no locking needed to iterate through the attachment list. For incorrect code the kernel will be on fire pretty soon anyway, trying to do locking won't help :-) And without the trylock we can catch more bugs (e.g. if you also forgot to unlock and not just forgot to detach). -Daniel > --- > drivers/dma-buf/dma-buf.c | 23 +++++++++++++++++++++++ > 1 file changed, 23 insertions(+) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 511fe0d217a0..672404857d6a 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -74,6 +74,29 @@ static void dma_buf_release(struct dentry *dentry) > */ > BUG_ON(dmabuf->cb_shared.active || dmabuf->cb_excl.active); > > + /* attachment check */ > + if (dma_resv_trylock(dmabuf->resv) && WARN(!list_empty(&dmabuf->attachments), > + "%s err, inode:%08lu size:%08zu name:%s exp_name:%s flags:0x%08x mode:0x%08x, %s\n", > + __func__, file_inode(dmabuf->file)->i_ino, dmabuf->size, > + dmabuf->name, dmabuf->exp_name, > + dmabuf->file->f_flags, dmabuf->file->f_mode, > + "Release dmabuf before detach all attachments, dump attach:\n")) { > + int attach_cnt = 0; > + dma_addr_t dma_addr; > + struct dma_buf_attachment *attach_obj; > + /* dump all attachment info */ > + list_for_each_entry(attach_obj, &dmabuf->attachments, node) { > + dma_addr = (dma_addr_t)0; > + if (attach_obj->sgt) > + dma_addr = sg_dma_address(attach_obj->sgt->sgl); > + pr_err("attach[%d]: dev:%s dma_addr:0x%-12lx\n", > + attach_cnt, dev_name(attach_obj->dev), dma_addr); > + attach_cnt++; > + } > + pr_err("Total %d devices attached\n\n", attach_cnt); > + dma_resv_unlock(dmabuf->resv); > + } > + > dmabuf->ops->release(dmabuf); > > if (dmabuf->resv == (struct dma_resv *)&dmabuf[1]) > -- > 2.17.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

4 years

Re: [Linaro-mm-sig] [PATCH 16/28] drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2

by Christian König

Thanks for the notice. Going to take a deeper look into this tomorrow. Basically looks like we messed up the fence ref count somehow. Thanks, Christian. Am 17.10.21 um 16:40 schrieb Nicolas Frattaroli: > On Dienstag, 5. Oktober 2021 13:37:30 CEST Christian König wrote: >> Simplifying the code a bit. >> >> v2: use dma_resv_for_each_fence >> >> Signed-off-by: Christian König <christian.koenig(a)amd.com> >> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> >> --- >> drivers/gpu/drm/scheduler/sched_main.c | 26 ++++++-------------------- >> 1 file changed, 6 insertions(+), 20 deletions(-) >> >> diff --git a/drivers/gpu/drm/scheduler/sched_main.c >> b/drivers/gpu/drm/scheduler/sched_main.c index 042c16b5d54a..5bc5f775abe1 >> 100644 >> --- a/drivers/gpu/drm/scheduler/sched_main.c >> +++ b/drivers/gpu/drm/scheduler/sched_main.c >> @@ -699,30 +699,16 @@ int drm_sched_job_add_implicit_dependencies(struct >> drm_sched_job *job, struct drm_gem_object *obj, >> bool write) >> { >> + struct dma_resv_iter cursor; >> + struct dma_fence *fence; >> int ret; >> - struct dma_fence **fences; >> - unsigned int i, fence_count; >> - >> - if (!write) { >> - struct dma_fence *fence = dma_resv_get_excl_unlocked(obj- >> resv); >> - >> - return drm_sched_job_add_dependency(job, fence); >> - } >> - >> - ret = dma_resv_get_fences(obj->resv, NULL, &fence_count, &fences); >> - if (ret || !fence_count) >> - return ret; >> >> - for (i = 0; i < fence_count; i++) { >> - ret = drm_sched_job_add_dependency(job, fences[i]); >> + dma_resv_for_each_fence(&cursor, obj->resv, write, fence) { >> + ret = drm_sched_job_add_dependency(job, fence); >> if (ret) >> - break; >> + return ret; >> } >> - >> - for (; i < fence_count; i++) >> - dma_fence_put(fences[i]); >> - kfree(fences); >> - return ret; >> + return 0; >> } >> EXPORT_SYMBOL(drm_sched_job_add_implicit_dependencies); > Hi Christian, > > unfortunately, this breaks lima on the rk3328 quite badly. Running glmark2- > es2-drm just locks up the device with the following traces: > > [ 39.624100] ------------[ cut here ]------------ > [ 39.624555] refcount_t: addition on 0; use-after-free. > [ 39.625058] WARNING: CPU: 0 PID: 123 at lib/refcount.c:25 > refcount_warn_saturate+0xa4/0x150 > [ 39.625825] Modules linked in: 8021q garp stp mrp llc crct10dif_ce > hantro_vpu(C) fuse ip_tables x_tables ipv6 > [ 39.626753] CPU: 0 PID: 123 Comm: pp Tainted: G C 5.15.0- > rc1fratti-00251-g9c2ba265352a #158 > [ 39.627614] Hardware name: Pine64 Rock64 (DT) > [ 39.628004] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > [ 39.628628] pc : refcount_warn_saturate+0xa4/0x150 > [ 39.629062] lr : refcount_warn_saturate+0xa4/0x150 > [ 39.629495] sp : ffffffc0124d3d90 > [ 39.629794] x29: ffffffc0124d3d90 x28: 0000000000000000 x27: > 0000000000000000 > [ 39.630441] x26: 0000000000000000 x25: ffffffc0117fe000 x24: > ffffff8001ad73f8 > [ 39.631087] x23: ffffffc0107fc3e0 x22: ffffffc0117fe000 x21: > ffffff8010660000 > [ 39.631731] x20: ffffff8001ad73c0 x19: ffffff807db094c8 x18: > ffffffffffffffff > [ 39.632377] x17: 0000000000000001 x16: 0000000000000001 x15: > 0765076507720766 > [ 39.633022] x14: 072d077207650774 x13: 0765076507720766 x12: > 072d077207650774 > [ 39.633668] x11: 0720072007200720 x10: ffffffc011c4b1b0 x9 : > ffffffc01010ac54 > [ 39.634314] x8 : 00000000ffffdfff x7 : ffffffc011cfb1b0 x6 : > 0000000000000001 > [ 39.634960] x5 : ffffff807fb4d980 x4 : 0000000000000000 x3 : > 0000000000000027 > [ 39.635605] x2 : 0000000000000000 x1 : 0000000000000000 x0 : > ffffff8000e1f000 > [ 39.636250] Call trace: > [ 39.636475] refcount_warn_saturate+0xa4/0x150 > [ 39.636879] drm_sched_entity_pop_job+0x414/0x4a0 > [ 39.637307] drm_sched_main+0xe4/0x450 > [ 39.637651] kthread+0x12c/0x140 > [ 39.637949] ret_from_fork+0x10/0x20 > [ 39.638279] ---[ end trace 47528e09b2512330 ]--- > [ 39.638783] ------------[ cut here ]------------ > [ 39.639214] refcount_t: underflow; use-after-free. > [ 39.639687] WARNING: CPU: 0 PID: 123 at lib/refcount.c:28 > refcount_warn_saturate+0xf8/0x150 > [ 39.640447] Modules linked in: 8021q garp stp mrp llc crct10dif_ce > hantro_vpu(C) fuse ip_tables x_tables ipv6 > [ 39.641373] CPU: 0 PID: 123 Comm: pp Tainted: G WC 5.15.0- > rc1fratti-00251-g9c2ba265352a #158 > [ 39.642237] Hardware name: Pine64 Rock64 (DT) > [ 39.642632] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > [ 39.643257] pc : refcount_warn_saturate+0xf8/0x150 > [ 39.643693] lr : refcount_warn_saturate+0xf8/0x150 > [ 39.644128] sp : ffffffc0124d3d90 > [ 39.644430] x29: ffffffc0124d3d90 x28: 0000000000000000 x27: > 0000000000000000 > [ 39.645077] x26: 0000000000000000 x25: ffffffc0117fe000 x24: > ffffff8001ad73f8 > [ 39.645724] x23: ffffffc0107fc3e0 x22: ffffffc0117fe000 x21: > ffffff8010660000 > [ 39.646372] x20: ffffff8001ad73c0 x19: ffffff807db094c8 x18: > ffffffffffffffff > [ 39.647020] x17: 0000000000000001 x16: 0000000000000001 x15: > 072007200720072e > [ 39.647666] x14: 0765076507720766 x13: 072007200720072e x12: > 0765076507720766 > [ 39.648312] x11: 0720072007200720 x10: ffffffc011c4b1b0 x9 : > ffffffc01010ac54 > [ 39.648957] x8 : 00000000ffffdfff x7 : ffffffc011cfb1b0 x6 : > 0000000000000001 > [ 39.649602] x5 : ffffff807fb4d980 x4 : 0000000000000000 x3 : > 0000000000000027 > [ 39.650247] x2 : 0000000000000000 x1 : 0000000000000000 x0 : > ffffff8000e1f000 > [ 39.650894] Call trace: > [ 39.651119] refcount_warn_saturate+0xf8/0x150 > [ 39.651526] drm_sched_entity_pop_job+0x420/0x4a0 > [ 39.651953] drm_sched_main+0xe4/0x450 > [ 39.652296] kthread+0x12c/0x140 > [ 39.652595] ret_from_fork+0x10/0x20 > [ 39.652924] ---[ end trace 47528e09b2512331 ]--- > [ 39.717053] ------------[ cut here ]------------ > [ 39.717543] refcount_t: saturated; leaking memory. > [ 39.718030] WARNING: CPU: 1 PID: 375 at lib/refcount.c:22 > refcount_warn_saturate+0x78/0x150 > [ 39.718800] Modules linked in: 8021q garp stp mrp llc crct10dif_ce > hantro_vpu(C) fuse ip_tables x_tables ipv6 > [ 39.719744] CPU: 1 PID: 375 Comm: glmark2-es2-drm Tainted: G WC > 5.15.0-rc1fratti-00251-g9c2ba265352a #158 > [ 39.720712] Hardware name: Pine64 Rock64 (DT) > [ 39.721109] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > [ 39.721739] pc : refcount_warn_saturate+0x78/0x150 > [ 39.722178] lr : refcount_warn_saturate+0x78/0x150 > [ 39.722617] sp : ffffffc012913a90 > [ 39.722921] x29: ffffffc012913a90 x28: ffffff8010630000 x27: > ffffff8005219e00 > [ 39.723576] x26: ffffff80103da500 x25: 0000000000000000 x24: > ffffff8000cb24c0 > [ 39.724230] x23: ffffff800ac045b0 x22: ffffff8005212100 x21: > 0000000000000000 > [ 39.724884] x20: ffffff8000cb24c0 x19: 0000000000000000 x18: > ffffffffffffffff > [ 39.725538] x17: 0000000000000000 x16: 0000000000000000 x15: > 072007200720072e > [ 39.726192] x14: 07790772076f076d x13: 072007200720072e x12: > 07790772076f076d > [ 39.726846] x11: 0720072007200720 x10: ffffffc011c4b1b0 x9 : > ffffffc01010ac54 > [ 39.727501] x8 : 00000000ffffdfff x7 : ffffffc011cfb1b0 x6 : > 0000000000000001 > [ 39.728155] x5 : ffffff807fb68980 x4 : 0000000000000000 x3 : > 0000000000000027 > [ 39.728808] x2 : 0000000000000000 x1 : 0000000000000000 x0 : > ffffff8004d7b800 > [ 39.729464] Call trace: > [ 39.729691] refcount_warn_saturate+0x78/0x150 > [ 39.730101] dma_resv_add_shared_fence+0x1ac/0x1cc > [ 39.730543] lima_gem_submit+0x300/0x580 > [ 39.730909] lima_ioctl_gem_submit+0x284/0x340 > [ 39.731318] drm_ioctl_kernel+0xd0/0x180 > [ 39.731685] drm_ioctl+0x220/0x450 > [ 39.732005] __arm64_sys_ioctl+0x568/0xe9c > [ 39.732386] invoke_syscall.constprop.0+0x58/0xf0 > [ 39.732824] do_el0_svc+0x138/0x170 > [ 39.733152] el0_svc+0x28/0xc0 > [ 39.733441] el0t_64_sync_handler+0xa8/0x130 > [ 39.733837] el0t_64_sync+0x1a0/0x1a4 > [ 39.734178] ---[ end trace 47528e09b2512332 ]--- > [ 39.734926] Unable to handle kernel write to read-only memory at virtual > address ffffffc0107fbc70 > [ 39.735763] Mem abort info: > [ 39.736029] ESR = 0x9600004e > [ 39.736313] EC = 0x25: DABT (current EL), IL = 32 bits > [ 39.736796] SET = 0, FnV = 0 > [ 39.737080] EA = 0, S1PTW = 0 > [ 39.737368] FSC = 0x0e: level 2 permission fault > [ 39.737804] Data abort info: > [ 39.738068] ISV = 0, ISS = 0x0000004e > [ 39.738419] CM = 0, WnR = 1 > [ 39.738693] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000003893000 > [ 39.739297] [ffffffc0107fbc70] pgd=100000007ffff003, p4d=100000007ffff003, > pud=100000007ffff003, pmd=0040000002800781 > [ 39.740270] Internal error: Oops: 9600004e [#1] SMP > [ 39.740719] Modules linked in: 8021q garp stp mrp llc crct10dif_ce > hantro_vpu(C) fuse ip_tables x_tables ipv6 > [ 39.741665] CPU: 0 PID: 123 Comm: pp Tainted: G WC 5.15.0- > rc1fratti-00251-g9c2ba265352a #158 > [ 39.742537] Hardware name: Pine64 Rock64 (DT) > [ 39.742934] pstate: 000000c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > [ 39.743570] pc : dma_fence_add_callback+0xb0/0xf0 > [ 39.744017] lr : dma_fence_add_callback+0x5c/0xf0 > [ 39.744457] sp : ffffffc0124d3d60 > [ 39.744764] x29: ffffffc0124d3d60 x28: 0000000000000000 x27: > 0000000000000000 > [ 39.745423] x26: 0000000000000000 x25: ffffffc0117fe000 x24: > ffffff800536b6e0 > [ 39.746080] x23: 0000000000000000 x22: 0000000000000000 x21: > ffffffc0107fc3e0 > [ 39.746736] x20: ffffff807db09528 x19: ffffff8000cb24c0 x18: > 0000000000000001 > [ 39.747390] x17: 000000040044ffff x16: 000000000000000c x15: > 000000000000000d > [ 39.748044] x14: 0000000000000000 x13: 000000000000072b x12: > 071c71c71c71c71c > [ 39.748697] x11: 000000000000072b x10: 0000000000000002 x9 : > ffffffc01087d5ac > [ 39.749350] x8 : 0000000000000238 x7 : 0000000000000000 x6 : > 0000000000000000 > [ 39.750002] x5 : 0000000000000000 x4 : 0000000000000000 x3 : > ffffff8000cb24f0 > [ 39.750654] x2 : 0000000000000000 x1 : ffffffc0107fbc70 x0 : > ffffff8000cb24d0 > [ 39.751309] Call trace: > [ 39.751539] dma_fence_add_callback+0xb0/0xf0 > [ 39.751944] drm_sched_entity_pop_job+0xac/0x4a0 > [ 39.752371] drm_sched_main+0xe4/0x450 > [ 39.752720] kthread+0x12c/0x140 > [ 39.753024] ret_from_fork+0x10/0x20 > [ 39.753367] Code: 91004260 f9400e61 f9000e74 a9000680 (f9000034) > [ 39.753920] ---[ end trace 47528e09b2512333 ]--- > [ 40.253374] [drm:lima_sched_timedout_job] *ERROR* lima job timeout > > I've bisected the problem to this commit, and confirmed that reverting it gets > glmark2's 3d horse back to spinning. > > It's possible this patch just uncovers a bug in lima, so I've added the lima > list as a recipient to this reply as well. > > Since I doubt AMD has many Rockchip SoCs laying about, I'll gladly test any > prospective fixes for this. > > Regards, > Nicolas Frattaroli > >

4 years

Re: [Linaro-mm-sig] [PATCH] dma-buf: Update obsoluted comments on dma_buf_vmap/vunmap()

by Christian König

Am 08.10.21 um 13:20 schrieb Shunsuke Mie: > A comment for the dma_buf_vmap/vunmap() is not catching up a > corresponding implementation. > > Signed-off-by: Shunsuke Mie <mie(a)igel.co.jp> Reviewed-by: Christian König <christian.koenig(a)amd.com> > --- > drivers/dma-buf/dma-buf.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index beb504a92d60..7b619998f03a 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -1052,8 +1052,8 @@ EXPORT_SYMBOL_GPL(dma_buf_move_notify); > * > * Interfaces:: > * > - * void \*dma_buf_vmap(struct dma_buf \*dmabuf) > - * void dma_buf_vunmap(struct dma_buf \*dmabuf, void \*vaddr) > + * void \*dma_buf_vmap(struct dma_buf \*dmabuf, struct dma_buf_map \*map) > + * void dma_buf_vunmap(struct dma_buf \*dmabuf, struct dma_buf_map \*map) > * > * The vmap call can fail if there is no vmap support in the exporter, or if > * it runs out of vmalloc space. Note that the dma-buf layer keeps a reference

4 years

Re: [Linaro-mm-sig] [PATCH v2] dma-buf: remove restriction of IOCTL:DMA_BUF_SET_NAME

by Sumit Semwal

Hello Guangming, Christian, On Tue, 12 Oct 2021, 14:09 , <guangming.cao(a)mediatek.com> wrote: > From: Guangming Cao <Guangming.Cao(a)mediatek.com> > > > Am 09.10.21 um 07:55 schrieb guangming.cao(a)mediatek.com: > > From: Guangming Cao <Guangming.Cao(a)mediatek.com> > > > > > > If dma-buf don't want userspace users to touch the dmabuf buffer, > > > it seems we should add this restriction into dma_buf_ops.mmap, > > > not in this IOCTL:DMA_BUF_SET_NAME. > > > > > > With this restriction, we can only know the kernel users of the dmabuf > > > by attachments. > > > However, for many userspace users, such as userpsace users of dma_heap, > > > they also need to mark the usage of dma-buf, and they don't care about > > > who attached to this dmabuf, and seems it's no meaning to be waiting > for > > > IOCTL:DMA_BUF_SET_NAME rather than mmap. > > > > Sounds valid to me, but I have no idea why this restriction was added in > > the first place. > > > > Can you double check the git history and maybe identify when that was > > added? Mentioning this change in the commit message then might make > > things a bit easier to understand. > > > > Thanks, > > Christian. > It was add in this patch: https://patchwork.freedesktop.org/patch/310349/. > However, there is no illustration about it. > I guess it wants users to set_name when no attachments on the dmabuf, > for case with attachments, we can find owner by device in attachments. > But just I said in commit message, this is might not a good idea. > > Do you have any idea? > For the original series, the idea was that allowing name change mid-use could confuse the users about the dma-buf. However, the rest of the series also makes sure each dma-buf have a unique inode, and any accounting should probably use that, without relying on the name as much. So I don't have an objection to this change. Best, Sumit. > > > > > > > > Signed-off-by: Guangming Cao <Guangming.Cao(a)mediatek.com> > > > --- > > > drivers/dma-buf/dma-buf.c | 14 ++------------ > > > 1 file changed, 2 insertions(+), 12 deletions(-) > > > > > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > > > index 511fe0d217a0..db2f4efdec32 100644 > > > --- a/drivers/dma-buf/dma-buf.c > > > +++ b/drivers/dma-buf/dma-buf.c > > > @@ -325,10 +325,8 @@ static __poll_t dma_buf_poll(struct file *file, > poll_table *poll) > > > > > > /** > > > * dma_buf_set_name - Set a name to a specific dma_buf to track the > usage. > > > - * The name of the dma-buf buffer can only be set when the dma-buf is > not > > > - * attached to any devices. It could theoritically support changing > the > > > - * name of the dma-buf if the same piece of memory is used for > multiple > > > - * purpose between different devices. > > > + * It could theoretically support changing the name of the dma-buf if > the same > > > + * piece of memory is used for multiple purpose between different > devices. > > > * > > > * @dmabuf: [in] dmabuf buffer that will be renamed. > > > * @buf: [in] A piece of userspace memory that contains the > name of > > > @@ -346,19 +344,11 @@ static long dma_buf_set_name(struct dma_buf > *dmabuf, const char __user *buf) > > > if (IS_ERR(name)) > > > return PTR_ERR(name); > > > > > > - dma_resv_lock(dmabuf->resv, NULL); > > > - if (!list_empty(&dmabuf->attachments)) { > > > - ret = -EBUSY; > > > - kfree(name); > > > - goto out_unlock; > > > - } > > > spin_lock(&dmabuf->name_lock); > > > kfree(dmabuf->name); > > > dmabuf->name = name; > > > spin_unlock(&dmabuf->name_lock); > > > > > > -out_unlock: > > > - dma_resv_unlock(dmabuf->resv); > > > return ret; > > > } > > > >

4 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig