Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp192253rwb; Thu, 6 Oct 2022 16:55:29 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5IEoCg5RQoIF0KfRpachWj3uDfSEd7gvcXTWeMAobUNW0tOqelKMC65ZQISg7NrIsy8WM8 X-Received: by 2002:a63:5950:0:b0:459:35df:3014 with SMTP id j16-20020a635950000000b0045935df3014mr1966812pgm.325.1665100529298; Thu, 06 Oct 2022 16:55:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665100529; cv=none; d=google.com; s=arc-20160816; b=lI8zSfjengvgTgjRRbN1camxTyVt41Xv4RiTlg8Z7J81YjciSftrBkbFt6EpDBpOpF JHwFp7OzkmF/78hCZnc00Jv2Y3ysBXwjUdOTnrL68p1FMoUvd+QIlc+h47yvZkqtBgT6 GY/ts3fG/omYAFGTm03fHF6nR6i/IvBcCLgngKJHQb7tuHfShxTaey/+oPZpE0S0iCcC 2o1LI5FaUqCIF+XsPDJBvx0H69sMvCpvMgU9hmvcqXrdjKkxJ/uB8hD+ReiNUAViTsJ5 p6WG4l7sG9D/bUJUQvuuFBF2spRW1RbM6dMig0sR2LhtaLJvnW1WMorxWM2zoAdSYdjL olKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=t/Fn1rFe9RxUjUPW0aTaKQgk6enalkHXPAMzNv/vI1U=; b=fbsT4ktEq+wpslFVKoLAFmhlAy0fXM0SUMMZ81k2W6RTiwDMYpTbmr4b9b4jVMvjyW UHS7pVaqinrM1TM0D9FyEO6rdLO4fkhivuJR0NORHmBhpiy8+Cf5FgPk1Uu+MycMrUv7 On1QCkqWv9/9Rp3h4bLERDlTv+QJYpgMHSLs0w3IgE0wKCYgPbHdhN1MFRkRwNjf6Dqw NtPljY0LwSerS4fGy7bh1PYzhX/rhREgwUr4x/ObmvJHeOn3GrTLVMD+L7NTwCchj2hx rAZ8+nOh30LL/eCcWoY3e9atn/eytcRmaiUsqmqrGA2A9+UK1BlKd+Fgp6c1R1DDEk+S HGuA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=h36AdQHI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k61-20020a17090a3ec300b0020aeaa98ed4si6353579pjc.93.2022.10.06.16.55.16; Thu, 06 Oct 2022 16:55:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=h36AdQHI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231897AbiJFX1h (ORCPT + 99 others); Thu, 6 Oct 2022 19:27:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55170 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231693AbiJFX1e (ORCPT ); Thu, 6 Oct 2022 19:27:34 -0400 Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CB493BBE22 for ; Thu, 6 Oct 2022 16:27:33 -0700 (PDT) Received: by mail-pf1-x42d.google.com with SMTP id v186so3409212pfv.11 for ; Thu, 06 Oct 2022 16:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=t/Fn1rFe9RxUjUPW0aTaKQgk6enalkHXPAMzNv/vI1U=; b=h36AdQHIpsJKcKRyXZ5n5CTzbj3vlgx+sHmXkK7a8FzYrQ6K4/LKNSvRvYKl8yLsZd pcRrf03MMIjwepNwZ/juPvzY2BuxsXbpG89t2rVxUlnWK1Xk3rNTm5s7Q7dhxzaUPGFm ybCZYejJKLX+Q0swAkH5yL5JgQO6HNwRg0mms= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=t/Fn1rFe9RxUjUPW0aTaKQgk6enalkHXPAMzNv/vI1U=; b=DVZ44gNYKEciQr6fobCEtpjI/yTrv8UPlHxwXkXsKHhYhbe3Y65xSwOs3zS3UZ1UL0 U+qjkVgPF0Za66pbYP32bA+IzyYBAmXaur63DvErpYE0P4oDuBZ6X58vSIUOA4FJhG9Q q5+NBrcUEpJ14Scf4gguy93UpOGFutlUqbCc3cIEpH4Vve9p67SWtf6jMSfpt2pR8lEs X8IDtRA/ACP9Dqxs15t2F6gMiLyKgPKfM019dJuoDTSYpfObeP+GWWEtBoIyFAnfbIEQ juV8xaumcXifIWEI+3jiWed4SCx3D0FS9MZcsngX/BdmUj3sQ3yBajGMk0tHiBzlAqve PMzg== X-Gm-Message-State: ACrzQf0h9uBHRIc8/KbPTCkDdQOt/G6vKwcuwuexUWDj/pvyDaN/lYm+ UsPP4WfJ+lnZ7VYiezq0iDi8ng== X-Received: by 2002:a05:6a00:3498:b0:562:70d0:1baf with SMTP id cp24-20020a056a00349800b0056270d01bafmr1828092pfb.61.1665098853334; Thu, 06 Oct 2022 16:27:33 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id a10-20020a1709027e4a00b0017f96581783sm146849pln.223.2022.10.06.16.27.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Oct 2022 16:27:32 -0700 (PDT) Date: Thu, 6 Oct 2022 16:27:31 -0700 From: Kees Cook To: "Guilherme G. Piccoli" Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, kernel-dev@igalia.com, kernel@gpiccoli.net, anton@enomsg.org, ccross@android.com, tony.luck@intel.com Subject: Re: [PATCH 1/8] pstore: Improve error reporting in case of backend overlap Message-ID: <202210061627.E29FCDBE1@keescook> References: <20221006224212.569555-1-gpiccoli@igalia.com> <20221006224212.569555-2-gpiccoli@igalia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221006224212.569555-2-gpiccoli@igalia.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 On Thu, Oct 06, 2022 at 07:42:05PM -0300, Guilherme G. Piccoli wrote: > The pstore infrastructure supports one single backend at a time; > trying to load a another backend causes an error and displays a > message, introduced on commit 0d7cd09a3dbb ("pstore: Improve > register_pstore() error reporting"). > > Happens that this message is not really clear about the situation, > also the current error returned (-EPERM) isn't accurate, whereas > -EBUSY makes more sense. We have another place in the code that > relies in the -EBUSY return for a similar check. > > So, make it consistent here by returning -EBUSY and using a > similar message in both scenarios. > > Signed-off-by: Guilherme G. Piccoli > --- > fs/pstore/platform.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c > index 0c034ea39954..c32957e4b256 100644 > --- a/fs/pstore/platform.c > +++ b/fs/pstore/platform.c > @@ -562,8 +562,9 @@ static int pstore_write_user_compat(struct pstore_record *record, > int pstore_register(struct pstore_info *psi) > { > if (backend && strcmp(backend, psi->name)) { > - pr_warn("ignoring unexpected backend '%s'\n", psi->name); > - return -EPERM; > + pr_warn("backend '%s' already in use: ignoring '%s'\n", > + backend, psi->name); > + return -EBUSY; Thank you! Yes, this has bothered me for a while. :) -- Kees Cook