This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: V3 [PATCH 03/24] x86: Support IBT and SHSTK in Intel CET [BZ #21598]
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 17 Jul 2018 22:53:04 +0000
- Subject: Re: V3 [PATCH 03/24] x86: Support IBT and SHSTK in Intel CET [BZ #21598]
- References: <CAMe9rOoaLoBTd27a1942BM538iZOcv48m2XoKdZeo34s-2c=8Q@mail.gmail.com> <f2adae90-39d9-6cbf-e29e-6f3283a80cf6@redhat.com>
On Mon, 16 Jul 2018, Carlos O'Donell wrote:
> This version is OK.
The documentation omissions need to be fixed for the release. I see no
install.texi update / INSTALL regeneration for the new configure option
and no NEWS update for the new feature and associated configure option.
It looks like there are new tunables added, at least according to the
commit message, which also need documenting in the glibc manual. In
general, any information from the commit message that is relevant to users
or builders of versions of glibc with this feature (as opposed to being
only information for developers of glibc, or ABI information that belongs
in an external ABI document, or only about the change rather than about
the feature as it exists after the change) needs to go in an appropriate
place in the manual, not just in the commit message.
At least the omission of documentation from some recent function additions
has the justification that none of the documentation for *at functions,
wherein it would need to go, exists at present. There is no such reason
for omitting documentation for configure options or tunables. I don't
think we want changes going in without documentation updates (in the
manual, NEWS etc., as appropriate) or a rationale for the absence of such
updates clearly specified in the commit message - and being in the freeze
period should make our standards for such things *higher*, not lower.
I'm also concerned that a large amount of complicated code added by this
change (or earlier CET changes) appears to have no execution tests (the
patch adds just one test, one that inspects object properties rather than
executing any of the affected code), so making it effectively
unmaintainable. I realise some would be covered by the normal testsuite,
at least for a --enable-cet build running on a CET-enabled processor and
kernel, and that some tests may only be effective on CET-enabled
processors and kernels that most people don't have yet. But I'd expect
there to be some execution tests for the various cases of mixed CET
properties in different executables and shared libraries, for example -
generically, each piece of CET support in glibc needs to be considered for
testability, and either have tests added, or be explained as tested
automatically for certain glibc build configurations, or be justified as
excessively hard to test.
In short, the code *present* in the patch may have been thoroughly
reviewed, but the unjustified *omissions* of documentation and testcases
mean I do not think it was ready to include in glibc or is appropriate to
include in a release unless those documentation and tests are added soon.
--
Joseph S. Myers
joseph@codesourcery.com