<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="Generator" content="Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="blue" vlink="purple"> <div class="WordSection1"> Hi,<o:p></o:p> <o:p> </o:p> Please have a review for below code change suggestion from Samsung DTV.<o:p></o:p> <o:p> </o:p> Thanks,<o:p></o:p> Rich<o:p></o:p> <o:p> </o:p> <div> <div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"> 寄件者: hoseon.kim [mailto:hoseon.kim@samsung.com] 寄件日期: Friday, December 20, 2013 10:51 PM 收件者: support-mali; 'Marco Starace'; 'Ravi Agnihotri'; 'Jeba Samuel' 副本: '무랄리'; '비핀'; '서주원'; '이승은'; Rich Su; Norman Evanson; 김호선 主旨: RE: [urgent] dmabuf close error and kernel oops from xf86-video-armsoc (571146)<o:p></o:p> </div> </div> <o:p> </o:p> Hi Norman,<o:p></o:p> <o:p> </o:p> When I check dma-buf API Guide document which is attached, there is a mention like this…<o:p></o:p> <o:p> </o:p> < DMA Buffer Sharing API Guide ><o:p></o:p> …<o:p></o:p> - In order to avoid fd leaks on exec, the FD_CLOEXEC flag must be set<o:p></o:p> on the file descriptor. This is not just a resource leak, but a<o:p></o:p> potential security hole. It could give the newly exec'd application<o:p></o:p> access to buffers, via the leaked fd, to which it should otherwise<o:p></o:p> not be permitted access.<o:p></o:p> <o:p> </o:p> The problem with doing this via a separate fcntl() call, versus doing it<o:p></o:p> atomically when the fd is created, is that this is inherently racy in a<o:p></o:p> multi-threaded app[3]. The issue is made worse when it is library code<o:p></o:p> opening/creating the file descriptor, as the application may not even be<o:p></o:p> aware of the fd's.<o:p></o:p> <o:p> </o:p> To avoid this problem, userspace must have a way to request O_CLOEXEC<o:p></o:p> flag be set when the dma-buf fd is created. So any API provided by<o:p></o:p> the exporting driver to create a dmabuf fd must provide a way to let<o:p></o:p> userspace control setting of O_CLOEXEC flag passed in to dma_buf_fd().<o:p></o:p> <o:p> </o:p> <o:p> </o:p> According to this description, I think that armsoc_bo_set_dmabuf() should use O_CLOEXEC when it try to get dma_buf fd.<o:p></o:p> So, the code need to be changed like this…<o:p></o:p> <o:p> </o:p> [ Before ]<o:p></o:p> /* Try to get dma_buf fd */<o:p></o:p> prime_handle.handle = bo->handle;<o:p></o:p> prime_handle.flags = 0;<o:p></o:p> res = drmIoctl(bo->dev->fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, &prime_handle);<o:p></o:p> <o:p> </o:p> [ After ]<o:p></o:p> /* Try to get dma_buf fd */<o:p></o:p> prime_handle.handle = bo->handle;<o:p></o:p> prime_handle.flags = O_CLOEXEC;<o:p></o:p> res = drmIoctl(bo->dev->fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, &prime_handle);<o:p></o:p> <o:p> </o:p> Could you please check if it is correct or not with your xf86_video_armsoc manager?<o:p></o:p> And, is it possible to check with him, if this usage(without O_CLOEXEC) can make the problem case that I mentioned previous mail (below)?<o:p></o:p> <o:p> </o:p> I will be happy if you can give feedback for my question in today.<o:p></o:p> <o:p> </o:p> Best Regards,<o:p></o:p> Hoseon<o:p></o:p> <div> <div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"> From: hoseon.kim [<a href="mailto:hoseon.kim@samsung.com">mailto:hoseon.kim@samsung.com</a>] Sent: Thursday, December 19, 2013 7:52 PM To: 'support-mali'; 'Marco Starace'; 'Ravi Agnihotri'; 'Jeba Samuel' Cc: '무랄리'; '비핀'; '서주원'; '이승은'; 'Rich Su'; 'Norman Evanson'; 김호선 Subject: RE: [urgent] dmabuf close error and kernel oops from xf86-video-armsoc (571146)<o:p></o:p> </div> </div> <o:p> </o:p> Hi Eason,<o:p></o:p> <o:p> </o:p> Please find the call stack analysis information from kernel team.<o:p></o:p> If you find something valuable, please let me know.<o:p></o:p> <o:p> </o:p> Best Regards,<o:p></o:p> Hoseon<o:p></o:p> <![if !supportLists]>- <![endif]>Kernel oops came from locks_remove_posix. <o:p></o:p> <table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" width="726" style="width:544.5pt;background:white;border-collapse:collapse"> <tbody> <tr style="height:15.0pt"> <td width="710" style="width:532.5pt;border:inset black 1.0pt;padding:0in 0in 0in 0in;height:15.0pt"> [14:54:15.511] [ 11.422439] PC is at locks_remove_posix+0x18/0x30 [14:54:15.515] [ 11.427193] LR is at filp_close+0x60/0x8c [14:54:15.519] [ 11.431244] pc : [<c018ca9c>] lr : [<c0148a78>] psr: 40000013 [14:54:15.525] [ 11.431244] sp : e1bbdf30 ip : e1bbdf40 fp : e1bbdf3c [14:54:15.530] [ 11.442868] r10: 00000000 r9 : e1bbc000 r8 : e598d040 [14:54:15.536] [ 11.448153] r7 : e5a33f00 r6 : e598d000 r5 : 00000000 r4 : e5a33f00 [14:54:15.543] [ 11.454758] r3 : 00000000 r2 : e1bbdf50 r1 : e598d000 r0 : e5a33f00 [14:54:15.549] [ 11.461364] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [14:54:15.556] [ 11.468586] Control: 30c53c7d Table: bd9fb9c0 DAC: 55555555 [14:54:15.563] [ 11.474399] Process XOrgLauncherThr (pid: 374, stack limit = 0xe1bbc238) [14:54:15.569] [ 11.481180] Stack: (0xe1bbdf30 to 0xe1bbe000) [14:54:15.573] [ 11.485585] df20: e1bbdf5c e1bbdf40 c0148a78 c018ca90 [14:54:15.581] [ 11.493864] df40: 00000000 0000001b e598d000 e598d008 e1bbdf94 e1bbdf60 c0165f9c c0148a24 [14:54:15.590] [ 11.502143] df60: e1bbdfa4 00000000 00000001 a341a230 00000001 be3fe504 00000006 c0013324 [14:54:15.598] [ 11.510421] df80: e1bbc000 00000000 e1bbdfa4 e1bbdf98 c01489f0 c0165e98 00000000 e1bbdfa8 [14:54:15.606] [ 11.518700] dfa0: c00130a0 c01489cc a341a230 00000001 0000001b aa5624d4 aa562910 00000001 [14:54:15.615] [ 11.526979] dfc0: a341a230 00000001 be3fe504 00000006 0051a77c 00000012 0051a784 aa561b1c [14:54:15.623] [ 11.535258] dfe0: 00000000 aa561b08 ab4b7fa4 ab4b7fb4 80000010 0000001b ffffffff ffffffff [14:54:15.632] [ 11.543534] Backtrace: [14:54:15.633] [ 11.546006] [<c018ca84>] (locks_remove_posix+0x0/0x30) from [<c0148a78>] (filp_close+0x60/0x8c) [14:54:15.643] [ 11.554814] [<c0148a18>] (filp_close+0x0/0x8c) from [<c0165f9c>] (__close_fd+0x110/0x1a4) [14:54:15.650] [ 11.563087] r6:e598d008 r5:e598d000 r4:0000001b r3:00000000 [14:54:15.657] [ 11.568816] [<c0165e8c>] (__close_fd+0x0/0x1a4) from [<c01489f0>] (sys_close+0x30/0x58) [14:54:15.664] [ 11.576919] [<c01489c0>] (sys_close+0x0/0x58) from [<c00130a0>] (ret_fast_syscall+0x0/0x48) [14:54:15.673] [ 11.585372] Code: e24cb004 e52de004 e8bd4000 e590300c (e5933028) [14:54:15.680] [ 11.591538] [SELP] while loop ... please attach T32...<o:p></o:p> </td> </tr> </tbody> </table> <o:p></o:p> Because dentry is 0 in file (anon idnoe file), this kernel oops problem comes.<o:p></o:p> <table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" width="726" style="width:544.5pt;background:white;border-collapse:collapse"> <tbody> <tr style="height:15.0pt"> <td width="726" style="width:544.5pt;border:inset black 1.0pt;padding:0in 0in 0in 0in;height:15.0pt"> -001|filp_close( | filp = 0xE5A33F00 -> ( | f_u = (fu_list = (next = 0xE5A33540, prev = 0xC014BA0C), fu_rcuhead = | f_path = (mnt = 0x0, dentry = 0x0), | f_op = 0xC03E389C, | f_lock = (rlock = (raw_lock = (slock = 0x0, tickets = (owner = 0x0, n | f_sb_list_cpu = 0x0, | f_count = (counter = 0x1), | f_flags = 0x0, | f_mode = 0x1,<o:p></o:p> </td> </tr> </tbody> </table> It seems that this call comes from armsoc_bo_clear_dmabuf.<o:p></o:p> <table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" width="726" style="width:544.5pt;background:white;border-collapse:collapse"> <tbody> <tr style="height:15.0pt"> <td width="726" style="width:544.5pt;border:inset black 1.0pt;padding:0in 0in 0in 0in;height:15.0pt"> void armsoc_bo_clear_dmabuf(struct mali_bo *bo) { assert(bo->refcnt > 0); assert(mali_bo_has_dmabuf(bo));<o:p></o:p> close(bo->dmabuf); bo->dmabuf = -1; }<o:p></o:p> </td> </tr> </tbody> </table> <o:p> </o:p> <o:p> </o:p> <div> <div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"> From: support-mali <a href="mailto:[mailto:support-mali@arm.com]">[mailto:support-mali@arm.com]</a> Sent: Thursday, December 19, 2013 12:38 PM To: hoseon.kim; 'Marco Starace'; 'Ravi Agnihotri'; 'Jeba Samuel' Cc: support-mali; '무랄리'; '비핀'; '서주원'; '이승은'; Rich Su; Norman Evanson Subject: RE: [urgent] dmabuf close error and kernel oops from xf86-video-armsoc (571146)<o:p></o:p> </div> </div> <o:p> </o:p> [From Eason Tang - ARM Technical Support] <o:p></o:p> <o:p> </o:p> Hi Hoseon,<o:p></o:p> <o:p> </o:p> This Kernel oops may be caused in kernel instead of in armsoc which is in user space. Armsoc may be able to use/call the kernel from user space with any values and the kernel driver should handle the problem.<o:p></o:p> The problem described by this case seems to be initially in the drm driver (or possibly kbase). Did you get chance to check the if the “refcount” is incorrect? I would suggest to review the drm driver first for the possible issue.<o:p></o:p> As I know, Samsung DTV may have more than one Xserver running with Samsung application. How many Xserver/views are running when reproducing this issue? Any specific procedure to see this issue?<o:p></o:p> Is there any log showing kernel crash with full call stack that can be shared to check further?<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Thanks,<o:p></o:p> -Eason<o:p></o:p> <o:p> </o:p> //--------------------------------------------------------------------------------------- From: hoseon.kim [<a href="mailto:hoseon.kim@samsung.com">mailto:hoseon.kim@samsung.com</a>] Sent: Wednesday, December 18, 2013 11:09 PM To: Eason Tang; Norman Evanson; Rich Su; 'Marco Starace'; 'Ravi Agnihotri'; 'Jeba Samuel' Cc: support-mali; '무랄리'; '비핀'; '서주원'; '이승은'; 김호선 Subject: RE: [urgent] dmabuf close error and kernel oops from xf86-video-armsoc Hi Norman, Eason, Please find the following analysis … Really, this problem is coming when dma_buf_lock is not used, also. So, please review the possibility of this problem with original xf86-video-armsoc driver itself. I expect your feedback today with some debug patch to try, it is very urgent issue. Best Regards, Hoseon From: hoseon.kim [<a href="mailto:hoseon.kim@samsung.com">mailto:hoseon.kim@samsung.com</a>] Sent: Wednesday, December 18, 2013 11:03 PM To: 'Eason Tang'; 'Norman Evanson'; 'Rich Su'; 'Marco Starace'; 'Ravi Agnihotri'; 'Jeba Samuel' Cc: 'support-mali'; '무랄리'; '비핀'; '서주원'; '이승은'; 김호선 Subject: RE: [urgent] dmabuf close error and kernel oops from xf86-video-armsoc Hi Eason, When we check the dma_buf_lock patch from ARM, we are not sure all the resources are protected correctly. Could you please review your dma_buf_lock patch in this point of view? And, if there are some suspected code, please let me know. Please find the dma_buf_lock patch from ARM : <a href="http://connect.arm.com/dropzone/samsung-lsi-mali-project/dma_buf_lock_wk48_v2.patch">http://connect.arm.com/dropzone/samsung-lsi-mali-project/dma_buf_lock_wk48_v2.patch</a> In dma_buf_lock_dolock() function of dma_buf_lock.c, All the kref_put() is protected by mutex, but kref_get() is not protected … is it no problem? Best Regards, Hoseon From: Eason Tang HYPERLINK "mailto:[<a href="mailto:Eason.Tang@arm.com">mailto:Eason.Tang@arm.com</a>]"[<a href="mailto:Eason.Tang@arm.com">mailto:Eason.Tang@arm.com</a>] Sent: Wednesday, December 18, 2013 7:02 PM To: hoseon.kim; Norman Evanson; Rich Su; 'Marco Starace'; 'Ravi Agnihotri'; 'Jeba Samuel' Cc: support-mali; '무랄리'; '비핀'; '서주원'; '이승은' Subject: RE: [urgent] dmabuf close error and kernel oops from xf86-video-armsoc Hi Hoseon, I just checked the engineer who is in charge of xf86-video-armsoc, he has got this reported issue from “xf86-video-armsoc” mail list as I attached previously for your reference. We are checking it now.<o:p></o:p> We will suggest to join the mailing list and report bugs or ask questions through that. Thanks, -Eason From: hoseon.kim HYPERLINK "mailto:[<a href="mailto:hoseon.kim@samsung.com">mailto:hoseon.kim@samsung.com</a>]"[<a href="mailto:hoseon.kim@samsung.com">mailto:hoseon.kim@samsung.com</a>] Sent: Wednesday, December 18, 2013 5:52 PM To: Eason Tang; Norman Evanson; Rich Su; 'Marco Starace'; 'Ravi Agnihotri'; 'Jeba Samuel' Cc: support-mali; '무랄리'; '비핀'; '서주원'; '이승은'; 김호선 Subject: RE: [urgent] dmabuf close error and kernel oops from xf86-video-armsoc Hi Eason, I have checked the latest xf86-video-armsoc code, and I could not find something meaningful. If ARM engineer who is in charge of xf86-video-armsoc can help us, it will be better to get closer for the point of problem.<o:p></o:p> Could you please check if ARM xf86-video-armsoc engineer can go through this issue? Best Regards, Hoseon From: Eason Tang [<a href="mailto:Eason.Tang@arm.com">mailto:Eason.Tang@arm.com</a>] Sent: Wednesday, December 18, 2013 5:48 PM To: HYPERLINK "<a href="mailto:hoseon.kim@samsung.com">mailto:hoseon.kim@samsung.com</a>"hoseon.kim@samsung.com; Norman Evanson; Rich Su; Marco Starace; Ravi Agnihotri; Jeba Samuel<o:p></o:p> Cc: support-mali; 무랄리; 비핀; 서주원; 이승은 Subject: RE: [urgent] dmabuf close error and kernel oops from xf86-video-armsoc Hi Hoseon, I just forwarded the reported issue to the below mail list, please refer to below links and mail list for xf86-video-armsoc.<o:p></o:p> Please be aware that we now have an armsoc git repo hosted by freedesktop: <a href="http://cgit.freedesktop.org/xorg/driver/xf86-video-armsoc/">http://cgit.freedesktop.org/xorg/driver/xf86-video-armsoc/</a> And we have a mailing list: <a href="http://lists.x.org/mailman/listinfo/xf86-video-armsoc">http://lists.x.org/mailman/listinfo/xf86-video-armsoc</a> Both the linaro and freedesktop repos are currently identical. Please move to the freedesktop location for the armsoc, and join the mailing list and report bugs or ask questions through that. You are also welcome to submit code changes on the mailing list for review, and comment on changes we make which will be posted on the mailing list.<o:p></o:p> Thanks, -Eason From: HOSEON KIM HYPERLINK "mailto:[<a href="mailto:hoseon.kim@samsung.com">mailto:hoseon.kim@samsung.com</a>]"[<a href="mailto:hoseon.kim@samsung.com">mailto:hoseon.kim@samsung.com</a>] Sent: Wednesday, December 18, 2013 4:26 PM To: Norman Evanson; Eason Tang; Rich Su; support-mali; Marco Starace; Ravi Agnihotri; Jeba Samuel Cc: 무랄리; 비핀; 서주원; 이승은; 김호선 Subject: [urgent] dmabuf close error and kernel oops from xf86-video-armsoc Hi Norman, Eason, Rich, Recentry, I received many NULL pointer access error reports from product team. It always shows the same error from xf86-video-armsoc driver. Could you please assign xf86-video-armsoc engineer, and check the following error case with highest priority? < armsoc_dumb.c > void mali_bo_clear_dmabuf(struct mali_bo *bo) { assert(bo->refcnt > 0); assert(mali_bo_has_dmabuf(bo)); close(bo->dmabuf); bo->dmabuf = -1; } close -> ... -> filp_close -> locks_remove_posix -> filp->f_path.dentry ==> kernel oops because it is NULL Please check if you have any previous history like this, and let me know which approach will be better to debug it. It is reproduced very rarely (once or twice in a day), so your quick response will be very helpful to get more detail debug iinformation.<o:p></o:p> Best Regards, Hoseon <o:p></o:p> </div> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 </body> </html>