lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a28d0542-5d63-7c72-0f39-40e4524d9a2a@linaro.org>
Date:   Fri, 7 Dec 2018 12:08:20 +0200
From:   Stanimir Varbanov <stanimir.varbanov@...aro.org>
To:     Vivek Gautam <vivek.gautam@...eaurora.org>,
        stanimir.varbanov@...aro.org, mchehab@...nel.org
Cc:     linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, vgarodia@...eaurora.org,
        acourbot@...omium.org
Subject: Re: [PATCH 1/1] media: venus: core: Set dma maximum segment size

Hi Vivek,

Thanks for the patch!

On 12/5/18 10:31 AM, Vivek Gautam wrote:
> Turning on CONFIG_DMA_API_DEBUG_SG results in the following error:
> 
> [  460.308650] ------------[ cut here ]------------
> [  460.313490] qcom-venus aa00000.video-codec: DMA-API: mapping sg segment longer than device claims to support [len=4194304] [max=65536]
> [  460.326017] WARNING: CPU: 3 PID: 3555 at src/kernel/dma/debug.c:1301 debug_dma_map_sg+0x174/0x254
> [  460.338888] Modules linked in: venus_dec venus_enc videobuf2_dma_sg videobuf2_memops hci_uart btqca bluetooth venus_core v4l2_mem2mem videobuf2_v4l2 videobuf2_common ath10k_snoc ath10k_core ath lzo lzo_compress zramjoydev
> [  460.375811] CPU: 3 PID: 3555 Comm: V4L2DecoderThre Tainted: G        W         4.19.1 #82
> [  460.384223] Hardware name: Google Cheza (rev1) (DT)
> [  460.389251] pstate: 60400009 (nZCv daif +PAN -UAO)
> [  460.394191] pc : debug_dma_map_sg+0x174/0x254
> [  460.398680] lr : debug_dma_map_sg+0x174/0x254
> [  460.403162] sp : ffffff80200c37d0
> [  460.406583] x29: ffffff80200c3830 x28: 0000000000010000
> [  460.412056] x27: 00000000ffffffff x26: ffffffc0f785ea80
> [  460.417532] x25: 0000000000000000 x24: ffffffc0f4ea1290
> [  460.423001] x23: ffffffc09e700300 x22: ffffffc0f4ea1290
> [  460.428470] x21: ffffff8009037000 x20: 0000000000000001
> [  460.433936] x19: ffffff80091b0000 x18: 0000000000000000
> [  460.439411] x17: 0000000000000000 x16: 000000000000f251
> [  460.444885] x15: 0000000000000006 x14: 0720072007200720
> [  460.450354] x13: ffffff800af536e0 x12: 0000000000000000
> [  460.455822] x11: 0000000000000000 x10: 0000000000000000
> [  460.461288] x9 : 537944d9c6c48d00 x8 : 537944d9c6c48d00
> [  460.466758] x7 : 0000000000000000 x6 : ffffffc0f8d98f80
> [  460.472230] x5 : 0000000000000000 x4 : 0000000000000000
> [  460.477703] x3 : 000000000000008a x2 : ffffffc0fdb13948
> [  460.483170] x1 : ffffffc0fdb0b0b0 x0 : 000000000000007a
> [  460.488640] Call trace:
> [  460.491165]  debug_dma_map_sg+0x174/0x254
> [  460.495307]  vb2_dma_sg_alloc+0x260/0x2dc [videobuf2_dma_sg]
> [  460.501150]  __vb2_queue_alloc+0x164/0x374 [videobuf2_common]
> [  460.507076]  vb2_core_reqbufs+0xfc/0x23c [videobuf2_common]
> [  460.512815]  vb2_reqbufs+0x44/0x5c [videobuf2_v4l2]
> [  460.517853]  v4l2_m2m_reqbufs+0x44/0x78 [v4l2_mem2mem]
> [  460.523144]  v4l2_m2m_ioctl_reqbufs+0x1c/0x28 [v4l2_mem2mem]
> [  460.528976]  v4l_reqbufs+0x30/0x40
> [  460.532480]  __video_do_ioctl+0x36c/0x454
> [  460.536610]  video_usercopy+0x25c/0x51c
> [  460.540572]  video_ioctl2+0x38/0x48
> [  460.544176]  v4l2_ioctl+0x60/0x74
> [  460.547602]  do_video_ioctl+0x948/0x3520
> [  460.551648]  v4l2_compat_ioctl32+0x60/0x98
> [  460.555872]  __arm64_compat_sys_ioctl+0x134/0x20c
> [  460.560718]  el0_svc_common+0x9c/0xe4
> [  460.564498]  el0_svc_compat_handler+0x2c/0x38
> [  460.568982]  el0_svc_compat+0x8/0x18
> [  460.572672] ---[ end trace ce209b87b2f3af88 ]---
> 
> From above warning one would deduce that the sg segment will overflow
> the device's capacity. In reality, the hardware can accommodate larger
> sg segments.
> So, initialize the max segment size properly to weed out this warning.
> 
> Based on a similar patch sent by Sean Paul for mdss:
> https://patchwork.kernel.org/patch/10671457/
> 
> Signed-off-by: Vivek Gautam <vivek.gautam@...eaurora.org>
> ---
>  drivers/media/platform/qcom/venus/core.c | 8 ++++++++
>  1 file changed, 8 insertions(+)

Acked-by: Stanimir Varbanov <stanimir.varbanov@...aro.org>

-- 
regards,
Stan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