public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Damien Riegel <damien.riegel@savoirfairelinux.com>,
	linux-watchdog@vger.kernel.org, Wim Van Sebroeck <wim@iguana.be>,
	Pratyush Anand <panand@redhat.com>,
	Hans de Goede <hdegoede@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/5] watchdog: Separate and maintain variables based on variable lifetime
Date: Tue, 22 Dec 2015 08:22:40 -0800	[thread overview]
Message-ID: <567978D0.2060801@roeck-us.net> (raw)
In-Reply-To: <20151222160907.GC6164@localhost>

On 12/22/2015 08:09 AM, Damien Riegel wrote:
> On Mon, Dec 21, 2015 at 05:10:58PM -0800, Guenter Roeck wrote:
>> On 12/21/2015 09:28 AM, Damien Riegel wrote:
>>> On Sun, Dec 20, 2015 at 01:05:00PM -0800, Guenter Roeck wrote:
>>>> All variables required by the watchdog core to manage a watchdog are
>>>> currently stored in struct watchdog_device. The lifetime of those
>>>> variables is determined by the watchdog driver. However, the lifetime
>>>> of variables used by the watchdog core differs from the lifetime of
>>>> struct watchdog_device. To remedy this situation, watchdog drivers
>>>> can implement ref and unref callbacks, to be used by the watchdog
>>>> core to lock struct watchdog_device in memory.
>>>>
>>>> While this solves the immediate problem, it depends on watchdog drivers
>>>> to actually implement the ref/unref callbacks. This is error prone,
>>>> often not implemented in the first place, or not implemented correctly.
>>>>
>>>> To solve the problem without requiring driver support, split the variables
>>>> in struct watchdog_device into two data structures - one for variables
>>>> associated with the watchdog driver, one for variables associated with
>>>> the watchdog core. With this approach, the watchdog core can keep track
>>>> of its variable lifetime and no longer depends on ref/unref callbacks
>>>> in the driver. As a side effect, some of the variables originally in
>>>> struct watchdog_driver are now private to the watchdog core and no longer
>>>> visible in watchdog drivers.
>>>>
>>>> The 'ref' and 'unref' callbacks in struct watchdog_driver are no longer
>>>> used and marked as deprecated.
>>>
>>> Two comments below. It's great to see that unbinding a driver no longer
>>> triggers a kernel panic.
>>>
>> It should not have caused a panic to start with, but the ref/unref functions
>> for the most part were either not or wrongly implemented. Not really
>> surprising - it took me a while to understand the problem.
>
> I tested on a driver which did not implement ref/unref. When ping is
> called, it tries to dereference a freed 'struct watchdog_device' in
> watchdog_get_drvdata, leading to a panic.
>
Yes, that will happen. Problem here is that the driver is buggy -
pretty much all drivers which dynamically allocate struct watchdog_device
have this problem.

This is the ultimate reason for coming up with this patch.

>>
>> [ ... ]
>>
>>>>
>>>>   /*
>>>> + * struct _watchdog_device - watchdog core internal data
>>>
>>> Think it should be /**. Anyway, I find it confusing to have both
>>> _watchdog_device and watchdog_device, but I can't think of a better
>>> name right now.
>>
>> I renamed the data structure to watchdog_data and moved it into watchdog_dev.c
>> since it is only used there. No '**', though, because it is not a published
>> API, but just an internal data structure.
>>
>> I also renamed the matching variable name to 'wd_data' (from '_wdd').
>
> Okay. Also, why didn't you use the explicit type for 'wdd_data' in
> 'struct watchdog_device' instead of a void*?
>

This is to hide the data type, since the structure is not exported
to drivers.

I could pre-declare the structure with 'struct watchdog_data;', but
then I'd have to use a different structure name (watchdog_cdev_data,
maybe, or watchdog_core_data) to make it less generic. Any opinion ?
Would that be better / preferred ? I am 50/50 about it.

Thanks,
Guenter


  reply	other threads:[~2015-12-22 16:22 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-20 21:04 [PATCH 0/5] watchdog: Replace driver based refcounting Guenter Roeck
2015-12-20 21:04 ` [PATCH 1/5] watchdog: Create watchdog device in watchdog_dev.c Guenter Roeck
2015-12-21 17:31   ` Damien Riegel
2015-12-21 23:28     ` Guenter Roeck
2015-12-22 15:33       ` Damien Riegel
2015-12-22 16:15         ` Guenter Roeck
2015-12-20 21:05 ` [PATCH 2/5] watchdog: Separate and maintain variables based on variable lifetime Guenter Roeck
2015-12-21 17:28   ` Damien Riegel
2015-12-21 23:36     ` Tomas Winkler
2015-12-22  1:40       ` Guenter Roeck
     [not found]         ` <CA+i0qc6O9BJaJd-RrZhoTRUkkCohTjZxVccS=NC6JEUKYwvGPQ@mail.gmail.com>
2015-12-23  0:32           ` Guenter Roeck
2015-12-22  1:10     ` Guenter Roeck
2015-12-22 16:09       ` Damien Riegel
2015-12-22 16:22         ` Guenter Roeck [this message]
2015-12-22 19:28           ` Damien Riegel
2015-12-22 19:34             ` Guenter Roeck
2015-12-20 21:05 ` [PATCH 3/5] watchdog: da9052_wdt: Drop reference counting Guenter Roeck
2015-12-20 21:05 ` [PATCH 4/5] watchdog: da9055_wdt: " Guenter Roeck
2015-12-20 21:05 ` [PATCH 5/5] hwmon: (sch56xx) Drop watchdog driver data reference count callbacks Guenter Roeck
2015-12-21 10:37   ` Hans de Goede
2015-12-21 13:21     ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=567978D0.2060801@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=damien.riegel@savoirfairelinux.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=panand@redhat.com \
    --cc=wim@iguana.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox