<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/media, branch v4.13.4</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>media: adv7180: add missing adv7180cp, adv7180st i2c device IDs</title>
<updated>2017-09-27T12:43:20+00:00</updated>
<author>
<name>Ulrich Hecht</name>
<email>ulrich.hecht+renesas@gmail.com</email>
</author>
<published>2017-07-03T08:43:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=163e5ee2361cab39e8fe29842b1f10a1d15642fa'/>
<id>163e5ee2361cab39e8fe29842b1f10a1d15642fa</id>
<content type='text'>
commit 281ddc3cdc10413b98531d701ab5323c4f3ff1f4 upstream.

Fixes a crash on Renesas R8A7793 Gose board that uses these "compatible"
entries.

Signed-off-by: Ulrich Hecht &lt;ulrich.hecht+renesas@gmail.com&gt;
Tested-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 281ddc3cdc10413b98531d701ab5323c4f3ff1f4 upstream.

Fixes a crash on Renesas R8A7793 Gose board that uses these "compatible"
entries.

Signed-off-by: Ulrich Hecht &lt;ulrich.hecht+renesas@gmail.com&gt;
Tested-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>media: uvcvideo: Prevent heap overflow when accessing mapped controls</title>
<updated>2017-09-27T12:43:20+00:00</updated>
<author>
<name>Guenter Roeck</name>
<email>linux@roeck-us.net</email>
</author>
<published>2017-08-08T12:56:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4185087177877b467df0b4aa08a128e7822542e2'/>
<id>4185087177877b467df0b4aa08a128e7822542e2</id>
<content type='text'>
commit 7e09f7d5c790278ab98e5f2c22307ebe8ad6e8ba upstream.

The size of uvc_control_mapping is user controlled leading to a
potential heap overflow in the uvc driver. This adds a check to verify
the user provided size fits within the bounds of the defined buffer
size.

Originally-from: Richard Simmons &lt;rssimmo@amazon.com&gt;

Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7e09f7d5c790278ab98e5f2c22307ebe8ad6e8ba upstream.

The size of uvc_control_mapping is user controlled leading to a
potential heap overflow in the uvc driver. This adds a check to verify
the user provided size fits within the bounds of the defined buffer
size.

Originally-from: Richard Simmons &lt;rssimmo@amazon.com&gt;

Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>media: venus: fix copy/paste error in return_buf_error</title>
<updated>2017-09-27T12:43:20+00:00</updated>
<author>
<name>Gustavo A. R. Silva</name>
<email>gustavo@embeddedor.com</email>
</author>
<published>2017-08-18T16:07:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d243b486a40c3d95e25888c511d4b71f0d52dc23'/>
<id>d243b486a40c3d95e25888c511d4b71f0d52dc23</id>
<content type='text'>
commit 0de0ef6c3f2dd7e9965270683445917e10384ab0 upstream.

Call function v4l2_m2m_dst_buf_remove_by_buf() instead of
v4l2_m2m_src_buf_remove_by_buf()

Addresses-Coverity-ID: 1415317

Signed-off-by: Gustavo A. R. Silva &lt;gustavo@embeddedor.com&gt;
Acked-by: Stanimir Varbanov &lt;stanimir.varbanov@linaro.org&gt;
Signed-off-by: Hans Verkuil &lt;hansverk@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 0de0ef6c3f2dd7e9965270683445917e10384ab0 upstream.

Call function v4l2_m2m_dst_buf_remove_by_buf() instead of
v4l2_m2m_src_buf_remove_by_buf()

Addresses-Coverity-ID: 1415317

