Re: simplify ext4_sb_read_encoding regression

From: Will McVicker <willmcvicker@google.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Christoph Hellwig <hch@infradead.org>,
	Christoph Hellwig <hch@lst.de>,
	linux-ext4@vger.kernel.org,
	"Stephen E. Baker" <baker.stephen.e@gmail.com>,
	adilger.kernel@dilger.ca
Subject: Re: simplify ext4_sb_read_encoding regression
Date: Mon, 17 Apr 2023 09:16:49 -0700	[thread overview]
Message-ID: <CABYd82ZX_HPrUONwNp+=A_zUa1m15PPnJcjO=BCsWZeVLVzf=Q@mail.gmail.com> (raw)
In-Reply-To: <ZDy8Tcp9Z/GILVRI@mit.edu>

On Sun, Apr 16, 2023 at 8:26 PM Theodore Ts'o <tytso@mit.edu> wrote:
>
> On Sat, Apr 15, 2023 at 10:56:23PM -0700, Christoph Hellwig wrote:
> > On Sun, Apr 16, 2023 at 07:47:42AM +0200, Christoph Hellwig wrote:
> > > We could do that, but it seems a bit ugly.  What prevents symbol_request
> > > from working properly for this case in your setup?
> >
> > To anwer to myself - I guess we need something else than a plain
> > EXPORT_SYMBOL for everything that is used by
> > symbol_request.  Which would be a nice cleanly anyway - exports for
> > symbol_request aren't normal exports and should probably have a clear
> > marker just to stand out anyway.
>
> Agreed, that's the best/cleanest long-term solution.
>
> The short-term hack that William could use in the interim would be to
> simply configure CONFIG_UNUSED_KSYMS_WHITELIST to include
> 'utf8_data_table', which will solve his immediate problem without
> needing to maintain an out-of-tree patch in his kernel.
>
> Presumably, that's what the long-term solution would effectively do,
> except it would be automated as opposed to requiring people who use
> CONFIG_TRIM_UNUSED_KSYMS to have to do manually.  Note also that there
> are only a half-dozen or so such symbols in the Linux kernel today, so
> while we could and probably should automate it, it's not clear to me
> the number of use cases where CONFIG_TRIM_UNUSED_KSYMS is going to be
> relevant are very likely quite small.  (The only ones I can think of
> are the Android Generic Kernel Image and for enterprise Linux
> distributions.  And in both cases, I suspect those use cases will
> probably have a very large list of symbol added to the allow list, so
> adding those few extra symbols is probably going to be in the noise.
>
>                                                 - Ted

Thanks for the responses! I was missing the part that utf8-core.c is always
built into the kernel when CONFIG_UNICODE is enabled. So it makes sense
to me why we need to use symbol_request() vs just EXPORT_SYMBOL. It
should be fine for us to include this symbol in our symbol list.

Thanks,
Will