Skip to contentSkip to conversation

I/O space write barrier

PATCH In review Jesse Barnes 4 participants 13 messages Sep 23, 2004 – Sep 27, 2004

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 I/O space write barrier

[Posting again to linux-arch at Ralf's suggestion.]

On some platforms (e.g. SGI Challenge, Origin, and Altix machines), writes to I/O space aren't ordered coming from different CPUs. For the most part, this isn't a problem since drivers generally spinlock around code that does writeX calls, but if the last operation a driver does before it releases a lock is a write and some other CPU takes the lock and immediately does a write, it's possible the second CPU's write could arrive before the first's.

This patch adds a mmiowb() call to deal with this sort of situation, and modifies the qla1280 driver to use it. The idea is to mirror the regular, cacheable memory barrier operation, wmb (arg! I misnamed it in my patch, I'll fix that up in the next rev assuming it's ok). Example:

CPU A:  spin_lock_irqsave(&dev_lock, flags)
CPU A:  ...
CPU A:  writel(newval, ring_ptr);
CPU A:  spin_unlock_irqrestore(&dev_lock, flags)
        ...
CPU B:  spin_lock_irqsave(&dev_lock, flags)
CPU B:  writel(newval2, ring_ptr);
CPU B:  ...
CPU B:  spin_unlock_irqrestore(&dev_lock, flags)

In this case, newval2 could be written to ring_ptr before newval. Fixing it is easy though:

CPU A:  spin_lock_irqsave(&dev_lock, flags)
CPU A:  ...
CPU A:  writel(newval, ring_ptr);
CPU A:  mmiowb(); /* ensure no other writes beat us to the device */
CPU A:  spin_unlock_irqrestore(&dev_lock, flags)
        ...
CPU B:  spin_lock_irqsave(&dev_lock, flags)
CPU B:  writel(newval2, ring_ptr);
CPU B:  ...
CPU B:  mmiowb();
CPU B:  spin_unlock_irqrestore(&dev_lock, flags)

Note that this doesn't address a related case where the driver may want to actually make a given write get to the device before proceeding. This should be dealt with by immediately reading a register from the card that has no side effects. According to the PCI spec, that will guarantee that all writes have arrived before being sent to the target bus. If no such register is available (in the case of card resets perhaps), reading from config space is sufficient (though it may return all ones if the card isn't responding to read cycles).

I'm also not quite sure if I got the ppc64 case right (and obviously I need to add the macro for other platforms). The assumption is that *most* platforms don't have this issue, and those that do have a chipset register or CPU instruction to ensure ordering. If that turns out not to be the case, we can add an address argument to the function.

Thanks,
Jesse

===== Documentation/DocBook/deviceiobook.tmpl 1.4 vs edited =====

Documentation/DocBook/deviceiobook.tmpl +13 -3
@@ -147,8 +147,7 @@
 	compiler is not permitted to reorder the I/O sequence. When the 
 	ordering can be compiler optimised, you can use <function>
 	__readb</function> and friends to indicate the relaxed ordering. Use 
-	this with care. The <function>rmb</function> provides a read memory 
-	barrier. The <function>wmb</function> provides a write memory barrier.
+	this with care.
       </para>
 
       <para>
@@ -163,6 +162,15 @@
       </para>
 
       <para>
+	In addition to write posting, some large SMP systems (e.g. SGI
+	Challenge, Origin and Altix machines) won't strongly order writes
+	coming from different CPUs.  Thus it's important to properly
+	protect parts of your driver that do memory-mapped writes with
+	locks and use the <function>mmiob</function> to make sure they
+	arrive in the order intended.
+      </para>
+
+      <para>
 	PCI ordering rules also guarantee that PIO read responses arrive
 	after any outstanding DMA writes on that bus, since for some devices
 	the result of a <function>readb</function> call may signal to the
@@ -171,7 +179,9 @@
 	<function>readb</function> call has no relation to any previous DMA
 	writes performed by the device.  The driver can use
 	<function>readb_relaxed</function> for these cases, although only
-	some platforms will honor the relaxed semantics.
+	some platforms will honor the relaxed semantics.  Using the relaxed
+	read functions will provide significant performance benefits on
+	platforms that support it.
       </para>
     </sect1>
 

===== arch/ia64/sn/io/machvec/iomv.c 1.9 vs edited =====

