From patchwork Mon Aug 13 16:33:12 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Petr Cvek X-Patchwork-Id: 10564507 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 7CC7213B4 for ; Mon, 13 Aug 2018 16:32:57 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6A3F3283B2 for ; Mon, 13 Aug 2018 16:32:57 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5C61628470; Mon, 13 Aug 2018 16:32:57 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id ED56E283B2 for ; Mon, 13 Aug 2018 16:32:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729029AbeHMTPw (ORCPT ); Mon, 13 Aug 2018 15:15:52 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:38721 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728293AbeHMTPw (ORCPT ); Mon, 13 Aug 2018 15:15:52 -0400 Received: by mail-wr1-f68.google.com with SMTP id v14-v6so14810597wro.5 for ; Mon, 13 Aug 2018 09:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=ilNXzDDb5I9UrcRXCG4QLSZu6g3QvVAB5rVmX9MOt78=; b=LfX97oEQnZvXUFwhj128l766XBACjrOdUHkT7a+Ut6nO21wfsF88+1d6pwtIVksIHf 6gYNayA3Wn7MZJST20zElx1TdHNSatYyLcXtqU4mP+uvM9iPrIXC5RgqfVIKsr6ehmQm HUqzVdv6yAtlWutFqRTHOq1prOy0DUsbCSly6LNURpmkeUHNrKAzIVNiiS557w0WX6Lk BuWkfD6uXn2v6mtEV9EyIyoqrHZvzD9UYu8lvGXHntto4Uyi0wjq71yi7hP+gQ38Sa7V AlJ2jlkqas9YDSINZLkmpt4wNQ4YVXqEc1xlvVQlAGtcQ7kSMnez2Z/RM0NbJDVBwxv8 cLEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=ilNXzDDb5I9UrcRXCG4QLSZu6g3QvVAB5rVmX9MOt78=; b=PEpViUnwoA34FVjSzE70OQ+e4kZ/+ARG05kQK3gz7mS5jJZc+HlL0i9vl69lO6xtSr Uf61xPKB0WHHUPmBy93NaCexmk1axRMTesgWEM1+JtAHj1aH6uBSPXcpeuxvrmMQBrIt gz9W+BEK84MQ9Cc7bga2q0IHKdyIFNTwIxzbUyo2w8+wX+eQMAvPlb+VpWbPJuxGGXlU kiiWXx1lWAFeniVH17v5afCDAEjsEGwE/k4LKSD+Txx9fF0O48PauEWZDeP1itNRfBcD ShNDu0MN9P1kBwkqUepGQkVhwWSVe/3IOQS73YSnC44pugHlWWQWacmVihFBNTQcSeNK VJ7w== X-Gm-Message-State: AOUpUlGLgvaAh2Hgvi1oSbhcCgQPTtlxoSzGLgDsN+I6wfv8vm+i6x9C l4uo5jjWCL0LDHgOmMcPC3M= X-Google-Smtp-Source: AA+uWPx2R1HRQYk+S131x7M2BZU7WT26qPhD95k4mYlOTZTaRlstmhWAncLlR7JReQW60YkkvnrR6g== X-Received: by 2002:adf:b2a7:: with SMTP id g36-v6mr10869786wrd.218.1534177974879; Mon, 13 Aug 2018 09:32:54 -0700 (PDT) Received: from kontron.lan ([2001:1ae9:ff1:f191:dba:8432:e1a9:eac7]) by smtp.gmail.com with ESMTPSA id x14-v6sm20941007wrv.21.2018.08.13.09.32.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Aug 2018 09:32:54 -0700 (PDT) From: petrcvekcz@gmail.com X-Google-Original-From: petrcvekcz.gmail.com To: mchehab@kernel.org, sakari.ailus@linux.intel.com Cc: Petr Cvek , laurent.pinchart@ideasonboard.com, linux-media@vger.kernel.org Subject: [BUG, RFC] media: Wrong module gets acquired Date: Mon, 13 Aug 2018 18:33:12 +0200 Message-Id: X-Mailer: git-send-email 2.18.0 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Petr Cvek When transferring a media sensor driver from the soc_camera I've found the controller module can get removed (which will cause a stack dump because the sensor driver depends on resources from the controller driver). When I've tried to remove the driver module of the sensor it said the resource was busy (without a reference name) though is should be possible to remove the sensor driver because it is at the end of the dependency list and not to remove the controller driver. I've dig into the called functions and I've found this in drivers/media/v4l2-core/v4l2-device.c: /* * The reason to acquire the module here is to avoid unloading * a module of sub-device which is registered to a media * device. To make it possible to unload modules for media * devices that also register sub-devices, do not * try_module_get() such sub-device owners. */ sd->owner_v4l2_dev = v4l2_dev->dev && v4l2_dev->dev->driver && sd->owner == v4l2_dev->dev->driver->owner; if (!sd->owner_v4l2_dev && !try_module_get(sd->owner)) return -ENODEV; It basicaly checks if subdevice (=sensor) is a same module as the media device (=controller) and if they are different it acquires the module. The acquired module is the one in sd->owner, which is the same module from which the function is called (-> sensor aquires itself). Is this functionality valid (should the subdevice really be unloadable)? When I've patched the module to aquire the controller instead the module, the removal worked as expected (sensor free to go, controller not). If this is really a bug (= there isn't a sensor which cannot be unloaded from a controller?) then I send a new patch with reworded commentary. Signed-off-by: Petr Cvek --- drivers/media/v4l2-core/v4l2-device.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-device.c b/drivers/media/v4l2-core/v4l2-device.c index 3940e55c72f1..1dec61cd560c 100644 --- a/drivers/media/v4l2-core/v4l2-device.c +++ b/drivers/media/v4l2-core/v4l2-device.c @@ -173,7 +173,8 @@ int v4l2_device_register_subdev(struct v4l2_device *v4l2_dev, sd->owner_v4l2_dev = v4l2_dev->dev && v4l2_dev->dev->driver && sd->owner == v4l2_dev->dev->driver->owner; - if (!sd->owner_v4l2_dev && !try_module_get(sd->owner)) + if (!sd->owner_v4l2_dev && + !try_module_get(v4l2_dev->dev->driver->owner)) return -ENODEV; sd->v4l2_dev = v4l2_dev; @@ -209,7 +210,7 @@ int v4l2_device_register_subdev(struct v4l2_device *v4l2_dev, #endif error_module: if (!sd->owner_v4l2_dev) - module_put(sd->owner); + module_put(v4l2_dev->dev->driver->owner); sd->v4l2_dev = NULL; return err; } @@ -318,6 +319,6 @@ void v4l2_device_unregister_subdev(struct v4l2_subdev *sd) #endif video_unregister_device(sd->devnode); if (!sd->owner_v4l2_dev) - module_put(sd->owner); + module_put(v4l2_dev->dev->driver->owner); } EXPORT_SYMBOL_GPL(v4l2_device_unregister_subdev);