From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id CA090E0ECFB; Thu, 16 Jan 2025 17:55:25 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org CA090E0ECFB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1737039325; bh=B45Vy/ruxsWCMnbpNop9jX/99Qnr+3nPeupFAoeMQIc=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=FR5x0DcKnFeIzfuUH7HrAdHqhkEPaFFDFprg9jx5v1kvlWb4txqFewTt0qh1s4NiR gdOZu1NLayg61LoLEY1JXT/OBAhp8qH7RWrLHWm58tQc8XmxCPLmNzJhE8fpScAzE1 mACT9Pmav1wZpO05Tvae6d1l90bYLAmqNFh6BDnI= Received: from send276.i.mail.ru (send276.i.mail.ru [95.163.59.115]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 7F948464E99 for ; Thu, 16 Jan 2025 17:55:24 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 7F948464E99 Received: by exim-smtp-6758d5575c-rj6l4 with esmtpa (envelope-from ) id 1tYRHH-00000000KkB-13bu; Thu, 16 Jan 2025 17:55:23 +0300 Content-Type: multipart/alternative; boundary="------------30By6vxalF5pxFVf7BYlN8vD" Message-ID: Date: Thu, 16 Jan 2025 17:55:21 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Sergey Kaplun Cc: tarantool-patches@dev.tarantool.org References: <20250116133559.2686-1-skaplun@tarantool.org> In-Reply-To: <20250116133559.2686-1-skaplun@tarantool.org> X-Mailru-Src: smtp X-4EC0790: 10 X-7564579A: B8F34718100C35BD X-77F55803: 4F1203BC0FB41BD9CAF828D4DCE9EB95B591CFFA19FDF6F6CC1EBF97A13E8988182A05F538085040FE2BA8F2825B90723DE06ABAFEAF6705D482D26362B7BD883FCEBCEDC5050B80BA06A431C0AF6E5A X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7E8204D72912C702FEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637CDA089757FB31C668638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D8BA8B19E939D643FFEBF38B3A38AEB22615C4DD040D7AFED7CC7F00164DA146DAFE8445B8C89999728AA50765F7900637DCE3DBD6F8E38AFD389733CBF5DBD5E9C8A9BA7A39EFB766F5D81C698A659EA7CC7F00164DA146DA9985D098DBDEAEC81D471462564A2E19F6B57BC7E6449061A352F6E88A58FB86F5D81C698A659EA73AA81AA40904B5D9A18204E546F3947C632EDEA9CD5989A3BA3038C0950A5D36C8A9BA7A39EFB766D91E3A1F190DE8FDBA3038C0950A5D36D5E8D9A59859A8B641D154D92E01BDF13AA81AA40904B5D99C9F4D5AE37F343AD1F44FA8B9022EA23BBE47FD9DD3FB595F5C1EE8F4F765FC72CEEB2601E22B093A03B725D353964B0B7D0EA88DDEDAC722CA9DD8327EE4930A3850AC1BE2E735B58781B77DE60D36C4224003CC83647689D4C264860C145E X-C1DE0DAB: 0D63561A33F958A5A8E40EC72BD6DE275002B1117B3ED6966C41EE12CAFCEEB2C81EEE05487B0209823CB91A9FED034534781492E4B8EEADD0953842B444AAC3BDAD6C7F3747799A X-C8649E89: 1C3962B70DF3F0ADBF74143AD284FC7177DD89D51EBB7742424CF958EAFF5D571004E42C50DC4CA955A7F0CF078B5EC49A30900B95165D340E23B77EA1807817901D4E7BE2594563CFA34CFD1F90364CF9C0AF88D01CECA7E474FA54DFFF07581D7E09C32AA3244C7B6C2145EF710B0577DD89D51EBB7742A53EC76271859316EA455F16B58544A2E30DDF7C44BCB90DA5AE236DF995FB59978A700BF655EAEEED6A17656DB59BCAD427812AF56FC65B X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojyistvkELW9pHL1MhtsnLew== X-Mailru-Sender: 520A125C2F17F0B1E52FEF5D219D6140DF5D227BC4A7D43A15C513EAE8123D4D8DEB63EBE13913C80152A3D17938EB451EB5A0BCEC6A560B3DDE9B364B0DF289BE2DA36745F2EEB5CEBA01FB949A1F1EEAB4BC95F72C04283CDA0F3B3F5B9367 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit] x86/x64: Add more red zone checks to assembler backend. X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Sergey Bronnikov via Tarantool-patches Reply-To: Sergey Bronnikov Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" This is a multi-part message in MIME format. --------------30By6vxalF5pxFVf7BYlN8vD Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, Sergey, thanks for the patch! See comments below. On 16.01.2025 16:35, Sergey Kaplun wrote: > diff --git a/test/tarantool-tests/lj-1116-redzones-checks.test.lua b/test/tarantool-tests/lj-1116-redzones-checks.test.lua > new file mode 100644 > index 00000000..70062ec9 > --- /dev/null > +++ b/test/tarantool-tests/lj-1116-redzones-checks.test.lua > @@ -0,0 +1,118 @@ > +local tap = require('tap') > +-- Test file to demonstrate mcode area overflow during recording a > +-- trace with the high FPR pressure. > +-- See also,https://github.com/LuaJIT/LuaJIT/issues/1116. > +-- > +-- XXX: Test fails only with GC64 enabled before the commit. I would rephrase: XXX: Test fails with reverted fix and enabled GC64. > +local test = tap.test('lj-1116-redzones-checks'):skipcond({ > + ['Test requires JIT enabled'] = not jit.status(), > +}) > + > +test:plan(1) > + > +jit.opt.start('hotloop=1') > + > +-- XXX: This test snippet was originally created by the fuzzer. > +-- Seehttps://oss-fuzz.com/testcase-detail/5622965122170880. > +-- > +-- Unfortunately, it's impossible to reduce the testcase further. > +-- Before the patch, assembling some instructions (like `IR_CONV > +-- int.num`, for example) with many mcode to be emitted may > +-- overflow the `MCLIM_REDZONE` (64) at once due to the huge > +-- mcode emitting. > +-- For example `IR_CONV` in this test requires 66 bytes of the > +-- machine code: > +-- | cvttsd2si r15d, xmm5 > +-- | xorps xmm9, xmm9 > +-- | cvtsi2sd xmm9, r15d > +-- | ucomisd xmm5, xmm9 > +-- | jnz 0x11edb00e5 ->37 > +-- | jpe 0x11edb00e5 ->37 > +-- | mov [rsp+0x80], r15d > +-- | mov r15, [rsp+0xe8] > +-- | movsd xmm9, [rsp+0xe0] > +-- | movsd xmm5, [rsp+0xd8] > +-- > +-- The reproducer needs sufficient register pressure as to > +-- immediately spill the result of the instruction to the stack > +-- and then reload the three registers used by the instruction, > +-- and to have chosen enough registers with numbers >=8 (because > +-- shaving off a REX prefix [1] or two would get 66 back down > +-- to <= `MCLIM_REDZONE`), and to be using lots of spill slots > +-- (because memory offsets <= 0x7f are shorter to encode compared > +-- to those >= 0x80. So, each reload instruction consumes 9 bytes. > +-- This makes this reproducer unstable (regarding the register > +-- allocator changes). So, lets use this as a regression test. > +-- > +-- [1]:https://wiki.osdev.org/X86-64_Instruction_Encoding#REX_prefix > + > +_G.a = 0 > +_G.b = 0 > +_G.c = 0 > +_G.d = 0 > +_G.e = 0 > +_G.f = 0 > +_G.g = 0 > +_G.h = 0 > +-- Skip `i`. I didn't get it. --------------30By6vxalF5pxFVf7BYlN8vD Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Hi, Sergey,

