Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp4479015pxf; Tue, 23 Mar 2021 11:34:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzNux42Y6FZHAtKx1mkl0IzocAcpb4luKZYVSnKa1worfAk8Yhe+OIXHq8SeOUMHUFvcKEo X-Received: by 2002:a17:906:4955:: with SMTP id f21mr6476846ejt.74.1616524442404; Tue, 23 Mar 2021 11:34:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616524442; cv=none; d=google.com; s=arc-20160816; b=pakz0cju9kZc+jl/qq4PAP4cEg2PtvTK89khliT8G7BRy0ajNQHHjim4cPml4Xq9VY pm/stUZpGDn1secxfOynAbYNpWGPK14L7dvOcbUoZyH71lbpSiX7+4bt/3ubl2Rknoj7 Ovdo3G8DLQ0fKmP14tsPILyPo+h4JfFgmcBkj+xeKM3LrNiSpeFMLXFzR0JE+7ilEy6z VU5lJrcxoXraRyOqffw2WVabOyPCOe4hUjJgELkuoitme9nuFfpHYEiS0YE9BfpnloZW JPso6hKThIquFybUNa/znAQJ+Ag7csuwqAKTXIWKLH2v4kRIFweOZeX0LXHvjv4qnff/ I4Cw== 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 :message-id:date:subject:cc:to:from; bh=EKAmWgEsZOcsdtigUWclob/h+LbxDAohBBASze3/10U=; b=JbCGoW2q4owLZlycD8TLLDuwzfvDwIZDTER26lEaTWxx0YfmpoEZkVkVqebt4IV4nQ YA3BKq5g9YyztDBB8aWHk0WIu+3BeBSfbSWMwtXug1cDZSM4liSlrAbl4dy+iswZWbST AbVmfoMN0bFhGvMC0AJT/o/bZRrC9eofSkTGfULzBQ4QD7B/48nHk9r1F7NwPhoyWpIa uJiC1l7UIJ8vHEhATUCgHbhfjlCcizsoFX/8R03bytrNwGzrOc/1odplB9oub/MfR5ih MMvi7roFAjG5+T7qJTiQwISHXXmSQFM7gjmhbpR8tRpHH5/u9d+6G7KC7m4k2p5NMeW/ zDKQ== ARC-Authentication-Results: i=1; mx.google.com; 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=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 y3si13686864eda.196.2021.03.23.11.33.33; Tue, 23 Mar 2021 11:34:02 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231966AbhCWSdB (ORCPT + 99 others); Tue, 23 Mar 2021 14:33:01 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:53204 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232025AbhCWScd (ORCPT ); Tue, 23 Mar 2021 14:32:33 -0400 Received: from localhost.localdomain (unknown [IPv6:2401:4900:5170:240f:f606:c194:2a1c:c147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: shreeya) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 59CC01F44A65; Tue, 23 Mar 2021 18:32:26 +0000 (GMT) From: Shreeya Patel To: tytso@mit.edu, adilger.kernel@dilger.ca, jaegeuk@kernel.org, chao@kernel.org, krisman@collabora.com, ebiggers@google.com, drosen@google.com, ebiggers@kernel.org, yuchao0@huawei.com Cc: 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: [PATCH v3 0/4] Make UTF-8 encoding loadable Date: Wed, 24 Mar 2021 00:01:56 +0530 Message-Id: <20210323183201.812944-1-shreeya.patel@collabora.com> X-Mailer: git-send-email 2.30.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org 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. Goal is to make UTF-8 encoding loadable by converting it into a module and adding a layer between the filesystems and the utf8 module which will load the module whenever any filesystem that needs unicode is mounted. 1st patch in the series resolves the warning reported by kernel test robot and 2nd patch fixes the incorrect use of utf8_unload() in ext4 and f2fs filesystems. Unicode is the subsystem and utf8 is a charachter encoding for the subsystem, hence 3rd and 4th patches in the series are renaming functions and file name to unicode for better understanding the difference between UTF-8 module and unicode layer. Last patch in the series adds the layer and utf8 module and also uses static_call() function introducted for preventing speculative execution attacks. --- Changes in v3 - Add a patch which checks if utf8 is loaded before calling utf8_unload() in ext4 and f2fs filesystems - Return error if strscpy() returns value < 0 - Correct the conditions to prevent NULL pointer dereference while accessing functions via utf8_ops variable. - Add spinlock to avoid race conditions. - Use static_call() for preventing speculative execution attacks. Changes in v2 - Remove the duplicate file from the last patch. - Make the wrapper functions inline. - Remove msleep and use try_module_get() and module_put() for ensuring that module is loaded correctly and also doesn't get unloaded while in use. - Resolve the warning reported by kernel test robot. - Resolve all the checkpatch.pl warnings. Shreeya Patel (4): fs: unicode: Use strscpy() instead of strncpy() fs: Check if utf8 encoding is loaded before calling utf8_unload() fs: unicode: Rename function names from utf8 to unicode fs: unicode: Rename utf8-core file to unicode-core fs/ext4/hash.c | 2 +- fs/ext4/namei.c | 12 ++--- fs/ext4/super.c | 8 +-- fs/f2fs/dir.c | 12 ++--- fs/f2fs/super.c | 11 ++-- fs/libfs.c | 6 +-- fs/unicode/Makefile | 2 +- fs/unicode/{utf8-core.c => unicode-core.c} | 62 +++++++++++----------- fs/unicode/utf8-selftest.c | 8 +-- include/linux/unicode.h | 32 +++++------ 10 files changed, 81 insertions(+), 74 deletions(-) rename fs/unicode/{utf8-core.c => unicode-core.c} (72%) -- 2.30.1