lkml.org 
[lkml]   [2017]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Possible bug in cypress_m8.ko
From
Date
Am Dienstag, den 22.08.2017, 15:11 +0300 schrieb Anton Volkov:
> Hello.
>
> Judging by the code of cypress_m8.c some functions are considered to be
> capable of working concurrently with other functions, e.g. cypress_open.
> There are, however, entities that are protected by the locks at one
> place and not protected in another. Lines are given using the info from
> Linux kernel v4.12. Example:
>
> cypress_send
> spin_lock_irqsave
> priv->write_urb_in_use = 1;
> spin_lock_irqrestore
> (cypress_m8.c: lines 761-763)
> ...
> if (result) {
> priv->write_urb_in_use = 0; //without lock protection
> (cypress_m8.c: line 783)
> }
>
> Is it a bug?

Yes, but not of the kind you describe.
The transition from "not in use" to "in use" must be guarded by
a lock, because it may be contended.
But if that transition is properly guarded, you already know
that there can be only user. He can theoretically give up
the resource without locking.

Yet there is a bug:

^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 702) spin_lock_irqsave(&priv->lock, flags);
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 703) if (priv->write_urb_in_use) {
441b62c1edb98 (Harvey Harrison 2008-03-03 16:08:34 -0800 704) dbg("%s - can't write, urb in use", __func__);
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 705) spin_unlock_irqrestore(&priv->lock, flags);
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 706) return;
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 707) }
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 708) spin_unlock_irqrestore(&priv->lock, flags);

The flag is checked is checked under a lock. But then the lock is dropped.
And here:

^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 759) spin_lock_irqsave(&priv->lock, flags);
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 760) priv->write_urb_in_use = 1;
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 761) spin_unlock_irqrestore(&priv->lock, flags);

The flag is set under lock, but unconditionally.
The code just makes no sense.


In addition, when you drop the flag without a lock you need to worry
about memory ordering.

HTH
Oliver

\
 
 \ /
  Last update: 2017-08-22 16:22    [W:0.040 / U:7.804 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site