On Tue, Mar 6, 2018 at 12:14 PM, Logan Gunthorpe <logang@xxxxxxxxxxxx> wrote: > > On 05/03/18 05:49 PM, Oliver wrote: >> >> It's in arch/powerpc/kernel/io.c as _memcpy_toio() and it has two full >> barriers! >> >> Awesome! >> >> Our io.h indicates that our iomem accessors are designed to provide x86ish >> strong ordering of accesses to MMIO space. The git log indicates >> arch/powerpc/kernel/io.c has barely been touched in the last decade so >> odds are most of that code was written in the elder days when people >> were less aware of ordering issues. It might just be overly conservative >> by today's standards, but maybe not (see below). > > > Yes, that seems overly conservative. > >> (I'm not going to suggest ditching the lwsync trick. mpe is not going >> to take that patch >> without a really good reason) > > > Well, that's pretty gross. Is this not exactly the situation mmiowb() is > meant to solve? See [1]. Yep, mmiowb() is supposed to be used in this situation. According to BenH, author of that io_sync hack, we implement the stronger semantics so that we don't break existing drivers that assume spin_unlock() does order i/o even though it's not supposed to. At a guess the x86 version of spin_unlock() happens to do that so the rest of us need to either live with it or fix all the bugs :) > Though, you're right in principle. Even if power was similar to other > systems in this way, it's still a risk that if these pages get passed > somewhere in the kernel that uses a spin lock like that without an mmiowb() > call, then it's going to have a bug. For now, the risk is pretty low as we > know exactly where all the p2pmem pages will be used but if it gets into > other places, all bets are off. Yeah this was my main concern with the whole approach. For ioremap()ed memory we have the __iomem annotation to help with tracking when we need to be careful, but we'd lose that entirely here. > I did do some work trying to make a safe > version of io-pages and also trying to change from pages to pfn_t in large > areas but neither approach seemed likely to get any traction in the > community, at least not in the near term. It's a tricky problem. HMM with DEVICE_PRIVATE might be more palatable than the pfn_t conversion since there would still be struct pages backing the device memory. That said, there are probably other issues with device private memory not being part of the linear mapping, but HMM provides some assistance there. Oliver
