Linaro-mm-sig April 2015

linaro-mm-sig@lists.linaro.org

5 participants
10 discussions

[PATCH] allow buffers allocation with DMABUF memory type

by Benjamin Gaignard

Until now the only way to make the driver allocate buffers and share them using dma_buf was to use V4L2_MEMORY_MMAP memory type. Use of MMAP memory type is a problem because vb2 never call dma_buf_map_attachment() to attach itself while queuing the buffer so dma_buf importer will not know that another device use this buffer. This patch allow to allocate buffer even for DMABUF memory type and correctly manage dma_buf buffer attachment. vb2_mem_ops attach_dmabuf() prototype has been changed to be able to distinguish if the attachment is done on a already existing buffer or on imported one. Signed-off-by: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> --- drivers/media/v4l2-core/videobuf2-core.c | 76 ++++++++++++++++++++++++-- drivers/media/v4l2-core/videobuf2-dma-contig.c | 10 ++-- drivers/media/v4l2-core/videobuf2-dma-sg.c | 8 ++- drivers/media/v4l2-core/videobuf2-vmalloc.c | 8 ++- include/media/videobuf2-core.h | 5 +- 5 files changed, 91 insertions(+), 16 deletions(-) diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index 1329dcc..c5968aa 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -337,6 +337,67 @@ static void __setup_offsets(struct vb2_queue *q, unsigned int n) } /** + * __setup_dmabufs() - setup dmabuf fd for every plane in + * every buffer on the queue + */ +static void __setup_dmabufs(struct vb2_queue *q, unsigned int n) +{ + unsigned int buffer, plane; + struct vb2_buffer *vb; + struct vb2_plane *vb_plane; + struct dma_buf *dbuf; + void *mem_priv; + int fd; + int write = !V4L2_TYPE_IS_OUTPUT(q->type); + int flags = write ? O_WRONLY : O_RDONLY; + + for (buffer = q->num_buffers; buffer < q->num_buffers + n; ++buffer) { + vb = q->bufs[buffer]; + if (!vb) + continue; + + for (plane = 0; plane < vb->num_planes; ++plane) { + vb_plane = &vb->planes[plane]; + + dbuf = call_ptr_memop(vb, get_dmabuf, + vb_plane->mem_priv, + flags & O_ACCMODE); + if (IS_ERR_OR_NULL(dbuf)) { + dprintk(1, "Failed to export buffer %d, " \ + "plane %d\n", buffer, plane); + continue; + } + + fd = dma_buf_fd(dbuf, flags & ~O_ACCMODE); + if (fd < 0) { + dprintk(3, "buffer %d, plane %d failed " \ + "to export (%d)\n", buffer, plane, fd); + dma_buf_put(dbuf); + continue; + } + + /* Acquire each plane's memory */ + mem_priv = call_ptr_memop(vb, attach_dmabuf, + q->alloc_ctx[plane], dbuf, + vb->v4l2_planes[plane].length, + write, vb_plane->mem_priv); + if (IS_ERR(mem_priv)) { + dprintk(1, "Buffer %d plane %d failed "\ + "to attach dmabuf\n", buffer, plane); + dma_buf_put(dbuf); + continue; + } + + vb_plane->dbuf = dbuf; + vb->v4l2_planes[plane].m.fd = fd; + + dprintk(3, "Buffer %d, plane %d fd %x\n", + buffer, plane, fd); + } + } +} + +/** * __vb2_queue_alloc() - allocate videobuf buffer structures and (for MMAP type) * video buffer memory for all buffers/planes on the queue and initializes the * queue @@ -369,8 +430,9 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum v4l2_memory memory, vb->v4l2_buf.type = q->type; vb->v4l2_buf.memory = memory; - /* Allocate video buffer memory for the MMAP type */ - if (memory == V4L2_MEMORY_MMAP) { + /* Allocate video buffer memory for the MMAP and DMABUF types */ + if (memory == V4L2_MEMORY_MMAP || + memory == V4L2_MEMORY_DMABUF) { ret = __vb2_buf_mem_alloc(vb); if (ret) { dprintk(1, "failed allocating memory for " @@ -400,6 +462,9 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum v4l2_memory memory, if (memory == V4L2_MEMORY_MMAP) __setup_offsets(q, buffer); + if (memory == V4L2_MEMORY_DMABUF) + __setup_dmabufs(q, buffer); + dprintk(1, "allocated %d buffers, %d plane(s) each\n", buffer, num_planes); @@ -859,7 +924,7 @@ static int __verify_memory_type(struct vb2_queue *q, * to be used during streaming, * 4) allocates internal buffer structures (struct vb2_buffer), according to * the agreed parameters, - * 5) for MMAP memory type, allocates actual video memory, using the + * 5) for MMAP and DMABUF memory types, allocates actual video memory, using the * memory handling/allocation routines provided during queue initialization * * If req->count is 0, all the memory will be freed instead. @@ -885,7 +950,8 @@ static int __reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req) * are not in use and can be freed. */ mutex_lock(&q->mmap_lock); - if (q->memory == V4L2_MEMORY_MMAP && __buffers_in_use(q)) { + if ((q->memory == V4L2_MEMORY_MMAP || + q->memory == V4L2_MEMORY_DMABUF) && __buffers_in_use(q)) { mutex_unlock(&q->mmap_lock); dprintk(1, "memory in use, cannot free\n"); return -EBUSY; @@ -1540,7 +1606,7 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const struct v4l2_buffer *b) /* Acquire each plane's memory */ mem_priv = call_ptr_memop(vb, attach_dmabuf, q->alloc_ctx[plane], - dbuf, planes[plane].length, dma_dir); + dbuf, planes[plane].length, dma_dir, NULL); if (IS_ERR(mem_priv)) { dprintk(1, "failed to attach dmabuf\n"); ret = PTR_ERR(mem_priv); diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c b/drivers/media/v4l2-core/videobuf2-dma-contig.c index b481d20..8dc945e 100644 --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c @@ -793,7 +793,7 @@ static void vb2_dc_detach_dmabuf(void *mem_priv) struct vb2_dc_buf *buf = mem_priv; /* if vb2 works correctly you should never detach mapped buffer */ - if (WARN_ON(buf->dma_addr)) + if (WARN_ON(buf->dma_sgt)) vb2_dc_unmap_dmabuf(buf); /* detach this attachment */ @@ -802,16 +802,18 @@ static void vb2_dc_detach_dmabuf(void *mem_priv) } static void *vb2_dc_attach_dmabuf(void *alloc_ctx, struct dma_buf *dbuf, - unsigned long size, enum dma_data_direction dma_dir) + unsigned long size, enum dma_data_direction dma_dir, void *buf_priv) { struct vb2_dc_conf *conf = alloc_ctx; - struct vb2_dc_buf *buf; + struct vb2_dc_buf *buf = buf_priv; struct dma_buf_attachment *dba; if (dbuf->size < size) return ERR_PTR(-EFAULT); - buf = kzalloc(sizeof(*buf), GFP_KERNEL); + if (!buf) + buf = kzalloc(sizeof(*buf), GFP_KERNEL); + if (!buf) return ERR_PTR(-ENOMEM); diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c b/drivers/media/v4l2-core/videobuf2-dma-sg.c index b1838ab..b9855fd 100644 --- a/drivers/media/v4l2-core/videobuf2-dma-sg.c +++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c @@ -667,16 +667,18 @@ static void vb2_dma_sg_detach_dmabuf(void *mem_priv) } static void *vb2_dma_sg_attach_dmabuf(void *alloc_ctx, struct dma_buf *dbuf, - unsigned long size, enum dma_data_direction dma_dir) + unsigned long size, enum dma_data_direction dma_dir, void *buf_priv) { struct vb2_dma_sg_conf *conf = alloc_ctx; - struct vb2_dma_sg_buf *buf; + struct vb2_dma_sg_buf *buf = buf_priv; struct dma_buf_attachment *dba; if (dbuf->size < size) return ERR_PTR(-EFAULT); - buf = kzalloc(sizeof(*buf), GFP_KERNEL); + if (!buf) + buf = kzalloc(sizeof(*buf), GFP_KERNEL); + if (!buf) return ERR_PTR(-ENOMEM); diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c b/drivers/media/v4l2-core/videobuf2-vmalloc.c index bcde885..373294c 100644 --- a/drivers/media/v4l2-core/videobuf2-vmalloc.c +++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c @@ -416,14 +416,16 @@ static void vb2_vmalloc_detach_dmabuf(void *mem_priv) } static void *vb2_vmalloc_attach_dmabuf(void *alloc_ctx, struct dma_buf *dbuf, - unsigned long size, enum dma_data_direction dma_dir) + unsigned long size, enum dma_data_direction dma_dir, void *buf_priv) { - struct vb2_vmalloc_buf *buf; + struct vb2_vmalloc_buf *buf = buf_priv; if (dbuf->size < size) return ERR_PTR(-EFAULT); - buf = kzalloc(sizeof(*buf), GFP_KERNEL); + if (!buf) + buf = kzalloc(sizeof(*buf), GFP_KERNEL); + if (!buf) return ERR_PTR(-ENOMEM); diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h index a5790fd..374b26b 100644 --- a/include/media/videobuf2-core.h +++ b/include/media/videobuf2-core.h @@ -49,6 +49,8 @@ struct vb2_threadio_data; * used for DMABUF memory types; alloc_ctx is the alloc context * dbuf is the shared dma_buf; returns NULL on failure; * allocator private per-buffer structure on success; + * if private per-buffer structure is provided reuse it + * instead of allocating a new one. * this needs to be used for further accesses to the buffer. * @detach_dmabuf: inform the exporter of the buffer that the current DMABUF * buffer is no longer used; the buf_priv argument is the @@ -98,7 +100,8 @@ struct vb2_mem_ops { void *(*attach_dmabuf)(void *alloc_ctx, struct dma_buf *dbuf, unsigned long size, - enum dma_data_direction dma_dir); + enum dma_data_direction dma_dir, + void *buf_priv); void (*detach_dmabuf)(void *buf_priv); int (*map_dmabuf)(void *buf_priv); void (*unmap_dmabuf)(void *buf_priv); -- 1.9.1

7 years, 10 months

[PATCH v8 00/11] Add DRM for stih4xx platforms

by Benjamin Gaignard

This series of patches add the support of DRM/KMS drivers for STMicroelectronics chipsets stih416 and stih407. version 8: - Allow driver to be build as kernel module. - Use Universal Plane instead of legacy code. patches could be found here: git://git.linaro.org/people/benjamin.gaignard/kernel.git on branch: drm_kms_for_next-v8 version 7: - rebased on top of drm-next (2014-07-24) patches could be found here: git://git.linaro.org/people/benjamin.gaignard/kernel.git on branch: drm_kms_for_next-v7 version 6: - rebased on top of new component framework API. patches could be found here: git://git.linaro.org/people/benjamin.gaignard/kernel.git on branch: drm_kms_for_next-v6 version 5: - Rework sti_drm_drv probes functions to support deferred probe. This allow hdmi to delayed framebuffer creation until I2C is available. - Add ops functions in sti_layer structure to simpify GDP and VID code. - Add NOTES file to describe how the DRM concepts are mapped on hardware. patches could be found here: git://git.linaro.org/people/benjamin.gaignard/kernel.git on branch: drm_kms_for_next-v5 version 4: - Remove depency between TVout it subdevices HDMI and HDA - Rework and simplify VTG and VTAC code - Fix numbers of typo and indentation - Remove debug (will be push in separate patches) - Fix remarks done in previous patcheset patches could be found here: git://git.linaro.org/people/benjamin.gaignard/kernel.git on branch: drm_kms_for_next-v4 version 3: - Correctly split code between probe and bind funtions - Squash some commits - remove HQ-VDP device code to have a smaller patcheset, we will introduce it later. patches could be found here: git://git.linaro.org/people/benjamin.gaignard/kernel.git on branch: drm_kms_for_next-v3 version 2: - Use componentized device instead of register sub-devices in master driver probe function - Fix Makefile and Kconfig to only allow built-in compilation patches could be found here: git://git.linaro.org/people/benjamin.gaignard/kernel.git on branch: drm_kms_for_next-v2 version 1: - First path submission Hardware is split in two main blocks: Compositor and TVout. Each of them includes specific hardware IPs and the display timing are controlled by a specific Video Timing Generator hardware IP (VTG). Compositor is made of the follow hardware IPs: - GDP (Generic Display Pipeline) which is an entry point for graphic (RGB) buffers - VDP (Video Diplay Pipeline) which is an entry point for video (YUV) buffers - HQVDP (High Quality Video Display Processor) that supports scaling, deinterlacing and some miscellaneous image quality improvements. It fetches the Video decoded buffers from memory, processes them and pushes them to the Compositor through a HW dedicated bus. - Mixer is responsible of mixing all the entries depending of their respective z-order and layout TVout is divided in 3 parts: - HDMI to generate HDMI signals, depending of chipset version HDMI phy can change. - HDA to generate signals for HD analog TV - VIP to control/switch data path coming from Compositor On stih416 compositor and Tvout are on different dies so a Video Trafic Advance inter-die Communication mechanism (VTAC) is needed. +---------------------------------------------+ +----------------------------------------+ | +-------------------------------+ +----+ | | +----+ +--------------------------+ | | | | | | | | | | | +---------+ +----+ | | | | +----+ +------+ | | | | | | | | | VIP |---->|HDMI| | | | | |GPD +------------->| | | | | | | | | | | | +----+ | | | | +----+ |Mixer |--|-->| | | | | |---|->| switcher| | | | | | | | | | | | | | | | | +----+ | | | | | | | | | | | | | | | |---->|HDA | | | | | +------+ | |VTAC|========>|VTAC| | +---------+ +----+ | | | | | | | | | | | | | | | | Compositor | | | | | | | | TVout | | | +-------------------------------+ | | | | | | +--------------------------+ | | ^ | | | | | | ^ | | | | | | | | | | | | +--------------+ | | | | | | +-------------+ | | | VTG (master) |----->| | | | | |----->| VTG (slave) | | | +--------------+ +----+ | | +----+ +-------------+ | |Digital die | | Analog Die| +---------------------------------------------+ +----------------------------------------+ On stih407 Compositor and Tvout are on the same die +-----------------------------------------------------------------+ | +-------------------------------+ +--------------------------+ | | | | | +---------+ +----+ | | | | +----+ +------+ | | | VIP |---->|HDMI| | | | | |GPD +------------->| | | | | | +----+ | | | | +----+ |Mixer |--|--|->| switcher| | | | | +----+ +-----+ | | | | | | +----+ | | | | |VDP +-->+HQVDP+--->| | | | | |---->|HDA | | | | | +----+ +-----+ +------+ | | +---------+ +----+ | | | | | | | | | | Compositor | | TVout | | | +-------------------------------+ +--------------------------+ | | ^ ^ | | | | | | +--------------+ | | | VTG | | | +--------------+ | |Digital die | +-----------------------------------------------------------------+ In addition of the drivers for the IPs listed before a thin I2C driver (hdmiddc) is used by HDMI driver to retrieve EDID for monitor. To unify interfaces of GDP and VDP we create a "layer" interface called by compositor to control both GPD and VDP. Hardware have memory contraints (alignment, contiguous) so we use CMA drm helpers functions to allocate frame buffer. File naming convention is: - sti_* for IPs drivers - sti_drm_* for drm functions implementation. Benjamin Gaignard (11): drm: sti: add bindings for DRM driver drm: sti: add VTG driver drm: sti: add VTAC drivers drm: sti: add HDMI driver drm: sti: add HDA driver drm: sti: add TVOut driver drm: sti: add GDP layer drm: sti: add VID layer drm: sti: add Mixer drm: sti: add Compositor drm: sti: Add DRM driver itself .../devicetree/bindings/gpu/st,stih4xx.txt | 189 +++++ drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/sti/Kconfig | 14 + drivers/gpu/drm/sti/Makefile | 21 + drivers/gpu/drm/sti/NOTES | 58 ++ drivers/gpu/drm/sti/sti_compositor.c | 279 +++++++ drivers/gpu/drm/sti/sti_compositor.h | 90 +++ drivers/gpu/drm/sti/sti_drm_crtc.c | 423 +++++++++++ drivers/gpu/drm/sti/sti_drm_crtc.h | 22 + drivers/gpu/drm/sti/sti_drm_drv.c | 241 ++++++ drivers/gpu/drm/sti/sti_drm_drv.h | 29 + drivers/gpu/drm/sti/sti_drm_plane.c | 195 +++++ drivers/gpu/drm/sti/sti_drm_plane.h | 18 + drivers/gpu/drm/sti/sti_gdp.c | 549 ++++++++++++++ drivers/gpu/drm/sti/sti_gdp.h | 16 + drivers/gpu/drm/sti/sti_hda.c | 794 ++++++++++++++++++++ drivers/gpu/drm/sti/sti_hdmi.c | 810 +++++++++++++++++++++ drivers/gpu/drm/sti/sti_hdmi.h | 88 +++ drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c | 336 +++++++++ drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h | 14 + drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c | 211 ++++++ drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.h | 14 + drivers/gpu/drm/sti/sti_layer.c | 197 +++++ drivers/gpu/drm/sti/sti_layer.h | 123 ++++ drivers/gpu/drm/sti/sti_mixer.c | 249 +++++++ drivers/gpu/drm/sti/sti_mixer.h | 54 ++ drivers/gpu/drm/sti/sti_tvout.c | 648 +++++++++++++++++ drivers/gpu/drm/sti/sti_vid.c | 138 ++++ drivers/gpu/drm/sti/sti_vid.h | 12 + drivers/gpu/drm/sti/sti_vtac.c | 215 ++++++ drivers/gpu/drm/sti/sti_vtg.c | 366 ++++++++++ drivers/gpu/drm/sti/sti_vtg.h | 28 + 33 files changed, 6444 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpu/st,stih4xx.txt create mode 100644 drivers/gpu/drm/sti/Kconfig create mode 100644 drivers/gpu/drm/sti/Makefile create mode 100644 drivers/gpu/drm/sti/NOTES create mode 100644 drivers/gpu/drm/sti/sti_compositor.c create mode 100644 drivers/gpu/drm/sti/sti_compositor.h create mode 100644 drivers/gpu/drm/sti/sti_drm_crtc.c create mode 100644 drivers/gpu/drm/sti/sti_drm_crtc.h create mode 100644 drivers/gpu/drm/sti/sti_drm_drv.c create mode 100644 drivers/gpu/drm/sti/sti_drm_drv.h create mode 100644 drivers/gpu/drm/sti/sti_drm_plane.c create mode 100644 drivers/gpu/drm/sti/sti_drm_plane.h create mode 100644 drivers/gpu/drm/sti/sti_gdp.c create mode 100644 drivers/gpu/drm/sti/sti_gdp.h create mode 100644 drivers/gpu/drm/sti/sti_hda.c create mode 100644 drivers/gpu/drm/sti/sti_hdmi.c create mode 100644 drivers/gpu/drm/sti/sti_hdmi.h create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.h create mode 100644 drivers/gpu/drm/sti/sti_layer.c create mode 100644 drivers/gpu/drm/sti/sti_layer.h create mode 100644 drivers/gpu/drm/sti/sti_mixer.c create mode 100644 drivers/gpu/drm/sti/sti_mixer.h create mode 100644 drivers/gpu/drm/sti/sti_tvout.c create mode 100644 drivers/gpu/drm/sti/sti_vid.c create mode 100644 drivers/gpu/drm/sti/sti_vid.h create mode 100644 drivers/gpu/drm/sti/sti_vtac.c create mode 100644 drivers/gpu/drm/sti/sti_vtg.c create mode 100644 drivers/gpu/drm/sti/sti_vtg.h -- 1.9.1

8 years, 8 months

[RFCv3 1/2] device: add dma_params->max_segment_count

by Sumit Semwal

From: Rob Clark <robdclark(a)gmail.com> For devices which have constraints about maximum number of segments in an sglist. For example, a device which could only deal with contiguous buffers would set max_segment_count to 1. The initial motivation is for devices sharing buffers via dma-buf, to allow the buffer exporter to know the constraints of other devices which have attached to the buffer. The dma_mask and fields in 'struct device_dma_parameters' tell the exporter everything else that is needed, except whether the importer has constraints about maximum number of segments. Signed-off-by: Rob Clark <robdclark(a)gmail.com> [sumits: Minor updates wrt comments] Signed-off-by: Sumit Semwal <sumit.semwal(a)linaro.org> --- v3: include Robin Murphy's fix[1] for handling '0' as a value for max_segment_count v2: minor updates wrt comments on the first version [1]: http://article.gmane.org/gmane.linux.kernel.iommu/8175/ include/linux/device.h | 1 + include/linux/dma-mapping.h | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+) diff --git a/include/linux/device.h b/include/linux/device.h index fb506738f7b7..a32f9b67315c 100644 --- a/include/linux/device.h +++ b/include/linux/device.h @@ -647,6 +647,7 @@ struct device_dma_parameters { * sg limitations. */ unsigned int max_segment_size; + unsigned int max_segment_count; /* INT_MAX for unlimited */ unsigned long segment_boundary_mask; }; diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index c3007cb4bfa6..d3351a36d5ec 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -154,6 +154,25 @@ static inline unsigned int dma_set_max_seg_size(struct device *dev, return -EIO; } +#define DMA_SEGMENTS_MAX_SEG_COUNT ((unsigned int) INT_MAX) + +static inline unsigned int dma_get_max_seg_count(struct device *dev) +{ + if (dev->dma_parms && dev->dma_parms->max_segment_count) + return dev->dma_parms->max_segment_count; + return DMA_SEGMENTS_MAX_SEG_COUNT; +} + +static inline int dma_set_max_seg_count(struct device *dev, + unsigned int count) +{ + if (dev->dma_parms) { + dev->dma_parms->max_segment_count = count; + return 0; + } + return -EIO; +} + static inline unsigned long dma_get_seg_boundary(struct device *dev) { return dev->dma_parms ? -- 1.9.1

9 years, 6 months

[RESEND PATCH] Smack: ignore private inode for smack_file_receive

by Seung-Woo Kim

The dmabuf fd can be shared between processes via unix domain socket. The file of dmabuf fd is came from anon_inode. The inode has no set and get xattr operations, so it can not be shared between processes with smack. This patch fixes just to ignore private inode including anon_inode for smack_file_receive. Signed-off-by: Seung-Woo Kim <sw0312.kim(a)samsung.com> --- I think there was some issue sending my previous mail, so I resend patch again. --- security/smack/smack_lsm.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c index 69fdc38..d1bb411 100644 --- a/security/smack/smack_lsm.c +++ b/security/smack/smack_lsm.c @@ -1673,6 +1673,9 @@ static int smack_file_receive(struct file *file) struct smk_audit_info ad; struct inode *inode = file_inode(file); + if (unlikely(IS_PRIVATE(inode))) + return 0; + smk_ad_init(&ad, __func__, LSM_AUDIT_DATA_PATH); smk_ad_setfield_u_fs_path(&ad, file->f_path); /* -- 1.7.4.1

9 years, 7 months

[GIT PULL]: dma-buf updates for 4.1-rc1

by Sumit Semwal

Hi Linus, May I request you to pull a few dma-buf changes for 4.1-rc1? minor cleanup only; this could've gone in for the 4.0 merge window, but for a copy-paste stupidity from me. It has been in the for-next since then, and no issues reported. Thanks and best regards, Sumit. The following changes since commit 646da63172f660ba84f195c1165360a9b73583ee: Merge tag 'remoteproc-4.1-next' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc (2015-04-20 15:40:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git tags/dma-buf-for-4.1 for you to fetch changes up to 72449cb47b0104c32ff8fb9380ade9113375d8d1: staging: android: ion: fix wrong init of dma_buf_export_info (2015-04-21 14:47:16 +0530) ---------------------------------------------------------------- - cleanup of dma_buf_export() - correction of copy-paste stupidity while doing the cleanup ---------------------------------------------------------------- Sumit Semwal (2): dma-buf: cleanup dma_buf_export() to make it easily extensible staging: android: ion: fix wrong init of dma_buf_export_info Documentation/dma-buf-sharing.txt | 23 +++++++------ drivers/dma-buf/dma-buf.c | 47 ++++++++++++-------------- drivers/gpu/drm/armada/armada_gem.c | 10 ++++-- drivers/gpu/drm/drm_prime.c | 12 ++++--- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 9 +++-- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 10 ++++-- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 9 ++++- drivers/gpu/drm/tegra/gem.c | 10 ++++-- drivers/gpu/drm/ttm/ttm_object.c | 9 +++-- drivers/gpu/drm/udl/udl_dmabuf.c | 9 ++++- drivers/media/v4l2-core/videobuf2-dma-contig.c | 8 ++++- drivers/media/v4l2-core/videobuf2-dma-sg.c | 8 ++++- drivers/media/v4l2-core/videobuf2-vmalloc.c | 8 ++++- drivers/staging/android/ion/ion.c | 9 +++-- include/linux/dma-buf.h | 34 +++++++++++++++---- 15 files changed, 152 insertions(+), 63 deletions(-)

9 years, 8 months

[PATCH v5 00/18] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem

by Marek Szyprowski

Hello Everyone, This is yet another attempt to get Exynos SYSMMU driver with integrated with IOMMU & DMA-mapping subsystems. The main change from previous version is a rebase onto some more pending Exynos DTS patches and minor fixes of the reported issues. Merge plan for this patchset: 1. All iommu related patches (with 'iommu: exynos') can be merged to iommu tree. They don't have any direct dependencies on the DTS, DRM and power domain initialization change - without them the driver will simply not initialize, when no exynos,sysmmu nodes are provided in device tree. Joerg, could you merge those patches? 2. DTS and power domain patches should go to Samsung Exynos tree. Those patches depends on earlier DTS patches for Exynos SoCs, which make this patchset really complete: - 'ARM: DTS: Exynos: convert to generic power domain bindings' (http://www.spinics.net/lists/linux-samsung-soc/msg40584.html) - '[PATCH v4 0/7] Enable HDMI support on Exynos platforms' (http://www.spinics.net/lists/arm-kernel/msg391148.html) - '[PATCH 0/2] Add HDMI support for Exynos5420 platform' (http://www.spinics.net/lists/linux-samsung-soc/msg41364.html) Kukjin, could you merge those patches? 3. Exynos DRM fix. This patch in my opinion should go Exynos DRM tree. Inki, could you merge it? Best regards Marek Szyprowski Samsung R&D Institute Poland Changelog: v5: - rebased onto 'Add HDMI support for Exynos5420 platform' patchset - fixed 'const' issue in 'iommu: exynos: init from dt-specific callback instead of initcall' patch, thanks to Tobias Jakobi for reporting it - fixed copy-paste typo in exynos5250 dts patch v4: http://www.spinics.net/lists/linux-samsung-soc/msg41177.html - rebased onto v3.19-rc4 and other Exynos DTS queued patches - added DTS patch for Exynos 5250 & 5420/5422/5800 v3: http://www.spinics.net/lists/linux-samsung-soc/msg39168.html - rebased onto "[RFC PATCH v4 0/8] Introduce automatic DMA configuration for IOMMU masters" - added some minor fixes for iommu and dma-mapping frameworks v2: http://thread.gmane.org/gmane.linux.kernel.iommu/6472/ - rebased onto "[RFC PATCH v3 0/7] Introduce automatic DMA configuration for IOMMU masters" patches: http://www.spinics.net/lists/arm-kernel/msg362076.html - changed initialization from bus notifiers to DT related callbacks - removed support for separate IO address spaces - this will be discussed separately after the basic support gets merged - removed support for power domain notifier-based runtime power management - this also will be discussed separately later v1: https://lkml.org/lkml/2014/8/5/183 - initial version, feature complete, completely rewrote integration approach Patch summary: Marek Szyprowski (18): drm: exynos: detach from default dma-mapping domain on init arm: exynos: pm_domains: add support for devices registered before arch_initcall ARM: dts: exynos4: add sysmmu nodes ARM: dts: exynos5250: add sysmmu nodes ARM: dts: exynos5420: add sysmmu nodes iommu: exynos: don't read version register on every tlb operation iommu: exynos: remove unused functions iommu: exynos: remove useless spinlock iommu: exynos: refactor function parameters to simplify code iommu: exynos: remove unused functions, part 2 iommu: exynos: remove useless device_add/remove callbacks iommu: exynos: add support for binding more than one sysmmu to master device iommu: exynos: add support for runtime_pm iommu: exynos: rename variables to reflect their purpose iommu: exynos: document internal structures iommu: exynos: remove excessive includes and sort others alphabetically iommu: exynos: init from dt-specific callback instead of initcall iommu: exynos: add callback for initializing devices from device tree arch/arm/boot/dts/exynos4.dtsi | 118 +++++++ arch/arm/boot/dts/exynos4210.dtsi | 23 ++ arch/arm/boot/dts/exynos4x12.dtsi | 82 +++++ arch/arm/boot/dts/exynos5250.dtsi | 250 +++++++++++++++ arch/arm/boot/dts/exynos5420.dtsi | 181 +++++++++++ arch/arm/mach-exynos/pm_domains.c | 9 +- drivers/gpu/drm/exynos/exynos_drm_iommu.c | 3 + drivers/iommu/exynos-iommu.c | 492 ++++++++++++++---------------- 8 files changed, 888 insertions(+), 270 deletions(-) -- 1.9.2

9 years, 8 months

[PATCH] Smack: ignore private inode for smack_file_receive

by Seung-Woo Kim

The dmabuf fd can be shared between processes via unix domain socket. The file of dmabuf fd is came from anon_inode. The inode has no set and get xattr operations, so it can not be shared between processes with smack. This patch fixes just to ignore private inode including anon_inode for smack_file_receive. Signed-off-by: Seung-Woo Kim <sw0312.kim(a)samsung.com> --- security/smack/smack_lsm.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c index 69fdc38..d1bb411 100644 --- a/security/smack/smack_lsm.c +++ b/security/smack/smack_lsm.c @@ -1673,6 +1673,9 @@ static int smack_file_receive(struct file *file) struct smk_audit_info ad; struct inode *inode = file_inode(file); + if (unlikely(IS_PRIVATE(inode))) + return 0; + smk_ad_init(&ad, __func__, LSM_AUDIT_DATA_PATH); smk_ad_setfield_u_fs_path(&ad, file->f_path); /* -- 1.7.4.1

9 years, 8 months

Re: [Linaro-mm-sig] [RFC PATCH] Security: ignore private inode from security_file_receive

by Seung-Woo Kim

Hello, On 2015년 04월 17일 00:35, Casey Schaufler wrote: > On 4/16/2015 6:40 AM, Seung-Woo Kim wrote: >> The dma-buf fd from anon_inode can be shared across processes, but >> there is no way to set security permission for the fd. So this >> patch fix just to ignore private inode from security_file_receive. >> >> Signed-off-by: Seung-Woo Kim <sw0312.kim(a)samsung.com> >> --- >> >> If security like smack is enabled, the dmabuf fd can not be shared between >> processes via unix domain socket. I am not familiar with security, so I am >> not sure that this kind of patch can be acceptable. > > If an IS_PRIVATE() check is appropriate, it should be in > smack_file_receive(), not security_file_receive(). Why are you > looking at file->f_path.dentry->d_inode? That's not used in the > Smack access check. You'd want file->f_inode if anything. > > Naked-by: Casey Schaufler <casey(a)schaufler-ca.com> > Ok, I will try to do it from smack side. Also checking about file->f_inode. Thanks and Regards, - Seung-Woo Kim >> >> Is there other option to share dmabuf fd via socket with security check? >> >> Best Regards, >> - Seung-Woo Kim >> >> --- >> security/security.c | 3 +++ >> 1 files changed, 3 insertions(+), 0 deletions(-) >> >> diff --git a/security/security.c b/security/security.c >> index 730ac65..c57354c 100644 >> --- a/security/security.c >> +++ b/security/security.c >> @@ -810,6 +810,9 @@ int security_file_send_sigiotask(struct task_struct *tsk, >> >> int security_file_receive(struct file *file) >> { >> + >> + if (unlikely(IS_PRIVATE(file->f_path.dentry->d_inode))) >> + return 0; >> return security_ops->file_receive(file); >> } >> > > -- Seung-Woo Kim Samsung Software R&D Center --

9 years, 8 months

Re: [Linaro-mm-sig] [RFC PATCH] Security: ignore private inode from security_file_receive

by Seung-Woo Kim

Hello, On 2015년 04월 16일 22:48, Stephen Smalley wrote: > On 04/16/2015 09:40 AM, Seung-Woo Kim wrote: >> The dma-buf fd from anon_inode can be shared across processes, but >> there is no way to set security permission for the fd. So this >> patch fix just to ignore private inode from security_file_receive. >> >> Signed-off-by: Seung-Woo Kim <sw0312.kim(a)samsung.com> >> --- >> >> If security like smack is enabled, the dmabuf fd can not be shared between >> processes via unix domain socket. I am not familiar with security, so I am >> not sure that this kind of patch can be acceptable. >> >> Is there other option to share dmabuf fd via socket with security check? >> >> Best Regards, >> - Seung-Woo Kim >> >> --- >> security/security.c | 3 +++ >> 1 files changed, 3 insertions(+), 0 deletions(-) >> >> diff --git a/security/security.c b/security/security.c >> index 730ac65..c57354c 100644 >> --- a/security/security.c >> +++ b/security/security.c >> @@ -810,6 +810,9 @@ int security_file_send_sigiotask(struct task_struct *tsk, >> >> int security_file_receive(struct file *file) >> { >> + >> + if (unlikely(IS_PRIVATE(file->f_path.dentry->d_inode))) >> + return 0; >> return security_ops->file_receive(file); >> } > > SELinux handles this internally; see its inode_has_perm() function. > Doing it here would prevent any security module checking at all, even of > the struct file, which SELinux does presently do (selinux_file_receive > calls file_has_perm which applies the fd use check and then calls > inode_has_perm on the inode). Unless you are saying that the > file->f_security field is also not being set correctly. Thanks for the suggestion. I will try to do on smack side. Best Regards, - Seung-Woo Kim > > > -- Seung-Woo Kim Samsung Software R&D Center --

9 years, 8 months

[RFC PATCH] Security: ignore private inode from security_file_receive

by Seung-Woo Kim

The dma-buf fd from anon_inode can be shared across processes, but there is no way to set security permission for the fd. So this patch fix just to ignore private inode from security_file_receive. Signed-off-by: Seung-Woo Kim <sw0312.kim(a)samsung.com> --- If security like smack is enabled, the dmabuf fd can not be shared between processes via unix domain socket. I am not familiar with security, so I am not sure that this kind of patch can be acceptable. Is there other option to share dmabuf fd via socket with security check? Best Regards, - Seung-Woo Kim --- security/security.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/security/security.c b/security/security.c index 730ac65..c57354c 100644 --- a/security/security.c +++ b/security/security.c @@ -810,6 +810,9 @@ int security_file_send_sigiotask(struct task_struct *tsk, int security_file_receive(struct file *file) { + + if (unlikely(IS_PRIVATE(file->f_path.dentry->d_inode))) + return 0; return security_ops->file_receive(file); } -- 1.7.4.1

9 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig April 2015