From owner-freebsd-hackers@freebsd.org Mon Aug 12 09:14:31 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4512EAB510; Mon, 12 Aug 2019 09:14:31 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 466VXj6k39z436B; Mon, 12 Aug 2019 09:14:29 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-pg1-f180.google.com with SMTP id w3so11961492pgt.13; Mon, 12 Aug 2019 02:14:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:openpgp:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=tzVpj/gNw2BPOSdi7D8ic5+J4emHm2UKnA7aX0gBpCE=; b=Pfq5Z1tZ6+xdCz+0PIhspeZrg+0fgHB4EilQKJErXGHrTvdQpq1UsyhzyfBpUjehXD +7xO/gdzErEX1WZG4//J44FF/jAwhsExyewfVSY8O6novRDN4BpppxNwpHRexxrkb/Rz N2odaTeC0A6Lt/rKn3PA4tQD6i5E6HCzpTJNk1XKwd5D5gGDNdwxEc+s9AVxTOsa0L69 I901uc8viJeG0N8TcmshPko+1PYKksQIJcT95hUaA9I8+DHKIFxBkiv+or1lsgJYU5aD SwJuwmmmy/6DhrAxVEEwcqyK0Uyn35PYHNMKpXt5dJ4pdyLueyenErkfhqzdIxRRp3o7 oVig== X-Gm-Message-State: APjAAAVLV/+AmiVlBNHtH+X6HFuVhaTpqRUTbnAeVlb+TN/xtwq31MC5 OVhGdP4Z3dIy2KGP8BCIH26s/G3z X-Google-Smtp-Source: APXvYqyT2wRdlodRhsXEykrwxx1iENAX6d/WvJS1tgUat84XhNRHRATXabADiahfhcs5Gi7dugZ3xg== X-Received: by 2002:a17:90a:21c1:: with SMTP id q59mr6511269pjc.6.1565601268101; Mon, 12 Aug 2019 02:14:28 -0700 (PDT) Received: from [192.168.1.36] (broadband-82-140-206-197.atc.tvcom.ru. [82.140.206.197]) by smtp.googlemail.com with ESMTPSA id c12sm14921067pfc.22.2019.08.12.02.14.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Aug 2019 02:14:27 -0700 (PDT) To: FreeBSD Current , "freebsd-hackers@freebsd.org" From: Andriy Gapon Subject: userret: assert td_lk_slocks == 0 Openpgp: preference=signencrypt Message-ID: <94110a73-3c55-e87e-96ae-475014e45596@FreeBSD.org> Date: Mon, 12 Aug 2019 12:14:25 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 466VXj6k39z436B X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.215.180 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-6.13 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[FreeBSD.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-3.14)[ip: (-9.89), ipnet: 209.85.128.0/17(-3.38), asn: 15169(-2.39), country: US(-0.05)]; NEURAL_HAM_SHORT(-0.99)[-0.989,0]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[180.215.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[197.206.140.82.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 09:14:31 -0000 I am trying to debug a leak of a shared vnode lock and I noticed that there is no check for td_lk_slocks in userret. There are checks for td_rw_rlocks and td_sx_slocks. I wonder if there is any valid scenario where a thread is allowed to retain a shared lock manager lock across system calls. Thanks! -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Mon Aug 12 10:49:05 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9D29BAE052; Mon, 12 Aug 2019 10:49:05 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 466Xds3YjXz48sJ; Mon, 12 Aug 2019 10:49:05 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-ot1-x341.google.com with SMTP id c34so17030902otb.7; Mon, 12 Aug 2019 03:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uBM1FAzsK84kstKTP657BIwgAzqQ8ZqZnFgsxMyzFW4=; b=SIf8MRxtg0Q50ipF5GtSIQg+27xLQ/x+F9MjasDTBMLfJGGszwMWFxo9jU7EYYPwN/ kKwzcmp1hCaxuzy589i0c5BhFfXY3HLf+1tmwjGk5Y7mVXNkGDHYj73bG+UNSYhrdsaq 1uMDaQrP4pPm4sXB/YcUu23TTfP77kOfODOyhFoPMQX8zoReY9aXzYKzOrWKrT7bDrR3 IPBBLzYaeTQ0+4iO3Q/YAW2euw4zBKemwExDneVp4ab65Xi/jgpPFMc/7PSyyM/Wukf3 Ja2z/2r38mNphELxID2L7VSHORhdOtvn/6EerTHpwFxZyG3o8m5Xv3EA7aP6hyAUoIY8 1dtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uBM1FAzsK84kstKTP657BIwgAzqQ8ZqZnFgsxMyzFW4=; b=Lx1sRjmWsU9/rb5PvHS3KdAetqSScLHa7YuVaCdIi7iMmESCB1hyzcedhLhrZ1PXPb 3wcrGe+bA0O65oI0D0VTNzYd7hJjXFky8vzocccHeBIWrCVHv4QWtj6qUVJJLsvSM2MW b35ys4oBISyH816HB7M53dwrsUbPxOhRb8F/CljLtM45bJlRHWN0vnqRMapidiNOqrJQ GQC21qjaCn+KaX7iYTw0q1Ae6zIiiO8LlMV0FyNCh6D5Z9G9Xg38AexNn1PPltdTZLJd xoy3Ii4/4WnxJ8hazlttHSx7gN+f0+NEhcLUgFJbrSqDb5/ZV6MwZlZImF2zfbIcoH1M P8+A== X-Gm-Message-State: APjAAAVp41iej1C4a4FegtV8NXiSXFZzEt2PNIxMOZTl/0Xw8x19c5Gf RvcGBaUX9g9FImyU7613ds0Egdd6AmGY2RBFDqffgA== X-Google-Smtp-Source: APXvYqw3sinxQGx9jkWCp74zJlcxGZgJCOpf1y7dBMzRZBP3nn/mNfNgR6krOKOttXxsxVmS8g/7fgs/CgKRVBgalYE= X-Received: by 2002:aca:b788:: with SMTP id h130mr15046815oif.85.1565606944173; Mon, 12 Aug 2019 03:49:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:2516:0:0:0:0:0 with HTTP; Mon, 12 Aug 2019 03:49:03 -0700 (PDT) In-Reply-To: <94110a73-3c55-e87e-96ae-475014e45596@FreeBSD.org> References: <94110a73-3c55-e87e-96ae-475014e45596@FreeBSD.org> From: Mateusz Guzik Date: Mon, 12 Aug 2019 12:49:03 +0200 Message-ID: Subject: Re: userret: assert td_lk_slocks == 0 To: Andriy Gapon Cc: FreeBSD Current , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 466Xds3YjXz48sJ X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.984,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 10:49:05 -0000 On 8/12/19, Andriy Gapon wrote: > > I am trying to debug a leak of a shared vnode lock and I noticed that > there is no check for td_lk_slocks in userret. There are checks for > td_rw_rlocks and td_sx_slocks. I wonder if there is any valid scenario > where a thread is allowed to retain a shared lock manager lock across > system calls. > These counters are not for debugging purposes. They are part of poor man's starvation prevention for writers. If the target lock is taken for reading and someone wants to take it for writing, a bit will be set to denote this fact and prevent more readers from showing up. However, this can lead to deadlocks so if someone already has a read lock on something, they can bypass the bit and grab the extra read lock anyway. No locks are allowed to leak back to userspace and witness should already handles checking this for readers as well. -- Mateusz Guzik From owner-freebsd-hackers@freebsd.org Mon Aug 12 10:50:52 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 81ABDAE2B3; Mon, 12 Aug 2019 10:50:52 +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) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 466Xgw1zpyz499R; Mon, 12 Aug 2019 10:50:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x7CAoijf052609 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 12 Aug 2019 13:50:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x7CAoijf052609 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x7CAoijp052608; Mon, 12 Aug 2019 13:50:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 12 Aug 2019 13:50:44 +0300 From: Konstantin Belousov To: Andriy Gapon Cc: FreeBSD Current , "freebsd-hackers@freebsd.org" Subject: Re: userret: assert td_lk_slocks == 0 Message-ID: <20190812105044.GB2738@kib.kiev.ua> References: <94110a73-3c55-e87e-96ae-475014e45596@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94110a73-3c55-e87e-96ae-475014e45596@FreeBSD.org> User-Agent: Mutt/1.12.1 (2019-06-15) 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 466Xgw1zpyz499R X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.92 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.92)[-0.919,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 10:50:52 -0000 On Mon, Aug 12, 2019 at 12:14:25PM +0300, Andriy Gapon wrote: > > I am trying to debug a leak of a shared vnode lock and I noticed that > there is no check for td_lk_slocks in userret. There are checks for > td_rw_rlocks and td_sx_slocks. I wonder if there is any valid scenario > where a thread is allowed to retain a shared lock manager lock across > system calls. There is a situation where thread returns while keeping the lockmgr lock busied. This is used by buffer cache to keep everybody hands away of async buffers until io is finished. But the ownership of the lock is erased, and the thread's slocks count is decremented. I think it should be correct to add the assert you proposed. From owner-freebsd-hackers@freebsd.org Mon Aug 12 10:55:59 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7D845AE758; Mon, 12 Aug 2019 10:55:59 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 466Xnp2Rzjz49xs; Mon, 12 Aug 2019 10:55:58 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-pl1-f178.google.com with SMTP id ay6so47776988plb.9; Mon, 12 Aug 2019 03:55:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=622/z6LLRa/0hDvDa9YnbGSjikbJQS8KpQBrj4MD4v0=; b=mm4NOqlTuTg/w1BHybWrmKAiB6AHM2zFfV2d/jCqHIhqIxUVFjkyxIp5f8dzfmS86Q ywmx0/BgIheXwAQ4Abx8mZSYAvdgYDXDp7hsx5QA6YwCqgc8Kt+TEiS8Sfyp4n8559Ge z0iGOL/U9kPyZOk2h+VMmdOUhl2QDaAxS32YS41w3Cb6KcBFz0BJnVhnuTxtb9Ca7m0X Pd+q3w7B7UPC6wUKeveI/LvJzkT23vxkmN70XItWVRHZce+q//c1xCPUZeSKz0rpmIuu rN5nMh1d32vuV84fkj571Ba7pBp78UjXTU5y+NdxUh1Pn9hdlJKICJzjUa6LNo0enxsm OuWA== X-Gm-Message-State: APjAAAXxmL5aml9R9A8IlpuGHNK7SeA4CLiyxxFEAJZjh9UXD6UAB/jY ob6TBGYuWAu4f8pxEfzUog3XW+JC X-Google-Smtp-Source: APXvYqxvObdhJTi7ubKhKRh7WjhMUKXtYkBxjz7GMUC7PaW1jws2fMrfiMGbhglKCqxFI+NSKyhLoA== X-Received: by 2002:a17:902:86:: with SMTP id a6mr32660625pla.244.1565607356391; Mon, 12 Aug 2019 03:55:56 -0700 (PDT) Received: from [192.168.1.36] (broadband-82-140-206-197.atc.tvcom.ru. [82.140.206.197]) by smtp.googlemail.com with ESMTPSA id a128sm123283225pfb.185.2019.08.12.03.55.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Aug 2019 03:55:55 -0700 (PDT) Subject: Re: userret: assert td_lk_slocks == 0 To: Mateusz Guzik Cc: FreeBSD Current , "freebsd-hackers@freebsd.org" References: <94110a73-3c55-e87e-96ae-475014e45596@FreeBSD.org> From: Andriy Gapon Openpgp: preference=signencrypt Message-ID: Date: Mon, 12 Aug 2019 13:55:53 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 466Xnp2Rzjz49xs X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.214.178 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-6.11 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_SHORT(-0.99)[-0.988,0]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[197.206.140.82.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[178.214.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-3.12)[ip: (-9.77), ipnet: 209.85.128.0/17(-3.38), asn: 15169(-2.39), country: US(-0.05)]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 10:55:59 -0000 On 12/08/2019 13:49, Mateusz Guzik wrote: > On 8/12/19, Andriy Gapon wrote: >> >> I am trying to debug a leak of a shared vnode lock and I noticed that >> there is no check for td_lk_slocks in userret. There are checks for >> td_rw_rlocks and td_sx_slocks. I wonder if there is any valid scenario >> where a thread is allowed to retain a shared lock manager lock across >> system calls. >> > > These counters are not for debugging purposes. They are part of poor > man's starvation prevention for writers. Yes, I realize that. > If the target lock is taken for reading and someone wants to take it for > writing, a bit will be set to denote this fact and prevent more readers > from showing up. However, this can lead to deadlocks so if someone > already has a read lock on something, they can bypass the bit and > grab the extra read lock anyway. > > No locks are allowed to leak back to userspace and witness should > already handles checking this for readers as well. Yes. But since we have those asserts for td_rw_rlocks and td_sx_slocks, wouldn't it make sense to add one for td_lk_slocks? If it's considered superfluous for FreeBSD, then at least I'll add it in the work's fork. -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Mon Aug 12 13:18:48 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 06FA9B3505 for ; Mon, 12 Aug 2019 13:18:48 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 466byb5S5Wz4LJt for ; Mon, 12 Aug 2019 13:18:47 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id B9610B3504; Mon, 12 Aug 2019 13:18:47 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B91E2B3503 for ; Mon, 12 Aug 2019 13:18:47 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 466byZ65pWz4LJs for ; Mon, 12 Aug 2019 13:18:46 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: by mail-wm1-x333.google.com with SMTP id m125so7686853wmm.3 for ; Mon, 12 Aug 2019 06:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mime-version :content-transfer-encoding; bh=t9uo8g6rjrIzUNmrvvv6/2PnIj/MvfX/UE99tHEuRBk=; b=PT58MQnRO0p1BCr83LHVYP6Kfp2JRPataz67Zq/O5o46IHU9vCk1SNF2tETJIftMFk jc82OjLX1w5CFA0hZu2T/FnxLe/cirKBqjmY7bLtUz48VDKEu3K/cqsA10ho769ZJ41y O9+Z3OQRwKAXML/J1NqUwz1LRXfDea0C0PfSRXt6VjQY6bXUVJbtOmp7mvHL8m6Y89AA C/VBpH72cHaQmuuwF9wV/Be91n8pDdg+dKJG/44M+svBcdmUDxVJMOHTwB4uRYh80YYG M4Kbtweg+/hWUEtdJcspDQHUyf3Rn59Kxj0DMzioJt+Xpgf6ubQ3GlidZ0hrPNYwobrX nfnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-transfer-encoding; bh=t9uo8g6rjrIzUNmrvvv6/2PnIj/MvfX/UE99tHEuRBk=; b=debHLOOe9GHFah7sLi1Fi1u5hSTHTrOeNGUkbX7aBvkVuzAhTxLoxyt5t6PpTu1Vum YpQQuy0sPOXQH83rEk8QhfpkR7qouTALiuoBzrKE3RGChL6JqqOlMK5ISq9AYX3CZVLF Eyl/+JwpV6uspYWVRGPORPOp58TXRQk8cVGE92IJmJ3rPwH24ic+LqtsvToDHQRAmYlR 9mDYWxahhCLCzvN9UqAS7gPlljjlOxZJWOS+gSP62LBBv4cjy/JXBgpwqwOuO4NqhkrV sd3Cr7ksTA844Ck0qCZsbTXYSOT7j58txV1WqJcPI8CYLP7Wx1lX6a1EJ6WFSQrglMX5 TUGQ== X-Gm-Message-State: APjAAAV8+dSdoX2TPkNvuoul2HDCRIjinxWUzCkXBHk7dxZ3uPHfOdOM +hfAGLv8UVY3QeVSB6MUUOfjI/pO X-Google-Smtp-Source: APXvYqw4T7ngbb8co3l3FA/lV/5ZUxqKutI6yVdOwf4c+qv6AQKvgVXBkesq+saYcE6oDrKif52XKQ== X-Received: by 2002:a1c:a8d7:: with SMTP id r206mr28053382wme.47.1565615925043; Mon, 12 Aug 2019 06:18:45 -0700 (PDT) Received: from localhost ([213.149.54.15]) by smtp.gmail.com with ESMTPSA id x6sm113629532wrt.63.2019.08.12.06.18.44 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 12 Aug 2019 06:18:44 -0700 (PDT) Date: Mon, 12 Aug 2019 15:17:35 +0200 From: Domagoj =?UTF-8?Q?Smol=C4=8Di=C4=87?= To: hackers@freebsd.org Subject: MAKEOBJDIRPREFIX fails if it has dot '.' in dir name (maybe also with some other chars) Message-ID: <20190812151735.000070b0@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 466byZ65pWz4LJs X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=PT58MQnR; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rank1seeker@gmail.com designates 2a00:1450:4864:20::333 as permitted sender) smtp.mailfrom=rank1seeker@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.997,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-9.15), ipnet: 2a00:1450::/32(-3.04), asn: 15169(-2.39), country: US(-0.05)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[3.3.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 13:18:48 -0000 11.3-RELEASE-p2 # make MAKEOBJDIRPREFIX=3D/usr/obj/usr.LOCAL buildworld make[1]: "/usr/src/Makefile.inc1" line 163: SYSTEM_COMPILER: Determined tha= t CC=3Dcc matches the source tree. Not bootstrapping a cross-compiler. -------------------------------------------------------------- >>> World build started on Sat Aug 12 11:57:54 CEST 2019 -------------------------------------------------------------- -------------------------------------------------------------- >>> Rebuilding the temporary build tree -------------------------------------------------------------- rm -rf /usr/obj/usr.LOCAL/usr/src/tmp rm: /usr/obj/usr.LOCAL/usr/src/tmp: Not a directory *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src # env MAKEOBJDIRPREFIX=3D/usr/obj/usr_LOCAL make buildworld make[1]: "/usr/src/Makefile.inc1" line 163: SYSTEM_COMPILER: Determined tha= t CC=3Dcc matches the source tree. Not bootstrapping a cross-compiler. -------------------------------------------------------------- >>> World build started on Sat Aug 12 11:58:52 CEST 2019 -------------------------------------------------------------- -------------------------------------------------------------- >>> Rebuilding the temporary build tree -------------------------------------------------------------- rm -rf /usr/obj/usr_LOCAL/usr/src/tmp mkdir -p /usr/obj/usr_LOCAL/usr/src/tmp/lib ... ... ... ... Domagoj Smol=C4=8Di=C4=87 From owner-freebsd-hackers@freebsd.org Mon Aug 12 14:38:48 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 09D80B577F for ; Mon, 12 Aug 2019 14:38:48 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 466dkv6DdZz4R7H for ; Mon, 12 Aug 2019 14:38:47 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id D417AB577E; Mon, 12 Aug 2019 14:38:47 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D3D8CB577D for ; Mon, 12 Aug 2019 14:38:47 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 466dkv5J0nz4R7G; Mon, 12 Aug 2019 14:38:47 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 67F54CD54; Mon, 12 Aug 2019 14:38:47 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Mon, 12 Aug 2019 14:38:45 +0000 From: Glen Barber To: Domagoj =?utf-8?B?U21vbMSNacSH?= Cc: hackers@freebsd.org Subject: Re: MAKEOBJDIRPREFIX fails if it has dot '.' in dir name (maybe also with some other chars) Message-ID: <20190812143845.GP75221@FreeBSD.org> References: <20190812151735.000070b0@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GoZzJvFfKjxI3RhA" Content-Disposition: inline In-Reply-To: <20190812151735.000070b0@gmail.com> User-Agent: Mutt/1.12.1 (2019-06-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 14:38:48 -0000 --GoZzJvFfKjxI3RhA Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 12, 2019 at 03:17:35PM +0200, Domagoj Smol=C4=8Di=C4=87 wrote: > 11.3-RELEASE-p2 >=20 >=20 > # make MAKEOBJDIRPREFIX=3D/usr/obj/usr.LOCAL buildworld You set MAKEOBJDIRPREFIX two different ways. Here you did not set it in the environment, but as a variable to make(1). The way you did this below is correct. > make[1]: "/usr/src/Makefile.inc1" line 163: SYSTEM_COMPILER: Determined t= hat CC=3Dcc matches the source tree. Not bootstrapping a cross-compiler. > -------------------------------------------------------------- > >>> World build started on Sat Aug 12 11:57:54 CEST 2019 > -------------------------------------------------------------- >=20 > -------------------------------------------------------------- > >>> Rebuilding the temporary build tree > -------------------------------------------------------------- > rm -rf /usr/obj/usr.LOCAL/usr/src/tmp > rm: /usr/obj/usr.LOCAL/usr/src/tmp: Not a directory > *** Error code 1 >=20 > Stop. > make[1]: stopped in /usr/src > *** Error code 1 >=20 > Stop. > make: stopped in /usr/src >=20 >=20 > # env MAKEOBJDIRPREFIX=3D/usr/obj/usr_LOCAL make buildworld This worked for me using '.' in the path. # env MAKEOBJDIRPREFIX=3D/usr/obj/usr.LOCAL make buildworld make[1]: "/usr/src/Makefile.inc1" line 163: SYSTEM_COMPILER: Determined th= at CC=3Dcc matches the source tree. Not bootstrapping a cross-compiler. -------------------------------------------------------------- >>> World build started on Mon Aug 12 14:38:13 UTC 2019 -------------------------------------------------------------- -------------------------------------------------------------- >>> Rebuilding the temporary build tree -------------------------------------------------------------- rm -rf /usr/obj/usr.LOCAL/usr/src/tmp rm -rf /usr/obj/usr.LOCAL/usr/src/lib32 mkdir -p /usr/obj/usr.LOCAL/usr/src/tmp/lib mkdir -p /usr/obj/usr.LOCAL/usr/src/tmp/lib/casper mkdir -p /usr/obj/usr.LOCAL/usr/src/tmp/usr Glen --GoZzJvFfKjxI3RhA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAl1RefUACgkQAxRYpUeP 4pPgABAAo3FLib9Z91y3GaafW2tPOfg1tACuOLTLh6OZPgZ1kle6wKMdFCzj7P4j QUSinXl2hK6CZBzXCJq7irdlQJ2c832SdHZ7JX058cf1weZ30JdLRd9mk0vDyXCG wAUoOJxYPsCuWB9Bldnt6v3GEPodJ/jc4L+X0a3+/SaF83MMjPHU47Xs0UnchsuK QJ42GdPySjxFLlVYYUQproxx+fuM/h2IwG6qCoKA2TYKzifgRsYaiVAxK8nctOZz qwURqOdXW2a4Nkmc/6YDbNisLFsZztde6HbcG50VoVqXbUpX5lAES8npA7O55hQV xuCHG3SU5bTh0m4byLLM3KqzV1Gi0oGvycnJYTJJZeh1w9+d1DLHxuizBORvU9Z4 ozI0qvfOjTooXuvm6karUaPZQRm8tpdFrW+IOwJsAdNrm6b40kXGIcYKew2CNPp9 qKq5gTml8dxSFhJ8/oklSQjwG6TndPbeAogIqKBdjGf1d1fSn1lEEcw7kmMSd4gM YPHgCvYtf6bHkt8O7rCDKCvzVqBB50JklR5nqZB9TnocYAp4ugPBu574MrGWWnbV 41Jw+BHNNw9zwaQatP2jxdUdOd0lK6ntMmQujUY6RAgwrGCvuGkXUwsrJaeAHr16 M+GiDidDCNgI0XkeNWA0ZMtAqYrs641tAj6IK8zGSenuIc2gzAs= =mYOJ -----END PGP SIGNATURE----- --GoZzJvFfKjxI3RhA-- From owner-freebsd-hackers@freebsd.org Mon Aug 12 15:09:48 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 36A5DB6254 for ; Mon, 12 Aug 2019 15:09:48 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 466fQh064Zz4SdV for ; Mon, 12 Aug 2019 15:09:48 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 03857B6253; Mon, 12 Aug 2019 15:09:48 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 033EFB6252 for ; Mon, 12 Aug 2019 15:09:48 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 466fQg6b53z4SdT; Mon, 12 Aug 2019 15:09:47 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf1-x442.google.com with SMTP id b13so49835525pfo.1; Mon, 12 Aug 2019 08:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=CpEy8yRCZueOABjn+jexnn35PQfdg6+MTEKT4monPIk=; b=R/hU9R3Ep9F9aaGS0p3DRkH3sGcDpQyy4V681La++fT0VcTChzOu+VlDDWff1R2PTg YY2BoxlNc86XI8MRwmlmRRwlA2+C7bzMue4GXwz2PFol52Zdyz2K7amxcZ0U4j7tsRn5 kevMv5LAhJfTR5HyyGacgqCQuFQAkLQdTGeNpkt14JHAlRRMr8A5bfDBl82BMhA7VHpE cW+Xpc06F52KX9/f4vC/AMZLLcD95oA5+D9xur+PIemqyViBlIWYY7bNDjrImHBmTVBT dFwdR6+lOfaoH51Bqx0BpQgFlHh5+1pQzeo9gDQInpew+ybvw56006ueI8Q+Y+5C7Csg SpQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=CpEy8yRCZueOABjn+jexnn35PQfdg6+MTEKT4monPIk=; b=WHG3tLwQG6MMKBk8fRCrkVKyUvIs+20+KREShAsdJKwgYjsOlDY3R4j4KJ0JmYdSp8 4UsA8upl6LrL6KcZxHNtj8L570g1XHOSlwD7TtLUO48/Ht5tMHmV3tFalr2kVqiMqvnH M3YLfFMbm9A6lgKs0CqlW/PYD+cSOFm55mnSOXn/hJ9MO5MCp7fjaHk+vLay/dbToa0k G5TVejs72E6ZL1hhBSdsNnYONT92WdPsWrOT/2c5FKVrq+zONH3bkZ2IPBGTT5LaGg+f 5sYoBF3I+C3HExcbjJw1tiiVsUcQACTLYBEOyVd0ZAqQzZPbADtZwaOXto72g0k2wYfj b/gw== X-Gm-Message-State: APjAAAWzqemS+VRklJZmI2Ce1sY8qbqP2IZd1q/B7rH3zSUZEMJYcNxs ZTWkQsDWUstR9WhYwqAVEPav8t3yZ6w= X-Google-Smtp-Source: APXvYqxCukNq5mVq+36g/XDmfVkDfBdOjWXjvVmeE+AkuFC0Wr4CYb1JTJBSM+ACTOwt+wu4v2e47g== X-Received: by 2002:a65:63c4:: with SMTP id n4mr30211123pgv.44.1565622586186; Mon, 12 Aug 2019 08:09:46 -0700 (PDT) Received: from [192.168.20.7] (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id w9sm4025911pfn.19.2019.08.12.08.09.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Aug 2019 08:09:45 -0700 (PDT) From: Enji Cooper Message-Id: <8A736CB1-EF26-4712-8A1E-5D66E20AA122@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: MAKEOBJDIRPREFIX fails if it has dot '.' in dir name (maybe also with some other chars) Date: Mon, 12 Aug 2019 08:09:44 -0700 In-Reply-To: <20190812143845.GP75221@FreeBSD.org> Cc: =?utf-8?B?RG9tYWdvaiBTbW9sxI1pxIc=?= , hackers@freebsd.org To: Glen Barber References: <20190812151735.000070b0@gmail.com> <20190812143845.GP75221@FreeBSD.org> X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 466fQg6b53z4SdT X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.980,0] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 15:09:48 -0000 > On Aug 12, 2019, at 7:38 AM, Glen Barber wrote: >=20 > On Mon, Aug 12, 2019 at 03:17:35PM +0200, Domagoj Smol=C4=8Di=C4=87 = wrote: >> 11.3-RELEASE-p2 >>=20 >>=20 >> # make MAKEOBJDIRPREFIX=3D/usr/obj/usr.LOCAL buildworld >=20 > You set MAKEOBJDIRPREFIX two different ways. Here you did not set it > in the environment, but as a variable to make(1). The way you did = this > below is correct. =E2=80=A6 >> # env MAKEOBJDIRPREFIX=3D/usr/obj/usr_LOCAL make buildworld >=20 > This worked for me using '.' in the path. >=20 > # env MAKEOBJDIRPREFIX=3D/usr/obj/usr.LOCAL make buildworld > make[1]: "/usr/src/Makefile.inc1" line 163: SYSTEM_COMPILER: = Determined that CC=3Dcc matches the source tree. Not bootstrapping a = cross-compiler. Hmmm=E2=80=A6 I wonder why this error case in /Makefile wasn=E2=80=99t = tripped... 193 MAKEOBJDIRPREFIX?=3D /usr/obj 194 _MAKEOBJDIRPREFIX!=3D /usr/bin/env -i PATH=3D${PATH} ${MAKE} = MK_AUTO_OBJ=3Dno \ 195 ${.MAKEFLAGS:MMAKEOBJDIRPREFIX=3D*} __MAKE_CONF=3D${__MAKE_CONF} = \ 196 SRCCONF=3D${SRCCONF} SRC_ENV_CONF=3D \ 197 -f /dev/null -V MAKEOBJDIRPREFIX dummy 198 .if !empty(_MAKEOBJDIRPREFIX) 199 .error MAKEOBJDIRPREFIX can only be set in environment or = src-env.conf(5),\ 200 not as a global (in make.conf(5) or src.conf(5)) or command-line = variable. 201 .endif -Enji= From owner-freebsd-hackers@freebsd.org Mon Aug 12 15:30:50 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 11F10B6B12 for ; Mon, 12 Aug 2019 15:30:50 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 466ftx57Tgz4Tg7 for ; Mon, 12 Aug 2019 15:30:49 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id B0158B6B11; Mon, 12 Aug 2019 15:30:49 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AFD39B6B10 for ; Mon, 12 Aug 2019 15:30:49 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 466ftx4Fz5z4Tg6; Mon, 12 Aug 2019 15:30:49 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: by mail-wm1-x343.google.com with SMTP id g67so12168377wme.1; Mon, 12 Aug 2019 08:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=wUbvQMHShtT9sLY8SZm6d857FdQMFG3D5jAqXgRIeNk=; b=IK0yWVn4tJ84YC3+JBfgiSGoEz0CtTYnFE9iO+RDRlyJyrpv4d6Qlyct7yAceVkWXA WB0xlnUVaYe8Wubk66GomPm/688YRuD0Evm0Ip30r8DGkjpJSI5wvWg/NjFYPMUXqiyk mAKay6bd37DmwvgM2vInDrr6b/tIPNWeXcMY1sTYkNw8Nnh3lWKW7itfHshJ8guvy17p yAD7JmLcM3TxoewKTtq0WaX6GA5j9mrDW3M89Q12C2gQkTS2AwnGLeTtBl874RTIjyyz fBI8cenAnAsf1hfqH2Lzn9FkAIjurE4TGEpTzZh0YjeC2Fh9j/IUNiMJay+EDBhZrEnM Mwkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=wUbvQMHShtT9sLY8SZm6d857FdQMFG3D5jAqXgRIeNk=; b=cGGFRjUALxGQGrMaemX6VCiKj8pr/SfGE4oOD21NcIrEjMNMTkkKYFQ8H2C6of7w8B 4ieZrrZSR33t7ThRDAWxW+kEZsP61c51Fx7jwaibqpJR0RI7/v/5w1+XZPczi81D9qvJ UgboQjzfoWH2lfsEL2NR5hMLXfIF8dE/N0BvHqohZiGx1AZ7yJW2xw+kWsST7rOE+4DH XTcvy2sD8r6AXYrr4rHpoUOcV7e2VmLqkFNSIvv3qu0i4+4l/6tVzQKrn3ImEKx6o1Rv 96aMbEPv2WbtTiB1z6CeyJ6zq56I1DBCxZLLHZdL4yfpkx5Dr6mFzYTjA0euVs0GugLP ELlw== X-Gm-Message-State: APjAAAWXNbmD+jnzI9204vJ7EEL26h5iPCH5wg92Uof8TQzmyRO5Iws8 /wJwqE/1i5uq/VG7VN3kwqrw7hrR X-Google-Smtp-Source: APXvYqzDnn6e6WG3HLBlfgLYJimXmhKav0tvSy3GpHF/of0IAUREV7DahNFbfHBky2oV6HgEOTWKeA== X-Received: by 2002:a1c:7611:: with SMTP id r17mr28290529wmc.117.1565623846940; Mon, 12 Aug 2019 08:30:46 -0700 (PDT) Received: from localhost ([213.149.54.15]) by smtp.gmail.com with ESMTPSA id j16sm61110093wrp.62.2019.08.12.08.30.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 12 Aug 2019 08:30:46 -0700 (PDT) Date: Mon, 12 Aug 2019 17:29:37 +0200 From: Domagoj =?UTF-8?Q?Smol=C4=8Di=C4=87?= To: Glen Barber Cc: hackers@freebsd.org Subject: Re: MAKEOBJDIRPREFIX fails if it has dot '.' in dir name (maybe also with some other chars) Message-ID: <20190812172937.00005941@gmail.com> In-Reply-To: <20190812143845.GP75221@FreeBSD.org> References: <20190812151735.000070b0@gmail.com> <20190812143845.GP75221@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 466ftx4Fz5z4Tg6 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.981,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 15:30:50 -0000 On Mon, 12 Aug 2019 14:38:45 +0000 Glen Barber wrote: > On Mon, Aug 12, 2019 at 03:17:35PM +0200, Domagoj Smol=C4=8Di=C4=87 wrote: > > 11.3-RELEASE-p2 > >=20 > >=20 > > # make MAKEOBJDIRPREFIX=3D/usr/obj/usr.LOCAL buildworld =20 >=20 > You set MAKEOBJDIRPREFIX two different ways. Here you did not set it > in the environment, but as a variable to make(1). The way you did > this below is correct. Ups! You were right Glen. Well, that happens when you copy-paste a lot. I haven't selected 'env' part. # env make MAKEOBJDIRPREFIX=3D/usr/obj/usr.LOCAL buildworld worked, as well as: # env MAKEOBJDIRPREFIX=3D/usr/obj/usr.LOCAL make buildworld Domagoj > > make[1]: "/usr/src/Makefile.inc1" line 163: SYSTEM_COMPILER: > > Determined that CC=3Dcc matches the source tree. Not bootstrapping a > > cross-compiler. > > -------------------------------------------------------------- =20 > > >>> World build started on Sat Aug 12 11:57:54 CEST 2019 =20 > > -------------------------------------------------------------- > >=20 > > -------------------------------------------------------------- =20 > > >>> Rebuilding the temporary build tree =20 > > -------------------------------------------------------------- > > rm -rf /usr/obj/usr.LOCAL/usr/src/tmp > > rm: /usr/obj/usr.LOCAL/usr/src/tmp: Not a directory > > *** Error code 1 > >=20 > > Stop. > > make[1]: stopped in /usr/src > > *** Error code 1 > >=20 > > Stop. > > make: stopped in /usr/src > >=20 > >=20 > > # env MAKEOBJDIRPREFIX=3D/usr/obj/usr_LOCAL make buildworld =20 >=20 > This worked for me using '.' in the path. >=20 > # env MAKEOBJDIRPREFIX=3D/usr/obj/usr.LOCAL make buildworld > make[1]: "/usr/src/Makefile.inc1" line 163: SYSTEM_COMPILER: > Determined that CC=3Dcc matches the source tree. Not bootstrapping a > cross-compiler. > -------------------------------------------------------------- > >>> World build started on Mon Aug 12 14:38:13 UTC 2019 =20 > -------------------------------------------------------------- >=20 > -------------------------------------------------------------- > >>> Rebuilding the temporary build tree =20 > -------------------------------------------------------------- > rm -rf /usr/obj/usr.LOCAL/usr/src/tmp > rm -rf /usr/obj/usr.LOCAL/usr/src/lib32 > mkdir -p /usr/obj/usr.LOCAL/usr/src/tmp/lib > mkdir -p /usr/obj/usr.LOCAL/usr/src/tmp/lib/casper > mkdir -p /usr/obj/usr.LOCAL/usr/src/tmp/usr >=20 > Glen >=20 >=20 From owner-freebsd-hackers@freebsd.org Mon Aug 12 15:51:16 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 36504B7448 for ; Mon, 12 Aug 2019 15:51:16 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 466gLX0px3z4W7T for ; Mon, 12 Aug 2019 15:51:16 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 19E6DB7446; Mon, 12 Aug 2019 15:51:16 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 19A73B7445 for ; Mon, 12 Aug 2019 15:51:16 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 466gLW3ghRz4W7P; Mon, 12 Aug 2019 15:51:15 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pl1-x62f.google.com with SMTP id c14so47942027plo.0; Mon, 12 Aug 2019 08:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AFLbpuujZ+sVWJ2D3Ovfe17ZllNLoUYu3Y/JiBImG1o=; b=u4ZMVNOs0iYMjp6H90s0Uj4WaQJ2KvFOXtwzb67wfJNPAouvC4DwuTr24MPPboSWBy PK8AlJvkP9L2bU0+0QuUj9OJslQZVK1sbzixL07rTnbVVjCwwEJ05a6m54cYQprxU9sU EdIpZXODYnyh3f84udEYhR+/vjhuqyv4nVjDG975LuL3/JHzPwhFABzCawo1Up4uuwJ+ BuQtdRSsPtowcjxID08FRlhzHIBseZsmFIM28krC2CTZq9QSlE/qL54c1Gazqs3BcdDt ByG16arc0BMJDnT0yHLV1r56WLyKa01OGKubJgJnDOLLq/DcOF1kMWHpe9oNZ2Gg/FOx Ds5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=AFLbpuujZ+sVWJ2D3Ovfe17ZllNLoUYu3Y/JiBImG1o=; b=VsnAn9aqh3mOtYmwVkHWPr6aLFptgbBrWhiRZpVqSflLebgTIlz0gGV/r08WU6Cd9U 4QV5jBaT0BTeWzoFlnYL6+YOHvq7wF1AGGS3ufrrqSCzfQGlRpDCUSLSX1nfYlZSVW/p WNrXrKMSFf2GhFLsECZjHuEnZhv7W3ptT80YbJjEt6EPkPYz3sVe9V0qmSp3YS9SBd61 810VExYXag7/hjMYlFTqD/3Wj0f838FCp4nE1gmpiWGru8WBezx8bNKTRM/qrpomJ4i/ sQaLORDNu1COkQ9dUEkyUGDr5LBc4GYtNXNbmM3vJDNxZDWGErAbWJDgoWV76yKtsK60 ow2g== X-Gm-Message-State: APjAAAXSIbGvytFWqJm+/rW1l9r0y0HW6WfjEFrv+72fXuouvx91qaoV MvFznPHGrGNBCJWC4SvKDiE= X-Google-Smtp-Source: APXvYqxLRXyhktMO1/XnOPK0ZRB/6OaRayMKIIc5AAsbsCYu/ag/e3lyjFjF9PEwCJVtKz4kXModuA== X-Received: by 2002:a17:902:4401:: with SMTP id k1mr33532856pld.193.1565625074123; Mon, 12 Aug 2019 08:51:14 -0700 (PDT) Received: from [192.168.20.7] (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id j187sm12726543pfg.178.2019.08.12.08.51.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Aug 2019 08:51:13 -0700 (PDT) From: Enji Cooper Message-Id: <06F611B5-075E-411E-B019-967F3C116681@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: MAKEOBJDIRPREFIX fails if it has dot '.' in dir name (maybe also with some other chars) Date: Mon, 12 Aug 2019 08:51:12 -0700 In-Reply-To: <20190812172937.00005941@gmail.com> Cc: Glen Barber , hackers@freebsd.org To: =?utf-8?B?RG9tYWdvaiBTbW9sxI1pxIc=?= References: <20190812151735.000070b0@gmail.com> <20190812143845.GP75221@FreeBSD.org> <20190812172937.00005941@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 466gLW3ghRz4W7P X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=u4ZMVNOs; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of yaneurabeya@gmail.com designates 2607:f8b0:4864:20::62f as permitted sender) smtp.mailfrom=yaneurabeya@gmail.com X-Spamd-Result: default: False [-3.49 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.992,0]; FREEMAIL_TO(0.00)[gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[228.52.19.73.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; IP_SCORE(0.00)[ip: (-9.42), ipnet: 2607:f8b0::/32(-2.97), asn: 15169(-2.39), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[f.2.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 15:51:16 -0000 > On Aug 12, 2019, at 8:29 AM, Domagoj Smol=C4=8Di=C4=87 = wrote: >=20 > On Mon, 12 Aug 2019 14:38:45 +0000 > Glen Barber > wrote: >=20 >> On Mon, Aug 12, 2019 at 03:17:35PM +0200, Domagoj Smol=C4=8Di=C4=87 = wrote: >>> 11.3-RELEASE-p2 >>>=20 >>>=20 >>> # make MAKEOBJDIRPREFIX=3D/usr/obj/usr.LOCAL buildworld =20 >>=20 >> You set MAKEOBJDIRPREFIX two different ways. Here you did not set it >> in the environment, but as a variable to make(1). The way you did >> this below is correct. >=20 > Ups! > You were right Glen. >=20 > Well, that happens when you copy-paste a lot. > I haven't selected 'env' part. >=20 > # env make MAKEOBJDIRPREFIX=3D/usr/obj/usr.LOCAL buildworld > worked, as well as: > # env MAKEOBJDIRPREFIX=3D/usr/obj/usr.LOCAL make buildworld This line is suspect: rm: /usr/obj/usr.LOCAL/usr/src/tmp: Not a directory What does it point to...? Cheers, -Enji= From owner-freebsd-hackers@freebsd.org Mon Aug 12 16:16:39 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 47232B8321 for ; Mon, 12 Aug 2019 16:16:39 +0000 (UTC) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (gerbercreations.com [71.39.140.16]) by mx1.freebsd.org (Postfix) with ESMTP id 466gvn2Tjtz4Xj3 for ; Mon, 12 Aug 2019 16:16:36 +0000 (UTC) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (localhost.eyesbeyond.com [127.0.0.1]) by misty.eyesbeyond.com (8.15.2/8.15.2) with ESMTP id x7CGGTJ4000338 for ; Mon, 12 Aug 2019 09:16:29 -0700 (PDT) (envelope-from glewis@eyesbeyond.com) Received: (from glewis@localhost) by misty.eyesbeyond.com (8.15.2/8.15.2/Submit) id x7CGGT33000337 for freebsd-hackers@freebsd.org; Mon, 12 Aug 2019 09:16:29 -0700 (PDT) (envelope-from glewis@eyesbeyond.com) X-Authentication-Warning: misty.eyesbeyond.com: glewis set sender to glewis@eyesbeyond.com using -f Date: Mon, 12 Aug 2019 09:16:29 -0700 From: Greg Lewis To: freebsd-hackers@freebsd.org Subject: Java stack overflow segfaults Message-ID: <20190812161629.GA99971@misty.eyesbeyond.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) X-Rspamd-Queue-Id: 466gvn2Tjtz4Xj3 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of glewis@eyesbeyond.com has no SPF policy when checking 71.39.140.16) smtp.mailfrom=glewis@eyesbeyond.com X-Spamd-Result: default: False [0.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.06)[-0.058,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.38)[-0.379,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; HAS_XAW(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; NEURAL_HAM_SHORT(-0.25)[-0.254,0]; DMARC_NA(0.00)[eyesbeyond.com]; R_SPF_NA(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209, ipnet:71.39.128.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-0.01)[asn: 209(-0.00), country: US(-0.05)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 16:16:39 -0000 Hi all, I'm investigating an issue where, on FreeBSD, Java will crash rather than throw a StackOverflowError given a simple test program with a function that just calls itself over and over. There's an example of such a test in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222146 This affects, I suspect, every native version of Java in the ports tree, although I've only tried openjdk8 and higher. My investigation has mostly focused on openjdk11. To outline the situation, Java uses pthreads internally for threading. It doesn't use the pthreads own guard page(s), but instead creates it's own guard area at the bottom of the stack (which grows downward) using mprotect. It then installs a signal handler and examines any SIGSEGV's fault address to see if it falls within the guard area, and if so throws a StackOverflowError. This logic is the same across all of the OSes I've looked at and works on OpenBSD, Linux, etc. On FreeBSD though, the fault address lies in the page above the guard zone, rather than in the guard zone, which results in a crash rather than throwing StackOverflowError. An diagram may help here: --- <- Stack top | | Untouched memory + stack frames + etc. | | | <-- SIGSEGV signal info fault address (< 1 page above guard zone) --- <- Start of JVM reserved zone / guard zone | | JVM Reserved page | --- <- Start of JVM yellow zone | | JVM Yellow pages | --- <- Start of JVM red zone | | JVM Red page | --- <- Stack bottom | | Pthread guard page(s) | --- On my FreeBSD 11.3/amd64 machine the JVM uses a total of four pages for the guard zone (1 reserved, 2 yellow, 1 red). The page size is 4K, and I see the follow mprotect calls with truss: mprotect(stack bottom address, 4K, PROT_NONE) (Just the red zone) mprotect(stack bottom address, 16K, PROT_NONE) (The entire guard zone) mprotect(top of red zone address, 12K, PROT_READ|PROT_WRITE) (Reserved + yellow) mprotect(top of red zone address, 12K, PROT_NONE) (Reserved + yellow) While I've committed a workaround for openjdk8, which just rounds down the fault address, it isn't entirely satisfactory (it's a hack) and I wondered if anyone had any insight into what may be going on. I've done an analysis of the sizes and addresses being used and used truss to check the parameters to the mprotect calls, and everything appears to add up. The same problem also occurs under FreeBSD 12.0/i386 and on aarch64, so it doesn't appear to be either version or platform specific. I've simplified a little here, but am happy to provide additional details and code references. -- Greg From owner-freebsd-hackers@freebsd.org Mon Aug 12 17:41:03 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 57FB4BAB0B for ; Mon, 12 Aug 2019 17:41:03 +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) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 466jnB2gzpz4dk3 for ; Mon, 12 Aug 2019 17:41:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x7CHedOJ049783 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 12 Aug 2019 20:40:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x7CHedOJ049783 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x7CHedfi049782; Mon, 12 Aug 2019 20:40:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 12 Aug 2019 20:40:39 +0300 From: Konstantin Belousov To: Greg Lewis Cc: freebsd-hackers@freebsd.org Subject: Re: Java stack overflow segfaults Message-ID: <20190812174039.GE2738@kib.kiev.ua> References: <20190812161629.GA99971@misty.eyesbeyond.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190812161629.GA99971@misty.eyesbeyond.com> User-Agent: Mutt/1.12.1 (2019-06-15) 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 466jnB2gzpz4dk3 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.98 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.976,0]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(0.00)[ip: (-2.51), ipnet: 2001:470::/32(-4.49), asn: 6939(-3.02), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 17:41:03 -0000 On Mon, Aug 12, 2019 at 09:16:29AM -0700, Greg Lewis wrote: > Hi all, > > I'm investigating an issue where, on FreeBSD, Java will crash rather than > throw a StackOverflowError given a simple test program with a function > that just calls itself over and over. There's an example of such a test > in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222146 > > This affects, I suspect, every native version of Java in the ports tree, > although I've only tried openjdk8 and higher. My investigation has mostly > focused on openjdk11. > > To outline the situation, Java uses pthreads internally for threading. It > doesn't use the pthreads own guard page(s), but instead creates it's own > guard area at the bottom of the stack (which grows downward) using > mprotect. It then installs a signal handler and examines any SIGSEGV's > fault address to see if it falls within the guard area, and if so throws a > StackOverflowError. This logic is the same across all of the OSes I've > looked at and works on OpenBSD, Linux, etc. On FreeBSD though, the fault > address lies in the page above the guard zone, rather than in the guard > zone, which results in a crash rather than throwing StackOverflowError. > > An diagram may help here: > > --- <- Stack top > | > | Untouched memory + stack frames + etc. > | > | > | <-- SIGSEGV signal info fault address (< 1 page above guard zone) > --- <- Start of JVM reserved zone / guard zone > | > | JVM Reserved page > | > --- <- Start of JVM yellow zone > | > | JVM Yellow pages > | > --- <- Start of JVM red zone > | > | JVM Red page > | > --- <- Stack bottom > | > | Pthread guard page(s) > | > --- > > On my FreeBSD 11.3/amd64 machine the JVM uses a total of four pages for the > guard zone (1 reserved, 2 yellow, 1 red). The page size is 4K, and I see > the follow mprotect calls with truss: > > mprotect(stack bottom address, 4K, PROT_NONE) (Just the red zone) > mprotect(stack bottom address, 16K, PROT_NONE) (The entire guard zone) > mprotect(top of red zone address, 12K, PROT_READ|PROT_WRITE) (Reserved + yellow) > mprotect(top of red zone address, 12K, PROT_NONE) (Reserved + yellow) > > While I've committed a workaround for openjdk8, which just rounds down the > fault address, it isn't entirely satisfactory (it's a hack) and I wondered > if anyone had any insight into what may be going on. I've done an analysis > of the sizes and addresses being used and used truss to check the parameters > to the mprotect calls, and everything appears to add up. > > The same problem also occurs under FreeBSD 12.0/i386 and on aarch64, so it > doesn't appear to be either version or platform specific. I've simplified > a little here, but am happy to provide additional details and code > references. Can you provide me with the java class that demonstrates the issue ? What exact environment do I need to reproduce it ? Is amd64 stable/11 openjdk8 good enough ? From owner-freebsd-hackers@freebsd.org Tue Aug 13 03:33:10 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F1E13CA45F for ; Tue, 13 Aug 2019 03:33:10 +0000 (UTC) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (gerbercreations.com [71.39.140.16]) by mx1.freebsd.org (Postfix) with ESMTP id 466ywN4Xs3z4MNJ for ; Tue, 13 Aug 2019 03:33:08 +0000 (UTC) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (localhost.eyesbeyond.com [127.0.0.1]) by misty.eyesbeyond.com (8.15.2/8.15.2) with ESMTP id x7D3X65c085111 for ; Mon, 12 Aug 2019 20:33:06 -0700 (PDT) (envelope-from glewis@eyesbeyond.com) Received: (from glewis@localhost) by misty.eyesbeyond.com (8.15.2/8.15.2/Submit) id x7D3X5c5085110 for freebsd-hackers@freebsd.org; Mon, 12 Aug 2019 20:33:05 -0700 (PDT) (envelope-from glewis@eyesbeyond.com) X-Authentication-Warning: misty.eyesbeyond.com: glewis set sender to glewis@eyesbeyond.com using -f Date: Mon, 12 Aug 2019 20:33:05 -0700 From: Greg Lewis To: freebsd-hackers@freebsd.org Subject: Re: Java stack overflow segfaults Message-ID: <20190813033305.GA85090@misty.eyesbeyond.com> References: <20190812161629.GA99971@misty.eyesbeyond.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190812161629.GA99971@misty.eyesbeyond.com> User-Agent: Mutt/1.12.1 (2019-06-15) X-Rspamd-Queue-Id: 466ywN4Xs3z4MNJ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of glewis@eyesbeyond.com has no SPF policy when checking 71.39.140.16) smtp.mailfrom=glewis@eyesbeyond.com X-Spamd-Result: default: False [0.09 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.33)[-0.327,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.29)[-0.295,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; HAS_XAW(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; NEURAL_HAM_SHORT(-0.27)[-0.273,0]; DMARC_NA(0.00)[eyesbeyond.com]; R_SPF_NA(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209, ipnet:71.39.128.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-0.01)[asn: 209(-0.00), country: US(-0.05)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 03:33:11 -0000 On Mon, Aug 12, 2019 at 09:16:29AM -0700, Greg Lewis wrote: > I'm investigating an issue where, on FreeBSD, Java will crash rather than > throw a StackOverflowError given a simple test program with a function > that just calls itself over and over. There's an example of such a test > in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222146 > > This affects, I suspect, every native version of Java in the ports tree, > although I've only tried openjdk8 and higher. My investigation has mostly > focused on openjdk11. > > To outline the situation, Java uses pthreads internally for threading. It > doesn't use the pthreads own guard page(s), but instead creates it's own > guard area at the bottom of the stack (which grows downward) using > mprotect. It then installs a signal handler and examines any SIGSEGV's > fault address to see if it falls within the guard area, and if so throws a > StackOverflowError. This logic is the same across all of the OSes I've > looked at and works on OpenBSD, Linux, etc. On FreeBSD though, the fault > address lies in the page above the guard zone, rather than in the guard > zone, which results in a crash rather than throwing StackOverflowError. > > An diagram may help here: > > --- <- Stack top > | > | Untouched memory + stack frames + etc. > | > | > | <-- SIGSEGV signal info fault address (< 1 page above guard zone) > --- <- Start of JVM reserved zone / guard zone > | > | JVM Reserved page > | > --- <- Start of JVM yellow zone > | > | JVM Yellow pages > | > --- <- Start of JVM red zone > | > | JVM Red page > | > --- <- Stack bottom > | > | Pthread guard page(s) > | > --- > > On my FreeBSD 11.3/amd64 machine the JVM uses a total of four pages for the > guard zone (1 reserved, 2 yellow, 1 red). The page size is 4K, and I see > the follow mprotect calls with truss: > > mprotect(stack bottom address, 4K, PROT_NONE) (Just the red zone) > mprotect(stack bottom address, 16K, PROT_NONE) (The entire guard zone) > mprotect(top of red zone address, 12K, PROT_READ|PROT_WRITE) (Reserved + yellow) > mprotect(top of red zone address, 12K, PROT_NONE) (Reserved + yellow) > > While I've committed a workaround for openjdk8, which just rounds down the > fault address, it isn't entirely satisfactory (it's a hack) and I wondered > if anyone had any insight into what may be going on. I've done an analysis > of the sizes and addresses being used and used truss to check the parameters > to the mprotect calls, and everything appears to add up. > > The same problem also occurs under FreeBSD 12.0/i386 and on aarch64, so it > doesn't appear to be either version or platform specific. I've simplified > a little here, but am happy to provide additional details and code > references. This appears to be due to security.bsd.stack_guard_page and setting that to different values alters the extra space which may contain the fault address. -- Greg From owner-freebsd-hackers@freebsd.org Thu Aug 15 10:28:53 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A16C6CD620 for ; Thu, 15 Aug 2019 10:28:53 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 468N383ZtBz3CGJ for ; Thu, 15 Aug 2019 10:28:52 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x42b.google.com with SMTP id c3so1784933wrd.7 for ; Thu, 15 Aug 2019 03:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=unkdlgH0Khg4ULz4nFbreLCjjnzYd0FkpUYcjpO2Z7w=; b=vHNAHGTl64W7x91KH83jgU/VD5H1OwM2P7xCfPeMUyuCm4KEPpmaauA3k4WP855oox S0ZUXjDbShx1F28CX0iQfpkWA2ObhsqDhR3EtZCDa531JyP/pNr7xYbI+MBRp6P6veWn gzQnZMarlvptoKhwAfyzLk5wJpkj5FG5dMO/rH2HtCr0XwR6XRNG+UqINU1ZpIJT/2yA V5FNntuec8ejIq4U4DSscDWAHmkNRt1iwgTjX9dpuGebNctPbqxWEbRH6wCuI/aerpiV Uo4URYDypUu6IfcM9C7X18A8xzNFe3q9e4LRKdbx56hi1FW+L1EtR1pSfl9cXj90k9G6 qMaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=unkdlgH0Khg4ULz4nFbreLCjjnzYd0FkpUYcjpO2Z7w=; b=ahgPVOMHiL6lncYkUHI/hwvN6MU0fbmKwqLCo2iPsbU51HNPq4mChPKXcL6h8wsQGj 0/WrgSNqxS6+DkBfayMzjh2NlZxaoJqUFHddR8TIa+OUN5IsfBzlva17GPJiAvqiJV/C lqPEF12HzM+5iLaffQ3ECgNk8PFVvVHvdPr/FGvbKMZIYXQTYoiqEbVXsGzwoXykPDbA 6lpQLk6bhl7NDE9oKMcH6KyYRcUqi/wgh2/CIMQFyY6cVAimIiNpgdo9Q5Ivs+C52+eu KKMG/8Q0QSe0GY6/7teKhM558LGIQ5YVDlO+HjD+Xyj6kGOD3mEwBEhvlA0SQPfyjLY/ tYww== X-Gm-Message-State: APjAAAUSXvpoXEMfwGuPB/IUcY6+I+xux0pwnbnM0qb1Ef4nUcpRSqhF 4HgS4OlmYtW4KKTCvADvcfM9Bl9UWvs= X-Google-Smtp-Source: APXvYqxvD20UEbHW28sAxw71Kcf7kzPjH+dwqdOTYEU0U76U085jkBBEB5QqGf5/tBase11hiTJ+vQ== X-Received: by 2002:a5d:6b84:: with SMTP id n4mr4786544wrx.118.1565864930214; Thu, 15 Aug 2019 03:28:50 -0700 (PDT) Received: from [192.168.1.7] ([79.66.151.94]) by smtp.gmail.com with ESMTPSA id f70sm1792388wme.22.2019.08.15.03.28.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Aug 2019 03:28:49 -0700 (PDT) Subject: Re: please help translate smartctl output to human language To: freebsd-hackers@freebsd.org References: <3082DC9C-9D05-499F-A4FE-712338A32D14@freebsd.org> From: Graham Perrin Message-ID: <7bed2865-46c0-8649-d6b4-79a096f563c8@gmail.com> Date: Thu, 15 Aug 2019 11:28:47 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <3082DC9C-9D05-499F-A4FE-712338A32D14@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 468N383ZtBz3CGJ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=vHNAHGTl; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::42b as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.997,0]; RECEIVED_SPAMHAUS_PBL(0.00)[94.151.66.79.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.00)[ip: (-9.33), ipnet: 2a00:1450::/32(-3.03), asn: 15169(-2.38), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[b.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 10:28:53 -0000 Where the Reallocated_Sector_Ct RAW_VALUE comprises three values, two of which are in parentheses: - what are the two raw values in parentheses? A guess: are the two, in parentheses, representations of Current_Pending_Sector and Reallocated_Event_Count? Here, for example: root@momh167-gjp4-8570p:~ # smartctl -a /dev/ada0 | grep -E 'Reall|Pending'   5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail Always       -       24 (0 3) 196 Reallocated_Event_Count 0x0032   100   100   000    Old_age Always       -       3 197 Current_Pending_Sector  0x0032   100   100   000    Old_age Always       -       0 root@momh167-gjp4-8570p:~ # In context: From owner-freebsd-hackers@freebsd.org Thu Aug 15 17:05:28 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7AE40AF10F for ; Thu, 15 Aug 2019 17:05:28 +0000 (UTC) (envelope-from rpokala@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 468Xrm2f1tz45pf for ; Thu, 15 Aug 2019 17:05:28 +0000 (UTC) (envelope-from rpokala@freebsd.org) Received: from [172.17.133.228] (unknown [12.202.168.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: rpokala) by smtp.freebsd.org (Postfix) with ESMTPSA id F3FF04E5F for ; Thu, 15 Aug 2019 17:05:27 +0000 (UTC) (envelope-from rpokala@freebsd.org) User-Agent: Microsoft-MacOutlook/10.1b.0.190715 Date: Thu, 15 Aug 2019 10:05:24 -0700 Subject: Re: please help translate smartctl output to human language From: Ravi Pokala To: "freebsd-hackers@freebsd.org" Message-ID: <0D470EB1-D893-4855-B081-0351DB9FF93E@panasas.com> Thread-Topic: please help translate smartctl output to human language Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 17:05:28 -0000 > Date: Thu, 15 Aug 2019 11:28:47 +0100 > From: Graham Perrin > To: freebsd-hackers@freebsd.org > Subject: Re: please help translate smartctl output to human language > Message-ID: <7bed2865-46c0-8649-d6b4-79a096f563c8@gmail.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Where the Reallocated_Sector_Ct RAW_VALUE comprises three values, two of which are in parentheses: > > - what are the two raw values in parentheses? > > A guess: are the two, in parentheses, representations of > Current_Pending_Sector and Reallocated_Event_Count? This doesn't really have anything to do with FreeBSD, but rather with smartmontools. The short version is, the SMART "raw" value is a 48-bit value, which has different interpretations for different attributes. I happen to have a copy of the smartmontools source handy, so I did some quick `grep'ing. In drivedb.h, "Reallocated_Sector_Ct" by default uses the format string "raw16(raw16)". The manpage for `smartctl' reports: | raw16(raw16) - Print the raw attribute as a 16-bit value and two optional 16-bit values if these words are nonzero. This is the default for Attributes 5 and 196. In atacmds.cpp, "raw16(raw16)" is associated with RAWFMT_RAW16_OPT_RAW16, which goes to this code: | case RAWFMT_RAW16_OPT_RAW16: | s = strprintf("%u", word[0]); | if (word[1] || word[2]) | s += strprintf(" (%u %u)", word[2], word[1]); | break; So, it's treating the 48-bit value as three separate 16-bit words, and is reporting them separately. In your case, the value of the low 16-bits is 24 (0x0018), the value of the middle 16-bits is 3 (0x0003), and the value of the high 16-bits is 0 (0x0000). -Ravi (rpokala@) > Here, for example: > > root@momh167-gjp4-8570p:~ # smartctl -a /dev/ada0 | grep -E 'Reall|Pending' > ? 5 Reallocated_Sector_Ct?? 0x0033?? 100?? 100?? 005??? Pre-fail Always?????? -?????? 24 (0 3) > 196 Reallocated_Event_Count 0x0032?? 100?? 100?? 000??? Old_age Always?????? -?????? 3 > 197 Current_Pending_Sector? 0x0032?? 100?? 100?? 000??? Old_age Always?????? -?????? 0 > root@momh167-gjp4-8570p:~ # > > In context: > > > > From owner-freebsd-hackers@freebsd.org Fri Aug 16 07:23:08 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7F48EC29AA for ; Fri, 16 Aug 2019 07:23:08 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 468vtM56Mfz3PMg for ; Fri, 16 Aug 2019 07:23:07 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-pg1-f177.google.com with SMTP id n9so2517450pgc.1 for ; Fri, 16 Aug 2019 00:23:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:openpgp:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=KdoYBOYsng2RH4z5kF1kl6YbXdQV+8m+qFLvSZtJ7R0=; b=ktPYHSugtg4ayatk61WG7idr8Mjv3VIK2yg8zU6JXLUR6pa4l8/B4ncMlmq0IhadYy DbtYIiAo/HTzcZpIcfwYLUEhwmxxSMZXX/ujntOYz6Qur41bEKz2u+hz90hI77bLU0ox Glfbmmpi5DjGspPUbI+qWfbSo5BVspswlzlmTg3VjNfWiU+EGjIyg1C+QrGjSGpoYZWk 6q6YqhT3ZR712hKt4NuoW9OJjC7IBwtIkOnGS10vZ69knVDMufOxAXv9ETpmRiA61ucM CrMEfDtrquXJ8/68u8CMxIkA6zEyXnMwJIz+qxN42FNkh6vfQU9I87rHJhtk4AJeruNu F2bw== X-Gm-Message-State: APjAAAULD3WcJIg2zx1/lrosd0P4qWKRGXAtUXlOogjhBuuOtsYbQNHW K0Pa8z6KrjSYz0qBqxqaOOdTNA1u X-Google-Smtp-Source: APXvYqwbd0x5puqsTDK9uBiZ57HJdizMEOJ3sIl6xUASjilxu0fgXLZu8FuudXJxzTGXRORjXyGFxA== X-Received: by 2002:a63:fc09:: with SMTP id j9mr6279601pgi.377.1565940185328; Fri, 16 Aug 2019 00:23:05 -0700 (PDT) Received: from [192.168.1.36] (broadband-82-140-193-12.atc.tvcom.ru. [82.140.193.12]) by smtp.googlemail.com with ESMTPSA id h13sm5246240pfn.13.2019.08.16.00.23.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Aug 2019 00:23:04 -0700 (PDT) From: Andriy Gapon Subject: confused/concerned about ZFS / 64-bit atomics / 32-bit platforms To: freebsd-hackers@freebsd.org Openpgp: preference=signencrypt Message-ID: <8bbee981-4f95-22eb-d9ec-00267c8e111d@FreeBSD.org> Date: Fri, 16 Aug 2019 10:23:01 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 468vtM56Mfz3PMg X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.215.177 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-6.13 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-0.995,0]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[12.193.140.82.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; TO_DOM_EQ_FROM_DOM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-3.13)[ip: (-9.85), ipnet: 209.85.128.0/17(-3.37), asn: 15169(-2.38), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[177.215.85.209.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 07:23:08 -0000 I somewhat confused with respect to what guarantees C provides with respect to accessing 64-bit objects on 32-bit platforms, if any. I am also concerned about the use of 64-bit atomic values in ZFS given that FreeBSD seems to support ZFS on 32-bit platforms (powerpc, i386, ...). My concerns stems from a failed import of a ZFS change from illumos. That change has this pattern: volatile uint64_t *p; uint64_t x, y; ... x = *p; ... atomic_foo_64(p, y); Specifically, I am concerned that there can be a torn read in x=*p assignment on 32-bit platforms even if they provide a native implementation of atomic_foo_64(). I am even more concerned about platforms where atomic_foo_64() is not available and we need to emulate it in opensolaris_atomic.c with the help from atomic_mtx. In more general terms, I am concerned about plain reads of 64-bit variables that are manipulated atomically elsewhere, on 32-bit platforms. Is my concern justified? Note that I saw the above access pattern only in the code that is not imported yet. I only suspect that that pattern might already be present in the current ZFS/FreeBSD code given that it uses 64-bit variables and atomics a lot. I am not sure if there is a quick way to check that. Maybe devel/coccinelle could be used for that. -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Fri Aug 16 08:14:20 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5B77DC43CF for ; Fri, 16 Aug 2019 08:14:20 +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) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 468x1S0FDQz3wbx; Fri, 16 Aug 2019 08:14:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x7G8E6QQ035762 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 16 Aug 2019 11:14:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x7G8E6QQ035762 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x7G8E66b035761; Fri, 16 Aug 2019 11:14:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 16 Aug 2019 11:14:06 +0300 From: Konstantin Belousov To: Andriy Gapon Cc: freebsd-hackers@freebsd.org Subject: Re: confused/concerned about ZFS / 64-bit atomics / 32-bit platforms Message-ID: <20190816081406.GM2738@kib.kiev.ua> References: <8bbee981-4f95-22eb-d9ec-00267c8e111d@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8bbee981-4f95-22eb-d9ec-00267c8e111d@FreeBSD.org> User-Agent: Mutt/1.12.1 (2019-06-15) 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 468x1S0FDQz3wbx X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.94 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.94)[-0.939,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 08:14:20 -0000 On Fri, Aug 16, 2019 at 10:23:01AM +0300, Andriy Gapon wrote: > > I somewhat confused with respect to what guarantees C provides with > respect to accessing 64-bit objects on 32-bit platforms, if any. > I am also concerned about the use of 64-bit atomic values in ZFS given > that FreeBSD seems to support ZFS on 32-bit platforms (powerpc, i386, ...). > > My concerns stems from a failed import of a ZFS change from illumos. > That change has this pattern: > > volatile uint64_t *p; > uint64_t x, y; > ... > x = *p; > ... > atomic_foo_64(p, y); > > Specifically, I am concerned that there can be a torn read in x=*p > assignment on 32-bit platforms even if they provide a native > implementation of atomic_foo_64(). I am even more concerned about > platforms where atomic_foo_64() is not available and we need to emulate > it in opensolaris_atomic.c with the help from atomic_mtx. > > In more general terms, I am concerned about plain reads of 64-bit > variables that are manipulated atomically elsewhere, on 32-bit platforms. > Is my concern justified? Yes, your concerns are justified. Plain reads of 64bit variables on 32bit arches are not atomic. Also we do not provide e.g. atomic_load_64(9) on 32bit machines. On some architectures, there might be specific tricks to ensure atomicity of load and store for 64bit vars, e.g. on i386 (actually Pentium and newer) with use of of the CMPXCHG8 instruction, using it in dumb mode. ARM seems to provide LDREXD/STREXD. But AFAIK 32 ppc does not have any means to do it. > > Note that I saw the above access pattern only in the code that is not > imported yet. I only suspect that that pattern might already be present > in the current ZFS/FreeBSD code given that it uses 64-bit variables and > atomics a lot. > I am not sure if there is a quick way to check that. Maybe > devel/coccinelle could be used for that. > > -- > Andriy Gapon > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Fri Aug 16 13:32:28 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1D2BCCC800 for ; Fri, 16 Aug 2019 13:32:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46944W25ftz4Gnt for ; Fri, 16 Aug 2019 13:32:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x743.google.com with SMTP id s145so4679977qke.7 for ; Fri, 16 Aug 2019 06:32:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZzCZlSD930PVSdTOQGNkdijNEQWIoUByIpCF06D8ewE=; b=QFhbWYKuc/SUE2Nkakqq3hsoCJhqqs0glShvU0prWiCnlfdOR+Ud4rNQQXHWt9ltcj B5Dv1Z9C1wac8FXZzjE22CgqsF6qZRz1+XzUWp4YKVN3E+w3HPTUNzMWfpMegScZC5xZ KVlkiZsT02vNPdjNycNjWE61yZC452KXguGxBMXUkfVm5ItSSwK+HVYRwI3nD6b/weuy oVJUi5mEhfz21uFEIXj+FtZcGbxm49ljcHm92O//WwTcN1ftZc3ihYtl8ItLhCCmHoQT qS8VNjc3Y21faHtHWWJY3D1MkBVmWJ4KRtKOF1m634umGgqzMl1pMLFvJpPv+8hV5ejA hTTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZzCZlSD930PVSdTOQGNkdijNEQWIoUByIpCF06D8ewE=; b=GwMJFxXwLKVTv/mhbQHmJUXXSybGXFJpev7YYZS1oiwESVAMEhH1VMVDv8xrsUJDDX nlkSTsfvXLd4Wx3jfrB6wbGrRdwqaKeEmtYIw4dQUyEhIKPy+hoYXuL1FFZab11rzCHi PaPruTwSBof2L06LctXxgSjnK1vnUEF/HosCkUitsDXCh/FpfnTH4RHnR1gpmkyn9F+H ghqnEKbMHVn1bX4lwvC7EDtfqNj0GVfU5Rpn5MNt7Y+w0ogVviUV6m7N3Ut9Of6ePcRu B+pO4o846vPw5MBNsr3r5Hstra8vLhiDamL2HYCYx2pxm2ykcUnpqpdEwF8ds7anef9L tK8w== X-Gm-Message-State: APjAAAW0lLftpnJBSfbOUwq0D3fRza7r1bk38PD8funevFUx2Dov20O6 qujobPU57sFML1QTu/6KiJojKUWHwoBHnDGr9MEHxYg5G54= X-Google-Smtp-Source: APXvYqwfZApjaBT8lkI3PIUHg04d+CNEI5lgU9TPNyHe1vOcOq/q0jBpZ/VXsKMESM3WrcK1bkATEWFqp1VhjELpGZs= X-Received: by 2002:a37:9307:: with SMTP id v7mr8666846qkd.495.1565962346030; Fri, 16 Aug 2019 06:32:26 -0700 (PDT) MIME-Version: 1.0 References: <8bbee981-4f95-22eb-d9ec-00267c8e111d@FreeBSD.org> <20190816081406.GM2738@kib.kiev.ua> In-Reply-To: <20190816081406.GM2738@kib.kiev.ua> From: Warner Losh Date: Fri, 16 Aug 2019 07:32:15 -0600 Message-ID: Subject: Re: confused/concerned about ZFS / 64-bit atomics / 32-bit platforms To: Konstantin Belousov Cc: Andriy Gapon , "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: 46944W25ftz4Gnt X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=QFhbWYKu; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::743) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.46 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.98)[-0.980,0]; RCVD_IN_DNSWL_NONE(0.00)[3.4.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-0.48)[ip: (2.99), ipnet: 2607:f8b0::/32(-2.96), asn: 15169(-2.38), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 13:32:28 -0000 On Fri, Aug 16, 2019 at 2:14 AM Konstantin Belousov wrote: > On Fri, Aug 16, 2019 at 10:23:01AM +0300, Andriy Gapon wrote: > > > > I somewhat confused with respect to what guarantees C provides with > > respect to accessing 64-bit objects on 32-bit platforms, if any. > > I am also concerned about the use of 64-bit atomic values in ZFS given > > that FreeBSD seems to support ZFS on 32-bit platforms (powerpc, i386, > ...). > > > > My concerns stems from a failed import of a ZFS change from illumos. > > That change has this pattern: > > > > volatile uint64_t *p; > > uint64_t x, y; > > ... > > x = *p; > > ... > > atomic_foo_64(p, y); > > > > Specifically, I am concerned that there can be a torn read in x=*p > > assignment on 32-bit platforms even if they provide a native > > implementation of atomic_foo_64(). I am even more concerned about > > platforms where atomic_foo_64() is not available and we need to emulate > > it in opensolaris_atomic.c with the help from atomic_mtx. > > > > In more general terms, I am concerned about plain reads of 64-bit > > variables that are manipulated atomically elsewhere, on 32-bit platforms. > > Is my concern justified? > Yes, your concerns are justified. Plain reads of 64bit variables on 32bit > arches are not atomic. Also we do not provide e.g. atomic_load_64(9) on > 32bit machines. > Should we? I mean for those that support it? > On some architectures, there might be specific tricks to ensure > atomicity of load and store for 64bit vars, e.g. on i386 (actually > Pentium and newer) with use of of the CMPXCHG8 instruction, using it in > dumb mode. ARM seems to provide LDREXD/STREXD. But AFAIK 32 ppc does not > have any means to do it. > My take: On those platforms that can do 64-bit atomics can support this software, those that can't don't get support for this software. i386 and armv[67] are still big enough players that supporting ZFS on them is desirable (though not mandatory). Since they have the functions, we should enable building there and fix bugs that are identified. If there's too many, or they are too elusive, we might want to disable by default selectively. armv6, if it differs from armv7, is likely OK to mark ZFS as broken there given how little power / memory the PiB and Pi0 have as well as a lack of a good way to connect mass storage (just USB which exacerbates the power situation on systems where power is already fragile). PowerPC 32-bit really isn't setup for ZFS either. The systems tend to have less memory and don't tend to have a lot of disk. While it's nice to run ZFS in a single disk setup, UFS is adequate for those situations. Don't build file servers with FreeBSD 13 on this platform. We should mark it as broken here. We already do this with several drivers. mips can do 64-bit atomics on 32-bit platforms, but it's ugly via disabling interrupts (at least I think I committed those).... But even fewer people have 32-bit mips boxes that want ZFS too... We don't build ZFS on mips today, IIRC, so this is kinda moot. If ZFS needs this (now or in the future), and there's some atomics that are possible, but not yet implemented, on these 32-bit platforms, we should mark ZFS broken on those platforms and let their supporters fill in the gaps (though it would be nice to ask for help before doing this if its i386 or armv[67]). Warner > > > > Note that I saw the above access pattern only in the code that is not > > imported yet. I only suspect that that pattern might already be present > > in the current ZFS/FreeBSD code given that it uses 64-bit variables and > > atomics a lot. > > I am not sure if there is a quick way to check that. Maybe > > devel/coccinelle could be used for that. > > > > -- > > Andriy Gapon > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Fri Aug 16 13:48:58 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BD708CCC81 for ; Fri, 16 Aug 2019 13:48:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4694RY6DQsz4HT0 for ; Fri, 16 Aug 2019 13:48:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x743.google.com with SMTP id m2so4698536qki.12 for ; Fri, 16 Aug 2019 06:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=98kp5uhOb2vtoaf/g5P4gW3b16SQFQWFzirESJByJnk=; b=VB7ngsRblMyfohkcaCRPoAcdz8KsFD8Saat2KMglqKcTa9vJgN5WkPWs1oTtIhgimy 7lahNsOuPwAVL8SvL/2Zj89hsX3XD03hbi5GgbMx+oDdTTcbi3jaXDOlBP1TnygmRt5C eGcbbUpSZU6Xa6N4Su5gHTZsS7sMST79BabeY4Tj/p6YU2ZD+ZWq5w6RdKi2kJFA0Gtc MvCgbx/k1352+EleAQLqds83F1LmATPV9XgJiwVz0MO5Ygu9JWzqVNmTUtcap1j+KL9D TueAbRry6sdIwOktyaZCiAThveED0uHpv8O9oN589SvVedWUUcolFydrDkHj5A0YQ187 uFRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=98kp5uhOb2vtoaf/g5P4gW3b16SQFQWFzirESJByJnk=; b=faZlfKkgA4TAr/ixRWCo2vgY5TxMRM10ctNcslHlSWUh4t9PVrC0g3LH00awJcbFWc 4wr8ujvSrgVC0qmiK9WOiK8Keaw8VnVjrV/edbKxpFW1knlVROx/UMHrFnSLr+Q5lBBj QRvizNlSXrgvDDPHSS6VDL2ySdJvrwZTvTTbKVoaVSuPsPGYynCsiSqp5ma3Q6tsOlZP hie09qbvraTjIi5L4z7nptQ+9stto4+8g/PrvsOJe6z0XuNfUmBXUR+8fbepMHDvr4u0 wnlLC6UiyBVoRbhYi2dfXhfnjpJx0zlL3kBwE86BdiPxYeuEtiPPaYJdogIqw603ts9p bl6w== X-Gm-Message-State: APjAAAWuZzCVajv973nlTQgrCfxX6DOew21ZW7toVN9vzNfsxB7nAwPq h6yeyCW+50Ft+l4NDwnLbkFNj/tP9AIJ3wXajIMTQSrFQs0= X-Google-Smtp-Source: APXvYqyvtVQEwhkB6u8ZpryNzeU/CS6CLzrfdZd7wM61qSoaHZ1stFKmpW9s5gsoV1sTuWgdmx/7XdT5EJc+FecVYoE= X-Received: by 2002:a37:4b03:: with SMTP id y3mr1140684qka.215.1565963336661; Fri, 16 Aug 2019 06:48:56 -0700 (PDT) MIME-Version: 1.0 References: <8bbee981-4f95-22eb-d9ec-00267c8e111d@FreeBSD.org> <20190816081406.GM2738@kib.kiev.ua> In-Reply-To: From: Warner Losh Date: Fri, 16 Aug 2019 07:48:45 -0600 Message-ID: Subject: Re: confused/concerned about ZFS / 64-bit atomics / 32-bit platforms To: Konstantin Belousov Cc: Andriy Gapon , "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: 4694RY6DQsz4HT0 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=VB7ngsRb; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::743) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.46 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.98)[-0.980,0]; RCVD_IN_DNSWL_NONE(0.00)[3.4.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-0.48)[ip: (2.98), ipnet: 2607:f8b0::/32(-2.96), asn: 15169(-2.38), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 13:48:58 -0000 [[ sorry to followup, but had a followup thought ]] On Fri, Aug 16, 2019 at 7:32 AM Warner Losh wrote: > > > On Fri, Aug 16, 2019 at 2:14 AM Konstantin Belousov > wrote: > >> On Fri, Aug 16, 2019 at 10:23:01AM +0300, Andriy Gapon wrote: >> > >> > I somewhat confused with respect to what guarantees C provides with >> > respect to accessing 64-bit objects on 32-bit platforms, if any. >> > I am also concerned about the use of 64-bit atomic values in ZFS given >> > that FreeBSD seems to support ZFS on 32-bit platforms (powerpc, i386, >> ...). >> > >> > My concerns stems from a failed import of a ZFS change from illumos. >> > That change has this pattern: >> > >> > volatile uint64_t *p; >> > uint64_t x, y; >> > ... >> > x = *p; >> > ... >> > atomic_foo_64(p, y); >> > >> > Specifically, I am concerned that there can be a torn read in x=*p >> > assignment on 32-bit platforms even if they provide a native >> > implementation of atomic_foo_64(). I am even more concerned about >> > platforms where atomic_foo_64() is not available and we need to emulate >> > it in opensolaris_atomic.c with the help from atomic_mtx. >> > >> > In more general terms, I am concerned about plain reads of 64-bit >> > variables that are manipulated atomically elsewhere, on 32-bit >> platforms. >> > Is my concern justified? >> Yes, your concerns are justified. Plain reads of 64bit variables on 32bit >> arches are not atomic. Also we do not provide e.g. atomic_load_64(9) on >> 32bit machines. >> > > Should we? I mean for those that support it? > Or is the practice pervasive enough that we can't hope to catch them all and we should just mark ZFS broken on all 32-bit platforms because even though it compiles, the torn-write and other cases are too hard to detect and too pervasive to support? > On some architectures, there might be specific tricks to ensure >> atomicity of load and store for 64bit vars, e.g. on i386 (actually >> Pentium and newer) with use of of the CMPXCHG8 instruction, using it in >> dumb mode. ARM seems to provide LDREXD/STREXD. But AFAIK 32 ppc does not >> have any means to do it. >> > > My take: On those platforms that can do 64-bit atomics can support this > software, those that can't don't get support for this software. > > i386 and armv[67] are still big enough players that supporting ZFS on them > is desirable (though not mandatory). Since they have the functions, we > should enable building there and fix bugs that are identified. If there's > too many, or they are too elusive, we might want to disable by default > selectively. armv6, if it differs from armv7, is likely OK to mark ZFS as > broken there given how little power / memory the PiB and Pi0 have as well > as a lack of a good way to connect mass storage (just USB which exacerbates > the power situation on systems where power is already fragile). > > PowerPC 32-bit really isn't setup for ZFS either. The systems tend to have > less memory and don't tend to have a lot of disk. While it's nice to run > ZFS in a single disk setup, UFS is adequate for those situations. Don't > build file servers with FreeBSD 13 on this platform. We should mark it as > broken here. We already do this with several drivers. > > mips can do 64-bit atomics on 32-bit platforms, but it's ugly via > disabling interrupts (at least I think I committed those).... But even > fewer people have 32-bit mips boxes that want ZFS too... We don't build ZFS > on mips today, IIRC, so this is kinda moot. > > If ZFS needs this (now or in the future), and there's some atomics that > are possible, but not yet implemented, on these 32-bit platforms, we > should mark ZFS broken on those platforms and let their supporters fill in > the gaps (though it would be nice to ask for help before doing this if its > i386 or armv[67]). > > Warner > > >> > >> > Note that I saw the above access pattern only in the code that is not >> > imported yet. I only suspect that that pattern might already be present >> > in the current ZFS/FreeBSD code given that it uses 64-bit variables and >> > atomics a lot. >> > I am not sure if there is a quick way to check that. Maybe >> > devel/coccinelle could be used for that. >> > >> > -- >> > Andriy Gapon >> > _______________________________________________ >> > freebsd-hackers@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> > To unsubscribe, send any mail to " >> freebsd-hackers-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org >> " >> > From owner-freebsd-hackers@freebsd.org Fri Aug 16 13:54:14 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B8637CD050 for ; Fri, 16 Aug 2019 13:54:14 +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) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4694Yd5mGlz4J28; Fri, 16 Aug 2019 13:54:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x7GDs4Tm014998 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 16 Aug 2019 16:54:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x7GDs4Tm014998 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x7GDs4Kn014997; Fri, 16 Aug 2019 16:54:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 16 Aug 2019 16:54:04 +0300 From: Konstantin Belousov To: Warner Losh Cc: Andriy Gapon , "freebsd-hackers@freebsd.org" Subject: Re: confused/concerned about ZFS / 64-bit atomics / 32-bit platforms Message-ID: <20190816135404.GB71821@kib.kiev.ua> References: <8bbee981-4f95-22eb-d9ec-00267c8e111d@FreeBSD.org> <20190816081406.GM2738@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 4694Yd5mGlz4J28 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.96 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_SOFTFAIL(0.00)[~all]; IP_SCORE_FREEMAIL(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.955,0]; IP_SCORE(0.00)[ip: (-2.55), ipnet: 2001:470::/32(-4.47), asn: 6939(-3.04), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 13:54:14 -0000 On Fri, Aug 16, 2019 at 07:32:15AM -0600, Warner Losh wrote: > On Fri, Aug 16, 2019 at 2:14 AM Konstantin Belousov > wrote: > > > On Fri, Aug 16, 2019 at 10:23:01AM +0300, Andriy Gapon wrote: > > > > > > I somewhat confused with respect to what guarantees C provides with > > > respect to accessing 64-bit objects on 32-bit platforms, if any. > > > I am also concerned about the use of 64-bit atomic values in ZFS given > > > that FreeBSD seems to support ZFS on 32-bit platforms (powerpc, i386, > > ...). > > > > > > My concerns stems from a failed import of a ZFS change from illumos. > > > That change has this pattern: > > > > > > volatile uint64_t *p; > > > uint64_t x, y; > > > ... > > > x = *p; > > > ... > > > atomic_foo_64(p, y); > > > > > > Specifically, I am concerned that there can be a torn read in x=*p > > > assignment on 32-bit platforms even if they provide a native > > > implementation of atomic_foo_64(). I am even more concerned about > > > platforms where atomic_foo_64() is not available and we need to emulate > > > it in opensolaris_atomic.c with the help from atomic_mtx. > > > > > > In more general terms, I am concerned about plain reads of 64-bit > > > variables that are manipulated atomically elsewhere, on 32-bit platforms. > > > Is my concern justified? > > Yes, your concerns are justified. Plain reads of 64bit variables on 32bit > > arches are not atomic. Also we do not provide e.g. atomic_load_64(9) on > > 32bit machines. > > > > Should we? I mean for those that support it? For i386 the implementation is trivial, I put the patch below, not tested. For arm, apparently there is atomic_load_64/atomic_store_64 already. > > > > On some architectures, there might be specific tricks to ensure > > atomicity of load and store for 64bit vars, e.g. on i386 (actually > > Pentium and newer) with use of of the CMPXCHG8 instruction, using it in > > dumb mode. ARM seems to provide LDREXD/STREXD. But AFAIK 32 ppc does not > > have any means to do it. > > > > My take: On those platforms that can do 64-bit atomics can support this > software, those that can't don't get support for this software. > > i386 and armv[67] are still big enough players that supporting ZFS on them > is desirable (though not mandatory). Since they have the functions, we > should enable building there and fix bugs that are identified. If there's > too many, or they are too elusive, we might want to disable by default > selectively. armv6, if it differs from armv7, is likely OK to mark ZFS as > broken there given how little power / memory the PiB and Pi0 have as well > as a lack of a good way to connect mass storage (just USB which exacerbates > the power situation on systems where power is already fragile). > > PowerPC 32-bit really isn't setup for ZFS either. The systems tend to have > less memory and don't tend to have a lot of disk. While it's nice to run > ZFS in a single disk setup, UFS is adequate for those situations. Don't > build file servers with FreeBSD 13 on this platform. We should mark it as > broken here. We already do this with several drivers. > > mips can do 64-bit atomics on 32-bit platforms, but it's ugly via disabling > interrupts (at least I think I committed those).... But even fewer people > have 32-bit mips boxes that want ZFS too... We don't build ZFS on mips > today, IIRC, so this is kinda moot. > > If ZFS needs this (now or in the future), and there's some atomics that are > possible, but not yet implemented, on these 32-bit platforms, we should > mark ZFS broken on those platforms and let their supporters fill in the > gaps (though it would be nice to ask for help before doing this if its i386 > or armv[67]). diff --git a/sys/i386/include/atomic.h b/sys/i386/include/atomic.h index 0d673af7358..ee2fa421ff8 100644 --- a/sys/i386/include/atomic.h +++ b/sys/i386/include/atomic.h @@ -891,6 +891,8 @@ u_long atomic_swap_long(volatile u_long *p, u_long v); #define atomic_add_rel_64 atomic_add_64 #define atomic_subtract_acq_64 atomic_subtract_64 #define atomic_subtract_rel_64 atomic_subtract_64 +#define atomic_load_64 atomic_load_acq_64 +#define atomic_store_64 atomic_store_rel_64 /* Operations on pointers. */ #define atomic_set_ptr(p, v) \ From owner-freebsd-hackers@freebsd.org Fri Aug 16 17:16:23 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 297D5A91C1 for ; Fri, 16 Aug 2019 17:16:23 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46992t2Lpvz4Tn9 for ; Fri, 16 Aug 2019 17:16:22 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: by mail-wr1-x436.google.com with SMTP id t16so2223692wra.6 for ; Fri, 16 Aug 2019 10:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=No9X/PuMlvorZAFvrBTy5W0y28W0CxmL1jsvlqyoJVA=; b=mP79yCAktarv84oSZw1Hsr7XzE/tIdQYkKUJbQt8D3hkZWPhdjHcHKlr33U2dhPj+h 7FIjwyXpXRllzrQlF7OjowHDJ2bFXqcoCVvOhhN/xqiKL9xz2Er6UVFYUNIdayu5zQcM PsSMdGOo1aaOvLrm4SdFfik+l9zZPcVGHLJz9nehVoHo/Y6Pawp3VB+jZLR7bCQzwQ3v t+WwfE5WI7GqjFpkNrYX++nyjxXqH5Gy6BFMmUmzJLhXtazI5jOHQJv34AZ8kFV88R+/ wEX+Y6czLUbUkhyQaQ1bcf48CFHhIPvgr3pdWtfGW8JSW3kki3SjN6Mgz1oH25SGKssE HgCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=No9X/PuMlvorZAFvrBTy5W0y28W0CxmL1jsvlqyoJVA=; b=r4/KzLQ0FVBuhQeI61HvoEYRdbwDK6poKSBcP8nrYrDyoO8BpJhqsIVMNyv40vAxvv xk1Nn/Ih/SbgvRmS0l4lHZGvIyx/8hUM4JWMGycy4D65pSSVD65BIXVlEl6lHh0SOmyG w/d44c3CHnavifknj2tNXO7wE2RVC5+iWP51PkEgLK4tOYwOybgt9Nul3MHkcEllpvAA wLQyKd/mjcmhgrNaMs9iu7DGYPy/vqBsCtxOiy57K2BkoGVv17Y7nvht70B8kw2mUiYx VR58M8B4MSGH/2OpKFbWHTNuXLw0kBD43aaEWmepf5ja+jewaoAipGaAkrb7wM4GqWQn xb5g== X-Gm-Message-State: APjAAAWV67Cpo5GbNGH5A6bU8EU5W05AuIEwZBGuetrg9/AxMYxgbwkP wS5fLVMtBekljx8SlMOys2CE4fcowirHSZM2IsdTSVY4 X-Google-Smtp-Source: APXvYqzfSgGmlQzdJ5bonoytPZufcr1A004nj9fUYk6unJa2QU+Uh6eVWmX+eRi0YJG4T/gokXh/7toGnXRcr+GvBwM= X-Received: by 2002:a05:6000:1085:: with SMTP id y5mr12178969wrw.285.1565975776708; Fri, 16 Aug 2019 10:16:16 -0700 (PDT) MIME-Version: 1.0 From: Shrikanth Kamath Date: Fri, 16 Aug 2019 10:16:05 -0700 Message-ID: Subject: Reclaiming "dirty buffers" after seeing "fsync: giving up on dirty..." / Unplugging USB while copy in progress To: freebsd-hackers@freebsd.org X-Rspamd-Queue-Id: 46992t2Lpvz4Tn9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=mP79yCAk; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of shrikanth07@gmail.com designates 2a00:1450:4864:20::436 as permitted sender) smtp.mailfrom=shrikanth07@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(0.00)[ip: (-9.21), ipnet: 2a00:1450::/32(-3.03), asn: 15169(-2.38), country: US(-0.05)]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[6.3.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-1.00)[-0.998,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 17:16:23 -0000 How do =E2=80=9Clingering=E2=80=9D dirty buffers get reclaimed? In the func= tion vop_stdfsync there is logic to retry but eventually fail after =E2=80=9Cmax= retry=E2=80=9D and print =E2=80=9Cfsync: giving up on dirty (error =E2=80=9C while returni= ng the error. In a scenario where a USB stick is plugged in and a large file (> 1.5G) is being copied to it from the host filesystem when the USB device is abruptly removed. I see the fsync function retrying for a number of times before returning with the below error fsync: giving up on dirty 0xfffff8058091d1d8: tag devfs, type VCHR usecount 1, writecount 0, refcount 1070 mountedhere 0xfffff805808af800 flags (VI_DOOMED|VI_ACTIVE) v_object 0xfffff807a6efe948 ref 0 pages 1069 cleanbuf 893 dirtybuf 174 lock type devfs: EXCL by thread 0xfffff8009aebb560 (pid 6463, chassisd, tid 100270) What is eventually happening is there are other processes that start appearing to be stuck waiting in =E2=80=9Cflswai=E2=80=9D state (including = the copy operation to the USB stick). # ps jaux -o mwchan -o command | grep flswai 6423 1 6423 6423 0 Ds - 0:02.35 /usr/sbin/eventd 0.0 0.0 744768 12916 06:22 flswai /usr/sbin/eventd -r -s -A 6463 6428 6427 6427 0 D - 8:25.69 /usr/sbin/chassi 0.0 0.1 862940 56472 06:22 flswai /usr/sbin/chassisd -N 19753 19195 19753 6453 1 D+ u0 0:01.08 cp junos-vmhost- 0.0 0.0 8164 2968 12:13 flswai cp junos-vmhost-install-mx-x86-64-19.3I-14062-TB-130172-_cd-builder.tgz /mnt/ Looking at the code, this seems to be coming from the =E2=80=9Cbwillwrite= =E2=80=9D function (sys/kern/vfs_bio.c) where it explains it will block prior to =E2=80=9C=E2= =80=A6locking of any vnodes we attempt to avoid the situation where a locked vnode prevents the various system daemons from flushing related buffers=E2=80=A6=E2=80=9D = How does the dirty buffers in this scenario get reclaimed? The dmesg log is from a Juniper device running stable/11 (closer to 11.1ish) based Junos. Jul 23 12:06:31.740 da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 Jul 23 12:06:31.740 da0: s/n AA04012700046751 detached Jul 23 12:06:31.740 g_vfs_done():da0p1[WRITE(offset=3D272711680, length=3D65536)]error =3D 6 ... Jul 23 12:06:31.943 g_vfs_done():da0p1[WRITE(offset=3D277626880, length=3D65536)]error =3D 6 ... Jul 23 12:06:31.992 g_vfs_done():da0p1[WRITE(offset=3D281624576, length=3D65536)]error =3D 6 ... Jul 23 12:06:32.144 g_vfs_done():da0p1[WRITE(offset=3D285687808, length=3D65536)]error =3D 6 Jul 23 12:06:32.144 (da0:umass-sim0:0:0:0): Periph destroyed Jul 23 12:06:32.144 umass0: detached Jul 23 12:06:36.672 fsync: giving up on dirty 0xfffff8058091d1d8: tag devfs, type VCHR Jul 23 12:06:36.672 usecount 1, writecount 0, refcount 1070 mountedhere 0xfffff805808af800 Jul 23 12:06:36.672 flags (VI_DOOMED|VI_ACTIVE) Jul 23 12:06:36.672 v_object 0xfffff807a6efe948 ref 0 pages 1069 cleanbuf 893 dirtybuf 174 -- Shrikanth R K From owner-freebsd-hackers@freebsd.org Fri Aug 16 19:00:00 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A1578ABBF9 for ; Fri, 16 Aug 2019 19:00:00 +0000 (UTC) (envelope-from kib@freebsd.org) 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) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 469CLS0mJ6z4dJV for ; Fri, 16 Aug 2019 18:59:59 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x7GIxql8086776 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 16 Aug 2019 21:59:55 +0300 (EEST) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x7GIxql8086776 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x7GIxq7u086775; Fri, 16 Aug 2019 21:59:52 +0300 (EEST) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Fri, 16 Aug 2019 21:59:52 +0300 From: Konstantin Belousov To: Shrikanth Kamath Cc: freebsd-hackers@freebsd.org Subject: Re: Reclaiming "dirty buffers" after seeing "fsync: giving up on dirty..." / Unplugging USB while copy in progress Message-ID: <20190816185952.GF71821@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 469CLS0mJ6z4dJV X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.974,0]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 19:00:00 -0000 On Fri, Aug 16, 2019 at 10:16:05AM -0700, Shrikanth Kamath wrote: > How do “lingering” dirty buffers get reclaimed? In the function > vop_stdfsync there is logic to retry but eventually fail after “maxretry” > and print “fsync: giving up on dirty (error “ while returning the error. In > a scenario where a USB stick is plugged in and a large file (> 1.5G) is > being copied to it from the host filesystem when the USB device is abruptly > removed. I see the fsync function retrying for a number of times before > returning with the below error > > fsync: giving up on dirty 0xfffff8058091d1d8: tag devfs, type VCHR > > usecount 1, writecount 0, refcount 1070 mountedhere 0xfffff805808af800 > > flags (VI_DOOMED|VI_ACTIVE) > > v_object 0xfffff807a6efe948 ref 0 pages 1069 cleanbuf 893 dirtybuf 174 > > lock type devfs: EXCL by thread 0xfffff8009aebb560 (pid 6463, chassisd, > tid 100270) > > What is eventually happening is there are other processes that start > appearing to be stuck waiting in “flswai” state (including the copy > operation to the USB stick). > > # ps jaux -o mwchan -o command | grep flswai > 6423 1 6423 6423 0 Ds - 0:02.35 /usr/sbin/eventd > 0.0 0.0 744768 12916 06:22 flswai /usr/sbin/eventd -r -s -A > 6463 6428 6427 6427 0 D - 8:25.69 /usr/sbin/chassi 0.0 > 0.1 862940 56472 06:22 flswai /usr/sbin/chassisd -N > 19753 19195 19753 6453 1 D+ u0 0:01.08 cp junos-vmhost- 0.0 > 0.0 8164 2968 12:13 flswai cp > junos-vmhost-install-mx-x86-64-19.3I-14062-TB-130172-_cd-builder.tgz /mnt/ > > Looking at the code, this seems to be coming from the “bwillwrite” function > (sys/kern/vfs_bio.c) where it explains it will block prior to “…locking of > any vnodes we attempt to avoid the situation where a locked vnode prevents > the various system daemons from flushing related buffers…” How does the > dirty buffers in this scenario get reclaimed? > > The dmesg log is from a Juniper device running stable/11 (closer to > 11.1ish) based Junos. > > Jul 23 12:06:31.740 da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 > > Jul 23 12:06:31.740 da0: s/n > AA04012700046751 detached > Jul 23 12:06:31.740 g_vfs_done():da0p1[WRITE(offset=272711680, > length=65536)]error = 6 > ... > > Jul 23 12:06:31.943 g_vfs_done():da0p1[WRITE(offset=277626880, > length=65536)]error = 6 > ... > > Jul 23 12:06:31.992 g_vfs_done():da0p1[WRITE(offset=281624576, > length=65536)]error = 6 > ... > > Jul 23 12:06:32.144 g_vfs_done():da0p1[WRITE(offset=285687808, > length=65536)]error = 6 > Jul 23 12:06:32.144 (da0:umass-sim0:0:0:0): Periph destroyed > > Jul 23 12:06:32.144 umass0: detached > > Jul 23 12:06:36.672 fsync: giving up on dirty 0xfffff8058091d1d8: tag > devfs, type VCHR > Jul 23 12:06:36.672 usecount 1, writecount 0, refcount 1070 > mountedhere 0xfffff805808af800 > Jul 23 12:06:36.672 flags (VI_DOOMED|VI_ACTIVE) > > Jul 23 12:06:36.672 v_object 0xfffff807a6efe948 ref 0 pages 1069 > cleanbuf 893 dirtybuf 174 What I describe below is relevant for HEAD, and might be absent in 11. After the io finished with whatever results, brelse(9) is called by some means. There, if io finished with an error, and the error is ENXIO, which is believed to mean that the device went away, the buffer is marked as B_INVAL and truncated. Then the normal flow in brelse() causes the buffer return to the freelist. A large unsolved issue is that if the buffer was used by UFS with softupdates and there are unfinished dependencies hanging from the buffer, system checks that and panics. You should not use SU on USB stick anyway. From owner-freebsd-hackers@freebsd.org Sat Aug 17 13:08:36 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E59E6C6C92 for ; Sat, 17 Aug 2019 13:08:36 +0000 (UTC) (envelope-from gbergling@gmail.com) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 469gVW2WJPz4Lh1 for ; Sat, 17 Aug 2019 13:08:35 +0000 (UTC) (envelope-from gbergling@gmail.com) Received: by mail-wm1-x32d.google.com with SMTP id o4so6149527wmh.2 for ; Sat, 17 Aug 2019 06:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=BxlE8YmDDp1bB/0MjXXQVKzThjXr40bw8MmeHFjU9RY=; b=W6haprRGwxzSL6Jz02BrhD9HA8B9KNwcOHUPRiw763w17XluWwyoO+WssPeTYn9YsZ GzwUcZbs/JmKQNuh27QsXIaD7f36tDBEb46z/60e5y6MUhxbQq43lPTxb9V8Wqk1oT09 Jo82JDwZorq2LvzQTVdGk2pM4J2XnNvOlxIs52uIRhzHHFSQwVTbL3t73B5xSQ6dLmPO rl1ewiX6yHZOzinWsa7ELfNJewrzz5Ep9npc6Crbbyrdh6jomY9HVGTlGetRIk24rfrM oplM2cwkGoXDhUsONbclf29RcT6uaIXEG76mCDVghpNS9R2ny3W8m4Thb3MQrYnwB7lY rabA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=BxlE8YmDDp1bB/0MjXXQVKzThjXr40bw8MmeHFjU9RY=; b=X3q8DPxlEVKY3iJSljFdjyCCi539zaZd3+CT9Thme8noQaEIEJNRy+nd3Khf4F8F03 6zzvkDQoo4UGDIbdBfKv+pwrquQxkEGTP2kRWUAE//WIZFgahoYw6ChJsVNoTzooN2OQ RfZNbkPiflPCboqmH+pZx3oVDIkVyrYFUmURslUrkk2HJFw/jF3Oedp8q0bbLCQFEiYN xeCAStHETB/NPtLEC1tJ1lFd2+YJmvGJUqEhc2GHtJj7weMWuUFnsgup7A8FknGCrp+9 a7xvywlJelnyle+Go39DX56wrs/t/RHV8fb79VvPaaQ/VcMQmtrz2IK78MWdOWWsVRlf 1Yfg== X-Gm-Message-State: APjAAAX/s+84QgAYs4B1bzskejgckuZHTqBXPA4wV3eI3z6/zNLqUumB veaLsCZCLB0OMsYl+qF+60uzrpEi X-Google-Smtp-Source: APXvYqyvz84GRCN9o1wE3HupHasmE13IYD815t+sfmDjjA486uV6rWXMa3wY4Z4TLGYAYo7KbyshLg== X-Received: by 2002:a1c:a957:: with SMTP id s84mr11749249wme.65.1566047312643; Sat, 17 Aug 2019 06:08:32 -0700 (PDT) Received: from [10.0.1.106] (p4FD3AB4E.dip0.t-ipconnect.de. [79.211.171.78]) by smtp.gmail.com with ESMTPSA id e13sm7005354wmh.44.2019.08.17.06.08.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Aug 2019 06:08:31 -0700 (PDT) From: Gordon Bergling Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: uname -a default options Message-Id: Date: Sat, 17 Aug 2019 15:08:30 +0200 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 469gVW2WJPz4Lh1 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=W6haprRG; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gbergling@gmail.com designates 2a00:1450:4864:20::32d as permitted sender) smtp.mailfrom=gbergling@gmail.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.997,0]; RECEIVED_SPAMHAUS_PBL(0.00)[78.171.211.79.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.00)[ip: (-9.26), ipnet: 2a00:1450::/32(-3.03), asn: 15169(-2.38), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[d.2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2019 13:08:37 -0000 Hello List, "uname -a" is currently mapping the -a option to =E2=80=9E-mnrsv=E2=80=9C,= which results in something similar like $ uname -a FreeBSD lion.0xfce3.net 12.0-STABLE FreeBSD = 12.0-STABLE r350835 GENERIC amd64 What would you think about reducing the option mapping for =E2=80=9E-a=E2=80= =9C to =E2=80=9E-vmn=E2=80=9C , which would result in a less repetitive = version string like the one below. $ uname -vmn lion.0xfce3.net FreeBSD 12.0-STABLE r350835 = GENERIC amd64 Adapting this would be trivial, but before I hack something together, I = would like to get some feedback if such a change would be welcomed? Best regards, Gordon= From owner-freebsd-hackers@freebsd.org Sat Aug 17 14:21:26 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 70A41C89F8 for ; Sat, 17 Aug 2019 14:21:26 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 469j6Y4Jb6z4Pyk for ; Sat, 17 Aug 2019 14:21:25 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1566051684; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=q0MK6sZpBoEIZCvjbBU2lx52i3kpKG6RxV/3zAFMVe9R7/gjJwaUBGIPBe2R8cSeGrCs17Zaf8gYN +HwU+6Vlsnoes65eTR9JEDwvWCRHhhNohrfeaXf1DsRzmhEd5RDc+996p2/CHjFvjuAgM5d/Jwh/Lg CUSheMVI1UlXDR39yvr55eIMFxmcOqeF7pBFGLN0DkdiFzFFAADt+4WqBZJ6udYHxvhvptQMkEi+I+ c/0hCHRACMDNKNNURgd+81/MGtrMzS6rrqWTFwyrTFFUhE9jIuaOnYqT5kxoQ1podyFM38N9WnU1kZ XLtDIPoPyVXp0cywdluWweB8VISPG6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=rgMiVK+y680YecSu4JWb2prq5vO1yLyGDpdEgrcy3Ig=; b=SyDSEnn5a0vkosHT3FcuIkCaApTOSzQHwFb9kEnEwIAr25+flmf5opkKcjDbGLpTPouBSRatrw/Fs nJcJ9cxaxXav35wHriZhSDEadKJs2wjKClvhqJkmpNzyYYV8bbKIQh3/fQ1INP8QFszQOLccC6h1qX idmCFKK+ty2XPEx9JhgQ9J3atla2VHKahBQ9cmt3z7BY26ZryKRExTroic6XB+whLqJNafCw9JPgxB wNi4wFVKUKESChfA23twrkB0C9HfYZWChQcixbY36j1w/oITY2MzRnE8Uc9Y5csN0szfSQBySqQZlO 9/O/PFT4k3huoC/E0DSfgZnjMHsFKuQ== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=rgMiVK+y680YecSu4JWb2prq5vO1yLyGDpdEgrcy3Ig=; b=GGBI+Kog6LWzFZHRb9voRWse3+wp+ack82iCqZNLCZm9oc4/A26RNtQKn5ZgQyxzaE/lSY7KlmaW4 JZMZvwXJ+4rDPFr7GNxp+6tJlbZY1m/6Auh87DJeYWoKDK84vJz7W2ekgUKhiSs7pGJBseb//xZmkw yUOSjyQfPd18RQQ8wbtJAEpcHBGeDRyGHWy1+LNqEOOC2frLccBlegXcb2IBDCoyRsI9XnDfVPJiDb uJYxPgjR+P6oscZVbRsvX7n0medhRAbDVIKH9qorgP/20rCEUkbFOSMhwWdhS+5B6puPIQfiIWFl/r r3vG2bIFaZxGdmCttyD3FNds9JxOw6g== X-MHO-RoutePath: aGlwcGll X-MHO-User: 49753d81-c0fa-11e9-b67b-cdd75d6ce7a8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 49753d81-c0fa-11e9-b67b-cdd75d6ce7a8; Sat, 17 Aug 2019 14:21:23 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x7HELLAS068210; Sat, 17 Aug 2019 08:21:21 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <7d1f88943c0b744920d7181df51b76675d145f18.camel@freebsd.org> Subject: Re: uname -a default options From: Ian Lepore To: Gordon Bergling , freebsd-hackers@freebsd.org Date: Sat, 17 Aug 2019 08:21:21 -0600 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 469j6Y4Jb6z4Pyk X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.984,0]; ASN(0.00)[asn:16509, ipnet:54.186.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2019 14:21:26 -0000 On Sat, 2019-08-17 at 15:08 +0200, Gordon Bergling wrote: > Hello List, > > "uname -a" is currently mapping the -a option to „-mnrsv“, which > results in something similar like > > $ uname -a > FreeBSD lion.0xfce3.net 12.0-STABLE FreeBSD > 12.0-STABLE r350835 GENERIC amd64 > > What would you think about reducing the option mapping for „-a“ to „- > vmn“ , which would result in a less repetitive version string like > the one below. > > $ uname -vmn > lion.0xfce3.net FreeBSD 12.0-STABLE r350835 > GENERIC amd64 > > Adapting this would be trivial, but before I hack something together, > I would like to get some feedback if such a change would be welcomed? > > Best regards, > > Gordon > I think there are likely very many existing scripts in the world that parse the output of uname -a and would break if the fields moved around or disappeared. -- Ian From owner-freebsd-hackers@freebsd.org Sat Aug 17 16:16:47 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A7DDACB305 for ; Sat, 17 Aug 2019 16:16:47 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 469lgg2sJvz4W0F; Sat, 17 Aug 2019 16:16:46 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x7HGGhGJ036346; Sat, 17 Aug 2019 09:16:43 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x7HGGhpK036345; Sat, 17 Aug 2019 09:16:43 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201908171616.x7HGGhpK036345@gndrsh.dnsmgr.net> Subject: Re: uname -a default options In-Reply-To: <7d1f88943c0b744920d7181df51b76675d145f18.camel@freebsd.org> To: Ian Lepore Date: Sat, 17 Aug 2019 09:16:43 -0700 (PDT) CC: Gordon Bergling , freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 469lgg2sJvz4W0F X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.959,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2019 16:16:47 -0000 > On Sat, 2019-08-17 at 15:08 +0200, Gordon Bergling wrote: > > Hello List, > > > > "uname -a" is currently mapping the -a option to ?-mnrsv?, which > > results in something similar like > > > > $ uname -a > > FreeBSD lion.0xfce3.net 12.0-STABLE FreeBSD > > 12.0-STABLE r350835 GENERIC amd64 > > > > What would you think about reducing the option mapping for ?-a? to ?- > > vmn? , which would result in a less repetitive version string like > > the one below. > > > > $ uname -vmn > > lion.0xfce3.net FreeBSD 12.0-STABLE r350835 > > GENERIC amd64 > > > > Adapting this would be trivial, but before I hack something together, > > I would like to get some feedback if such a change would be welcomed? > > > > Best regards, > > > > Gordon > > > > I think there are likely very many existing scripts in the world that > parse the output of uname -a and would break if the fields moved around > or disappeared. I agree that we should not change the output of uname -a, for one it is a POSIX spec'ed command, though I would not expect scripts to be parsing the output of -a, they should actually invoke the more specific item(s) they need and parse those, a much less error prone methods. I would however like to note that Linux (or atleast Ubuntu 19.04) has a man page that -a says "All of the below" and are infact returning more info than the Posix man page which says -a is -mnrsv rgrimes@mgmt:~$ uname -a Linux mgmt 5.1.0-rc2+ #14 SMP Sun Aug 4 09:23:12 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux rgrimes@mgmt:~$ man uname rgrimes@mgmt:~$ uname -mnrsv Linux mgmt 5.1.0-rc2+ #14 SMP Sun Aug 4 09:23:12 UTC 2019 x86_64 rgrimes@mgmt:~$ uname -m x86_64 rgrimes@mgmt:~$ uname -n mgmt rgrimes@mgmt:~$ uname -r 5.1.0-rc2+ rgrimes@mgmt:~$ uname -s Linux rgrimes@mgmt:~$ uname -v #14 SMP Sun Aug 4 09:23:12 UTC 2019 FreeBSD: root {1003}# uname -a FreeBSD w530a.dnsmgr.net 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC amd64 root {1004}# uname -m amd64 root {1005}# uname -n w530a.dnsmgr.net root {1006}# uname -r 12.0-RELEASE root {1007}# uname -s FreeBSD root {1008}# uname -v FreeBSD 12.0-RELEASE r341666 GENERIC So it is really our -v string that is full of redundant data that MAY want to be evaluated for trimming. -- Rod Grimes rgrimes@freebsd.org