Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4149293yba; Tue, 9 Apr 2019 12:13:12 -0700 (PDT) X-Google-Smtp-Source: APXvYqySlbrQz56JuMepy0kJaf1pCvNzuz15mPhr1qs+GoYEJtlhA26A1nLa2DFhpv3eRLGGcg/k X-Received: by 2002:a17:902:7841:: with SMTP id e1mr38487021pln.303.1554837192189; Tue, 09 Apr 2019 12:13:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554837192; cv=none; d=google.com; s=arc-20160816; b=IIYuSoMv5otIrVDRUdkz7s8LXeJuqGfG3clUSOwsGDmUzOj2TjsO8PhD7Lqq3C/7Yi eB8YBcwc8UgdAIMmAj05weWgk9VPGVpAb8yYUqEb5pGIFitmK+xpYsz+pD6dsUDE5D21 LBrU07vykswK+uZ9rhGCmA4LnyX4uhBavv+6qjFwC6faqr/J26Fag7JYi+Bo7Pp7MEB9 Wr0sufQpWfgvK0l7BvJ1Nr3xnqzIz6NRXLcu9asyc/gErOZlXBnvFBNw5Hdv3/hrODDn ddica+Qipk+5GIz+0v7EghaM/RQUZKJdayXKn2WwkcJr1nGhtLsNzMZu4DCAAXY5T14/ mHvA== 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:date:cc:to:from:subject:message-id; bh=3a290FE3frq7ebbZBukHvQ2jBQeJ+afzHth6WzBjIS8=; b=0A6xN0K5ETh6VO4+ASaOqqChQ8mxATaapiN/8HCfbQXzCSE2T7VdAs6flhwA8oKmIA v9J+A4xr+Bl5ogulK59AGMWLiO1QLUzdLyApEu2sLnpq3Rhxfq2d3gmdfOaw+qRbX7zk 2WufT/AnHs1FYqt73bL5qoCAT0CXFlFNiGh8Jhped0JlGo1oDGnMhVYEgicpmeWmuMV5 4k9cJQocWctVAd4dDOqabWt6T9mk2zIYOawEWR5EFclHcp8eXjKePemb6r1JAaGR70vt /8lFvmGLJAtKUi3X84Spj1kQEdW8XAdR33J3AM1XQqBEEAP/dLyrbBiPjxWGz9PQyK9q RI/w== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=tiscali.nl Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l189si27716398pgd.291.2019.04.09.12.12.56; Tue, 09 Apr 2019 12:13:12 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=tiscali.nl Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726937AbfDITLu (ORCPT + 99 others); Tue, 9 Apr 2019 15:11:50 -0400 Received: from lb3-smtp-cloud9.xs4all.net ([194.109.24.30]:39498 "EHLO lb3-smtp-cloud9.xs4all.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726497AbfDITLu (ORCPT ); Tue, 9 Apr 2019 15:11:50 -0400 Received: from xps13 ([83.160.161.190]) by smtp-cloud9.xs4all.net with ESMTPSA id Dw9ohQUhdiLOmDw9rh4pfW; Tue, 09 Apr 2019 21:11:47 +0200 Message-ID: <10ca99831556bed2849e16caa5a4810628dc320c.camel@tiscali.nl> Subject: Re: CONFIG_* symbols in UAPI headers? From: Paul Bolle To: Christoph Hellwig , Jie Zhang Cc: Mike Frysinger , David Howells , Arnd Bergmann , linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Date: Tue, 09 Apr 2019 21:11:44 +0200 In-Reply-To: <20190408124640.GA607@lst.de> References: <20190408124640.GA607@lst.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-3.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfIPQIcZ4KvPu46+eDT2MM+SEWOGQy7P6d90TqyeXZL4+8n6Kcpj1u7s8SqKxOxsElumt/RD0XJ1QdhsAh+GaY3bPKanWxZGgCv22PoTyDPfDjaVQ46wn C00u7ZdajfgQIEN8I93G4w65JXcbUFoV7yhpos9x7nMBYUqs/oI8umQqM3lFIKsG0azvYmFFKfwfEzSaLxe2NbI/i3GRlmb7DSlbHRUabzhSvfzOqMUH09C9 kxat3GDuuf9fWDIywSlFNFVJ3G/skKoQ9HendIWw/GyY38lSoy4LzG/yCua7E7lo160e62+TekNQxmG0KF1J8t7kWLXh+pi+BiSlgyVz4Cs= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christoph Hellwig schreef op ma 08-04-2019 om 14:46 [+0200]: > There are a few similar issues, like struct elf_prstatus having > a different layout depending on CONFIG_BINFMT_ELF_FDPIC, or > MAX_SHARED_LIBS defending on CONFIG_BINFMT_SHARED_FLAT. I've had the patch pasted below in a local branch for over five years, but never dared to push it upstream. Does it still apply? Thanks, Paul Bolle -- >8 --- From 0f73c8ee776c197e3029c4eed21af0f121a8f9d3 Mon Sep 17 00:00:00 2001 From: Paul Bolle Date: Tue, 4 Feb 2014 22:22:48 +0100 Subject: [PATCH] headers_check: enable check for CONFIG_ leakage The check for leaked CONFIG_ symbols was disabled in v2.6.30, because it generated too much noise. But a (rather simplistic) preprocessing of comments suffices to silence the noise (ie, no false positives are reported anymore). So add some preprocessing of comments and enable check_config() again. Signed-off-by: Paul Bolle --- scripts/headers_check.pl | 33 ++++++++++++++++++++++++++++----- 1 file changed, 28 insertions(+), 5 deletions(-) diff --git a/scripts/headers_check.pl b/scripts/headers_check.pl index b6aec5e4365f..8e67017c1b67 100755 --- a/scripts/headers_check.pl +++ b/scripts/headers_check.pl @@ -36,13 +36,36 @@ foreach my $file (@files) { open(my $fh, '<', $filename) or die "$filename: $!\n"; $lineno = 0; + my $in_comment = 0; + my $swap_state = 0; while ($line = <$fh>) { $lineno++; - &check_include(); - &check_asm_types(); - &check_sizetypes(); - &check_declarations(); - # Dropped for now. Too much noise &check_config(); + + # strip inline comments + $line =~ s|/\*.*\*/||; + + # try to handle multi line comments + if ($in_comment == 0 and $line =~ m|/\*|) { + $line =~ s|/\*.*$||; + # we still need to check (the first half of) this line + # so we set $in_comment after the checks + $swap_state = 1; + } + if ($in_comment == 1 and $line =~ m|\*/|) { + $line =~ s|^.*\*/||; + $in_comment = 0; + } + unless ($in_comment) { + check_include(); + check_asm_types(); + check_sizetypes(); + check_declarations(); + check_config(); + } + if ($swap_state) { + $in_comment = 1; + $swap_state = 0; + } } close $fh; } -- 2.17.2