Signed-off-by: Gustavo A. R. Silva &lt;gustavo@embeddedor.com&gt;
Acked-by: Stanimir Varbanov &lt;stanimir.varbanov@linaro.org&gt;
Signed-off-by: Hans Verkuil &lt;hansverk@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>media: Revert "[media] lirc_dev: remove superfluous get/put_device() calls"</title>
<updated>2017-09-27T12:43:20+00:00</updated>
<author>
<name>Sean Young</name>
<email>sean@mess.org</email>
</author>
<published>2017-08-04T14:12:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e2204d254f27087a71e58d371b2a60bddf3e7c54'/>
<id>e2204d254f27087a71e58d371b2a60bddf3e7c54</id>
<content type='text'>
commit a607f51e5a4c421e2097077db88105402099c528 upstream.

This reverts commit 5be2b76a9ca4ea5fd3e221114d62eeb0d78267ca.

Only when the lirc device is freed, should we drop our reference to
rc_dev, else we the rc_dev is freed to early. If userspace has
a file descriptor open during unplug, it goes bang.

==================================================================
BUG: KASAN: use-after-free in __lock_acquire+0x7bb/0x1e10
Read of size 8 at addr ffff8801d7d61ed0 by task ir-rec/2609

-snip-
 mutex_lock_nested+0x1b/0x20
 ? mutex_lock_nested+0x1b/0x20
 rc_close.part.6+0x20/0x60 [rc_core]
 rc_close+0x13/0x20 [rc_core]
 lirc_dev_fop_close+0x62/0xd0 [lirc_dev]
 __fput+0x236/0x410
 ? fput+0xb0/0xb0
 ? do_raw_spin_trylock+0x110/0x110
 ? set_rq_offline.part.70+0xa0/0xa0
 ____fput+0xe/0x10
 task_work_run+0x116/0x180
 ? task_work_cancel+0x170/0x170
 ? _raw_spin_unlock+0x27/0x40
 ? switch_task_namespaces+0x5f/0x90
 do_exit+0x68b/0xe80

Fixes: 5be2b76a9ca4 ("[media] lirc_dev: remove superfluous get/put_device() calls")
Signed-off-by: Sean Young &lt;sean@mess.org&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a607f51e5a4c421e2097077db88105402099c528 upstream.

This reverts commit 5be2b76a9ca4ea5fd3e221114d62eeb0d78267ca.

Only when the lirc device is freed, should we drop our reference to
rc_dev, else we the rc_dev is freed to early. If userspace has
a file descriptor open during unplug, it goes bang.

==================================================================
BUG: KASAN: use-after-free in __lock_acquire+0x7bb/0x1e10
Read of size 8 at addr ffff8801d7d61ed0 by task ir-rec/2609

-snip-
 mutex_lock_nested+0x1b/0x20
 ? mutex_lock_nested+0x1b/0x20
 rc_close.part.6+0x20/0x60 [rc_core]
 rc_close+0x13/0x20 [rc_core]
 lirc_dev_fop_close+0x62/0xd0 [lirc_dev]
 __fput+0x236/0x410
 ? fput+0xb0/0xb0
 ? do_raw_spin_trylock+0x110/0x110
 ? set_rq_offline.part.70+0xa0/0xa0
 ____fput+0xe/0x10
 task_work_run+0x116/0x180
 ? task_work_cancel+0x170/0x170
 ? _raw_spin_unlock+0x27/0x40
 ? switch_task_namespaces+0x5f/0x90
 do_exit+0x68b/0xe80

Fixes: 5be2b76a9ca4 ("[media] lirc_dev: remove superfluous get/put_device() calls")
Signed-off-by: Sean Young &lt;sean@mess.org&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>media: v4l2-compat-ioctl32: Fix timespec conversion</title>
<updated>2017-09-27T12:43:20+00:00</updated>
<author>
<name>Daniel Mentz</name>
<email>danielmentz@google.com</email>
</author>
<published>2017-08-03T03:42:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a0416c1e96556d59de02b672b574994572a38444'/>
<id>a0416c1e96556d59de02b672b574994572a38444</id>
<content type='text'>
commit 9c7ba1d7634cef490b85bc64c4091ff004821bfd upstream.

