Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp812552ybg; Sun, 26 Jul 2020 23:27:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyGWiqC2zXNqCcs1bF01txc3J9XjJALlpYkNXyq42FexKtnwrfqcagtkLOpS1AtYmXPBhUD X-Received: by 2002:a05:6402:785:: with SMTP id d5mr3677561edy.370.1595831247613; Sun, 26 Jul 2020 23:27:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595831247; cv=none; d=google.com; s=arc-20160816; b=VjoMTgyDKsXy9SYv1ybNV9ngO0lRsIz2rUw7JtNUSMjjoMCCEYCIfj45obeREeb8Gp f86f7NmisITsl3dBHpomG9rS2EX5lcLSgmm0TAEFJmGdDjcQdzydWLn1eOBoEK1IEMOO kzeYfh/VeL/8KblTzi4uP03Jf4rtZt8Ttg/N1CJorkNBAHS4Fq25UlWGy+79tvWMKETs lY+/f+FkDBTu1Z7oTnoal7yopMzVBaDF4MbOXIiP2om1FEtvm2yhl3uyBVGzBawSwl+h YYzcbkxrNwJtBT6JWNQYW0ccpHDSa6YN5nucAXf1WzSmTRTbrkGXB43+KYLJs9yPw9B2 3Psg== 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; bh=2EgGnGmo/REffNp7iRssCmrxwMY7mCIJNW4OaA0WAPU=; b=WS47zQ6qnvELl+KLGZxTWZvBM8UlwbyduqURVsPUs2QCORt5POEq5iJN5qmKTbcaxs aPrwylqlDLXxWv+LnE1HzaUbIFICrDtvu4sSfwsR0r1BBizn400T03QDRHjWH1mOSjKT +r4Zkly9icaUddkNDtHJDxmXFHQ/5tZvvVoIm1YbGYQ/qWdcfxB/wxkUlGhMKflN2W6t lJEfFSsZEIjPCBtK93sQBFsu1QkNUvi6xzBKawFkHX64l9knp7/c52qAtPV1aJtwUbUP MxfAujz008Edav1RSu+S0qMsT/MmHPg0KiPn0nqxKQhqmBpE+alkNDR5uZJ+cwJGX1xe YTow== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cb10si4989092edb.420.2020.07.26.23.27.05; Sun, 26 Jul 2020 23:27:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726797AbgG0GY2 (ORCPT + 99 others); Mon, 27 Jul 2020 02:24:28 -0400 Received: from verein.lst.de ([213.95.11.211]:42172 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726124AbgG0GY2 (ORCPT ); Mon, 27 Jul 2020 02:24:28 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id C0BE068B05; Mon, 27 Jul 2020 08:24:25 +0200 (CEST) Date: Mon, 27 Jul 2020 08:24:25 +0200 From: Christoph Hellwig To: hpa@zytor.com Cc: Al Viro , Christoph Hellwig , linux-kernel@vger.kernel.org, Song Liu , Linus Torvalds , linux-raid@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH 18/23] init: open code setting up stdin/stdout/stderr Message-ID: <20200727062425.GA2005@lst.de> References: <20200714190427.4332-1-hch@lst.de> <20200714190427.4332-19-hch@lst.de> <20200727030534.GD795125@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jul 26, 2020 at 11:20:41PM -0700, hpa@zytor.com wrote: > On July 26, 2020 8:05:34 PM PDT, Al Viro wrote: > >On Tue, Jul 14, 2020 at 09:04:22PM +0200, Christoph Hellwig wrote: > >> Don't rely on the implicit set_fs(KERNEL_DS) for ksys_open to work, > >but > >> instead open a struct file for /dev/console and then install it as FD > >> 0/1/2 manually. > > > >I really hate that one. Every time we exposed the internal details to > >the fucking early init code, we paid for that afterwards. And this > >goes over the top wrt the level of details being exposed. > > > >_IF_ you want to keep that thing, move it to fs/file.c, with dire > >comment > >re that being very special shite for init and likely cause of > >subsequent > >trouble whenever anything gets changed, a gnat farts somewhere, etc. > > > > Do not leave that kind of crap sitting around init/*.c; KERNEL_DS > >may be a source of occasional PITA, but here you are trading it for a > >lot > >worse one in the future. > > Okay... here is a perhaps idiotic idea... even if we don't want to run stuff in actual user space, could we map initramfs into user space memory before running init (execing init will tear down those mappings anyway) so that we don't need KERNEL_DS at least? Err, why? The changes have been pretty simple, and I'd rather not come up with new crazy ways just to make things complicated.