From patchwork Sun Oct 29 15:43:22 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Scheller X-Patchwork-Id: 10031557 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id B5B3B60249 for ; Sun, 29 Oct 2017 15:43:31 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8CC8B285BE for ; Sun, 29 Oct 2017 15:43:31 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6D446286C7; Sun, 29 Oct 2017 15:43:31 +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=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 065B5285BE for ; Sun, 29 Oct 2017 15:43:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751385AbdJ2Pn0 (ORCPT ); Sun, 29 Oct 2017 11:43:26 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:46588 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750916AbdJ2Pn0 (ORCPT ); Sun, 29 Oct 2017 11:43:26 -0400 Received: by mail-wm0-f67.google.com with SMTP id m72so11270970wmc.1 for ; Sun, 29 Oct 2017 08:43:25 -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=HJkfYE6JE9NbaXYSgk1A8ZAOe8fOSHHk3bl3Sf+bmOA=; b=AUeai6N/qsOkW4xAWcG4HySzX0/XLU6fpyreom5nVodQyihHffRl8i/j4yhCOjTvQz wjLmmpVFWZslhygX6ZYqu3amrrdmNPI7T5QItWqljtuYOu3lMs1p8etcRuMaMEd2ODSa ksS9TwH+2ETNH4NHu1QsEBoWzvxHzega+Inx1qZwE0e7e8exFrirscZBiurWhyCrpAv9 v5UuZbYbvrC6jqoQ0oVDLa24kzrtR66yn6f2KyupImvJ1FrAkKPrW32vNO4IbHnxN8o4 r7uTGWDmSP2+DYmdSGtxqLfyfU4qo7GZVvae4xFtgrprMGoK2favIiUKrDPbToNKPSqN 5JLQ== 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=HJkfYE6JE9NbaXYSgk1A8ZAOe8fOSHHk3bl3Sf+bmOA=; b=AWlG1hSotQCo/bMW9tCepdlzmgpvOZocD0Mim4sAyYZF1PDPkgCp41qyov/uclwYga 1bjEgumdoStbSKDmpMESOcwhOhZDDecnp+X9jLx6xhG5/kbYG7zOfgvKV8d6ljau1tkw 2FTLzARbxnNpf33Dg9z29coMGXsMxZvrBsgOwI0gTFGinjdAl6Y74HxwK1mC4+71Dhk6 ZJCiL7r1lY40ZB5CUGtudfDqyZpw8gCGgH/IU3qudVeRqRyJHFAYrumw8cVUvtQz+ayl GVb+nmSN+vCC9gptCAbyPzCZWmpf7AypH6j6WQlo2ZZA/bOpM+E/oQAUL1pwHVd0iwGz QhMw== X-Gm-Message-State: AMCzsaUsN9uIFr0UT6CzdZxrrnwRk5Ind0FTU7EDq+J+p5EDKmh/jvk0 oLTAqCF5tD3MHv8eOx1H9Q5BXg== X-Google-Smtp-Source: ABhQp+Qr2K8r2SIzA8c4DF+7rlwSD0Jw/irMbSV8SxvPmV1EuDDxgEw0AaoAPczInzk8gJILAovfFw== X-Received: by 10.28.13.135 with SMTP id 129mr1739064wmn.24.1509291804652; Sun, 29 Oct 2017 08:43:24 -0700 (PDT) Received: from dvbdev.wuest.de (ip-37-201-239-211.hsi13.unitymediagroup.de. [37.201.239.211]) by smtp.gmail.com with ESMTPSA id m8sm10628610wrg.55.2017.10.29.08.43.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 29 Oct 2017 08:43:23 -0700 (PDT) From: Daniel Scheller To: linux-media@vger.kernel.org Cc: mchehab@kernel.org, mchehab@s-opensource.com, laurent.pinchart@ideasonboard.com Subject: [PATCH] [media] dvb-core: always call invoke_release() in fe_free() Date: Sun, 29 Oct 2017 16:43:22 +0100 Message-Id: <20171029154322.9983-1-d.scheller.oss@gmail.com> X-Mailer: git-send-email 2.13.6 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: Daniel Scheller Follow-up to: ead666000a5f ("media: dvb_frontend: only use kref after initialized") The aforementioned commit fixed refcount OOPSes when demod driver attaching succeeded but tuner driver didn't. However, the use count of the attached demod drivers don't go back to zero and thus couldn't be cleanly unloaded. Improve on this by calling dvb_frontend_invoke_release() in __dvb_frontend_free() regardless of fepriv being NULL, instead of returning when fepriv is NULL. This is safe to do since _invoke_release() will check for passed pointers being valid before calling the .release() function. Signed-off-by: Daniel Scheller --- I discovered, checked and tested this with ddbridge, which, in ddbridge-core.c:dvb_input_attach(), follows this common logic: * attach demod * if demod ok, attach tuner * if tuner attach ok, proceed with dvb_reg_fe() * else (tuner attach NOK): dvb_fe_detach(demod) Without ead666000a5f, this caused refcount OOPSes when - at the latest - unloading the kernel modules. This doesn't happen any more, yet the loaded drivers still have a >0 use count. At first I tested calling dvb_register_device() directly followed by dvb_unregister_device() on the failure case, which worked but obviously isn't what is wanted. With this patch, all refs are finally freed, drivers have a zero use count on failure and can be unloaded cleanly. Since dvb_frontend_invoke_release() checks the passed pointers before calling them, I believe this is a safe thing to do. drivers/media/dvb-core/dvb_frontend.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/media/dvb-core/dvb_frontend.c b/drivers/media/dvb-core/dvb_frontend.c index daaf969719e4..bda1eac8f4c0 100644 --- a/drivers/media/dvb-core/dvb_frontend.c +++ b/drivers/media/dvb-core/dvb_frontend.c @@ -145,15 +145,15 @@ static void __dvb_frontend_free(struct dvb_frontend *fe) { struct dvb_frontend_private *fepriv = fe->frontend_priv; - if (!fepriv) - return; - - dvb_free_device(fepriv->dvbdev); + if (fepriv) + dvb_free_device(fepriv->dvbdev); dvb_frontend_invoke_release(fe, fe->ops.release); - kfree(fepriv); - fe->frontend_priv = NULL; + if (fepriv) { + kfree(fepriv); + fe->frontend_priv = NULL; + } } static void dvb_frontend_free(struct kref *ref)