From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3zfy1N69RtzF0j4 for ; Mon, 12 Feb 2018 18:27:33 +1100 (AEDT) Received: by mail-wm0-x243.google.com with SMTP id f3so7950488wmc.1 for ; Sun, 11 Feb 2018 23:27:33 -0800 (PST) Sender: Ingo Molnar Date: Mon, 12 Feb 2018 08:27:27 +0100 From: Ingo Molnar To: Randy Dunlap Cc: LKML , Linux MM , Andrew Morton , Fengguang Wu , iommu@lists.linux-foundation.org, linuxppc-dev@lists.ozlabs.org, linux-s390 , sparclinux@vger.kernel.org, X86 ML , "netdev@vger.kernel.org" , linux-wireless , virtualization@lists.linux-foundation.org, John Johansen , Greg Kroah-Hartman Subject: Re: [PATCH] headers: untangle kmemleak.h from mm.h Message-ID: <20180212072727.saupl35jvwex6hbe@gmail.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , * Randy Dunlap wrote: > From: Randy Dunlap > > Currently #includes for no obvious > reason. It looks like it's only a convenience, so remove kmemleak.h > from slab.h and add to any users of kmemleak_* > that don't already #include it. > Also remove from source files that do not use it. > > This is tested on i386 allmodconfig and x86_64 allmodconfig. It > would be good to run it through the 0day bot for other $ARCHes. > I have neither the horsepower nor the storage space for the other > $ARCHes. > > [slab.h is the second most used header file after module.h; kernel.h > is right there with slab.h. There could be some minor error in the > counting due to some #includes having comments after them and I > didn't combine all of those.] > > This is Lingchi patch #1 (death by a thousand cuts, applied to kernel > header files). > > Signed-off-by: Randy Dunlap Nice find: Reviewed-by: Ingo Molnar I agree that it needs to go through 0-day to find any hidden dependencies we might have grown due to this. Thanks, Ingo