lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 02 Apr 2014 09:11:26 +0900
From:	Kamezawa Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Andrew Morton <akpm@...ux-foundation.org>
CC:	Davidlohr Bueso <davidlohr@...com>,
	Manfred Spraul <manfred@...orfullife.com>, aswin@...com,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"Gotou, Yasunori" <y-goto@...fujitsu.com>,
	chenhanxiao <chenhanxiao@...fujitsu.com>,
	Gao feng <gaofeng@...fujitsu.com>
Subject: Re: [PATCH] ipc,shm: increase default size for shmmax

(2014/04/02 5:15), KOSAKI Motohiro wrote:
>>> Our middleware engineers has been complaining about this sysctl limit.
>>> System administrator need to calculate required sysctl value by making sum
>>> of all planned middlewares, and middleware provider needs to write "please
>>> calculate systcl param by....." in their installation manuals.
>>
>> Why aren't people just setting the sysctl to a petabyte?  What problems
>> would that lead to?
>
> I don't have much Fujitsu middleware knowledges. But I'd like to explain
> very funny bug I saw.
>
> 1. middleware-A suggest to set SHMMAX to very large value (maybe
> LONG_MAX, but my memory was flushed)
> 2. middleware-B suggest to set SHMMAX to increase some dozen mega byte.
>
> Finally, it was overflow and didn't work at all.
>
> Let's demonstrate.
>
> # echo 18446744073709551615 > /proc/sys/kernel/shmmax
> # cat /proc/sys/kernel/shmmax
> 18446744073709551615
> # echo 18446744073709551616 > /proc/sys/kernel/shmmax
> # cat /proc/sys/kernel/shmmax
> 0
>
> That's why many open source software continue the silly game. But
> again, I don't have knowledge about Fujitsu middleware. I'm waiting
> kamezawa-san's answer.
>

Nowadays, Middleware/application are required to be installed automatically without
any admin's operations. But the shmmax tends to be a value which admin needs to modify
by hand after installation. This is not the last one problem, but it is.

I says MW engineers "you, middleware/application, can modify it automatically
as you needed, there will be no pain".

But they tend not to do it. (in my guess) in application writer's way on thinking..
   - If there is a limit by OS, it should have some meaning.
     There may be an unknown, os internal reason which the system admin need to check it.
     For example, os will consume more resource when shmmax is enlarged.
   - If there is a limit by OS, it should be modified by admin.

I guess customer thinks so, too. There is no official information "increasing shmmax
will not cunsume any resource and will not cause any problem in the kernel inside."

Then, admins need to set it. Middleware needs to write "please modify the sysctl
value based on this calculation....." in their manual.

I think the worst problem about this "limit" is that it's hard to explain "why this limit
exists". I need to answer "I guess it's just legacy, hehe...."

Thanks,
-Kame

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