Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp4754844iob; Mon, 9 May 2022 00:21:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJykzLjWkCBn+5wVL/KnAqo9fYDdZb7tqlW9oNms6VQB4CJldrOTRLR5jSEiWPMFtoiJrPjG X-Received: by 2002:a17:902:aa85:b0:155:ceb9:3710 with SMTP id d5-20020a170902aa8500b00155ceb93710mr15519280plr.59.1652080892489; Mon, 09 May 2022 00:21:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652080892; cv=none; d=google.com; s=arc-20160816; b=ON1q5qbrywhkiMyesyjkL4HT4SV5EFiUQFjIIBkEb7fkHrUBCN8ZMGWNwYhGBTS7ee LniJ1DWAjx8Oefx8tqOGcL17vm7ZbRKznzfWdC9l+zAXtMidV+aH9Th/REEp7FBUjV5V 5XfjbxQr0m3efoklCWL5ziYKTnjK5MWR/k7cwARKavHXVr1/4ypp/kggltY0fmh5F84A GHlnRgFOj26GB0jyV/c54JTFEWZ7ygA+kNnaO9VPYMIrvJ0Dq/UeTboRc6QjbbJmLLfg DBdjeteujirowHBuGQ7rpfU9OII3lixuppjgnwJO+qZcM71RAcK2VWNa96HHCVcuSvDJ sCEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=0uSvfs9Z2v7njRGJQViLybeKzFVsrwm01hOR+kgXElc=; b=C0XI9rrTsigjZwTLkG2eDZGgsRppOVIf9pTSTH3CbGCm8wKqrNZjY0q8NEbFJ/5va6 rdYFSZcbLnyxAs3pFRn+UlJ7D+rnPEklvQkUU8DOcpvFpfwH00q6qt4AwkyAJsmG69Wx ggI6ZxeDIUIctbWfeu07sbrACfhvlMI0RFmCPZ0i//FGuS2C75CwOeTJ7IxlMc+fT6vi S/LvIpKhVWmDjsNz8Xzw6JWAC1upz4fxhUcRdpzPoUMCaW1bFyWx8tz+KuVyiQy9A+WO PaU1AJv2ic6inpIWPBubDBvhD479YhyzJ9/57ykZxmt61+kO21HOBT3jIbBUzedakogz ReGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@me.com header.s=1a1hai header.b=EUdQrxkt; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=me.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id t7-20020a170902e84700b00153b2d16593si12345235plg.411.2022.05.09.00.21.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 May 2022 00:21:32 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@me.com header.s=1a1hai header.b=EUdQrxkt; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=me.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 12AF7170F32; Mon, 9 May 2022 00:18:23 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1389333AbiEFGHZ (ORCPT + 99 others); Fri, 6 May 2022 02:07:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60062 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1389349AbiEFGHR (ORCPT ); Fri, 6 May 2022 02:07:17 -0400 Received: from mr85p00im-ztdg06021201.me.com (mr85p00im-ztdg06021201.me.com [17.58.23.189]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0F5BA66208 for ; Thu, 5 May 2022 23:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1651817010; bh=0uSvfs9Z2v7njRGJQViLybeKzFVsrwm01hOR+kgXElc=; h=From:To:Subject:Date:Message-Id:MIME-Version; b=EUdQrxktd8AJnT09qpyCtwfFvowE28/1Oz2gh/Try2FQYKgGMAXZ2DKHiHHxANHyY nIXq4h4H77XlR42Q4WE9FAlizpoQwMUsEr9gEoQD5xjcTSa+zaVeLxWByXyrTyXiOK eGrOuGzTiAd5SrPM7LctxoeOl2y0xc4voXgTNURV1QGZLH0h95nYOvXwr2PLstmokp /Yq4428xxRoo/BY7ax3hhe9Eca7NeH1UEOl8mX7XJiBOkMmBmsvOnRRMqPOSVi8Xq4 Msl2B+UmnTkUzaxUBoE5mcJ5BO4FPnls7DBR2Mkc+xLGosMjoMijSyVNJ+0fS5RFW6 0549l+DNuOYwQ== Received: from hitch.danm.net (mr38p00im-dlb-asmtp-mailmevip.me.com [17.57.152.18]) by mr85p00im-ztdg06021201.me.com (Postfix) with ESMTPSA id 2BA593208D8; Fri, 6 May 2022 06:03:30 +0000 (UTC) From: Dan Moulding To: linux-kernel@vger.kernel.org Cc: linux-doc@vger.kernel.org, tglx@linutronix.de, akpm@linux-foundation.org, corbet@lwn.net, Dan Moulding Subject: [PATCH v2 0/1] Allow setting hostname before userspace starts Date: Fri, 6 May 2022 00:03:09 -0600 Message-Id: <20220506060310.7495-1-dmoulding@me.com> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Proofpoint-GUID: V7SvW3eXVQsdKv4GqDoxCloxC7_-oHS2 X-Proofpoint-ORIG-GUID: V7SvW3eXVQsdKv4GqDoxCloxC7_-oHS2 X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.425,18.0.572,17.0.605.474.0000000_definitions?= =?UTF-8?Q?=3D2022-01-14=5F01:2022-01-14=5F01,2020-02-14=5F11,2020-01-23?= =?UTF-8?Q?=5F02_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=3 phishscore=0 suspectscore=0 bulkscore=0 clxscore=1015 mlxlogscore=156 spamscore=3 malwarescore=0 mlxscore=3 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205060031 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Some userspace processes may rely on gethostname to always return the correct machine name. However, the only way that the hostname may be set is by some other userspace process calling sethostname first. During boot, if a process that depends on gethostname runs before sethostname has been called, then the process that called gethostname is going to get an incorrect result. A real-world case where this comes up is with mdadm, which if gethostname returns the wrong name, can cause local md-raid arrays to appear to be foreign arrays. This can alter how mdadm assembles the array, or can even cause array assembly to fail. I imagine there are probbaly other real-world cases where undesirable behavior results when the hostname is not set early enough. I'm proposing adding the option to set the hostname from a kernel parameter, so that the correct host name can be guaranteed to be set before any userspace process can call gethostname. I can imagine an even better way to do this would be to have the hostname written to some non-volatile storage (like a firmware NVRAM variable or such), which the kernel could read out during early boot. But, alas, such designs require hardware support, standards, and cooperation. This proposal is an alternative that can provide a simple and immediate solution. v2: * Use strlcpy instead of strncpy to eliminate W=1 compiler warning (assuaging it from its string truncation fears). Thanks to kernel test robot for finding this. * Move "hostname" after "hlt" in kernel-parameters.txt (I promise I know my ABCs). Dan Moulding (1): init: Add "hostname" kernel parameter Documentation/admin-guide/kernel-parameters.txt | 13 +++++++++++++ init/version.c | 17 +++++++++++++++++ 2 files changed, 30 insertions(+) -- 2.35.1