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 40CA96ECE3; Wed, 29 Jun 2022 23:27:57 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 40CA96ECE3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1656534477; bh=wgmf+dIX6Hahi0FB/n4YNRZKfMaFMXt57npIdZnBLcY=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=JwDdpA0J6DMkOMT7wiXMMhnAL+Mv5rFl7Jt1yNck9wugzUpMVRtMUf8ZMdIctx1sa UJ/PeFZadvKiMrTSiyk+r+oWKVAfN5z+tCcAxACn3JQhu8qgq/8bNsLh2uHSECbl9B MV0hDsRwb9/L7zrIW/+0EJeHUwAbZO8RR7GmMfk8= Received: from smtpng3.i.mail.ru (smtpng3.i.mail.ru [94.100.177.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id D890A6ECE3 for ; Wed, 29 Jun 2022 23:27:55 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org D890A6ECE3 Received: by smtpng3.m.smailru.net with esmtpa (envelope-from ) id 1o6eHy-0007iL-N4; Wed, 29 Jun 2022 23:27:55 +0300 Date: Wed, 29 Jun 2022 23:20:44 +0300 To: sergos Message-ID: References: <45fce284fce8df636a18e7303114f82d5bbce2f0.1631170629.git.skaplun@tarantool.org> <31B92E03-B5C4-4719-9191-41D8581C930E@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-Mailru-Src: smtp X-4EC0790: 10 X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD9F05DDD76985F91269807460EE4DCEBE9440C6B23F8456A48182A05F538085040236A575C1FC390FC66A2A78E49588FD594B009463BA3F004F051C707640B6EAA X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE72AC9FB60380F23AEEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006376F978168E59B07A5EA1F7E6F0F101C6723150C8DA25C47586E58E00D9D99D84E1BDDB23E98D2D38B8859CA687ABA27BACEA6944794E04185050DC9354F4B37D3CC7F00164DA146DAFE8445B8C89999728AA50765F7900637F6B57BC7E64490618DEB871D839B7333395957E7521B51C2DFABB839C843B9C08941B15DA834481F8AA50765F79006370D9A29B7FD16D1239FA2833FD35BB23DF004C906525384302BEBFE083D3B9BA71A620F70A64A45A98AA50765F79006372E808ACE2090B5E1725E5C173C3A84C3C5EA940A35A165FF2DBA43225CD8A89FB26E97DCB74E6252156CCFE7AF13BCA4B5C8C57E37DE458BEDA766A37F9254B7 X-8FC586DF: 6EFBBC1D9D64D975 X-C1DE0DAB: 9604B64F49C60606AD91A466A1DEF99B296C473AB1E14218C6CDE5D1141D2B1CA34FC8761089F4A9B5484B3E5C47D04CA44EF55405A62889AD91A466A1DEF99B296C473AB1E14218B936CB490224F2464EEA7BD89490CAC0EDDA962BC3F61961 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D348F343DA43F62289F1E9F82F376080DB92FC777075BA7400E25FDA2F89EE1EDA8AF49F2CE0B7F1B991D7E09C32AA3244C6968798F7F82986ABA6A6653FB9703D07101BF96129E4011927AC6DF5659F194 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojhvrbUd41KJnGqVYSnUq2aw== X-Mailru-Sender: 689FA8AB762F7393CC2E0F076E87284E566A8AF6096E3C76805E682EFAD94207A7C8D0F45F857DBFE9F1EFEE2F478337FB559BB5D741EB964C8C2C849690F8E70A04DAD6CC59E3365FEEDEB644C299C0ED14614B50AE0675 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit 3/3] Avoid conflict between 64 bit lightuserdata and ITERN key. 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: Igor Munkin via Tarantool-patches Reply-To: Igor Munkin Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Sergey, Thanks for the patch! As a result of the fixes discussed offline, LGTM. On 20.09.21, sergos wrote: > Hi! > > > On 20 Sep 2021, at 11:38, Sergey Kaplun wrote: > > > > Hi, Sergos! > > > > Thanks for the review! > > > > On 15.09.21, sergos wrote: > > [...] > > >>> +++ b/test/tarantool-tests/lj-727-lightuserdata-itern.test.lua > >>> @@ -0,0 +1,48 @@ > >>> +local tap = require('tap') > >>> + > >>> +-- Test file to demonstrate next FF incorrect behaviour on LJ_64. > >>> +-- See also, https://github.com/LuaJIT/LuaJIT/issues/727. > >>> + > >>> +local test = tap.test('lj-727-lightuserdata-itern') > >>> +test:plan(1) > >>> + > >>> +local ud = require('lightuserdata').craft_ptr_wp() > >>> + > >>> +-- We now have the tagged lightuuserdata pointer > >>> +-- 0xFFFE7FFF00000002 in the up before this patch (after the patch > >>> +-- the maximum available lightuserdata segment is 0xffe). > >> > >> Shall we end the test here with just an expectation of an error? > >> I believe you can make a way simpler test: pcall(craft_ptr()) should work > >> successfully 254 times and error on an 255th one, isn’t it? > > > > Not exactly, I think. > > The main idea of the test -- generate as much lightuserdata objects as > > we can, and save them in the same table. After that we check that > > iteration by them is correct. > > > > Test you suggested doesn't show up the possible issue with ITERN, does > > it? > > Exactly. I don’t see any reason to force the situation showing that you > can’t use the LUD segment beyond particular value. The test can be that > simple showing the max segment is 254, not 255 - exactly the functionality > that is added to the code. So, it should fail at creation of 255th segment > and it will be the positive outcome of the test. If there’s no error - > the test fails. > It will simplify the test considerably. Also, you should not have such > long explanation of ITERN/ITERC - just say "the 255th segment is forbidden, > since its encoding is overlapped with control variable used by ISNEXT”. Sergos, I'm partially agree with you: we can just check that the last lightuserdata segment is reserved for LuaJIT internal usage -- this is the case. However, Sergey wants to check that after this patch ITERN despecialization doesn't lead to table misiteration (since this is the symptom being reported in LuaJIT queue). Unfortunately I can't figure out two issues: 1. How to properly check the BADLU is raised for the *last* segment (consider the comment in the commit from the trunk[1]). 2. What is more important: how does this error stops us from using "ITERN-magic-range" pointers outside of the last segment? I might be missing some related macro-magic, but AFAIU a new segment is created for any lightudup value, hence 0xfffe7fff... pointers can be mapped into the second segment, can't they? Anyway, I guess we can proceed with this series and report an issue/PR to the vanilla trunk when the issue bothers us again. P.S. What if we create "craft pointers" in a reverse order? I'll check this a bit later. > > I would recommend to wait for the 2nd reviewer here - especially if you > discussed the patch before submit. > > Regards, > Sergos > -- Best regards, IM