* Regression test failure - tests/ts/ipcs/limits2
@ 2014-08-18 22:19 Bruce Dubbs
2014-08-19 6:09 ` Sami Kerola
0 siblings, 1 reply; 5+ messages in thread
From: Bruce Dubbs @ 2014-08-18 22:19 UTC (permalink / raw)
To: util-linux
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Regression test failure - tests/ts/ipcs/limits2
2014-08-18 22:19 Regression test failure - tests/ts/ipcs/limits2 Bruce Dubbs
@ 2014-08-19 6:09 ` Sami Kerola
2014-08-19 9:18 ` Ruediger Meier
0 siblings, 1 reply; 5+ messages in thread
From: Sami Kerola @ 2014-08-19 6:09 UTC (permalink / raw)
To: Bruce Dubbs; +Cc: util-linux
On 18 August 2014 23:19, Bruce Dubbs <bruce.dubbs@gmail.com> wrote:
> 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?
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
--
Sami Kerola
http://www.iki.fi/kerolasa/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Regression test failure - tests/ts/ipcs/limits2
2014-08-19 6:09 ` Sami Kerola
@ 2014-08-19 9:18 ` Ruediger Meier
2014-08-20 11:40 ` Sami Kerola
0 siblings, 1 reply; 5+ messages in thread
From: Ruediger Meier @ 2014-08-19 9:18 UTC (permalink / raw)
To: kerolasa; +Cc: Bruce Dubbs, util-linux
On Tuesday 19 August 2014, Sami Kerola wrote:
> On 18 August 2014 23:19, Bruce Dubbs <bruce.dubbs@gmail.com> wrote:
> > 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?
>
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Regression test failure - tests/ts/ipcs/limits2
2014-08-19 9:18 ` Ruediger Meier
@ 2014-08-20 11:40 ` Sami Kerola
2014-08-26 15:09 ` Ruediger Meier
0 siblings, 1 reply; 5+ messages in thread
From: Sami Kerola @ 2014-08-20 11:40 UTC (permalink / raw)
To: Ruediger Meier; +Cc: Bruce Dubbs, util-linux
On 19 August 2014 12:18, Ruediger Meier <sweet_f_a@gmx.de> wrote:
> 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/
--
Sami Kerola
http://www.iki.fi/kerolasa/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Regression test failure - tests/ts/ipcs/limits2
2014-08-20 11:40 ` Sami Kerola
@ 2014-08-26 15:09 ` Ruediger Meier
0 siblings, 0 replies; 5+ messages in thread
From: Ruediger Meier @ 2014-08-26 15:09 UTC (permalink / raw)
To: kerolasa; +Cc: util-linux, Karel Zak
On Wednesday 20 August 2014, Sami Kerola wrote:
> On 19 August 2014 12:18, Ruediger Meier <sweet_f_a@gmx.de> wrote:
> > 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?
@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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-08-26 15:09 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-08-18 22:19 Regression test failure - tests/ts/ipcs/limits2 Bruce Dubbs
2014-08-19 6:09 ` Sami Kerola
2014-08-19 9:18 ` Ruediger Meier
2014-08-20 11:40 ` Sami Kerola
2014-08-26 15:09 ` Ruediger Meier
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.