[PATCH] dcache: Define DNAME_INLINE_LEN as a number directly

[PATCH] dcache: Define DNAME_INLINE_LEN as a number directly

[Tiezhu Yang]

When executing the bcc script, there exists the following error
on LoongArch and x86_64:

Traceback (most recent call last):
  File "/usr/share/bcc/tools/filetop", line 218, in <module>
    counts = b.get_table("counts")
  File "/usr/lib/python3.13/site-packages/bcc-0.34.0+a434ee50-py3.13.egg/bcc/__init__.py", line 658, in get_table
    keytype = BPF._decode_table_type(json.loads(key_desc))
                                     ~~~~~~~~~~^^^^^^^^^^
  File "/usr/lib64/python3.13/json/__init__.py", line 346, in loads
    return _default_decoder.decode(s)
           ~~~~~~~~~~~~~~~~~~~~~~~^^^
  File "/usr/lib64/python3.13/json/decoder.py", line 345, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
               ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.13/json/decoder.py", line 361, in raw_decode
    obj, end = self.scan_once(s, idx)
               ~~~~~~~~~~~~~~^^^^^^^^
json.decoder.JSONDecodeError: Expecting ',' delimiter: line 1 column 179 (char 178)

Here is the related definition in tools/filetop.py of bcc:

// the key for the output summary
struct info_t {
    unsigned long inode;
    dev_t dev;
    dev_t rdev;
    u32 pid;
    u32 name_len;
    char comm[TASK_COMM_LEN];
    // de->d_name.name may point to de->d_iname so limit len accordingly
    char name[DNAME_INLINE_LEN];
    char type;
};

Here is the output of print(key_desc) in src/python/bcc/__init__.py
of bcc, there is a missing ',' between "char" and "unsigned long" at
column 179 for the "name" member.

["info_t", [["inode","unsigned long"], ["dev","unsigned int"], ["rdev","unsigned int"], ["pid","unsigned int"], ["name_len","unsigned int"], ["comm","char", [16]], ["name","char""unsigned long", [40]], ["type","char"], ["__pad_end","char",[7]] ], "struct_packed"]

In order to avoid such issues, define DNAME_INLINE_LEN as a number
directly, there is only "char" and no "unsigned long" at column 179
for the "name" member with this patch.

["info_t", [["inode","unsigned long"], ["dev","unsigned int"], ["rdev","unsigned int"], ["pid","unsigned int"], ["name_len","unsigned int"], ["comm","char", [16]], ["name","char", [40]], ["type","char"], ["__pad_end","char",[7]] ], "struct_packed"]

How to reproduce:

git clone https://github.com/iovisor/bcc.git
mkdir bcc/build; cd bcc/build
cmake ..
make
sudo make install
sudo /usr/share/bcc/tools/filetop

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
 include/linux/dcache.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/linux/dcache.h b/include/linux/dcache.h
index e9f07e37dd6f..08e91738e3de 100644
--- a/include/linux/dcache.h
+++ b/include/linux/dcache.h
@@ -70,15 +70,17 @@ extern const struct qstr dotdot_name;
  */
 #ifdef CONFIG_64BIT
 # define DNAME_INLINE_WORDS 5 /* 192 bytes */
+# define DNAME_INLINE_LEN 40
 #else
 # ifdef CONFIG_SMP
 #  define DNAME_INLINE_WORDS 9 /* 128 bytes */
+#  define DNAME_INLINE_LEN 36
 # else
 #  define DNAME_INLINE_WORDS 11 /* 128 bytes */
+#  define DNAME_INLINE_LEN 44
 # endif
 #endif
 