arch/ia64/sn/io/machvec/iomv.c +5 -9
@@ -54,23 +54,19 @@
 EXPORT_SYMBOL(sn_io_addr);
 
 /**
- * sn_mmiob - I/O space memory barrier
+ * __sn_mmiowb - I/O space write barrier
  *
- * Acts as a memory mapped I/O barrier for platforms that queue writes to 
- * I/O space.  This ensures that subsequent writes to I/O space arrive after
- * all previous writes.  For most ia64 platforms, this is a simple
- * 'mf.a' instruction.  For other platforms, mmiob() may have to read
- * a chipset register to ensure ordering.
+ * See include/asm-ia64/io.h and Documentation/DocBook/deviceiobook.tmpl
+ * for details.
  *
  * On SN2, we wait for the PIO_WRITE_STATUS SHub register to clear.
  * See PV 871084 for details about the WAR about zero value.
  *
  */
-void
-sn_mmiob (void)
+void __sn_mmiowb(void)
 {
 	while ((((volatile unsigned long) (*pda->pio_write_status_addr)) & SH_PIO_WRITE_STATUS_0_PENDING_WRITE_COUNT_MASK) != 
 				SH_PIO_WRITE_STATUS_0_PENDING_WRITE_COUNT_MASK)
 		cpu_relax();
 }
-EXPORT_SYMBOL(sn_mmiob);
+EXPORT_SYMBOL(__sn_mmiowb);

===== drivers/scsi/qla1280.c 1.65 vs edited =====

drivers/scsi/qla1280.c +3 -3
@@ -1715,7 +1715,7 @@
 	reg = ha->iobase;
 	/* enable risc and host interrupts */
 	WRT_REG_WORD(&reg->ictrl, (ISP_EN_INT | ISP_EN_RISC));
-	RD_REG_WORD(&reg->ictrl);	/* PCI Posted Write flush */
+	mmiowb(); /* make sure this write arrives before any others */
 	ha->flags.ints_enabled = 1;
 }
 
@@ -1727,7 +1727,7 @@
 	reg = ha->iobase;
 	/* disable risc and host interrupts */
 	WRT_REG_WORD(&reg->ictrl, 0);
-	RD_REG_WORD(&reg->ictrl);	/* PCI Posted Write flush */
+	mmiowb(); /* make sure this write arrives before any others */
 	ha->flags.ints_enabled = 0;
 }
 
@@ -3398,7 +3398,7 @@
 	sp->flags |= SRB_SENT;
 	ha->actthreads++;
 	WRT_REG_WORD(&reg->mailbox4, ha->req_ring_index);
-	(void) RD_REG_WORD(&reg->mailbox4); /* PCI posted write flush */
+	mmiowb(); /* make sure this write arrives before any others */
 
  out:
 	if (status)

===== include/asm-ia64/io.h 1.19 vs edited =====

include/asm-ia64/io.h +16 -0
@@ -91,6 +91,20 @@
  */
 #define __ia64_mf_a()	ia64_mfa()
 
