Received: by 2002:a05:6358:53a8:b0:117:f937:c515 with SMTP id z40csp2514333rwe; Sat, 15 Apr 2023 22:52:14 -0700 (PDT) X-Google-Smtp-Source: AKy350Zbo7AmRgENlTpwyZw+QqivKjAWNg9Ix4tW06OCy5LhbdJFS2zencZl09VHLUbcUHy90rAT X-Received: by 2002:a17:902:dacd:b0:1a6:d2a9:3fab with SMTP id q13-20020a170902dacd00b001a6d2a93fabmr397780plx.47.1681624334660; Sat, 15 Apr 2023 22:52:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681624334; cv=none; d=google.com; s=arc-20160816; b=bLc0KgRu7a1mArH7kx94204vn6wufaz8kUwyOadjJsrnXDNEqJrQ9rl8bBz6CPgkRu nLusdZbzvahyCOkn0LZWoNrv8QFEI7I8iiGr9ruzwNX+rjCY4a+fdfXYf21/oYw2mUBm qbP6TLk+YUd2m4vGJ96YUKWobyFqC/7qABQvr+cHoHw+zX+YcqCSewL8P3+2DoLXNq+S MIeTR9EEoA1NJCSb4KEbFKOX1+z+00zCegqAp8CjdCrJq44UOdXy+1O5BHMPnPS24eoG P8hxXRVaobgKL/c34HiY34J/uLuYF7+dUEJOHraUb5rI1v28NlFbsyCcTWuKBRvklDkZ 9gWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=wqsA7Z4mCJ97xISxuQiW3h0hDzqgcB3WV6K8pW5KJTE=; b=x/MXgZZVaFxJkFN+UPiW8IBggnu1tCthKHGJckO8aly+kLRf7ZETWqoCzMp5Ji8XX9 NJLAE9ShtOrUDnxBocjL+lIO8sBJJ3gQPIaOVKpemaYegBAcGOCTgorylGmicZOctf8c qEubEDI801ZuQVrwuVKtNzvIXcb4UlB9sUvhPTla5Uvs2hUSsppo8EKiS8KT9BO0GeQr T2JaLUm1Dg3DUsn+CBEWEvoJTAYaysWTui8Iq7QY1JsKddI39xWIZFTEzkrNL3pbOY5g hSi1zLODfcavLILA0H/1IMeiaQEhx9n0yPQ18YvSEqZ+HWGv8Gsc8s32UieaUjwxCDB/ KiIw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-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 q14-20020a170902b10e00b001a669006139si8378899plr.248.2023.04.15.22.51.52; Sat, 15 Apr 2023 22:52:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-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; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229472AbjDPFrs (ORCPT + 99 others); Sun, 16 Apr 2023 01:47:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38988 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229593AbjDPFrr (ORCPT ); Sun, 16 Apr 2023 01:47:47 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 71A922D79 for ; Sat, 15 Apr 2023 22:47:46 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id B7B1A67373; Sun, 16 Apr 2023 07:47:42 +0200 (CEST) Date: Sun, 16 Apr 2023 07:47:42 +0200 From: Christoph Hellwig To: William McVicker Cc: Theodore Ts'o , hch@lst.de, linux-ext4@vger.kernel.org, "Stephen E. Baker" , adilger.kernel@dilger.ca Subject: Re: simplify ext4_sb_read_encoding regression Message-ID: <20230416054742.GA5427@lst.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE 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-ext4@vger.kernel.org On Fri, Apr 14, 2023 at 04:01:47PM -0700, William McVicker wrote: > I believe I figured out what is going on here since I am hitting a similar > issue with CONFIG_UNICODE. If you take a look at the .config from Stephen's > message, you'll see that he sets: > > CONFIG_TRIM_UNUSED_KSYMS=y > CONFIG_UNUSED_KSYMS_WHITELIST="" > > When trimming is enabled, kbuild will strip all exported symbols that are not > listed in the whitelist. As a result, when utf8-core.c calls: > > um->tables = symbol_request(utf8_data_table); > > it will fail since `utf8_data_table` doesn't exist in the exported section of > the kernel symbol table. For me on Android, this leads to the userdata > partition failing to mount. To be clear, this happens when CONFIG_UNICODE=y. > > One question I have is -- Why are we using symbol_request()/symbol_put() when > `utf8_data_table` is exported? Why can't we directly reference the > `utf8_data_table` symbol? We could, but that would require to always include the huge utf8 case folding tables into the kernel. The idea here is that there is no sane way to move the utf8 handling code into a module that only gets used some times, because common file systems like ext4 call into it. But they only actually use the case folding for the very rare case of someone actually using the case insensitive file system feature, so we only load the module containing the table for that case. > If we need to use symbol_request() when CONFIG_UNICODE=m, then can we apply the > below patch to fix this when CONFIG_UNICODE=y? I have verified this works for > me with CONFIG_UNICODE=y and CONFIG_TRIM_UNUSED_KSYMS=y. We could do that, but it seems a bit ugly. What prevents symbol_request from working properly for this case in your setup?