mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tejun Heo <htejun@gmail.com>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: James Bottomley <James.Bottomley@SteelEye.com>,
	Jens Axboe <axboe@suse.de>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH scsi-misc-2.6 04/08] scsi: remove meaningless volatile qualifiers from structure definitions
Date: Wed, 23 Mar 2005 14:28:38 +0900	[thread overview]
Message-ID: <20050323052838.GA31878@htj.dyndns.org> (raw)
In-Reply-To: <4240EEFF.8030703@pobox.com>

 Hello, guys.

On Tue, Mar 22, 2005 at 11:22:23PM -0500, Jeff Garzik wrote:
> James Bottomley wrote:
> >On Wed, 2005-03-23 at 11:14 +0900, Tejun Heo wrote:
> >
> >>	scsi_device->device_busy, Scsi_Host->host_busy and
> >>	->host_failed have volatile qualifiers, but the qualifiers
> >>	don't serve any purpose.  Kill them.  While at it, protect
> >>	->host_failed update in scsi_error for consistency and clarity.
> >
> >
> >Well ... the data here is volatile so what you're advocating is a move
> >away from a volatile variable model to a protected variable one ... did
> >you audit all users of both of these to make sure we have protection on
> >all of them?  It looks like the sata strategy handlers would still rely
> >on the volatile data.

 Yes, I did (well, tried :-).  Adding locking/unlocking was just for
clarity.  We have synchronization w/ implied memory barrier before and
after eh processing, so we don't really need to acquire the lock
there.  And while adding it, I forgot about libata strategy function.
Sorry about that.  I removed the locking from scsi_error and added
comments to data structure definition that those fields can be
accessed without acquiring the host lock.  I think it's clearer this
way.

> volatile is almost always (a) buggy, or (b) hiding bugs.  At the very 
> least, barriers are usually needed.
> 
> Almost every case really wants to be inside a spinlock, or atomic_t, or 
> similarly protected.
> 
> Specifically for SATA, I am making the presumption that SCSI is smart 
> enough not to mess with host_failed until my error handler completes.

 Yes, volatile only instructs the compiler to not cache the variable
in the register and not move around accesses to the variable.  The
only valid usage would be raw synchronization with variables (busy
checking, two flag variable synchronization, etc...), but even those
usages are better off with explicit barriers and cpu relaxations to
clarify what's going on.

 Currently all accesses outside eh are properly protected with locks
except for the following two cases.

 * sg_proc_seq_show_dev(): read access, informational.  doesn't matter.
 * check looping in scsi_device_quiesce(): we have proper barrier.


 Signed-off-by: Tejun Heo <htejun@gmail.com>


Index: scsi-export/include/scsi/scsi_device.h
===================================================================
--- scsi-export.orig/include/scsi/scsi_device.h	2005-03-23 09:40:12.000000000 +0900
+++ scsi-export/include/scsi/scsi_device.h	2005-03-23 14:04:59.000000000 +0900
@@ -43,7 +43,8 @@ struct scsi_device {
 	struct list_head    siblings;   /* list of all devices on this host */
 	struct list_head    same_target_siblings; /* just the devices sharing same target id */
 
-	volatile unsigned short device_busy;	/* commands actually active on low-level */
+	unsigned short device_busy;	/* commands actually active on
+					 * low-level. protected by sdev_lock. */
 	spinlock_t sdev_lock;           /* also the request queue_lock */
 	spinlock_t list_lock;
 	struct list_head cmd_list;	/* queue of in use SCSI Command structures */
Index: scsi-export/include/scsi/scsi_host.h
===================================================================
--- scsi-export.orig/include/scsi/scsi_host.h	2005-03-23 09:40:12.000000000 +0900
+++ scsi-export/include/scsi/scsi_host.h	2005-03-23 14:04:59.000000000 +0900
@@ -448,8 +448,14 @@ struct Scsi_Host {
 	wait_queue_head_t       host_wait;
 	struct scsi_host_template *hostt;
 	struct scsi_transport_template *transportt;
-	volatile unsigned short host_busy;   /* commands actually active on low-level */
-	volatile unsigned short host_failed; /* commands that failed. */
+
+	/*
+	 * The following two fields are protected with host_lock;
+	 * however, eh routines can safely access during eh processing
+	 * without acquiring the lock.
+	 */
+	unsigned short host_busy;	   /* commands actually active on low-level */
+	unsigned short host_failed;	   /* commands that failed. */
     
 	unsigned short host_no;  /* Used for IOCTL_GET_IDLUN, /proc/scsi et al. */
 	int resetting; /* if set, it means that last_reset is a valid value */

  reply	other threads:[~2005-03-23  5:28 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-23  2:14 [PATCH scsi-misc-2.6 00/08] scsi: small fixes & cleanups Tejun Heo
2005-03-23  2:14 ` [PATCH scsi-misc-2.6 01/08] scsi: remove unused bounce-buffer release path Tejun Heo
2005-03-23  4:07   ` James Bottomley
2005-03-23  6:08     ` Tejun Heo
2005-03-23 15:27       ` Jens Axboe
2005-03-23  2:14 ` [PATCH scsi-misc-2.6 02/08] scsi: don't use blk_insert_request() for requeueing Tejun Heo
2005-03-23  2:14 ` [PATCH scsi-misc-2.6 03/08] scsi: remove unused scsi_cmnd->internal_timeout field Tejun Heo
2005-03-23  2:14 ` [PATCH scsi-misc-2.6 04/08] scsi: remove meaningless volatile qualifiers from structure definitions Tejun Heo
2005-03-23  4:15   ` James Bottomley
2005-03-23  4:22     ` Jeff Garzik
2005-03-23  5:28       ` Tejun Heo [this message]
2005-03-23 15:16       ` James Bottomley
2005-03-23  2:14 ` [PATCH scsi-misc-2.6 05/08] scsi: remove a timer race from scsi_queue_insert() and cleanup timer Tejun Heo
2005-03-23  2:14 ` [PATCH scsi-misc-2.6 06/08] scsi: remove meaningless scsi_cmnd->serial_number_at_timeout field Tejun Heo
2005-03-23  2:14 ` [PATCH scsi-misc-2.6 07/08] scsi: remove bogus {get|put}_device() calls Tejun Heo
2005-03-23  4:15   ` James Bottomley
2005-03-23  9:13     ` Tejun Heo
2005-03-29 17:02       ` Patrick Mansfield
2005-03-23  2:14 ` [PATCH scsi-misc-2.6 08/08] scsi: fix hot unplug sequence Tejun Heo
2005-03-23  4:08   ` James Bottomley
2005-03-23  4:50     ` Tejun Heo
2005-03-23  7:19       ` Jens Axboe
2005-03-23 15:20         ` James Bottomley
2005-03-23 15:25           ` Jens Axboe
2005-03-25  0:45             ` James Bottomley
2005-03-25  3:15               ` Tejun Heo
2005-03-25  5:02                 ` James Bottomley
2005-03-25  5:38                   ` Tejun Heo
2005-03-25 19:19                     ` James Bottomley
2005-03-25 21:43                       ` Tejun Heo
2005-03-25 22:49                         ` James Bottomley
2005-03-26  7:27                       ` Kai Makisara
2005-03-26 14:48                         ` James Bottomley
2005-03-23 15:12       ` James Bottomley

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=20050323052838.GA31878@htj.dyndns.org \
    --to=htejun@gmail.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=axboe@suse.de \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@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

all inboxes | Powered by JetHome®