+/**
+ * __ia64_mmiowb - I/O write barrier
+ *
+ * Ensure ordering of I/O space writes.  This will make sure that writes
+ * following the barrier will arrive after all previous writes.  For most
+ * ia64 platforms, this is a simple 'mf.a' instruction.
+ *
+ * See Documentation/DocBook/deviceiobook.tmpl for more information.
+ */
+static inline void __ia64_mmiowb(void)
+{
+	ia64_mfa();
+}
+
 static inline const unsigned long
 __ia64_get_io_port_base (void)
 {
@@ -267,6 +281,7 @@
 #define __outb		platform_outb
 #define __outw		platform_outw
 #define __outl		platform_outl
+#define __mmiowb	platform_mmiowb
 
 #define inb(p)		__inb(p)
 #define inw(p)		__inw(p)
@@ -280,6 +295,7 @@
 #define outsb(p,s,c)	__outsb(p,s,c)
 #define outsw(p,s,c)	__outsw(p,s,c)
 #define outsl(p,s,c)	__outsl(p,s,c)
+#define mmiowb()	__mmiowb()
 
 /*
  * The address passed to these functions are ioremap()ped already.

===== include/asm-ia64/machvec.h 1.26 vs edited =====

include/asm-ia64/machvec.h +7 -0
@@ -62,6 +62,7 @@
 typedef void ia64_mv_outb_t (unsigned char, unsigned long);
 typedef void ia64_mv_outw_t (unsigned short, unsigned long);
 typedef void ia64_mv_outl_t (unsigned int, unsigned long);
+typedef void ia64_mv_mmiowb_t (void);
 typedef unsigned char ia64_mv_readb_t (void *);
 typedef unsigned short ia64_mv_readw_t (void *);
 typedef unsigned int ia64_mv_readl_t (void *);
@@ -130,6 +131,7 @@
 #  define platform_outb		ia64_mv.outb
 #  define platform_outw		ia64_mv.outw
 #  define platform_outl		ia64_mv.outl
+#  define platform_mmiowb	ia64_mv.mmiowb
 #  define platform_readb        ia64_mv.readb
 #  define platform_readw        ia64_mv.readw
 #  define platform_readl        ia64_mv.readl
@@ -176,6 +178,7 @@
 	ia64_mv_outb_t *outb;
 	ia64_mv_outw_t *outw;
 	ia64_mv_outl_t *outl;
+	ia64_mv_mmiowb_t *mmiowb;
 	ia64_mv_readb_t *readb;
 	ia64_mv_readw_t *readw;
 	ia64_mv_readl_t *readl;
@@ -218,6 +221,7 @@
 	platform_outb,				\
 	platform_outw,				\
 	platform_outl,				\
+	platform_mmiowb,			\
 	platform_readb,				\
 	platform_readw,				\
 	platform_readl,				\
@@ -343,6 +347,9 @@
 #endif
 #ifndef platform_outl
 # define platform_outl		__ia64_outl
+#endif
+#ifndef platform_mmiowb
+# define platform_mmiowb	__ia64_mmiowb
 #endif
 #ifndef platform_readb
 # define platform_readb		__ia64_readb

===== include/asm-ia64/machvec_init.h 1.7 vs edited =====

include/asm-ia64/machvec_init.h +1 -0
@@ -12,6 +12,7 @@
 extern ia64_mv_outb_t __ia64_outb;
 extern ia64_mv_outw_t __ia64_outw;
 extern ia64_mv_outl_t __ia64_outl;
+extern ia64_mv_mmiowb_t __ia64_mmiowb;
 extern ia64_mv_readb_t __ia64_readb;
 extern ia64_mv_readw_t __ia64_readw;
 extern ia64_mv_readl_t __ia64_readl;

===== include/asm-ia64/machvec_sn2.h 1.14 vs edited =====

include/asm-ia64/machvec_sn2.h +2 -0
@@ -49,6 +49,7 @@
 extern ia64_mv_outb_t __sn_outb;
 extern ia64_mv_outw_t __sn_outw;
 extern ia64_mv_outl_t __sn_outl;
+extern ia64_mv_mmiowb_t __sn_mmiowb;
 extern ia64_mv_readb_t __sn_readb;
 extern ia64_mv_readw_t __sn_readw;
 extern ia64_mv_readl_t __sn_readl;
@@ -92,6 +93,7 @@
 #define platform_outb			__sn_outb
 #define platform_outw			__sn_outw
 #define platform_outl			__sn_outl
+#define platform_mmiowb			__sn_mmiowb
 #define platform_readb			__sn_readb
 #define platform_readw			__sn_readw
 #define platform_readl			__sn_readl

===== include/asm-ia64/sn/io.h 1.7 vs edited =====

include/asm-ia64/sn/io.h +2 -2
@@ -58,8 +58,8 @@
 #include <asm/sn/sn2/shubio.h>
 
 /*
- * Used to ensure write ordering (like mb(), but for I/O space)
+ * Used to ensure write ordering
  */
-extern void sn_mmiob(void);
+extern void __sn_mmiowb(void);
 
 #endif /* _ASM_IA64_SN_IO_H */

===== include/asm-ia64/sn/sn2/io.h 1.6 vs edited =====

include/asm-ia64/sn/sn2/io.h +7 -5
@@ -11,8 +11,10 @@
 #include <linux/compiler.h>
 #include <asm/intrinsics.h>
 
-extern void * sn_io_addr(unsigned long port) __attribute_const__; /* Forward definition */
-extern void sn_mmiob(void); /* Forward definition */
+/* Forward declarations */
+struct device;
+extern void *sn_io_addr(unsigned long port) __attribute_const__;
+extern void __sn_mmiowb(void);
 
 #define __sn_mf_a()   ia64_mfa()
 
@@ -91,7 +93,7 @@
 
 	if ((addr = sn_io_addr(port))) {
 		*addr = val;
-		sn_mmiob();
+		__sn_mmiowb();
 	}
 }
 
