From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 53045C27C4F for ; Thu, 13 Jun 2024 14:07:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CEBEF6B009E; Thu, 13 Jun 2024 10:07:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C9B456B00A0; Thu, 13 Jun 2024 10:07:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B62BD6B00A1; Thu, 13 Jun 2024 10:07:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 993846B009E for ; Thu, 13 Jun 2024 10:07:04 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 4EE37140130 for ; Thu, 13 Jun 2024 14:07:04 +0000 (UTC) X-FDA: 82226041968.10.373180F Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf05.hostedemail.com (Postfix) with ESMTP id 53D8010000C for ; Thu, 13 Jun 2024 14:07:02 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=mgUp09eo; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf05.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718287621; a=rsa-sha256; cv=none; b=udduyIA5NOYvzzq6AVkQX9VTuKs2qpwqBXWIl7Ygp3eCKfnrFI2km0jfydd+FPtk3mhmUP eDaBKowbFh2ASfJasGbPHoZ5nkhSa7ZoIhQMAjM30+tkmIr3XY0omW44QISmG6pEkjVwj+ KGxdiyEZmYkYVyAabLwEbVvwCnBGs/8= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=mgUp09eo; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf05.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718287621; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=aZq6PN49zE6/crz+f03BWODsiATPJSnT/GYXKHLLVW8=; b=mBn6ZQN3qvpg/iMu898/5VDy25+neXSgu5R2LQmkeekqmNA0AS/ijNbNO7QbVRQxoSjQpQ Ve7EmLFHRz1KaH+wr8ngnV4R/Z4urP1hAoQH8Njrf5gzPSp58isBLcA4O8FapbrBqW3ttr Rc9RItsMt7u83axl7+NVRsi4n7wlwug= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 70AA261B66 for ; Thu, 13 Jun 2024 14:07:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C45DBC4AF67 for ; Thu, 13 Jun 2024 14:07:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718287620; bh=aZq6PN49zE6/crz+f03BWODsiATPJSnT/GYXKHLLVW8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=mgUp09eoHFNiC+e40Sdlx+wV86u6mq28RsjWv5yqW22xAYuD2V4ef6X2PqBlt5Pjx TAzzT6h4NAeWiW/TE4Gkt11NQs6odaT0AY0/uvykvzEV31/hGUMlnXaoknHbYWvVle zgBAtmbLLg6iuO+MBqgMmcg9akpbcF2BjvAWNq9y/RbUYe0PsoabxSlI1/xzP7sdpM D6AQ6C37jNSgmrBzdLlgGcsv8HpLmo2VC5zNv30Sh4hojY8tRvzdDehAFWbIJUNB1m muhNxpK/NW3yGnVd2dz7sV4/7fLicjxg01bzfKeyuV4LgnQTKFys5rgLjUDGNokCaM UmKr9iYpm+zIw== Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-52c525257feso1383890e87.1 for ; Thu, 13 Jun 2024 07:07:00 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCX0BwoJRmMHTpBbJ+n7fT3SQ2mTsU/wlfkt4i6wqTSHTKY6YKJ9Q99SEM1HgowEYHq0Ja/e9IybOh12p1jW/aROlC4= X-Gm-Message-State: AOJu0YzVVutsRzNM2tWSqufZRza9RdqxcIhx8VEDLopjLOgfEbFxy/11 X3IlXJ28btdkTginmlBx/WxV0H91lFkPXrb1u2YOayuqnXFD5PBi9nLry6+soEeUy1wLw6POEjO 5zQyAqeWd5ahXajVpvw+LMWEEV0s= X-Google-Smtp-Source: AGHT+IF9eAs9Xa9DMTH+FguZcJhTpSg8shwf78TXAXIjRoDacPdfR5OXqtb6KahPz38tlgl4i+ur9hrZoV4xDfDGqZ4= X-Received: by 2002:a05:6512:3f10:b0:529:b632:ae4e with SMTP id 2adb3069b0e04-52c9a3b7b34mr3721460e87.2.1718287618656; Thu, 13 Jun 2024 07:06:58 -0700 (PDT) MIME-Version: 1.0 References: <20240611144911.327227285@goodmis.org> <20240611144949.703297941@goodmis.org> <202406121145.8860502D7@keescook> <20240612145228.5bf426e0@rorschach.local.home> <20240613092642.385461d5@rorschach.local.home> In-Reply-To: <20240613092642.385461d5@rorschach.local.home> From: Ard Biesheuvel Date: Thu, 13 Jun 2024 16:06:47 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 2/2] pstore/ramoops: Add ramoops.mem_name= command line option To: Steven Rostedt Cc: Mike Rapoport , Kees Cook , linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Lorenzo Stoakes , linux-mm@kvack.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Tony Luck , "Guilherme G. Piccoli" , linux-hardening@vger.kernel.org, Guenter Roeck , Ross Zwisler , wklin@google.com, Vineeth Remanan Pillai , Joel Fernandes , Suleiman Souhlal , Linus Torvalds , Catalin Marinas , Will Deacon Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 53D8010000C X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: i3mioksr8su4qgmq577jhqei79u36fqb X-HE-Tag: 1718287622-160207 X-HE-Meta: U2FsdGVkX19uoVHKQagNG0lL07NOATm074HKxSyqYzBjRufLQFeEEfz1jRLChSWa7MciAG1q/WdS041jlKw6ldcAcba+hzaTn/R/Y0iiXAq4tvkYGKDtmcvYHYVQ7Nu2sdffQnb//0/jurSvZGiXORlMl8AaywHNhqkLwxybKrOmoB0s+MbbR0xexiqxWC2CnrRfQ02ja29kIMe4xmguhter62HmTnt6U5nFc7npVTrjyWsaW7jgKuqIfBJ3aFJYQ8YmN0eagXqbUdHITNEmeE9Dt+yXD9nj+XRnwuNtL8UDohu5dFj0O13hxlej6IiP92Wat1l4QA+aohKDS8Bp13DfFecRTTdjGeXPHXMxn2b3AsW5aC0jlOFp46auu4wVMVomIl1woZqSRKO4cBB9IRAV65AmiKJJVeuNCBdXkAQSJhDjYuFzo9luZVjEW+GDLcqyan7XC4X5GYuE+g4adGDcW5T8E9DbuWqonUfr0SeAFSlOqsEpuyNHlUmdZ71tF6y6QjphChJ83mcUnn30YxspzkQ9CQsV196gmjbGfpItw1Bc77bFEugBFbEgTpKL/LtBpi3yuLKiGolJMepaaKG2ReXKR3iiuRVvaNC4w3rxTlnlLWpSYolg+envLfwuflQHfwoS5LWWNJCybjpacmr9lFixaq11Jp2zM+U5IfDCEVEODxofXRaeJWJhfnUENfnsr4uJN0Jo2gohRLBsjl9jc3oP5mZ2Sif5xjLKAv4FO9t9ib3jteROMjB7CVWWrvJvsOZp2jiYpZCDtj8m/f77CRaeBAOY9A8Z4ibef1IAosfH+EMLlQUH8InTjIrojhPD2adgOIQdxvdXWa/DWdZ6aJdbSfcmJMwZnsU+gJgcaZhc3rKeHsd2WZNtHmQOgXE3debXE24dQem4JPeIY5MiLIE25W4RieQmFWWnY5VgAQc7iRyLrFDLPvt42gKvaUd2wRsxL1CTaJjNSTF B4FmU00c XMRPTGsxQ3itLfSUAmRHPQnwmAxf8UCBupi4DsJ3BiqkeMHtD+ZcrkNdku95KoT3chcNgz+S97DchqSQsf5hcrUe0mT7PAJSbFcKE6CLvvhhvW6u8G+te8Ef6tseeKxNGq46vBcYMspXM2/6tuiXUb5udrw1biq/yCLcqx1PmPokwV6UvBGLxqH5/h60SI2oYea4l0zhjFzpdX/C/o/YSHubpITYMLKgsesZ1NlzYC8W8JTMrVACHZt+1xum6ezfBIfnqfKG6+GkKSp3Tyvb9wKnkCAPNXPCs8mCKW5LEtHsUvR/DMy4hx2GdQWBjCMLcLnhTCL0OSacvP8C+P32w6bl9xcofn3R0MX8ha9i88jDRvfHyITXcEie6a9+2STXoF9+xtJnO8FOrjvI8rlBOq99UMPsiQvWytyOxnHl30hX3SbM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, 13 Jun 2024 at 15:26, Steven Rostedt wrote: > > On Thu, 13 Jun 2024 08:11:48 +0200 > Ard Biesheuvel wrote: > > > > > > I've added one more comment to v5, with that fixed I can take this. > > > > > > > So how is this supposed to work wrt to the rigid 'no user visible > > regressions' rule, given that this whole thing is a best effort thing > > This has nothing to do with user space. The kernel command line has > broken in the past. If you update the kernel, you can update the > command line. There's no "no user visible regressions" rule. It's > "Don't break user space". This has nothing to do with user space. > > > to begin with. This needs at least a huge disclaimer that this rule > > does not apply, and if this works today, there is no guarantee that it > > will keep working on newer kernels. Otherwise, you will be making the > > job of the people who work on the boot code significantly more > > difficult. And even then, I wonder whether Linus and #regzcop are > > going to honour such a disclaimer. > > Again, this has nothing to do with user space. The rule Linus talks > about is breaking user space. This is about kernel debugging. Something > *completely different*! > > > > > So this belongs downstream, unless some guarantees can be provided > > that this functionality is exempt from the usual regression policies. > > I disagree. kexec/kdump also has the same issues. > Fair enough. As long as it is documented that there is no guarantee that this will keep working over a kernel upgrade, then I have no objections.