Are syconf(_SC_XXX) issues glibc or kernel issues?

[Jeffrey Walton]

Hi Everyone,

My apologies for asking. I'm seeing bug reports against both components.

Are syconf(_SC_XXX) issues glibc or kernel issues?

In my particular case, I'm getting an unexpected value from
_SC_LEVEL1_DCACHE_LINESIZE on PPC64. AIX and SC_L1C_DLS returns an
expected value.

Jeff

[Jason Duerstock]

Run strace against the binary. If the syscall returns the "correct"
value(s), then it's a glibc issue. If not, it's a kernel issue.

Post by Jeffrey Walton
Hi Everyone,
My apologies for asking. I'm seeing bug reports against both components.
Are syconf(_SC_XXX) issues glibc or kernel issues?
In my particular case, I'm getting an unexpected value from
_SC_LEVEL1_DCACHE_LINESIZE on PPC64. AIX and SC_L1C_DLS returns an
expected value.
Jeff

[Jeffrey Walton]

On Wed, Mar 21, 2018 at 12:38 PM, Jason Duerstock

Post by Jason Duerstock
Run strace against the binary. If the syscall returns the "correct"
value(s), then it's a glibc issue. If not, it's a kernel issue.

Thanks Jason.

If I _don't_ see a system call, then would that indicate it is
probably a glibc issue? That is, glibc provides the answer without
going to the kernel?

Jeff

Post by Jason Duerstock

Post by Jeffrey Walton
Hi Everyone,
My apologies for asking. I'm seeing bug reports against both components.
Are syconf(_SC_XXX) issues glibc or kernel issues?
In my particular case, I'm getting an unexpected value from
_SC_LEVEL1_DCACHE_LINESIZE on PPC64. AIX and SC_L1C_DLS returns an
expected value.
Jeff

[Jason Duerstock]

That would be my interpretation. See:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/posix/sysconf.c;h=8b74ad6184cc724b2291c35249021a059e331fcc;hb=HEAD#l1182

What value are you seeing returned?

Jason

Post by Jeffrey Walton
On Wed, Mar 21, 2018 at 12:38 PM, Jason Duerstock

Post by Jason Duerstock
Run strace against the binary. If the syscall returns the "correct"
value(s), then it's a glibc issue. If not, it's a kernel issue.

Thanks Jason.
If I _don't_ see a system call, then would that indicate it is
probably a glibc issue? That is, glibc provides the answer without
going to the kernel?
Jeff

Post by Jason Duerstock

Post by Jeffrey Walton
Hi Everyone,
My apologies for asking. I'm seeing bug reports against both components.
Are syconf(_SC_XXX) issues glibc or kernel issues?
In my particular case, I'm getting an unexpected value from
_SC_LEVEL1_DCACHE_LINESIZE on PPC64. AIX and SC_L1C_DLS returns an
expected value.
Jeff

[Jeffrey Walton]

On Wed, Mar 21, 2018 at 2:27 PM, Jason Duerstock

Post by Jason Duerstock
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/posix/sysconf.c;h=8b74ad6184cc724b2291c35249021a059e331fcc;hb=HEAD#l1182
What value are you seeing returned?

I'm seeing 0, which is incorrect. The L1 cache line size on the POWER
System S822 is 128, not 0.

The man pages don't discuss how to interpret a 0 return value.
Shouldn't -1 be returned with a ENOENT or ENOSYS or similar error set?

_POSIX_LEVEL1_DCACHE_LINESIZE is not defined. If I am parsing the man
page correctly, then _SC_LEVEL1_DCACHE_LINESIZE is a runtime test. A
value of -1 means it is unsupported.

A lot of code is written like this, which is incorrect for the new return value:

if ((cacheLineSize = sysconf(_SC_LEVEL1_DCACHE_LINESIZE)) < 0)
...

Some high integrity software, like Botan and Crypto++, use the cache
line size to coerce cache evictions to harden against some timing
attacks. Returning 0 may have really bad consequences.

Jeff

[Tulio Magno Quites Machado Filho]

Post by Jeffrey Walton
Hi Everyone,

Hi,

Post by Jeffrey Walton
My apologies for asking. I'm seeing bug reports against both components.
Are syconf(_SC_XXX) issues glibc or kernel issues?

I need more information to answer you.

What does the following command return?
LD_SHOW_AUXV=1 /bin/true

Which glibc version are you using?
Which kernel version are you using?