Message ID | 20240610100530.1107771-11-sakari.ailus@linux.intel.com (mailing list archive) |
---|---|
State | New |
Headers |
Received: from am.mirrors.kernel.org ([147.75.80.249]) by linuxtv.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <linux-media+bounces-12833-patchwork=linuxtv.org@vger.kernel.org>) id 1sGbvD-0004x9-1x for patchwork@linuxtv.org; Mon, 10 Jun 2024 10:06:40 +0000 Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 8EB471F26B2F for <patchwork@linuxtv.org>; Mon, 10 Jun 2024 10:06:37 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3282979DDB; Mon, 10 Jun 2024 10:05:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="WunF74uw" X-Original-To: linux-media@vger.kernel.org Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8E4A678C7A for <linux-media@vger.kernel.org>; Mon, 10 Jun 2024 10:05:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718013954; cv=none; b=haehEQUfeNR5iMGRu7HhFFF3DQDJiw8DUCCISGH5mLgtO5ZpskASsgFbtJsQ8zKe9yaEhi33YF3zaSal2xhkQ4j30tqJ/u/3ebTQAtYjWI/13PF+WMHbCB54U4zkeSv7jAveiSk2swyqRMDx1c9kKvzgFp29cC2fa5xa+EtW3ac= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718013954; c=relaxed/simple; bh=TKR1odmfIubdY4xEWjZh17liN+dbJy2GC6GvZT/yQT8=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=He5xdgHQozPWyTgPPVb3P0c2oIi7rh/MhoSZGW23lLd2ztNd3gM1BkZkx6nD2yZkIMNDlKHmEt029sCLpunfRxFAwRcQVA8L+4wgCi7FJJpLNrplDeQNdUGsqTIJBS61U1Nqi6rUcWm7n2n66/NFPq9BR1psSwDIz6tVrP77hdE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=WunF74uw; arc=none smtp.client-ip=198.175.65.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1718013954; x=1749549954; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=TKR1odmfIubdY4xEWjZh17liN+dbJy2GC6GvZT/yQT8=; b=WunF74uw2WMLAaDzEOvEDxWp4goMgPdzzSA9LH045QSfH3e1PSe6iW/J Vm54OkxEeO8xq7ZaEmjRpdthfvF0YNirXE25t8B6I+HaMbO/qf1BUwYOo yJpb7mukLogQmPJJEMaz06FwoFpJKs236NXkzlS8zma6pWK2NJM8JPBji DqHV+FpjJRZA8Mq+g2kc/EmAgXdUfCDAEnr2hgXCiL6//ARP/qvdQJd4x iUu2PqAup6WDBFKN+W1I/Sz6aXW4jlI7w6Pnta59gen8TxDG/X97I3j4l P9TYLFQPguBwgu96ABDXIduDjPEM7y1c/L6kJcLK3y4S0hQpBwyhYZR+m w==; X-CSE-ConnectionGUID: YhFDgSt9S4u7ga2pY+o9cw== X-CSE-MsgGUID: Kzsm06BHTxiU04fNQt2baw== X-IronPort-AV: E=McAfee;i="6600,9927,11098"; a="14819916" X-IronPort-AV: E=Sophos;i="6.08,227,1712646000"; d="scan'208";a="14819916" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jun 2024 03:05:50 -0700 X-CSE-ConnectionGUID: edNiaai9TFqlQ89EdfDuXQ== X-CSE-MsgGUID: 57ecsFn3QW2/jQ4x8hYKgw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,227,1712646000"; d="scan'208";a="39137345" Received: from turnipsi.fi.intel.com (HELO kekkonen.fi.intel.com) ([10.237.72.44]) by fmviesa009-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jun 2024 03:05:47 -0700 Received: from punajuuri.localdomain (punajuuri.localdomain [192.168.240.130]) by kekkonen.fi.intel.com (Postfix) with ESMTP id 0D59B120AD4; Mon, 10 Jun 2024 13:05:41 +0300 (EEST) Received: from sailus by punajuuri.localdomain with local (Exim 4.96) (envelope-from <sakari.ailus@linux.intel.com>) id 1sGbuH-004eD7-05; Mon, 10 Jun 2024 13:05:41 +0300 From: Sakari Ailus <sakari.ailus@linux.intel.com> To: linux-media@vger.kernel.org Cc: laurent.pinchart@ideasonboard.com, hverkuil@xs4all.nl Subject: [PATCH v4 10/26] media: mc: Clear minor number reservation at unregistration time Date: Mon, 10 Jun 2024 13:05:14 +0300 Message-Id: <20240610100530.1107771-11-sakari.ailus@linux.intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240610100530.1107771-1-sakari.ailus@linux.intel.com> References: <20240610100530.1107771-1-sakari.ailus@linux.intel.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: <linux-media.vger.kernel.org> List-Subscribe: <mailto:linux-media+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-media+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-LSpam-Score: -3.5 (---) X-LSpam-Report: No, score=-3.5 required=5.0 tests=ARC_SIGNED=0.001,ARC_VALID=-0.1,BAYES_00=-1.9,DKIMWL_WL_HIGH=-1,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DMARC_PASS=-0.001,HEADER_FROM_DIFFERENT_DOMAINS=0.5,MAILING_LIST_MULTI=-1,SPF_HELO_NONE=0.001,SPF_PASS=-0.001 autolearn=ham autolearn_force=no |
Series |
Media device lifetime management
|
|
Commit Message
Sakari Ailus
June 10, 2024, 10:05 a.m. UTC
Clear the media device's minor number reservation at unregister time as
there's no need to keep it reserved for longer. This makes it possible to
reserve the same minor right after unregistration.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
---
drivers/media/mc/mc-devnode.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
Comments
On 10/06/2024 12:05, Sakari Ailus wrote: > Clear the media device's minor number reservation at unregister time as > there's no need to keep it reserved for longer. This makes it possible to > reserve the same minor right after unregistration. Have you tested this? I'm not certain whether this won't cause kobject errors. If an app has the media device open when the device is unbound, then the old device node still is around until the application closes the fh. I'm not sure if you can create a new device node with the same minor while an old device node with the same minor is still around. V4L2 and CEC definitely both keep the old minor until the last user has gone. Regards, Hans > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> > --- > drivers/media/mc/mc-devnode.c | 11 ++++------- > 1 file changed, 4 insertions(+), 7 deletions(-) > > diff --git a/drivers/media/mc/mc-devnode.c b/drivers/media/mc/mc-devnode.c > index 38c472498f9e..f7ecabe469a4 100644 > --- a/drivers/media/mc/mc-devnode.c > +++ b/drivers/media/mc/mc-devnode.c > @@ -49,13 +49,6 @@ static void media_devnode_release(struct device *cd) > { > struct media_devnode *devnode = to_media_devnode(cd); > > - mutex_lock(&media_devnode_lock); > - > - /* Mark device node number as free */ > - clear_bit(devnode->minor, media_devnode_nums); > - > - mutex_unlock(&media_devnode_lock); > - > /* Release media_devnode and perform other cleanups as needed. */ > if (devnode->release) > devnode->release(devnode); > @@ -268,6 +261,10 @@ void media_devnode_unregister(struct media_devnode *devnode) > > cdev_del(&devnode->cdev); > device_unregister(&devnode->dev); > + > + mutex_lock(&media_devnode_lock); > + clear_bit(devnode->minor, media_devnode_nums); > + mutex_unlock(&media_devnode_lock); > } > > /*
Hi Hans, On Thu, Jun 27, 2024 at 08:43:47AM +0200, Hans Verkuil wrote: > On 10/06/2024 12:05, Sakari Ailus wrote: > > Clear the media device's minor number reservation at unregister time as > > there's no need to keep it reserved for longer. This makes it possible to > > reserve the same minor right after unregistration. > > Have you tested this? By unbinding and re-binding a device while file handles to the old Media device one are still around. > > I'm not certain whether this won't cause kobject errors. If an app has the > media device open when the device is unbound, then the old device node still > is around until the application closes the fh. I'm not sure if you can create > a new device node with the same minor while an old device node with the same > minor is still around. I added the patch based on Laurent's comments <URL:https://lore.kernel.org/linux-media/20240207100810.GG23702@pendragon.ideasonboard.com/>. > > V4L2 and CEC definitely both keep the old minor until the last user has gone.
On Thu, Jun 27, 2024 at 06:58:03AM +0000, Sakari Ailus wrote: > Hi Hans, > > On Thu, Jun 27, 2024 at 08:43:47AM +0200, Hans Verkuil wrote: > > On 10/06/2024 12:05, Sakari Ailus wrote: > > > Clear the media device's minor number reservation at unregister time as > > > there's no need to keep it reserved for longer. This makes it possible to > > > reserve the same minor right after unregistration. > > > > Have you tested this? > > By unbinding and re-binding a device while file handles to the old Media > device one are still around. Also in MC we don't have an array indexed by minor numbers of Media devices, as we have for V4L2 device nodes. How is it for CEC?
On 27/06/2024 09:10, Sakari Ailus wrote: > On Thu, Jun 27, 2024 at 06:58:03AM +0000, Sakari Ailus wrote: >> Hi Hans, >> >> On Thu, Jun 27, 2024 at 08:43:47AM +0200, Hans Verkuil wrote: >>> On 10/06/2024 12:05, Sakari Ailus wrote: >>>> Clear the media device's minor number reservation at unregister time as >>>> there's no need to keep it reserved for longer. This makes it possible to >>>> reserve the same minor right after unregistration. >>> >>> Have you tested this? >> >> By unbinding and re-binding a device while file handles to the old Media >> device one are still around. > > Also in MC we don't have an array indexed by minor numbers of Media > devices, as we have for V4L2 device nodes. > > How is it for CEC? > It doesn't have such an array either. I think that's V4L2 specific, and I wonder if it is really needed. That code is very old, so it wouldn't surprise me if it can be removed. Regards, Hans
diff --git a/drivers/media/mc/mc-devnode.c b/drivers/media/mc/mc-devnode.c index 38c472498f9e..f7ecabe469a4 100644 --- a/drivers/media/mc/mc-devnode.c +++ b/drivers/media/mc/mc-devnode.c @@ -49,13 +49,6 @@ static void media_devnode_release(struct device *cd) { struct media_devnode *devnode = to_media_devnode(cd); - mutex_lock(&media_devnode_lock); - - /* Mark device node number as free */ - clear_bit(devnode->minor, media_devnode_nums); - - mutex_unlock(&media_devnode_lock); - /* Release media_devnode and perform other cleanups as needed. */ if (devnode->release) devnode->release(devnode); @@ -268,6 +261,10 @@ void media_devnode_unregister(struct media_devnode *devnode) cdev_del(&devnode->cdev); device_unregister(&devnode->dev); + + mutex_lock(&media_devnode_lock); + clear_bit(devnode->minor, media_devnode_nums); + mutex_unlock(&media_devnode_lock); } /*