public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Saikiran <bjsaikiran@gmail.com>
To: linux-media@vger.kernel.org
Cc: linux-arm-msm@vger.kernel.org, rfoss@kernel.org,
	todor.too@gmail.com, bryan.odonoghue@linaro.org, bod@kernel.org,
	vladimir.zapolskiy@linaro.org, hansg@kernel.org,
	sakari.ailus@linux.intel.com, mchehab@kernel.org,
	Saikiran <bjsaikiran@gmail.com>
Subject: [PATCH] media: qcom: camss: Fix pipeline lock leak in stop_streaming
Date: Sat, 24 Jan 2026 12:47:49 +0530	[thread overview]
Message-ID: <20260124071751.5885-2-bjsaikiran@gmail.com> (raw)
In-Reply-To: <20260124071751.5885-1-bjsaikiran@gmail.com>

When a browser or application closes the camera, if any subdevice fails
to stop streaming, the video_stop_streaming() function returns early
without calling video_device_pipeline_stop(). This leaves the media
pipeline permanently locked, preventing any other application from
accessing the camera until reboot.

Symptom:
--------
1. Open camera in browser (via pipewire/libcamera)
2. Close browser
3. Try to open camera in another app (e.g., qcam)
4. Error: "Pipeline handler in use by another process"
5. Camera remains locked until reboot

Root Cause:
-----------
In video_stop_streaming() at line 315-318:

  ret = v4l2_subdev_call(subdev, video, s_stream, 0);
  if (ret) {
      dev_err(...);
      return;  // ❌ Early return without pipeline_stop()
  }

This skips the critical cleanup at line 321:
  video_device_pipeline_stop(vdev);

Solution:
---------
Continue stopping all subdevices even if one fails, and ALWAYS call
video_device_pipeline_stop() to release the pipeline lock. This
ensures proper cleanup even in error cases.

The pipeline MUST be released when streaming stops, regardless of
whether individual subdevices report errors. Failing to do so creates
a permanent resource leak that can only be fixed by rebooting.

Fixes: Camera permanently locked after browser closes
Tested-on: Lenovo Yoga Slim 7x (Snapdragon X Elite, ov02c10 camera)
Signed-off-by: Saikiran <bjsaikiran@gmail.com>
---
 drivers/media/platform/qcom/camss/camss-video.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss-video.c b/drivers/media/platform/qcom/camss/camss-video.c
index 831486e14754..578c0ae3d997 100644
--- a/drivers/media/platform/qcom/camss/camss-video.c
+++ b/drivers/media/platform/qcom/camss/camss-video.c
@@ -312,10 +312,15 @@ static void video_stop_streaming(struct vb2_queue *q)
 
 		ret = v4l2_subdev_call(subdev, video, s_stream, 0);
 
-		if (ret) {
-			dev_err(video->camss->dev, "Video pipeline stop failed: %d\n", ret);
-			return;
-		}
+		/*
+		 * Don't return early on error - we must continue to stop
+		 * remaining subdevices and release the pipeline lock to
+		 * prevent the camera from being permanently locked.
+		 */
+		if (ret)
+			dev_err(video->camss->dev,
+				"Failed to stop subdev '%s': %d\n",
+				subdev->name, ret);
 	}
 
 	video_device_pipeline_stop(vdev);
-- 
2.51.0


  reply	other threads:[~2026-01-24  7:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-24  7:17 [PATCH 0/3] Fix OV02C10 camera stability on Snapdragon X Elite Saikiran
2026-01-24  7:17 ` Saikiran [this message]
2026-01-25 12:23   ` [PATCH] media: qcom: camss: Fix pipeline lock leak in stop_streaming Bryan O'Donoghue
2026-01-24  7:17 ` [PATCH] media: i2c: ov02c10: Check for errors in disable_streams Saikiran
2026-01-25 12:26   ` Bryan O'Donoghue
2026-01-26 10:18   ` Hans de Goede
2026-01-24  7:17 ` [PATCH] media: i2c: ov02c10: Enforce cool-down period to prevent brownout Saikiran
2026-01-25 13:21   ` Bryan O'Donoghue

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260124071751.5885-2-bjsaikiran@gmail.com \
    --to=bjsaikiran@gmail.com \
    --cc=bod@kernel.org \
    --cc=bryan.odonoghue@linaro.org \
    --cc=hansg@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=rfoss@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=todor.too@gmail.com \
    --cc=vladimir.zapolskiy@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox