From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Stancek Date: Mon, 17 Jul 2017 05:43:19 -0400 (EDT) Subject: [LTP] [PATCH] syscalls/setrlimit: add setrlimit04 In-Reply-To: References: <1008257811.53320687.1500274229249.JavaMail.zimbra@redhat.com> Message-ID: <1856940022.53375066.1500284599278.JavaMail.zimbra@redhat.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ltp@lists.linux.it ----- Original Message ----- > On Mon, Jul 17, 2017 at 2:50 PM, Jan Stancek wrote: > > > > > > ----- Original Message ----- > >> On Fri, Jul 14, 2017 at 7:12 PM, Jan Stancek wrote: > >> > Early patches for stack guard gap caused that gap size was contributing > >> > towards stack limit. This caused failures for new processes (E2BIG) when > >> > ulimit was set to anything lower than size of gap. > > ... > >> > +static struct tst_test test = { > >> > + .test_all = test_setrlimit, > >> > + .forks_child = 1, > >> > + .needs_root = 1, > >> > >> seems we need to filter out the suitable kernel: > >> > >> .min_kver = "4.12.0", > > > > Why, shouldn't this work on any kernel version? > > My bad. The "Early patches" has been reverted. I mistook this issue in > versions. > > You are right. please ignore my comments in last mail. :) > > > Another question come to my mind is that, if a system reboot with > kernel parameter "stack_guard_gap=xxx", this case setrlimit04 still > runs well and getting PASS, right? Yes. On side note, I also want a testcase in LTP where we on purpose keep expanding stack until it hits existing mapping.