Certain syscalls like recvmmsg support 64 bit timespec values for the
X32 ABI. The helper function compat_put_timespec converts a timespec
value to a 32 bit or 64 bit value depending on what ABI is used. The
v4l2 compat layer, however, is not designed to support 64 bit timespec
values and always uses 32 bit values. Hence, compat_put_timespec must
not be used.

Without this patch, user space will be provided with bad timestamp
values from the VIDIOC_DQEVENT ioctl. Also, fields of the struct
v4l2_event32 that come immediately after timestamp get overwritten,
namely the field named id.

Fixes: 81993e81a994 ("compat: Get rid of (get|put)_compat_time(val|spec)")
Cc: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Cc: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Cc: Tiffany Lin &lt;tiffany.lin@mediatek.com&gt;
Cc: Ricardo Ribalda Delgado &lt;ricardo.ribalda@gmail.com&gt;
Cc: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Signed-off-by: Daniel Mentz &lt;danielmentz@google.com&gt;
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9c7ba1d7634cef490b85bc64c4091ff004821bfd upstream.

Certain syscalls like recvmmsg support 64 bit timespec values for the
X32 ABI. The helper function compat_put_timespec converts a timespec
value to a 32 bit or 64 bit value depending on what ABI is used. The
v4l2 compat layer, however, is not designed to support 64 bit timespec
values and always uses 32 bit values. Hence, compat_put_timespec must
not be used.

Without this patch, user space will be provided with bad timestamp
values from the VIDIOC_DQEVENT ioctl. Also, fields of the struct
v4l2_event32 that come immediately after timestamp get overwritten,
namely the field named id.

Fixes: 81993e81a994 ("compat: Get rid of (get|put)_compat_time(val|spec)")
Cc: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Cc: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Cc: Tiffany Lin &lt;tiffany.lin@mediatek.com&gt;
Cc: Ricardo Ribalda Delgado &lt;ricardo.ribalda@gmail.com&gt;
Cc: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Signed-off-by: Daniel Mentz &lt;danielmentz@google.com&gt;
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>media: platform: davinci: drop VPFE_CMD_S_CCDC_RAW_PARAMS</title>
<updated>2017-07-26T10:14:33+00:00</updated>
<author>
<name>Prabhakar Lad</name>
<email>prabhakar.csengg@gmail.com</email>
</author>
<published>2017-07-20T08:56:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b25db383928cecba356835583b16fa7008f97b3a'/>
<id>b25db383928cecba356835583b16fa7008f97b3a</id>
<content type='text'>
drop VPFE_CMD_S_CCDC_RAW_PARAMS ioctl from dm355/dm644x following reasons:

- This ioctl was never in public api and was only defined in kernel header.
- The function set_params constantly mixes up pointers and phys_addr_t
  numbers.
- This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is
  described as an 'experimental ioctl that will change in future kernels'.
- The code to allocate the table never gets called after we copy_from_user
  the user input over the kernel settings, and then compare them
  for inequality.
- We then go on to use an address provided by user space as both the
  __user pointer for input and pass it through phys_to_virt to come up
  with a kernel pointer to copy the data to. This looks like a trivially
  exploitable root hole.

Signed-off-by: Lad, Prabhakar &lt;prabhakar.csengg@gmail.com&gt;
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
drop VPFE_CMD_S_CCDC_RAW_PARAMS ioctl from dm355/dm644x following reasons:

- This ioctl was never in public api and was only defined in kernel header.
- The function set_params constantly mixes up pointers and phys_addr_t
  numbers.
- This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is
  described as an 'experimental ioctl that will change in future kernels'.
- The code to allocate the table never gets called after we copy_from_user
  the user input over the kernel settings, and then compare them
  for inequality.
- We then go on to use an address provided by user space as both the
  __user pointer for input and pass it through phys_to_virt to come up
  with a kernel pointer to copy the data to. This looks like a trivially
  exploitable root hole.

Signed-off-by: Lad, Prabhakar &lt;prabhakar.csengg@gmail.com&gt;
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>media: platform: davinci: return -EINVAL for VPFE_CMD_S_CCDC_RAW_PARAMS ioctl</title>
<updated>2017-07-26T10:14:33+00:00</updated>
<author>
<name>Prabhakar Lad</name>
<email>prabhakar.csengg@gmail.com</email>
</author>
<published>2017-07-20T12:02:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=da05d52d2f0f6bd61094a0cd045fed94bf7d673a'/>
<id>da05d52d2f0f6bd61094a0cd045fed94bf7d673a</id>
<content type='text'>
this patch makes sure VPFE_CMD_S_CCDC_RAW_PARAMS ioctl no longer works
for vpfe_capture driver with a minimal patch suitable for backporting.

- This ioctl was never in public api and was only defined in kernel header.
- The function set_params constantly mixes up pointers and phys_addr_t
  numbers.
- This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is
  described as an 'experimental ioctl that will change in future kernels'.
- The code to allocate the table never gets called after we copy_from_user
  the user input over the kernel settings, and then compare them
  for inequality.
- We then go on to use an address provided by user space as both the
  __user pointer for input and pass it through phys_to_virt to come up
  with a kernel pointer to copy the data to. This looks like a trivially
  exploitable root hole.

Due to these reasons we make sure this ioctl now returns -EINVAL and backport
this patch as far as possible.

Fixes: 5f15fbb68fd7 ("V4L/DVB (12251): v4l: dm644x ccdc module for vpfe capture driver")

Signed-off-by: Lad, Prabhakar &lt;prabhakar.csengg@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;      # for v3.7 and up
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
this patch makes sure VPFE_CMD_S_CCDC_RAW_PARAMS ioctl no longer works
for vpfe_capture driver with a minimal patch suitable for backporting.

- This ioctl was never in public api and was only defined in kernel header.
- The function set_params constantly mixes up pointers and phys_addr_t
  numbers.
- This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is
  described as an 'experimental ioctl that will change in future kernels'.
- The code to allocate the table never gets called after we copy_from_user
  the user input over the kernel settings, and then compare them
  for inequality.
- We then go on to use an address provided by user space as both the
  __user pointer for input and pass it through phys_to_virt to come up
  with a kernel pointer to copy the data to. This looks like a trivially
  exploitable root hole.

Due to these reasons we make sure this ioctl now returns -EINVAL and backport
this patch as far as possible.

Fixes: 5f15fbb68fd7 ("V4L/DVB (12251): v4l: dm644x ccdc module for vpfe capture driver")

Signed-off-by: Lad, Prabhakar &lt;prabhakar.csengg@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;      # for v3.7 and up
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>media: venus: don't abuse dma_alloc for non-DMA allocations</title>
<updated>2017-07-26T10:14:32+00:00</updated>
<author>
<name>Stanimir Varbanov</name>
<email>stanimir.varbanov@linaro.org</email>
</author>
<published>2017-07-19T11:51:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=377a22d3caec3d2cda0cc996101121145ac43ff2'/>
<id>377a22d3caec3d2cda0cc996101121145ac43ff2</id>
<content type='text'>
In venus_boot(), we pass a pointer to a phys_addr_t
into dmam_alloc_coherent, which the compiler warns about:

platform/qcom/venus/firmware.c: In function 'venus_boot':
platform/qcom/venus/firmware.c:63:49: error: passing argument 3 of 'dmam_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types]

To avoid the error refactor venus_boot function by discard
dma_alloc_coherent invocation because we don't want to map the
memory for the device.  Something more, the usage of
DMA mapping API is actually wrong and the current
implementation relies on several bugs in DMA mapping code.
When these bugs are fixed that will break firmware loading,
so fix this now to avoid future troubles.

