linux.git/include/media, branch v5.12.5

media: v4l2-ctrls: fix reference to freed memory

2021-05-12T06:40:01+00:00

commit ac34b79da14d67a9b494f6125186becbd067e225 upstream.

When controls are used together with the Request API, then for
each request a v4l2_ctrl_handler struct is allocated. This contains
the controls that can be set in a request. If a control is *not* set in
the request, then the value used in the most recent previous request
must be used, or the current value if it is not found in any outstanding
requests.

The framework tried to find such a previous request and it would set
the 'req' pointer in struct v4l2_ctrl_ref to the v4l2_ctrl_ref of the
control in such a previous request. So far, so good. However, when that
previous request was applied to the hardware, returned to userspace, and
then userspace would re-init or free that request, any 'ref' pointer in
still-queued requests would suddenly point to freed memory.

This was not noticed before since the drivers that use this expected
that each request would always have the controls set, so there was
never any need to find a control in older requests. This requirement
was relaxed, and now this bug surfaced.

It was also made worse by changeset
2fae4d6aabc8 ("media: v4l2-ctrls: v4l2_ctrl_request_complete() should always set ref->req")
which increased the chance of this happening.

The use of the 'req' pointer in v4l2_ctrl_ref was very fragile, so
drop this entirely. Instead add a valid_p_req bool to indicate that
p_req contains a valid value for this control. And if it is false,
then just use the current value of the control.

Note that VIDIOC_G_EXT_CTRLS will always return -EACCES when attempting
to get a control from a request until the request is completed. And in
that case, all controls in the request will have the control value set
(i.e. valid_p_req is true). This means that the whole 'find the most
recent previous request containing a control' idea is pointless, and
the code can be simplified considerably.

The v4l2_g_ext_ctrls_common() function was refactored a bit to make
it more understandable. It also avoids updating volatile controls
in a completed request since that was already done when the request
was completed.

Signed-off-by: Hans Verkuil 
Fixes: 2fae4d6aabc8 ("media: v4l2-ctrls: v4l2_ctrl_request_complete() should always set ref->req")
Fixes: 6fa6f831f095 ("media: v4l2-ctrls: add core request support")
Cc:       # for v5.9 and up
Tested-by: Alexandre Courbot 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: rc: compile rc-cec.c into rc-core

2021-03-11T10:40:28+00:00

The rc-cec keymap is unusual in that it can't be built as a module,
instead it is registered directly in rc-main.c if CONFIG_MEDIA_CEC_RC
is set. This is because it can be called from drm_dp_cec_set_edid() via
cec_register_adapter() in an asynchronous context, and it is not
allowed to use request_module() to load rc-cec.ko in that case. Trying to
do so results in a 'WARN_ON_ONCE(wait && current_is_async())'.

Since this keymap is only used if CONFIG_MEDIA_CEC_RC is set, we
just compile this keymap into the rc-core module and never as a
separate module.

Signed-off-by: Hans Verkuil 
Fixes: 2c6d1fffa1d9 (drm: add support for DisplayPort CEC-Tunneling-over-AUX)
Reported-by: Hans de Goede 
Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab

Merge tag 'topic/iomem-mmap-vs-gup-2021-02-22' of git://anongit.freedesktop.org/drm/drm

2021-02-23T01:45:02+00:00

Pull follow_pfn() updates from Daniel Vetter:
 "Fixes around VM_FPNMAP and follow_pfn:

   - replace mm/frame_vector.c by get_user_pages in misc/habana and
     drm/exynos drivers, then move that into media as it's sole user

   - close race in generic_access_phys

   - s390 pci ioctl fix of this series landed in 5.11 already

   - properly revoke iomem mappings (/dev/mem, pci files)"

* tag 'topic/iomem-mmap-vs-gup-2021-02-22' of git://anongit.freedesktop.org/drm/drm:
  PCI: Revoke mappings like devmem
  PCI: Also set up legacy files only after sysfs init
  sysfs: Support zapping of binary attr mmaps
  resource: Move devmem revoke code to resource framework
  /dev/mem: Only set filp->f_mapping
  PCI: Obey iomem restrictions for procfs mmap
  mm: Close race in generic_access_phys
  media: videobuf2: Move frame_vector into media subsystem
  mm/frame-vector: Use FOLL_LONGTERM
  misc/habana: Use FOLL_LONGTERM for userptr
  misc/habana: Stop using frame_vector helpers
  drm/exynos: Use FOLL_LONGTERM for g2d cmdlists
  drm/exynos: Stop using frame_vector helpers