@@ -102,7 +104,7 @@
 
 	if ((addr = sn_io_addr(port))) {
 		*addr = val;
-		sn_mmiob();
+		__sn_mmiowb();
 	}
 }
 
@@ -113,7 +115,7 @@
 
 	if ((addr = sn_io_addr(port))) {
 		*addr = val;
-		sn_mmiob();
+		__sn_mmiowb();
 	}
 }
 

===== include/asm-mips/io.h 1.7 vs edited =====

include/asm-mips/io.h +3 -0
@@ -290,6 +290,9 @@
 #define __raw_writeb(b,addr)	((*(volatile unsigned char *)(addr)) = (b))
 #define __raw_writew(w,addr)	((*(volatile unsigned short *)(addr)) = (w))
 #define __raw_writel(l,addr)	((*(volatile unsigned int *)(addr)) = (l))
+
+#define mmiowb() asm volatile ("sync" ::: "memory")
+
 #ifdef CONFIG_MIPS32
 #define ____raw_writeq(val,addr)						\
 ({									\

===== include/asm-ppc64/io.h 1.21 vs edited =====

include/asm-ppc64/io.h +2 -0
@@ -152,6 +152,8 @@
 extern void _insl_ns(volatile u32 *port, void *buf, int nl);
 extern void _outsl_ns(volatile u32 *port, const void *buf, int nl);
 
+#define mmiowb() asm volatile ("eieio" ::: "memory")
+
 /*
  * output pause versions need a delay at least for the
  * w83c105 ide controller in a p610.
#1 lore raw

Review

Quoted 2 lines · Jesse Barnes
(quoted diff) +1 -1
-	RD_REG_WORD(&reg->ictrl);	/* PCI Posted Write flush */
+	mmiowb(); /* make sure this write arrives before any others */

What's going on here? In your docs you say this mmiowb() is explicitly to prevent write ordering problems and doesn't affect posting. However in this patch you're using it to replace a posting flush read.

Quoted 1 line

ha->flags.ints_enabled = 1;

The result will be that we can get to here, but the write that enables the interrupt may still be posted in a bridge somewhere.

James

#2 lore raw
Quoted 7 lines · James Bottomley
Quoted 2 lines · Jesse Barnes

- RD_REG_WORD(&reg->ictrl); /* PCI Posted Write flush */
+ mmiowb(); /* make sure this write arrives before any others */

What's going on here? In your docs you say this mmiowb() is explicitly to prevent write ordering problems and doesn't affect posting. However in this patch you're using it to replace a posting flush read.

Jeremy was the one that added these, I think the comment is misleading and only ordering was intended. If that's not the case I'll drop this bit.

Quoted 5 lines
Quoted 2 lines
  ha->flags.ints_enabled = 1;

The result will be that we can get to here, but the write that enables the interrupt may still be posted in a bridge somewhere.

If we're waiting for an interrupt here, I don't think it matters if we flush or order, we'll wait the same amount of time regardless.

Thanks,
Jesse

#3 lore raw
Quoted 2 lines · Jesse Barnes

If we're waiting for an interrupt here, I don't think it matters if we flush or order, we'll wait the same amount of time regardless.

I don't think so. Your ordering barrier doesn't cause a posted write flush. Posted writes have theoretically no upper limit defined in the spec for the time they may remain posted, so in the former case, you are guaranteed that by the time you set the flag and exit the function that interrupts are enabled in the qla1280. If you apply the patch you sent in, this guarantee is broken and you don't really know how much longer after exiting the function it will be before interrupts become enabled (although in practice it's probably only of the order of ms).

James

#4 lore raw
Quoted 9 lines · James Bottomley
Quoted 2 lines · Jesse Barnes

If we're waiting for an interrupt here, I don't think it matters if we flush or order, we'll wait the same amount of time regardless.

I don't think so. Your ordering barrier doesn't cause a posted write flush. Posted writes have theoretically no upper limit defined in the spec for the time they may remain posted, so in the former case, you are guaranteed that by the time you set the flag and exit the function that interrupts are enabled in the qla1280.

Ok, you're right we don't want to break that. I just didn't think it was that important for the driver to think that interrupts were enabled even when they weren't since it would probably do another read sometime soon anyway, but that's sloppy, so I'll just drop this bit.

Thanks,
Jesse

#5 lore raw
In reply to James Bottomley
Quoted 13 lines · James Bottomley
Quoted 2 lines · Jesse Barnes

If we're waiting for an interrupt here, I don't think it matters if we flush or order, we'll wait the same amount of time regardless.

I don't think so. Your ordering barrier doesn't cause a posted write flush. Posted writes have theoretically no upper limit defined in the spec for the time they may remain posted, so in the former case, you are guaranteed that by the time you set the flag and exit the function that interrupts are enabled in the qla1280. If you apply the patch you sent in, this guarantee is broken and you don't really know how much longer after exiting the function it will be before interrupts become enabled (although in practice it's probably only of the order of ms).