The meaning of venus_boot is to copy the content of the
firmware buffer into reserved (and memblock removed)
block of memory and pass that physical address to the
trusted zone for authentication and mapping through iommu
form the secure world. After iommu mapping is done the iova
is passed as ane entry point to the remote processor.

After this change memory-region property is parsed manually
and the physical address is memremap to CPU, call mdt_load to
load firmware segments into proper places and unmap
reserved memory.

Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions")

Signed-off-by: Stanimir Varbanov &lt;stanimir.varbanov@linaro.org&gt;
Reviewed-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In venus_boot(), we pass a pointer to a phys_addr_t
into dmam_alloc_coherent, which the compiler warns about:

platform/qcom/venus/firmware.c: In function 'venus_boot':
platform/qcom/venus/firmware.c:63:49: error: passing argument 3 of 'dmam_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types]

To avoid the error refactor venus_boot function by discard
dma_alloc_coherent invocation because we don't want to map the
memory for the device.  Something more, the usage of
DMA mapping API is actually wrong and the current
implementation relies on several bugs in DMA mapping code.
When these bugs are fixed that will break firmware loading,
so fix this now to avoid future troubles.

The meaning of venus_boot is to copy the content of the
firmware buffer into reserved (and memblock removed)
block of memory and pass that physical address to the
trusted zone for authentication and mapping through iommu
form the secure world. After iommu mapping is done the iova
is passed as ane entry point to the remote processor.

After this change memory-region property is parsed manually
and the physical address is memremap to CPU, call mdt_load to
load firmware segments into proper places and unmap
reserved memory.

Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions")

Signed-off-by: Stanimir Varbanov &lt;stanimir.varbanov@linaro.org&gt;
Reviewed-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>media: venus: hfi: fix error handling in hfi_sys_init_done()</title>
<updated>2017-07-26T10:14:32+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@gmail.com</email>
</author>
<published>2017-07-17T08:56:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3e7caae5f2853436153a7d5f253fd7e0e720f4b8'/>
<id>3e7caae5f2853436153a7d5f253fd7e0e720f4b8</id>
<content type='text'>
Not entirely sure what triggers it, but with venus build as kernel
module and in initrd, we hit this crash:

  Unable to handle kernel paging request at virtual address ffff80003c039000
  pgd = ffff00000a14f000
  [ffff80003c039000] *pgd=00000000bd9f7003, *pud=00000000bd9f6003, *pmd=00000000bd9f0003, *pte=0000000000000000
  Internal error: Oops: 96000007 [#1] SMP
  Modules linked in: qcom_wcnss_pil(E+) crc32_ce(E) qcom_common(E) venus_core(E+) remoteproc(E) snd_soc_msm8916_digital(E) virtio_ring(E) cdc_ether(E) snd_soc_lpass_apq8016(E) snd_soc_lpass_cpu(E) snd_soc_apq8016_sbc(E) snd_soc_lpass_platform(E) v4l2_mem2mem(E) virtio(E) snd_soc_core(E) ac97_bus(E) snd_pcm_dmaengine(E) snd_seq(E) leds_gpio(E) videobuf2_v4l2(E) videobuf2_core(E) snd_seq_device(E) snd_pcm(E) videodev(E) media(E) nvmem_qfprom(E) msm(E) snd_timer(E) snd(E) soundcore(E) spi_qup(E) mdt_loader(E) qcom_tsens(E) qcom_spmi_temp_alarm(E) nvmem_core(E) msm_rng(E) uas(E) usb_storage(E) dm9601(E) usbnet(E) mii(E) mmc_block(E) adv7511(E) drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) qcom_spmi_vadc(E) qcom_vadc_common(PE) industrialio(E) pinctrl_spmi_mpp(E)
   pinctrl_spmi_gpio(E) rtc_pm8xxx(E) clk_smd_rpm(E) sdhci_msm(E) sdhci_pltfm(E) qcom_smd_regulator(E) drm(E) smd_rpm(E) qcom_spmi_pmic(E) regmap_spmi(E) ci_hdrc_msm(E) ci_hdrc(E) usb3503(E) extcon_usb_gpio(E) phy_msm_usb(E) udc_core(E) qcom_hwspinlock(E) extcon_core(E) ehci_msm(E) i2c_qup(E) sdhci(E) mmc_core(E) spmi_pmic_arb(E) spmi(E) qcom_smd(E) smsm(E) rpmsg_core(E) smp2p(E) smem(E) hwspinlock_core(E) gpio_keys(E)
  CPU: 2 PID: 551 Comm: irq/150-venus Tainted: P            E   4.12.0+ #1625
  Hardware name: qualcomm dragonboard410c/dragonboard410c, BIOS 2017.07-rc2-00144-ga97bdbdf72-dirty 07/08/2017
  task: ffff800037338000 task.stack: ffff800038e00000
  PC is at hfi_sys_init_done+0x64/0x140 [venus_core]
  LR is at hfi_process_msg_packet+0xcc/0x1e8 [venus_core]
  pc : [&lt;ffff00000118b384&gt;] lr : [&lt;ffff00000118c11c&gt;] pstate: 20400145
  sp : ffff800038e03c60
  x29: ffff800038e03c60 x28: 0000000000000000
  x27: 00000000000df018 x26: ffff00000118f4d0
  x25: 0000000000020003 x24: ffff80003a8d3010
  x23: ffff00000118f760 x22: ffff800037b40028
  x21: ffff8000382981f0 x20: ffff800037b40028
  x19: ffff80003c039000 x18: 0000000000000020
  x17: 0000000000000000 x16: ffff800037338000
  x15: ffffffffffffffff x14: 0000001000000014
  x13: 0000000100001007 x12: 0000000100000020
  x11: 0000100e00000000 x10: 0000000000000001
  x9 : 0000000200000000 x8 : 0000001400000001
  x7 : 0000000000001010 x6 : 0000000000000148
  x5 : 0000000000001009 x4 : ffff80003c039000
  x3 : 00000000cd770abb x2 : 0000000000000042
  x1 : 0000000000000788 x0 : 0000000000000002
  Process irq/150-venus (pid: 551, stack limit = 0xffff800038e00000)
  Call trace:
  [&lt;ffff00000118b384&gt;] hfi_sys_init_done+0x64/0x140 [venus_core]
  [&lt;ffff00000118c11c&gt;] hfi_process_msg_packet+0xcc/0x1e8 [venus_core]
  [&lt;ffff00000118a2b4&gt;] venus_isr_thread+0x1b4/0x208 [venus_core]
  [&lt;ffff00000118e750&gt;] hfi_isr_thread+0x28/0x38 [venus_core]
  [&lt;ffff000008161550&gt;] irq_thread_fn+0x30/0x70
  [&lt;ffff0000081617fc&gt;] irq_thread+0x14c/0x1c8
  [&lt;ffff000008105e68&gt;] kthread+0x138/0x140
  [&lt;ffff000008083590&gt;] ret_from_fork+0x10/0x40
  Code: 52820125 52820207 7a431820 54000249 (b9400263)
  ---[ end trace c963460f20a984b6 ]---

The problem is that in the error case, we've incremented the data ptr
but not decremented rem_bytes, and keep reading (presumably garbage)
until eventually we go beyond the end of the buffer.

Instead, on first error, we should probably just bail out.  Other
option is to increment read_bytes by sizeof(u32) before the switch,
rather than only accounting for the ptype header in the non-error
case.  Note that in this case it is HFI_ERR_SYS_INVALID_PARAMETER,
ie. an unrecognized/unsupported parameter, so interpreting the next
word as a property type would be bogus.  The other error cases are
due to truncated buffer, so there isn't likely to be anything valid
to interpret in the remainder of the buffer.  So just bailing seems
like a reasonable solution.

Signed-off-by: Rob Clark &lt;robdclark@gmail.com&gt;
Reviewed-by: Stanimir Varbanov &lt;stanimir.varbanov@linaro.org&gt;
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Not entirely sure what triggers it, but with venus build as kernel
module and in initrd, we hit this crash:

  Unable to handle kernel paging request at virtual address ffff80003c039000
  pgd = ffff00000a14f000
  [ffff80003c039000] *pgd=00000000bd9f7003, *pud=00000000bd9f6003, *pmd=00000000bd9f0003, *pte=0000000000000000
  Internal error: Oops: 96000007 [#1] SMP
  Modules linked in: qcom_wcnss_pil(E+) crc32_ce(E) qcom_common(E) venus_core(E+) remoteproc(E) snd_soc_msm8916_digital(E) virtio_ring(E) cdc_ether(E) snd_soc_lpass_apq8016(E) snd_soc_lpass_cpu(E) snd_soc_apq8016_sbc(E) snd_soc_lpass_platform(E) v4l2_mem2mem(E) virtio(E) snd_soc_core(E) ac97_bus(E) snd_pcm_dmaengine(E) snd_seq(E) leds_gpio(E) videobuf2_v4l2(E) videobuf2_core(E) snd_seq_device(E) snd_pcm(E) videodev(E) media(E) nvmem_qfprom(E) msm(E) snd_timer(E) snd(E) soundcore(E) spi_qup(E) mdt_loader(E) qcom_tsens(E) qcom_spmi_temp_alarm(E) nvmem_core(E) msm_rng(E) uas(E) usb_storage(E) dm9601(E) usbnet(E) mii(E) mmc_block(E) adv7511(E) drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) qcom_spmi_vadc(E) qcom_vadc_common(PE) industrialio(E) pinctrl_spmi_mpp(E)
   pinctrl_spmi_gpio(E) rtc_pm8xxx(E) clk_smd_rpm(E) sdhci_msm(E) sdhci_pltfm(E) qcom_smd_regulator(E) drm(E) smd_rpm(E) qcom_spmi_pmic(E) regmap_spmi(E) ci_hdrc_msm(E) ci_hdrc(E) usb3503(E) extcon_usb_gpio(E) phy_msm_usb(E) udc_core(E) qcom_hwspinlock(E) extcon_core(E) ehci_msm(E) i2c_qup(E) sdhci(E) mmc_core(E) spmi_pmic_arb(E) spmi(E) qcom_smd(E) smsm(E) rpmsg_core(E) smp2p(E) smem(E) hwspinlock_core(E) gpio_keys(E)
  CPU: 2 PID: 551 Comm: irq/150-venus Tainted: P            E   4.12.0+ #1625
  Hardware name: qualcomm dragonboard410c/dragonboard410c, BIOS 2017.07-rc2-00144-ga97bdbdf72-dirty 07/08/2017
  task: ffff800037338000 task.stack: ffff800038e00000
  PC is at hfi_sys_init_done+0x64/0x140 [venus_core]
  LR is at hfi_process_msg_packet+0xcc/0x1e8 [venus_core]
  pc : [&lt;ffff00000118b384&gt;] lr : [&lt;ffff00000118c11c&gt;] pstate: 20400145
  sp : ffff800038e03c60
  x29: ffff800038e03c60 x28: 0000000000000000
  x27: 00000000000df018 x26: ffff00000118f4d0
  x25: 0000000000020003 x24: ffff80003a8d3010
  x23: ffff00000118f760 x22: ffff800037b40028
  x21: ffff8000382981f0 x20: ffff800037b40028
  x19: ffff80003c039000 x18: 0000000000000020
  x17: 0000000000000000 x16: ffff800037338000
  x15: ffffffffffffffff x14: 0000001000000014
  x13: 0000000100001007 x12: 0000000100000020
  x11: 0000100e00000000 x10: 0000000000000001
  x9 : 0000000200000000 x8 : 0000001400000001
  x7 : 0000000000001010 x6 : 0000000000000148
  x5 : 0000000000001009 x4 : ffff80003c039000
  x3 : 00000000cd770abb x2 : 0000000000000042
  x1 : 0000000000000788 x0 : 0000000000000002
  Process irq/150-venus (pid: 551, stack limit = 0xffff800038e00000)
  Call trace:
  [&lt;ffff00000118b384&gt;] hfi_sys_init_done+0x64/0x140 [venus_core]
  [&lt;ffff00000118c11c&gt;] hfi_process_msg_packet+0xcc/0x1e8 [venus_core]
  [&lt;ffff00000118a2b4&gt;] venus_isr_thread+0x1b4/0x208 [venus_core]
  [&lt;ffff00000118e750&gt;] hfi_isr_thread+0x28/0x38 [venus_core]
  [&lt;ffff000008161550&gt;] irq_thread_fn+0x30/0x70
  [&lt;ffff0000081617fc&gt;] irq_thread+0x14c/0x1c8
  [&lt;ffff000008105e68&gt;] kthread+0x138/0x140
  [&lt;ffff000008083590&gt;] ret_from_fork+0x10/0x40
  Code: 52820125 52820207 7a431820 54000249 (b9400263)
  ---[ end trace c963460f20a984b6 ]---

The problem is that in the error case, we've incremented the data ptr
but not decremented rem_bytes, and keep reading (presumably garbage)
until eventually we go beyond the end of the buffer.

Instead, on first error, we should probably just bail out.  Other
option is to increment read_bytes by sizeof(u32) before the switch,
rather than only accounting for the ptype header in the non-error
case.  Note that in this case it is HFI_ERR_SYS_INVALID_PARAMETER,
ie. an unrecognized/unsupported parameter, so interpreting the next
word as a property type would be bogus.  The other error cases are
due to truncated buffer, so there isn't likely to be anything valid
to interpret in the remainder of the buffer.  So just bailing seems
like a reasonable solution.

Signed-off-by: Rob Clark &lt;robdclark@gmail.com&gt;
Reviewed-by: Stanimir Varbanov &lt;stanimir.varbanov@linaro.org&gt;
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>media: venus: fix compile-test build on non-qcom ARM platform</title>
<updated>2017-07-26T10:14:31+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2017-07-17T08:56:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b8f9bdc151e4a61eaa385900e580aad1e68f094b'/>
<id>b8f9bdc151e4a61eaa385900e580aad1e68f094b</id>
<content type='text'>
If QCOM_MDT_LOADER is enabled, but ARCH_QCOM is not, we run into
a build error:

ERROR: "qcom_mdt_load" [drivers/media/platform/qcom/venus/venus-core.ko] undefined!
ERROR: "qcom_mdt_get_size" [drivers/media/platform/qcom/venus/venus-core.ko] undefined!

This changes the 'select' statement again, so we only try to enable
those symbols when the drivers will actually get built, and explicitly
test for QCOM_MDT_LOADER to be enabled before calling into it.

Fixes: 76724b30f222 ("[media] media: venus: enable building with COMPILE_TEST")

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Reviewed-by: Stanimir Varbanov &lt;stanimir.varbanov@linaro.org&gt;
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If QCOM_MDT_LOADER is enabled, but ARCH_QCOM is not, we run into
a build error:

ERROR: "qcom_mdt_load" [drivers/media/platform/qcom/venus/venus-core.ko] undefined!
ERROR: "qcom_mdt_get_size" [drivers/media/platform/qcom/venus/venus-core.ko] undefined!

This changes the 'select' statement again, so we only try to enable
those symbols when the drivers will actually get built, and explicitly
test for QCOM_MDT_LOADER to be enabled before calling into it.

Fixes: 76724b30f222 ("[media] media: venus: enable building with COMPILE_TEST")

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Reviewed-by: Stanimir Varbanov &lt;stanimir.varbanov@linaro.org&gt;
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
