Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp10672749ybi; Thu, 25 Jul 2019 03:24:42 -0700 (PDT) X-Google-Smtp-Source: APXvYqw64NvNreYi1mOmHqbToHixceee/A1XVhrWPM1Yadvh+MpgKUO1ilAbg5orgikgaRs3+SeM X-Received: by 2002:a17:90a:71ca:: with SMTP id m10mr38316851pjs.27.1564050282872; Thu, 25 Jul 2019 03:24:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564050282; cv=none; d=google.com; s=arc-20160816; b=U1edmLad0DdPnpTgnCW/7QeTuHvNvIHyi167K/Q5cLaLfYbIeGUu5o96ouIz0hWHtv qTvrtO0Cgqc6Dq4WVLwdz61CZR01wACKgMJqbAYraFjnHjx+UQqp6SXeZBi0MKPsEy2w Pw23U8cA0EnDraiVZ1mA/QDcp89aonDWscoS0x5qnkAjgVdBizPuI1LkLcPlotI2mxLx uEuXmp0w60MsAYkj1C+O+3Au+VJ9QlNrA4Pc7+nRYPsqvjzAHhIuUY5D8bZbmkD/lulJ U/2Y0Z/2Q8Cv3n0tKtKFiuoxL4EzDKogf3MFfr99R8kuCP9K8DAwGyVAXBTiGcz0XGQd LU4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=BV6dM8lKRM4nhvSMMWnOBjohuWI0KYuThYPBtqqjlnQ=; b=FO1KlldSUxoEgezAEYLMWUjCwJts/ICh4gFW6OFTBBbuFFzlFSvaDidKve95QVW8nL akhLpKo8i59O6t2vd0jdUTCVp2+bZA95bNuRtliwq+++6pQANg7HHb0Am+f5d0Ch7Pj6 NU1Koi007/lFI0AsUpuXYEPCEFDNeGs/3t0wqN6hSlsODc83V8WwtdPgcY6isvg0zifP 50h3GZhzF5/08yQpAv2QZWZw8doiz1gG1rVapl7DenGi9hpNmTBgik9kuHMoIlVfD8Wq 907BcUZqE6p/7iJcvWYYwfb9PaFRkdP4s6oP371+rQcBk9Abl8BycTISI+9Gr3APbR1m m0zQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@brauner.io header.s=google header.b=GGWhlUW9; 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 k32si15771149pjb.11.2019.07.25.03.24.26; Thu, 25 Jul 2019 03:24:42 -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; dkim=pass header.i=@brauner.io header.s=google header.b=GGWhlUW9; 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 S1728428AbfGXWB2 (ORCPT + 99 others); Wed, 24 Jul 2019 18:01:28 -0400 Received: from mail-wm1-f67.google.com ([209.85.128.67]:54454 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726240AbfGXWB1 (ORCPT ); Wed, 24 Jul 2019 18:01:27 -0400 Received: by mail-wm1-f67.google.com with SMTP id p74so43105132wme.4 for ; Wed, 24 Jul 2019 15:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brauner.io; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=BV6dM8lKRM4nhvSMMWnOBjohuWI0KYuThYPBtqqjlnQ=; b=GGWhlUW9ryx7EWI6z+Z45cz9XopIiSQe38PSDmjbvfqKkCIK9IsRQA6UGQhDZvq2+R O+VjLW5fkETWlc1kwbnBUbDG2yWjXwDEkjayqYbBzC1iSjXW2970Zfi4k3sjaulApZUj bAxJFgeHZywTFhfAzsV/6ClZUQl61976hHv5hRI9Qdm6oS9OmyJ6miEjgTAi8d7IT0Gn dgy6su7/zbVTAGjZPkurkiwRS95wmd3jQfCj6u19AmiyHJ7BmSSoilQUFhSKg5sTCsRS RrHGmsIgPIRzycfeVF9HGAHn3+mZm6AQTwUcwIC+ylTsqqsGUdj2Q0ggbNmpuEjpns9g vPAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=BV6dM8lKRM4nhvSMMWnOBjohuWI0KYuThYPBtqqjlnQ=; b=YArqjMEjWmDInkNqkCfmqFHztZmNM+a+ahMVbchbc8PzcvABucF2dcj8i9Z+E+JQ+3 1YY6SRbVLr86WgCeYyZI1qpRBLHeSP2uYPKXypWBZS7m6C8u9MeSh9CF+500Or2RT7Ia aPv9heR06TR2zrRyI9aI3RL+ZIsOKLIeTJz9Q4VoaNQZ9z1yLiOMr/MSTZhrr6rIgXy9 OHREQuBsANfHNCiwAh9/W90NzaN3yPaAyeA4fheTSAXIdAh48ADPbf+7oKuAGDK8WXwX h8LTmQnavFpJ6Z9YhWTqBylJHTZwNpNwNR9lAOsH2Fgsd5oDUHZJHvGgNNF2kFKR4kgp HCIQ== X-Gm-Message-State: APjAAAX51JrC9AFkQtcU8RwEPxc5FPuUmRrwpw7i26R4wCb8WbDzuS10 7JZOXZp0TSj7FiSsPqU9qB8= X-Received: by 2002:a1c:be11:: with SMTP id o17mr75496324wmf.115.1564005685476; Wed, 24 Jul 2019 15:01:25 -0700 (PDT) Received: from brauner.io ([213.220.153.21]) by smtp.gmail.com with ESMTPSA id u1sm43447538wml.14.2019.07.24.15.01.23 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 24 Jul 2019 15:01:24 -0700 (PDT) Date: Thu, 25 Jul 2019 00:01:23 +0200 From: Christian Brauner To: Linus Torvalds Cc: Linux List Kernel Mailing , Oleg Nesterov , Arnd Bergmann , "Eric W. Biederman" , Kees Cook , Joel Fernandes , Thomas Gleixner , Tejun Heo , David Howells , Jann Horn , Andrew Lutomirski , Andrew Morton , Aleksa Sarai , Al Viro , Android Kernel Team Subject: Re: [RFC][PATCH 1/5] exit: kill struct waitid_info Message-ID: <20190724220122.ngf6arhl7gqcnwzf@brauner.io> References: <20190724144651.28272-1-christian@brauner.io> <20190724144651.28272-2-christian@brauner.io> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 24, 2019 at 10:37:34AM -0700, Linus Torvalds wrote: > On Wed, Jul 24, 2019 at 7:47 AM Christian Brauner wrote: > > > > The code here uses a struct waitid_info to catch basic information about > > process exit including the pid, uid, status, and signal that caused the > > process to exit. This information is then stuffed into a struct siginfo > > for the waitid() syscall. That seems like an odd thing to do. We can > > just pass down a siginfo_t struct directly which let's us cleanup and > > simplify the whole code quite a bit. > > Ack. Except I'd like the commit message to explain where this comes > from instead of that "That seems like an odd thing to do". I'll respin and will add an explanation based on the info you gave below. Thanks for providing the background on that! Christian > > The _original_ reason for "struct waitid_info" was that "siginfo_t" is > huge because of all the insane padding that various architectures do. > > So it was introduced by commit 67d7ddded322 ("waitid(2): leave copyout > of siginfo to syscall itself") very much to avoid stack usage issues. > And I quote: > > collect the information needed for siginfo into > a small structure (waitid_info) > > simply because "sigset_t" was big. > > But that size came from the explicit "pad it out to 128 bytes for > future expansion that will never happen", and the kernel using the > same exact sigset_t that was exposed to user space. > > Then in commit 4ce5f9c9e754 ("signal: Use a smaller struct siginfo in > the kernel") we got rid of the insane padding for in-kernel use, > exactly because it causes issues like this. > > End result: that "struct waitid_info" no longer makes sense. It's not > appreciably smaller than kernel_siginfo_t is today, but it made sense > at the time. > > Linus