Quoted 1 line

James

I would say microseconds. I think that knowing that the hardware has interrupts enabled by the end of the function is unnecessary, because they will be enabled before you can do anything else to the chip. But it shouldn't hurt anything either, and defensive programming in old SCSI drivers is often a good idea :-)

#6 lore raw
In reply to James Bottomley
Quoted 13 lines · James Bottomley
Quoted 2 lines · Jesse Barnes

If we're waiting for an interrupt here, I don't think it matters if we flush or order, we'll wait the same amount of time regardless.

I don't think so. Your ordering barrier doesn't cause a posted write flush. Posted writes have theoretically no upper limit defined in the spec for the time they may remain posted, so in the former case, you are guaranteed that by the time you set the flag and exit the function that interrupts are enabled in the qla1280. If you apply the patch you sent in, this guarantee is broken and you don't really know how much longer after exiting the function it will be before interrupts become enabled (although in practice it's probably only of the order of ms).

Quoted 1 line

James

James, is this what you want?
I think these are the only writes that need ordering, as opposed to flushing. Being not certain what was intended in the other cases, it's safer to leave them be.

===== drivers/scsi/qla1280.c 1.65 vs edited =====

drivers/scsi/qla1280.c +3 -3
@@ -3398,7 +3398,7 @@
 	sp->flags |= SRB_SENT;
 	ha->actthreads++;
 	WRT_REG_WORD(&reg->mailbox4, ha->req_ring_index);
-	(void) RD_REG_WORD(&reg->mailbox4); /* PCI posted write flush */
+	mmiowb(); /* posted write ordering */
 
  out:
 	if (status)
@@ -3666,7 +3666,7 @@
 	sp->flags |= SRB_SENT;
 	ha->actthreads++;
 	WRT_REG_WORD(&reg->mailbox4, ha->req_ring_index);
-	(void) RD_REG_WORD(&reg->mailbox4); /* PCI posted write flush */
+	mmiowb(); /* posted write ordering */
 
 out:
 	if (status)
@@ -3778,7 +3778,7 @@
 
 	/* Set chip new ring index. */
 	WRT_REG_WORD(&reg->mailbox4, ha->req_ring_index);
-	(void) RD_REG_WORD(&reg->mailbox4); /* PCI posted write flush */
+	mmiowb(); /* posted write ordering */
 
 	LEAVE("qla1280_isp_cmd");
 }
#7 lore raw
Quoted 4 lines · Jeremy Higdon

James, is this what you want?
I think these are the only writes that need ordering, as opposed to flushing. Being not certain what was intended in the other cases, it's safer to leave them be.

Well, these two are just the kicks to tell the card that we have filled a consistent memory slot with a SCSI command. The ordering, I assume, is because we want SCSI commands issued in the order they went down to queuecommand in, so the mmiowb() preserves that order? Could we have a comment to that effect.

My objection isn't so much that what the original patch did would result in errors, merely that we have enough trouble explaining these issues to device driver writers, so whatever you do in your patches demonstrating use has to be really exemplary.

James

#8 lore raw
Quoted 11 lines · James Bottomley
Quoted 4 lines · Jeremy Higdon

James, is this what you want?
I think these are the only writes that need ordering, as opposed to flushing. Being not certain what was intended in the other cases, it's safer to leave them be.

Well, these two are just the kicks to tell the card that we have filled a consistent memory slot with a SCSI command. The ordering, I assume, is because we want SCSI commands issued in the order they went down to queuecommand in, so the mmiowb() preserves that order? Could we have a comment to that effect.

Okay, I'll add a comment there. On the qla1280, it's worse than just out of order. If the write order is switched, the chip will issue an entire queue's worth of stale commands.

Quoted 4 lines

