On Thu 13-12-18 07:43:25, Jerome Glisse wrote: > On Wed, Dec 12, 2018 at 08:20:43PM -0700, Jason Gunthorpe wrote: > > On Wed, Dec 12, 2018 at 07:01:09PM -0500, Jerome Glisse wrote: > > > > Even the IOMMU idea probably doesn't work, I doubt all current > > > > hardware can handle a PCI-E error TLP properly. > > > > > > What i saying is reprogram hardware to crappy page ie valid page > > > dma map but that just has random content as a last resort to allow > > > filesystem to reuse block. So their should be no PCIE error unless > > > hardware freak out to see its page table reprogram randomly. > > > > No, that isn't an option. You can't silently provide corrupted data > > for RDMA to transfer out onto the network, or silently discard data > > coming in!! > > > > Think of the consequences of that - I have a fileserver process and > > someone does ftruncate and now my clients receive corrupted data?? > > This is what happens _today_ ie today someone do GUP on page file > and then someone else do truncate the first GUP is effectively > streaming _random_ data to network as the page does not correspond > to anything anymore and once the RDMA MR goes aways and release > the page the page content will be lost. So i am not changing anything > here, what i proposed was to make it explicit to device driver at > least that they were streaming random data. Right now this is all > silent but this is what is happening wether you like it or not :) I think you're making the current behaviour sound worse than it really is. You are correct that currently driver can setup RDMA with some page, one instant later that page can get truncated from the file and thus has no association to the file anymore. That can lead to *stale* data being streamed over RDMA or loss of data that are coming from RDMA. But none of this is actually a security issue - no streaming of random data or memory corruption. And that's all kernel cares about. It is userspace responsibility to make sure file cannot be truncated if it cannot tolerate stale data. So your "redirect RDMA to dummy page" solution has to make sure you really swap one real page for one dummy page and copy old real page contents to the dummy page contents. Then it will be equivalent to the current behavior and if the hardware can do the swapping, then I'm fine with such solution... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
