From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BB526C282C3 for ; Thu, 24 Jan 2019 09:04:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8DF5F20854 for ; Thu, 24 Jan 2019 09:04:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727345AbfAXJEC (ORCPT ); Thu, 24 Jan 2019 04:04:02 -0500 Received: from mx2.suse.de ([195.135.220.15]:37578 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726997AbfAXJEC (ORCPT ); Thu, 24 Jan 2019 04:04:02 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id CDB23AEFF; Thu, 24 Jan 2019 09:04:00 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 59C7C1E3FF5; Thu, 24 Jan 2019 10:04:00 +0100 (CET) Date: Thu, 24 Jan 2019 10:04:00 +0100 From: Jan Kara To: lsf-pc@lists.linux-foundation.org Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Dan Williams , Jerome Glisse , John Hubbard Subject: [LSF/MM TOPIC] get_user_pages() pins in file mappings Message-ID: <20190124090400.GE12184@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org This is a joint proposal with Dan Williams, John Hubbard, and Jérôme Glisse. Last year we've talked with Dan about issues we have with filesystems and GUP [1]. The crux of the problem lies in the fact that there is no coordination (or even awareness) between filesystem working on a page (such as doing writeback) and GUP user modifying page contents and setting it dirty. This can (and we have user reports of this) lead to data corruption, kernel crashes, and other fun. Since last year we have worked together on solving these problems and we have explored couple dead ends as well as hopefully found solutions to some of the partial problems. So I'd like to give some overview of where we stand and what remains to be solved and get thoughts from wider community about proposed solutions / problems to be solved. In particular we hope to have reasonably robust mechanism of identifying pages pinned by GUP (patches will be posted soon) - I'd like to run that by MM folks (unless discussion happens on mailing lists before LSF/MM). We also have ideas how filesystems should react to pinned page in their writepages methods - there will be some changes needed in some filesystems to bounce the page if they need stable page contents. So I'd like to explain why we chose to do bouncing to fs people (i.e., why we cannot just wait, skip the page, do something else etc.) to save us from the same discussion with each fs separately and also hash out what the API for filesystems to do this should look like. Finally we plan to keep pinned page permanently dirty - again something I'd like to explain why we do this and gather input from other people. This should be ideally shared MM + FS session. [1] https://lwn.net/Articles/753027/ Honza -- Jan Kara SUSE Labs, CR