Returned mail: Data format error

[Bounced mail]

SK?°
!
O Î‰mæÃco;>FP2vN¦•m ¤óô©–us–òÑ
Ô³®K2…²õð¾ÖeToì7êA<å¬Ñô0oa Œç`äB¸ô•MÀ>5ML5>å¥Ã±F)Joà³Nþ¼ý‰hk|$4n>º¿ª3Mb0 
6ŋ¨‰pãÀ™X´(À>Z9CªùÇ˂aØ;¨UD
×KÊ߶· µœäžu¸¯Õ©ýȽNŽÃ
‰42u-\ö–JïÜðéloëð—rY
Ê?´\Æ©{,kUòâ³÷(yZã»GcŒ“ž/MÀûcr0z™Ï(|±ŸvP ó¸Í <ÏvQ ™¿4ê!Ž1^½WÃòÁä9ÖC¼~b
LG?¯ÎôMí*ÎluK(\·Wjô×È{-œ¯UfŒƒ%(u}úC·NŸ#c“þö'p½sh…~D#§µ†g]ŽÖc~„ä’Ú…^Ç9´?´TžæT,ø 
›KC’Á_9Û£s7ÖÂB!ܸÒOLTWt!mlcž\‘º5}&ÇZX’ɯ>©kDħj[0
&]Fñòlµé÷ì/ùz;}§ü2¨B9c½<0ÁLª¢#êŘŰk
ÚƹŸy«§·üVPwÄ2í$
ùúHµŒÉÃte­|íñ0áTޚÊ
 ]íl2VϞ¢ò7G÷¹"Ÿëútùƍî&êbFš5½ïÜ6ç‰{›úÊÉv:Õ#-¡#Úw_½E¼
ŒÈ¤~µÒäyƚ„“š‘_3h¡;E¥‚dº¿T›£ÊQç†]u“Æ?¤dԋ«q»¡ó¤X¼TÕP¸…‚Ë
jÞBµÎ{]âlwØÏMè1”tñ‚c”O„•¸<1wŒb,ù¸éC£H ˆîM:XÜWœö¿n;ŸRæ3¬]»Iãš`>úQXé[Öhž‚å.Ãp6…
õj{IÚpv÷ãPUûŠŒ¦»*I)§¢°Iî scÚÈsÉ9_Ǽz¹máiñ¯Ä–1™Ãý_侅
ý-Ük}-wò»uv–3UÐ!cÚá4¬þüÖ>æÍ£9¶Flý7¹ÍԈ_F—’!DԄ³±‚ø²¥ˆÖ<%è'Z©s9Íé
 OçоÜfmRú‰‘Š<¨Pš³S”ª>E\#‘©"¡’š…
