From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <nixiaoming@huawei.com>
Received: from huawei.com (szxga04-in.huawei.com [45.249.212.190])
 by sourceware.org (Postfix) with ESMTPS id 3ACA23857011;
 Sat,  8 Aug 2020 08:54:57 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3ACA23857011
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 DGGEMS409-HUB.china.huawei.com (unknown [172.30.72.58])
 by Forcepoint Email with ESMTP id A500399064C12977A259;
 Sat,  8 Aug 2020 16:54:53 +0800 (CST)
Received: from [127.0.0.1] (10.67.102.197) by DGGEMS409-HUB.china.huawei.com
 (10.3.19.209) with Microsoft SMTP Server id 14.3.487.0; Sat, 8 Aug 2020
 16:54:42 +0800
Subject: Re: [PATCH v2] stdlib: realpath use malloc replace __alloca to reduce
 stack overflow risks [BZ #26341]
To: Paul Eggert <eggert@cs.ucla.edu>, <libc-alpha@sourceware.org>,
 <glibc-bugs@sourceware.org>, <unassigned@sourceware.org>,
 <drepper.fsp@gmail.com>, <roland@gnu.org>, <carlos@redhat.com>,
 <adhemerval.zanella@linaro.org>
CC: <yukeji@huawei.com>, <wangle6@huawei.com>
References: <20200807101601.61670-1-nixiaoming@huawei.com>
 <059aea74-2976-c16a-0a6d-fbde2123ac87@cs.ucla.edu>
From: Xiaoming Ni <nixiaoming@huawei.com>
Message-ID: <27f372e4-ec8d-340e-e12b-83b2cbca1c5b@huawei.com>
Date: Sat, 8 Aug 2020 16:54:42 +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: <059aea74-2976-c16a-0a6d-fbde2123ac87@cs.ucla.edu>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.67.102.197]
X-CFilter-Loop: Reflected
X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 KAM_MANYTO, 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 <libc-alpha.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Aug 2020 08:54:58 -0000

On 2020/8/8 7:56, Paul Eggert wrote:
> I don't understand why malloc is required here.
> 
> Isn't the problem that the buffer is being allocated over and over 
> again? And if you fix that bug, the function should allocate only 8 KiB 
> via __alloca on GNU/Linux. Something like the attached (untested) patch, 
> say. So why not keep using the stack? That would be more efficient than 
> resorting to the heap.
To avoid possible stack overflow risks (the remaining stack space is 
uncertain when realpath is called), should we sacrifice some efficiency 
and reduce the stack space usage? Use malloc instead of alloca (4k+4k).

thanks