From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754225AbcBPIgP (ORCPT ); Tue, 16 Feb 2016 03:36:15 -0500 Received: from mail-wm0-f45.google.com ([74.125.82.45]:38753 "EHLO mail-wm0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752290AbcBPIgL (ORCPT ); Tue, 16 Feb 2016 03:36:11 -0500 Date: Tue, 16 Feb 2016 09:36:06 +0100 From: Ingo Molnar To: Dave Hansen , Linus Torvalds , Andrew Morton Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org, torvalds@linux-foundation.org, dave.hansen@linux.intel.com, srikar@linux.vnet.ibm.com, vbabka@suse.cz, akpm@linux-foundation.org, kirill.shutemov@linux.intel.com, aarcange@redhat.com, n-horiguchi@ah.jp.nec.com, jack@suse.cz Subject: Re: [PATCH 02/33] mm: overload get_user_pages() functions Message-ID: <20160216083606.GB3335@gmail.com> References: <20160212210152.9CAD15B0@viggo.jf.intel.com> <20160212210155.73222EE1@viggo.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160212210155.73222EE1@viggo.jf.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Dave Hansen wrote: > > From: Dave Hansen > > The concept here was a suggestion from Ingo. The implementation > horrors are all mine. > > This allows get_user_pages(), get_user_pages_unlocked(), and > get_user_pages_locked() to be called with or without the > leading tsk/mm arguments. We will give a compile-time warning > about the old style being __deprecated and we will also > WARN_ON() if the non-remote version is used for a remote-style > access. So at minimum this should be WARN_ON_ONCE(), to make it easier to recover some meaningful kernel log from such incidents. But: > Doing this, folks will get nice warnings and will not break the > build. This should be nice for -next and will hopefully let > developers fix up their own code instead of maintainers needing > to do it at merge time. > > The way we do this is hideous. It uses the __VA_ARGS__ macro > functionality to call different functions based on the number > of arguments passed to the macro. > > There's an additional hack to ensure that our EXPORT_SYMBOL() > of the deprecated symbols doesn't trigger a warning. > > We should be able to remove this mess as soon as -rc1 hits in > the release after this is merged. So when I suggested this then it looked a _lot_ cleanear to me, in my head! OTOH this, if factored out a bit perhaps, could be the basis for a useful technical model to do 'phased in, -next invariant' prototype migrations in the future, especially when it involves lots of subsystems. Strictly only in cases where -rc1 will truly get rid of the __VA_ARGS__ hackery - which we'd do in this case. Nevertheless I'd love to have a high level buy-in from either Linus or Andrew that we can do it this way, as the hackery looks very hideous... The alternative would be to allow the -next churn and to allow the occasional (fairly trivial but tester-disruptive) build breakage. Thanks, Ingo