media: v4l: async: Fix kerneldoc documentation for async functions

2021-02-15T15:21:54+00:00

Fix kerneldoc documentation for functions that add async sub-devices to
notifiers. The functions themselves were improved recently but that left
issues with the kerneldoc documentation. Fix them now.

Also remove underscores from macro argument names.

[mchehab: fix a build breakage]
Reported-by: Stephen Rothwell 
Fixes: b01edcbd409c ("media: v4l2-async: Improve v4l2_async_notifier_add_*_subdev() API")
Signed-off-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab

media: Remove the legacy v4l2-clk API

2021-02-06T08:39:44+00:00

The V4L2 temporary clock helper API, was introduced
in late 2012 and, as mentioned in the documentation,
meant to be replaced by the generic clock API,
once the generic clock framework became available
on all relevant architectures.

The generic clock API is a well-established API (since a few
years now). The last few media capture drivers and sensors
using v4l2-clk have been converted to the generic clock framework.

We can now remove the v4l2-clk API.

Signed-off-by: Ezequiel Garcia 
Acked-by: Petr Cvek 
Signed-off-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab

media: Clarify v4l2-async subdevice addition API

2021-02-06T08:30:10+00:00

Now that most users of v4l2_async_notifier_add_subdev have been converted,
let's fix the documentation so it's more clear how the v4l2-async API
should be used.

Document functions that drivers should use, and their purpose.

Signed-off-by: Ezequiel Garcia 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Sakari Ailus 
Reviewed-by: Helen Koike 
Signed-off-by: Mauro Carvalho Chehab

media: v4l2-async: Improve v4l2_async_notifier_add_*_subdev() API

2021-02-06T08:18:53+00:00

The functions that add an async subdev to an async subdev notifier take
as an argument the size of the container structure they need to
allocate. This is error prone, as passing an invalid size will not be
caught by the compiler. Wrap those functions in macros that take a
container type instead of a size, and cast the returned pointer to the
desired type. The compiler will catch mistakes if the incorrect type is
passed to the macro, as the assignment types won't match.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Niklas Söderlund 
Reviewed-by: Jacopo Mondi 
Signed-off-by: Ezequiel Garcia 
Signed-off-by: Sakari Ailus 
Reviewed-by: Helen Koike 
Reviewed-by: Tomi Valkeinen  (core+ti-cal)
Signed-off-by: Mauro Carvalho Chehab

media: v4l2-async: Discourage use of v4l2_async_notifier_add_subdev

2021-02-06T08:16:17+00:00

Most -if not all- use-cases are expected to be covered by one of:
v4l2_async_notifier_add_fwnode_subdev,
v4l2_async_notifier_add_fwnode_remote_subdev or
v4l2_async_notifier_add_i2c_subdev.

We'd like to discourage drivers from using v4l2_async_notifier_add_subdev,
so rename it as __v4l2_async_notifier_add_subdev. This is
typically a good hint for drivers to avoid using the function.

Signed-off-by: Ezequiel Garcia 
Reviewed-by: Laurent Pinchart 
Reviewed-by: Helen Koike 
Signed-off-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab

media: davinci: vpif_display: Remove unused v4l2-async code

2021-02-06T07:46:25+00:00

There are no users for vpif_display_config.asd_sizes
and vpif_display_config.asd members, which means the v4l2-async
subdevices aren't being defined anywhere.

Remove the v4l2-async, leaving only the synchronous setup.

Signed-off-by: Ezequiel Garcia 
Reviewed-by: Helen Koike 
Signed-off-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab

media: v4l2-async: Clean v4l2_async_notifier_add_fwnode_remote_subdev

2021-02-06T07:40:36+00:00

Change v4l2_async_notifier_add_fwnode_remote_subdev semantics
so it allocates the struct v4l2_async_subdev pointer.

This makes the API consistent: the v4l2-async subdevice addition
functions have now a unified usage model. This model is simpler,
as it makes v4l2-async responsible for the allocation and release
of the subdevice descriptor, and no longer something the driver
has to worry about.

On the user side, the change makes the API simpler for the drivers
to use and less error-prone.

Signed-off-by: Ezequiel Garcia 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Sakari Ailus 
Reviewed-by: Helen Koike 
Signed-off-by: Mauro Carvalho Chehab