On Tue, 2005-03-22 at 23:22 -0500, Jeff Garzik wrote: > volatile is almost always (a) buggy, or (b) hiding bugs. At the very > least, barriers are usually needed.
The choice is either barrier or volatile usually. volatile is nasty primarily because it causes compiler pessimism in variable reloading. > Almost every case really wants to be inside a spinlock, or atomic_t, or > similarly protected. I know that's what I'm asking if an audit has been conducted for...to replace the volatile, accesses have to be barrier 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, that's a valid assumption ... and by the single threaded nature of the error handler, always true. However, the proposed patch wanted to add a spinlock around the access in the scsi eh thread (the comment stating for clarity). Thus, the same change should be made in SATA for consistency. Since that change isn't in the patch, I was asking if all the users of these variables had been audited for barriers instead ... since the answer looks to be "no" to me. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