My objection isn't so much that what the original patch did would result in errors, merely that we have enough trouble explaining these issues to device driver writers, so whatever you do in your patches demonstrating use has to be really exemplary.

I think there was also the issue of whether we wanted a flush or just ordering for the interrupt enable/disable. Since we don't really know, and since it's not a performance path, it's safer to leave it a flush after those.

Is the following diff what you're thinking of, James? I'm not entirely happy with it, and could spend more time on it.

===== drivers/scsi/qla1280.c 1.65 vs edited =====

drivers/scsi/qla1280.c +36 -3
@@ -3398,7 +3398,18 @@
 	sp->flags |= SRB_SENT;
 	ha->actthreads++;
 	WRT_REG_WORD(&reg->mailbox4, ha->req_ring_index);
-	(void) RD_REG_WORD(&reg->mailbox4); /* PCI posted write flush */
+
+	/*
+	 * A Memory Mapped I/O Write Barrier is needed to ensure that this write
+	 * of the request queue in register is ordered ahead of writes issued
+	 * after this one by other CPUs.  Access to the register is protected
+	 * by the host_lock.  Without the mmiowb, however, it is possible for
+	 * this CPU to release the host lock, another CPU acquire the host lock,
+	 * and write to the request queue in, and have the second write make it
+	 * to the chip first.  See Documentation/DocBook/deviceiobook.tmpl for
+	 * more information.
+	 */
+	mmiowb(); /* posted write ordering */
 
  out:
 	if (status)
@@ -3666,7 +3677,18 @@
 	sp->flags |= SRB_SENT;
 	ha->actthreads++;
 	WRT_REG_WORD(&reg->mailbox4, ha->req_ring_index);
-	(void) RD_REG_WORD(&reg->mailbox4); /* PCI posted write flush */
+
+	/*
+	 * A Memory Mapped I/O Write Barrier is needed to ensure that this write
+	 * of the request queue in register is ordered ahead of writes issued
+	 * after this one by other CPUs.  Access to the register is protected
+	 * by the host_lock.  Without the mmiowb, however, it is possible for
+	 * this CPU to release the host lock, another CPU acquire the host lock,
+	 * and write to the request queue in, and have the second write make it
+	 * to the chip first.  See Documentation/DocBook/deviceiobook.tmpl for
+	 * more information.
+	 */
+	mmiowb(); /* posted write ordering */
 
 out:
 	if (status)
@@ -3778,7 +3800,18 @@
 
 	/* Set chip new ring index. */
 	WRT_REG_WORD(&reg->mailbox4, ha->req_ring_index);
-	(void) RD_REG_WORD(&reg->mailbox4); /* PCI posted write flush */
+
+	/*
+	 * A Memory Mapped I/O Write Barrier is needed to ensure that this write
+	 * of the request queue in register is ordered ahead of writes issued
+	 * after this one by other CPUs.  Access to the register is protected
+	 * by the host_lock.  Without the mmiowb, however, it is possible for
+	 * this CPU to release the host lock, another CPU acquire the host lock,
+	 * and write to the request queue in, and have the second write make it
+	 * to the chip first.  See Documentation/DocBook/deviceiobook.tmpl for
+	 * more information.
+	 */
+	mmiowb(); /* posted write ordering */
 
 	LEAVE("qla1280_isp_cmd");
 }
#9 lore raw
In reply to Jesse Barnes
Quoted 11 lines · Jesse Barnes
Quoted 7 lines · James Bottomley
Quoted 2 lines · Jesse Barnes

- RD_REG_WORD(&reg->ictrl); /* PCI Posted Write flush */
+ mmiowb(); /* make sure this write arrives before any others */

What's going on here? In your docs you say this mmiowb() is explicitly to prevent write ordering problems and doesn't affect posting. However in this patch you're using it to replace a posting flush read.

Jeremy was the one that added these, I think the comment is misleading and only ordering was intended. If that's not the case I'll drop this bit.

No, I didn't add those. In fact, I thought them to be unnecessary. Jes added them, I believe. I added the reads after the writes of req_ring_index to mailbox4. Since at the time we did not have a write ordering function, I had to use the heavy weight flush.

Take a look at the 1.56 diffs in the scsi_misc-2.6 tree.

jeremy

#10 lore raw
Quoted 10 lines · Jeremy Higdon
Quoted 9 lines · Jesse Barnes
Quoted 7 lines · James Bottomley
Quoted 2 lines · Jesse Barnes

