Messages in this thread | | | Date | Mon, 18 May 2015 10:58:13 +0300 | From | Boaz Harrosh <> | Subject | Re: [FYI] tux3: Core changes |
| |
On 05/18/2015 05:20 AM, Rik van Riel wrote: > On 05/17/2015 09:26 AM, Boaz Harrosh wrote: >> On 05/14/2015 03:59 PM, Rik van Riel wrote: >>> On 05/14/2015 04:26 AM, Daniel Phillips wrote: >>>> Hi Rik, >> <> >>> >>> The issue is that things like ptrace, AIO, infiniband >>> RDMA, and other direct memory access subsystems can take >>> a reference to page A, which Tux3 clones into a new page B >>> when the process writes it. >>> >>> However, while the process now points at page B, ptrace, >>> AIO, infiniband, etc will still be pointing at page A. >>> >> >> All these problems can also happen with truncate+new-extending-write >> >> It is the responsibility of the application to take file/range locks >> to prevent these page-pinned problems. > > It is unreasonable to expect a process that is being ptraced > (potentially without its knowledge) to take special measures > to protect the ptraced memory from disappearing.
If the memory disappears that's a bug. No the memory is just there it is just not reflecting the latest content of the fs-file.
> > It is impossible for the debugger to take those special measures > for anonymous memory, or unlinked inodes. >
Why? one line of added code after the open and before the mmap do an flock
> I don't think your requirement is workable or reasonable. >
Therefor it is unreasonable to write/modify a ptraced process file.
Again what I'm saying is COWing a page on write, has the same effect as truncate+write. They are both allowed and both might give you the same "stale" effect. So the presidence is there. We are not introducing a new anomaly, just introducing a new instance of it. I guess the question is what applications/procedures are going to break. Need lots of testing and real life installations to answer that, I guess.
Thanks Boaz
| |