From nobody Wed Sep 07 12:11:09 2022 X-Original-To: dev-commits-src-branches@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MN1Lt0FN0z4cJp4; Wed, 7 Sep 2022 12:11:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MN1Ls1KLvz3G7N; Wed, 7 Sep 2022 12:11:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 287CB9MD097587 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 7 Sep 2022 15:11:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 287CB9RV097586; Wed, 7 Sep 2022 15:11:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 7 Sep 2022 15:11:09 +0300 From: Konstantin Belousov To: =?utf-8?Q?T=C4=B3l?= Coosemans Cc: Colin Percival , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-branches@freebsd.org Subject: Re: git: 5d45f99a1ed8 - stable/13 - i386 doreti: Fix calculation of stack frame size Message-ID: References: <202209021506.282F6Jhx029847@gitrepo.freebsd.org> <01000182feec990a-943b1465-055b-4cb8-984c-225a4feabf7d-000000@email.amazonses.com> <20220906172225.1a4d1064@FreeBSD.org> <20220907115604.6e5fbfeb@FreeBSD.org> List-Id: Commits to the stable branches of the FreeBSD src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-branches List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-branches@freebsd.org X-BeenThere: dev-commits-src-branches@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220907115604.6e5fbfeb@FreeBSD.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on tom.home X-Rspamd-Queue-Id: 4MN1Ls1KLvz3G7N X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.68 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_SHORT(-0.68)[-0.678]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MLMMJ_DEST(0.00)[dev-commits-src-all@freebsd.org,dev-commits-src-branches@freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_FIVE(0.00)[5]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_SOFTFAIL(0.00)[~all:c]; HAS_XAW(0.00)[]; ARC_NA(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Sep 07, 2022 at 11:56:04AM +0200, Tijl Coosemans wrote: > On Tue, 6 Sep 2022 20:18:33 +0300 Konstantin Belousov > wrote: > > On Tue, Sep 06, 2022 at 05:22:25PM +0200, Tijl Coosemans wrote: > >> On Fri, 2 Sep 2022 15:58:14 +0000 Colin Percival > >> wrote: > >>> On 9/2/22 08:06, Tijl Coosemans wrote: > >>>> The branch stable/13 has been updated by tijl: > >>>> > >>>> URL: https://cgit.FreeBSD.org/src/commit/?id=5d45f99a1ed861618d5c4d5b4252d5eba001ad35 > >>>> > >>>> commit 5d45f99a1ed861618d5c4d5b4252d5eba001ad35 > >>>> Author: Tijl Coosemans > >>>> AuthorDate: 2022-09-02 14:16:35 +0000 > >>>> Commit: Tijl Coosemans > >>>> CommitDate: 2022-09-02 15:02:00 +0000 > >>>> > >>>> i386 doreti: Fix calculation of stack frame size > >>>> > >>>> Reviewed by: kib > >>>> Fixes: e8b2980e4a12 - i386 doreti: stop saving/restoring %ecx > >>>> > >>>> (cherry picked from commit cfdc649e455bc0d37d42c46b59360462e93b4300) > >>> I assume this MFC took place 23 minutes after the original commit because it > >>> was an urgent fix; to avoid the need for assumptions, please indicate the > >>> reason for an accelerated MFC in the commit message when you skip the normal > >>> 3 day waiting period. > >> > >> Will do. In this case it was a trivial fixup in a critical path. At the > >> time I also thought it fixed a panic I was seeing but this turned out to > >> be caused by another commit. > > > > It is not on critical path, at worst it affected vm86 mode only. > > That said, 'the other bug' was there before the series. > > Looking into this again I now believe your change was actually correct. > trampstk = (uintptr_t)tramp_stack_base + TRAMP_STACK_SZ - VM86_STACK_SPACE > So it already has VM86_STACK_SPACE subtracted. Can you double-check > this? The trampstk pointer has the space for additional segment registers values that are pushed by hardware (in C it is at the end of the struct trapframe). But the calculation for %ecx is the size we are going to copy from kstack to trampoline. So when we are returning to vm86 mode, we must account for additional segment registers by increasing the copy size. The trampstk definition you cited means that we do not overflow the destination by the copy. So I think that your fix was correct.