From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752167AbbFZNyg (ORCPT ); Fri, 26 Jun 2015 09:54:36 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:38702 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751379AbbFZNy3 (ORCPT ); Fri, 26 Jun 2015 09:54:29 -0400 Message-ID: <558D5990.30102@roeck-us.net> Date: Fri, 26 Jun 2015 06:54:24 -0700 From: Guenter Roeck User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ian Abbott , linux-watchdog@vger.kernel.org CC: Wim Van Sebroeck , linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/5] watchdog: dw_wdt: allow only one probe + various fixes References: <1435324873-18318-1-git-send-email-abbotti@mev.co.uk> In-Reply-To: <1435324873-18318-1-git-send-email-abbotti@mev.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated_sender: linux@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: linux@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/26/2015 06:21 AM, Ian Abbott wrote: > The dw_wdt watchdog driver supports a single DesignWare watchdog device > using a statically allocated variable 'dw_wdt' to manage it, but there > are some bits of hardware containing two such devices. If the "probe" > is called for more than one device, the 'dw_wdt' variable gets > clobbered, generally resulting in a kernel crash. Change it to reject > additional probed devices. > > We probably don't expect the "remove" function to get called, but if it > does, make sure the Linux timer used by device gets unqueued. > > The timer also gets unqueued if the watchdog device is closed by the > user process unexpectedly. However, this is not currently done > asynchronously and the timer function normally requeues the timer. If > it manages to requeue the timer, the next call of the timer function > will behave as though the close was expected and continue patting the > dog every half a second when it should have stopped doing so. Unqueue > the timer synchronously to avoid that. > > NOTE: There is another potential problem that I haven't bothered to fix. > If the "remove" function is called while the watchdog device is still > open, any in-progress or future file operations are likely to screw > things up. > > 1) watchdog: dw_wdt: prepare for more atomic bits > 2) watchdog: dw_wdt: reject additional device probes > 3) watchdog: dw_wdt: only unregister restart handler if registered > 4) watchdog: dw_wdt: unqueue timer on device removal > 5) watchdog: dw_wdt: unqueue timer synchronously on unexpected close > > drivers/watchdog/dw_wdt.c | 46 +++++++++++++++++++++++++++++++++++----------- > 1 file changed, 35 insertions(+), 11 deletions(-) Hi Ian, any chance you can convert the driver to use the watchdog APIs instead ? This way it could support more than one watchdog, and the code would be much simpler. Thanks, Guenter