Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp2664501rwb; Fri, 2 Dec 2022 13:07:56 -0800 (PST) X-Google-Smtp-Source: AA0mqf5tC0T8M90qcwJSf6qkU1qIuusztD6FSKTA3L2hp0mLptPYpdiAg0v7JQ1rkwwXuYXROos/ X-Received: by 2002:a17:902:f812:b0:189:9a71:109b with SMTP id ix18-20020a170902f81200b001899a71109bmr20979798plb.171.1670015275804; Fri, 02 Dec 2022 13:07:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670015275; cv=none; d=google.com; s=arc-20160816; b=b2sUXVLyAh21S1HC7yb9YE8h+89tkDTi9jnyIishrwPvxYQc/lIjqXLovsYPWi/e/G 7gy8xnstPcLTsvzXSimGKaQG0XouMbmBOmPaOzGJxIv+hPq3KH/2zuogTlMWSDxPaCrW EaPUtlM2iJC66iEUzs56wzPH4ni3vS/0uWzNYEkcElMwG9LX0R6exK3MBopodp1igg73 byi0emTiAM+iZ0TN8+/VCbqiBtW8CI8qDTFoGfrOR9sWPi4+dh6wzhoIOS2VtzbuHolx IDkPjvbgvF2WKXSa1/DU8qSjOcxQj0ET81YhRv9H9P1D/IxNl1ZP8IH/GIMB3+xJSZiy 6QvQ== 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 :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=10BRB4aEzDuavaIq2q8F6ozaK43XUtHizzv88zbJaJM=; b=cNac3DcJd0LkJ48bnjLNfQa4u29q3ZBFE8uBKtHqGwVc2LPcUH2gMTaWu1X9zqZPAz +obwW20riV4XGwaq8Hc+iSl0AW3vN6Uc+ah+xE815aAGBdGejqF9QMEb62S2aaWfrRm1 RP928c4aH1+FG9Z7xauIq3YMoh7dTeTLjb/Cl4e3xrRBZU7uFka5pBWiPlFZ39txEzfF j1qnJlvZTk6ofyPfF7HyFf5yviXVQtb3R6LbB+dGdjU6SK7Y8wG5+GEuWktwXIl1vYzr KECUFya+nQXF9uVcOABOIKwtVCZ+Tl8GjRg4Ur98WdBS22xPg3XgiLiNsICxGISUpzvb 0ouA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=VQ6Kt73v; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id kb3-20020a17090ae7c300b00218b76cda10si9376207pjb.0.2022.12.02.13.07.45; Fri, 02 Dec 2022 13:07:55 -0800 (PST) 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=@linux-foundation.org header.s=korg header.b=VQ6Kt73v; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234041AbiLBUxv (ORCPT + 83 others); Fri, 2 Dec 2022 15:53:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60520 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233851AbiLBUxt (ORCPT ); Fri, 2 Dec 2022 15:53:49 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 85E3DDB615; Fri, 2 Dec 2022 12:53:48 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 4005AB8229B; Fri, 2 Dec 2022 20:53:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79F67C433D6; Fri, 2 Dec 2022 20:53:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1670014425; bh=UyfrIfBwgRbws4E6wvQ9jOxRC9kf4UQkkYiiqt2Trm4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=VQ6Kt73vpwRd9sui69s96hd9uhvSKWsJ4WR6vBi/7Be+2rqQL7SlW8oqS1D18qaxe GzxMmezBd++jpf7Wde2XV6iAKNTcncWQih5RaMbrYvX3iZ35JrrzpXRfJLpxEp0UYC BkbAuAp1SajuCE4kvSQAYYmDeHrTluA2R/5kxHOY= Date: Fri, 2 Dec 2022 12:53:44 -0800 From: Andrew Morton To: Aditya Garg Cc: "willy@infradead.org" , "ira.weiny@intel.com" , "axboe@kernel.dk" , "bvanassche@acm.org" , "keescook@chromium.org" , "songmuchun@bytedance.com" , "slava@dubeyko.com" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Christoph Hellwig Subject: Re: [PATCH] hfsplus: Add module parameter to enable force writes Message-Id: <20221202125344.4254ab20d2fe0a8e784b33e8@linux-foundation.org> In-Reply-To: <53821C76-DAFE-4505-9EC8-BE4ACBEA9DD9@live.com> References: <53821C76-DAFE-4505-9EC8-BE4ACBEA9DD9@live.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 Fri, 2 Dec 2022 06:01:16 +0000 Aditya Garg wrote: > From: Aditya Garg > > This patch enables users to permanently enable writes of HFS+ locked > and/or journaled volumes using a module parameter. > > Why module parameter? > Reason being, its not convenient to manually mount the volume with force > everytime. There are use cases which are fine with force enabling writes > on journaled volumes. I've seen many on various online forums and I am one > of them as well. > > Isn't it risky? > Yes obviously it is, as the driver itself warns users for the same. But > any user using the parameter obviously shall be well aware of the risks > involved. To be honest, I've been writing on a 100Gb journaled volume for > a few days, including both large and small files, and haven't faced any > corruption yet. > Presumably anyone who enables this knows the risk, and if it's a convenience, why not. Documentation/filesystems/hfsplus.rst would be a good place to document this module parameter please. > --- a/fs/hfsplus/super.c > +++ b/fs/hfsplus/super.c > @@ -459,12 +477,20 @@ static int hfsplus_fill_super(struct super_block *sb, void *data, int silent) > } else if (test_and_clear_bit(HFSPLUS_SB_FORCE, &sbi->flags)) { > /* nothing */ > } else if (vhdr->attributes & cpu_to_be32(HFSPLUS_VOL_SOFTLOCK)) { > - pr_warn("Filesystem is marked locked, mounting read-only.\n"); > - sb->s_flags |= SB_RDONLY; > + if (force_locked_rw) { > + pr_warn("Filesystem is marked locked, but writes have been force enabled.\n"); > + } else { > + pr_warn("Filesystem is marked locked, mounting read-only.\n"); > + sb->s_flags |= SB_RDONLY; > + } > } else if ((vhdr->attributes & cpu_to_be32(HFSPLUS_VOL_JOURNALED)) && > !sb_rdonly(sb)) { > - pr_warn("write access to a journaled filesystem is not supported, use the force option at your own risk, mounting read-only.\n"); > - sb->s_flags |= SB_RDONLY; > + if (force_journaled_rw) { > + pr_warn("write access to a journaled filesystem is not supported, but has been force enabled.\n"); > + } else { > + pr_warn("write access to a journaled filesystem is not supported, use the force option at your own risk, mounting read-only.\n"); > + sb->s_flags |= SB_RDONLY; > + } All these super long lines are an eyesore. How about pr_warn("write access to a journaled filesystem is " "not supported, but has been force enabled.\n");