All of lore.kernel.org
 help / color / mirror / Atom feed
* 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.