Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp796616pxf; Thu, 1 Apr 2021 13:54:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwL+/svifxmcscGVG0GGXclWfMQLE4pwQQPTRK93XaeKHsf5pMx6SoJkiTm0w3Di7Zg8fP7 X-Received: by 2002:a17:906:7842:: with SMTP id p2mr11508882ejm.87.1617310484786; Thu, 01 Apr 2021 13:54:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617310484; cv=none; d=google.com; s=arc-20160816; b=dDq/+MDdhuhirvnPnodxYRuz2wyv+mx5tWUAph6JSjKM0rAavin44nyhGQTG3PAJAM 3VVFgoHEOKDWjTRgWkUSfTBfNXI5oXD4VqUME3P8cg5S6AEOBeBnltsglYWIV6tMIn95 aO9bsfwcVar7SZfNLKs87cboocZ+85nKBE/THAy9N0eQvg/LwPaKmrqTPOUP/rs90Boh H0MTajkRLi4IP1CJ3rndCooRPvIl6a6uNNMLucuoMlZhjP+xSIuGPN2OiUiALZrnVR5i /VcbSowjUFOsY6tBXpSWAnWIhduAuZuyTFuI3Z4ZcFtB3iMsn8w8SaVGEh0CUTuzYOm/ QfDA== 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=yGKHITxEwhK0Iy01/uiraz05kcK/PxwJp5MiD8PH/OY=; b=hrIQzbXvASZ1bsRUi8d840Je0BXp2fe7DnfACZyv1fT0mrdfpnq9VDcxmsBlvS4M3N WeVlgIDFw5OWI2zy0G7y7NHxjVavX3Bewp4gBN1cRF2CaTN9M+W+9j2T5ji/vB7CqboN qVhNR3cAy9Xm5OuEJ3id+3E28XEq0kmMSdyIITMl//Xk0qMNX3j8TZP7FokzZZIHYQbR tBlaCgdScIMSHJ+z94T5Kqobei0VxAczl0ESeTzxsxwuoulfQSKsWxkCfNFVpRf8vbta KjuMQtXTdvfGzqccF3Bfzuw7Ym2isGW1HJbjTe9nBoYH0JhJFvToI9Iol03uMm2s91MD 0K6A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=NyAgAAha; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z13si4982663edd.128.2021.04.01.13.54.12; Thu, 01 Apr 2021 13:54:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=NyAgAAha; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233781AbhDAUyK (ORCPT + 99 others); Thu, 1 Apr 2021 16:54:10 -0400 Received: from mail.kernel.org ([198.145.29.99]:38020 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233885AbhDAUx3 (ORCPT ); Thu, 1 Apr 2021 16:53:29 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 272BB6100C; Thu, 1 Apr 2021 20:53:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1617310409; bh=IeGFO7wQN74UxS4HFnyBTT77n4Wa4GfPsbfpJB6Qlnw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NyAgAAhaziRAU8zj1EByvNvVzNYpGkxmEryvVDgLck0vq0MCStLK31Om2yrVXTvgE u+Rcydyi7/3x/AKzZ7mYa+xV9A3ipvVDPxOwAEVYM4nFw71uT7Wsk7W12WBJ5Op7G7 P5lEhp/MR5vN89OsR9PdNpLZIoqVakzUvmxtUSuAcqNmWzwIfwoCsx2p8tk80NJ5Ed 5HdFHQlHtnlax50ii+08WTeWmhnA7fu9YvM9xVYwv/l7+rhdWvybOsQ9i4iIhYRfC7 Z6h7cwPG4yfggyxw6mrQpjkIXnERttU2dM6TiBLRx5bdrZsY0bPjFGAz6ZUA2g5Ebr GMHxNfjLkpAXA== Date: Thu, 1 Apr 2021 13:53:27 -0700 From: Eric Biggers To: Shreeya Patel Cc: tytso@mit.edu, adilger.kernel@dilger.ca, jaegeuk@kernel.org, chao@kernel.org, krisman@collabora.com, 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 v6 4/4] fs: unicode: Add utf8 module and a unicode layer Message-ID: References: <20210331210751.281645-1-shreeya.patel@collabora.com> <20210331210751.281645-5-shreeya.patel@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210331210751.281645-5-shreeya.patel@collabora.com> Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Thu, Apr 01, 2021 at 02:37:51AM +0530, Shreeya Patel wrote: > +# utf8data.h_shipped has a large database table which is an auto-generated > +# decodification trie for the unicode normalization functions and it is not > +# necessary to carry this large table in the kernel. > +# Enabling UNICODE_UTF8 option will allow UTF-8 encoding to be built as a > +# module and this module will be loaded by the unicode subsystem layer only > +# when any filesystem needs it. > +config UNICODE_UTF8 > + tristate "UTF-8 module" > help > Say Y here to enable UTF-8 NFD normalization and NFD+CF casefolding > support. Please update this help text to properly describe this option, especially the consequences of setting it to 'm'. > + select UNICODE 'select' should go before 'help'. > struct unicode_map *unicode_load(const char *version) > { > + try_then_request_module(utf8mod, "utf8"); > + if (!utf8mod) { > + pr_err("Failed to load UTF-8 module\n"); > + return ERR_PTR(-ENODEV); > } > > + spin_lock(&utf8mod_lock); > + if (!utf8mod || !try_module_get(utf8mod)) { > + spin_unlock(&utf8mod_lock); > + return ERR_PTR(-ENODEV); > + } > + spin_unlock(&utf8mod_lock); > + return static_call(unicode_load_static_call)(version); > } > EXPORT_SYMBOL(unicode_load); > > void unicode_unload(struct unicode_map *um) > { > kfree(um); > + > + spin_lock(&utf8mod_lock); > + if (utf8mod) > + module_put(utf8mod); > + spin_unlock(&utf8mod_lock); > + > } > EXPORT_SYMBOL(unicode_unload); > > +void unicode_register(struct module *owner) > +{ > + utf8mod = owner; > +} > +EXPORT_SYMBOL(unicode_register); > + > +void unicode_unregister(void) > +{ > + spin_lock(&utf8mod_lock); > + utf8mod = NULL; > + spin_unlock(&utf8mod_lock); > +} > +EXPORT_SYMBOL(unicode_unregister); This all looks very broken. First, when !CONFIG_MODULES, utf8mod will always be NULL so unicode_load() will always fail. Also, if the unicode_load_static_call() fails, a reference to the utf8mod will be leaked. Also, unicode_unload() can put a reference to the utf8mod that was never acquired. Also there is a data race on utf8mod because the accesses to it aren't properly synchronized. Please consider something like the following, which I think would address all these bugs: static bool utf8mod_get(void) { bool ret; spin_lock(&utf8mod_lock); ret = utf8mod_loaded && try_module_get(utf8mod); spin_unlock(&utf8mod_lock); return ret; } struct unicode_map *unicode_load(const char *version) { struct unicode_map *um; if (!try_then_request_module(utf8mod_get(), "utf8")) { pr_err("Failed to load UTF-8 module\n"); return ERR_PTR(-ENODEV); } um = static_call(unicode_load_static_call)(version); if (IS_ERR(um)) module_put(utf8mod); return um; } EXPORT_SYMBOL(unicode_load); void unicode_unload(struct unicode_map *um) { if (um) { kfree(um); module_put(utf8mod); } } EXPORT_SYMBOL(unicode_unload); void unicode_register(struct module *owner) { spin_lock(&utf8mod_lock); utf8mod = owner; /* note: will be NULL if !CONFIG_MODULES */ utf8mod_loaded = true; spin_unlock(&utf8mod_lock); } EXPORT_SYMBOL(unicode_register); void unicode_unregister(void) { spin_lock(&utf8mod_lock); utf8mod = NULL; utf8mod_loaded = false; spin_unlock(&utf8mod_lock); } EXPORT_SYMBOL(unicode_unregister);