From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from huawei.com (szxga06-in.huawei.com [45.249.212.32]) by sourceware.org (Postfix) with ESMTPS id A53CC3858D38 for ; Sat, 22 Aug 2020 03:27:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A53CC3858D38 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=nixiaoming@huawei.com Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id D4BA2F83326DCF67E166; Sat, 22 Aug 2020 11:27:31 +0800 (CST) Received: from [127.0.0.1] (10.67.102.197) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.487.0; Sat, 22 Aug 2020 11:27:26 +0800 Subject: Re: ping//Re: [PATCH v2] io:nftw/ftw:fix stack overflow when large nopenfd [BZ #26353] To: Paul Eggert , References: <20200815070851.46403-1-nixiaoming@huawei.com> <8fa27d3a-f65c-ee0c-e665-7c4f4ace18e2@huawei.com> <9960d71b-28f0-bf9c-a854-df416363fabf@cs.ucla.edu> From: Xiaoming Ni Message-ID: <509977d1-35c7-d80a-c061-efb79a08b84f@huawei.com> Date: Sat, 22 Aug 2020 11:27:26 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.0.1 MIME-Version: 1.0 In-Reply-To: <9960d71b-28f0-bf9c-a854-df416363fabf@cs.ucla.edu> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.102.197] X-CFilter-Loop: Reflected X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2020 03:27:54 -0000 On 2020/8/22 10:51, Paul Eggert wrote: > On 8/21/20 7:23 PM, Xiaoming Ni wrote: >> -  data.dirstreams = (struct dir_data **) alloca (data.maxdir >> +  data.dirstreams = (struct dir_data **) malloc (data.maxdir >>                             * sizeof (struct dir_data *)); > > Surely this should call alloca unless data.maxdir is too large, as > malloc puts pressure on the heap. That's what's done elsewhere in glibc, > anyway. The user may run the setrlimit() or unlimit -s command to modify the stack space limit. When the user runs the ftw() command, the remaining stack space cannot be determined. How do I determine whether data.maxdir is too large for alloca? malloc puts pressure on the heap, cause ENOMEM but alloca puts pressure on the stack, cause stack overflow, Worse. Thanks Xiaoming Ni