From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boaz Harrosh Subject: Re: [FYI] tux3: Core changes Date: Mon, 18 May 2015 10:58:13 +0300 Message-ID: <55599B95.9030800@plexistor.com> References: <8f886f13-6550-4322-95be-93244ae61045@phunq.net> <55545C2F.8040207@phunq.net> <55549C2F.6000103@redhat.com> <555896EB.7040002@plexistor.com> <55594C8A.7000803@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, tux3@tux3.org, OGAWA Hirofumi To: Rik van Riel , Daniel Phillips , linux-kernel@vger.kernel.org Return-path: Received: from mail-wi0-f172.google.com ([209.85.212.172]:34740 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751207AbbERH6R (ORCPT ); Mon, 18 May 2015 03:58:17 -0400 Received: by wicmc15 with SMTP id mc15so82676511wic.1 for ; Mon, 18 May 2015 00:58:15 -0700 (PDT) In-Reply-To: <55594C8A.7000803@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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