public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Johannes Erdfelt <johannes@erdfelt.com>
To: "David C. Hansen" <haveblue@us.ibm.com>
Cc: Peter.Pregler@risc.uni-linz.ac.at, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] broken locking in CPiA driver
Date: Mon, 10 Sep 2001 20:16:28 -0400	[thread overview]
Message-ID: <20010910201628.D32532@sventech.com> (raw)
In-Reply-To: <3B9D477F.CABAFD79@us.ibm.com>
In-Reply-To: <3B9D477F.CABAFD79@us.ibm.com>; from haveblue@us.ibm.com on Mon, Sep 10, 2001 at 04:06:39PM -0700

On Mon, Sep 10, 2001, David C. Hansen <haveblue@us.ibm.com> wrote:
> This patch fixes a locking issue with the CPiA driver, and cleans up the
> locking.  There is a potential race condition in cpia_pp_detach().  The
> REMOVE_FROM_LIST macro uses the BKL to provide protection for the
> cam_list.  However, the BKL is not held during the whole for loop, only
> during the macro.  
>  
> This patch does several things:
> 1.  rename REMOVE_FROM_LIST and ADD_TO_LIST to cpia_remove_from_list and
> cpia_add_to_list, respectively
> 2. make them "static inline" functions instead of #define macros. (take
> a look at this, they probably should be functions)
> 3.  add one static spinlock cam_list_lock_{pp|usb} for each of the pp
> and usb drivers to replace BKL
> 4.  do locking around all cam_list references to replace BKL locking
> from the macros
> 5.  fix race condition
> 6.  initialize cam_list to NULL in pp driver, just like the usb driver.

Technically this isn't a problem with USB since all connects and
disconnects are serialized, but it's probably worth the effort to
maintain consistency.

One lock for both PP and USB is probably sufficient.

They should also probably use the generic list.h routines.

JE


      reply	other threads:[~2001-09-11  0:16 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-10 23:06 [PATCH] broken locking in CPiA driver David C. Hansen
2001-09-11  0:16 ` Johannes Erdfelt [this message]

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=20010910201628.D32532@sventech.com \
    --to=johannes@erdfelt.com \
    --cc=Peter.Pregler@risc.uni-linz.ac.at \
    --cc=haveblue@us.ibm.com \
    --cc=linux-kernel@vger.kernel.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