- RD_REG_WORD(&reg->ictrl); /* PCI Posted Write flush */
+ mmiowb(); /* make sure this write arrives before any others */

What's going on here? In your docs you say this mmiowb() is explicitly to prevent write ordering problems and doesn't affect posting. However in this patch you're using it to replace a posting flush read.

Quoted 8 lines
Quoted 3 lines

Jeremy was the one that added these, I think the comment is misleading and only ordering was intended. If that's not the case I'll drop this bit.

No, I didn't add those. In fact, I thought them to be unnecessary. Jes added them, I believe. I added the reads after the writes of req_ring_index to mailbox4. Since at the time we did not have a write ordering function, I had to use the heavy weight flush.

Ok, sorry for the misattribution :). At any rate, I've already dropped that bit.

Jesse

#11 lore raw
In reply to Jesse Barnes

drivers/scsi/qla1280.c line 1732

Quoted 8 lines · Jesse Barnes
drivers/scsi/qla1280.c +1 -1
@@ -1727,7 +1727,7 @@
       reg = ha->iobase;
       /* disable risc and host interrupts */
       WRT_REG_WORD(&reg->ictrl, 0);
-       RD_REG_WORD(&reg->ictrl);       /* PCI Posted Write flush */
+       mmiowb(); /* make sure this write arrives before any others */
       ha->flags.ints_enabled = 0;
 }

This is a typical example of non working sync. You platform might have some kind of guarantee vs. ordering of interrupts, but in the general case, the above may "leak", that is you may still take an interrupt after ha->flags.ints_enabled = 0.

First, on some CPUs like evil PPCs, that write to memory may end up beeing on a different write queue as I explaines, thouh the mmiowb() will help if I implement it as a strong barrier (and the previous MMIO read wouldn't have helped). But that isn't my point.

The problem is that interrupts are asynchronous by nature. When the above code is reached, the device may already have asserted the interrupt line, which may still be in the process of propagating to the CPU through the various APICs or within the CPU core. There is no way you can guarantee you won't take it (though since it's a PCI interrupt, it's, I suppose, a level interrupt, so it will probably go away shortly after beeing asserted). It may even be on it's way to beeing handled on another CPU in fact. Even synchronize_irq() won't help.

I haven't looked at the rest of the driver, but it certainly must be prepared to take spurrious interrupts since that can (and so will) happen.

Ben.

#12 lore raw
Quoted 14 lines · Benjamin Herrenschmidt

drivers/scsi/qla1280.c line 1732

Quoted 8 lines · Jesse Barnes
drivers/scsi/qla1280.c +1 -1
@@ -1727,7 +1727,7 @@
       reg = ha->iobase;
       /* disable risc and host interrupts */
       WRT_REG_WORD(&reg->ictrl, 0);
-       RD_REG_WORD(&reg->ictrl);       /* PCI Posted Write flush */
+       mmiowb(); /* make sure this write arrives before any others */
       ha->flags.ints_enabled = 0;
 }

This is a typical example of non working sync. You platform might have some kind of guarantee vs. ordering of interrupts, but in the general case, the above may "leak", that is you may still take an interrupt after ha->flags.ints_enabled = 0.

Right, that's what James pointed out. Jeremy will submit the qla mmiowb bits, and has dropped these, since the routine probably shouldn't return until interrupts are actually enabled. (But I see on your platform the sore to ins_enabled will probably be issued in parallel to the MMIO store to the interrupt register, and so might happen first.)

Quoted 15 lines

First, on some CPUs like evil PPCs, that write to memory may end up beeing on a different write queue as I explaines, thouh the mmiowb() will help if I implement it as a strong barrier (and the previous MMIO read wouldn't have helped). But that isn't my point.

The problem is that interrupts are asynchronous by nature. When the above code is reached, the device may already have asserted the interrupt line, which may still be in the process of propagating to the CPU through the various APICs or within the CPU core. There is no way you can guarantee you won't take it (though since it's a PCI interrupt, it's, I suppose, a level interrupt, so it will probably go away shortly after beeing asserted). It may even be on it's way to beeing handled on another CPU in fact. Even synchronize_irq() won't help.

Quoted 3 lines

I haven't looked at the rest of the driver, but it certainly must be prepared to take spurrious interrupts since that can (and so will) happen.

Right, afaik all drivers (or at least all PCI drivers) should be able to deal with this. Whether or not they do is a different story (I think qla does).

Jesse