linux-kernel - restrict initial stack space expansion to rlimit

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-next>] [day] [month] [year] [list]

Date:	Thu, 04 Mar 2010 10:22:40 +0100
From:	Paweł Sikora <pawel.sikora@...k.net>
To:	linux-kernel@...r.kernel.org
Cc:	mikey@...ling.org
Subject: restrict initial stack space expansion to rlimit - the process
 killer...

Hi all,

i'm currently testing the 2.6.32.9 and observing random process killing
on my builder machine (x86-64) which contains several tcl/bash
scripts for svn checkout, compilation, archive and ftp deploying.

here's a fragment of build log:

(...)
[CXX] obj-release-i486-gnu-linux/genMappingRst.o
[CXX] obj-release-i486-gnu-linux/otelloVerdiThread.o
i486-gnu-linux-g++: Internal error: Killed (program as)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[1]: *** [obj-release-i486-gnu-linux/genMappingRst.o] Error 1

the builder process tree looks like this:

$ pstree -Acl
?---screen-+-bash---loop.sh-+-loop.sh---tclsh8.4---temp_9_12676174---tclsh8.4---temp_3_12676174---tclsh8.4---temp_4_12676174---tclsh8.4---temp_9_12676176---make---make-+-sh---ccache---x86_64-gnu-linu-+-as
              |
|
|                               `-cc1plus
              |
|
`-sh---ccache---x86_64-gnu-linu-+-as
              |
|
`-cc1plus
              |                `-tee
              `-bash---pstree

as you can see there're few levels of bash and tclsh(8.4)
and make/ccache/binutils/g++ workers at the bottom.

i've noticed that rolling back to the 2.6.32.8 (or just reverting
the 'ulimit -s' commit: 35e2093d5d7b632c083af3578c05876375828314)
fixes the problem.

so, is it my stack ulimit (8192) to small, or maybe the new limit
calculations are wrong? shoud i bump the stack limit for new kernels?

please CC me on reply.

BR,
Pawel.
--
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/