On Mon, Jun 02, 2014 at 12:06:39PM -0500, Steve Wise wrote: > > > On Mon, Jun 02, 2014 at 11:52:47AM -0500, Steve Wise wrote: > > > > > You're correct. And this bug appears to be in the current upstream code as well. > If > > > an > > > > > IB_WR_LOCAL_INV wr is used, it must include IB_SEND_FENCE to fence it until the > prior > > > > read > > > > > completes. > > > > > > > > > > Good catch! I'll post V4 soon. > > > > > > > > Any chance that can be handled as a separate patch rather than folded > > > > in? > > > > > > > > (Disclaimer: I've been following the discussion only very > > > > superficially.) > > > > > > > > > > Sure. I'll post the patch soon. > > > > Thanks, and, again, I'm not terribly happy about the monster > > patch--anything you can split off it is great, even if that thing's > > small. As long as all the intermediate stages still build and run. > > I don't see any way to do this for this particular patch. It rewrites the entire rdma > read logic. There's almost always a way. > > (And any bugs you've identified in upstream code are good candidates for > > separate patches, hopefully preceding the rewrite. That also allows us > > to apply those fixes to stable kernels if appropriate.) > > > > If I do this, then I'd have to respin the refactor patch. I really would like to get this > merged as-is (with the one change I'm sending soon), and move on. I definitely will try > and keep the patches smaller and more discrete going forward. > > Will that work? Yes, just this once, we'll live. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
