Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp296371imm; Tue, 25 Sep 2018 22:02:29 -0700 (PDT) X-Google-Smtp-Source: ACcGV60KOLC9q3ghle/NA08dea4NPLUV/MqgGWoKUJ79ilGGg3pWP/tQZ3YasiYUQFPB5apTdAzf X-Received: by 2002:a62:6e45:: with SMTP id j66-v6mr220878pfc.259.1537938149590; Tue, 25 Sep 2018 22:02:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537938149; cv=none; d=google.com; s=arc-20160816; b=U4D4eRalZ7D8B1SLL07cQfCSQglykVoCOwla99spqNnCMu5gqIDhslxprJwkNVu7Q8 ayfaTOTDO1XA2wFERxQX8fXVGKkKsEoTI489lSRgbYdOUaosK6gOiaVGSOJX12xEGzs2 /NaWDFRvW6slzUXGHvfouWFHB53MwazStQXaC0WGFiTZV1s0yXl40ZAkmUZUIBj3D623 HFlfEjLV1YCYn0fZSGzxqVk+Bkj2RARGg1Thx3BOH73PxEnj6Mbv/p7qGxGxn8/uqBkM jL40qaueTmYa2Paro9mprEbqMXZHJNxhx+G2bYl1GX1t8w9WiHXhrr25PQHNfaaW9I8t 4KYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:dkim-signature:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=wqDsxABzUE8c/7q35edv8o0o9cYz8e4VO0t3mC1yF5k=; b=wUVFaeVwy4gjfipK/tUBqDJGKabYVKBFr2ZFKm70N+ERMFXc7MlYf5JLTcGurgYu5c bIttAYFDd5qsopMUVkz2O2UeeKi6di4Xj5ERNo6on1ZM6TIIAvNpOvtyLWEOj5TSJWyK oAA/qRFKFZ6Tj/AdZIPd+Y1vaehlxXBa+UcK/RqZWtOyf2dwTiRvyLqq3bodU1H4spoi c7LSpEeUvicc0wQaO0E23gJ7KeIMAEH66fF4nSn9JfLJvBKMMQHZrXAvb0CITYN3lcd5 Dc8vx3rn8hSKZ96IyieSo9MgO/nCr4+YQJm2gDZv0N6sfRaaTmHWnN/j4ZexBu4zvMWT Le4A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nvidia.com header.s=n1 header.b=UlxnlU9Q; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h2-v6si4355899pgk.330.2018.09.25.22.02.14; Tue, 25 Sep 2018 22:02:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@nvidia.com header.s=n1 header.b=UlxnlU9Q; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726669AbeIZLLt (ORCPT + 99 others); Wed, 26 Sep 2018 07:11:49 -0400 Received: from hqemgate15.nvidia.com ([216.228.121.64]:1728 "EHLO hqemgate15.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726328AbeIZLLt (ORCPT ); Wed, 26 Sep 2018 07:11:49 -0400 Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqemgate15.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Tue, 25 Sep 2018 22:00:12 -0700 Received: from HQMAIL101.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Tue, 25 Sep 2018 22:00:46 -0700 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Tue, 25 Sep 2018 22:00:46 -0700 Received: from [10.110.48.28] (10.110.48.28) by HQMAIL101.nvidia.com (172.20.187.10) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 26 Sep 2018 05:00:45 +0000 Subject: Re: [BUG] mm: direct I/O (using GUP) can write to COW anonymous pages To: Jan Kara , Jann Horn CC: Hugh Dickins , Dan Williams , Andrew Morton , Michal Hocko , Rik van Riel , Andrea Arcangeli , Konstantin Khlebnikov , , "Michael S. Tsirkin" , kernel list , Linux-MM , Miklos Szeredi , References: <20180918095822.GH10257@quack2.suse.cz> X-Nvconfidentiality: public From: John Hubbard Message-ID: <4a17705b-5ca9-296b-b24e-d2d9f10b4c06@nvidia.com> Date: Tue, 25 Sep 2018 22:00:45 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180918095822.GH10257@quack2.suse.cz> X-Originating-IP: [10.110.48.28] X-ClientProxiedBy: HQMAIL103.nvidia.com (172.20.187.11) To HQMAIL101.nvidia.com (172.20.187.10) Content-Type: text/plain; charset="utf-8" Content-Language: en-US-large Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1537938012; bh=wqDsxABzUE8c/7q35edv8o0o9cYz8e4VO0t3mC1yF5k=; h=X-PGP-Universal:Subject:To:CC:References:X-Nvconfidentiality:From: Message-ID:Date:User-Agent:MIME-Version:In-Reply-To: X-Originating-IP:X-ClientProxiedBy:Content-Type:Content-Language: Content-Transfer-Encoding; b=UlxnlU9Q1GNa8tY16EcHXLPdirfKofK0NeDcpgzQFSw5ti9Cf+EMUNKe+HMEx9HEA 3zopg+Q8iISYSOkZyCYY1MYwuxm3HL+YA8ClS52moTEmQKJRsYuKmYgUQ5Mhyx4Ef1 h2qPxEMruQ3ow7DMKjJ2kIElm+//3zrkiEjrMJDN0z9mrMAhJnd2mkZRlzo4/Ua82g CjA40dHKnj+qvSMJNxOBY05lB2X/SKJb5D8vWpEAzFc6QCq9WX2i+lPabYcIJf83Wb oqGdOjqROVn1lbY5jFcIqWBhuBdMAmcJjKEh1jxsH5+0HoSCAb8BLptSSjUIlC8lyP Lzs7EeaHJZVoA== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/18/18 2:58 AM, Jan Kara wrote: > On Tue 18-09-18 02:35:43, Jann Horn wrote: >> On Tue, Sep 18, 2018 at 2:05 AM Hugh Dickins wrote: > > Thanks for CC Hugh. > >>> On Mon, 17 Sep 2018, Jann Horn wrote: >>> >> >> Makes sense, I guess. >> >> I wonder whether there's a concise way to express this in the fork.2 >> manpage, or something like that. Maybe I'll take a stab at writing >> something. The biggest issue I see with documenting this edgecase is >> that, as an application developer, if you don't know whether some file >> might be coming from a FUSE filesystem that has opted out of using the >> disk cache, the "don't do that" essentially becomes "don't read() into >> heap buffers while fork()ing in another thread", since with FUSE, >> direct I/O can happen even if you don't open files as O_DIRECT as long >> as the filesystem requests direct I/O, and get_user_pages_fast() will >> AFAIU be used for non-page-aligned buffers, meaning that an adjacent >> heap memory access could trigger CoW page duplication. But then, FUSE >> filesystems that opt out of the disk cache are probably so rare that >> it's not a concern in practice... > > So at least for shared file mappings we do need to fix this issue as it's > currently userspace triggerable Oops if you try hard enough. And with RDMA > you don't even have to try that hard. Properly dealing with private > mappings should not be that hard once the infrastructure is there I hope > but I didn't seriously look into that. I've added Miklos and John to CC as > they are interested as well. John was working on fixing this problem - > https://lkml.org/lkml/2018/7/9/158 - but I didn't hear from him for quite a > while so I'm not sure whether it died off or what's the current situation. > Hi, Sorry for missing this even though I was CC'd, I only just now noticed it, while trying to get caught up again. Anyway, I've been sidetracked for a...while (since July!), but am jumping back in and working on this now. And I've got time allocated for it. So here goes. thanks, -- John Hubbard NVIDIA