From: Kris Van Hees <kris.van.hees@oracle.com>
To: Eugene Loh <eugene.loh@oracle.com>, Nick Alcock <nick.alcock@oracle.com>
Cc: dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [PATCH 4/4] test: Do not depend on ext4
Date: Wed, 27 Nov 2024 11:51:47 -0500 [thread overview]
Message-ID: <Z0dOI9eQui1v5wDR@oracle.com> (raw)
In-Reply-To: <9c8bfb58-6d34-07d8-243b-691fc62df38f@oracle.com>
Resend to the list for Nick
On Wed, Oct 30, 2024 at 04:14:54PM -0400, Eugene Loh wrote:
> E.g.,
> $ uname -r
> 5.15.0-205.149.5.1.el9uek.aarch64
> $ sudo grep ext4_dir_operations /proc/kallmodsyms
> ffffc45a59d9ee88 100 D ext4_dir_operations
> $ sudo awk '/ext4/ { print NF }' /proc/kallmodsyms | uniq -c
> 2342 4
> $ sudo grep -w ext4 /proc/kallmodsyms
>
> So, lots of ext4 symbols (including ext4_dir_operations) but none of them
> are [ext4]. Bug in... kallmodsyms?
>
> On 10/25/24 17:16, Kris Van Hees wrote:
> > I am not too sure about this patch... We are not using kallmodsyms anymore
> > for newer kernels, and on older kernels that symbol certainly be listed as
> > [ext4]. So, if ext4_dir_operations *is* in the ext4 module code (compiled in
> > or loadable), then the proper ref to it would be ext4`ext4_dir_operations.
> > So the test should be able to use that - if not, that seems like a bug rather
> > than something to change in the test?
> >
> > On Fri, Oct 04, 2024 at 12:43:55AM -0400, eugene.loh@oracle.com wrote:
> > > From: Eugene Loh <eugene.loh@oracle.com>
> > >
> > > It is possible that there is no ext4 module, whether built-in or otherwise,
> > > even if its symbols are present. E.g.,
> > > # grep ext4_dir_operations /proc/kallmodsyms
> > > ffffc45a59d9ee88 100 D ext4_dir_operations
> > > # grep -w ext4 /proc/kallmodsyms
> > > #
> > >
> > > Meanwhile, in
> > > ab883bae "tests, io, scalars: use kallsyms instead of kallmodsyms where possible"
> > > we read:
> > > scalars/tst.misc.x needs adjusting to check for the presence of the actual
> > > symbols we are looking up, since the modules might well be built-in, and
> > > thus not show up in /proc/kallsyms.
> > >
> > > With that patch, in test/unittest/scalars/tst.misc.x, we check:
> > > -if ! $(grep -qw ext4 /proc/kallmodsyms); then
> > > +if ! grep -qw ext4_dir_operations /proc/kallsyms; then
> > > exit 1
> > > fi
> > >
> > > So it is possible for us to find
> > > `ext4_dir_operations
> > > but not
> > > ext4`ext4_dir_operations
> > >
> > > Change the .d script to look simply for `ext4_dir_operations.
> > >
> > > Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> > > ---
> > > test/unittest/scalars/tst.misc.d | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/test/unittest/scalars/tst.misc.d b/test/unittest/scalars/tst.misc.d
> > > index 60edab45e..6a5f4ae2e 100644
> > > --- a/test/unittest/scalars/tst.misc.d
> > > +++ b/test/unittest/scalars/tst.misc.d
> > > @@ -20,7 +20,7 @@
> > > BEGIN
> > > {
> > > printf("\nr_cpu_ids = 0x%x\n", `nr_cpu_ids);
> > > - printf("ext4`ext4_dir_operations = %p\n", &ext4`ext4_dir_operations);
> > > + printf("ext4`ext4_dir_operations = %p\n", &`ext4_dir_operations);
> > > printf("isofs`isofs_dir_operations = %p\n", &isofs`isofs_dir_operations);
> > > printf("vmlinux`major_names = %p\n", &vmlinux`major_names);
> > > x = 123;
> > > --
> > > 2.43.5
> > >
next prev parent reply other threads:[~2024-11-27 16:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-04 4:43 [PATCH 1/4] Tweak self-armouring eugene.loh
2024-10-04 4:43 ` [PATCH 2/4] test: Increase timeout due to long shutdown eugene.loh
2024-10-25 21:05 ` Kris Van Hees
2024-10-04 4:43 ` [PATCH 3/4] test: Do not return 1 for err.*.x checks eugene.loh
2024-10-25 21:09 ` Kris Van Hees
2024-10-04 4:43 ` [PATCH 4/4] test: Do not depend on ext4 eugene.loh
2024-10-25 21:16 ` Kris Van Hees
2024-10-30 20:14 ` Eugene Loh
2024-11-27 16:51 ` Kris Van Hees [this message]
2025-09-14 11:18 ` Nick Alcock
2025-09-15 17:39 ` [DTrace-devel] " Kris Van Hees
2024-10-25 21:02 ` [PATCH 1/4] Tweak self-armouring Kris Van Hees
2024-11-29 13:57 ` [DTrace-devel] " Nick Alcock
2024-12-03 11:46 ` Nick Alcock
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z0dOI9eQui1v5wDR@oracle.com \
--to=kris.van.hees@oracle.com \
--cc=dtrace-devel@oss.oracle.com \
--cc=dtrace@lists.linux.dev \
--cc=eugene.loh@oracle.com \
--cc=nick.alcock@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.