thanks for the patch! See comments below.


On 16.01.2025 16:35, Sergey Kaplun wrote:


<snipped>

diff --git a/test/tarantool-tests/lj-1116-redzones-checks.test.lua b/test/tarantool-tests/lj-1116-redzones-checks.test.lua
new file mode 100644
index 00000000..70062ec9
--- /dev/null
+++ b/test/tarantool-tests/lj-1116-redzones-checks.test.lua
@@ -0,0 +1,118 @@
+local tap = require('tap')
+-- Test file to demonstrate mcode area overflow during recording a
+-- trace with the high FPR pressure.
+-- See also, https://github.com/LuaJIT/LuaJIT/issues/1116.
+--
+-- XXX: Test fails only with GC64 enabled before the commit.
I would rephrase: XXX: Test fails with reverted fix and enabled GC64.
+local test = tap.test('lj-1116-redzones-checks'):skipcond({
+  ['Test requires JIT enabled'] = not jit.status(),
+})
+
+test:plan(1)
+
+jit.opt.start('hotloop=1')
+
+-- XXX: This test snippet was originally created by the fuzzer.
+-- See https://oss-fuzz.com/testcase-detail/5622965122170880.
+--
+-- Unfortunately, it's impossible to reduce the testcase further.
+-- Before the patch, assembling some instructions (like `IR_CONV
+-- int.num`, for example) with many mcode to be emitted may
+-- overflow the `MCLIM_REDZONE` (64) at once due to the huge
+-- mcode emitting.
+-- For example `IR_CONV` in this test requires 66 bytes of the
+-- machine code:
+-- |  cvttsd2si r15d, xmm5
+-- |  xorps xmm9, xmm9
+-- |  cvtsi2sd xmm9, r15d
+-- |  ucomisd xmm5, xmm9
+-- |  jnz 0x11edb00e5       ->37
+-- |  jpe 0x11edb00e5       ->37
+-- |  mov [rsp+0x80], r15d
+-- |  mov r15, [rsp+0xe8]
+-- |  movsd xmm9, [rsp+0xe0]
+-- |  movsd xmm5, [rsp+0xd8]
+--
+-- The reproducer needs sufficient register pressure as to
+-- immediately spill the result of the instruction to the stack
+-- and then reload the three registers used by the instruction,
+-- and to have chosen enough registers with numbers >=8 (because
+-- shaving off a REX prefix [1] or two would get 66 back down
+-- to <= `MCLIM_REDZONE`), and to be using lots of spill slots
+-- (because memory offsets <= 0x7f are shorter to encode compared
+-- to those >= 0x80. So, each reload instruction consumes 9 bytes.
+-- This makes this reproducer unstable (regarding the register
+-- allocator changes). So, lets use this as a regression test.
+--
+-- [1]: https://wiki.osdev.org/X86-64_Instruction_Encoding#REX_prefix
+
+_G.a = 0
+_G.b = 0
+_G.c = 0
+_G.d = 0
+_G.e = 0
+_G.f = 0
+_G.g = 0
+_G.h = 0
+-- Skip `i`.

I didn't get it.



    

    <snipped>

    

      

    

  
  


--------------30By6vxalF5pxFVf7BYlN8vD--