Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933443AbbENM7t (ORCPT ); Thu, 14 May 2015 08:59:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45103 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933066AbbENM7m (ORCPT ); Thu, 14 May 2015 08:59:42 -0400 Message-ID: <55549C2F.6000103@redhat.com> Date: Thu, 14 May 2015 08:59:27 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Phillips , linux-kernel@vger.kernel.org CC: linux-fsdevel@vger.kernel.org, tux3@tux3.org, OGAWA Hirofumi Subject: Re: [FYI] tux3: Core changes References: <8f886f13-6550-4322-95be-93244ae61045@phunq.net> <55545C2F.8040207@phunq.net> In-Reply-To: <55545C2F.8040207@phunq.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1594 Lines: 38 On 05/14/2015 04:26 AM, Daniel Phillips wrote: > Hi Rik, > > Our linux-tux3 tree currently currently carries this 652 line diff > against core, to make Tux3 work. This is mainly by Hirofumi, except > the fs-writeback.c hook, which is by me. The main part you may be > interested in is rmap.c, which addresses the issues raised at the > 2013 Linux Storage Filesystem and MM Summit 2015 in San Francisco.[1] > > LSFMM: Page forking > http://lwn.net/Articles/548091/ > > This is just a FYI. An upcoming Tux3 report will be a tour of the page > forking design and implementation. For now, this is just to give a > general sense of what we have done. We heard there are concerns about > how ptrace will work. I really am not familiar with the issue, could > you please explain what you were thinking of there? 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. 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... -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/