public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "long.wanglong" <long.wanglong@huawei.com>
To: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	Wang Kai <morgan.wang@huawei.com>,
	peifeiyue <peifeiyue@huawei.com>
Subject: Re: [RFC] kernel random segmentation fault?
Date: Wed, 6 May 2015 17:22:52 +0800	[thread overview]
Message-ID: <5549DD6C.40806@huawei.com> (raw)
In-Reply-To: <0b8a01d087d5$7d3a9740$77afc5c0$@alibaba-inc.com>

On 2015/5/6 16:20, Hillf Danton wrote:
>>
>> Hi all:
>>
>> I meet a kernel problem about the random segmentation fault(x86_64). In my testcase, the size of local variables exceeds 20MB.
>> when run the testcase, it will cause segmentation fault(because the default stack size limit is 8192KB).
>> when I increase the stack size limit to 1024000KB(ulimit -s 1024000), the testcase will pass.
>>
>> But when I run the testcase 100 times, it will cause random segmentation fault.
>>
>> Maybe the commit fee7e49d45149fba60156f5b59014f764d3e3728  "mm: propagate error from stack expansion even for guard page"
>> cause this problems, when I revert it, the testcase will not cause random segmentation fault problem.
>>
>> Can anyone give some ideas about this problem?
>>
>> Best Regards
>> Wang Long
>>
>> ############ Test Environment #############
>>
>> # uname -a
>> Linux ivybridge 4.1.0-rc2+ #3 SMP PREEMPT Wed May 6 10:46:57 CST 2015 x86_64 x86_64 x86_64 GNU/Linux
>>
>>
>> ############  The Testcase ################
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include <sys/resource.h>
>>
>> #define KB *1024
>> #define MB *(1024*1024)
>> #define GB *(1024*1024*1024)
>>
>> int main(int argc, char** argv)
>> {
>>     int ret;
>>     struct rlimit rlim;
>>
>>     rlim.rlim_cur=20 MB;
>>     rlim.rlim_max=20 MB;
> 
> Can you please get rlimit before setting it?
> And try again without reverting fee7e49d45?
>

Hi,Hillf Danton

After add getrlimit function before setting it. the testcase will not cause
random segmentation fault problem.

Could you please explain why? Are there any special considerations when we
use setrlimit and getrlimit functions?

Best Regards
Wang Long

>>     ret = setrlimit(RLIMIT_AS, &rlim);
>>     if ( 0 > ret)
>>     {
>>         perror("setrlimit failed");
>>         exit(1);
>>     }
>>
>>     printf("setrlimit success\n");
>>
>>     char tmp[20 MB];
>>     int i = 0;
>>
>>     for (i = 0; i < 20 MB; i++)
>>     {
>>         tmp[i]=1;
>>     }
>>
>>     printf("test success\n");
>>     exit(1);
>> }
>>
> 
> 
> 



  reply	other threads:[~2015-05-06  9:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <0b8901d087d4$eafcd8c0$c0f68a40$@alibaba-inc.com>
2015-05-06  8:20 ` [RFC] kernel random segmentation fault? Hillf Danton
2015-05-06  9:22   ` long.wanglong [this message]
     [not found] <1430882810-225406-1-git-send-email-long.wanglong@huawei.com>
2015-05-06  3:46 ` long.wanglong
2015-05-06 10:57   ` Jan Engelhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5549DD6C.40806@huawei.com \
    --to=long.wanglong@huawei.com \
    --cc=hillf.zj@alibaba-inc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=morgan.wang@huawei.com \
    --cc=peifeiyue@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox