Re: [PATCH for v4.9] Revert "media: videobuf2-core: don't call memop 'finish' when queueing"
On Thu, Nov 22, 2018 at 12:43:56PM +0100, Hans Verkuil wrote:
This reverts commit 9ac47200b51cb09d2f15dbefa67e0412741d98aa.
This commit fixes a bug in upstream commit a136f59c0a1f ("vb2: Move
buffer cache synchronisation to prepare from queue") which isn't
present in 4.9.
So as a result you get an UNBALANCED message in the kernel log if
this patch is applied:
vb2: counters for queue ffc0f3687478, buffer 3: UNBALANCED!
vb2: buf_init: 1 buf_cleanup: 1 buf_prepare: 805 buf_finish: 805
vb2: buf_queue: 806 buf_done: 806
vb2: alloc: 0 put: 0 prepare: 806 finish: 805 mmap: 0
vb2: get_userptr: 0 put_userptr: 0
vb2: attach_dmabuf: 1 detach_dmabuf: 1 map_dmabuf: 805 unmap_dmabuf: 805
vb2: get_dmabuf: 0 num_users: 1609 vaddr: 0 cookie: 805
Reverting this patch solves this regression.
Signed-off-by: Hans Verkuil
I've queued both reverts to their respective branches, thank you.
--
Thanks,
Sasha
Re: [PATCH v4.9 1/1] v4l: event: Add subscription to list before calling "add" operation
On Thu, Nov 08, 2018 at 01:46:06PM +0200, Sakari Ailus wrote:
[ upstream commit 92539d3eda2c090b382699bbb896d4b54e9bdece ]
Patch ad608fbcf166 changed how events were subscribed to address an issue
elsewhere. As a side effect of that change, the "add" callback was called
before the event subscription was added to the list of subscribed events,
causing the first event queued by the add callback (and possibly other
events arriving soon afterwards) to be lost.
Fix this by adding the subscription to the list before calling the "add"
callback, and clean up afterwards if that fails.
Fixes: ad608fbcf166 ("media: v4l: event: Prevent freeing event subscriptions while
accessed")
Reported-by: Dave Stevenson
Signed-off-by: Sakari Ailus
Tested-by: Dave Stevenson
Reviewed-by: Hans Verkuil
Tested-by: Hans Verkuil
Cc: sta...@vger.kernel.org (for 4.14 and up)
Signed-off-by: Mauro Carvalho Chehab
Hi Sakari,
For the sake of completeness, can you sign off on the backport too and
indicate it was backported to 4.9 in the commit messge? Otherwise, this
commit message says it's for 4.14+ and will suddenly appear in the 4.9
tree, and if we have issues later it might cause confusion.
--
Thanks,
Sasha
Re: [Outreachy kernel] [PATCH vicodec] media: pvrusb2: replace `printk` with `pr_*`
On Sat, Oct 06, 2018 at 10:21:38PM +0300, Dafna Hirschfeld wrote: Replace calls to `printk` with the appropriate `pr_*` macro. Hi Dafna, I'd encourage you to look into the dev_ family of print functions (such as dev_info() ). They can avoid having to repeat the driver name in every print call. -- Thanks, Sasha
[PATCH AUTOSEL for 4.15 005/102] video/hdmi: Allow "empty" HDMI infoframes
From: Ville Syrjälä <ville.syrj...@linux.intel.com>
[ Upstream commit 593f4b19a094c4426bd1e1e3cbab87a48bd13c71 ]
HDMI 2.0 Appendix F suggest that we should keep sending the infoframe
when switching from 3D to 2D mode, even if the infoframe isn't strictly
necessary (ie. not needed to transmit the VIC or stereo information).
This is a workaround against some sinks that fail to realize that they
should switch from 3D to 2D mode when the source stop transmitting
the infoframe.
v2: Handle unpack() as well
Pull the length calculation into a helper
Cc: Shashank Sharma <shashank.sha...@intel.com>
Cc: Andrzej Hajda <a.ha...@samsung.com>
Cc: Thierry Reding <thierry.red...@gmail.com>
Cc: Hans Verkuil <hans.verk...@cisco.com>
Cc: linux-media@vger.kernel.org
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
Link:
https://patchwork.freedesktop.org/patch/msgid/20171113170427.4150-2-ville.syrj...@linux.intel.com
Reviewed-by: Shashank Sharma <shashank.sha...@intel.com>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
---
drivers/video/hdmi.c | 51 +++
1 file changed, 31 insertions(+), 20 deletions(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1cf907ecded4..111a0ab6280a 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -321,6 +321,17 @@ int hdmi_vendor_infoframe_init(struct
hdmi_vendor_infoframe *frame)
}
EXPORT_SYMBOL(hdmi_vendor_infoframe_init);
+static int hdmi_vendor_infoframe_length(const struct hdmi_vendor_infoframe
*frame)
+{
+ /* for side by side (half) we also need to provide 3D_Ext_Data */
+ if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
+ return 6;
+ else if (frame->vic != 0 || frame->s3d_struct !=
HDMI_3D_STRUCTURE_INVALID)
+ return 5;
+ else
+ return 4;
+}
+
/**
* hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary
buffer
* @frame: HDMI infoframe
@@ -341,19 +352,11 @@ ssize_t hdmi_vendor_infoframe_pack(struct
hdmi_vendor_infoframe *frame,
u8 *ptr = buffer;
size_t length;
- /* empty info frame */
- if (frame->vic == 0 && frame->s3d_struct == HDMI_3D_STRUCTURE_INVALID)
- return -EINVAL;
-
/* only one of those can be supplied */
if (frame->vic != 0 && frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID)
return -EINVAL;
- /* for side by side (half) we also need to provide 3D_Ext_Data */
- if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
- frame->length = 6;
- else
- frame->length = 5;
+ frame->length = hdmi_vendor_infoframe_length(frame);
length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
@@ -372,14 +375,16 @@ ssize_t hdmi_vendor_infoframe_pack(struct
hdmi_vendor_infoframe *frame,
ptr[5] = 0x0c;
ptr[6] = 0x00;
- if (frame->vic) {
- ptr[7] = 0x1 << 5; /* video format */
- ptr[8] = frame->vic;
- } else {
+ if (frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) {
ptr[7] = 0x2 << 5; /* video format */
ptr[8] = (frame->s3d_struct & 0xf) << 4;
if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
ptr[9] = (frame->s3d_ext_data & 0xf) << 4;
+ } else if (frame->vic) {
+ ptr[7] = 0x1 << 5; /* video format */
+ ptr[8] = frame->vic;
+ } else {
+ ptr[7] = 0x0 << 5; /* video format */
}
hdmi_infoframe_set_checksum(buffer, length);
@@ -1165,7 +1170,7 @@ hdmi_vendor_any_infoframe_unpack(union
hdmi_vendor_any_infoframe *frame,
if (ptr[0] != HDMI_INFOFRAME_TYPE_VENDOR ||
ptr[1] != 1 ||
- (ptr[2] != 5 && ptr[2] != 6))
+ (ptr[2] != 4 && ptr[2] != 5 && ptr[2] != 6))
return -EINVAL;
length = ptr[2];
@@ -1193,16 +1198,22 @@ hdmi_vendor_any_infoframe_unpack(union
hdmi_vendor_any_infoframe *frame,
hvf->length = length;
- if (hdmi_video_format == 0x1) {
- hvf->vic = ptr[4];
- } else if (hdmi_video_format == 0x2) {
+ if (hdmi_video_format == 0x2) {
+ if (length != 5 && length != 6)
+ return -EINVAL;
hvf->s3d_struct = ptr[4] >> 4;
if (hvf->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) {
- if (length == 6)
- hvf->s3d_ext_data = ptr[5] >> 4;
- else
+ if (length !=
[PATCH AUTOSEL for 4.14 03/84] video/hdmi: Allow "empty" HDMI infoframes
From: Ville Syrjälä <ville.syrj...@linux.intel.com>
[ Upstream commit 593f4b19a094c4426bd1e1e3cbab87a48bd13c71 ]
HDMI 2.0 Appendix F suggest that we should keep sending the infoframe
when switching from 3D to 2D mode, even if the infoframe isn't strictly
necessary (ie. not needed to transmit the VIC or stereo information).
This is a workaround against some sinks that fail to realize that they
should switch from 3D to 2D mode when the source stop transmitting
the infoframe.
v2: Handle unpack() as well
Pull the length calculation into a helper
Cc: Shashank Sharma <shashank.sha...@intel.com>
Cc: Andrzej Hajda <a.ha...@samsung.com>
Cc: Thierry Reding <thierry.red...@gmail.com>
Cc: Hans Verkuil <hans.verk...@cisco.com>
Cc: linux-media@vger.kernel.org
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
Link:
https://patchwork.freedesktop.org/patch/msgid/20171113170427.4150-2-ville.syrj...@linux.intel.com
Reviewed-by: Shashank Sharma <shashank.sha...@intel.com>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
---
drivers/video/hdmi.c | 51 +++
1 file changed, 31 insertions(+), 20 deletions(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1cf907ecded4..111a0ab6280a 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -321,6 +321,17 @@ int hdmi_vendor_infoframe_init(struct
hdmi_vendor_infoframe *frame)
}
EXPORT_SYMBOL(hdmi_vendor_infoframe_init);
+static int hdmi_vendor_infoframe_length(const struct hdmi_vendor_infoframe
*frame)
+{
+ /* for side by side (half) we also need to provide 3D_Ext_Data */
+ if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
+ return 6;
+ else if (frame->vic != 0 || frame->s3d_struct !=
HDMI_3D_STRUCTURE_INVALID)
+ return 5;
+ else
+ return 4;
+}
+
/**
* hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary
buffer
* @frame: HDMI infoframe
@@ -341,19 +352,11 @@ ssize_t hdmi_vendor_infoframe_pack(struct
hdmi_vendor_infoframe *frame,
u8 *ptr = buffer;
size_t length;
- /* empty info frame */
- if (frame->vic == 0 && frame->s3d_struct == HDMI_3D_STRUCTURE_INVALID)
- return -EINVAL;
-
/* only one of those can be supplied */
if (frame->vic != 0 && frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID)
return -EINVAL;
- /* for side by side (half) we also need to provide 3D_Ext_Data */
- if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
- frame->length = 6;
- else
- frame->length = 5;
+ frame->length = hdmi_vendor_infoframe_length(frame);
length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
@@ -372,14 +375,16 @@ ssize_t hdmi_vendor_infoframe_pack(struct
hdmi_vendor_infoframe *frame,
ptr[5] = 0x0c;
ptr[6] = 0x00;
- if (frame->vic) {
- ptr[7] = 0x1 << 5; /* video format */
- ptr[8] = frame->vic;
- } else {
+ if (frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) {
ptr[7] = 0x2 << 5; /* video format */
ptr[8] = (frame->s3d_struct & 0xf) << 4;
if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
ptr[9] = (frame->s3d_ext_data & 0xf) << 4;
+ } else if (frame->vic) {
+ ptr[7] = 0x1 << 5; /* video format */
+ ptr[8] = frame->vic;
+ } else {
+ ptr[7] = 0x0 << 5; /* video format */
}
hdmi_infoframe_set_checksum(buffer, length);
@@ -1165,7 +1170,7 @@ hdmi_vendor_any_infoframe_unpack(union
hdmi_vendor_any_infoframe *frame,
if (ptr[0] != HDMI_INFOFRAME_TYPE_VENDOR ||
ptr[1] != 1 ||
- (ptr[2] != 5 && ptr[2] != 6))
+ (ptr[2] != 4 && ptr[2] != 5 && ptr[2] != 6))
return -EINVAL;
length = ptr[2];
@@ -1193,16 +1198,22 @@ hdmi_vendor_any_infoframe_unpack(union
hdmi_vendor_any_infoframe *frame,
hvf->length = length;
- if (hdmi_video_format == 0x1) {
- hvf->vic = ptr[4];
- } else if (hdmi_video_format == 0x2) {
+ if (hdmi_video_format == 0x2) {
+ if (length != 5 && length != 6)
+ return -EINVAL;
hvf->s3d_struct = ptr[4] >> 4;
if (hvf->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) {
- if (length == 6)
- hvf->s3d_ext_data = ptr[5] >> 4;
- else
+ if (length !=
[PATCH AUTOSEL for 4.9 172/219] video/hdmi: Allow "empty" HDMI infoframes
From: Ville Syrjälä <ville.syrj...@linux.intel.com>
[ Upstream commit 593f4b19a094c4426bd1e1e3cbab87a48bd13c71 ]
HDMI 2.0 Appendix F suggest that we should keep sending the infoframe
when switching from 3D to 2D mode, even if the infoframe isn't strictly
necessary (ie. not needed to transmit the VIC or stereo information).
This is a workaround against some sinks that fail to realize that they
should switch from 3D to 2D mode when the source stop transmitting
the infoframe.
v2: Handle unpack() as well
Pull the length calculation into a helper
Cc: Shashank Sharma <shashank.sha...@intel.com>
Cc: Andrzej Hajda <a.ha...@samsung.com>
Cc: Thierry Reding <thierry.red...@gmail.com>
Cc: Hans Verkuil <hans.verk...@cisco.com>
Cc: linux-media@vger.kernel.org
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
Link:
https://patchwork.freedesktop.org/patch/msgid/20171113170427.4150-2-ville.syrj...@linux.intel.com
Reviewed-by: Shashank Sharma <shashank.sha...@intel.com>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
---
drivers/video/hdmi.c | 51 +++
1 file changed, 31 insertions(+), 20 deletions(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 162689227a23..b73520aaf697 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -321,6 +321,17 @@ int hdmi_vendor_infoframe_init(struct
hdmi_vendor_infoframe *frame)
}
EXPORT_SYMBOL(hdmi_vendor_infoframe_init);
+static int hdmi_vendor_infoframe_length(const struct hdmi_vendor_infoframe
*frame)
+{
+ /* for side by side (half) we also need to provide 3D_Ext_Data */
+ if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
+ return 6;
+ else if (frame->vic != 0 || frame->s3d_struct !=
HDMI_3D_STRUCTURE_INVALID)
+ return 5;
+ else
+ return 4;
+}
+
/**
* hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary
buffer
* @frame: HDMI infoframe
@@ -341,19 +352,11 @@ ssize_t hdmi_vendor_infoframe_pack(struct
hdmi_vendor_infoframe *frame,
u8 *ptr = buffer;
size_t length;
- /* empty info frame */
- if (frame->vic == 0 && frame->s3d_struct == HDMI_3D_STRUCTURE_INVALID)
- return -EINVAL;
-
/* only one of those can be supplied */
if (frame->vic != 0 && frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID)
return -EINVAL;
- /* for side by side (half) we also need to provide 3D_Ext_Data */
- if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
- frame->length = 6;
- else
- frame->length = 5;
+ frame->length = hdmi_vendor_infoframe_length(frame);
length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
@@ -372,14 +375,16 @@ ssize_t hdmi_vendor_infoframe_pack(struct
hdmi_vendor_infoframe *frame,
ptr[5] = 0x0c;
ptr[6] = 0x00;
- if (frame->vic) {
- ptr[7] = 0x1 << 5; /* video format */
- ptr[8] = frame->vic;
- } else {
+ if (frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) {
ptr[7] = 0x2 << 5; /* video format */
ptr[8] = (frame->s3d_struct & 0xf) << 4;
if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
ptr[9] = (frame->s3d_ext_data & 0xf) << 4;
+ } else if (frame->vic) {
+ ptr[7] = 0x1 << 5; /* video format */
+ ptr[8] = frame->vic;
+ } else {
+ ptr[7] = 0x0 << 5; /* video format */
}
hdmi_infoframe_set_checksum(buffer, length);
@@ -1161,7 +1166,7 @@ hdmi_vendor_any_infoframe_unpack(union
hdmi_vendor_any_infoframe *frame,
if (ptr[0] != HDMI_INFOFRAME_TYPE_VENDOR ||
ptr[1] != 1 ||
- (ptr[2] != 5 && ptr[2] != 6))
+ (ptr[2] != 4 && ptr[2] != 5 && ptr[2] != 6))
return -EINVAL;
length = ptr[2];
@@ -1189,16 +1194,22 @@ hdmi_vendor_any_infoframe_unpack(union
hdmi_vendor_any_infoframe *frame,
hvf->length = length;
- if (hdmi_video_format == 0x1) {
- hvf->vic = ptr[4];
- } else if (hdmi_video_format == 0x2) {
+ if (hdmi_video_format == 0x2) {
+ if (length != 5 && length != 6)
+ return -EINVAL;
hvf->s3d_struct = ptr[4] >> 4;
if (hvf->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) {
- if (length == 6)
- hvf->s3d_ext_data = ptr[5] >> 4;
- else
+ if (length !=
[PATCH AUTOSEL for 4.4 085/115] video/hdmi: Allow "empty" HDMI infoframes
From: Ville Syrjälä <ville.syrj...@linux.intel.com>
[ Upstream commit 593f4b19a094c4426bd1e1e3cbab87a48bd13c71 ]
HDMI 2.0 Appendix F suggest that we should keep sending the infoframe
when switching from 3D to 2D mode, even if the infoframe isn't strictly
necessary (ie. not needed to transmit the VIC or stereo information).
This is a workaround against some sinks that fail to realize that they
should switch from 3D to 2D mode when the source stop transmitting
the infoframe.
v2: Handle unpack() as well
Pull the length calculation into a helper
Cc: Shashank Sharma <shashank.sha...@intel.com>
Cc: Andrzej Hajda <a.ha...@samsung.com>
Cc: Thierry Reding <thierry.red...@gmail.com>
Cc: Hans Verkuil <hans.verk...@cisco.com>
Cc: linux-media@vger.kernel.org
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
Link:
https://patchwork.freedesktop.org/patch/msgid/20171113170427.4150-2-ville.syrj...@linux.intel.com
Reviewed-by: Shashank Sharma <shashank.sha...@intel.com>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
---
drivers/video/hdmi.c | 51 +++
1 file changed, 31 insertions(+), 20 deletions(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 162689227a23..b73520aaf697 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -321,6 +321,17 @@ int hdmi_vendor_infoframe_init(struct
hdmi_vendor_infoframe *frame)
}
EXPORT_SYMBOL(hdmi_vendor_infoframe_init);
+static int hdmi_vendor_infoframe_length(const struct hdmi_vendor_infoframe
*frame)
+{
+ /* for side by side (half) we also need to provide 3D_Ext_Data */
+ if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
+ return 6;
+ else if (frame->vic != 0 || frame->s3d_struct !=
HDMI_3D_STRUCTURE_INVALID)
+ return 5;
+ else
+ return 4;
+}
+
/**
* hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary
buffer
* @frame: HDMI infoframe
@@ -341,19 +352,11 @@ ssize_t hdmi_vendor_infoframe_pack(struct
hdmi_vendor_infoframe *frame,
u8 *ptr = buffer;
size_t length;
- /* empty info frame */
- if (frame->vic == 0 && frame->s3d_struct == HDMI_3D_STRUCTURE_INVALID)
- return -EINVAL;
-
/* only one of those can be supplied */
if (frame->vic != 0 && frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID)
return -EINVAL;
- /* for side by side (half) we also need to provide 3D_Ext_Data */
- if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
- frame->length = 6;
- else
- frame->length = 5;
+ frame->length = hdmi_vendor_infoframe_length(frame);
length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
@@ -372,14 +375,16 @@ ssize_t hdmi_vendor_infoframe_pack(struct
hdmi_vendor_infoframe *frame,
ptr[5] = 0x0c;
ptr[6] = 0x00;
- if (frame->vic) {
- ptr[7] = 0x1 << 5; /* video format */
- ptr[8] = frame->vic;
- } else {
+ if (frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) {
ptr[7] = 0x2 << 5; /* video format */
ptr[8] = (frame->s3d_struct & 0xf) << 4;
if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
ptr[9] = (frame->s3d_ext_data & 0xf) << 4;
+ } else if (frame->vic) {
+ ptr[7] = 0x1 << 5; /* video format */
+ ptr[8] = frame->vic;
+ } else {
+ ptr[7] = 0x0 << 5; /* video format */
}
hdmi_infoframe_set_checksum(buffer, length);
@@ -1161,7 +1166,7 @@ hdmi_vendor_any_infoframe_unpack(union
hdmi_vendor_any_infoframe *frame,
if (ptr[0] != HDMI_INFOFRAME_TYPE_VENDOR ||
ptr[1] != 1 ||
- (ptr[2] != 5 && ptr[2] != 6))
+ (ptr[2] != 4 && ptr[2] != 5 && ptr[2] != 6))
return -EINVAL;
length = ptr[2];
@@ -1189,16 +1194,22 @@ hdmi_vendor_any_infoframe_unpack(union
hdmi_vendor_any_infoframe *frame,
hvf->length = length;
- if (hdmi_video_format == 0x1) {
- hvf->vic = ptr[4];
- } else if (hdmi_video_format == 0x2) {
+ if (hdmi_video_format == 0x2) {
+ if (length != 5 && length != 6)
+ return -EINVAL;
hvf->s3d_struct = ptr[4] >> 4;
if (hvf->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) {
- if (length == 6)
- hvf->s3d_ext_data = ptr[5] >> 4;
- else
+ if (length !=
Re: [PATCH v7] media: vb2: Take queue or device lock in mmap-related vb2 ioctl handlers
Ping?
On 05/23/2014 09:54 AM, Hans Verkuil wrote:
Hi Laurent,
This patch caused a circular locking dependency as reported by Sasha Levin:
https://lkml.org/lkml/2014/5/5/366
The reason is that copy_to/from_user is called in video_usercopy() with the
core lock held. The copy functions can fault which takes the mmap_sem. If it
was just video_usercopy() then it would be fairly easy to solve this, but
the copy_to_/from_user functions are also called from read and write and they
can be used in other unexpected places.
I'm not sure if vb2_fop_get_unmapped_area() is a problem. I suspect (but I'm
not sure) that when that one is called the mmap_sem isn't taken, in which
case taking the lock is fine.
But taking the lock in vb2_fop_mmap() does cause lockdep problems.
Ideally I would like to drop taking that lock in vb2_fop_mmap and resolve the
race condition that it intended to fix in a different way.
Regards,
Hans
On 08/06/2013 10:10 PM, Laurent Pinchart wrote:
The vb2_fop_mmap() and vb2_fop_get_unmapped_area() functions are plug-in
implementation of the mmap() and get_unmapped_area() file operations
that calls vb2_mmap() and vb2_get_unmapped_area() on the queue
associated with the video device. Neither the
vb2_fop_mmap/vb2_fop_get_unmapped_area nor the
v4l2_mmap/vb2_get_unmapped_area functions in the V4L2 core take any
lock, leading to race conditions between mmap/get_unmapped_area and
other buffer-related ioctls such as VIDIOC_REQBUFS.
Fix it by taking the queue or device lock around the vb2_mmap() and
vb2_get_unmapped_area() calls.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
drivers/media/v4l2-core/videobuf2-core.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 9fc4bab..c9b50c7 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2578,8 +2578,15 @@ EXPORT_SYMBOL_GPL(vb2_ioctl_expbuf);
int vb2_fop_mmap(struct file *file, struct vm_area_struct *vma)
{
struct video_device *vdev = video_devdata(file);
+struct mutex *lock = vdev-queue-lock ? vdev-queue-lock : vdev-lock;
+int err;
-return vb2_mmap(vdev-queue, vma);
+if (lock mutex_lock_interruptible(lock))
+return -ERESTARTSYS;
+err = vb2_mmap(vdev-queue, vma);
+if (lock)
+mutex_unlock(lock);
+return err;
}
EXPORT_SYMBOL_GPL(vb2_fop_mmap);
@@ -2685,8 +2692,15 @@ unsigned long vb2_fop_get_unmapped_area(struct file
*file, unsigned long addr,
unsigned long len, unsigned long pgoff, unsigned long flags)
{
struct video_device *vdev = video_devdata(file);
+struct mutex *lock = vdev-queue-lock ? vdev-queue-lock : vdev-lock;
+int ret;
-return vb2_get_unmapped_area(vdev-queue, addr, len, pgoff, flags);
+if (lock mutex_lock_interruptible(lock))
+return -ERESTARTSYS;
+ret = vb2_get_unmapped_area(vdev-queue, addr, len, pgoff, flags);
+if (lock)
+mutex_unlock(lock);
+return ret;
}
EXPORT_SYMBOL_GPL(vb2_fop_get_unmapped_area);
#endif
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l2: circular locking between mmap_sem and device mutex
ping?
On 05/05/2014 11:49 AM, Sasha Levin wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest running latest -next
kernel I've stumbled on the following:
[ 2179.111265] ==
[ 2179.112228] [ INFO: possible circular locking dependency detected ]
[ 2179.113144] 3.15.0-rc3-next-20140502-sasha-00020-g3183c20 #432 Tainted: G
W
[ 2179.114325] ---
[ 2179.115286] trinity-c15/27050 is trying to acquire lock:
[ 2179.116071] (dev-mutex#3){+.+.+.}, at: vb2_fop_mmap
(drivers/media/v4l2-core/videobuf2-core.c:3029 (discriminator 1))
[ 2179.117347]
[ 2179.117347] but task is already holding lock:
[ 2179.118185] (mm-mmap_sem){++}, at: vm_mmap_pgoff (mm/util.c:398)
[ 2179.120023]
[ 2179.120023] which lock already depends on the new lock.
[ 2179.120023]
[ 2179.120036]
[ 2179.120036] the existing dependency chain (in reverse order) is:
[ 2179.120036]
- #1 (mm-mmap_sem){++}:
[ 2179.120036] lock_acquire (arch/x86/include/asm/current.h:14
kernel/locking/lockdep.c:3602)
[ 2179.120036] might_fault (mm/memory.c:4368)
[ 2179.120036] video_usercopy (arch/x86/include/asm/uaccess.h:713
drivers/media/v4l2-core/v4l2-ioctl.c:2369)
[ 2179.120036] video_ioctl2 (drivers/media/v4l2-core/v4l2-ioctl.c:2445)
[ 2179.120036] v4l2_ioctl (drivers/media/v4l2-core/v4l2-dev.c:355)
[ 2179.120036] do_vfs_ioctl (fs/ioctl.c:44 fs/ioctl.c:598)
[ 2179.120036] SyS_ioctl (include/linux/file.h:38 fs/ioctl.c:614
fs/ioctl.c:604)
[ 2179.120036] tracesys (arch/x86/kernel/entry_64.S:746)
[ 2179.120036]
- #0 (dev-mutex#3){+.+.+.}:
[ 2179.120036] __lock_acquire (kernel/locking/lockdep.c:1840
kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131
kernel/locking/lockdep.c:3182)
[ 2179.120036] lock_acquire (arch/x86/include/asm/current.h:14
kernel/locking/lockdep.c:3602)
[ 2179.120036] mutex_lock_interruptible_nested (kernel/locking/mutex.c:486
kernel/locking/mutex.c:616)
[ 2179.120036] vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
(discriminator 1))
[ 2179.120036] v4l2_mmap (drivers/media/v4l2-core/v4l2-dev.c:427)
[ 2179.120036] mmap_region (mm/mmap.c:1577)
[ 2179.120036] do_mmap_pgoff (mm/mmap.c:1369)
[ 2179.120036] vm_mmap_pgoff (mm/util.c:400)
[ 2179.120036] SyS_mmap_pgoff (mm/mmap.c:1418 mm/mmap.c:1378)
[ 2179.120036] SyS_mmap (arch/x86/kernel/sys_x86_64.c:72)
[ 2179.120036] tracesys (arch/x86/kernel/entry_64.S:746)
[ 2179.120036]
[ 2179.120036] other info that might help us debug this:
[ 2179.120036]
[ 2179.120036] Possible unsafe locking scenario:
[ 2179.120036]
[ 2179.120036]CPU0CPU1
[ 2179.120036]
[ 2179.120036] lock(mm-mmap_sem);
[ 2179.120036]lock(dev-mutex#3);
[ 2179.120036]lock(mm-mmap_sem);
[ 2179.120036] lock(dev-mutex#3);
[ 2179.120036]
[ 2179.120036] *** DEADLOCK ***
[ 2179.120036]
[ 2179.120036] 1 lock held by trinity-c15/27050:
[ 2179.120036] #0: (mm-mmap_sem){++}, at: vm_mmap_pgoff (mm/util.c:398)
[ 2179.120036]
[ 2179.120036] stack backtrace:
[ 2179.120036] CPU: 1 PID: 27050 Comm: trinity-c15 Tainted: GW
3.15.0-rc3-next-20140502-sasha-00020-g3183c20 #432
[ 2179.120036] baa718e0 88065df9dab8 b75326bb
0002
[ 2179.120036] baa718e0 88065df9db08 b7525488
0001
[ 2179.120036] 88065df9db98 88065df9db08 88065dd63cf0
88065dd63d28
[ 2179.120036] Call Trace:
[ 2179.120036] dump_stack (lib/dump_stack.c:52)
[ 2179.120036] print_circular_bug (kernel/locking/lockdep.c:1216)
[ 2179.120036] __lock_acquire (kernel/locking/lockdep.c:1840
kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131
kernel/locking/lockdep.c:3182)
[ 2179.120036] ? mmap_region (mm/mmap.c:1556)
[ 2179.120036] lock_acquire (arch/x86/include/asm/current.h:14
kernel/locking/lockdep.c:3602)
[ 2179.120036] ? vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
(discriminator 1))
[ 2179.120036] mutex_lock_interruptible_nested (kernel/locking/mutex.c:486
kernel/locking/mutex.c:616)
[ 2179.120036] ? vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
(discriminator 1))
[ 2179.120036] ? vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
(discriminator 1))
[ 2179.120036] ? get_parent_ip (kernel/sched/core.c:2485)
[ 2179.120036] vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
(discriminator 1))
[ 2179.120036] ? mmap_region (mm/mmap.c:1556)
[ 2179.120036] ? mmap_region (mm/mmap.c:1556)
[ 2179.120036] v4l2_mmap (drivers/media/v4l2-core/v4l2-dev.c:427)
[ 2179.120036] mmap_region (mm/mmap.c:1577)
[ 2179.120036] do_mmap_pgoff (mm/mmap.c:1369)
[ 2179.120036] ? vm_mmap_pgoff (mm/util.c:398)
[ 2179.120036] vm_mmap_pgoff (mm/util.c:400)
[ 2179.120036
v4l2: circular locking between mmap_sem and device mutex
Hi all,
While fuzzing with trinity inside a KVM tools guest running latest -next
kernel I've stumbled on the following:
[ 2179.111265] ==
[ 2179.112228] [ INFO: possible circular locking dependency detected ]
[ 2179.113144] 3.15.0-rc3-next-20140502-sasha-00020-g3183c20 #432 Tainted: G
W
[ 2179.114325] ---
[ 2179.115286] trinity-c15/27050 is trying to acquire lock:
[ 2179.116071] (dev-mutex#3){+.+.+.}, at: vb2_fop_mmap
(drivers/media/v4l2-core/videobuf2-core.c:3029 (discriminator 1))
[ 2179.117347]
[ 2179.117347] but task is already holding lock:
[ 2179.118185] (mm-mmap_sem){++}, at: vm_mmap_pgoff (mm/util.c:398)
[ 2179.120023]
[ 2179.120023] which lock already depends on the new lock.
[ 2179.120023]
[ 2179.120036]
[ 2179.120036] the existing dependency chain (in reverse order) is:
[ 2179.120036]
- #1 (mm-mmap_sem){++}:
[ 2179.120036] lock_acquire (arch/x86/include/asm/current.h:14
kernel/locking/lockdep.c:3602)
[ 2179.120036] might_fault (mm/memory.c:4368)
[ 2179.120036] video_usercopy (arch/x86/include/asm/uaccess.h:713
drivers/media/v4l2-core/v4l2-ioctl.c:2369)
[ 2179.120036] video_ioctl2 (drivers/media/v4l2-core/v4l2-ioctl.c:2445)
[ 2179.120036] v4l2_ioctl (drivers/media/v4l2-core/v4l2-dev.c:355)
[ 2179.120036] do_vfs_ioctl (fs/ioctl.c:44 fs/ioctl.c:598)
[ 2179.120036] SyS_ioctl (include/linux/file.h:38 fs/ioctl.c:614 fs/ioctl.c:604)
[ 2179.120036] tracesys (arch/x86/kernel/entry_64.S:746)
[ 2179.120036]
- #0 (dev-mutex#3){+.+.+.}:
[ 2179.120036] __lock_acquire (kernel/locking/lockdep.c:1840
kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131
kernel/locking/lockdep.c:3182)
[ 2179.120036] lock_acquire (arch/x86/include/asm/current.h:14
kernel/locking/lockdep.c:3602)
[ 2179.120036] mutex_lock_interruptible_nested (kernel/locking/mutex.c:486
kernel/locking/mutex.c:616)
[ 2179.120036] vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
(discriminator 1))
[ 2179.120036] v4l2_mmap (drivers/media/v4l2-core/v4l2-dev.c:427)
[ 2179.120036] mmap_region (mm/mmap.c:1577)
[ 2179.120036] do_mmap_pgoff (mm/mmap.c:1369)
[ 2179.120036] vm_mmap_pgoff (mm/util.c:400)
[ 2179.120036] SyS_mmap_pgoff (mm/mmap.c:1418 mm/mmap.c:1378)
[ 2179.120036] SyS_mmap (arch/x86/kernel/sys_x86_64.c:72)
[ 2179.120036] tracesys (arch/x86/kernel/entry_64.S:746)
[ 2179.120036]
[ 2179.120036] other info that might help us debug this:
[ 2179.120036]
[ 2179.120036] Possible unsafe locking scenario:
[ 2179.120036]
[ 2179.120036]CPU0CPU1
[ 2179.120036]
[ 2179.120036] lock(mm-mmap_sem);
[ 2179.120036]lock(dev-mutex#3);
[ 2179.120036]lock(mm-mmap_sem);
[ 2179.120036] lock(dev-mutex#3);
[ 2179.120036]
[ 2179.120036] *** DEADLOCK ***
[ 2179.120036]
[ 2179.120036] 1 lock held by trinity-c15/27050:
[ 2179.120036] #0: (mm-mmap_sem){++}, at: vm_mmap_pgoff (mm/util.c:398)
[ 2179.120036]
[ 2179.120036] stack backtrace:
[ 2179.120036] CPU: 1 PID: 27050 Comm: trinity-c15 Tainted: GW
3.15.0-rc3-next-20140502-sasha-00020-g3183c20 #432
[ 2179.120036] baa718e0 88065df9dab8 b75326bb
0002
[ 2179.120036] baa718e0 88065df9db08 b7525488
0001
[ 2179.120036] 88065df9db98 88065df9db08 88065dd63cf0
88065dd63d28
[ 2179.120036] Call Trace:
[ 2179.120036] dump_stack (lib/dump_stack.c:52)
[ 2179.120036] print_circular_bug (kernel/locking/lockdep.c:1216)
[ 2179.120036] __lock_acquire (kernel/locking/lockdep.c:1840
kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131
kernel/locking/lockdep.c:3182)
[ 2179.120036] ? mmap_region (mm/mmap.c:1556)
[ 2179.120036] lock_acquire (arch/x86/include/asm/current.h:14
kernel/locking/lockdep.c:3602)
[ 2179.120036] ? vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
(discriminator 1))
[ 2179.120036] mutex_lock_interruptible_nested (kernel/locking/mutex.c:486
kernel/locking/mutex.c:616)
[ 2179.120036] ? vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
(discriminator 1))
[ 2179.120036] ? vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
(discriminator 1))
[ 2179.120036] ? get_parent_ip (kernel/sched/core.c:2485)
[ 2179.120036] vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
(discriminator 1))
[ 2179.120036] ? mmap_region (mm/mmap.c:1556)
[ 2179.120036] ? mmap_region (mm/mmap.c:1556)
[ 2179.120036] v4l2_mmap (drivers/media/v4l2-core/v4l2-dev.c:427)
[ 2179.120036] mmap_region (mm/mmap.c:1577)
[ 2179.120036] do_mmap_pgoff (mm/mmap.c:1369)
[ 2179.120036] ? vm_mmap_pgoff (mm/util.c:398)
[ 2179.120036] vm_mmap_pgoff (mm/util.c:400)
[ 2179.120036] ? __rcu_read_unlock (kernel/rcu/update.c:97)
[ 2179.120036] ? __fget (fs/file.c:633)
[ 2179.120036] SyS_mmap_pgoff (mm/mmap.c:1418 mm/mmap.c:1378)
[ 2179.120036] SyS_mmap
Re: v4l2: lockdep spew mmap_sem/dev_mutex
Ping? This is still happening in -next, more than half a year later...
Thanks,
Sasha
On 05/06/2013 09:29 PM, Sasha Levin wrote:
Hi guys,
While fuzzing with trinity running inside a KVM tools guest, using latest
-next kernel,
I've stumbled on the following spew:
[ 160.267181] ==
[ 160.267896] [ INFO: possible circular locking dependency detected ]
[ 160.268631] 3.9.0-next-20130506-sasha-00012-g01de88a #356 Tainted: G
W
[ 160.269486] ---
[ 160.271108] trinity-child3/10132 is trying to acquire lock:
[ 160.271108] (dev-dev_mutex){+.+.+.}, at: [831c39f1]
m2mtest_mmap+0x51/0x90
[ 160.271108]
[ 160.271108] but task is already holding lock:
[ 160.271108] (mm-mmap_sem){++}, at: [8124ff02]
vm_mmap_pgoff+0x62/0xd0
[ 160.271108]
[ 160.271108] which lock already depends on the new lock.
[ 160.271108]
[ 160.271108]
[ 160.271108] the existing dependency chain (in reverse order) is:
[ 160.271108]
- #1 (mm-mmap_sem){++}:
[ 160.271108][811a1f5a] lock_acquire+0x1aa/0x240
[ 160.271108][81259f8b] might_fault+0x7b/0xa0
[ 160.271108][8315d82e] video_usercopy+0x41e/0x490
[ 160.271108][8315d8b0] video_ioctl2+0x10/0x20
[ 160.271108][83157c33] v4l2_ioctl+0xa3/0x170
[ 160.271108][812bff52] do_vfs_ioctl+0x522/0x570
[ 160.271108][812bfffd] SyS_ioctl+0x5d/0xa0
[ 160.271108][84028558] tracesys+0xe1/0xe6
[ 160.271108]
- #0 (dev-dev_mutex){+.+.+.}:
[ 160.271108][811a0e4f] __lock_acquire+0x15af/0x1e40
[ 160.271108][811a1f5a] lock_acquire+0x1aa/0x240
[ 160.271108][8401bf89] __mutex_lock_common+0x59/0x600
[ 160.271108][8401c56f]
mutex_lock_interruptible_nested+0x3f/0x50
[ 160.271108][831c39f1] m2mtest_mmap+0x51/0x90
[ 160.271108][831576b8] v4l2_mmap+0x48/0xa0
[ 160.271108][81265fbb] mmap_region+0x33b/0x630
[ 160.271108][812665c6] do_mmap_pgoff+0x316/0x3d0
[ 160.271108][8124ff23] vm_mmap_pgoff+0x83/0xd0
[ 160.271108][81264b2e] SyS_mmap_pgoff+0x16e/0x1b0
[ 160.271108][8106ea2d] SyS_mmap+0x1d/0x20
[ 160.271108][84028558] tracesys+0xe1/0xe6
[ 160.271108]
[ 160.271108] other info that might help us debug this:
[ 160.271108]
[ 160.271108] Possible unsafe locking scenario:
[ 160.271108]
[ 160.271108]CPU0CPU1
[ 160.271108]
[ 160.271108] lock(mm-mmap_sem);
[ 160.271108]lock(dev-dev_mutex);
[ 160.271108]lock(mm-mmap_sem);
[ 160.271108] lock(dev-dev_mutex);
[ 160.271108]
[ 160.271108] *** DEADLOCK ***
[ 160.271108]
[ 160.271108] 1 lock held by trinity-child3/10132:
[ 160.271108] #0: (mm-mmap_sem){++}, at: [8124ff02]
vm_mmap_pgoff+0x62/0xd0
[ 160.271108]
[ 160.271108] stack backtrace:
[ 160.271108] CPU: 3 PID: 10132 Comm: trinity-child3 Tainted: GW
3.9.0-next-20130506-sasha-00012-g01de88a #356
[ 160.271108] 86ba8bf0 8800ab3aba78 83fde6a3
8800ab3abac8
[ 160.271108] 83fd33cf 00abc6d5 8800ab3abb58
8800ab3abac8
[ 160.271108] 88009314b9b0 88009314b978 88009314b000
00abc6d5
[ 160.271108] Call Trace:
[ 160.271108] [83fde6a3] dump_stack+0x19/0x1b
[ 160.271108] [83fd33cf] print_circular_bug+0x1fb/0x20c
[ 160.271108] [811a0e4f] __lock_acquire+0x15af/0x1e40
[ 160.271108] [8401fb60] ? _raw_spin_unlock+0x30/0x60
[ 160.271108] [811a1f5a] lock_acquire+0x1aa/0x240
[ 160.271108] [831c39f1] ? m2mtest_mmap+0x51/0x90
[ 160.271108] [8401bf89] __mutex_lock_common+0x59/0x600
[ 160.271108] [831c39f1] ? m2mtest_mmap+0x51/0x90
[ 160.271108] [8119e9aa] ? __lock_is_held+0x5a/0x80
[ 160.271108] [81265ee4] ? mmap_region+0x264/0x630
[ 160.271108] [831c39f1] ? m2mtest_mmap+0x51/0x90
[ 160.271108] [8401c56f] mutex_lock_interruptible_nested+0x3f/0x50
[ 160.271108] [831c39f1] m2mtest_mmap+0x51/0x90
[ 160.271108] [81265ee4] ? mmap_region+0x264/0x630
[ 160.271108] [831576b8] v4l2_mmap+0x48/0xa0
[ 160.271108] [81265fbb] mmap_region+0x33b/0x630
[ 160.271108] [812665c6] do_mmap_pgoff+0x316/0x3d0
[ 160.271108] [8124ff02] ? vm_mmap_pgoff+0x62/0xd0
[ 160.271108] [8124ff23] vm_mmap_pgoff+0x83/0xd0
[ 160.271108] [81a4a889] ? __const_udelay+0x29/0x30
[ 160.271108] [81151824] ? __rcu_read_unlock+0x44/0xb0
[ 160.271108] [812cace0] ? fget_raw
v4l2: lockdep spew mmap_sem/dev_mutex
Hi guys,
While fuzzing with trinity running inside a KVM tools guest, using latest -next
kernel,
I've stumbled on the following spew:
[ 160.267181] ==
[ 160.267896] [ INFO: possible circular locking dependency detected ]
[ 160.268631] 3.9.0-next-20130506-sasha-00012-g01de88a #356 Tainted: GW
[ 160.269486] ---
[ 160.271108] trinity-child3/10132 is trying to acquire lock:
[ 160.271108] (dev-dev_mutex){+.+.+.}, at: [831c39f1]
m2mtest_mmap+0x51/0x90
[ 160.271108]
[ 160.271108] but task is already holding lock:
[ 160.271108] (mm-mmap_sem){++}, at: [8124ff02]
vm_mmap_pgoff+0x62/0xd0
[ 160.271108]
[ 160.271108] which lock already depends on the new lock.
[ 160.271108]
[ 160.271108]
[ 160.271108] the existing dependency chain (in reverse order) is:
[ 160.271108]
- #1 (mm-mmap_sem){++}:
[ 160.271108][811a1f5a] lock_acquire+0x1aa/0x240
[ 160.271108][81259f8b] might_fault+0x7b/0xa0
[ 160.271108][8315d82e] video_usercopy+0x41e/0x490
[ 160.271108][8315d8b0] video_ioctl2+0x10/0x20
[ 160.271108][83157c33] v4l2_ioctl+0xa3/0x170
[ 160.271108][812bff52] do_vfs_ioctl+0x522/0x570
[ 160.271108][812bfffd] SyS_ioctl+0x5d/0xa0
[ 160.271108][84028558] tracesys+0xe1/0xe6
[ 160.271108]
- #0 (dev-dev_mutex){+.+.+.}:
[ 160.271108][811a0e4f] __lock_acquire+0x15af/0x1e40
[ 160.271108][811a1f5a] lock_acquire+0x1aa/0x240
[ 160.271108][8401bf89] __mutex_lock_common+0x59/0x600
[ 160.271108][8401c56f]
mutex_lock_interruptible_nested+0x3f/0x50
[ 160.271108][831c39f1] m2mtest_mmap+0x51/0x90
[ 160.271108][831576b8] v4l2_mmap+0x48/0xa0
[ 160.271108][81265fbb] mmap_region+0x33b/0x630
[ 160.271108][812665c6] do_mmap_pgoff+0x316/0x3d0
[ 160.271108][8124ff23] vm_mmap_pgoff+0x83/0xd0
[ 160.271108][81264b2e] SyS_mmap_pgoff+0x16e/0x1b0
[ 160.271108][8106ea2d] SyS_mmap+0x1d/0x20
[ 160.271108][84028558] tracesys+0xe1/0xe6
[ 160.271108]
[ 160.271108] other info that might help us debug this:
[ 160.271108]
[ 160.271108] Possible unsafe locking scenario:
[ 160.271108]
[ 160.271108]CPU0CPU1
[ 160.271108]
[ 160.271108] lock(mm-mmap_sem);
[ 160.271108]lock(dev-dev_mutex);
[ 160.271108]lock(mm-mmap_sem);
[ 160.271108] lock(dev-dev_mutex);
[ 160.271108]
[ 160.271108] *** DEADLOCK ***
[ 160.271108]
[ 160.271108] 1 lock held by trinity-child3/10132:
[ 160.271108] #0: (mm-mmap_sem){++}, at: [8124ff02]
vm_mmap_pgoff+0x62/0xd0
[ 160.271108]
[ 160.271108] stack backtrace:
[ 160.271108] CPU: 3 PID: 10132 Comm: trinity-child3 Tainted: GW
3.9.0-next-20130506-sasha-00012-g01de88a #356
[ 160.271108] 86ba8bf0 8800ab3aba78 83fde6a3
8800ab3abac8
[ 160.271108] 83fd33cf 00abc6d5 8800ab3abb58
8800ab3abac8
[ 160.271108] 88009314b9b0 88009314b978 88009314b000
00abc6d5
[ 160.271108] Call Trace:
[ 160.271108] [83fde6a3] dump_stack+0x19/0x1b
[ 160.271108] [83fd33cf] print_circular_bug+0x1fb/0x20c
[ 160.271108] [811a0e4f] __lock_acquire+0x15af/0x1e40
[ 160.271108] [8401fb60] ? _raw_spin_unlock+0x30/0x60
[ 160.271108] [811a1f5a] lock_acquire+0x1aa/0x240
[ 160.271108] [831c39f1] ? m2mtest_mmap+0x51/0x90
[ 160.271108] [8401bf89] __mutex_lock_common+0x59/0x600
[ 160.271108] [831c39f1] ? m2mtest_mmap+0x51/0x90
[ 160.271108] [8119e9aa] ? __lock_is_held+0x5a/0x80
[ 160.271108] [81265ee4] ? mmap_region+0x264/0x630
[ 160.271108] [831c39f1] ? m2mtest_mmap+0x51/0x90
[ 160.271108] [8401c56f] mutex_lock_interruptible_nested+0x3f/0x50
[ 160.271108] [831c39f1] m2mtest_mmap+0x51/0x90
[ 160.271108] [81265ee4] ? mmap_region+0x264/0x630
[ 160.271108] [831576b8] v4l2_mmap+0x48/0xa0
[ 160.271108] [81265fbb] mmap_region+0x33b/0x630
[ 160.271108] [812665c6] do_mmap_pgoff+0x316/0x3d0
[ 160.271108] [8124ff02] ? vm_mmap_pgoff+0x62/0xd0
[ 160.271108] [8124ff23] vm_mmap_pgoff+0x83/0xd0
[ 160.271108] [81a4a889] ? __const_udelay+0x29/0x30
[ 160.271108] [81151824] ? __rcu_read_unlock+0x44/0xb0
[ 160.271108] [812cace0] ? fget_raw+0x280/0x280
[ 160.271108] [81264b2e] SyS_mmap_pgoff+0x16e/0x1b0
[ 160.271108] [8106ea2d] SyS_mmap+0x1d/0x20
[ 160.271108] [84028558] tracesys+0xe1/0xe6
Thanks,
Sasha
--
To unsubscribe from this list:
Re: [PATCH] rc-core: don't return from store_protocols without releasing device mutex
Ping?
On Sat, Dec 8, 2012 at 7:50 AM, Sasha Levin sasha.le...@oracle.com wrote:
Commit c003ab1b ([media] rc-core: add separate defines for protocol bitmaps
and numbers) has introduced a bug which allows store_protocols() to return
without releasing the device mutex it's holding.
Doing that would cause infinite hangs waiting on device mutex next time
around.
Signed-off-by: Sasha Levin sasha.le...@oracle.com
---
drivers/media/rc/rc-main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 601d1ac1..0510f4d 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -890,7 +890,8 @@ static ssize_t store_protocols(struct device *device,
if (i == ARRAY_SIZE(proto_names)) {
IR_dprintk(1, Unknown protocol: '%s'\n, tmp);
- return -EINVAL;
+ ret = -EINVAL;
+ goto out;
}
count++;
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] m2m-deinterlace: use correct check for kzalloc failure
There is no point in PTR_ERR()ing a NULL pointer, use a real error
instead.
Signed-off-by: Sasha Levin sasha.le...@oracle.com
---
drivers/media/platform/m2m-deinterlace.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/media/platform/m2m-deinterlace.c
b/drivers/media/platform/m2m-deinterlace.c
index 05c560f..64db74e 100644
--- a/drivers/media/platform/m2m-deinterlace.c
+++ b/drivers/media/platform/m2m-deinterlace.c
@@ -917,10 +917,8 @@ static int deinterlace_open(struct file *file)
ctx-xt = kzalloc(sizeof(struct dma_async_tx_descriptor) +
sizeof(struct data_chunk), GFP_KERNEL);
if (!ctx-xt) {
- int ret = PTR_ERR(ctx-xt);
-
kfree(ctx);
- return ret;
+ return -ENOMEM;
}
ctx-colorspace = V4L2_COLORSPACE_REC709;
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] rc-core: don't return from store_protocols without releasing device mutex
Commit c003ab1b ([media] rc-core: add separate defines for protocol bitmaps
and numbers) has introduced a bug which allows store_protocols() to return
without releasing the device mutex it's holding.
Doing that would cause infinite hangs waiting on device mutex next time
around.
Signed-off-by: Sasha Levin sasha.le...@oracle.com
---
drivers/media/rc/rc-main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 601d1ac1..0510f4d 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -890,7 +890,8 @@ static ssize_t store_protocols(struct device *device,
if (i == ARRAY_SIZE(proto_names)) {
IR_dprintk(1, Unknown protocol: '%s'\n, tmp);
- return -EINVAL;
+ ret = -EINVAL;
+ goto out;
}
count++;
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: Staging: media: lirc: initialize spinlocks before usage
Ping? This thing still causes spinlock errors in 3.5-rc2.
On Sat, May 26, 2012 at 9:25 PM, Sasha Levin levinsasha...@gmail.com wrote:
Initialize the spinlock for each hardware time.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
drivers/staging/media/lirc/lirc_serial.c | 6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/media/lirc/lirc_serial.c
b/drivers/staging/media/lirc/lirc_serial.c
index 3295ea6..97ef670 100644
--- a/drivers/staging/media/lirc/lirc_serial.c
+++ b/drivers/staging/media/lirc/lirc_serial.c
@@ -129,6 +129,7 @@ static void send_space_homebrew(long length);
static struct lirc_serial hardware[] = {
[LIRC_HOMEBREW] = {
+ .lock = __SPIN_LOCK_UNLOCKED(hardware[LIRC_HOMEBREW].lock),
.signal_pin = UART_MSR_DCD,
.signal_pin_change = UART_MSR_DDCD,
.on = (UART_MCR_RTS | UART_MCR_OUT2 | UART_MCR_DTR),
@@ -145,6 +146,7 @@ static struct lirc_serial hardware[] = {
},
[LIRC_IRDEO] = {
+ .lock = __SPIN_LOCK_UNLOCKED(hardware[LIRC_IRDEO].lock),
.signal_pin = UART_MSR_DSR,
.signal_pin_change = UART_MSR_DDSR,
.on = UART_MCR_OUT2,
@@ -156,6 +158,7 @@ static struct lirc_serial hardware[] = {
},
[LIRC_IRDEO_REMOTE] = {
+ .lock =
__SPIN_LOCK_UNLOCKED(hardware[LIRC_IRDEO_REMOTE].lock),
.signal_pin = UART_MSR_DSR,
.signal_pin_change = UART_MSR_DDSR,
.on = (UART_MCR_RTS | UART_MCR_DTR | UART_MCR_OUT2),
@@ -167,6 +170,7 @@ static struct lirc_serial hardware[] = {
},
[LIRC_ANIMAX] = {
+ .lock = __SPIN_LOCK_UNLOCKED(hardware[LIRC_ANIMAX].lock),
.signal_pin = UART_MSR_DCD,
.signal_pin_change = UART_MSR_DDCD,
.on = 0,
@@ -177,6 +181,7 @@ static struct lirc_serial hardware[] = {
},
[LIRC_IGOR] = {
+ .lock = __SPIN_LOCK_UNLOCKED(hardware[LIRC_IGOR].lock),
.signal_pin = UART_MSR_DSR,
.signal_pin_change = UART_MSR_DDSR,
.on = (UART_MCR_RTS | UART_MCR_OUT2 | UART_MCR_DTR),
@@ -201,6 +206,7 @@ static struct lirc_serial hardware[] = {
* See also http://www.nslu2-linux.org for this device
*/
[LIRC_NSLU2] = {
+ .lock = __SPIN_LOCK_UNLOCKED(hardware[LIRC_NSLU2].lock),
.signal_pin = UART_MSR_CTS,
.signal_pin_change = UART_MSR_DCTS,
.on = (UART_MCR_RTS | UART_MCR_OUT2 | UART_MCR_DTR),
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
