Skip to contentSkip to conversation

Regression test failure - tests/ts/ipcs/limits2

DISCUSSION Bruce Dubbs 3 participants 5 messages Aug 18, 2014 – Aug 26, 2014 Util-Linux package

lore
Share & tools
lore
#0 lore raw

When testing util-linux-2.25, I was suprised to get a test failure. Running it down, I found tests/ts/ipcs/limits2 is doing:

if [ $(</proc/sys/kernel/shmall) -ge $(bc <<<"2^64 / $PAGE_SIZE") ];

The problem is that starting with the 3.16 kernel the shmall value is 18446744073692774399 which is the max value of an unsigned long on a 64-bit system (UINT64_MAX). Bash doesn't like this value and says:

"18446744073692774399: integer expression expected"

I can work around this by setting shmall before running the test, but there is a problem with either the test or in the kernel.

I note that the kernel's shmmax value is also set to UINT64_MAX.

What's the best way to approach this?

-- Bruce Dubbs
linuxfromscratch.org

#1 lore raw
Quoted 9 lines · Bruce Dubbs

When testing util-linux-2.25, I was suprised to get a test failure. Running it down, I found tests/ts/ipcs/limits2 is doing:

if [ $(</proc/sys/kernel/shmall) -ge $(bc <<<"2^64 / $PAGE_SIZE") ];

The problem is that starting with the 3.16 kernel the shmall value is 18446744073692774399 which is the max value of an unsigned long on a 64-bit system (UINT64_MAX). Bash doesn't like this value and says:

Quoted 8 lines

"18446744073692774399: integer expression expected"

I can work around this by setting shmall before running the test, but there is a problem with either the test or in the kernel.

I note that the kernel's shmmax value is also set to UINT64_MAX.

What's the best way to approach this?

Hi Bruce,

I found the same. The best way is to pull the most recent code from upstream git, and test it is no longer affected.

https://github.com/karelzak/util-linux/commit/3a9ec12d6664527fad9c56347c88f3447d6c0856

Signature · 2 lines
Sami Kerola
http://www.iki.fi/kerolasa/
#2 lore raw
Quoted 21 lines · Sami Kerola
Quoted 11 lines · Bruce Dubbs

When testing util-linux-2.25, I was suprised to get a test failure. Running it down, I found tests/ts/ipcs/limits2 is doing:

if [ $(</proc/sys/kernel/shmall) -ge $(bc <<<"2^64 / $PAGE_SIZE") ];

The problem is that starting with the 3.16 kernel the shmall value is 18446744073692774399 which is the max value of an unsigned long on a 64-bit system (UINT64_MAX). Bash doesn't like this value and says:

Quoted 8 lines

"18446744073692774399: integer expression expected"

I can work around this by setting shmall before running the test, but there is a problem with either the test or in the kernel.

I note that the kernel's shmmax value is also set to UINT64_MAX.

What's the best way to approach this?

Quoted 7 lines

Hi Bruce,

I found the same. The best way is to pull the most recent code from upstream git, and test it is no longer affected.

https://github.com/karelzak/util-linux/commit/3a9ec12d6664527fad9c563
47c88f3447d6c0856

BTW, woud be nice to fix that TODO finally. Since "ipcs -m" internally converts all these sizes to bytes we have to use large integer arithmetics somehow to have correct output at all.

cu,
Rudi

#3 lore raw
Quoted 3 lines · Ruediger Meier

BTW, woud be nice to fix that TODO finally. Since "ipcs -m" internally converts all these sizes to bytes we have to use large integer arithmetics somehow to have correct output at all.

Hi Rudi and others,

I agree, it would be nice to be precise about sizes. But should util-linux have a lib/bigint.c or something similar to avoid dependency to external infinite precision implementation[1]?

By glance there are some examples how to write bigint from scratch. And the examples are more or less directly advising against re-inventing the wheel. My feeling is that use of existing bigint implementation would be good decision, but one has to be able to disable the dependency when needed. I am guessing distributors who bootstrap systems would prefer that sort of setup.

Comments, opinions?

[1] https://gmplib.org/

Signature · 2 lines
Sami Kerola
http://www.iki.fi/kerolasa/
#4 lore raw
Quoted 11 lines · Sami Kerola
Quoted 3 lines · Ruediger Meier

BTW, woud be nice to fix that TODO finally. Since "ipcs -m" internally converts all these sizes to bytes we have to use large integer arithmetics somehow to have correct output at all.

Hi Rudi and others,

I agree, it would be nice to be precise about sizes. But should util-linux have a lib/bigint.c or something similar to avoid dependency to external infinite precision implementation[1]?

Quoted 8 lines

By glance there are some examples how to write bigint from scratch. And the examples are more or less directly advising against re-inventing the wheel. My feeling is that use of existing bigint implementation would be good decision, but one has to be able to disable the dependency when needed. I am guessing distributors who bootstrap systems would prefer that sort of setup.

Comments, opinions?

@Karel
Maybe you could re-open the issue on github to not forget about it.
https://github.com/karelzak/util-linux/issues/51

cu,
Rudi