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;
MIME-Version: 1.0
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> <ZDy8Tcp9Z/GILVRI@mit.edu>
In-Reply-To: <ZDy8Tcp9Z/GILVRI@mit.edu>
From:   Will McVicker <willmcvicker@google.com>
Date:   Mon, 17 Apr 2023 09:16:49 -0700
Message-ID: <CABYd82ZX_HPrUONwNp+=A_zUa1m15PPnJcjO=BCsWZeVLVzf=Q@mail.gmail.com>
Subject: Re: simplify ext4_sb_read_encoding regression
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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Sun, Apr 16, 2023 at 8:26=E2=80=AFPM 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_requ=
est
> > > 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