linux-watchdog.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Mark Balantzyan <mbalant3@gmail.com>
Cc: Pavel Andrianov <andrianov@ispras.ru>,
	wim@linux-watchdog.org, linux-kernel@vger.kernel.org,
	linux-watchdog@vger.kernel.org
Subject: Re: [PATCH] watchdog:alim1535_wdt: Fix data race in ali_settimer() concerning ali_timeout_bits variable.
Date: Mon, 22 Jul 2019 09:38:55 -0700	[thread overview]
Message-ID: <20190722163855.GC8122@roeck-us.net> (raw)
In-Reply-To: <CACV1r+a4bz+5L_AkYJ0NXkhwarx30=W3MQ20ur1A4Z-zEOE=FA@mail.gmail.com>

On Mon, Jul 22, 2019 at 07:35:03AM -0700, Mark Balantzyan wrote:
> Hello all,
> 
> I had previously submitted 2 patches attempting to fix the data race
> condition in alim1535_wdt.c as part of my work with individuals on the
> Linux Driver Verification project. I am including the original patch
> description I provided, below, along with revised patch. Thank you.
> 
> (PATCH DESCRIPTION AND PATCH BELOW)
> 
This is not how the description is supposed to look like; the above would
end up in the commit log. Please check the kernel documentation on how
to write subject lines and patch descriptions.

> In drivers/watchdog/ailm1535_wdt.c, there is the potential for a data race
> due to parallel call stacks as follows: Thread 1 calls a file operation
> callback, denoted *ali_fops* in the .c file, which in turn results in calls
> to ali_write() followed by ali_start(), which has the line
> 
> val |= (1 << 25) | ali_timeout_bits;
> 
> surrounded by a spin_lock and spin_unlock. This is crucial because Thread 2

The "surrounded by spinlock" does not refer to the line above, but to
pci_read_config_dword() followed by pci_write_config_dword(), which
needs to be protected. The described race condition around ali_timeout_bits
[ali_start() vs. ali_settimer()] does not exist.

The only race condition in the driver is 'ali_timeout_bits' vs. 'timeout'.
It is theoretically possible that those two get out of sync, ie that
ali_timeout_bits does not reflect the value of timeout. This can happen
if one of the threads is interrupted after setting 'ali_timeout_bits' but
before updating 'timeout'.

> can access "ali_timeout_bits" then when it calls ali_ioctl(), which calls
> ali_settimer() having the lines (else if (t < 60) ali_timeout_bits = t|(1
>  << 6);, lines 112-113, etc.)
> 
There is no need to be that detailed. It is sufficient to explain that
there is a race condition when updating 'ali_timeout_bits' and 'timeout'
(or maybe use my explanation above).

> (Revised) patch adds spinlocking around "ali_timeout_bits" in
> ali_settimer() should "ali_ioctl()" be called in a concurrent thread (at
> any time).
> ---
>  drivers/watchdog/alim1535_wdt.c | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/watchdog/alim1535_wdt.c
> b/drivers/watchdog/alim1535_wdt.c
> index 60f0c2e..1260e9e 100644
> --- a/drivers/watchdog/alim1535_wdt.c
> +++ b/drivers/watchdog/alim1535_wdt.c
> @@ -106,19 +106,23 @@ static void ali_keepalive(void)
>   */
> 
>  static int ali_settimer(int t)
> -{
> - if (t < 0)
> +{ spin_lock(&ali_lock);
> + if (t < 0) {
> + spin_unlock(&ali_unlock);
>   return -EINVAL;
> + }
>   else if (t < 60)
>   ali_timeout_bits = t|(1 << 6);
>   else if (t < 3600)
>   ali_timeout_bits = (t / 60)|(1 << 7);
>   else if (t < 18000)
>   ali_timeout_bits = (t / 300)|(1 << 6)|(1 << 7);
> - else
> + else {
> + spin_unlock(&ali_lock);
>   return -EINVAL;

Please use goto for error exits, as suggested in the coding style document.

> -
> + }
>   timeout = t;
> + spin_unlock(&ali_lock);
>   return 0;
>  }

Formatting is completely messed up.

> 
> -- 
> 2.15.1
> Signed-off-by: Mark Balantzyan <mbalant3@gmail.com>

Wrong location for Signed-off-by:.

Guenter

       reply	other threads:[~2019-07-22 16:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CACV1r+a4bz+5L_AkYJ0NXkhwarx30=W3MQ20ur1A4Z-zEOE=FA@mail.gmail.com>
2019-07-22 16:38 ` Guenter Roeck [this message]
2019-07-18 15:52 [PATCH] watchdog:alim1535_wdt: Fix data race in ali_settimer() concerning ali_timeout_bits variable. variable Mark Balantzyan
2019-07-18 16:34 ` Guenter Roeck
2019-07-31 16:17   ` [PATCH] watchdog:alim1535_wdt: Fix data race in ali_settimer() concerning ali_timeout_bits variable Mark Balantzyan
2019-07-31 16:43     ` Guenter Roeck
2019-07-31 17:04       ` Mark Balantzyan
2019-07-31 18:23       ` Mark Balantzyan
2019-07-31 19:24         ` Guenter Roeck
2019-07-31 23:37           ` Mark Balantzyan

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=20190722163855.GC8122@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=andrianov@ispras.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=mbalant3@gmail.com \
    --cc=wim@linux-watchdog.org \
    /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;
as well as URLs for NNTP newsgroup(s).