linux-kernel - Re: [PATCH] ipc,shm: increase default size for shmmax

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]

Message-ID: <533B55AE.9090906@jp.fujitsu.com>
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/