OpenCloudOS-Kernel/drivers/media/media-device.c

903 lines
23 KiB
C
Raw Normal View History

/*
* Media device
*
* Copyright (C) 2010 Nokia Corporation
*
* Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
* Sakari Ailus <sakari.ailus@iki.fi>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
#include <linux/compat.h>
#include <linux/export.h>
#include <linux/idr.h>
#include <linux/ioctl.h>
#include <linux/media.h>
[media] media: convert links from array to list The entire logic that represent graph links were developed on a time where there were no needs to dynamic remove links. So, although links are created/removed one by one via some functions, they're stored as an array inside the entity struct. As the array may grow, there's a logic inside the code that checks if the amount of space is not enough to store the needed links. If it isn't the core uses krealloc() to change the size of the link, with is bad, as it leaves the memory fragmented. So, convert links into a list. Also, currently, both source and sink entities need the link at the graph traversal logic inside media_entity. So there's a logic duplicating all links. That makes it to spend twice the memory needed. This is not a big deal for today's usage, where the number of links are not big. Yet, if during the MC workshop discussions, it was said that IIO graphs could have up to 4,000 entities. So, we may want to remove the duplication on some future. The problem is that it would require a separate linked list to store the backlinks inside the entity, or to use a more complex algorithm to do graph backlink traversal, with is something that the current graph traversal inside the core can't cope with. So, let's postpone a such change if/when it is actually needed. It should also be noticed that the media_link structure uses 44 bytes on 32-bit architectures and 84 bytes on 64-bit architecture. It will thus be allocated out of the 64-bytes and 96-bytes pools respectively. That's a 12.5% memory waste on 64-bit architectures and 31.25% on 32-bit architecture. A linked list is less efficient than an array in this case, but this could later be optimized if we can get rid of the reverse links (with would reduce memory allocation by 50%). Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-08-07 17:55:40 +08:00
#include <linux/slab.h>
#include <linux/types.h>
#include <linux/pci.h>
#include <linux/usb.h>
#include <linux/version.h>
#include <media/media-device.h>
#include <media/media-devnode.h>
[media] media: Entities, pads and links As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. An entity is a basic media hardware building block. It can correspond to a large variety of logical blocks such as physical hardware devices (CMOS sensor for instance), logical hardware devices (a building block in a System-on-Chip image processing pipeline), DMA channels or physical connectors. A pad is a connection endpoint through which an entity can interact with other entities. Data (not restricted to video) produced by an entity flows from the entity's output to one or more entity inputs. Pads should not be confused with physical pins at chip boundaries. A link is a point-to-point oriented connection between two pads, either on the same entity or on different entities. Data flows from a source pad to a sink pad. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil <hverkuil@xs4all.nl> initial work. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-12-09 19:40:00 +08:00
#include <media/media-entity.h>
media: media-request: implement media requests Add initial media request support: 1) Add MEDIA_IOC_REQUEST_ALLOC ioctl support to media-device.c 2) Add struct media_request to store request objects. 3) Add struct media_request_object to represent a request object. 4) Add MEDIA_REQUEST_IOC_QUEUE/REINIT ioctl support. Basic lifecycle: the application allocates a request, adds objects to it, queues the request, polls until it is completed and can then read the final values of the objects at the time of completion. When it closes the file descriptor the request memory will be freed (actually, when the last user of that request releases the request). Drivers will bind an object to a request (the 'adds objects to it' phase), when MEDIA_REQUEST_IOC_QUEUE is called the request is validated (req_validate op), then queued (the req_queue op). When done with an object it can either be unbound from the request (e.g. when the driver has finished with a vb2 buffer) or marked as completed (e.g. for controls associated with a buffer). When all objects in the request are completed (or unbound), then the request fd will signal an exception (poll). Co-developed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Co-developed-by: Alexandre Courbot <acourbot@chromium.org> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-05-21 16:54:27 +08:00
#include <media/media-request.h>
#ifdef CONFIG_MEDIA_CONTROLLER
/*
* Legacy defines from linux/media.h. This is the only place we need this
* so we just define it here. The media.h header doesn't expose it to the
* kernel to prevent it from being used by drivers, but here (and only here!)
* we need it to handle the legacy behavior.
*/
#define MEDIA_ENT_SUBTYPE_MASK 0x0000ffff
#define MEDIA_ENT_T_DEVNODE_UNKNOWN (MEDIA_ENT_F_OLD_BASE | \
MEDIA_ENT_SUBTYPE_MASK)
/* -----------------------------------------------------------------------------
* Userspace API
*/
static inline void __user *media_get_uptr(__u64 arg)
{
return (void __user *)(uintptr_t)arg;
}
static int media_device_open(struct file *filp)
{
return 0;
}
static int media_device_close(struct file *filp)
{
return 0;
}
static long media_device_get_info(struct media_device *dev, void *arg)
{
struct media_device_info *info = arg;
memset(info, 0, sizeof(*info));
if (dev->driver_name[0])
strscpy(info->driver, dev->driver_name, sizeof(info->driver));
else
strscpy(info->driver, dev->dev->driver->name,
sizeof(info->driver));
strscpy(info->model, dev->model, sizeof(info->model));
strscpy(info->serial, dev->serial, sizeof(info->serial));
strscpy(info->bus_info, dev->bus_info, sizeof(info->bus_info));
info->media_version = LINUX_VERSION_CODE;
info->driver_version = info->media_version;
info->hw_revision = dev->hw_revision;
return 0;
}
static struct media_entity *find_entity(struct media_device *mdev, u32 id)
{
struct media_entity *entity;
int next = id & MEDIA_ENT_ID_FLAG_NEXT;
id &= ~MEDIA_ENT_ID_FLAG_NEXT;
media_device_for_each_entity(entity, mdev) {
if (((media_entity_id(entity) == id) && !next) ||
((media_entity_id(entity) > id) && next)) {
return entity;
}
}
return NULL;
}
static long media_device_enum_entities(struct media_device *mdev, void *arg)
{
struct media_entity_desc *entd = arg;
struct media_entity *ent;
ent = find_entity(mdev, entd->id);
if (ent == NULL)
return -EINVAL;
memset(entd, 0, sizeof(*entd));
entd->id = media_entity_id(ent);
if (ent->name)
strscpy(entd->name, ent->name, sizeof(entd->name));
entd->type = ent->function;
entd->revision = 0; /* Unused */
entd->flags = ent->flags;
entd->group_id = 0; /* Unused */
entd->pads = ent->num_pads;
entd->links = ent->num_links - ent->num_backlinks;
/*
* Workaround for a bug at media-ctl <= v1.10 that makes it to
* do the wrong thing if the entity function doesn't belong to
* either MEDIA_ENT_F_OLD_BASE or MEDIA_ENT_F_OLD_SUBDEV_BASE
* Ranges.
*
* Non-subdevices are expected to be at the MEDIA_ENT_F_OLD_BASE,
* or, otherwise, will be silently ignored by media-ctl when
* printing the graphviz diagram. So, map them into the devnode
* old range.
*/
if (ent->function < MEDIA_ENT_F_OLD_BASE ||
ent->function > MEDIA_ENT_F_TUNER) {
if (is_media_entity_v4l2_subdev(ent))
entd->type = MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN;
else if (ent->function != MEDIA_ENT_F_IO_V4L)
entd->type = MEDIA_ENT_T_DEVNODE_UNKNOWN;
}
memcpy(&entd->raw, &ent->info, sizeof(ent->info));
return 0;
}
static void media_device_kpad_to_upad(const struct media_pad *kpad,
struct media_pad_desc *upad)
{
upad->entity = media_entity_id(kpad->entity);
upad->index = kpad->index;
upad->flags = kpad->flags;
}
static long media_device_enum_links(struct media_device *mdev, void *arg)
{
struct media_links_enum *links = arg;
struct media_entity *entity;
entity = find_entity(mdev, links->entity);
if (entity == NULL)
return -EINVAL;
if (links->pads) {
unsigned int p;
for (p = 0; p < entity->num_pads; p++) {
struct media_pad_desc pad;
memset(&pad, 0, sizeof(pad));
media_device_kpad_to_upad(&entity->pads[p], &pad);
if (copy_to_user(&links->pads[p], &pad, sizeof(pad)))
return -EFAULT;
}
}
if (links->links) {
struct media_link *link;
struct media_link_desc __user *ulink_desc = links->links;
list_for_each_entry(link, &entity->links, list) {
struct media_link_desc klink_desc;
/* Ignore backlinks. */
if (link->source->entity != entity)
continue;
memset(&klink_desc, 0, sizeof(klink_desc));
media_device_kpad_to_upad(link->source,
&klink_desc.source);
media_device_kpad_to_upad(link->sink,
&klink_desc.sink);
klink_desc.flags = link->flags;
if (copy_to_user(ulink_desc, &klink_desc,
sizeof(*ulink_desc)))
return -EFAULT;
ulink_desc++;
}
}
memset(links->reserved, 0, sizeof(links->reserved));
return 0;
}
static long media_device_setup_link(struct media_device *mdev, void *arg)
{
struct media_link_desc *linkd = arg;
struct media_link *link = NULL;
struct media_entity *source;
struct media_entity *sink;
/* Find the source and sink entities and link.
*/
source = find_entity(mdev, linkd->source.entity);
sink = find_entity(mdev, linkd->sink.entity);
if (source == NULL || sink == NULL)
return -EINVAL;
if (linkd->source.index >= source->num_pads ||
linkd->sink.index >= sink->num_pads)
return -EINVAL;
link = media_entity_find_link(&source->pads[linkd->source.index],
&sink->pads[linkd->sink.index]);
if (link == NULL)
return -EINVAL;
memset(linkd->reserved, 0, sizeof(linkd->reserved));
/* Setup the link on both entities. */
return __media_entity_setup_link(link, linkd->flags);
}
static long media_device_get_topology(struct media_device *mdev, void *arg)
{
struct media_v2_topology *topo = arg;
struct media_entity *entity;
struct media_interface *intf;
struct media_pad *pad;
struct media_link *link;
struct media_v2_entity kentity, __user *uentity;
struct media_v2_interface kintf, __user *uintf;
struct media_v2_pad kpad, __user *upad;
struct media_v2_link klink, __user *ulink;
unsigned int i;
int ret = 0;
topo->topology_version = mdev->topology_version;
/* Get entities and number of entities */
i = 0;
uentity = media_get_uptr(topo->ptr_entities);
media_device_for_each_entity(entity, mdev) {
i++;
if (ret || !uentity)
continue;
if (i > topo->num_entities) {
ret = -ENOSPC;
continue;
}
/* Copy fields to userspace struct if not error */
memset(&kentity, 0, sizeof(kentity));
kentity.id = entity->graph_obj.id;
kentity.function = entity->function;
kentity.flags = entity->flags;
strscpy(kentity.name, entity->name,
sizeof(kentity.name));
if (copy_to_user(uentity, &kentity, sizeof(kentity)))
ret = -EFAULT;
uentity++;
}
topo->num_entities = i;
topo->reserved1 = 0;
/* Get interfaces and number of interfaces */
i = 0;
uintf = media_get_uptr(topo->ptr_interfaces);
media_device_for_each_intf(intf, mdev) {
i++;
if (ret || !uintf)
continue;
if (i > topo->num_interfaces) {
ret = -ENOSPC;
continue;
}
memset(&kintf, 0, sizeof(kintf));
/* Copy intf fields to userspace struct */
kintf.id = intf->graph_obj.id;
kintf.intf_type = intf->type;
kintf.flags = intf->flags;
if (media_type(&intf->graph_obj) == MEDIA_GRAPH_INTF_DEVNODE) {
struct media_intf_devnode *devnode;
devnode = intf_to_devnode(intf);
kintf.devnode.major = devnode->major;
kintf.devnode.minor = devnode->minor;
}
if (copy_to_user(uintf, &kintf, sizeof(kintf)))
ret = -EFAULT;
uintf++;
}
topo->num_interfaces = i;
topo->reserved2 = 0;
/* Get pads and number of pads */
i = 0;
upad = media_get_uptr(topo->ptr_pads);
media_device_for_each_pad(pad, mdev) {
i++;
if (ret || !upad)
continue;
if (i > topo->num_pads) {
ret = -ENOSPC;
continue;
}
memset(&kpad, 0, sizeof(kpad));
/* Copy pad fields to userspace struct */
kpad.id = pad->graph_obj.id;
kpad.entity_id = pad->entity->graph_obj.id;
kpad.flags = pad->flags;
kpad.index = pad->index;
if (copy_to_user(upad, &kpad, sizeof(kpad)))
ret = -EFAULT;
upad++;
}
topo->num_pads = i;
topo->reserved3 = 0;
/* Get links and number of links */
i = 0;
ulink = media_get_uptr(topo->ptr_links);
media_device_for_each_link(link, mdev) {
if (link->is_backlink)
continue;
i++;
if (ret || !ulink)
continue;
if (i > topo->num_links) {
ret = -ENOSPC;
continue;
}
memset(&klink, 0, sizeof(klink));
/* Copy link fields to userspace struct */
klink.id = link->graph_obj.id;
klink.source_id = link->gobj0->id;
klink.sink_id = link->gobj1->id;
klink.flags = link->flags;
if (copy_to_user(ulink, &klink, sizeof(klink)))
ret = -EFAULT;
ulink++;
}
topo->num_links = i;
topo->reserved4 = 0;
return ret;
}
media: media-request: implement media requests Add initial media request support: 1) Add MEDIA_IOC_REQUEST_ALLOC ioctl support to media-device.c 2) Add struct media_request to store request objects. 3) Add struct media_request_object to represent a request object. 4) Add MEDIA_REQUEST_IOC_QUEUE/REINIT ioctl support. Basic lifecycle: the application allocates a request, adds objects to it, queues the request, polls until it is completed and can then read the final values of the objects at the time of completion. When it closes the file descriptor the request memory will be freed (actually, when the last user of that request releases the request). Drivers will bind an object to a request (the 'adds objects to it' phase), when MEDIA_REQUEST_IOC_QUEUE is called the request is validated (req_validate op), then queued (the req_queue op). When done with an object it can either be unbound from the request (e.g. when the driver has finished with a vb2 buffer) or marked as completed (e.g. for controls associated with a buffer). When all objects in the request are completed (or unbound), then the request fd will signal an exception (poll). Co-developed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Co-developed-by: Alexandre Courbot <acourbot@chromium.org> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-05-21 16:54:27 +08:00
static long media_device_request_alloc(struct media_device *mdev,
int *alloc_fd)
{
#ifdef CONFIG_MEDIA_CONTROLLER_REQUEST_API
media: media-request: implement media requests Add initial media request support: 1) Add MEDIA_IOC_REQUEST_ALLOC ioctl support to media-device.c 2) Add struct media_request to store request objects. 3) Add struct media_request_object to represent a request object. 4) Add MEDIA_REQUEST_IOC_QUEUE/REINIT ioctl support. Basic lifecycle: the application allocates a request, adds objects to it, queues the request, polls until it is completed and can then read the final values of the objects at the time of completion. When it closes the file descriptor the request memory will be freed (actually, when the last user of that request releases the request). Drivers will bind an object to a request (the 'adds objects to it' phase), when MEDIA_REQUEST_IOC_QUEUE is called the request is validated (req_validate op), then queued (the req_queue op). When done with an object it can either be unbound from the request (e.g. when the driver has finished with a vb2 buffer) or marked as completed (e.g. for controls associated with a buffer). When all objects in the request are completed (or unbound), then the request fd will signal an exception (poll). Co-developed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Co-developed-by: Alexandre Courbot <acourbot@chromium.org> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-05-21 16:54:27 +08:00
if (!mdev->ops || !mdev->ops->req_validate || !mdev->ops->req_queue)
return -ENOTTY;
return media_request_alloc(mdev, alloc_fd);
#else
return -ENOTTY;
#endif
media: media-request: implement media requests Add initial media request support: 1) Add MEDIA_IOC_REQUEST_ALLOC ioctl support to media-device.c 2) Add struct media_request to store request objects. 3) Add struct media_request_object to represent a request object. 4) Add MEDIA_REQUEST_IOC_QUEUE/REINIT ioctl support. Basic lifecycle: the application allocates a request, adds objects to it, queues the request, polls until it is completed and can then read the final values of the objects at the time of completion. When it closes the file descriptor the request memory will be freed (actually, when the last user of that request releases the request). Drivers will bind an object to a request (the 'adds objects to it' phase), when MEDIA_REQUEST_IOC_QUEUE is called the request is validated (req_validate op), then queued (the req_queue op). When done with an object it can either be unbound from the request (e.g. when the driver has finished with a vb2 buffer) or marked as completed (e.g. for controls associated with a buffer). When all objects in the request are completed (or unbound), then the request fd will signal an exception (poll). Co-developed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Co-developed-by: Alexandre Courbot <acourbot@chromium.org> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-05-21 16:54:27 +08:00
}
static long copy_arg_from_user(void *karg, void __user *uarg, unsigned int cmd)
{
media: media-request: implement media requests Add initial media request support: 1) Add MEDIA_IOC_REQUEST_ALLOC ioctl support to media-device.c 2) Add struct media_request to store request objects. 3) Add struct media_request_object to represent a request object. 4) Add MEDIA_REQUEST_IOC_QUEUE/REINIT ioctl support. Basic lifecycle: the application allocates a request, adds objects to it, queues the request, polls until it is completed and can then read the final values of the objects at the time of completion. When it closes the file descriptor the request memory will be freed (actually, when the last user of that request releases the request). Drivers will bind an object to a request (the 'adds objects to it' phase), when MEDIA_REQUEST_IOC_QUEUE is called the request is validated (req_validate op), then queued (the req_queue op). When done with an object it can either be unbound from the request (e.g. when the driver has finished with a vb2 buffer) or marked as completed (e.g. for controls associated with a buffer). When all objects in the request are completed (or unbound), then the request fd will signal an exception (poll). Co-developed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Co-developed-by: Alexandre Courbot <acourbot@chromium.org> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-05-21 16:54:27 +08:00
if ((_IOC_DIR(cmd) & _IOC_WRITE) &&
copy_from_user(karg, uarg, _IOC_SIZE(cmd)))
return -EFAULT;
return 0;
}
static long copy_arg_to_user(void __user *uarg, void *karg, unsigned int cmd)
{
media: media-request: implement media requests Add initial media request support: 1) Add MEDIA_IOC_REQUEST_ALLOC ioctl support to media-device.c 2) Add struct media_request to store request objects. 3) Add struct media_request_object to represent a request object. 4) Add MEDIA_REQUEST_IOC_QUEUE/REINIT ioctl support. Basic lifecycle: the application allocates a request, adds objects to it, queues the request, polls until it is completed and can then read the final values of the objects at the time of completion. When it closes the file descriptor the request memory will be freed (actually, when the last user of that request releases the request). Drivers will bind an object to a request (the 'adds objects to it' phase), when MEDIA_REQUEST_IOC_QUEUE is called the request is validated (req_validate op), then queued (the req_queue op). When done with an object it can either be unbound from the request (e.g. when the driver has finished with a vb2 buffer) or marked as completed (e.g. for controls associated with a buffer). When all objects in the request are completed (or unbound), then the request fd will signal an exception (poll). Co-developed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Co-developed-by: Alexandre Courbot <acourbot@chromium.org> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-05-21 16:54:27 +08:00
if ((_IOC_DIR(cmd) & _IOC_READ) &&
copy_to_user(uarg, karg, _IOC_SIZE(cmd)))
return -EFAULT;
return 0;
}
/* Do acquire the graph mutex */
#define MEDIA_IOC_FL_GRAPH_MUTEX BIT(0)
#define MEDIA_IOC_ARG(__cmd, func, fl, from_user, to_user) \
[_IOC_NR(MEDIA_IOC_##__cmd)] = { \
.cmd = MEDIA_IOC_##__cmd, \
.fn = (long (*)(struct media_device *, void *))func, \
.flags = fl, \
.arg_from_user = from_user, \
.arg_to_user = to_user, \
}
#define MEDIA_IOC(__cmd, func, fl) \
MEDIA_IOC_ARG(__cmd, func, fl, copy_arg_from_user, copy_arg_to_user)
/* the table is indexed by _IOC_NR(cmd) */
struct media_ioctl_info {
unsigned int cmd;
unsigned short flags;
long (*fn)(struct media_device *dev, void *arg);
long (*arg_from_user)(void *karg, void __user *uarg, unsigned int cmd);
long (*arg_to_user)(void __user *uarg, void *karg, unsigned int cmd);
};
static const struct media_ioctl_info ioctl_info[] = {
MEDIA_IOC(DEVICE_INFO, media_device_get_info, MEDIA_IOC_FL_GRAPH_MUTEX),
MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities, MEDIA_IOC_FL_GRAPH_MUTEX),
MEDIA_IOC(ENUM_LINKS, media_device_enum_links, MEDIA_IOC_FL_GRAPH_MUTEX),
MEDIA_IOC(SETUP_LINK, media_device_setup_link, MEDIA_IOC_FL_GRAPH_MUTEX),
MEDIA_IOC(G_TOPOLOGY, media_device_get_topology, MEDIA_IOC_FL_GRAPH_MUTEX),
media: media-request: implement media requests Add initial media request support: 1) Add MEDIA_IOC_REQUEST_ALLOC ioctl support to media-device.c 2) Add struct media_request to store request objects. 3) Add struct media_request_object to represent a request object. 4) Add MEDIA_REQUEST_IOC_QUEUE/REINIT ioctl support. Basic lifecycle: the application allocates a request, adds objects to it, queues the request, polls until it is completed and can then read the final values of the objects at the time of completion. When it closes the file descriptor the request memory will be freed (actually, when the last user of that request releases the request). Drivers will bind an object to a request (the 'adds objects to it' phase), when MEDIA_REQUEST_IOC_QUEUE is called the request is validated (req_validate op), then queued (the req_queue op). When done with an object it can either be unbound from the request (e.g. when the driver has finished with a vb2 buffer) or marked as completed (e.g. for controls associated with a buffer). When all objects in the request are completed (or unbound), then the request fd will signal an exception (poll). Co-developed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Co-developed-by: Alexandre Courbot <acourbot@chromium.org> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-05-21 16:54:27 +08:00
MEDIA_IOC(REQUEST_ALLOC, media_device_request_alloc, 0),
};
static long media_device_ioctl(struct file *filp, unsigned int cmd,
unsigned long __arg)
{
struct media_devnode *devnode = media_devnode_data(filp);
struct media_device *dev = devnode->media_dev;
const struct media_ioctl_info *info;
void __user *arg = (void __user *)__arg;
char __karg[256], *karg = __karg;
long ret;
if (_IOC_NR(cmd) >= ARRAY_SIZE(ioctl_info)
|| ioctl_info[_IOC_NR(cmd)].cmd != cmd)
return -ENOIOCTLCMD;
info = &ioctl_info[_IOC_NR(cmd)];
if (_IOC_SIZE(info->cmd) > sizeof(__karg)) {
karg = kmalloc(_IOC_SIZE(info->cmd), GFP_KERNEL);
if (!karg)
return -ENOMEM;
}
if (info->arg_from_user) {
ret = info->arg_from_user(karg, arg, cmd);
if (ret)
goto out_free;
}
if (info->flags & MEDIA_IOC_FL_GRAPH_MUTEX)
mutex_lock(&dev->graph_mutex);
ret = info->fn(dev, karg);
if (info->flags & MEDIA_IOC_FL_GRAPH_MUTEX)
mutex_unlock(&dev->graph_mutex);
if (!ret && info->arg_to_user)
ret = info->arg_to_user(arg, karg, cmd);
out_free:
if (karg != __karg)
kfree(karg);
return ret;
}
#ifdef CONFIG_COMPAT
struct media_links_enum32 {
__u32 entity;
compat_uptr_t pads; /* struct media_pad_desc * */
compat_uptr_t links; /* struct media_link_desc * */
__u32 reserved[4];
};
static long media_device_enum_links32(struct media_device *mdev,
struct media_links_enum32 __user *ulinks)
{
struct media_links_enum links;
compat_uptr_t pads_ptr, links_ptr;
memset(&links, 0, sizeof(links));
if (get_user(links.entity, &ulinks->entity)
|| get_user(pads_ptr, &ulinks->pads)
|| get_user(links_ptr, &ulinks->links))
return -EFAULT;
links.pads = compat_ptr(pads_ptr);
links.links = compat_ptr(links_ptr);
return media_device_enum_links(mdev, &links);
}
#define MEDIA_IOC_ENUM_LINKS32 _IOWR('|', 0x02, struct media_links_enum32)
static long media_device_compat_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
{
struct media_devnode *devnode = media_devnode_data(filp);
struct media_device *dev = devnode->media_dev;
long ret;
switch (cmd) {
case MEDIA_IOC_ENUM_LINKS32:
mutex_lock(&dev->graph_mutex);
ret = media_device_enum_links32(dev,
(struct media_links_enum32 __user *)arg);
mutex_unlock(&dev->graph_mutex);
break;
default:
return media_device_ioctl(filp, cmd, arg);
}
return ret;
}
#endif /* CONFIG_COMPAT */
static const struct media_file_operations media_device_fops = {
.owner = THIS_MODULE,
.open = media_device_open,
.ioctl = media_device_ioctl,
#ifdef CONFIG_COMPAT
.compat_ioctl = media_device_compat_ioctl,
#endif /* CONFIG_COMPAT */
.release = media_device_close,
};
/* -----------------------------------------------------------------------------
* sysfs
*/
static ssize_t show_model(struct device *cd,
struct device_attribute *attr, char *buf)
{
struct media_devnode *devnode = to_media_devnode(cd);
struct media_device *mdev = devnode->media_dev;
return sprintf(buf, "%.*s\n", (int)sizeof(mdev->model), mdev->model);
}
static DEVICE_ATTR(model, S_IRUGO, show_model, NULL);
/* -----------------------------------------------------------------------------
* Registration/unregistration
*/
static void media_device_release(struct media_devnode *devnode)
{
dev_dbg(devnode->parent, "Media device released\n");
}
/**
* media_device_register_entity - Register an entity with a media device
* @mdev: The media device
* @entity: The entity
*/
int __must_check media_device_register_entity(struct media_device *mdev,
struct media_entity *entity)
{
struct media_entity_notify *notify, *next;
unsigned int i;
[media] media-entity: don't sleep at media_device_register_entity() media_device_register_entity() is protected by a spin_lock. Calling ida_pre_get() with GFP_KERNEL may put it to sleep, with is a bad idea and causes this warning: [ 8812.397195] BUG: sleeping function called from invalid context at mm/slub.c:1287 [ 8812.397203] in_atomic(): 1, irqs_disabled(): 0, pid: 15179, name: modprobe [ 8812.397207] INFO: lockdep is turned off. [ 8812.397213] CPU: 2 PID: 15179 Comm: modprobe Tainted: G B 4.4.0-rc2+ #41 [ 8812.397218] Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015 [ 8812.397222] 0000000000000000 ffff880314c77268 ffffffff818f8ba7 ffff8803b17dde00 [ 8812.397232] ffff880314c77290 ffffffff811c2ee5 ffff8803b17dde00 ffffffff8284dbc9 [ 8812.397241] 0000000000000507 ffff880314c772d0 ffffffff811c30d5 0000000041b58ab3 [ 8812.397250] Call Trace: [ 8812.397258] [<ffffffff818f8ba7>] dump_stack+0x4b/0x64 [ 8812.397265] [<ffffffff811c2ee5>] ___might_sleep+0x245/0x3a0 [ 8812.397270] [<ffffffff811c30d5>] __might_sleep+0x95/0x1a0 [ 8812.397276] [<ffffffff818fd083>] ? ida_pre_get+0x113/0x250 [ 8812.397282] [<ffffffff8153bb77>] kmem_cache_alloc+0x197/0x250 [ 8812.397288] [<ffffffff818fd083>] ida_pre_get+0x113/0x250 [ 8812.397293] [<ffffffff818fd265>] ida_simple_get+0xa5/0x170 [ 8812.397298] [<ffffffff818fd1c0>] ? ida_pre_get+0x250/0x250 [ 8812.397306] [<ffffffffa07382d1>] media_device_register_entity+0x171/0x420 [media] [ 8812.397318] [<ffffffffa129e76f>] v4l2_device_register_subdev+0x34f/0x640 [videodev] [ 8812.397324] [<ffffffffa0768dea>] v4l2_i2c_new_subdev_board+0x12a/0x250 [v4l2_common] [ 8812.397330] [<ffffffffa0768fe7>] v4l2_i2c_new_subdev+0xd7/0x110 [v4l2_common] [ 8812.397337] [<ffffffffa0768f10>] ? v4l2_i2c_new_subdev_board+0x250/0x250 [v4l2_common] [ 8812.397347] [<ffffffffa13d2f76>] au0828_card_analog_fe_setup+0x2e6/0x3f0 [au0828] [ 8812.397352] [<ffffffff814450cc>] ? power_down+0xc4/0xc4 [ 8812.397361] [<ffffffffa13d2c90>] ? au0828_tuner_callback+0x160/0x160 [au0828] [ 8812.397370] [<ffffffffa13d319f>] au0828_card_setup+0x11f/0x340 [au0828] [ 8812.397378] [<ffffffffa13d3080>] ? au0828_card_analog_fe_setup+0x3f0/0x3f0 [au0828] [ 8812.397384] [<ffffffff812a575b>] ? msleep+0x7b/0xc0 [ 8812.397393] [<ffffffffa13d0d79>] au0828_usb_probe+0x679/0xcf0 [au0828] [ 8812.397399] [<ffffffff81d7619d>] usb_probe_interface+0x45d/0x940 [ 8812.397406] [<ffffffff81ca7004>] driver_probe_device+0x454/0xd90 [ 8812.397411] [<ffffffff81ca7940>] ? driver_probe_device+0xd90/0xd90 [ 8812.397417] [<ffffffff81ca7940>] ? driver_probe_device+0xd90/0xd90 [ 8812.397422] [<ffffffff81ca7a61>] __driver_attach+0x121/0x160 [ 8812.397427] [<ffffffff81ca141f>] bus_for_each_dev+0x11f/0x1a0 [ 8812.397433] [<ffffffff81ca1300>] ? subsys_dev_iter_exit+0x10/0x10 [ 8812.397439] [<ffffffff822917d7>] ? _raw_spin_unlock+0x27/0x40 [ 8812.397445] [<ffffffff81ca5d4d>] driver_attach+0x3d/0x50 [ 8812.397450] [<ffffffff81ca5039>] bus_add_driver+0x4c9/0x770 [ 8812.397456] [<ffffffff81ca944c>] driver_register+0x18c/0x3b0 [ 8812.397462] [<ffffffff8124c952>] ? __raw_spin_lock_init+0x32/0x100 [ 8812.397468] [<ffffffff81d71e58>] usb_register_driver+0x1f8/0x440 [ 8812.397473] [<ffffffffa0208000>] ? 0xffffffffa0208000 [ 8812.397481] [<ffffffffa02080b7>] au0828_init+0xb7/0x1000 [au0828] [ 8812.397486] [<ffffffff810021b1>] do_one_initcall+0x141/0x300 [ 8812.397492] [<ffffffff81002070>] ? try_to_run_init_process+0x40/0x40 [ 8812.397497] [<ffffffff8123bbf6>] ? trace_hardirqs_on_caller+0x16/0x590 [ 8812.397502] [<ffffffff815406e6>] ? kasan_unpoison_shadow+0x36/0x50 [ 8812.397507] [<ffffffff815406e6>] ? kasan_unpoison_shadow+0x36/0x50 [ 8812.397512] [<ffffffff815406e6>] ? kasan_unpoison_shadow+0x36/0x50 [ 8812.397517] [<ffffffff815407f7>] ? __asan_register_globals+0x87/0xa0 [ 8812.397524] [<ffffffff814454e5>] do_init_module+0x1d0/0x5a4 [ 8812.397530] [<ffffffff812ed7e8>] load_module+0x6648/0x9d70 [ 8812.397535] [<ffffffff812e4b70>] ? symbol_put_addr+0x50/0x50 [ 8812.397546] [<ffffffff812e71a0>] ? module_frob_arch_sections+0x20/0x20 [ 8812.397552] [<ffffffff8158e950>] ? open_exec+0x50/0x50 [ 8812.397559] [<ffffffff811648db>] ? ns_capable+0x5b/0xd0 [ 8812.397565] [<ffffffff812f1208>] SyS_finit_module+0x108/0x130 [ 8812.397571] [<ffffffff812f1100>] ? SyS_init_module+0x1f0/0x1f0 [ 8812.397576] [<ffffffff81004044>] ? lockdep_sys_exit_thunk+0x12/0x14 [ 8812.397582] [<ffffffff82292236>] entry_SYSCALL_64_fastpath+0x16/0x7a Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-12-17 01:33:54 +08:00
int ret;
if (entity->function == MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN ||
entity->function == MEDIA_ENT_F_UNKNOWN)
dev_warn(mdev->dev,
"Entity type for entity %s was not initialized!\n",
entity->name);
/* Warn if we apparently re-register an entity */
WARN_ON(entity->graph_obj.mdev != NULL);
entity->graph_obj.mdev = mdev;
INIT_LIST_HEAD(&entity->links);
entity->num_links = 0;
entity->num_backlinks = 0;
ret = ida_alloc_min(&mdev->entity_internal_idx, 1, GFP_KERNEL);
if (ret < 0)
[media] media-entity: don't sleep at media_device_register_entity() media_device_register_entity() is protected by a spin_lock. Calling ida_pre_get() with GFP_KERNEL may put it to sleep, with is a bad idea and causes this warning: [ 8812.397195] BUG: sleeping function called from invalid context at mm/slub.c:1287 [ 8812.397203] in_atomic(): 1, irqs_disabled(): 0, pid: 15179, name: modprobe [ 8812.397207] INFO: lockdep is turned off. [ 8812.397213] CPU: 2 PID: 15179 Comm: modprobe Tainted: G B 4.4.0-rc2+ #41 [ 8812.397218] Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015 [ 8812.397222] 0000000000000000 ffff880314c77268 ffffffff818f8ba7 ffff8803b17dde00 [ 8812.397232] ffff880314c77290 ffffffff811c2ee5 ffff8803b17dde00 ffffffff8284dbc9 [ 8812.397241] 0000000000000507 ffff880314c772d0 ffffffff811c30d5 0000000041b58ab3 [ 8812.397250] Call Trace: [ 8812.397258] [<ffffffff818f8ba7>] dump_stack+0x4b/0x64 [ 8812.397265] [<ffffffff811c2ee5>] ___might_sleep+0x245/0x3a0 [ 8812.397270] [<ffffffff811c30d5>] __might_sleep+0x95/0x1a0 [ 8812.397276] [<ffffffff818fd083>] ? ida_pre_get+0x113/0x250 [ 8812.397282] [<ffffffff8153bb77>] kmem_cache_alloc+0x197/0x250 [ 8812.397288] [<ffffffff818fd083>] ida_pre_get+0x113/0x250 [ 8812.397293] [<ffffffff818fd265>] ida_simple_get+0xa5/0x170 [ 8812.397298] [<ffffffff818fd1c0>] ? ida_pre_get+0x250/0x250 [ 8812.397306] [<ffffffffa07382d1>] media_device_register_entity+0x171/0x420 [media] [ 8812.397318] [<ffffffffa129e76f>] v4l2_device_register_subdev+0x34f/0x640 [videodev] [ 8812.397324] [<ffffffffa0768dea>] v4l2_i2c_new_subdev_board+0x12a/0x250 [v4l2_common] [ 8812.397330] [<ffffffffa0768fe7>] v4l2_i2c_new_subdev+0xd7/0x110 [v4l2_common] [ 8812.397337] [<ffffffffa0768f10>] ? v4l2_i2c_new_subdev_board+0x250/0x250 [v4l2_common] [ 8812.397347] [<ffffffffa13d2f76>] au0828_card_analog_fe_setup+0x2e6/0x3f0 [au0828] [ 8812.397352] [<ffffffff814450cc>] ? power_down+0xc4/0xc4 [ 8812.397361] [<ffffffffa13d2c90>] ? au0828_tuner_callback+0x160/0x160 [au0828] [ 8812.397370] [<ffffffffa13d319f>] au0828_card_setup+0x11f/0x340 [au0828] [ 8812.397378] [<ffffffffa13d3080>] ? au0828_card_analog_fe_setup+0x3f0/0x3f0 [au0828] [ 8812.397384] [<ffffffff812a575b>] ? msleep+0x7b/0xc0 [ 8812.397393] [<ffffffffa13d0d79>] au0828_usb_probe+0x679/0xcf0 [au0828] [ 8812.397399] [<ffffffff81d7619d>] usb_probe_interface+0x45d/0x940 [ 8812.397406] [<ffffffff81ca7004>] driver_probe_device+0x454/0xd90 [ 8812.397411] [<ffffffff81ca7940>] ? driver_probe_device+0xd90/0xd90 [ 8812.397417] [<ffffffff81ca7940>] ? driver_probe_device+0xd90/0xd90 [ 8812.397422] [<ffffffff81ca7a61>] __driver_attach+0x121/0x160 [ 8812.397427] [<ffffffff81ca141f>] bus_for_each_dev+0x11f/0x1a0 [ 8812.397433] [<ffffffff81ca1300>] ? subsys_dev_iter_exit+0x10/0x10 [ 8812.397439] [<ffffffff822917d7>] ? _raw_spin_unlock+0x27/0x40 [ 8812.397445] [<ffffffff81ca5d4d>] driver_attach+0x3d/0x50 [ 8812.397450] [<ffffffff81ca5039>] bus_add_driver+0x4c9/0x770 [ 8812.397456] [<ffffffff81ca944c>] driver_register+0x18c/0x3b0 [ 8812.397462] [<ffffffff8124c952>] ? __raw_spin_lock_init+0x32/0x100 [ 8812.397468] [<ffffffff81d71e58>] usb_register_driver+0x1f8/0x440 [ 8812.397473] [<ffffffffa0208000>] ? 0xffffffffa0208000 [ 8812.397481] [<ffffffffa02080b7>] au0828_init+0xb7/0x1000 [au0828] [ 8812.397486] [<ffffffff810021b1>] do_one_initcall+0x141/0x300 [ 8812.397492] [<ffffffff81002070>] ? try_to_run_init_process+0x40/0x40 [ 8812.397497] [<ffffffff8123bbf6>] ? trace_hardirqs_on_caller+0x16/0x590 [ 8812.397502] [<ffffffff815406e6>] ? kasan_unpoison_shadow+0x36/0x50 [ 8812.397507] [<ffffffff815406e6>] ? kasan_unpoison_shadow+0x36/0x50 [ 8812.397512] [<ffffffff815406e6>] ? kasan_unpoison_shadow+0x36/0x50 [ 8812.397517] [<ffffffff815407f7>] ? __asan_register_globals+0x87/0xa0 [ 8812.397524] [<ffffffff814454e5>] do_init_module+0x1d0/0x5a4 [ 8812.397530] [<ffffffff812ed7e8>] load_module+0x6648/0x9d70 [ 8812.397535] [<ffffffff812e4b70>] ? symbol_put_addr+0x50/0x50 [ 8812.397546] [<ffffffff812e71a0>] ? module_frob_arch_sections+0x20/0x20 [ 8812.397552] [<ffffffff8158e950>] ? open_exec+0x50/0x50 [ 8812.397559] [<ffffffff811648db>] ? ns_capable+0x5b/0xd0 [ 8812.397565] [<ffffffff812f1208>] SyS_finit_module+0x108/0x130 [ 8812.397571] [<ffffffff812f1100>] ? SyS_init_module+0x1f0/0x1f0 [ 8812.397576] [<ffffffff81004044>] ? lockdep_sys_exit_thunk+0x12/0x14 [ 8812.397582] [<ffffffff82292236>] entry_SYSCALL_64_fastpath+0x16/0x7a Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-12-17 01:33:54 +08:00
return ret;
entity->internal_idx = ret;
mutex_lock(&mdev->graph_mutex);
mdev->entity_internal_idx_max =
max(mdev->entity_internal_idx_max, entity->internal_idx);
/* Initialize media_gobj embedded at the entity */
media_gobj_create(mdev, MEDIA_GRAPH_ENTITY, &entity->graph_obj);
/* Initialize objects at the pads */
for (i = 0; i < entity->num_pads; i++)
media_gobj_create(mdev, MEDIA_GRAPH_PAD,
&entity->pads[i].graph_obj);
/* invoke entity_notify callbacks */
list_for_each_entry_safe(notify, next, &mdev->entity_notify, list)
notify->notify(entity, notify->notify_data);
if (mdev->entity_internal_idx_max
>= mdev->pm_count_walk.ent_enum.idx_max) {
struct media_graph new = { .top = 0 };
/*
* Initialise the new graph walk before cleaning up
* the old one in order not to spoil the graph walk
* object of the media device if graph walk init fails.
*/
ret = media_graph_walk_init(&new, mdev);
if (ret) {
mutex_unlock(&mdev->graph_mutex);
return ret;
}
media_graph_walk_cleanup(&mdev->pm_count_walk);
mdev->pm_count_walk = new;
}
mutex_unlock(&mdev->graph_mutex);
return 0;
}
EXPORT_SYMBOL_GPL(media_device_register_entity);
static void __media_device_unregister_entity(struct media_entity *entity)
{
struct media_device *mdev = entity->graph_obj.mdev;
struct media_link *link, *tmp;
struct media_interface *intf;
unsigned int i;
ida_free(&mdev->entity_internal_idx, entity->internal_idx);
/* Remove all interface links pointing to this entity */
list_for_each_entry(intf, &mdev->interfaces, graph_obj.list) {
list_for_each_entry_safe(link, tmp, &intf->links, list) {
if (link->entity == entity)
__media_remove_intf_link(link);
}
}
/* Remove all data links that belong to this entity */
__media_entity_remove_links(entity);
/* Remove all pads that belong to this entity */
for (i = 0; i < entity->num_pads; i++)
media_gobj_destroy(&entity->pads[i].graph_obj);
/* Remove the entity */
media_gobj_destroy(&entity->graph_obj);
/* invoke entity_notify callbacks to handle entity removal?? */
entity->graph_obj.mdev = NULL;
}
void media_device_unregister_entity(struct media_entity *entity)
{
struct media_device *mdev = entity->graph_obj.mdev;
if (mdev == NULL)
return;
[media] media-device: get rid of the spinlock Right now, the lock schema for media_device struct is messy, since sometimes, it is protected via a spin lock, while, for media graph traversal, it is protected by a mutex. Solve this conflict by always using a mutex. As a side effect, this prevents a bug when the media notifiers is called at atomic context, while running the notifier callback: BUG: sleeping function called from invalid context at mm/slub.c:1289 in_atomic(): 1, irqs_disabled(): 0, pid: 3479, name: modprobe 4 locks held by modprobe/3479: #0: (&dev->mutex){......}, at: [<ffffffff81ce8933>] __driver_attach+0xa3/0x160 #1: (&dev->mutex){......}, at: [<ffffffff81ce8941>] __driver_attach+0xb1/0x160 #2: (register_mutex#5){+.+.+.}, at: [<ffffffffa10596c7>] usb_audio_probe+0x257/0x1c90 [snd_usb_audio] #3: (&(&mdev->lock)->rlock){+.+.+.}, at: [<ffffffffa0e6051b>] media_device_register_entity+0x1cb/0x700 [media] CPU: 2 PID: 3479 Comm: modprobe Not tainted 4.5.0-rc3+ #49 Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015 0000000000000000 ffff8803b3f6f288 ffffffff81933901 ffff8803c4bae000 ffff8803c4bae5c8 ffff8803b3f6f2b0 ffffffff811c6af5 ffff8803c4bae000 ffffffff8285d7f6 0000000000000509 ffff8803b3f6f2f0 ffffffff811c6ce5 Call Trace: [<ffffffff81933901>] dump_stack+0x85/0xc4 [<ffffffff811c6af5>] ___might_sleep+0x245/0x3a0 [<ffffffff811c6ce5>] __might_sleep+0x95/0x1a0 [<ffffffff8155aade>] kmem_cache_alloc_trace+0x20e/0x300 [<ffffffffa0e66e3d>] ? media_add_link+0x4d/0x140 [media] [<ffffffffa0e66e3d>] media_add_link+0x4d/0x140 [media] [<ffffffffa0e69931>] media_create_pad_link+0xa1/0x600 [media] [<ffffffffa0fe11b3>] au0828_media_graph_notify+0x173/0x360 [au0828] [<ffffffffa0e68a6a>] ? media_gobj_create+0x1ba/0x480 [media] [<ffffffffa0e606fb>] media_device_register_entity+0x3ab/0x700 [media] Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2016-04-06 21:55:24 +08:00
mutex_lock(&mdev->graph_mutex);
__media_device_unregister_entity(entity);
[media] media-device: get rid of the spinlock Right now, the lock schema for media_device struct is messy, since sometimes, it is protected via a spin lock, while, for media graph traversal, it is protected by a mutex. Solve this conflict by always using a mutex. As a side effect, this prevents a bug when the media notifiers is called at atomic context, while running the notifier callback: BUG: sleeping function called from invalid context at mm/slub.c:1289 in_atomic(): 1, irqs_disabled(): 0, pid: 3479, name: modprobe 4 locks held by modprobe/3479: #0: (&dev->mutex){......}, at: [<ffffffff81ce8933>] __driver_attach+0xa3/0x160 #1: (&dev->mutex){......}, at: [<ffffffff81ce8941>] __driver_attach+0xb1/0x160 #2: (register_mutex#5){+.+.+.}, at: [<ffffffffa10596c7>] usb_audio_probe+0x257/0x1c90 [snd_usb_audio] #3: (&(&mdev->lock)->rlock){+.+.+.}, at: [<ffffffffa0e6051b>] media_device_register_entity+0x1cb/0x700 [media] CPU: 2 PID: 3479 Comm: modprobe Not tainted 4.5.0-rc3+ #49 Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015 0000000000000000 ffff8803b3f6f288 ffffffff81933901 ffff8803c4bae000 ffff8803c4bae5c8 ffff8803b3f6f2b0 ffffffff811c6af5 ffff8803c4bae000 ffffffff8285d7f6 0000000000000509 ffff8803b3f6f2f0 ffffffff811c6ce5 Call Trace: [<ffffffff81933901>] dump_stack+0x85/0xc4 [<ffffffff811c6af5>] ___might_sleep+0x245/0x3a0 [<ffffffff811c6ce5>] __might_sleep+0x95/0x1a0 [<ffffffff8155aade>] kmem_cache_alloc_trace+0x20e/0x300 [<ffffffffa0e66e3d>] ? media_add_link+0x4d/0x140 [media] [<ffffffffa0e66e3d>] media_add_link+0x4d/0x140 [media] [<ffffffffa0e69931>] media_create_pad_link+0xa1/0x600 [media] [<ffffffffa0fe11b3>] au0828_media_graph_notify+0x173/0x360 [au0828] [<ffffffffa0e68a6a>] ? media_gobj_create+0x1ba/0x480 [media] [<ffffffffa0e606fb>] media_device_register_entity+0x3ab/0x700 [media] Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2016-04-06 21:55:24 +08:00
mutex_unlock(&mdev->graph_mutex);
}
EXPORT_SYMBOL_GPL(media_device_unregister_entity);
/**
* media_device_init() - initialize a media device
* @mdev: The media device
*
* The caller is responsible for initializing the media device before
* registration. The following fields must be set:
*
* - dev must point to the parent device
* - model must be filled with the device model name
*/
void media_device_init(struct media_device *mdev)
{
[media] media: Entities, pads and links As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. An entity is a basic media hardware building block. It can correspond to a large variety of logical blocks such as physical hardware devices (CMOS sensor for instance), logical hardware devices (a building block in a System-on-Chip image processing pipeline), DMA channels or physical connectors. A pad is a connection endpoint through which an entity can interact with other entities. Data (not restricted to video) produced by an entity flows from the entity's output to one or more entity inputs. Pads should not be confused with physical pins at chip boundaries. A link is a point-to-point oriented connection between two pads, either on the same entity or on different entities. Data flows from a source pad to a sink pad. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil <hverkuil@xs4all.nl> initial work. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-12-09 19:40:00 +08:00
INIT_LIST_HEAD(&mdev->entities);
INIT_LIST_HEAD(&mdev->interfaces);
INIT_LIST_HEAD(&mdev->pads);
INIT_LIST_HEAD(&mdev->links);
INIT_LIST_HEAD(&mdev->entity_notify);
media: media-request: implement media requests Add initial media request support: 1) Add MEDIA_IOC_REQUEST_ALLOC ioctl support to media-device.c 2) Add struct media_request to store request objects. 3) Add struct media_request_object to represent a request object. 4) Add MEDIA_REQUEST_IOC_QUEUE/REINIT ioctl support. Basic lifecycle: the application allocates a request, adds objects to it, queues the request, polls until it is completed and can then read the final values of the objects at the time of completion. When it closes the file descriptor the request memory will be freed (actually, when the last user of that request releases the request). Drivers will bind an object to a request (the 'adds objects to it' phase), when MEDIA_REQUEST_IOC_QUEUE is called the request is validated (req_validate op), then queued (the req_queue op). When done with an object it can either be unbound from the request (e.g. when the driver has finished with a vb2 buffer) or marked as completed (e.g. for controls associated with a buffer). When all objects in the request are completed (or unbound), then the request fd will signal an exception (poll). Co-developed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Co-developed-by: Alexandre Courbot <acourbot@chromium.org> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-05-21 16:54:27 +08:00
mutex_init(&mdev->req_queue_mutex);
mutex_init(&mdev->graph_mutex);
ida_init(&mdev->entity_internal_idx);
[media] media: Entities, pads and links As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. An entity is a basic media hardware building block. It can correspond to a large variety of logical blocks such as physical hardware devices (CMOS sensor for instance), logical hardware devices (a building block in a System-on-Chip image processing pipeline), DMA channels or physical connectors. A pad is a connection endpoint through which an entity can interact with other entities. Data (not restricted to video) produced by an entity flows from the entity's output to one or more entity inputs. Pads should not be confused with physical pins at chip boundaries. A link is a point-to-point oriented connection between two pads, either on the same entity or on different entities. Data flows from a source pad to a sink pad. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil <hverkuil@xs4all.nl> initial work. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-12-09 19:40:00 +08:00
media: media-request: implement media requests Add initial media request support: 1) Add MEDIA_IOC_REQUEST_ALLOC ioctl support to media-device.c 2) Add struct media_request to store request objects. 3) Add struct media_request_object to represent a request object. 4) Add MEDIA_REQUEST_IOC_QUEUE/REINIT ioctl support. Basic lifecycle: the application allocates a request, adds objects to it, queues the request, polls until it is completed and can then read the final values of the objects at the time of completion. When it closes the file descriptor the request memory will be freed (actually, when the last user of that request releases the request). Drivers will bind an object to a request (the 'adds objects to it' phase), when MEDIA_REQUEST_IOC_QUEUE is called the request is validated (req_validate op), then queued (the req_queue op). When done with an object it can either be unbound from the request (e.g. when the driver has finished with a vb2 buffer) or marked as completed (e.g. for controls associated with a buffer). When all objects in the request are completed (or unbound), then the request fd will signal an exception (poll). Co-developed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Co-developed-by: Alexandre Courbot <acourbot@chromium.org> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-05-21 16:54:27 +08:00
atomic_set(&mdev->request_id, 0);
dev_dbg(mdev->dev, "Media device initialized\n");
}
EXPORT_SYMBOL_GPL(media_device_init);
void media_device_cleanup(struct media_device *mdev)
{
ida_destroy(&mdev->entity_internal_idx);
mdev->entity_internal_idx_max = 0;
media_graph_walk_cleanup(&mdev->pm_count_walk);
mutex_destroy(&mdev->graph_mutex);
media: media-request: implement media requests Add initial media request support: 1) Add MEDIA_IOC_REQUEST_ALLOC ioctl support to media-device.c 2) Add struct media_request to store request objects. 3) Add struct media_request_object to represent a request object. 4) Add MEDIA_REQUEST_IOC_QUEUE/REINIT ioctl support. Basic lifecycle: the application allocates a request, adds objects to it, queues the request, polls until it is completed and can then read the final values of the objects at the time of completion. When it closes the file descriptor the request memory will be freed (actually, when the last user of that request releases the request). Drivers will bind an object to a request (the 'adds objects to it' phase), when MEDIA_REQUEST_IOC_QUEUE is called the request is validated (req_validate op), then queued (the req_queue op). When done with an object it can either be unbound from the request (e.g. when the driver has finished with a vb2 buffer) or marked as completed (e.g. for controls associated with a buffer). When all objects in the request are completed (or unbound), then the request fd will signal an exception (poll). Co-developed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Co-developed-by: Alexandre Courbot <acourbot@chromium.org> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-05-21 16:54:27 +08:00
mutex_destroy(&mdev->req_queue_mutex);
}
EXPORT_SYMBOL_GPL(media_device_cleanup);
int __must_check __media_device_register(struct media_device *mdev,
struct module *owner)
{
struct media_devnode *devnode;
int ret;
devnode = kzalloc(sizeof(*devnode), GFP_KERNEL);
if (!devnode)
return -ENOMEM;
/* Register the device node. */
mdev->devnode = devnode;
devnode->fops = &media_device_fops;
devnode->parent = mdev->dev;
devnode->release = media_device_release;
/* Set version 0 to indicate user-space that the graph is static */
mdev->topology_version = 0;
ret = media_devnode_register(mdev, devnode, owner);
if (ret < 0) {
[media] media: fix use-after-free in cdev_put() when app exits after driver unbind When driver unbinds while media_ioctl is in progress, cdev_put() fails with when app exits after driver unbinds. Add devnode struct device kobj as the cdev parent kobject. cdev_add() gets a reference to it and releases it in cdev_del() ensuring that the devnode is not deallocated as long as the application has the device file open. media_devnode_register() initializes the struct device kobj before calling cdev_add(). media_devnode_unregister() does cdev_del() and then deletes the device. devnode is released when the last reference to the struct device is gone. This problem is found on uvcvideo, em28xx, and au0828 drivers and fix has been tested on all three. kernel: [ 193.599736] BUG: KASAN: use-after-free in cdev_put+0x4e/0x50 kernel: [ 193.599745] Read of size 8 by task media_device_te/1851 kernel: [ 193.599792] INFO: Allocated in __media_device_register+0x54 kernel: [ 193.599951] INFO: Freed in media_devnode_release+0xa4/0xc0 kernel: [ 193.601083] Call Trace: kernel: [ 193.601093] [<ffffffff81aecac3>] dump_stack+0x67/0x94 kernel: [ 193.601102] [<ffffffff815359b2>] print_trailer+0x112/0x1a0 kernel: [ 193.601111] [<ffffffff8153b5e4>] object_err+0x34/0x40 kernel: [ 193.601119] [<ffffffff8153d9d4>] kasan_report_error+0x224/0x530 kernel: [ 193.601128] [<ffffffff814a2c3d>] ? kzfree+0x2d/0x40 kernel: [ 193.601137] [<ffffffff81539d72>] ? kfree+0x1d2/0x1f0 kernel: [ 193.601154] [<ffffffff8157ca7e>] ? cdev_put+0x4e/0x50 kernel: [ 193.601162] [<ffffffff8157ca7e>] cdev_put+0x4e/0x50 kernel: [ 193.601170] [<ffffffff815767eb>] __fput+0x52b/0x6c0 kernel: [ 193.601179] [<ffffffff8117743a>] ? switch_task_namespaces+0x2a kernel: [ 193.601188] [<ffffffff815769ee>] ____fput+0xe/0x10 kernel: [ 193.601196] [<ffffffff81170023>] task_work_run+0x133/0x1f0 kernel: [ 193.601204] [<ffffffff8117746e>] ? switch_task_namespaces+0x5e kernel: [ 193.601213] [<ffffffff8111b50c>] do_exit+0x72c/0x2c20 kernel: [ 193.601224] [<ffffffff8111ade0>] ? release_task+0x1250/0x1250 - - - kernel: [ 193.601360] [<ffffffff81003587>] ? exit_to_usermode_loop+0xe7 kernel: [ 193.601368] [<ffffffff810035c0>] exit_to_usermode_loop+0x120 kernel: [ 193.601376] [<ffffffff810061da>] syscall_return_slowpath+0x16a kernel: [ 193.601386] [<ffffffff82848b33>] entry_SYSCALL_64_fastpath+0xa6 Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com> Tested-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-05-05 03:48:28 +08:00
/* devnode free is handled in media_devnode_*() */
mdev->devnode = NULL;
return ret;
}
ret = device_create_file(&devnode->dev, &dev_attr_model);
if (ret < 0) {
[media] media: fix use-after-free in cdev_put() when app exits after driver unbind When driver unbinds while media_ioctl is in progress, cdev_put() fails with when app exits after driver unbinds. Add devnode struct device kobj as the cdev parent kobject. cdev_add() gets a reference to it and releases it in cdev_del() ensuring that the devnode is not deallocated as long as the application has the device file open. media_devnode_register() initializes the struct device kobj before calling cdev_add(). media_devnode_unregister() does cdev_del() and then deletes the device. devnode is released when the last reference to the struct device is gone. This problem is found on uvcvideo, em28xx, and au0828 drivers and fix has been tested on all three. kernel: [ 193.599736] BUG: KASAN: use-after-free in cdev_put+0x4e/0x50 kernel: [ 193.599745] Read of size 8 by task media_device_te/1851 kernel: [ 193.599792] INFO: Allocated in __media_device_register+0x54 kernel: [ 193.599951] INFO: Freed in media_devnode_release+0xa4/0xc0 kernel: [ 193.601083] Call Trace: kernel: [ 193.601093] [<ffffffff81aecac3>] dump_stack+0x67/0x94 kernel: [ 193.601102] [<ffffffff815359b2>] print_trailer+0x112/0x1a0 kernel: [ 193.601111] [<ffffffff8153b5e4>] object_err+0x34/0x40 kernel: [ 193.601119] [<ffffffff8153d9d4>] kasan_report_error+0x224/0x530 kernel: [ 193.601128] [<ffffffff814a2c3d>] ? kzfree+0x2d/0x40 kernel: [ 193.601137] [<ffffffff81539d72>] ? kfree+0x1d2/0x1f0 kernel: [ 193.601154] [<ffffffff8157ca7e>] ? cdev_put+0x4e/0x50 kernel: [ 193.601162] [<ffffffff8157ca7e>] cdev_put+0x4e/0x50 kernel: [ 193.601170] [<ffffffff815767eb>] __fput+0x52b/0x6c0 kernel: [ 193.601179] [<ffffffff8117743a>] ? switch_task_namespaces+0x2a kernel: [ 193.601188] [<ffffffff815769ee>] ____fput+0xe/0x10 kernel: [ 193.601196] [<ffffffff81170023>] task_work_run+0x133/0x1f0 kernel: [ 193.601204] [<ffffffff8117746e>] ? switch_task_namespaces+0x5e kernel: [ 193.601213] [<ffffffff8111b50c>] do_exit+0x72c/0x2c20 kernel: [ 193.601224] [<ffffffff8111ade0>] ? release_task+0x1250/0x1250 - - - kernel: [ 193.601360] [<ffffffff81003587>] ? exit_to_usermode_loop+0xe7 kernel: [ 193.601368] [<ffffffff810035c0>] exit_to_usermode_loop+0x120 kernel: [ 193.601376] [<ffffffff810061da>] syscall_return_slowpath+0x16a kernel: [ 193.601386] [<ffffffff82848b33>] entry_SYSCALL_64_fastpath+0xa6 Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com> Tested-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-05-05 03:48:28 +08:00
/* devnode free is handled in media_devnode_*() */
mdev->devnode = NULL;
[media] media: fix media devnode ioctl/syscall and unregister race Media devnode open/ioctl could be in progress when media device unregister is initiated. System calls and ioctls check media device registered status at the beginning, however, there is a window where unregister could be in progress without changing the media devnode status to unregistered. process 1 process 2 fd = open(/dev/media0) media_devnode_is_registered() (returns true here) media_device_unregister() (unregister is in progress and devnode isn't unregistered yet) ... ioctl(fd, ...) __media_ioctl() media_devnode_is_registered() (returns true here) ... media_devnode_unregister() ... (driver releases the media device memory) media_device_ioctl() (By this point devnode->media_dev does not point to allocated memory. use-after free in in mutex_lock_nested) BUG: KASAN: use-after-free in mutex_lock_nested+0x79c/0x800 at addr ffff8801ebe914f0 Fix it by clearing register bit when unregister starts to avoid the race. process 1 process 2 fd = open(/dev/media0) media_devnode_is_registered() (could return true here) media_device_unregister() (clear the register bit, then start unregister.) ... ioctl(fd, ...) __media_ioctl() media_devnode_is_registered() (return false here, ioctl returns I/O error, and will not access media device memory) ... media_devnode_unregister() ... (driver releases the media device memory) Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com> Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reported-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Tested-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-06-11 01:37:23 +08:00
media_devnode_unregister_prepare(devnode);
media_devnode_unregister(devnode);
return ret;
}
dev_dbg(mdev->dev, "Media device registered\n");
return 0;
}
EXPORT_SYMBOL_GPL(__media_device_register);
int __must_check media_device_register_entity_notify(struct media_device *mdev,
struct media_entity_notify *nptr)
{
[media] media-device: get rid of the spinlock Right now, the lock schema for media_device struct is messy, since sometimes, it is protected via a spin lock, while, for media graph traversal, it is protected by a mutex. Solve this conflict by always using a mutex. As a side effect, this prevents a bug when the media notifiers is called at atomic context, while running the notifier callback: BUG: sleeping function called from invalid context at mm/slub.c:1289 in_atomic(): 1, irqs_disabled(): 0, pid: 3479, name: modprobe 4 locks held by modprobe/3479: #0: (&dev->mutex){......}, at: [<ffffffff81ce8933>] __driver_attach+0xa3/0x160 #1: (&dev->mutex){......}, at: [<ffffffff81ce8941>] __driver_attach+0xb1/0x160 #2: (register_mutex#5){+.+.+.}, at: [<ffffffffa10596c7>] usb_audio_probe+0x257/0x1c90 [snd_usb_audio] #3: (&(&mdev->lock)->rlock){+.+.+.}, at: [<ffffffffa0e6051b>] media_device_register_entity+0x1cb/0x700 [media] CPU: 2 PID: 3479 Comm: modprobe Not tainted 4.5.0-rc3+ #49 Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015 0000000000000000 ffff8803b3f6f288 ffffffff81933901 ffff8803c4bae000 ffff8803c4bae5c8 ffff8803b3f6f2b0 ffffffff811c6af5 ffff8803c4bae000 ffffffff8285d7f6 0000000000000509 ffff8803b3f6f2f0 ffffffff811c6ce5 Call Trace: [<ffffffff81933901>] dump_stack+0x85/0xc4 [<ffffffff811c6af5>] ___might_sleep+0x245/0x3a0 [<ffffffff811c6ce5>] __might_sleep+0x95/0x1a0 [<ffffffff8155aade>] kmem_cache_alloc_trace+0x20e/0x300 [<ffffffffa0e66e3d>] ? media_add_link+0x4d/0x140 [media] [<ffffffffa0e66e3d>] media_add_link+0x4d/0x140 [media] [<ffffffffa0e69931>] media_create_pad_link+0xa1/0x600 [media] [<ffffffffa0fe11b3>] au0828_media_graph_notify+0x173/0x360 [au0828] [<ffffffffa0e68a6a>] ? media_gobj_create+0x1ba/0x480 [media] [<ffffffffa0e606fb>] media_device_register_entity+0x3ab/0x700 [media] Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2016-04-06 21:55:24 +08:00
mutex_lock(&mdev->graph_mutex);
list_add_tail(&nptr->list, &mdev->entity_notify);
[media] media-device: get rid of the spinlock Right now, the lock schema for media_device struct is messy, since sometimes, it is protected via a spin lock, while, for media graph traversal, it is protected by a mutex. Solve this conflict by always using a mutex. As a side effect, this prevents a bug when the media notifiers is called at atomic context, while running the notifier callback: BUG: sleeping function called from invalid context at mm/slub.c:1289 in_atomic(): 1, irqs_disabled(): 0, pid: 3479, name: modprobe 4 locks held by modprobe/3479: #0: (&dev->mutex){......}, at: [<ffffffff81ce8933>] __driver_attach+0xa3/0x160 #1: (&dev->mutex){......}, at: [<ffffffff81ce8941>] __driver_attach+0xb1/0x160 #2: (register_mutex#5){+.+.+.}, at: [<ffffffffa10596c7>] usb_audio_probe+0x257/0x1c90 [snd_usb_audio] #3: (&(&mdev->lock)->rlock){+.+.+.}, at: [<ffffffffa0e6051b>] media_device_register_entity+0x1cb/0x700 [media] CPU: 2 PID: 3479 Comm: modprobe Not tainted 4.5.0-rc3+ #49 Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015 0000000000000000 ffff8803b3f6f288 ffffffff81933901 ffff8803c4bae000 ffff8803c4bae5c8 ffff8803b3f6f2b0 ffffffff811c6af5 ffff8803c4bae000 ffffffff8285d7f6 0000000000000509 ffff8803b3f6f2f0 ffffffff811c6ce5 Call Trace: [<ffffffff81933901>] dump_stack+0x85/0xc4 [<ffffffff811c6af5>] ___might_sleep+0x245/0x3a0 [<ffffffff811c6ce5>] __might_sleep+0x95/0x1a0 [<ffffffff8155aade>] kmem_cache_alloc_trace+0x20e/0x300 [<ffffffffa0e66e3d>] ? media_add_link+0x4d/0x140 [media] [<ffffffffa0e66e3d>] media_add_link+0x4d/0x140 [media] [<ffffffffa0e69931>] media_create_pad_link+0xa1/0x600 [media] [<ffffffffa0fe11b3>] au0828_media_graph_notify+0x173/0x360 [au0828] [<ffffffffa0e68a6a>] ? media_gobj_create+0x1ba/0x480 [media] [<ffffffffa0e606fb>] media_device_register_entity+0x3ab/0x700 [media] Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2016-04-06 21:55:24 +08:00
mutex_unlock(&mdev->graph_mutex);
return 0;
}
EXPORT_SYMBOL_GPL(media_device_register_entity_notify);
/*
* Note: Should be called with mdev->lock held.
*/
static void __media_device_unregister_entity_notify(struct media_device *mdev,
struct media_entity_notify *nptr)
{
list_del(&nptr->list);
}
void media_device_unregister_entity_notify(struct media_device *mdev,
struct media_entity_notify *nptr)
{
[media] media-device: get rid of the spinlock Right now, the lock schema for media_device struct is messy, since sometimes, it is protected via a spin lock, while, for media graph traversal, it is protected by a mutex. Solve this conflict by always using a mutex. As a side effect, this prevents a bug when the media notifiers is called at atomic context, while running the notifier callback: BUG: sleeping function called from invalid context at mm/slub.c:1289 in_atomic(): 1, irqs_disabled(): 0, pid: 3479, name: modprobe 4 locks held by modprobe/3479: #0: (&dev->mutex){......}, at: [<ffffffff81ce8933>] __driver_attach+0xa3/0x160 #1: (&dev->mutex){......}, at: [<ffffffff81ce8941>] __driver_attach+0xb1/0x160 #2: (register_mutex#5){+.+.+.}, at: [<ffffffffa10596c7>] usb_audio_probe+0x257/0x1c90 [snd_usb_audio] #3: (&(&mdev->lock)->rlock){+.+.+.}, at: [<ffffffffa0e6051b>] media_device_register_entity+0x1cb/0x700 [media] CPU: 2 PID: 3479 Comm: modprobe Not tainted 4.5.0-rc3+ #49 Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015 0000000000000000 ffff8803b3f6f288 ffffffff81933901 ffff8803c4bae000 ffff8803c4bae5c8 ffff8803b3f6f2b0 ffffffff811c6af5 ffff8803c4bae000 ffffffff8285d7f6 0000000000000509 ffff8803b3f6f2f0 ffffffff811c6ce5 Call Trace: [<ffffffff81933901>] dump_stack+0x85/0xc4 [<ffffffff811c6af5>] ___might_sleep+0x245/0x3a0 [<ffffffff811c6ce5>] __might_sleep+0x95/0x1a0 [<ffffffff8155aade>] kmem_cache_alloc_trace+0x20e/0x300 [<ffffffffa0e66e3d>] ? media_add_link+0x4d/0x140 [media] [<ffffffffa0e66e3d>] media_add_link+0x4d/0x140 [media] [<ffffffffa0e69931>] media_create_pad_link+0xa1/0x600 [media] [<ffffffffa0fe11b3>] au0828_media_graph_notify+0x173/0x360 [au0828] [<ffffffffa0e68a6a>] ? media_gobj_create+0x1ba/0x480 [media] [<ffffffffa0e606fb>] media_device_register_entity+0x3ab/0x700 [media] Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2016-04-06 21:55:24 +08:00
mutex_lock(&mdev->graph_mutex);
__media_device_unregister_entity_notify(mdev, nptr);
[media] media-device: get rid of the spinlock Right now, the lock schema for media_device struct is messy, since sometimes, it is protected via a spin lock, while, for media graph traversal, it is protected by a mutex. Solve this conflict by always using a mutex. As a side effect, this prevents a bug when the media notifiers is called at atomic context, while running the notifier callback: BUG: sleeping function called from invalid context at mm/slub.c:1289 in_atomic(): 1, irqs_disabled(): 0, pid: 3479, name: modprobe 4 locks held by modprobe/3479: #0: (&dev->mutex){......}, at: [<ffffffff81ce8933>] __driver_attach+0xa3/0x160 #1: (&dev->mutex){......}, at: [<ffffffff81ce8941>] __driver_attach+0xb1/0x160 #2: (register_mutex#5){+.+.+.}, at: [<ffffffffa10596c7>] usb_audio_probe+0x257/0x1c90 [snd_usb_audio] #3: (&(&mdev->lock)->rlock){+.+.+.}, at: [<ffffffffa0e6051b>] media_device_register_entity+0x1cb/0x700 [media] CPU: 2 PID: 3479 Comm: modprobe Not tainted 4.5.0-rc3+ #49 Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015 0000000000000000 ffff8803b3f6f288 ffffffff81933901 ffff8803c4bae000 ffff8803c4bae5c8 ffff8803b3f6f2b0 ffffffff811c6af5 ffff8803c4bae000 ffffffff8285d7f6 0000000000000509 ffff8803b3f6f2f0 ffffffff811c6ce5 Call Trace: [<ffffffff81933901>] dump_stack+0x85/0xc4 [<ffffffff811c6af5>] ___might_sleep+0x245/0x3a0 [<ffffffff811c6ce5>] __might_sleep+0x95/0x1a0 [<ffffffff8155aade>] kmem_cache_alloc_trace+0x20e/0x300 [<ffffffffa0e66e3d>] ? media_add_link+0x4d/0x140 [media] [<ffffffffa0e66e3d>] media_add_link+0x4d/0x140 [media] [<ffffffffa0e69931>] media_create_pad_link+0xa1/0x600 [media] [<ffffffffa0fe11b3>] au0828_media_graph_notify+0x173/0x360 [au0828] [<ffffffffa0e68a6a>] ? media_gobj_create+0x1ba/0x480 [media] [<ffffffffa0e606fb>] media_device_register_entity+0x3ab/0x700 [media] Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2016-04-06 21:55:24 +08:00
mutex_unlock(&mdev->graph_mutex);
}
EXPORT_SYMBOL_GPL(media_device_unregister_entity_notify);
void media_device_unregister(struct media_device *mdev)
{
[media] media: Entities, pads and links As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. An entity is a basic media hardware building block. It can correspond to a large variety of logical blocks such as physical hardware devices (CMOS sensor for instance), logical hardware devices (a building block in a System-on-Chip image processing pipeline), DMA channels or physical connectors. A pad is a connection endpoint through which an entity can interact with other entities. Data (not restricted to video) produced by an entity flows from the entity's output to one or more entity inputs. Pads should not be confused with physical pins at chip boundaries. A link is a point-to-point oriented connection between two pads, either on the same entity or on different entities. Data flows from a source pad to a sink pad. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil <hverkuil@xs4all.nl> initial work. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-12-09 19:40:00 +08:00
struct media_entity *entity;
struct media_entity *next;
struct media_interface *intf, *tmp_intf;
struct media_entity_notify *notify, *nextp;
if (mdev == NULL)
return;
[media] media-device: get rid of the spinlock Right now, the lock schema for media_device struct is messy, since sometimes, it is protected via a spin lock, while, for media graph traversal, it is protected by a mutex. Solve this conflict by always using a mutex. As a side effect, this prevents a bug when the media notifiers is called at atomic context, while running the notifier callback: BUG: sleeping function called from invalid context at mm/slub.c:1289 in_atomic(): 1, irqs_disabled(): 0, pid: 3479, name: modprobe 4 locks held by modprobe/3479: #0: (&dev->mutex){......}, at: [<ffffffff81ce8933>] __driver_attach+0xa3/0x160 #1: (&dev->mutex){......}, at: [<ffffffff81ce8941>] __driver_attach+0xb1/0x160 #2: (register_mutex#5){+.+.+.}, at: [<ffffffffa10596c7>] usb_audio_probe+0x257/0x1c90 [snd_usb_audio] #3: (&(&mdev->lock)->rlock){+.+.+.}, at: [<ffffffffa0e6051b>] media_device_register_entity+0x1cb/0x700 [media] CPU: 2 PID: 3479 Comm: modprobe Not tainted 4.5.0-rc3+ #49 Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015 0000000000000000 ffff8803b3f6f288 ffffffff81933901 ffff8803c4bae000 ffff8803c4bae5c8 ffff8803b3f6f2b0 ffffffff811c6af5 ffff8803c4bae000 ffffffff8285d7f6 0000000000000509 ffff8803b3f6f2f0 ffffffff811c6ce5 Call Trace: [<ffffffff81933901>] dump_stack+0x85/0xc4 [<ffffffff811c6af5>] ___might_sleep+0x245/0x3a0 [<ffffffff811c6ce5>] __might_sleep+0x95/0x1a0 [<ffffffff8155aade>] kmem_cache_alloc_trace+0x20e/0x300 [<ffffffffa0e66e3d>] ? media_add_link+0x4d/0x140 [media] [<ffffffffa0e66e3d>] media_add_link+0x4d/0x140 [media] [<ffffffffa0e69931>] media_create_pad_link+0xa1/0x600 [media] [<ffffffffa0fe11b3>] au0828_media_graph_notify+0x173/0x360 [au0828] [<ffffffffa0e68a6a>] ? media_gobj_create+0x1ba/0x480 [media] [<ffffffffa0e606fb>] media_device_register_entity+0x3ab/0x700 [media] Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2016-04-06 21:55:24 +08:00
mutex_lock(&mdev->graph_mutex);
/* Check if mdev was ever registered at all */
if (!media_devnode_is_registered(mdev->devnode)) {
[media] media-device: get rid of the spinlock Right now, the lock schema for media_device struct is messy, since sometimes, it is protected via a spin lock, while, for media graph traversal, it is protected by a mutex. Solve this conflict by always using a mutex. As a side effect, this prevents a bug when the media notifiers is called at atomic context, while running the notifier callback: BUG: sleeping function called from invalid context at mm/slub.c:1289 in_atomic(): 1, irqs_disabled(): 0, pid: 3479, name: modprobe 4 locks held by modprobe/3479: #0: (&dev->mutex){......}, at: [<ffffffff81ce8933>] __driver_attach+0xa3/0x160 #1: (&dev->mutex){......}, at: [<ffffffff81ce8941>] __driver_attach+0xb1/0x160 #2: (register_mutex#5){+.+.+.}, at: [<ffffffffa10596c7>] usb_audio_probe+0x257/0x1c90 [snd_usb_audio] #3: (&(&mdev->lock)->rlock){+.+.+.}, at: [<ffffffffa0e6051b>] media_device_register_entity+0x1cb/0x700 [media] CPU: 2 PID: 3479 Comm: modprobe Not tainted 4.5.0-rc3+ #49 Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015 0000000000000000 ffff8803b3f6f288 ffffffff81933901 ffff8803c4bae000 ffff8803c4bae5c8 ffff8803b3f6f2b0 ffffffff811c6af5 ffff8803c4bae000 ffffffff8285d7f6 0000000000000509 ffff8803b3f6f2f0 ffffffff811c6ce5 Call Trace: [<ffffffff81933901>] dump_stack+0x85/0xc4 [<ffffffff811c6af5>] ___might_sleep+0x245/0x3a0 [<ffffffff811c6ce5>] __might_sleep+0x95/0x1a0 [<ffffffff8155aade>] kmem_cache_alloc_trace+0x20e/0x300 [<ffffffffa0e66e3d>] ? media_add_link+0x4d/0x140 [media] [<ffffffffa0e66e3d>] media_add_link+0x4d/0x140 [media] [<ffffffffa0e69931>] media_create_pad_link+0xa1/0x600 [media] [<ffffffffa0fe11b3>] au0828_media_graph_notify+0x173/0x360 [au0828] [<ffffffffa0e68a6a>] ? media_gobj_create+0x1ba/0x480 [media] [<ffffffffa0e606fb>] media_device_register_entity+0x3ab/0x700 [media] Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2016-04-06 21:55:24 +08:00
mutex_unlock(&mdev->graph_mutex);
return;
}
[media] media: fix media devnode ioctl/syscall and unregister race Media devnode open/ioctl could be in progress when media device unregister is initiated. System calls and ioctls check media device registered status at the beginning, however, there is a window where unregister could be in progress without changing the media devnode status to unregistered. process 1 process 2 fd = open(/dev/media0) media_devnode_is_registered() (returns true here) media_device_unregister() (unregister is in progress and devnode isn't unregistered yet) ... ioctl(fd, ...) __media_ioctl() media_devnode_is_registered() (returns true here) ... media_devnode_unregister() ... (driver releases the media device memory) media_device_ioctl() (By this point devnode->media_dev does not point to allocated memory. use-after free in in mutex_lock_nested) BUG: KASAN: use-after-free in mutex_lock_nested+0x79c/0x800 at addr ffff8801ebe914f0 Fix it by clearing register bit when unregister starts to avoid the race. process 1 process 2 fd = open(/dev/media0) media_devnode_is_registered() (could return true here) media_device_unregister() (clear the register bit, then start unregister.) ... ioctl(fd, ...) __media_ioctl() media_devnode_is_registered() (return false here, ioctl returns I/O error, and will not access media device memory) ... media_devnode_unregister() ... (driver releases the media device memory) Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com> Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reported-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Tested-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-06-11 01:37:23 +08:00
/* Clear the devnode register bit to avoid races with media dev open */
media_devnode_unregister_prepare(mdev->devnode);
/* Remove all entities from the media device */
list_for_each_entry_safe(entity, next, &mdev->entities, graph_obj.list)
__media_device_unregister_entity(entity);
/* Remove all entity_notify callbacks from the media device */
list_for_each_entry_safe(notify, nextp, &mdev->entity_notify, list)
__media_device_unregister_entity_notify(mdev, notify);
/* Remove all interfaces from the media device */
list_for_each_entry_safe(intf, tmp_intf, &mdev->interfaces,
graph_obj.list) {
/*
* Unlink the interface, but don't free it here; the
* module which created it is responsible for freeing
* it
*/
__media_remove_intf_links(intf);
media_gobj_destroy(&intf->graph_obj);
}
[media] media-device: get rid of the spinlock Right now, the lock schema for media_device struct is messy, since sometimes, it is protected via a spin lock, while, for media graph traversal, it is protected by a mutex. Solve this conflict by always using a mutex. As a side effect, this prevents a bug when the media notifiers is called at atomic context, while running the notifier callback: BUG: sleeping function called from invalid context at mm/slub.c:1289 in_atomic(): 1, irqs_disabled(): 0, pid: 3479, name: modprobe 4 locks held by modprobe/3479: #0: (&dev->mutex){......}, at: [<ffffffff81ce8933>] __driver_attach+0xa3/0x160 #1: (&dev->mutex){......}, at: [<ffffffff81ce8941>] __driver_attach+0xb1/0x160 #2: (register_mutex#5){+.+.+.}, at: [<ffffffffa10596c7>] usb_audio_probe+0x257/0x1c90 [snd_usb_audio] #3: (&(&mdev->lock)->rlock){+.+.+.}, at: [<ffffffffa0e6051b>] media_device_register_entity+0x1cb/0x700 [media] CPU: 2 PID: 3479 Comm: modprobe Not tainted 4.5.0-rc3+ #49 Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015 0000000000000000 ffff8803b3f6f288 ffffffff81933901 ffff8803c4bae000 ffff8803c4bae5c8 ffff8803b3f6f2b0 ffffffff811c6af5 ffff8803c4bae000 ffffffff8285d7f6 0000000000000509 ffff8803b3f6f2f0 ffffffff811c6ce5 Call Trace: [<ffffffff81933901>] dump_stack+0x85/0xc4 [<ffffffff811c6af5>] ___might_sleep+0x245/0x3a0 [<ffffffff811c6ce5>] __might_sleep+0x95/0x1a0 [<ffffffff8155aade>] kmem_cache_alloc_trace+0x20e/0x300 [<ffffffffa0e66e3d>] ? media_add_link+0x4d/0x140 [media] [<ffffffffa0e66e3d>] media_add_link+0x4d/0x140 [media] [<ffffffffa0e69931>] media_create_pad_link+0xa1/0x600 [media] [<ffffffffa0fe11b3>] au0828_media_graph_notify+0x173/0x360 [au0828] [<ffffffffa0e68a6a>] ? media_gobj_create+0x1ba/0x480 [media] [<ffffffffa0e606fb>] media_device_register_entity+0x3ab/0x700 [media] Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2016-04-06 21:55:24 +08:00
mutex_unlock(&mdev->graph_mutex);
[media] media: Entities, pads and links As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. An entity is a basic media hardware building block. It can correspond to a large variety of logical blocks such as physical hardware devices (CMOS sensor for instance), logical hardware devices (a building block in a System-on-Chip image processing pipeline), DMA channels or physical connectors. A pad is a connection endpoint through which an entity can interact with other entities. Data (not restricted to video) produced by an entity flows from the entity's output to one or more entity inputs. Pads should not be confused with physical pins at chip boundaries. A link is a point-to-point oriented connection between two pads, either on the same entity or on different entities. Data flows from a source pad to a sink pad. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil <hverkuil@xs4all.nl> initial work. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-12-09 19:40:00 +08:00
dev_dbg(mdev->dev, "Media device unregistered\n");
[media] media: fix media devnode ioctl/syscall and unregister race Media devnode open/ioctl could be in progress when media device unregister is initiated. System calls and ioctls check media device registered status at the beginning, however, there is a window where unregister could be in progress without changing the media devnode status to unregistered. process 1 process 2 fd = open(/dev/media0) media_devnode_is_registered() (returns true here) media_device_unregister() (unregister is in progress and devnode isn't unregistered yet) ... ioctl(fd, ...) __media_ioctl() media_devnode_is_registered() (returns true here) ... media_devnode_unregister() ... (driver releases the media device memory) media_device_ioctl() (By this point devnode->media_dev does not point to allocated memory. use-after free in in mutex_lock_nested) BUG: KASAN: use-after-free in mutex_lock_nested+0x79c/0x800 at addr ffff8801ebe914f0 Fix it by clearing register bit when unregister starts to avoid the race. process 1 process 2 fd = open(/dev/media0) media_devnode_is_registered() (could return true here) media_device_unregister() (clear the register bit, then start unregister.) ... ioctl(fd, ...) __media_ioctl() media_devnode_is_registered() (return false here, ioctl returns I/O error, and will not access media device memory) ... media_devnode_unregister() ... (driver releases the media device memory) Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com> Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reported-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Tested-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-06-11 01:37:23 +08:00
device_remove_file(&mdev->devnode->dev, &dev_attr_model);
media_devnode_unregister(mdev->devnode);
/* devnode free is handled in media_devnode_*() */
mdev->devnode = NULL;
}
EXPORT_SYMBOL_GPL(media_device_unregister);
[media] media: Entities, pads and links As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. An entity is a basic media hardware building block. It can correspond to a large variety of logical blocks such as physical hardware devices (CMOS sensor for instance), logical hardware devices (a building block in a System-on-Chip image processing pipeline), DMA channels or physical connectors. A pad is a connection endpoint through which an entity can interact with other entities. Data (not restricted to video) produced by an entity flows from the entity's output to one or more entity inputs. Pads should not be confused with physical pins at chip boundaries. A link is a point-to-point oriented connection between two pads, either on the same entity or on different entities. Data flows from a source pad to a sink pad. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil <hverkuil@xs4all.nl> initial work. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-12-09 19:40:00 +08:00
#if IS_ENABLED(CONFIG_PCI)
void media_device_pci_init(struct media_device *mdev,
struct pci_dev *pci_dev,
const char *name)
{
mdev->dev = &pci_dev->dev;
if (name)
strscpy(mdev->model, name, sizeof(mdev->model));
else
strscpy(mdev->model, pci_name(pci_dev), sizeof(mdev->model));
sprintf(mdev->bus_info, "PCI:%s", pci_name(pci_dev));
mdev->hw_revision = (pci_dev->subsystem_vendor << 16)
| pci_dev->subsystem_device;
media_device_init(mdev);
}
EXPORT_SYMBOL_GPL(media_device_pci_init);
#endif
#if IS_ENABLED(CONFIG_USB)
void __media_device_usb_init(struct media_device *mdev,
struct usb_device *udev,
const char *board_name,
const char *driver_name)
{
mdev->dev = &udev->dev;
if (driver_name)
strscpy(mdev->driver_name, driver_name,
sizeof(mdev->driver_name));
if (board_name)
strscpy(mdev->model, board_name, sizeof(mdev->model));
else if (udev->product)
strscpy(mdev->model, udev->product, sizeof(mdev->model));
else
strscpy(mdev->model, "unknown model", sizeof(mdev->model));
if (udev->serial)
strscpy(mdev->serial, udev->serial, sizeof(mdev->serial));
usb_make_path(udev, mdev->bus_info, sizeof(mdev->bus_info));
mdev->hw_revision = le16_to_cpu(udev->descriptor.bcdDevice);
media_device_init(mdev);
}
EXPORT_SYMBOL_GPL(__media_device_usb_init);
#endif
#endif /* CONFIG_MEDIA_CONTROLLER */