From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on gnuweeb.org X-Spam-Level: X-Spam-Status: No, score=1.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 Authentication-Results: gnuweeb.org; dmarc=none (p=none dis=none) header.from=1wt.eu Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=163.172.96.212; helo=1wt.eu; envelope-from=w@1wt.eu; receiver= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by gnuweeb.org (Postfix) with ESMTP id AD2A824B211 for ; Tue, 29 Aug 2023 19:24:42 +0700 (WIB) Received: (from willy@localhost) by mail.home.local (8.17.1/8.17.1/Submit) id 37TCORUW015361; Tue, 29 Aug 2023 14:24:27 +0200 Date: Tue, 29 Aug 2023 14:24:27 +0200 From: Willy Tarreau To: Ammar Faizi Cc: Thomas =?iso-8859-1?Q?Wei=DFschuh?= , Zhangjin Wu , Nicholas Rosenberg , Michael William Jonathan , GNU/Weeb Mailing List , Linux Kernel Mailing List Subject: Re: [PATCH v2 1/1] tools/nolibc: i386: Fix a stack misalign bug on _start Message-ID: References: <20230828070240.1691921-1-ammarfaizi2@gnuweeb.org> <20230828070240.1691921-2-ammarfaizi2@gnuweeb.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: On Tue, Aug 29, 2023 at 07:17:10PM +0700, Ammar Faizi wrote: > On Tue, Aug 29, 2023 at 08:21:47AM +0200, Willy Tarreau wrote: > > Indeed, good catch! However if we want to do it cleany (i.e not punch a > > 16 to 28 byes hole in the stack), we should do this instead: > > > > add $12, %esp /* the stack must be aligned to 16 ... */ > > and $-16, %esp /* ... bytes after eax is pushed and ... */ > > sub $12, %esp /* ... before the call. */ > > > > This will only add 0 to 12 bytes depending on the existing alignment. > > > > What do you think ? > > Good point. I'll send a v3 revision tomorrow. OK thanks! > I just saw that Linus has pulled the PR from Shuah that contains this > bug. IOW, I missed this fix for the 6.6 merge window. Let's see if it > can go to 6.6-rc2. Or maybe sooner than that. No worries, we all know that -rc1 gets more exposure than individual branches and raises bugs like this one. Cheers, Willy