Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2942194yba; Mon, 8 Apr 2019 07:55:55 -0700 (PDT) X-Google-Smtp-Source: APXvYqwHkOXROImgcC1hoBv0fHLy1XSiAHGS18tzUgQ8tqOGDEugoda8e8OYbCGwtBjHn9wfBBrw X-Received: by 2002:a63:36ce:: with SMTP id d197mr29484585pga.180.1554735355213; Mon, 08 Apr 2019 07:55:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554735355; cv=none; d=google.com; s=arc-20160816; b=mTYc4OMftIFC/qrLdOYqJDtkt3guk52ciBR/oWuhDJWuo6qOlZJtE+zsFHEAo1T1rp qIyUa1rSHBwJY9B1SKB/i3I4GwVbjrw7jJeWykNABVoFd2SyYVoDDHgus2KcQPgahkya HN1/fJTlswa55OoE6nu4qMy3EqwRKTV9xM6FwFm6zUFXGP8T811+t7SZNo9cPWa1RyUE aJ+NmHGoox9osRRc9yk30UMc3ic/lRB1nqIH1fIuL0YjFLFMB+l8chTZyoes+SxRkWEJ fJD6IRGLIEGdwgGG4EFufyHnfVGJ2xB2bGw5jpKkJuMIEl6otEjdvbC1xgyvCSpbSItt jwxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=jYS4YB6xQJBW5Cjgq2FmmiodlQqxQnUu/xaaZZ+5Xjc=; b=SkIW/um3SqOB5q5wvhNHFSVm4QU6IFsPsI0Zh0+h4rRYS2ZVdi/h95SpHyUr7RaxuA Pf3ypRDU4awVLCQoo3s25FG8+gcSqlKxMSjXubcefS/pOKyrKE4MOC0QURYjDap7HhVI xt5jtJcJPD9NF6nVkfximHJVcjxDtZrwLbUgkU88FJ9SSed2OGLD9QkJfA6CVuWLzKc/ fVt8a8aJHv51iY4CnxTFgkPQMW/BNfo+pp5Y+EBZinU5LXvmmxjDQ3mQaARkEBtpNfHa ig7hMMeWMLPpPd7nJy2ZMfMfdI8taRIG6OSKfdRbd0gF8d1JpogicVoFKpjtSyj4Au1h zYaw== 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 x3si26134812pll.268.2019.04.08.07.55.39; Mon, 08 Apr 2019 07:55:55 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726911AbfDHN7C (ORCPT + 99 others); Mon, 8 Apr 2019 09:59:02 -0400 Received: from mail-qt1-f194.google.com ([209.85.160.194]:35538 "EHLO mail-qt1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726523AbfDHN7C (ORCPT ); Mon, 8 Apr 2019 09:59:02 -0400 Received: by mail-qt1-f194.google.com with SMTP id h39so6683684qte.2; Mon, 08 Apr 2019 06:59:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jYS4YB6xQJBW5Cjgq2FmmiodlQqxQnUu/xaaZZ+5Xjc=; b=c98tOlUyKAxfiiAGSqUyy0ZNCQTfvfjcYwKUYRv04KX5t7ZeJXY+QP3Rcmjqe6zei8 2yv8DJrzrmbCLpLNzTuMX0mYc8vt3vZGVOZfeHav2GFhG4+syygbTQ3VFUtLL31dVn+P JQ/WGlSaybHnYybIee2Qw8g0TMzXyp/PkjtiLhBisdBv8LiTtgBqQdMuqdJX3f40aiIY Nd2WUby+cwreYgrMlU4lbJutNjBesObxD+YMDvv/1cjBjyIIbbRjbSyKL1IGuurV8GnQ Iyyd7uWqPDggk6Et/+NzdPb/bThxU1PNnphNu6qqSEIrgBgrqiLzF0TVqCSuotjYgZxD Vl5g== X-Gm-Message-State: APjAAAUyUA5dmE5owhOi3hE80DrvFe84MnClm6d8cl6SOyyMdBtzP0Yt dXvI6GKukgN4n5+v1u0m3akxDm/qCCpD0sS0Dek= X-Received: by 2002:ac8:8b9:: with SMTP id v54mr25473996qth.64.1554731941101; Mon, 08 Apr 2019 06:59:01 -0700 (PDT) MIME-Version: 1.0 References: <20190408124640.GA607@lst.de> In-Reply-To: <20190408124640.GA607@lst.de> From: Arnd Bergmann Date: Mon, 8 Apr 2019 15:58:44 +0200 Message-ID: Subject: Re: CONFIG_* symbols in UAPI headers? To: Christoph Hellwig Cc: Jie Zhang , Mike Frysinger , David Howells , linux-arch , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 8, 2019 at 2:46 PM Christoph Hellwig wrote: > > I just stumbled over the MAP_UNINITIALIZED defintion, initially > added by: > > commit ea637639591def87a54cea811cbac796980cb30d > Author: Jie Zhang > Date: Mon Dec 14 18:00:02 2009 -0800 > > nommu: fix malloc performance by adding uninitialized flag > > The defintion depends on CONFIG_MMAP_ALLOW_UNINITIALIZED, which > will never be set by userspace. How is this supposed to work? > > Shoudn't we define the symbol unconditionally and just turn it > into a no-op in the implementation? Right, good catch. That should work. It can probably be done by adding another check before the conditional, like: /* clear anonymous mappings that don't ask for uninitialized data */ if (!vma->vm_file && !(IS_ENABLED(CONFIG_MMAP_ALLOW_UNINITIALIZED) && (flags & MAP_UNINITIALIZED)) memset((void *)region->vm_start, 0, region->vm_end - region->vm_start); > 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 thought we had cleaned them out a long time ago, but it looks like those have been there since the uapi headers got split out, and are still wrong. Why doesn't scripts/headers_check.pl find those? Arnd