Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp726039pxf; Thu, 25 Mar 2021 12:33:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxLTJOZa9mEOhnvU99rO0lIag727Vfh/RjUnmXVIfNlg0lITQl+3TyaaGJ7bw+gFTLYayI/ X-Received: by 2002:a17:906:8447:: with SMTP id e7mr11460638ejy.523.1616700811236; Thu, 25 Mar 2021 12:33:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616700811; cv=none; d=google.com; s=arc-20160816; b=PcDz1q+J9FguaxdLW63sZiqWrelgPqdNhvcrEVWjdDehaLf74lPFHaMVzYyqGPU+OD ndF4YtV1cEhB/H7SJH0d8f4JwXSkbBS//4UGWuelB8xSPwJwXtxkzUjhFcN0+slhzBxd Bo0Qzn8pUq9kRA8EzrRdDXgNipvHN1Ap4SEbjjkTbhcB5htjWW3nYzM7r0sEFvJ9wWE2 Q2keilFvQaKWDjUaDviDb3wlsZ2djWY0JOp5wNKCj44P9dw7StMtiWjBIyBVqdQWax+7 0aKbd/FNnTi1PfWjtftW9XwzwmpMY9Waq0iBrkmkyByTaZodIluOBEmtW3AfPjK7U2oc LnMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:message-id:in-reply-to :date:references:organization:subject:cc:to:from; bh=eSvkCo381eqVAbjV/h519ZlM/cXYTRD5G2N2zBo22Yk=; b=eztWpEM9oas1mok5HZzLEk1D006MsYoPXF71AKSoEI9N90UY5w6KUT2y2GTcr0pkJM yKHEBVZt8wpKAg7QuLB1wZOteVcQQuyJ+fs6gPnnlzkF1a+aF3d3Y/Ppz0/oHv9DGr1J isYUvvN5/scoBGiSM0G7OGtYE175kHy5aXFdeItN54Dh7b+8Z/k0FbLxSd9LxbqcmRQK 5FPDTYkicymtmn+UAJGkd2tsyZnG9SzFDJgF7grdp/2r6QAs0sgVapDE9z6M5/vDVfLO Aw0OAXctzd32LdsbooiQ9AZ5l1KJoRdWq6HLNhz3jOP7fB7CmgAPODxEDeV7t0OdKfFL rCDQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hc39si5012904ejc.125.2021.03.25.12.33.08; Thu, 25 Mar 2021 12:33:31 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229616AbhCYTcI (ORCPT + 99 others); Thu, 25 Mar 2021 15:32:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60656 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229576AbhCYTbr (ORCPT ); Thu, 25 Mar 2021 15:31:47 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1D45AC06174A; Thu, 25 Mar 2021 12:31:47 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: krisman) with ESMTPSA id 0A0F11F46850 From: Gabriel Krisman Bertazi To: Eric Biggers Cc: Shreeya Patel , tytso@mit.edu, adilger.kernel@dilger.ca, jaegeuk@kernel.org, chao@kernel.org, drosen@google.com, yuchao0@huawei.com, linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, kernel@collabora.com, andre.almeida@collabora.com Subject: Re: [PATCH v4 2/5] fs: Check if utf8 encoding is loaded before calling utf8_unload() Organization: Collabora References: <20210325000811.1379641-1-shreeya.patel@collabora.com> <20210325000811.1379641-3-shreeya.patel@collabora.com> Date: Thu, 25 Mar 2021 15:31:42 -0400 In-Reply-To: (Eric Biggers's message of "Thu, 25 Mar 2021 12:21:49 -0700") Message-ID: <878s6bt4gx.fsf@collabora.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Eric Biggers writes: > On Thu, Mar 25, 2021 at 05:38:08AM +0530, Shreeya Patel wrote: >> utf8_unload is being called if CONFIG_UNICODE is enabled. >> The ifdef block doesn't check if utf8 encoding has been loaded >> or not before calling the utf8_unload() function. >> This is not the expected behavior since it would sometimes lead >> to unloading utf8 even before loading it. >> Hence, add a condition which will check if sb->encoding is NOT NULL >> before calling the utf8_unload(). >> >> Reviewed-by: Gabriel Krisman Bertazi >> Signed-off-by: Shreeya Patel >> --- >> fs/ext4/super.c | 6 ++++-- >> fs/f2fs/super.c | 9 ++++++--- >> 2 files changed, 10 insertions(+), 5 deletions(-) >> >> diff --git a/fs/ext4/super.c b/fs/ext4/super.c >> index ad34a37278cd..e438d14f9a87 100644 >> --- a/fs/ext4/super.c >> +++ b/fs/ext4/super.c >> @@ -1259,7 +1259,8 @@ static void ext4_put_super(struct super_block *sb) >> fs_put_dax(sbi->s_daxdev); >> fscrypt_free_dummy_policy(&sbi->s_dummy_enc_policy); >> #ifdef CONFIG_UNICODE >> - utf8_unload(sb->s_encoding); >> + if (sb->s_encoding) >> + utf8_unload(sb->s_encoding); >> #endif >> kfree(sbi); >> } > > > What's the benefit of this change? utf8_unload is a no-op when passed a NULL > pointer; why not keep it that way? For the record, it no longer is a no-op after patch 5 of this series. Honestly, I prefer making it explicitly at the caller that we are not entering the function, like the patch does, instead of returning from it immediately. Makes it more readable, IMO. -- Gabriel Krisman Bertazi