From patchwork Tue Jul 5 00:55:01 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Devin Heitmueller X-Patchwork-Id: 943172 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by demeter2.kernel.org (8.14.4/8.14.4) with ESMTP id p650tFhd030439 for ; Tue, 5 Jul 2011 00:55:15 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751465Ab1GEAzE (ORCPT ); Mon, 4 Jul 2011 20:55:04 -0400 Received: from mail-ew0-f46.google.com ([209.85.215.46]:33595 "EHLO mail-ew0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750949Ab1GEAzD (ORCPT ); Mon, 4 Jul 2011 20:55:03 -0400 Received: by ewy4 with SMTP id 4so1879061ewy.19 for ; Mon, 04 Jul 2011 17:55:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.3.76 with SMTP id 12mr527446ebm.137.1309827301765; Mon, 04 Jul 2011 17:55:01 -0700 (PDT) Received: by 10.213.9.204 with HTTP; Mon, 4 Jul 2011 17:55:01 -0700 (PDT) Date: Mon, 4 Jul 2011 20:55:01 -0400 Message-ID: Subject: [PATCH] dvb_frontend: fix race condition in stopping/starting frontend From: Devin Heitmueller To: Linux Media Mailing List Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter2.kernel.org [140.211.167.43]); Tue, 05 Jul 2011 00:55:15 +0000 (UTC) Attached is a patch which addresses a race condition in the DVB core related to closing/reopening the DVB frontend device in quick succession. This is the reason that devices such as the HVR-1300, HVR-3000, and HVR-4000 have been failing to scan properly under MythTV and w_scan. The gory details of the race are described in the patch. Devin dvb_frontend: fix race condition in stopping/starting frontend From: Devin Heitmueller There is a race condition exhibited when channel scanners such as w_scan and MythTV quickly close and then reopen the frontend device node. Under normal conditions, the behavior is as follows: 1. Application closes the device node 2. DVB frontend ioctl calls dvb_frontend_release which sets fepriv->release_jiffies 3. DVB frontend thread *eventually* calls dvb_frontend_is_exiting() which compares fepriv->release_jiffies, and shuts down the thread if timeout has expired 4. Thread goes away 5. Application opens frontend device 6. DVB frontend ioctl() calls ts_bus_ctrl(1) 7. DVB frontend ioctl() creates new frontend thread, which calls dvb_frontend_init(), which has demod driver init() routine setup initial register state for demod chip. 8. Tuning request is issued. The race occurs when the application in step 5 performs the new open() call before the frontend thread is shutdown. In this case the ts_bus_ctrl() call is made, which strobes the RESET pin on the demodulator, but the dvb_frontend_init() function never gets called because the frontend thread hasn't gone away yet. As a result, the initial register config for the demod is *never* setup, causing subsequent tuning requests to fail. If there is time between the close and open (enough for the dvb frontend thread to be torn down), then in that case the new frontend thread is created and thus the dvb_frontend_init() function does get called. The fix is to set the flag which forces reinitialization if we did in fact call ts_bus_ctrl(). This problem has been seen on the HVR-1300, HVR-3000, and HVR-4000, and is likely occuring on other designs as well where ts_bus_ctrl() actually strobes the reset pin on the demodulator. Note that this patch should supercede any patches submitted for the 1300/3000/4000 which remove the code that removes GPIO code in cx8802_dvb_advise_acquire(), which have been circulating by users for some time now... Canonical tracking this issue in Launchpad 439163: https://bugs.launchpad.net/mythtv/+bug/439163 Thanks to Jon Sayers from Hauppauge and Florent Audebert from Anevia S.A. for providing hardware to test/debug with. Signed-off-by: Devin Heitmueller Cc: Jon Sayers Cc: Florent Audebert diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c index bed7bfe..efe9c30 100644 --- a/drivers/media/dvb/dvb-core/dvb_frontend.c +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c @@ -1989,6 +1989,14 @@ static int dvb_frontend_open(struct inode *inode, struct file *file) if (dvbdev->users == -1 && fe->ops.ts_bus_ctrl) { if ((ret = fe->ops.ts_bus_ctrl(fe, 1)) < 0) goto err0; + + /* If we took control of the bus, we need to force + reinitialization. This is because many ts_bus_ctrl() + functions strobe the RESET pin on the demod, and if the + frontend thread already exists then the dvb_init() routine + won't get called (which is what usually does initial + register configuration). */ + fepriv->reinitialise = 1; } if ((ret = dvb_generic_open (inode, file)) < 0)