Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp5196798imb; Thu, 7 Mar 2019 09:48:19 -0800 (PST) X-Google-Smtp-Source: APXvYqyynVrim1wCXqabyTlDYNbVyq36G1h5S3p6qjSx5vAgA9phoMnLtO4mupxm9Rx/tLiiP4gJ X-Received: by 2002:a63:2c50:: with SMTP id s77mr12573096pgs.440.1551980899123; Thu, 07 Mar 2019 09:48:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551980899; cv=none; d=google.com; s=arc-20160816; b=MQN0h4dEtF+wSZtRxsoyVJBjimefff3FyLSWmmAPeKiPj2xpSkWPRnldH2ckr/39W3 55TLtt+psM0VUf8tPL3GPHe1UhOgY/fn0uwRKojurfrGO5WOEOMheWhYqQ3t7OjzvC5K yXFiZhQgX81Nax7rcbRCR1DYpdfHX+sZL3t9KpEt2FNhhZ+Jgxypiwty1EYvbCqnTqsB //Ct44AW63txz1JRTjd58dzEVhbbgK6hKo6qrk51DoX/NCItw3CTLu58+IDeM/Lof2PY y+cPSCJY2pz4KcDtRTF8YC3sUiiDFgQT+fYmDLPKHiqBF4s5w0Erji0zQfhR0pW/sNgY SrUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=B650aAqz0JXcIiNtPXoMS7FiqQQajk6JP9Xmjxq1Lto=; b=E5gD18KT5lDwFQA/c1RQMx9NXgFfFqpi4Chx7DqCrFI1sGvk7glfKYUvTb5dOtDcgq yApsj0hLNQLwtqjDQf8sG5ntNr/neJEqKjPbWHucNbdH3SjygLHbcRk2P1mlOBsaUfG5 zy3kkJ9J7NLBiYTzPWStuvmTM50QU+L8/lmSAVwC3R8FKP7J+cJAM8sVbaqiDte+H+ai kIoYk8EoTf4zMJ+STgpO8dg/g6WISixfoYEnR/AP7TyFl/MsO5p205COkmVf/nfKY+la wVlrFjmSFiJL8NhQHAS0njQwQDdyBXEUw1LiZgmpeGDRMH6d64hVhijnfzLlbcVNSb70 zmkw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f67si4307310pgc.182.2019.03.07.09.48.03; Thu, 07 Mar 2019 09:48:19 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726956AbfCGRq5 (ORCPT + 99 others); Thu, 7 Mar 2019 12:46:57 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:36516 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726943AbfCGRq4 (ORCPT ); Thu, 7 Mar 2019 12:46:56 -0500 Received: from akpm3.svl.corp.google.com (unknown [104.133.8.65]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 17DE1C139; Thu, 7 Mar 2019 17:46:55 +0000 (UTC) Date: Thu, 7 Mar 2019 09:46:54 -0800 From: Andrew Morton To: Dan Williams Cc: Jerome Glisse , Linux MM , Linux Kernel Mailing List , Ralph Campbell , John Hubbard , linux-fsdevel Subject: Re: [PATCH 09/10] mm/hmm: allow to mirror vma of a file on a DAX backed filesystem Message-Id: <20190307094654.35391e0066396b204d133927@linux-foundation.org> In-Reply-To: References: <20190129165428.3931-10-jglisse@redhat.com> <20190129193123.GF3176@redhat.com> <20190129212150.GP3176@redhat.com> <20190130030317.GC10462@redhat.com> <20190130183616.GB5061@redhat.com> <20190131041641.GK5061@redhat.com> <20190305141635.8134e310ba7187bc39532cd3@linux-foundation.org> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 5 Mar 2019 20:20:10 -0800 Dan Williams wrote: > My hesitation would be drastically reduced if there was a plan to > avoid dangling unconsumed symbols and functionality. Specifically one > or more of the following suggestions: > > * EXPORT_SYMBOL_GPL on all exports to avoid a growing liability > surface for out-of-tree consumers to come grumble at us when we > continue to refactor the kernel as we are wont to do. The existing patches use EXPORT_SYMBOL() so that's a sticking point. Jerome, what would happen is we made these EXPORT_SYMBOL_GPL()? > * A commitment to consume newly exported symbols in the same merge > window, or the following merge window. When that goal is missed revert > the functionality until such time that it can be consumed, or > otherwise abandoned. It sounds like we can tick this box. > * No new symbol exports and functionality while existing symbols go unconsumed. Unsure about this one?