From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boaz Harrosh Subject: Re: [FYI] tux3: Core changes Date: Sun, 17 May 2015 16:26:03 +0300 Message-ID: <555896EB.7040002@plexistor.com> References: <8f886f13-6550-4322-95be-93244ae61045@phunq.net> <55545C2F.8040207@phunq.net> <55549C2F.6000103@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-f177.google.com ([209.85.212.177]:37440 "EHLO mail-wi0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752763AbbEQN0G (ORCPT ); Sun, 17 May 2015 09:26:06 -0400 Received: by wibt6 with SMTP id t6so41763784wib.0 for ; Sun, 17 May 2015 06:26:05 -0700 (PDT) In-Reply-To: <55549C2F.6000103@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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. > This causes the process and the other subsystem to each > look at a different page, instead of at shared state, > causing ptrace to do nothing, AIO and RDMA data to be > invisible (or corrupted), etc... > Again these problems already exist. Consider each in-place-write being a truncate (punch hole) + new-write is that not the same? Cheers Boaz