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;
Date:   Sun, 16 Apr 2023 23:26:05 -0400
From:   "Theodore Ts'o" <tytso@mit.edu>
To:     Christoph Hellwig <hch@infradead.org>
Cc:     Christoph Hellwig <hch@lst.de>,
        William McVicker <willmcvicker@google.com>,
        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
Message-ID: <ZDy8Tcp9Z/GILVRI@mit.edu>
References: <CAFDdnB0a3mfcoY7rg5N4dO13qMeSsV+PkA2YHeerEOFRv8484Q@mail.gmail.com>
 <YpQixl+ljcC1VHNU@mit.edu>
 <CAFDdnB1WxrqddeLJwjsqqgoij1q_QGa=SBs-i=j31W2QbksJ=Q@mail.gmail.com>
 <YpVeeKRH1bycP7P1@mit.edu>
 <YpVxYchs1wScNRDw@mit.edu>
 <CAFDdnB1KJVSXXzXKOc+T+g1Qewr11AS4f9tFJqSMLvfpiX-5Lg@mail.gmail.com>
 <YpjNf8WGfYh31F+2@mit.edu>
 <ZDnbW1qYmBLycefL@google.com>
 <20230416054742.GA5427@lst.de>
 <ZDuOB8We29IAYR/4@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZDuOB8We29IAYR/4@infradead.org>
Precedence: bulk

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