最近项目中出现公司Android系统产品在工作中显示的中间服务HAL层会出现异常。通过上一篇日志“https://my.oschina.net/yuyang/blog/3010044”自己编写的自动保存日志的脚本，获取了日志后，分析得知是用于显示的HAL层composer服务进程出现FD溢出问题。
经分析是在使用Android Sync Framework架构时出现的FD问题，经过几番周折最终确认是调用sync_fence_merge函数进行两个sync fence合并后会得到第三个FD，使用第三个sync fence做为最后的结果返回给Android SurfaceFlinger。对于之前的两个sync fence，需要在HAL层中关闭掉，不然就会出现FD溢出问题。我们出现FD溢出问题的产品，就是因为HWC在调用sync_fence_merges合并两个sync fence后,只关闭了其中的一个sync fence, 因此出现了FD溢出问题。
我在网上找了一篇关于Android Sync Framework 的文章https://blog.csdn.net/fuyajun01/article/details/44261495 上面说的还算可以，官方地址我已经找到了一部分，可以在国内进行访问。地址如下：https://developer.android.google.cn/ndk/reference/group/sync
另外还找一篇PPT https://blog.linuxplumbersconf.org/2014/ocw/system/presentations/2355/original/03%20-%20sync%20&%20dma-fence.pdf
下面是内核文档中的原文
===================
Sync File API Guide
===================
:Author: Gustavo Padovan <gustavo at padovan dot org>
This document serves as a guide for device drivers writers on what the
sync_file API is, and how drivers can support it. Sync file is the carrier ofthe fences(struct dma_fence) that are needed to synchronize between drivers oracross process boundaries. 本文档是用于向驱动开发者说明sync_file API的，以及应该如何支持它。Sync file其实就是Fences的传输器， fences大家都知道它是用于驱动之间或和进程之间同步的。The sync_file API is meant to be used to send and receive fence information
to/from userspace. It enables userspace to do explicit fencing, where instead of attaching a fence to the buffer a producer driver (such as a GPU or V4L driver) sends the fence related to the buffer to userspace via a sync_file.也就是说Sync_file则是用于内核空间与用户空间接收和发送fence。这样用户空间可以使用一个fence绑定到一个buffer，Producer driver（GPU 或者 是V4L ）将通过sync file把fence发送给用户空间，从而可以用户空间可以明确一个时间范围。The sync_file then can be sent to the consumer (DRM driver for example), that
will not use the buffer for anything before the fence(s) signals, i.e., the driver that issued the fence is not using/processing the buffer anymore, so it signals that the buffer is ready to use. And vice-versa for the consumer -> producer part of the cycle.Sync files allows userspace awareness on buffer sharing synchronization between
drivers.Sync file was originally added in the Android kernel but current Linux Desktop
can benefit a lot from it.in-fences and out-fences
------------------------Sync files can go either to or from userspace. When a sync_file is sent from
the driver to userspace we call the fences it contains 'out-fences'. They are related to a buffer that the driver is processing or is going to process, so the driver creates an out-fence to be able to notify, through dma_fence_signal(), when it has finished using (or processing) that buffer. Out-fences are fences that the driver creates.On the other hand if the driver receives fence(s) through a sync_file from
userspace we call these fence(s) 'in-fences'. Receiving in-fences means that we need to wait for the fence(s) to signal before using any buffer related to the in-fences.Creating Sync Files
-------------------When a driver needs to send an out-fence userspace it creates a sync_file.
Interface::
struct sync_file *sync_file_create(struct dma_fence *fence);
The caller pass the out-fence and gets back the sync_file. That is just the
first step, next it needs to install an fd on sync_file->file. So it gets an fd::fd = get_unused_fd_flags(O_CLOEXEC);
and installs it on sync_file->file::
fd_install(fd, sync_file->file);
The sync_file fd now can be sent to userspace.
If the creation process fail, or the sync_file needs to be released by any
other reason fput(sync_file->file) should be used.Receiving Sync Files from Userspace
-----------------------------------When userspace needs to send an in-fence to the driver it passes file descriptor
of the Sync File to the kernel. The kernel can then retrieve the fences from it.Interface::
struct dma_fence *sync_file_get_fence(int fd);
The returned reference is owned by the caller and must be disposed of afterwards using dma_fence_put(). In case of error, a NULL is returned instead.References:
1. struct sync_file in include/linux/sync_file.h
2. All interfaces mentioned above defined in include/linux/sync_file.h