oº$7œ0—*µl]ß_܌ªå.âkêCäŒÙ‚¦åèC‡š1Ï"ŽYÙ59‘ó¯:7O/ìÀU}jãé‡#"p
ËÔ
pßÊ öŽ“ž”±œ0çPp‰ð‹wyZA›šQë§i'ü#{ÜHþÊB–âÂ>ŠFó ðë5
¢>C”1L×ЏâÂÝP>2d^
”ê8‰Ãx˜3FÙ,“ûDë¬õiìàNhó~¸\:xÎÕ¡
3‘ƒAl5yPcmµ2¥‚5‹:ãhv‘UY„ƒÈGÍh³/ªÖk‘dϲ¨9TʪN­»L¬ø‡—̵#†Mnš
_u0éF¾B5¸ÕîІWµÒ´ú®àÜ1ï¹®'à"<¼'Án<
< ~™jІ“Cð-$¥
ÏZeÑf.±ïKÌ\âzP†ìnÉ¿ÜLžg-Wxr·®va­sqù¬®¾œÉ—äÌ»DÖ?´<^;}Äy*áðµ¾ÌËnô5
áÛkò$Ì1fÛïö„ò®lJÁ„3êe#å»k׿<^îFIOòÑù¾‘xXú\G-‰¿3uü'0Á•)Ü4<ÄMcÑPïlC<ŽÀóGg‡cíÛ2t/òòïç¸{¯×èÖ¾Kª
…dv‹ÃÆtz.›©Âd 1ÑÇî\e’Š÷õˆ(ts"4n¥“¡îè™WYɉ4•T”S:°'Ž 
“‹¢/[?)¯¼Åºs±äQUØ&Í1ñZsgci]·&<û0[.߁è!5¾¾êYÆÀCдϩlQnÝõI›
ãûj5ôu¦˜ÝŽ·©¡š/˜R×Q[ëE–\’‚ñÖuª„ŽÏÓחRír8jØ/:ç­t[Q&Õiö‡hޏ!ÚMRÞsB:ŽÓÁ

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH v7 07/12] dma-mapping: introduce dma_has_iommu()

[Dan Williams]

On Sun, Oct 15, 2017 at 8:14 AM, Matan Barak  wrote:
[..]
> IMHO, using iommu for that and causing DMA errors just because the
> lease broke isn't the right thing to do.

Yes, see the current proposal over in this thread:

https://lists.01.org/pipermail/linux-nvdimm/2017-October/012885.html
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH v7 07/12] dma-mapping: introduce dma_has_iommu()

[Matan Barak]

On Fri, Oct 13, 2017 at 6:03 PM, Jason Gunthorpe
 wrote:
> On Fri, Oct 13, 2017 at 08:50:47AM +0200, Christoph Hellwig wrote:
>
>> > However, chatting this over with a few more people I have an alternate
>> > solution that effectively behaves the same as how non-ODP hardware
>> > handles this case of hole punch / truncation today. So, today if this
>> > scenario happens on a page-cache backed mapping, the file blocks are
>> > unmapped and the RDMA continues into pinned pages that are no longer
>> > part of the file. We can achieve the same thing with the iommu, just
>> > re-target the I/O into memory that isn't part of the file. That way
>> > hardware does not see I/O errors and the DAX data consistency model is
>> > no worse than the page-cache case.
>>
>> Yikes.
>
> Well, as much as you say Yikes, Dan is correct, this does match the
> semantics RDMA MR's already have. They become non-coherent if their
> underlying object is changed, and there are many ways to get there.
> I've never thought about it, but it does sound like ftruncate,
> fallocate, etc on a normal file would break the MR coherency too??
>
> There have been efforts in the past driven by the MPI people to
> create, essentially, something like lease-break' SIGIO. Except it was
> intended to be general, and wanted solve all the problems related with
> MR de-coherence. This was complicated and never became acceptable to
> mainline.
>
> Instead ODP was developed, and ODP actually solves all the problem
> sanely.
>
> Thinking about it some more, and with your other comments on
> get_user_pages in this thread, I tend to agree. It doesn't make sense
> to develop a user space lease break API for MR's that is a DAX
> specific feature.
>
> Along the some lines, it also doesn't make sense to force-invalidate
> MR's linked to DAX regions, while leaving MR's linked to other
> regions that have the same problem alone.
>
> If you want to make non-ODP MR's work better, then you need to have a
> general overall solution to tell userspace when the MR becomes (or I
> guess, is becoming) non-coherent, that covers all the cases that break
> MR coherence, not just via DAX.
>
> Otherwise, I think Dan is right, keeping the current semantic of
> having MRs just do something wrong, but not corrupt memory, when they
> loose coherence, is broadly consistent with how non-ODP MRs work today.
>

I agree, keeping the current semantics is probably the best thing we
could do. It's a trade-off between breaking existing applications,
having a new lease API for DAX or just failing DAX in particular (as
opposed to other cases). For stable mappings, what we have is probably
sufficient. For mappings which could be changed, it's unclear to me
how you could guarantee non-racy behavior that is bounded by a
pre-defined time and guarantee no user-space errors. On top of that,
ODP (should) already solve that problem transparently.

IMHO, using iommu for that and causing DMA errors just because the
lease broke isn't the right thing to do.

> Jason

Matan

> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm