On Mon, 05 Feb 2007 02:42:09 +0100 Tilman Schmidt <[EMAIL PROTECTED]> wrote:
> Am 04.02.2007 02:56 schrieb Andrew Morton: > > On Sun, 04 Feb 2007 02:32:41 +0100 Tilman Schmidt <[EMAIL PROTECTED]> wrote: > > > >>>> + spin_lock_irqsave(&cs->cmdlock, flags); > >>>> + cb = cs->cmdbuf; > >>>> + spin_unlock_irqrestore(&cs->cmdlock, flags); > >>> It is doubtful if the locking here does anything useful. > >> It assures atomicity when reading the cs->cmdbuf pointer. > > > > I think it's bogus. If the quantity being copied here is more than 32-bits > > then yes, a lock is appropriate. But if it's a single word then it's > > unlikely that the locking does anything useful. Or there might be a bug > > here. > > It's a pointer. Are reads and writes of pointer sized objects > guaranteed to be atomic on every platform? Yup - we make the same assumption about longs in various places. It's a bit strange to read a pointer which can be changing at the same time. Because the local copy will no longer represent the thing which it was just copied from. - 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/