-#define DNAME_INLINE_LEN (DNAME_INLINE_WORDS*sizeof(unsigned long))
 
 union shortname_store {
 	unsigned char string[DNAME_INLINE_LEN];
-- 
2.42.0

Re: [PATCH] dcache: Define DNAME_INLINE_LEN as a number directly

[Al Viro]

On Tue, May 20, 2025 at 02:47:07PM +0800, Tiezhu Yang wrote:
> When executing the bcc script, there exists the following error
> on LoongArch and x86_64:

NOTABUG.  You can't require array sizes to contain no arithmetics,
including sizeof().  Well, you can, but don't expect your requests
to be satisfied.

> How to reproduce:
> 
> git clone https://github.com/iovisor/bcc.git
> mkdir bcc/build; cd bcc/build
> cmake ..
> make
> sudo make install
> sudo /usr/share/bcc/tools/filetop

So fix the script.  Or report it to whoever wrote it, if it's
not yours.

I'm sorry, but we are NOT going to accomodate random parsers
poking inside the kernel-internal headers and failing to
actually parse the language they are written in.

If you want to exfiltrate a constant, do what e.g. asm-offsets is
doing.  Take a look at e.g.  arch/loongarch/kernel/asm-offsets.c
and check what ends up in include/generated/asm-offsets.h - the
latter is entirely produced out of the former.

The trick is to have inline asm that would spew a recognizable
line when compiled into assembler, with the value(s) you want
substituted into it.  See include/linux/kbuild.h for the macros.

Then you pick these lines out of generated your_file.s - no need
to use python, sed(1) will do just fine.  See filechk_offsets in
scripts/Makefile.lib for that part.

Re: [PATCH] dcache: Define DNAME_INLINE_LEN as a number directly

[Alexei Starovoitov]

On Tue, May 20, 2025 at 1:23 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Tue, May 20, 2025 at 02:47:07PM +0800, Tiezhu Yang wrote:
> > When executing the bcc script, there exists the following error
> > on LoongArch and x86_64:
>
> NOTABUG.  You can't require array sizes to contain no arithmetics,
> including sizeof().  Well, you can, but don't expect your requests
> to be satisfied.
>
> > How to reproduce:
> >
> > git clone https://github.com/iovisor/bcc.git
> > mkdir bcc/build; cd bcc/build
> > cmake ..
> > make
> > sudo make install
> > sudo /usr/share/bcc/tools/filetop
>
> So fix the script.  Or report it to whoever wrote it, if it's
> not yours.

+1

> I'm sorry, but we are NOT going to accomodate random parsers
> poking inside the kernel-internal headers and failing to
> actually parse the language they are written in.
>
> If you want to exfiltrate a constant, do what e.g. asm-offsets is
> doing.  Take a look at e.g.  arch/loongarch/kernel/asm-offsets.c
> and check what ends up in include/generated/asm-offsets.h - the
> latter is entirely produced out of the former.
>
> The trick is to have inline asm that would spew a recognizable
> line when compiled into assembler, with the value(s) you want
> substituted into it.  See include/linux/kbuild.h for the macros.
>
> Then you pick these lines out of generated your_file.s - no need
> to use python, sed(1) will do just fine.  See filechk_offsets in
> scripts/Makefile.lib for that part.

None of it is necessary.

Tiezhu,

bcc's tools/filetop.py is really old and obsolete.
It's not worth fixing. I'd delete it.
Use bcc's libbpf-tools/filetop instead.

Re: [PATCH] dcache: Define DNAME_INLINE_LEN as a number directly

[Yonghong Song]

On 5/20/25 1:04 AM, Alexei Starovoitov wrote:
> On Tue, May 20, 2025 at 1:23 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
>> On Tue, May 20, 2025 at 02:47:07PM +0800, Tiezhu Yang wrote:
>>> When executing the bcc script, there exists the following error
>>> on LoongArch and x86_64:
>> NOTABUG.  You can't require array sizes to contain no arithmetics,
>> including sizeof().  Well, you can, but don't expect your requests
>> to be satisfied.
>>
>>> How to reproduce:
>>>
>>> git clone https://github.com/iovisor/bcc.git
>>> mkdir bcc/build; cd bcc/build
>>> cmake ..
>>> make
>>> sudo make install
>>> sudo /usr/share/bcc/tools/filetop
>> So fix the script.  Or report it to whoever wrote it, if it's
>> not yours.
> +1
>
>> I'm sorry, but we are NOT going to accomodate random parsers
>> poking inside the kernel-internal headers and failing to
>> actually parse the language they are written in.
>>
>> If you want to exfiltrate a constant, do what e.g. asm-offsets is
>> doing.  Take a look at e.g.  arch/loongarch/kernel/asm-offsets.c
>> and check what ends up in include/generated/asm-offsets.h - the
>> latter is entirely produced out of the former.
>>
>> The trick is to have inline asm that would spew a recognizable
>> line when compiled into assembler, with the value(s) you want
>> substituted into it.  See include/linux/kbuild.h for the macros.
>>
>> Then you pick these lines out of generated your_file.s - no need
>> to use python, sed(1) will do just fine.  See filechk_offsets in
>> scripts/Makefile.lib for that part.
> None of it is necessary.
>
> Tiezhu,
>
> bcc's tools/filetop.py is really old and obsolete.
> It's not worth fixing. I'd delete it.
> Use bcc's libbpf-tools/filetop instead.

Tiezhu, please check whether libbpf-tools/filetop satisfied your need or 
not. Thanks!

Re: [PATCH] dcache: Define DNAME_INLINE_LEN as a number directly

[Tiezhu Yang]

On 05/21/2025 02:26 AM, Yonghong Song wrote:
>
>
> On 5/20/25 1:04 AM, Alexei Starovoitov wrote:
>> On Tue, May 20, 2025 at 1:23 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
>>> On Tue, May 20, 2025 at 02:47:07PM +0800, Tiezhu Yang wrote:
>>>> When executing the bcc script, there exists the following error
>>>> on LoongArch and x86_64:
>>> NOTABUG.  You can't require array sizes to contain no arithmetics,
>>> including sizeof().  Well, you can, but don't expect your requests
>>> to be satisfied.
>>>
>>>> How to reproduce:
>>>>
>>>> git clone https://github.com/iovisor/bcc.git
>>>> mkdir bcc/build; cd bcc/build
>>>> cmake ..
>>>> make
>>>> sudo make install
>>>> sudo /usr/share/bcc/tools/filetop
>>> So fix the script.  Or report it to whoever wrote it, if it's
>>> not yours.
>> +1
>>
>>> I'm sorry, but we are NOT going to accomodate random parsers
>>> poking inside the kernel-internal headers and failing to
>>> actually parse the language they are written in.
>>>
>>> If you want to exfiltrate a constant, do what e.g. asm-offsets is
>>> doing.  Take a look at e.g.  arch/loongarch/kernel/asm-offsets.c
>>> and check what ends up in include/generated/asm-offsets.h - the
>>> latter is entirely produced out of the former.
>>>
>>> The trick is to have inline asm that would spew a recognizable
>>> line when compiled into assembler, with the value(s) you want
>>> substituted into it.  See include/linux/kbuild.h for the macros.
>>>
>>> Then you pick these lines out of generated your_file.s - no need
>>> to use python, sed(1) will do just fine.  See filechk_offsets in
>>> scripts/Makefile.lib for that part.
>> None of it is necessary.
>>
>> Tiezhu,
>>
>> bcc's tools/filetop.py is really old and obsolete.
>> It's not worth fixing. I'd delete it.
>> Use bcc's libbpf-tools/filetop instead.
>
> Tiezhu, please check whether libbpf-tools/filetop satisfied your need or
> not. Thanks!

Yes, it works well for me.