From owner-freebsd-hackers@freebsd.org Sun Jan 7 08:36:57 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E848BE5F188 for ; Sun, 7 Jan 2018 08:36:57 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A86867CCD4; Sun, 7 Jan 2018 08:36:56 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 4974827376; Sun, 7 Jan 2018 08:36:45 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id w078aTae053798 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 7 Jan 2018 08:36:29 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id w078aTe3053797; Sun, 7 Jan 2018 08:36:29 GMT (envelope-from phk) To: Brooks Davis cc: Ian Lepore , Freebsd hackers list , cem@freebsd.org Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? In-reply-to: <20180106215947.GG95035@spindle.one-eyed-alien.net> From: "Poul-Henning Kamp" References: <24acbd94-c52f-e71a-8a96-d608a10963c6@rawbw.com> <1514572041.12000.7.camel@freebsd.org> <20180105221330.GD95035@spindle.one-eyed-alien.net> <24173.1515191675@critter.freebsd.dk> <1515201055.1865.5.camel@freebsd.org> <20180106215947.GG95035@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <53795.1515314189.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sun, 07 Jan 2018 08:36:29 +0000 Message-ID: <53796.1515314189@critter.freebsd.dk> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 08:36:58 -0000 -------- In message <20180106215947.GG95035@spindle.one-eyed-alien.net>, Brooks Dav= is writes: >The portable API is terrible and closefrom() with arguments >other than 3 (or maybe 4) is in many ways worse with require dup2(2) >shenanigans. Agreed. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-hackers@freebsd.org Mon Jan 8 16:13:24 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 162EFE74F25 for ; Mon, 8 Jan 2018 16:13:24 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id F089282BCA; Mon, 8 Jan 2018 16:13:23 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from sweettea.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 940355646F; Mon, 8 Jan 2018 10:13:16 -0600 (CST) Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? To: Eugene Grosbein , Brooks Davis , Alan Somers Cc: Yuri , Ian Lepore , Freebsd hackers list References: <24acbd94-c52f-e71a-8a96-d608a10963c6@rawbw.com> <1514572041.12000.7.camel@freebsd.org> <20180105221330.GD95035@spindle.one-eyed-alien.net> <5A4FF989.1040709@grosbein.net> <7b977409-96ee-5acb-60d0-3b0e124495f0@vangyzen.net> <5A5002D9.9080205@grosbein.net> From: Eric van Gyzen Message-ID: Date: Mon, 8 Jan 2018 10:13:15 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <5A5002D9.9080205@grosbein.net> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 16:13:24 -0000 On 01/05/2018 16:57, Eugene Grosbein wrote: > 06.01.2018 5:26, Eric van Gyzen wrote: > >>>>> I would argue the opposite. There are very few reasons why close(s) would >>>>> ever fail, and the most likely is EBADF. EBADF indicates a programming >>>>> bug, like a double close or use of an uninitialized variable. Those could >>>>> easily turn into worse bugs in the future. So I think the best course of >>>>> action is to check the return code, assert() on EBADF, and ignore, or >>>>> possibly log, other errors. >>>> >>>> For this specific case, I think there would be value in an option to >>>> have the kernel kill any process that calls close(fd) where fd != -1 >>>> where EBADF would be returned. >>> >>> A medicine should not be worse worse than the disease, imho. >> >> In a multi-threaded application, a double-close can close completely >> unrelated file descriptors, which can be a nightmare to diagnose. In >> that case, death by signal is far better than the disease. > > A kernel cannot know if close() was called for "unrealated" but correct file descriptor. Right, which is the reason such bugs are hard to diagnose. Optionally killing the process on close->EBADF would help find buggy code when another thread did NOT re-open the file descriptor between the two close calls. Eric From owner-freebsd-hackers@freebsd.org Mon Jan 8 16:18:03 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DCE8CE75447 for ; Mon, 8 Jan 2018 16:18:03 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D34383001; Mon, 8 Jan 2018 16:18:02 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w08GHsAq070167 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 8 Jan 2018 17:17:55 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: eric@vangyzen.net Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w08GHo5Y041119 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 8 Jan 2018 23:17:50 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? To: Eric van Gyzen , Brooks Davis , Alan Somers References: <24acbd94-c52f-e71a-8a96-d608a10963c6@rawbw.com> <1514572041.12000.7.camel@freebsd.org> <20180105221330.GD95035@spindle.one-eyed-alien.net> <5A4FF989.1040709@grosbein.net> <7b977409-96ee-5acb-60d0-3b0e124495f0@vangyzen.net> <5A5002D9.9080205@grosbein.net> Cc: Yuri , Ian Lepore , Freebsd hackers list From: Eugene Grosbein Message-ID: <5A5399AA.9020309@grosbein.net> Date: Mon, 8 Jan 2018 23:17:46 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 16:18:04 -0000 08.01.2018 23:13, Eric van Gyzen wrote: > Right, which is the reason such bugs are hard to diagnose. Optionally > killing the process on close->EBADF would help find buggy code when > another thread did NOT re-open the file descriptor between the two close > calls. Wouldn't "close(f); assert(errno != EBADF);" be better? From owner-freebsd-hackers@freebsd.org Mon Jan 8 16:13:06 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 475F0E74EAC for ; Mon, 8 Jan 2018 16:13:06 +0000 (UTC) (envelope-from florian.florensa@gmail.com) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 046AB82B95 for ; Mon, 8 Jan 2018 16:13:06 +0000 (UTC) (envelope-from florian.florensa@gmail.com) Received: by mail-qt0-x22d.google.com with SMTP id k19so14230415qtj.6 for ; Mon, 08 Jan 2018 08:13:05 -0800 (PST) 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=dkObirH7vyaNbJ3hcXIBJ3tRMzFI45G8dUNEFIBeiRY=; b=r7VZZXbaGEdyFbvaQQ4R/VS8eWGmAwldedbVtmPCGMNg2ciMB6cUHtRrWFDgodKtxf CguYTDc0BOaSuXag2DwW+53LAMd5psl2vEPoKHyA6h6aqXwuR1mIwvbu26L4UYRfdAOV mqFa8AzCj3JF7buG5uyr06cn2AwYGCl+XrY7fAlBtaAgvdQc+nYEK0MRI3NXnwmrmY2I BFkgU5KguwmDE+qtnBgThET6kqRbSVwIQbUp7aTZUvI3jA8QNUFC8icdCzzDqPJt5szo McbjQzizTKovfffUxexIm4LaNPkVZyGXG5r12sGpLE4cZN1vFu07/glhPSzJPmjVUCVl 9nSw== 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=dkObirH7vyaNbJ3hcXIBJ3tRMzFI45G8dUNEFIBeiRY=; b=lPlWwSKr+IUyq3sLu2k5RBPsAL5iHyP2nki//iOUjbOPKCM+yngAmO7syDRUYPfhOB 1iUmjXTQr0d9jnbwlvzvduurA/8Dg9kd9V349JbYNEt+IfmSlP/7l9RPVtzIbBk4zYKq 0Loau4jBj3z3sbA5gLWT/65f4MSdrb0vmqvyNqMIFymQxEBRtXf+f1IhE6bba36lkWrG LEDqMTzmi3TNxbDvDuBlD2fz68dBzhuc+8sYPUMqB/PuNbsEr/lcdYiQ9/I+8+imfvLU G7ACAt8j/nNtDK2xlN7fXrj9O2m10HU7S3uqFL6HgCS86FO8z68v52NaljmIZjO6FRwp vD0w== X-Gm-Message-State: AKwxytfDf1/wEX1tijIeHTSxaJMaQ8EId+VETHlqf/5Y8VBLK1U5aCyF q1PoBLA2rZQ39wDjobs1NKKUGwt7NRsB2BIweppMQ9ex X-Google-Smtp-Source: ACJfBot4VIFj3TkwJk7WoR5DXZua3Mt6CrJZYpFdFrRJ8wWwsf1iiTnS4c4DzRAvQ6Sk33UdIfvu9vevYupeaip0TfQ= X-Received: by 10.200.25.195 with SMTP id s3mr16461543qtk.173.1515427984925; Mon, 08 Jan 2018 08:13:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.25.42 with HTTP; Mon, 8 Jan 2018 08:13:04 -0800 (PST) From: Florian Florensa Date: Mon, 8 Jan 2018 17:13:04 +0100 Message-ID: Subject: Virtual SCSI Device To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Mon, 08 Jan 2018 17:44:26 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 16:13:06 -0000 Hello, I've been trying to hack together a virtual SCSI device, and i've been struggling withthe device creation. Here is the relevant code on pastebin : https://pastebin.com/e50bYHiQ the device never gets created, and xpt_action_default spits error regarding unsupported codes : 0xE and 0x708 (XPT_DEV_ADVINFO and XPT_SCAN_BUS). If anyone can give me some advice, i would appreciate, Regards, Florian. From owner-freebsd-hackers@freebsd.org Mon Jan 8 17:52:01 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F3104E7AABF for ; Mon, 8 Jan 2018 17:52:01 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id DB30E692CC; Mon, 8 Jan 2018 17:52:01 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from sweettea.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 80FEA5646F; Mon, 8 Jan 2018 11:52:00 -0600 (CST) Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? To: "Rodney W. Grimes" , Eugene Grosbein Cc: Brooks Davis , Alan Somers , Yuri , Ian Lepore , Freebsd hackers list References: <201801081655.w08GtO3D022568@pdx.rh.CN85.dnsmgr.net> From: Eric van Gyzen Message-ID: Date: Mon, 8 Jan 2018 11:51:56 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <201801081655.w08GtO3D022568@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 17:52:02 -0000 On 01/08/2018 10:55, Rodney W. Grimes wrote: >> 08.01.2018 23:13, Eric van Gyzen wrote: >> >>> Right, which is the reason such bugs are hard to diagnose. Optionally >>> killing the process on close->EBADF would help find buggy code when >>> another thread did NOT re-open the file descriptor between the two close >>> calls. >> >> Wouldn't "close(f); assert(errno != EBADF);" be better? Putting the code in one place is far better than putting it in N places...after /finding/ those N places. Indeed, the purpose of this code is to help people find those places, even in their own code, outside of base. > Or even > #ifdef DEBUG_CLOSE > #define close(f) close(f); assert(errno != EBADF); > #endif errno could have been EBADF before the close(). A successful close() does not modify errno. So, this would have be larger, making it even more unpalatable. > Then the people that want to go chasing these errors can, > and the rest of us are untouched. Every mention in this thread of killing the process has called it optional. Tools, not policy. Eric From owner-freebsd-hackers@freebsd.org Mon Jan 8 18:05:31 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 588B4E7B90C for ; Mon, 8 Jan 2018 18:05:31 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "thawte SHA256 SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 16EED6A17F; Mon, 8 Jan 2018 18:05:30 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w08HxBIQ020044; Mon, 8 Jan 2018 10:05:28 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=4Ua6JlYOwEcwPzmMp2HKu68snB/7d2MlePhspaupCmU=; b=Pgdm1Suw5bE0hEGgbWkrgOv2o9hoeYbwU+0t48MKciH7RYkHiSz62HxwiNMbqQ4lXXv6 63Km9vPGqCX7N5WO+O0zfuEr88Qngqr0tvPdRtxQH6aThU4cJflHB0r7o7XsMRHwSrY3 k6BGpaF9kkDg3kGZZXKvclLCm2g4ad86zRDIJOqgN8skM0EkRSAF14r0Yfags0OHc38o SK1Lii203qZH5i4RUmvP55PwdbAwYUkD9QB0y94xBQOz9kwttD2H5Le7MaD+UfMNFuF2 /IO9GgSRJRH/g74xjzmqmSVbtvefUHqT1qJfB28Jcs32RI7z2d6tdcs5e3EEQZqqUExD jQ== Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0082.outbound.protection.outlook.com [207.46.163.82]) by mx0a-00273201.pphosted.com with ESMTP id 2fc49715y0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 08 Jan 2018 10:05:28 -0800 Received: from SN1PR0501MB2125.namprd05.prod.outlook.com (10.163.228.152) by SN1PR0501MB2160.namprd05.prod.outlook.com (10.163.229.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.1; Mon, 8 Jan 2018 18:05:25 +0000 Received: from SN1PR0501MB2125.namprd05.prod.outlook.com ([10.163.228.152]) by SN1PR0501MB2125.namprd05.prod.outlook.com ([10.163.228.152]) with mapi id 15.20.0407.005; Mon, 8 Jan 2018 18:05:25 +0000 From: Andrew Duane To: Eric van Gyzen , "Rodney W. Grimes" , Eugene Grosbein CC: Yuri , Brooks Davis , Ian Lepore , Alan Somers , Freebsd hackers list Subject: RE: Is it considered to be ok to not check the return code of close(2) in base? Thread-Topic: Is it considered to be ok to not check the return code of close(2) in base? Thread-Index: AQHTiKloOfClzGJYSEGJa8gDMYWghaNqRGmQ Date: Mon, 8 Jan 2018 18:05:25 +0000 Message-ID: References: <201801081655.w08GtO3D022568@pdx.rh.CN85.dnsmgr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1PR0501MB2160; 7:lL1xNIZNlWknDTzVO04SApzOHZItSMu1viSTMHpFAb0wuSFvbn4roJ7/1zJjewB0RF105nMANwNJ0OSJ/oKgJ2GUEf+gBSq21QvA8EDaUzbjvhIUW5ukfxJmEXCCN52d2pldFSFKwFODmaHFJwk2z7wNQa9i9OcVBjwvxpJ2/3EOqivAOM5DZsYHuNIMxdZzcI9r23O47LT/aBp0ePiS51567XsHGXpc7O7u8/RYLA7dMSUXcYa5qWPnjkTjA+zc x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d78c0d50-0552-406a-9634-08d556c264d0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020040)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:SN1PR0501MB2160; x-ms-traffictypediagnostic: SN1PR0501MB2160: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3002001)(3231023)(944501098)(10201501046)(93006095)(93001095)(6055026)(6041268)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:SN1PR0501MB2160; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SN1PR0501MB2160; x-forefront-prvs: 054642504A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(396003)(346002)(39860400002)(39380400002)(13464003)(199004)(189003)(24454002)(2950100002)(305945005)(81166006)(77096006)(68736007)(9686003)(5660300001)(55016002)(2906002)(97736004)(229853002)(4326008)(6436002)(66066001)(7736002)(6246003)(3280700002)(81156014)(8676002)(3660700001)(86362001)(7696005)(106356001)(76176011)(110136005)(105586002)(59450400001)(53546011)(6506007)(3846002)(6116002)(2900100001)(478600001)(74316002)(53936002)(33656002)(14454004)(316002)(25786009)(8936002)(102836004)(99286004)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2160; H:SN1PR0501MB2125.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: FNxXjny9KMfxkBr6nGCUujY8loG/+JfBVYTdO6f7GQLX2SFrsvvFTpsIHK/Dc8kabeyVpLRZqH15lIO9y0SM4g== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: d78c0d50-0552-406a-9634-08d556c264d0 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2018 18:05:25.7047 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2160 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-08_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801080257 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 18:05:31 -0000 > -----Original Message----- > From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd- > hackers@freebsd.org] On Behalf Of Eric van Gyzen > Sent: Monday, January 8, 2018 12:52 PM > To: Rodney W. Grimes ; Eugene > Grosbein > Cc: Yuri ; Brooks Davis ; Ian > Lepore ; Alan Somers ; Freebsd > hackers list > Subject: Re: Is it considered to be ok to not check the return code of cl= ose(2) > in base? >=20 > On 01/08/2018 10:55, Rodney W. Grimes wrote: > >> 08.01.2018 23:13, Eric van Gyzen wrote: > >> > >>> Right, which is the reason such bugs are hard to diagnose. > >>> Optionally killing the process on close->EBADF would help find buggy > >>> code when another thread did NOT re-open the file descriptor between > >>> the two close calls. > >> > >> Wouldn't "close(f); assert(errno !=3D EBADF);" be better? >=20 > Putting the code in one place is far better than putting it in N places..= .after > /finding/ those N places. Indeed, the purpose of this code is to help pe= ople > find those places, even in their own code, outside of base. >=20 > > Or even > > #ifdef DEBUG_CLOSE > > #define close(f) close(f); assert(errno !=3D EBADF); > > #endif >=20 > errno could have been EBADF before the close(). A successful close() doe= s > not modify errno. So, this would have be larger, making it even more > unpalatable. >=20 > > Then the people that want to go chasing these errors can, and the rest > > of us are untouched. >=20 > Every mention in this thread of killing the process has called it optiona= l. > Tools, not policy. >=20 > Eric Of course, my OCD will kick in and say this would need to be something like= : #ifdef DEBUG_CLOSE #define close(f) do {if (close(f) < 0) assert(errno !=3D EBADF); } while (0= ) #endif Have to watch those macro replacements like "if (need_to_close) close(f);".= And the close succeeding :-) .................................... Andrew L. Duane - Principal Resident Engineer AT&T Advanced Services Technical Lead Juniper Quality Ambassador m +1 603.770.7088 o +1 408.933.6944 (2-6944) skype: andrewlduane aduane@juniper.net From owner-freebsd-hackers@freebsd.org Mon Jan 8 18:06:02 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C349E7B998 for ; Mon, 8 Jan 2018 18:06:02 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mx2.catspoiler.org (mx2.catspoiler.org [IPv6:2607:f740:16::d18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D61946A27B; Mon, 8 Jan 2018 18:06:01 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org ([76.212.85.177]) by mx2.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w08I6DnT036931 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 8 Jan 2018 18:06:14 GMT (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w08I5llL056404 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jan 2018 10:05:48 -0800 (PST) (envelope-from truckman@FreeBSD.org) Date: Mon, 8 Jan 2018 10:05:42 -0800 (PST) From: Don Lewis Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? To: Eugene Grosbein cc: Eric van Gyzen , Brooks Davis , Alan Somers , Yuri , Ian Lepore , Freebsd hackers list In-Reply-To: <5A5399AA.9020309@grosbein.net> Message-ID: References: <24acbd94-c52f-e71a-8a96-d608a10963c6@rawbw.com> <1514572041.12000.7.camel@freebsd.org> <20180105221330.GD95035@spindle.one-eyed-alien.net> <5A4FF989.1040709@grosbein.net> <7b977409-96ee-5acb-60d0-3b0e124495f0@vangyzen.net> <5A5002D9.9080205@grosbein.net> <5A5399AA.9020309@grosbein.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 18:06:02 -0000 On 8 Jan, Eugene Grosbein wrote: > 08.01.2018 23:13, Eric van Gyzen wrote: > >> Right, which is the reason such bugs are hard to diagnose. Optionally >> killing the process on close->EBADF would help find buggy code when >> another thread did NOT re-open the file descriptor between the two close >> calls. > > Wouldn't "close(f); assert(errno != EBADF);" be better? That can produce false positives. The close() might be successful, in which case it will not touch errno, and errno might have been set to EBADF by some earlier operation. From owner-freebsd-hackers@freebsd.org Mon Jan 8 18:13:23 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40903E7C307 for ; Mon, 8 Jan 2018 18:13:23 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io0-f175.google.com (mail-io0-f175.google.com [209.85.223.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D9CA66AC8B for ; Mon, 8 Jan 2018 18:13:22 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io0-f175.google.com with SMTP id 14so15587047iou.2 for ; Mon, 08 Jan 2018 10:13:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=httyc6stZQI6+Xn/sH48vwI+PZGfPwB4Uw2EPv2FEJM=; b=qavVpeSoB2whUif1POLedPY0EfRWzCmZ4dq4rjltO2bnHDqsuevi22r1kiQuRsIOtE 7G73V2KsFUGaOxr/RFftWYFfqt8U1UnCQhGibZ/0Vs92tsacLJApRcPRpKY1lUhhZouG KxInJ0lDdxowXwl1AoBAPnRM9mdgX4DRbEjhtZ9OZy8yw1BNSEU1ecxgjVZ22YUBG+ac V8Ol796umhXqT3faYplKXK3M930Knv+4mBVGRb6bwj32gKlCKXMVuP7+gqnA+9LMmdBK kSLGEgVYZCUgama89ybN43Uh9iahk7pDgrvc1kdAQprEGFJB8anyYzV2KzhL0ifJwrlo tVZg== X-Gm-Message-State: AKGB3mL7pspxo6j73III4K/Leui/TpYpDkFCzkwqT30t4BD2iS1M3Ow+ aTQStgS5HGxr+xoDd1dtJokVGEjZ X-Google-Smtp-Source: ACJfBosgkdbK8jbq5Etgrsrldw+Ymx2ypUojaLA3WtthUS8VKjAAA5sz7AgzPcLebGcsbPN53GVQXQ== X-Received: by 10.36.7.133 with SMTP id f127mr13149640itf.101.1515435201326; Mon, 08 Jan 2018 10:13:21 -0800 (PST) Received: from mail-io0-f176.google.com (mail-io0-f176.google.com. [209.85.223.176]) by smtp.gmail.com with ESMTPSA id o200sm7117754itg.10.2018.01.08.10.13.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jan 2018 10:13:20 -0800 (PST) Received: by mail-io0-f176.google.com with SMTP id k18so15585893ioc.11 for ; Mon, 08 Jan 2018 10:13:20 -0800 (PST) X-Received: by 10.36.47.207 with SMTP id j198mr12398830itj.119.1515435200292; Mon, 08 Jan 2018 10:13:20 -0800 (PST) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.15.193 with HTTP; Mon, 8 Jan 2018 10:13:19 -0800 (PST) In-Reply-To: References: <201801081655.w08GtO3D022568@pdx.rh.CN85.dnsmgr.net> From: Conrad Meyer Date: Mon, 8 Jan 2018 10:13:19 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? To: Andrew Duane Cc: Freebsd hackers list Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 18:13:24 -0000 On Mon, Jan 8, 2018 at 10:05 AM, Andrew Duane wrote: > Of course, my OCD will kick in and say this would need to be something like: > > #ifdef DEBUG_CLOSE > #define close(f) do {if (close(f) < 0) assert(errno != EBADF); } while (0) > #endif > > Have to watch those macro replacements like "if (need_to_close) close(f);". And the close succeeding :-) Of course, this has turned into nerd sniping. But I'll take my turn. Better to use the GCC "statement expression" extension so that the return value of "close()" can still be used by callers naive to the macro. #define close(f) ({ int __ret; __ret = (close)(f); if (__ret < 0) assert(errno != EBADF); __ret; }) Best, Conrad From owner-freebsd-hackers@freebsd.org Mon Jan 8 18:42:42 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66FBAE7DC79 for ; Mon, 8 Jan 2018 18:42:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D3D0E6C1F5; Mon, 8 Jan 2018 18:42:41 +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 w08IgXqF005789 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 Jan 2018 20:42:36 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w08IgXqF005789 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w08IgX58005788; Mon, 8 Jan 2018 20:42:33 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 8 Jan 2018 20:42:33 +0200 From: Konstantin Belousov To: Conrad Meyer Cc: Andrew Duane , Freebsd hackers list Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? Message-ID: <20180108184233.GL1684@kib.kiev.ua> References: <201801081655.w08GtO3D022568@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 18:42:42 -0000 On Mon, Jan 08, 2018 at 10:13:19AM -0800, Conrad Meyer wrote: > On Mon, Jan 8, 2018 at 10:05 AM, Andrew Duane wrote: > > Of course, my OCD will kick in and say this would need to be something like: > > > > #ifdef DEBUG_CLOSE > > #define close(f) do {if (close(f) < 0) assert(errno != EBADF); } while (0) > > #endif > > > > Have to watch those macro replacements like "if (need_to_close) close(f);". And the close succeeding :-) > > Of course, this has turned into nerd sniping. But I'll take my turn. > > Better to use the GCC "statement expression" extension so that the > return value of "close()" can still be used by callers naive to the > macro. > > #define close(f) ({ int __ret; __ret = (close)(f); if (__ret < 0) > assert(errno != EBADF); __ret; }) You can create a dso which interposes close(3), calls original close() resolved by dlsym(RTLD_NEXT), and checks for the error, for use with LD_PRELOAD environment variable. No need to vandali^H^H^H^hack on either kernel nor userland code. From owner-freebsd-hackers@freebsd.org Mon Jan 8 16:55:26 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0ECDE77659 for ; Mon, 8 Jan 2018 16:55:26 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.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 81DEA1EB6; Mon, 8 Jan 2018 16:55:26 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w08GtOkr022569; Mon, 8 Jan 2018 08:55:25 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w08GtO3D022568; Mon, 8 Jan 2018 08:55:24 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201801081655.w08GtO3D022568@pdx.rh.CN85.dnsmgr.net> Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? In-Reply-To: <5A5399AA.9020309@grosbein.net> To: Eugene Grosbein Date: Mon, 8 Jan 2018 08:55:24 -0800 (PST) CC: Eric van Gyzen , Brooks Davis , Alan Somers , Yuri , Ian Lepore , Freebsd hackers list X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Mon, 08 Jan 2018 18:57:04 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 16:55:26 -0000 > 08.01.2018 23:13, Eric van Gyzen wrote: > > > Right, which is the reason such bugs are hard to diagnose. Optionally > > killing the process on close->EBADF would help find buggy code when > > another thread did NOT re-open the file descriptor between the two close > > calls. > > Wouldn't "close(f); assert(errno != EBADF);" be better? Or even #ifdef DEBUG_CLOSE #define close(f) close(f); assert(errno != EBADF); #endif Then the people that want to go chasing these errors can, and the rest of us are untouched. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Mon Jan 8 17:30:21 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE19BE79631; Mon, 8 Jan 2018 17:30:21 +0000 (UTC) (envelope-from Anton.Rang@dell.com) Received: from esa7.dell-outbound.iphmx.com (esa7.dell-outbound.iphmx.com [68.232.153.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.dell-outbound.iphmx.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 64EA963900; Mon, 8 Jan 2018 17:30:20 +0000 (UTC) (envelope-from Anton.Rang@dell.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1515432417; x=1546968417; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RVPEUPFalTgnjitjhLJD1U2wK2JMWE91e51agZNjHXg=; b=QaJdDKlUKfNrUElkgy7iZqy6fpm+J8TosUBjUuoun7a5VV19XMVVUnw4 y8+0ijGYUZ16tr+HL1XAObSh+hpU2l3IfTVc3oBcJ6WoyS/r0U+kadRiB C8W4GD1V6M3BZZbGYLGYg8tfPJuXVqaQSXmbfZg3QrvtdtmvubK46mHNH k=; IronPort-PHdr: =?us-ascii?q?9a23=3AKl2V5hSSbYgP3Z2XFjVoAN9xe9psv+yvbD5Q0YIu?= =?us-ascii?q?jvd0So/mwa6zYhKN2/xhgRfzUJnB7Loc0qyK6/mmATRIyK3CmUhKSIZLWR4BhJ?= =?us-ascii?q?detC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBxrwKxd+?= =?us-ascii?q?KPjrFY7OlcS30P2594HObwlSizexfa5+IA+qoQnNq8IbnZZsJqEtxxXTv3BGYf?= =?us-ascii?q?5WxWRmJVKSmxbz+MK994N9/ipTpvws6ddOXb31cKokQ7NYCi8mM30u683wqRbD?= =?us-ascii?q?VwqP6WACXWgQjxFFHhLK7BD+Xpf2ryv6qu9w0zSUMMHqUbw5Xymp4rx1QxH0li?= =?us-ascii?q?gIKz858HnWisNuiqJbvAmhrAF7z4LNfY2ZKOZycqbbcNgHR2ROQ9xRWjRBDI2i?= =?us-ascii?q?coUPE+QPM+VWr4b/plsBsRSwCga3CePz0TBIg2P60bEm3+kjFwzNwQwuH8gJsH?= =?us-ascii?q?TRtNj5OrscXvqzzKnH1TnIcu9b2THh6IjPdBAtr+yHULVsfMrX1UkvEAXFgk+M?= =?us-ascii?q?p4P/OTOV2f8AvHWF4OpkUeKjkXIoqwZ0ojW2wMonl4fHhoUQyl/e9CV5xp44Jd?= =?us-ascii?q?OiSEFlf9GrC4BQuDyAO4txWMMiTGdlszs5xL0eoZO2fSsHxI45yxPRdfCLaZWE?= =?us-ascii?q?7xLtWeqLPzt0mHxodKqiixqu60Ss1PHwWtWu3FtKqidJiMTAu34O2hDL98SKS/?= =?us-ascii?q?9w8l2/1TuP2A3f8OBJLVoqmafVJZMsxKM7mIAJvkTZBCD2nV37jKqRdko55Oel?= =?us-ascii?q?8//nYrD6pp+EMI90lx3+PrwumsOhBeQ4NRADUHaA+eum1LDv51D2T6tOjv0yi6?= =?us-ascii?q?XZt43aJdgAqa6+Hg9V1Jss5wilAzenyNQYnXwHLV1fdB2biIjpPknCIPH+Dfih?= =?us-ascii?q?n1ShiDZmyvPcMrH/DJjBMGLPnKrhcLtz8UJQ1hY/wN5H65JREL4BIfbzWkHrtN?= =?us-ascii?q?zfCx80KxC5w+D7CNV60IMSQ36BDbWfMKPdqlKH+/wgI+2IZIMPpDn9LP0l6+b0?= =?us-ascii?q?jXAlgV8dYbWp3ZwPZXC2BPRpPVuWbmH3gtgcCGsFpBA+Q/DqiFCZXz5TfWi9UL?= =?us-ascii?q?wn6TEgFY2qF4DDRpqigLaZxie0AoVWZnxaClCLCXroeZ+EVOkSZy2JOc9ujyUI?= =?us-ascii?q?Vbi7RIA91hGhqhX6y6F8I+ra4C0Xq4zs28Nu5+LOjx0y8iZ0D8vOm12KGl5znG?= =?us-ascii?q?gJSjQ2lJhiqkx00B/Xzq96n/FbPcRO7PNASEE8OIKKnMJgDNWnEDjIeNjNAH+g?= =?us-ascii?q?XtKgS3llZ9QtxNlIWU97FP2ugxTHmSGtBulGxPSwGJUo//eEjDDKLMFnxiODjf?= =?us-ascii?q?F5gg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HMAAA7qVNamMuZ6ERcGwEBAQEDAQEBC?= =?us-ascii?q?QEBAYQVEHQnB4QKmH2CApk/ChgLhElPAhqEHEMUAQEBAQEBAQEBAQIQAQEBAQE?= =?us-ascii?q?ICwsGKC+COCQBDkstAQEBAQEBAQEBIwEBAQEBASMCCAVdAQEBAwEBASERDA4RD?= =?us-ascii?q?wsBBAsCAQgOCgICJgICAiUBCQEVEAIECAYBBAEcAgKKCAgQr3qCJ4MRhyABAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBFwMFgQ+ER1+BV4FoKYMFgzCBTgEBgzUxgjSjXQYCi?= =?us-ascii?q?AWHI4YUlAmNM4k3AgQCBAUCGoE8NoFzb1IqAYF/glQQDIFneAiIK4ElgRcBAQE?= X-IPAS-Result: =?us-ascii?q?A2HMAAA7qVNamMuZ6ERcGwEBAQEDAQEBCQEBAYQVEHQnB4Q?= =?us-ascii?q?KmH2CApk/ChgLhElPAhqEHEMUAQEBAQEBAQEBAQIQAQEBAQEICwsGKC+COCQBD?= =?us-ascii?q?kstAQEBAQEBAQEBIwEBAQEBASMCCAVdAQEBAwEBASERDA4RDwsBBAsCAQgOCgI?= =?us-ascii?q?CJgICAiUBCQEVEAIECAYBBAEcAgKKCAgQr3qCJ4MRhyABAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBFwMFgQ+ER1+BV4FoKYMFgzCBTgEBgzUxgjSjXQYCiAWHI4YUlAmNM4k?= =?us-ascii?q?3AgQCBAUCGoE8NoFzb1IqAYF/glQQDIFneAiIK4ElgRcBAQE?= Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa7.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2018 11:25:50 -0600 From: "Rang, Anton" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2018 23:24:58 +0600 Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w08HSv2w031920 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 Jan 2018 12:28:59 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com w08HSv2w031920 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=isilon.com; s=jan2013; t=1515432540; bh=YvVrLgzXNb65dmU0ndxfAQfw68w=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-ID:Content-Transfer-Encoding:MIME-Version; b=UOrAT0KnywKn1buXZTGGCk44fQg6XCdlU5IkzgxlTGwAke8n6a9i4u+ENCzbf6n/J WMCltwoL/a9wp4CAHlpHL9vMjepKooWPy9G6ZxwIFd2CAd/s95+jygUD3yZUO8me1/ Y/6nDHtHDzsOijqMBKIwY1QdhsGg0I3npOu2TdK8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com w08HSv2w031920 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd55.lss.emc.com (RSA Interceptor); Mon, 8 Jan 2018 12:28:34 -0500 Received: from MXHUB216.corp.emc.com (MXHUB216.corp.emc.com [10.253.68.86]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w08HSLDp027832 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 8 Jan 2018 12:28:23 -0500 Received: from MX103CL02.corp.emc.com ([169.254.6.233]) by MXHUB216.corp.emc.com ([10.253.68.86]) with mapi id 14.03.0352.000; Mon, 8 Jan 2018 12:28:20 -0500 To: Wojciech Puchar CC: Warner Losh , Eric McCorkle , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Subject: Re: A more general possible meltdown/spectre countermeasure Thread-Topic: A more general possible meltdown/spectre countermeasure Thread-Index: AQHTiKYTEmeeeTOFpkyH+zs3xbP9kQ== Date: Mon, 8 Jan 2018 17:28:20 +0000 Message-ID: <6AF5185E-201A-4C8E-B4ED-B30C65E36E99@isilon.com> References: <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> <73d2f1a5-55f7-0ae7-7660-3e680ba3d32e@metricspace.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.59.138] Content-Type: text/plain; charset="utf-8" Content-ID: <5E962322D258134786F410FBD9824AD6@mail.corp.emc.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public X-Mailman-Approved-At: Mon, 08 Jan 2018 18:58:13 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 17:30:21 -0000 VGhlIHRhYmxlcyBhcmVu4oCZdCBjaGFuZ2VkIG9uIGVhY2ggdHJhbnNpdGlvbjsgcmF0aGVyLCB0 d28gcGFnZSB0YWJsZXMgYXJlIG1haW50YWluZWQsIG9uZSB3aGljaCBoYXMgYW4gZW50cnkgZm9y IHRoZSBrZXJuZWwgbWFwcGluZ3MgYXQgdGhlIHRvcCBsZXZlbCBhbmQgb25lIHdoaWNoIGRvZXMg bm90Lg0KDQpUaGVuIGl04oCZcyBzaW1wbHkgYSBtYXR0ZXIgb2YgY2hhbmdpbmcgd2hpY2ggcGFn ZSB0YWJsZSBpcyBleGFtaW5lZCAoYnkgd3JpdGluZyB0byBDUjMpIG9uIHRyYW5zaXRpb24uDQoN CklmIFBDSUQgaXMgYXZhaWxhYmxlLCBwcmV2aW91c2x5LXVzZWQgbWFwcGluZ3MgY2FuIHN0YXkg Y2FjaGVkIGluIHRoZSBUTEIgdGhyb3VnaCB0aGlzLCB0aG91Z2ggdGhleSB3b27igJl0IGJlIHNo YXJlZCBiZXR3ZWVuIHVzZXIva2VybmVsIChzbyBpbiBnZW5lcmFsIHN5c2NhbGxzIHdpbGwgaW5j dXIgYW4gYWRkaXRpb25hbCB0cmFuc2xhdGlvbiBwZXIgYnVmZmVyIHBhZ2UpLg0KDQpBbnRvbg0K DQo+IE9uIEphbiA2LCAyMDE4LCBhdCAyOjQxIFBNLCBXb2pjaWVjaCBQdWNoYXIgPHdvanRla0Bw dWNoYXIubmV0PiB3cm90ZToNCj4gDQo+PiBUaGUgb25seSB3b3JrYXJvdW5kIHRoYXQncyBjb21w bGV0ZWx5IGVmZmVjdGl2ZSBpcyB0byB1bm1hcCBhbGwgb2Yga2VybmVsIG1lbW9yeSB3aGVuIHJ1 bm5pbmcgaW4gdXNlcmxhbmQuIEl0J3MgYSBiaXQgdHJpY2t5IGJlY2F1c2UNCj4gDQo+IHRoaXMg bWVhbnMgb24gZXZlcnkgc3lzY2FsbCBvbiBpbnRlcnJ1cHQ6DQo+IA0KPiAtIG1lbWNvcHkgcGFy dCBvZiB0b3AgbGV2ZWwgUFRFIG9uIGVudGVyLCBiemVybyBvbiBleGl0DQo+IC0gVExCIGZsdXNo IGJvdGggb24gZW50ZXIgYW5kIGV4aXQuDQo+IA0KPiBJTUhPIGl0IHdvdWxkIG1ha2UgbXVjaCBt b3JlIHRoYW4gMzAlIG92ZXJoZWFkIGluIG1hbnkgY2FzZXMuIGFtIGkgd3Jvbmc/DQo+IA0KPj4g dGhlcmUncyBzbWFsbCBwYXJ0cyB0aGF0IGhhdmUgdG8gc3RheSBtYXBwZWQgZm9yIHZhcmlvdXMg YXJjaGl0ZWN0dXJhbCByZWFzb25zLiBUaGlzIG1lYW5zIEtBU0xSIG9uIHRoZXNlIENQVXMgbGlr ZWx5IGNhbiBuZXZlciBiZQ0KPj4gZWZmZWN0aXZlIHNpbmNlIG1lbHRkb3duIHdpbGwgbGV0IHlv dSBmaW5kIHdoYXQgdGhlIHRyYXAgYWRkcmVzcyBpcyBhbmQgZnJvbSB0aGF0IGZpbmQgdGhlIGtl cm5lbCAodGhvdWdoIHRoZXJlJ3Mgc29tZSBydW1ibGluZ3MNCj4+IHRoYXQgdGhlIGluZGlyZWN0 aW9uIExpbnV4IGlzIGRvaW5nIHdpbGwgc3VmZmljZSkuDQo+PiBXYXJuZXINCj4+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBmcmVlYnNkLWFy Y2hAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0DQo+IGh0dHBzOi8vbGlzdHMuZnJlZWJzZC5vcmcv bWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLWFyY2gNCj4gVG8gdW5zdWJzY3JpYmUsIHNlbmQgYW55 IG1haWwgdG8gImZyZWVic2QtYXJjaC11bnN1YnNjcmliZUBmcmVlYnNkLm9yZyINCg0K From owner-freebsd-hackers@freebsd.org Mon Jan 8 18:00:15 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F34DCE7B2FF for ; Mon, 8 Jan 2018 18:00:15 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.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 B010169A69; Mon, 8 Jan 2018 18:00:15 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w08I0DAZ022878; Mon, 8 Jan 2018 10:00:13 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w08I0D0q022877; Mon, 8 Jan 2018 10:00:13 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201801081800.w08I0D0q022877@pdx.rh.CN85.dnsmgr.net> Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? In-Reply-To: To: Eric van Gyzen Date: Mon, 8 Jan 2018 10:00:13 -0800 (PST) CC: Eugene Grosbein , Yuri , Brooks Davis , Ian Lepore , Alan Somers , Freebsd hackers list X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Mon, 08 Jan 2018 19:08:13 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 18:00:16 -0000 > On 01/08/2018 10:55, Rodney W. Grimes wrote: > >> 08.01.2018 23:13, Eric van Gyzen wrote: > >> > >>> Right, which is the reason such bugs are hard to diagnose. Optionally > >>> killing the process on close->EBADF would help find buggy code when > >>> another thread did NOT re-open the file descriptor between the two close > >>> calls. > >> > >> Wouldn't "close(f); assert(errno != EBADF);" be better? > > Putting the code in one place is far better than putting it in N > places...after /finding/ those N places. Indeed, the purpose of this > code is to help people find those places, even in their own code, > outside of base. I agree with that. > > Or even > > #ifdef DEBUG_CLOSE > > #define close(f) close(f); assert(errno != EBADF); > > #endif > > errno could have been EBADF before the close(). A successful close() > does not modify errno. So, this would have be larger, making it even > more unpalatable. Ok, so lets get a bit more clever, #ifdef DEBUG_CLOSE #define close(f) assert(close(f) && errno != EBADF) #endif There, now only if close failed do we check errno, how does that work for you? And if it doesnt I am sure you can code up a #define that does work well. > > > Then the people that want to go chasing these errors can, > > and the rest of us are untouched. > > Every mention in this thread of killing the process has called it > optional. Tools, not policy. I am not certain on that, I think some of the proposals seemed to make the change non optional, but maybe I was reading too much between the lines. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Mon Jan 8 20:03:56 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E11CE5DD5A for ; Mon, 8 Jan 2018 20:03:56 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from rayleigh.systella.fr (newton-ipv6.systella.fr [IPv6:2001:7a8:a8ed:253::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "rayleigh.systella.fr", Issuer "rayleigh.systella.fr" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C913371102 for ; Mon, 8 Jan 2018 20:03:55 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from [192.168.10.4] ([192.168.10.4]) (authenticated bits=0) by rayleigh.systella.fr (8.15.2/8.15.2/Debian-9) with ESMTPSA id w08K3dte025937 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 8 Jan 2018 21:03:42 +0100 To: "freebsd-hackers@freebsd.org" From: BERTRAND Joel Subject: IPv6 Message-ID: <03877bcd-2d95-d0b8-6e8a-1628b619540e@systella.fr> Date: Mon, 8 Jan 2018 21:03:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.3-beta1 at rayleigh X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 20:03:56 -0000 Hello, I have installed a long time ago a diskless workstation running FreeBSD 9. Today, it runs FreeBSD 11.0-RELEASE-p12. When I have installed this workstation, I have disabled IPv6 as IPv6 connection was done by a slow VPN. Now, I have a full IPv6 access. Thus, I have reconfigured my router (NetBSD) to announce IPv6 network (rtadvd). All Linux workstations on LAN take a global IPv6 address and IPv6 router address. I suppose I have done a mistake on FreeBSD as it cannot obtain an address. root@pythagore:/etc # ifconfig re0: flags=8843 metric 0 mtu 1500 options=201b ether d8:cb:8a:7d:10:59 inet 192.168.10.102 netmask 0xffffff00 broadcast 192.168.10.255 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 inet6 fe80::dacb:8aff:fe7d:1059%re0 prefixlen 64 tentative scopeid 0x1 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 groups: lo root@pythagore:/etc # grep ip rc.conf ip6addrctl_enable="YES" ip6addrctl_verbose="NO" ip6addrctl_policy="ipv4_prefer" Where is my mistake ? Best regards, JB From owner-freebsd-hackers@freebsd.org Mon Jan 8 20:15:48 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F6F9E5EA64 for ; Mon, 8 Jan 2018 20:15:48 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C928F71AF9 for ; Mon, 8 Jan 2018 20:15:47 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x233.google.com with SMTP id w23so3277304lfd.11 for ; Mon, 08 Jan 2018 12:15:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=EjCY6eCXJGwmbKSDW1QGyxRLPx/v5EnGjzqLUcnCf1A=; b=KAp8Ny4vnCvvLlICOFKPpsHC/n75BsmT0IUpXz/7kZz25gBDea5jkM7dgUB60ihHZd lvcHIt3/YqvxjiDoydYLYeA77Mm3lDmp6QBL3tX2zwVnFR7GW853FhDcW2nTa8wnF7vI qQF10/rfMvBFLv+GL60ACJXOGzoWX17TlKYxLdbKgqWmZkanvMjf/SVRooMzfKo6Cj6L 7SnDFlBaXE+2/s7mCP04UY7rgFc0WK7j2dYVG15GusVE8b6rIVqZaPQRFsmL1YfOqGPP kQwAbjBdNj93j6I1ZngTg2JBD26aXrV2m0367yklVV0Da/0Oj3MKBCtpLWzNO3wwdGxo /ynA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=EjCY6eCXJGwmbKSDW1QGyxRLPx/v5EnGjzqLUcnCf1A=; b=KUk2Aex6mEG8xGe3/XUc06b/8iejGPBpUcQgmfMWghN4BtSaon3sxkjGZ0H4zm633I jhyPge6zW7wTOaSBsrZ0cdHJSrXf06/xYKSXYNqDRQ9jvBze9ULIupS4ahlMi9moAcpX /C2g+zzz7U2qKQVl432ApJKtSvCxQtPCo3lG0bgXqYFb8GuzOB8PrIRU5OnNSTtr/f4e wkl5mXCgW89Fu3+uPbGpreoXqqoE6repB+hGRFodC4nFpEE29RJq1XxZg1U32T7aKNxj iZOx2IGDVXQM+IHdmMW6O4IFl94MGlzWVQdiSkZXtfbvw6WwK8cR3tS79knWH7+RLiQY LV/g== X-Gm-Message-State: AKGB3mINTnWKcBioOomWl9AfnW/rQAkdJZuk572ZjkzweJqjoc8498rP SAUJ4Sr/cNbf3umUDGvJd8bMq4vwGbHLpW//08QVvw== X-Google-Smtp-Source: ACJfBot7YJYuwkJLzkmGQcfpAy1HX8gAW1hrve/8rcYTufFd9fHCDL88sYlEcnMK7YtR9mems2AWl9+5rglTk5gthAE= X-Received: by 10.46.16.1 with SMTP id j1mr7006538lje.139.1515442545432; Mon, 08 Jan 2018 12:15:45 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.76.19 with HTTP; Mon, 8 Jan 2018 12:15:44 -0800 (PST) In-Reply-To: <03877bcd-2d95-d0b8-6e8a-1628b619540e@systella.fr> References: <03877bcd-2d95-d0b8-6e8a-1628b619540e@systella.fr> From: Alan Somers Date: Mon, 8 Jan 2018 13:15:44 -0700 X-Google-Sender-Auth: OFsWFeu-NvCB0sDB99h958Svu4k Message-ID: Subject: Re: IPv6 To: BERTRAND Joel Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 20:15:48 -0000 On Mon, Jan 8, 2018 at 1:03 PM, BERTRAND Joel wrote: > Hello, > > I have installed a long time ago a diskless workstation running > FreeBSD 9. Today, it runs FreeBSD 11.0-RELEASE-p12. > > When I have installed this workstation, I have disabled IPv6 as > IPv6 connection was done by a slow VPN. Now, I have a full IPv6 access. > > Thus, I have reconfigured my router (NetBSD) to announce IPv6 > network (rtadvd). All Linux workstations on LAN take a global IPv6 address > and IPv6 router address. I suppose I have done a mistake on FreeBSD as it > cannot obtain an address. > > root@pythagore:/etc # ifconfig > re0: flags=8843 metric 0 mtu 1500 > options=201b > ether d8:cb:8a:7d:10:59 > inet 192.168.10.102 netmask 0xffffff00 broadcast 192.168.10.255 > inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 > inet6 fe80::dacb:8aff:fe7d:1059%re0 prefixlen 64 tentative scopeid > 0x1 > nd6 options=29 > media: Ethernet autoselect (1000baseT ) > status: active > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=21 > groups: lo > root@pythagore:/etc # grep ip rc.conf > ip6addrctl_enable="YES" > ip6addrctl_verbose="NO" > ip6addrctl_policy="ipv4_prefer" > > Where is my mistake ? > > Best regards, > > JB > You need to add something like : ifconfig_vtnet0_ipv6="inet6 accept_rtadv" -Alan From owner-freebsd-hackers@freebsd.org Mon Jan 8 20:29:44 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14D54E5FB57 for ; Mon, 8 Jan 2018 20:29:44 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from rayleigh.systella.fr (newton-ipv6.systella.fr [IPv6:2001:7a8:a8ed:253::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "rayleigh.systella.fr", Issuer "rayleigh.systella.fr" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CE10872BD4 for ; Mon, 8 Jan 2018 20:29:43 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from [192.168.10.4] ([192.168.10.4]) (authenticated bits=0) by rayleigh.systella.fr (8.15.2/8.15.2/Debian-9) with ESMTPSA id w08KTUxp002399 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 8 Jan 2018 21:29:31 +0100 Subject: Re: IPv6 To: "freebsd-hackers@freebsd.org" References: <03877bcd-2d95-d0b8-6e8a-1628b619540e@systella.fr> From: BERTRAND Joel Message-ID: Date: Mon, 8 Jan 2018 21:29:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.3-beta1 at rayleigh X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 20:29:44 -0000 Alan Somers a écrit : > > You need to add something like : > ifconfig_vtnet0_ipv6="inet6 accept_rtadv" Thanks a lot, I have added ifconfig_re0_ipv6="inet6 accept_rtadv" and ifconfig_re0_ipv6="inet6 -ifdisabled". Now ifconfig re0 returns : root@pythagore:/etc # ifconfig re0 re0: flags=8843 metric 0 mtu 1500 options=201b ether d8:cb:8a:7d:10:59 inet 192.168.10.102 netmask 0xffffff00 broadcast 192.168.10.255 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 inet6 fe80::dacb:8aff:fe7d:1059%re0 prefixlen 64 scopeid 0x1 nd6 options=23 media: Ethernet autoselect (1000baseT ) status: active But interface doesn't take any address... Best regards, JB From owner-freebsd-hackers@freebsd.org Mon Jan 8 20:55:29 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1276DE61A32 for ; Mon, 8 Jan 2018 20:55:29 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from rayleigh.systella.fr (newton-ipv6.systella.fr [IPv6:2001:7a8:a8ed:253::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "rayleigh.systella.fr", Issuer "rayleigh.systella.fr" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CC140743FC for ; Mon, 8 Jan 2018 20:55:28 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from [192.168.10.4] ([192.168.10.4]) (authenticated bits=0) by rayleigh.systella.fr (8.15.2/8.15.2/Debian-9) with ESMTPSA id w08KtBFM012558 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 8 Jan 2018 21:55:15 +0100 Subject: Re: IPv6 To: freebsd-hackers@freebsd.org References: <03877bcd-2d95-d0b8-6e8a-1628b619540e@systella.fr> From: BERTRAND Joel Message-ID: Date: Mon, 8 Jan 2018 21:55:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.3-beta1 at rayleigh X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 20:55:29 -0000 BERTRAND Joel a écrit : > Alan Somers a écrit : >> >> You need to add something like : >> ifconfig_vtnet0_ipv6="inet6 accept_rtadv" > >     Thanks a lot, I have added ifconfig_re0_ipv6="inet6 accept_rtadv" > and ifconfig_re0_ipv6="inet6 -ifdisabled". > >     Now ifconfig re0 returns : > > root@pythagore:/etc # ifconfig re0 > re0: flags=8843 metric 0 mtu 1500 >         options=201b >         ether d8:cb:8a:7d:10:59 >         inet 192.168.10.102 netmask 0xffffff00 broadcast 192.168.10.255 >         inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 >         inet6 fe80::dacb:8aff:fe7d:1059%re0 prefixlen 64 scopeid 0x1 >         nd6 options=23 >         media: Ethernet autoselect (1000baseT ) >         status: active > >     But interface doesn't take any address... After a long time (more than 10mn...) re0 has token a global Ipv6 address. Best regards, JB From owner-freebsd-hackers@freebsd.org Mon Jan 8 21:20:56 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1CA66E63106 for ; Mon, 8 Jan 2018 21:20:56 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:bb:dcff:fe50:d900]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "lerctr.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ECD7A754C2 for ; Mon, 8 Jan 2018 21:20:55 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To: References:Message-ID:To:From:Subject:Date:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=2qycNyYF7nbHwisI7yGbOwzoEd73JOdDhnavYEdrSBA=; b=IsmyN3vL2N3wE9n4SoJnuBHJUD XK+bvB9xWoffjoWOQMXoZDGXl8vGNVQURK47jopbzQy7M+/Ezozmka8MwCVVw/ZaB7GqXRqmGFGcZ YVQr8NSkKA1RrkKhRhlwlwLSNDBzd1bzzmR9hnCiyvXiigsPxejoOEFLJAzP7BE5WP/g=; Received: from [74.203.163.58] (port=14386 helo=[10.106.10.35]) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90 (FreeBSD)) (envelope-from ) id 1eYeqk-0003KM-8s; Mon, 08 Jan 2018 15:20:54 -0600 User-Agent: Microsoft-MacOutlook/10.a.0.180102 Date: Mon, 08 Jan 2018 15:20:21 -0600 Subject: Re: IPv6 From: Larry Rosenman To: BERTRAND Joel , Message-ID: <4BC5A494-5EE0-43AF-907B-441D10AD9323@lerctr.org> Thread-Topic: IPv6 References: <03877bcd-2d95-d0b8-6e8a-1628b619540e@systella.fr> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 21:20:56 -0000 You might need to run rtsold to force it to solicit an address from the rou= ter.=20 rtsold_enable=3D"YES" #in /etc/rc.conf and then service rtsold start --=20 Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 =20 =20 =EF=BB=BFOn 1/8/18, 2:55 PM, "BERTRAND Joel" wrote: BERTRAND Joel a =C3=A9crit : > Alan Somers a =C3=A9crit : >> >> You need to add something like : >> ifconfig_vtnet0_ipv6=3D"inet6 accept_rtadv" >=20 > Thanks a lot, I have added ifconfig_re0_ipv6=3D"inet6 accept_rtadv= "=20 > and ifconfig_re0_ipv6=3D"inet6 -ifdisabled". >=20 > Now ifconfig re0 returns : >=20 > root@pythagore:/etc # ifconfig re0 > re0: flags=3D8843 metric 0 mtu = 1500 > options=3D201b > ether d8:cb:8a:7d:10:59 > inet 192.168.10.102 netmask 0xffffff00 broadcast 192.168.10.= 255 > inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 > inet6 fe80::dacb:8aff:fe7d:1059%re0 prefixlen 64 scopeid 0x1 > nd6 options=3D23 > media: Ethernet autoselect (1000baseT ) > status: active >=20 > But interface doesn't take any address... =20 After a long time (more than 10mn...) re0 has token a global Ipv6 addr= ess. =20 Best regards, =20 JB _______________________________________________ freebsd-hackers@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" =20 From owner-freebsd-hackers@freebsd.org Wed Jan 10 10:26:37 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AFA1BE7781C for ; Wed, 10 Jan 2018 10:26:37 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout02.t-online.de (mailout02.t-online.de [194.25.134.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7167E6CE74; Wed, 10 Jan 2018 10:26:36 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd36.aul.t-online.de (fwd36.aul.t-online.de [172.20.26.137]) by mailout02.t-online.de (Postfix) with SMTP id F0E0441B3314; Wed, 10 Jan 2018 11:26:33 +0100 (CET) Received: from Stefans-MBP-LAN.fritz.box (bVis6ZZYghcKT8ZA2uLhpbELGpbAm5ch46uu7iomd3dOK9drmo-kLoreCsWFun1wbo@[87.151.219.126]) by fwd36.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1eZDaY-1qQGlE0; Wed, 10 Jan 2018 11:26:30 +0100 Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? To: "Rodney W. Grimes" , Eric van Gyzen Cc: Brooks Davis , Ian Lepore , Alan Somers , Freebsd hackers list , Yuri , Eugene Grosbein References: <201801081800.w08I0D0q022877@pdx.rh.CN85.dnsmgr.net> From: Stefan Esser Message-ID: Date: Wed, 10 Jan 2018 11:26:30 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <201801081800.w08I0D0q022877@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=windows-1252 Content-Language: de-DE Content-Transfer-Encoding: 7bit X-ID: bVis6ZZYghcKT8ZA2uLhpbELGpbAm5ch46uu7iomd3dOK9drmo-kLoreCsWFun1wbo X-TOI-MSGID: ae2ed1b3-cf4e-4927-af3a-5696d4328f56 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 10:26:37 -0000 Am 08.01.18 um 19:00 schrieb Rodney W. Grimes: >> On 01/08/2018 10:55, Rodney W. Grimes wrote: >>>> 08.01.2018 23:13, Eric van Gyzen wrote: >>>> >>>>> Right, which is the reason such bugs are hard to diagnose. Optionally >>>>> killing the process on close->EBADF would help find buggy code when >>>>> another thread did NOT re-open the file descriptor between the two close >>>>> calls. >>>> >>>> Wouldn't "close(f); assert(errno != EBADF);" be better? >> >> Putting the code in one place is far better than putting it in N >> places...after /finding/ those N places. Indeed, the purpose of this >> code is to help people find those places, even in their own code, >> outside of base. > > I agree with that. > >>> Or even >>> #ifdef DEBUG_CLOSE >>> #define close(f) close(f); assert(errno != EBADF); >>> #endif >> >> errno could have been EBADF before the close(). A successful close() >> does not modify errno. So, this would have be larger, making it even >> more unpalatable. > > Ok, so lets get a bit more clever, > #ifdef DEBUG_CLOSE > #define close(f) assert(close(f) && errno != EBADF) > #endif This will lead to close() being removed from the program, if NDEBUG is defined ... So, at least test for NDEBUG in addition to DEBUG_CLOSE, to enable this macro. From owner-freebsd-hackers@freebsd.org Wed Jan 10 10:48:00 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09F19E786D3 for ; Wed, 10 Jan 2018 10:48:00 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id AFC306DAC3; Wed, 10 Jan 2018 10:47:59 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id D187D27374; Wed, 10 Jan 2018 10:47:55 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id w0AAlehg021077 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Jan 2018 10:47:40 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id w0AAlbkk021076; Wed, 10 Jan 2018 10:47:37 GMT (envelope-from phk) To: Stefan Esser cc: "Rodney W. Grimes" , Eric van Gyzen , Brooks Davis , Ian Lepore , Alan Somers , Freebsd hackers list , Yuri , Eugene Grosbein Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? In-reply-to: From: "Poul-Henning Kamp" References: <201801081800.w08I0D0q022877@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21074.1515581257.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jan 2018 10:47:37 +0000 Message-ID: <21075.1515581257@critter.freebsd.dk> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 10:48:00 -0000 -------- In message , Stefan Esse= r wri tes: >> Ok, so lets get a bit more clever, >> #ifdef DEBUG_CLOSE >> #define close(f) assert(close(f) && errno !=3D EBADF) >> #endif > >This will lead to close() being removed from the program, >if NDEBUG is defined ... > >So, at least test for NDEBUG in addition to DEBUG_CLOSE, >to enable this macro. More importantly, it will lead to the assert failing if close(2) succeeds... The NDEBUG details is easiest solved by: #undef NDEBUG // assert()'s not to be removed #include -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-hackers@freebsd.org Wed Jan 10 11:12:33 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09254E796E3 for ; Wed, 10 Jan 2018 11:12:33 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout06.t-online.de (mailout06.t-online.de [194.25.134.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BEE196E807; Wed, 10 Jan 2018 11:12:32 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd15.aul.t-online.de (fwd15.aul.t-online.de [172.20.27.63]) by mailout06.t-online.de (Postfix) with SMTP id 4DD2E41C6C44; Wed, 10 Jan 2018 12:12:29 +0100 (CET) Received: from Stefans-MBP-LAN.fritz.box (bRCgkvZXrhtqx4gn2OVWo9wXLngP-4XpEBUElqM2AlySnfRSwE+lVz-L1gbID0FZ73@[87.151.219.126]) by fwd15.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1eZEJ2-2XpnSy0; Wed, 10 Jan 2018 12:12:28 +0100 Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? To: Poul-Henning Kamp Cc: "Rodney W. Grimes" , Eric van Gyzen , Brooks Davis , Ian Lepore , Alan Somers , Freebsd hackers list , Yuri , Eugene Grosbein References: <201801081800.w08I0D0q022877@pdx.rh.CN85.dnsmgr.net> <21075.1515581257@critter.freebsd.dk> From: Stefan Esser Message-ID: <0ec49613-0eb5-6c6d-f9aa-f88cf4c22659@freebsd.org> Date: Wed, 10 Jan 2018 12:12:27 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <21075.1515581257@critter.freebsd.dk> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ID: bRCgkvZXrhtqx4gn2OVWo9wXLngP-4XpEBUElqM2AlySnfRSwE+lVz-L1gbID0FZ73 X-TOI-MSGID: 6a85e584-6838-45da-ab93-bb24e4401669 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 11:12:33 -0000 Am 10.01.18 um 11:47 schrieb Poul-Henning Kamp: > -------- > In message , Stefan Esser wri > tes: > >>> Ok, so lets get a bit more clever, >>> #ifdef DEBUG_CLOSE >>> #define close(f) assert(close(f) && errno != EBADF) >>> #endif >> >> This will lead to close() being removed from the program, >> if NDEBUG is defined ... >> >> So, at least test for NDEBUG in addition to DEBUG_CLOSE, >> to enable this macro. > > More importantly, it will lead to the assert failing if close(2) > succeeds... Oh, yes, I missed that detail ;-) > The NDEBUG details is easiest solved by: > > #undef NDEBUG // assert()'s not to be removed > #include There has been the much better suggestion by Conrad Meyer (which uses a GCC extension that might not be supported by CLANG?) and the LD_PRELOAD hack suggested by Konstantin Belousov, which even works without recompilation of the program that is to be checked. I should have read the full thread before replying to a post in the middle of the discussion ... Regards, STefan From owner-freebsd-hackers@freebsd.org Wed Jan 10 15:41:26 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 831DDE62CB7 for ; Wed, 10 Jan 2018 15:41:26 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47C627A86B for ; Wed, 10 Jan 2018 15:41:25 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPS id w0AFfImF013949 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Jan 2018 10:41:18 -0500 (EST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.15.2/8.14.9/Submit) id w0AFfIMd013948; Wed, 10 Jan 2018 10:41:18 -0500 (EST) (envelope-from ken) Date: Wed, 10 Jan 2018 10:41:18 -0500 From: "Kenneth D. Merry" To: Florian Florensa Cc: freebsd-hackers@freebsd.org Subject: Re: Virtual SCSI Device Message-ID: <20180110154118.GA13659@mithlond.kdm.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Wed, 10 Jan 2018 10:41:18 -0500 (EST) X-Spam-Status: No, score=-2.6 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mithlond.kdm.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 15:41:26 -0000 On Mon, Jan 08, 2018 at 17:13:04 +0100, Florian Florensa wrote: > Hello, > > I've been trying to hack together a virtual SCSI device, and i've been > struggling withthe device creation. > > Here is the relevant code on pastebin : https://pastebin.com/e50bYHiQ > > the device never gets created, and xpt_action_default spits error > regarding unsupported codes : 0xE and 0x708 (XPT_DEV_ADVINFO and > XPT_SCAN_BUS). > > If anyone can give me some advice, i would appreciate, In your function online_device(): done_ccb = xpt_alloc_ccb_nowait(); xpt_setup_ccb(&done_ccb->ccb_h, vhba_softc->path, CAM_PRIORITY_NORMAL); done_ccb->ccb_h.func_code = XPT_GDEV_TYPE; xpt_action(done_ccb); xpt_async(AC_FOUND_DEVICE, done_ccb->ccb_h.path, done_ccb); AC_FOUND_DEVICE tells listeners that the device is ready to go. It is normally issued by the probe peripheral driver when it has completed probing a device. You really want to use xpt_rescan() instead. That will tell the probe code to start probing the device. If you want an example of a working virtual SCSI device, you can just use CTL. This will create a "fake" ramdisk (only backed by a small amount of real memory) and enable it: ctladm create -b ramdisk -s 104857600000 ctladm port -o on You can also use the block backend if you want to use a file or block device as the backing store. If you don't have real SCSI target capable hardware in your system, you'll still have the CAM SIM frontend for CTL which will allow you to access your device. See: sys/cam/ctl/ctl_frontend_cam_sim.c Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-hackers@freebsd.org Thu Jan 11 12:03:43 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92FBFEA4CB7 for ; Thu, 11 Jan 2018 12:03:43 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4EF906C449 for ; Thu, 11 Jan 2018 12:03:43 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yw0-x230.google.com with SMTP id x62so895129ywg.11 for ; Thu, 11 Jan 2018 04:03:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to; bh=vtUwVEIB2ae516snvE4wxF0tISu+WozBNpldOZb8bWY=; b=R93Q9JvfQeJkkKCqkDNdbyEZmPB+X0Yfojndv4SGicDegRodyCf1HqR8UgMUgPI2i5 Yfff04VYPUZu5APL8bz0eK5ZWLYji/OqHr/8Cp8n1SzBRUahL7xHp1HoTg1Pik1vzc1m /ZolWAx87fYRWVXO9luwTYezXaddXq3pqJfew= 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=vtUwVEIB2ae516snvE4wxF0tISu+WozBNpldOZb8bWY=; b=K+PYU7e1PCrl3kgywIOuOBowDTZ+34Toh/4uhtm7/fXFfQhyenCn/+38wu5cF5KzXn qnMpfom4jdaQJgxtsBUEt8WFSnvRTJf0/pTb0WOCRb39qrw5wJ6CLp3Pmij7FyWX5NvL OYvybivTtdw1dTDmQ5rz95fp90yBghHHgE5Niyq+vGdXcmRiVntj6RYOEbIxVMQX0RjQ /H+VeqooDPGu33TDQbUgiCOzMANBBnLPXpObLcOgSdDPpmeX5xkvdlKvtiFNTwQGhPsM Hgk1nQ2qsQspR4Oy7TK78Ezpz8WSP+H7rdUDALDeHCuWiQLBYvuC2jB6S0MVWqR/Is69 QJ7A== X-Gm-Message-State: AKwxytcHdnuCZD2T1XPWwI7tQ8N6i1q6XRuA26GD9cAfMyZe3jFRCjS+ mLrTRc1K6oICc0bWuyLA4xaWD1WH/77xSPXggIJ4ZKwD X-Google-Smtp-Source: ACJfBovMiQkh7SravDIxdAdoHCp7FhESgQ/FH2dTqLZ5h4uDIH05q5/OwgFjAX3hyN0wVGxIPl1QLyKV+b/AsE/ZpDU= X-Received: by 10.13.228.1 with SMTP id n1mr2830536ywe.6.1515672221915; Thu, 11 Jan 2018 04:03:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.46.79 with HTTP; Thu, 11 Jan 2018 04:03:11 -0800 (PST) From: Eitan Adler Date: Thu, 11 Jan 2018 04:03:11 -0800 Message-ID: Subject: 1 << 31 redux To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 12:03:43 -0000 Hi all, A few years ago I fixed most of the cases where we used 1 << 31 in FreeBSD. This expression is illegal in C. Since then the issue has arisen again. https://reviews.freebsd.org/D13858 fixed most of the non-contrib cases. I'd also like to see if we could find some more general solution, be it a compiler warning, bit set macro, or otherwise. -- Eitan Adler From owner-freebsd-hackers@freebsd.org Thu Jan 11 12:06:23 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75FFCEA5191 for ; Thu, 11 Jan 2018 12:06:23 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 37E0C6C6CF for ; Thu, 11 Jan 2018 12:06:23 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-yw0-x22b.google.com with SMTP id r205so908351ywb.3 for ; Thu, 11 Jan 2018 04:06:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pz43Yxp37W5wIPkgmk3ygg3zxn/L1XRNqVd66u1B3dQ=; b=YQxQPq0Fxl5bg18dNVTKZvWFkZSI+qOuPk7r0GzpQx5QxjPcf6QPylc/eHOx+HNOXN zf8RtFGa+dww5gCFvJ1fJHfDvZ1GOu4PivxPBJq3mE+x1xboh59AAd7AjPcsxhuy/x1o v8CH/kWHPkVUVEAtIisUyBdck3PI5FMAS5kVv0NXs+Dw+QcQdFy4KzxrbMUdE5vea02l bZ0NuekRuHNivcbLNJHi2WPKoS2Gb06tIur95sntoLyzXItTHMILEjcCGvxt5ya/3XRx xxqC+jT4ZYlCyq89FSLyEgNb28uqDYm2I467MRgkgTmOyy3p6mg9BlcMPE1+PKWDckk6 +Glw== 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=pz43Yxp37W5wIPkgmk3ygg3zxn/L1XRNqVd66u1B3dQ=; b=OkbaeLMnY6Tmu28okfInVyWdo8Y/paTMklq0M1jEwnDAVyZ7vtlP2a4mh9VDBmTq5y LA/MHgyIYBG/Uk4cwt0x3hDle6joUZ5hLi7BWmdmhofp/JMJkhdDIwYT10FT2y+B2G1i YmsmdN6aszt+gZ/+/ygGfgXABiF974hxaaSd0+f5oH8kVVSmEGJubh4BeXtbVMVnrQaR OmRsmwyd5b0Cqk2Tg67VkG/uA1sKiTqi0wCVS33F2qkEIqe2L7hUm9YKFtVrXNE/JGHd hT0XffOiJvn3x+yr1YZC9qiE3Ha7R9I6PFB9WWjC19y/D6J4pQcxHuShZst/I91oJ3z0 Ykmw== X-Gm-Message-State: AKGB3mIY3vwUXjdhpb29Mil08pkZTfRa8hEsXzwEEV1d15j4cRIQX77i d2SiX/pmeca1I1InzG5JN7ngfskBcGtgiq/02YkXRg== X-Google-Smtp-Source: ACJfBosgcGhWLPg2GVquB6AWAnk2aOyB1iRrliAIDfqjaO9vr0jraRdfmO4xSijxd1/ho3kMUxxYuBkv7YU90e4ELpU= X-Received: by 10.129.124.2 with SMTP id x2mr11000695ywc.314.1515672382340; Thu, 11 Jan 2018 04:06:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.165.10 with HTTP; Thu, 11 Jan 2018 04:05:51 -0800 (PST) In-Reply-To: References: From: Ed Schouten Date: Thu, 11 Jan 2018 13:05:51 +0100 Message-ID: Subject: Re: 1 << 31 redux To: Eitan Adler Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 12:06:23 -0000 2018-01-11 13:03 GMT+01:00 Eitan Adler : > I'd also like to see if we could find some more general solution, be it a > compiler warning, bit set macro, or otherwise. Does Clang already offer a warning for this? If so, we should consider adding it to WARNS=6. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands From owner-freebsd-hackers@freebsd.org Thu Jan 11 13:37:35 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3899E62097 for ; Thu, 11 Jan 2018 13:37:35 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 65A4A70863 for ; Thu, 11 Jan 2018 13:37:35 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.avinity.tv (unknown [77.95.97.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 99432470A2; Thu, 11 Jan 2018 14:37:26 +0100 (CET) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6E5DDFDF-BE48-4DCC-8E7E-427B9DF92CAF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: 1 << 31 redux Date: Thu, 11 Jan 2018 14:37:25 +0100 In-Reply-To: Cc: Eitan Adler , FreeBSD Hackers To: Ed Schouten References: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 13:37:35 -0000 --Apple-Mail=_6E5DDFDF-BE48-4DCC-8E7E-427B9DF92CAF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 11 Jan 2018, at 13:05, Ed Schouten wrote: >=20 > 2018-01-11 13:03 GMT+01:00 Eitan Adler : >> I'd also like to see if we could find some more general solution, be = it a >> compiler warning, bit set macro, or otherwise. >=20 > Does Clang already offer a warning for this? If so, we should consider > adding it to WARNS=3D6. There is a -Wshift-sign-overflow flag, but it isn't enabled by default: $ clang -Wshift-sign-overflow -c bar.c bar.c:1:26: warning: signed shift result (0x80000000) sets the sign bit = of the shift expression's type ('int') and becomes negative = [-Wshift-sign-overflow] int bar(void) { return 1 << 31; } ~ ^ ~~ I would expect quite a lot of stuff to break if you enable it, though. = :) And of course, there is -fsanitize=3Dundefined, which can catch this = kind of thing at runtime. -Dimitry --Apple-Mail=_6E5DDFDF-BE48-4DCC-8E7E-427B9DF92CAF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWldolQAKCRCwXqMKLiCW o19IAJ9ixD8oHFm42FnA5Xb6U5NKCE+E3gCbBHLqNDN8M01JnPjSLzSl6D+0CkA= =8FrU -----END PGP SIGNATURE----- --Apple-Mail=_6E5DDFDF-BE48-4DCC-8E7E-427B9DF92CAF-- From owner-freebsd-hackers@freebsd.org Thu Jan 11 15:47:19 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78A5BE6AA82 for ; Thu, 11 Jan 2018 15:47:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 298EF7708A for ; Thu, 11 Jan 2018 15:47:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-wm0-x235.google.com with SMTP id g75so6503993wme.0 for ; Thu, 11 Jan 2018 07:47:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qCBfBU59UaIFQBbe+WuoBGiMUSDCFuKDQatC0/PchzI=; b=zu3jvljphBs32YbK2cIUQOcXTYmVfRaIe8zWI1XRgSCJ7wb2jurrjHxJ5PeUUuUQRM pOznOvbGI2bBkiQBuLhwKveEh/XA20F4yfLZ7CLQJLAQcCC9wPBADIRIDgjTW8Gh6YGp CAUfY5w+dmcXfjnifIWB1vCfmFw0vZb4wdbIJQeU7Km9vjaVM+YUnSb1l0BAVwvQofkB ZeOu67NCnnkomNIpRY1EhIOrflmjr85rcfU8PQGjpV54JtVY6y0Tz31CsrDJVYAtDOBh L32gc/InYDP3J+e4G08ZwVjC2ptgj0XuzueUlAvqbOrlfT4yDMVzeAnZq5J1AGcIi8+1 A4Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=qCBfBU59UaIFQBbe+WuoBGiMUSDCFuKDQatC0/PchzI=; b=cDbuQMKurmyS/XYdPxT1k2Y4Vr5clqSpQSaC4xbTqDkqdif1AsvCcKV/9xolkQDH9C YtDl6uyuLT78/8Lu4q4rSRRVTk0YPxBmwOTRXA5NdyKKiQTl2mNPgWAa3tiseR3tu8Qi FhfIcnkHuLCyW+KTLUh0jnMYrdaYYSS1/iFfH4GZiA0FN99iW205rfjZcv9+aTQKHThH mzwvLEx1zOL86PT6O1I42xaR0M7vNguLooSPHc394jRHZrYIAUhe4ZfVQi8mcmR92lPM hqZp1AkYk3XxTZnap7Q7WC4Rqje4ezJAGCTEyyi9v5gzPzGu7SzWSjfNPXkDNgPDbLGR pZnQ== X-Gm-Message-State: AKGB3mL6MwdtJ9A0r2z4K2VMTdL9PaotosZn1EOft3HG76bV4sLF41cz gkuDwbtd9roV3AIizAbf9ieyY54j29g+ZFz3+R+I0Q== X-Google-Smtp-Source: ACJfBovSWblF60zsC8B7Xac00xfGpe+dpxMsiQFCNL8ZXnIa8d2ooKo9GA7NE2dRrcvf5GbVcTKTAQl+YsQwd2olIuE= X-Received: by 10.80.147.228 with SMTP id o91mr31682168eda.206.1515685637007; Thu, 11 Jan 2018 07:47:17 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.80.195.88 with HTTP; Thu, 11 Jan 2018 07:47:16 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: References: From: Warner Losh Date: Thu, 11 Jan 2018 08:47:16 -0700 X-Google-Sender-Auth: 27ekSWxqbT0FUpoKC55fytml3-s Message-ID: Subject: Re: 1 << 31 redux To: Dimitry Andric Cc: Ed Schouten , Eitan Adler , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 15:47:19 -0000 On Thu, Jan 11, 2018 at 6:37 AM, Dimitry Andric wrote: > On 11 Jan 2018, at 13:05, Ed Schouten wrote: > > > > 2018-01-11 13:03 GMT+01:00 Eitan Adler : > >> I'd also like to see if we could find some more general solution, be it > a > >> compiler warning, bit set macro, or otherwise. > > > > Does Clang already offer a warning for this? If so, we should consider > > adding it to WARNS=6. > > There is a -Wshift-sign-overflow flag, but it isn't enabled by default: > > $ clang -Wshift-sign-overflow -c bar.c > bar.c:1:26: warning: signed shift result (0x80000000) sets the sign bit of > the shift expression's type ('int') and becomes negative > [-Wshift-sign-overflow] > int bar(void) { return 1 << 31; } > ~ ^ ~~ > > I would expect quite a lot of stuff to break if you enable it, though. :) > > And of course, there is -fsanitize=undefined, which can catch this kind > of thing at runtime. > If we can't get people to fix the warnings we have in the tree now (especially the kernel), why enable new warnings that will just be ignored? Warner From owner-freebsd-hackers@freebsd.org Thu Jan 11 19:40:18 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8C55E7800B for ; Thu, 11 Jan 2018 19:40:18 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8974D823AE; Thu, 11 Jan 2018 19:40:18 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w0BJe9eD032394 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Jan 2018 11:40:09 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w0BJe8HQ032380; Thu, 11 Jan 2018 11:40:08 -0800 (PST) (envelope-from sgk) Date: Thu, 11 Jan 2018 11:40:08 -0800 From: Steve Kargl To: Warner Losh Cc: Dimitry Andric , Eitan Adler , FreeBSD Hackers , Ed Schouten Subject: Re: 1 << 31 redux Message-ID: <20180111194008.GA31206@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 19:40:18 -0000 On Thu, Jan 11, 2018 at 08:47:16AM -0700, Warner Losh wrote: > On Thu, Jan 11, 2018 at 6:37 AM, Dimitry Andric wrote: > > > On 11 Jan 2018, at 13:05, Ed Schouten wrote: > > > > > > 2018-01-11 13:03 GMT+01:00 Eitan Adler : > > >> I'd also like to see if we could find some more general solution, be it > > a > > >> compiler warning, bit set macro, or otherwise. > > > > > > Does Clang already offer a warning for this? If so, we should consider > > > adding it to WARNS=6. > > > > There is a -Wshift-sign-overflow flag, but it isn't enabled by default: > > > > $ clang -Wshift-sign-overflow -c bar.c > > bar.c:1:26: warning: signed shift result (0x80000000) sets the sign bit of > > the shift expression's type ('int') and becomes negative > > [-Wshift-sign-overflow] > > int bar(void) { return 1 << 31; } > > ~ ^ ~~ > > > > I would expect quite a lot of stuff to break if you enable it, though. :) > > > > And of course, there is -fsanitize=undefined, which can catch this kind > > of thing at runtime. > > > > If we can't get people to fix the warnings we have in the tree now > (especially the kernel), why enable new warnings that will just be ignored? Create WARNS=7 with -Werror added to command line option. Edit the various *.mk files to force WARNS=7 Watch warnings get fixed. -- Steve From owner-freebsd-hackers@freebsd.org Fri Jan 12 04:53:17 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4C06E70F14; Fri, 12 Jan 2018 04:53:17 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BD3176B63; Fri, 12 Jan 2018 04:53:16 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074422-fc5ff700000030c7-1d-5a583e034520 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 1D.5E.12487.40E385A5; Thu, 11 Jan 2018 23:48:04 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w0C4m2hh024784; Thu, 11 Jan 2018 23:48:02 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w0C4lxDY024134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jan 2018 23:48:01 -0500 Date: Thu, 11 Jan 2018 22:47:59 -0600 From: Benjamin Kaduk To: freebsd-hackers@FreeBSD.org Cc: freebsd-current@FreeBSD.org Subject: FINAL CALL for 2017Q4 quarterly status reports Message-ID: <20180112044759.GT72574@kduck.kaduk.org> References: <20171226002716.GG59505@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <20171226002716.GG59505@kduck.kaduk.org> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRmVeSWpSXmKPExsUixCmqrctiFxFlcG67ssWcNx+YLLZv/sfo wOQx49N8lgDGKC6blNSczLLUIn27BK6Ma0dWsRQcFK7o625mbGD8JNDFyMkhIWAiMbP3G2sX IxeHkMBiJom9p56wQDgbGSWeL9nGDuFcZZLo/3CbFaSFRUBVoun3NEYQm01ATWL9imvMILaI gLzEvqb37CA2M5D9a2sTmC0sYC5x+3MPE4jNC7TuVcNUMFsIyF5yag0jRFxQ4uRMkM0cQL1l Ev9fhUCY0hLL/3GAVHAKmEo82riXDcQWFVCW2Nt3iH0Co8AsJM2zEJpnITTPAjtHS+LGv5dM GMK2EuvWvWdZwMi2ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdULzezRC81pXQTIyi82V2UdjBO /Od1iFGAg1GJh/dBbniUEGtiWXFl7iFGSQ4mJVHePelAIb6k/JTKjMTijPii0pzU4kOMKkC7 Hm1YfYFRiiUvPy9VSYS3phuojjclsbIqtSgfpkyag0VJnNfDRDtKSCA9sSQ1OzW1ILUIJivD waEkwetqExElJFiUmp5akZaZU4KQZuLgPMQowcEDNPyqNVANb3FBYm5xZjpE/hSjLseNF6/b mIXALpAS5y0DGSQAUpRRmgc3B5SuJLL317xiFAd6UZhXH2QUDzDVwU16BbSECWjJ+Y2hIEtK EhFSUg2MC7NubPxdofe1P+xbepAYT1t7gPL1OjahoPnpxzNjn1ZXiG8yEjl40Pno9Mi2aL3b p49NkOn5ETyHv1kv8cHblBkMuzN4l7Bbsl2fck5nuekORfuM6GfyDg+K2QyviRzwynW97tXz tWaF7eXQUz8cd3kxiq7bJ2ATtePL3kMHeFqufpffa+euxFKckWioxVxUnAgAM1xHuTIDAAA= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 04:53:17 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear FreeBSD Community, This is the last call for submissions for the 2017Q4 FreeBSD Quarterly Status Update. The deadline for submissions is January 14, 2018, for work done in October through December. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about work that is underway and completed. Submission of reports is not restricted to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at monthly@FreeBSD.org . (Do be sure, though, to save the form output and not the form itself! In particular, the Google Chrome "save as" function does not save the generated output for some reason.) There is also an XML template [2] that can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4][5] for ideas on the style and format. We look forward to seeing your 2017Q4 reports! Thanks, Ben (on behalf of monthly@) [1] https://www.FreeBSD.org/cgi/monthly.cgi [2] https://www.FreeBSD.org/news/status/report-sample.xml [3] https://www.FreeBSD.org/news/status/howto.html [4] https://www.FreeBSD.org/news/status/report-2017-07-2017-09.html [5] https://www.FreeBSD.org/news/status/report-2017-04-2017-06.html --SUOF0GtieIMvvwua Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlpYPfkACgkQKNmm82Tr dRJNTAwfU7M53e5Zdq1cg4FP3MZKi0dFyx7n12HxGuSk4ID9/J5UbVx1tVkTLFKk 58ewVKXLe6u2uo+dZ0IdUI2L4CY/V+/g6R1SQzSShjkaM5KU+GK/WIK6g2n0oTZt 5DtSAyiSM+w6FRl4b+UU+jbHaPusDNCoZEw3Oa4OxVZCMCXXtoaf/smyckErEyTj XMu2bfapXycqaijWH0lDfF/+nbsUkrffDt36cUBpcd3Ehok67oZe4qABCnd99b1X 0eAgS4HqwNk/ShtSrg5JJDPIBc2xBB/+W12MS2gBcpA883JB7wFixruH/hktRM8Z 6sx1d25fj2Fkza22SaOftcr9cGTECoKAsqkjX4yD+FTjm/rCra1MG3ELmA0zpRhp kVCRRuKbvjcvvdInYeeJRfjA1tmpGFVVAZWImxX1tsYk+yd1Hf1JSONDC1P3a4HN P1YHvos7PsR6mR1EYHeUntMi0vpFgwYJx4GqyeJwmWhHJ0Jfzuf5U17dG9n2oLhJ v/xWhtG5tJdnUw== =myiJ -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- From owner-freebsd-hackers@freebsd.org Fri Jan 12 15:09:29 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 469CCE69F6A for ; Fri, 12 Jan 2018 15:09:29 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 146E66EEC3 for ; Fri, 12 Jan 2018 15:09:29 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: by mail-it0-x22e.google.com with SMTP id c16so9401598itc.5 for ; Fri, 12 Jan 2018 07:09:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dragondata.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=KQ6xC8q8YBbsUlZSdSP1DmNgTvHvQMPc5LEaI9cVu20=; b=m/F/wZtr5yCn4cPPksDjlQm+jKj9I7vFJgwQ9RCOqRkhJGqF8aqh03pSNLbjGALEIG 95LvrEryUes4jAevtlz9Dq5GCTgmDBTVeFRZN8DzLhxrd41qeS+FemigLumGC0Q1ibC7 VXGfxMDTnz9WmTfsIxAuVFVQISa3Da02a3yvM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=KQ6xC8q8YBbsUlZSdSP1DmNgTvHvQMPc5LEaI9cVu20=; b=RBsxb5mMUJfXpaVTAB4lNH8/pfnoIXy3WHa23BU+kdxFHGOFOXB3KO9Z7MKXhJk+Oq pWAg8Br3TyESrN2R7jHpYPF+iWuTuYdhtqMUoQH1ErjuwoBYrA6WZCDlmtnjpUU/Wj2i 0q09tJOpc+FaVAJWNIW9KxGvWapUd2Qa9UOtL/Q+IjEZZfI9minxJGT+O+naKdvet8pa EczicSF8iR+kXrGTGgJmpr4yQOvdEUtGanqOHOjl7v4zBX2wp6uWz4R33tkjlDIKfwe9 5Qnog0DVztSGVu0yQCnvjkDyEc0XMprPT1YcAX2zXtOT2g2vscinFaVKoSomGiiPW0P5 VIww== X-Gm-Message-State: AKwxytc38XB74jrMn4wAEPqf6ED97EH3RT9d1HTIOvXGjtPDp1Wfl9Uf 6rPfl+xHitcpYKMIeNGafEaDVFHkhUA= X-Google-Smtp-Source: ACJfBouKi5461oSR/ptR3bG+Vq8kMc4UrqtbzaS7dp/qXfAcFqU1MKO9ffKW5meJTEUlvhautSAyAA== X-Received: by 10.36.9.144 with SMTP id 138mr4893596itm.125.1515769767989; Fri, 12 Jan 2018 07:09:27 -0800 (PST) Received: from unassigned.v6.your.org ([2001:4978:1:45:f8d5:9e8:2741:8367]) by smtp.gmail.com with ESMTPSA id z102sm9924168ioi.86.2018.01.12.07.09.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jan 2018 07:09:27 -0800 (PST) From: Kevin Day Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: sysctl(8) can't read IFMIB nodes Message-Id: <18D7A1E9-8564-47D7-90D7-CA2E94F7F9F7@dragondata.com> Date: Fri, 12 Jan 2018 09:09:26 -0600 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 15:09:29 -0000 IFMIB doesn't work with the command-line tool sysctl(8). = src/tools/tools/ifinfo uses IFMIB correctly though, so I looked at why: ifinfo is calling sysctlbyname() directly: 86387 ifinfo CALL = __sysctl(0x7fffffffe510,0x6,0x7fffffffe530,0x7fffffffe100,0,0) 86387 ifinfo SCTL "net.link.generic.ifdata.1.1" 86387 ifinfo RET __sysctl 0 But using sysctl directly doesn't: # ktrace sysctl net.link.generic.ifdata.1.1 sysctl: unknown oid 'net.link.generic.ifdata.1.1': No such file or = directory The problem is that sysctl(8) is calling sysctl.name2oid on it first, so = that it can get type information on it: 21090 sysctl CALL = __sysctl(0x7fffffffda00,0x2,0x7fffffffd970,0x7fffffffd9f8,0x7fffffffe210,0= x1b) 21090 sysctl SCTL "sysctl.name2oid" 21090 sysctl RET __sysctl -1 errno 2 No such file or directory 21090 sysctl CALL write(0x2,0x7fffffffd2d0,0x8) 21090 sysctl GIO fd 2 wrote 8 bytes "sysctl: " 21090 sysctl RET write 8 21090 sysctl CALL write(0x2,0x7fffffffd3c0,0x29) 21090 sysctl GIO fd 2 wrote 41 bytes "unknown oid 'net.link.generic.ifdata.1.1'" This fails because in the kernel, ifmib isn't setting up oids for every = possible entry under ifdata, it configures the parent node then captures = every request under it. I'm specifically looking to be able to get link state/speed on all = interfaces from what's essentially a shell script using tools that only = exist in a base install. If I were trying to fix this with a patch that would likely get = accepted, what's the best way of fixing this? 1) Making IFMIB create sysctls for every interface? This would require = it get involved every time an interface is added or deleted, which might = not be popular because this is a very infrequently used feature. 2) Allowing sysctl(8) to forge ahead anyway with reading/writing to = sysctls without oids (maybe only if the -o flag is present?) 3) Overhauling sysctl.oidfmt and oiddescr to somehow work by names as = well as oids so that sysctl(8) doesn't need to translate them to oids = first From owner-freebsd-hackers@freebsd.org Sat Jan 13 03:25:28 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2F52E6E969 for ; Sat, 13 Jan 2018 03:25:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-141.reflexion.net [208.70.210.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7308D703D3 for ; Sat, 13 Jan 2018 03:25:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4947 invoked from network); 13 Jan 2018 02:58:41 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 13 Jan 2018 02:58:41 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.4) with SMTP; Fri, 12 Jan 2018 21:58:41 -0500 (EST) Received: (qmail 10921 invoked from network); 13 Jan 2018 02:58:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Jan 2018 02:58:40 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 10FC7EC7C39; Fri, 12 Jan 2018 18:58:40 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Builworld stalls on rpi2 [various processes stuck in pfault and vmwait with 1996M Free Swap listed by top] From: Mark Millard In-Reply-To: <20180113024346.GB48702@www.zefox.net> Date: Fri, 12 Jan 2018 18:58:39 -0800 Cc: Freebsd-arm , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <866A14D4-2D81-4C2E-B902-0AD05514E709@dsl-only.net> References: <20180113005426.GA48702@www.zefox.net> <19904500-5819-47AC-9666-7103ED87C1CA@dsl-only.net> <20180113024346.GB48702@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 03:25:28 -0000 On 2018-Jan-12, at 6:43 PM, bob prohaska wrote: > On Fri, Jan 12, 2018 at 05:53:03PM -0800, Mark Millard wrote: >>=20 >> On 2018-Jan-12, at 4:54 PM, bob prohaska = wrote: >>=20 >>>=20 >>> The machine still answers ping. Typing escape control-b does not >>> bring up a debugger, did the keysequence change? Power cycling seems >>> to be the only way out. >>=20 >> With or without: >>=20 >> options ALT_BREAK_TO_DEBUGGER >>=20 >> For with: ~^B (with being >> and ^ being ) is an alternate with >> this. >>=20 >=20 > The line=20 > options ALT_BREAK_TO_DEBUGGER > does not appear in the GENERIC kernel, but > neither does the ue identifier for ethernet. > I thought perhaps both were included from > elsewhere. Maybe not. I'll add it. >=20 >=20 I tend to include GENERIC in another file and then specify things I want as well or instead: # more /usr/src/sys/arm/conf/GENERIC-NODBG=20 include "GENERIC" ident GENERIC-NODBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger # Extra stuff: #options VERBOSE_SYSINIT # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE options KLD_DEBUG #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # Disable any extra checking for. . . nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC nooptions BUF_TRACKING nooptions FULL_BUF_TRACKING nooptions DEADLKRES # Enable the deadlock resolver nooptions USB_DEBUG nooptions USB_REQ_DEBUG nooptions USB_VERBOSE # more /usr/src/sys/arm/conf/GENERIC-DBG include "GENERIC" ident GENERIC-DBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger # Extra stuff: #options VERBOSE_SYSINIT # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KLD_DEBUG #options KTR #options KTR_MASK=3DKTR_TRAP|KTR_PROC ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # Enable any extra checking for. . . options INVARIANTS # Enable calls of extra sanity = checking options INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS options WITNESS # Enable checks to detect = deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC options BUF_TRACKING options FULL_BUF_TRACKING options DEADLKRES # Enable the deadlock resolver options USB_DEBUG #options USB_REQ_DEBUG #options USB_VERBOSE This avoids changing the official GENERIC. Of course I have to specify the non-default file name for the build. >> I've see the smsc0 messages before but I'm >> not up to -r327664+ yet. This has been with >> a non-debug kernel running. >>=20 >> I've had building large ports get into such states, >> especially while at least one large link operation >> was active with other fairly large processes, >> as I remember. >>=20 >> Note all the pfault and vmwait lines. It looks like >> -r327316 and -r327468 did not happen to avoid this. >> It looks like the paging/swaping has gotten stuck >> in some way. How tied that might be to smsc0 >> messages, I've no clue. >>=20 >> You might get through by using -j3 or -j2 or -j1 which >> likely would use less process space at once (worst case) >> than -j4 happened to. >>=20 >> Of course there are other time consequences as you >> approach -j1 (or no explicit -j for the buildworld >> at all). >>=20 >>=20 >=20 > I'd rather not slow things down, but slow is better than > crashed.... =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sat Jan 13 02:43:50 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 504A2E6A9D5; Sat, 13 Jan 2018 02:43:50 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2568E6DD1F; Sat, 13 Jan 2018 02:43:49 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w0D2hlL8049243 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Jan 2018 18:43:48 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w0D2hlMs049242; Fri, 12 Jan 2018 18:43:47 -0800 (PST) (envelope-from fbsd) Date: Fri, 12 Jan 2018 18:43:46 -0800 From: bob prohaska To: Mark Millard Cc: Freebsd-arm , FreeBSD Hackers , bob prohaska Subject: Re: Builworld stalls on rpi2 [various processes stuck in pfault and vmwait with 1996M Free Swap listed by top] Message-ID: <20180113024346.GB48702@www.zefox.net> References: <20180113005426.GA48702@www.zefox.net> <19904500-5819-47AC-9666-7103ED87C1CA@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19904500-5819-47AC-9666-7103ED87C1CA@dsl-only.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-Mailman-Approved-At: Sat, 13 Jan 2018 04:04:34 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 02:43:50 -0000 On Fri, Jan 12, 2018 at 05:53:03PM -0800, Mark Millard wrote: > > On 2018-Jan-12, at 4:54 PM, bob prohaska wrote: > > > > > The machine still answers ping. Typing escape control-b does not > > bring up a debugger, did the keysequence change? Power cycling seems > > to be the only way out. > > With or without: > > options ALT_BREAK_TO_DEBUGGER > > For with: ~^B (with being > and ^ being ) is an alternate with > this. > The line options ALT_BREAK_TO_DEBUGGER does not appear in the GENERIC kernel, but neither does the ue identifier for ethernet. I thought perhaps both were included from elsewhere. Maybe not. I'll add it. > I've see the smsc0 messages before but I'm > not up to -r327664+ yet. This has been with > a non-debug kernel running. > > I've had building large ports get into such states, > especially while at least one large link operation > was active with other fairly large processes, > as I remember. > > Note all the pfault and vmwait lines. It looks like > -r327316 and -r327468 did not happen to avoid this. > It looks like the paging/swaping has gotten stuck > in some way. How tied that might be to smsc0 > messages, I've no clue. > > You might get through by using -j3 or -j2 or -j1 which > likely would use less process space at once (worst case) > than -j4 happened to. > > Of course there are other time consequences as you > approach -j1 (or no explicit -j for the buildworld > at all). > > > I'd rather not slow things down, but slow is better than crashed.... 8-) Thanks for writing! bob prohaska From owner-freebsd-hackers@freebsd.org Sat Jan 13 06:34:49 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94B92E77A69 for ; Sat, 13 Jan 2018 06:34:49 +0000 (UTC) (envelope-from leeb@ratnaling.org) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 53696768E3 for ; Sat, 13 Jan 2018 06:34:49 +0000 (UTC) (envelope-from leeb@ratnaling.org) Received: by mail-it0-x236.google.com with SMTP id c16so11512392itc.5 for ; Fri, 12 Jan 2018 22:34:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ratnaling-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=vMOh31w2zP7yjKzYAA/JBmnOQVAh5ki9oqt/HX9ZTq0=; b=Zp/KSJYBRf+wHgluKtNmbLP5bnOCVFRBe/pucjsjtds89cyoWCGpdhxPIMfehs8G16 UU/ERa0YVFvkucifTe6rFUn//h4tm8NdEkHz53nIza4h8sVAkrnEsrQInNrCd8lujMjr V/3IMXJot6iDayVYU/1PxYTUUW3U85lGI1JKi5ySt0wGiTdZeFHOHoDiNGXdtaTFpCn7 Z+bcxXdr3Q0EDJq+It3qrNnSHTc/1thpOqDwPRLew8OpTSFd+YzkHvETnJbRUk5hp6LK IoFMewjIZc24knUiw2PrYJ5AukIVgAmE5Crg7xQUw1Y2iRqefqo/l2Vt0MvzavuyaLsf OIWw== 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=vMOh31w2zP7yjKzYAA/JBmnOQVAh5ki9oqt/HX9ZTq0=; b=gi7deVL8Tv/Uv9F9Qq3thugRA4hSZuYmQwG+lXgs2uYF6L8LVE1FSDjlx8/Tfw3xaW +akPKD78jc3vCDXj03VXvwTg18IbvQVn/JylLwBzENrzctLSYtfmeZG6DFrDg3lwFrC9 rYITBNywRZGtjebrimO0L0SvhsVC9yneUxDfL8bnoRvtvqOb3xuQpAPxS1laHRUsN+8S pra5X3KcPLjn9RlnCNvbq0zZO9TicD0+cV/gZfuTrNSJe8eZA9sFFiUbKL4xOjHzoP10 Soe/prKnMLBDP3b2biGeodqOOiaLCkzmPI6aQn5quDhv+qvj8QvOrUrorCXoNgzV4ONR Ha5g== X-Gm-Message-State: AKwxyteuDZD9Lc/Tcfx4cXiPbAe7LOIJdSQ2QROODb7ItGYMe9PXbOhW 0AoTuS8UEihENNpozq2p93Z5suLNfdSsPERXfy74ZnfY X-Google-Smtp-Source: ACJfBouKrBS+l137uZrfxkWdx94D+NyTGxD7eldt55jzthg1NmJNzz/qqJx2wZgklxSpNqsPlV5YRmTjQBWIeZGJVTs= X-Received: by 10.36.76.68 with SMTP id a65mr6761853itb.57.1515825287968; Fri, 12 Jan 2018 22:34:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.157.200 with HTTP; Fri, 12 Jan 2018 22:34:47 -0800 (PST) From: Lee Brown Date: Fri, 12 Jan 2018 22:34:47 -0800 Message-ID: Subject: bsdinstaller question To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 06:34:49 -0000 I've rolled my own release, placed base.txz, kernel.txz and MANIFEST onto my ftp server. The stock install CD complains about the checksum for base.txz because it uses the MANIFEST from the ISO and ignores the one at the FTP site. Is there some way I can override this? I couldn't see anything in the bsdinstall manpage. I'd rather not have to spend the time generating boot media, it's quicker to go into Shell mode and manually install the OS. Thanks -- lee From owner-freebsd-hackers@freebsd.org Sat Jan 13 08:59:48 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4D59E7E82F for ; Sat, 13 Jan 2018 08:59:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-152.reflexion.net [208.70.210.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 809357CB05 for ; Sat, 13 Jan 2018 08:59:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13158 invoked from network); 13 Jan 2018 01:53:05 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 13 Jan 2018 01:53:05 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.4) with SMTP; Fri, 12 Jan 2018 20:53:05 -0500 (EST) Received: (qmail 15122 invoked from network); 13 Jan 2018 01:53:05 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Jan 2018 01:53:05 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 831DBEC944A; Fri, 12 Jan 2018 17:53:04 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Builworld stalls on rpi2 [various processes stuck in pfault and vmwait with 1996M Free Swap listed by top] From: Mark Millard In-Reply-To: <20180113005426.GA48702@www.zefox.net> Date: Fri, 12 Jan 2018 17:53:03 -0800 Cc: Freebsd-arm , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <19904500-5819-47AC-9666-7103ED87C1CA@dsl-only.net> References: <20180113005426.GA48702@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 08:59:48 -0000 On 2018-Jan-12, at 4:54 PM, bob prohaska wrote: > Trying to self-host a build of r327859 using a GENERIC kernel at =20 > r327664, make seems to stall, with top showing >=20 > last pid: 28822; load averages: 3.12, 3.95, 5.09 up 0+08:39:01 = 16:39:49 > 50 processes: 1 running, 47 sleeping, 2 waiting > CPU: 0.0% user, 0.0% nice, 0.2% system, 0.9% interrupt, 98.9% idle > Mem: 527M Active, 16M Inact, 98M Laundry, 148M Wired, 86M Buf, 3272K = Free > Swap: 2048M Total, 52M Used, 1996M Free, 2% Inuse >=20 > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU = COMMAND > 769 bob 1 20 0 6204K 1344K CPU0 0 3:02 0.68% = top > 674 bob 1 20 0 11188K 1636K select 1 0:18 0.04% = sshd > 719 root 1 20 0 4572K 552K select 0 0:03 0.01% = make > 28760 root 1 52 0 346M 302M pfault 2 13:59 0.00% = c++ > 28812 root 1 52 0 208M 167M pfault 2 2:54 0.00% = c++ > 28815 root 1 52 0 212M 171M pfault 1 2:20 0.00% = c++ > 22172 root 1 20 0 13036K 4484K select 2 2:09 0.00% = make > 28820 root 1 52 0 145M 104M pfault 1 2:00 0.00% = c++ > 21438 root 1 20 0 7092K 556K select 0 0:05 0.00% = make > 695 root 1 20 0 4016K 552K select 1 0:04 0.00% = make > 593 root 1 20 0 8156K 1596K vmwait 1 0:04 0.00% = sendmail > 20119 root 1 20 0 4516K 548K select 1 0:03 0.00% = make > 21427 root 1 20 0 4484K 556K select 2 0:02 0.00% = make > 590 root 1 20 0 10148K 1552K vmwait 1 0:02 0.00% = sshd > 22168 root 1 20 0 3956K 560K select 0 0:02 0.00% = make > 600 root 1 20 0 4960K 0K WAIT 2 0:01 0.00% = > 461 root 1 20 0 4916K 1020K select 1 0:01 0.00% = syslogd >=20 > The machine seems dead, none of the ssh sessions responds to = keystrokes,=20 > nor the serial console. There are a smattering of=20 > smsc0: warning: Failed to write register 0x114 > smsc0: warning: Failed to read register 0x114 > smsc0: warning: MII is busy > smsc0: warning: Failed to write register 0x114 >=20 > The machine still answers ping. Typing escape control-b does not > bring up a debugger, did the keysequence change? Power cycling seems > to be the only way out. With or without: options ALT_BREAK_TO_DEBUGGER For with: ~^B (with being and ^ being ) is an alternate with this. I've see the smsc0 messages before but I'm not up to -r327664+ yet. This has been with a non-debug kernel running. I've had building large ports get into such states, especially while at least one large link operation was active with other fairly large processes, as I remember. Note all the pfault and vmwait lines. It looks like -r327316 and -r327468 did not happen to avoid this. It looks like the paging/swaping has gotten stuck in some way. How tied that might be to smsc0 messages, I've no clue. You might get through by using -j3 or -j2 or -j1 which likely would use less process space at once (worst case) than -j4 happened to. Of course there are other time consequences as you approach -j1 (or no explicit -j for the buildworld at all). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sat Jan 13 09:08:59 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A2EEE7F108; Sat, 13 Jan 2018 09:08:59 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 648EF7D1AF; Sat, 13 Jan 2018 09:08:57 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id B30F827342; Sat, 13 Jan 2018 09:08:49 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id w0D98X3F036829 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 13 Jan 2018 09:08:33 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id w0D98XhH036828; Sat, 13 Jan 2018 09:08:33 GMT (envelope-from phk) To: Mark Millard cc: bob prohaska , FreeBSD Hackers , Freebsd-arm Subject: Re: Builworld stalls on rpi2 [various processes stuck in pfault and vmwait with 1996M Free Swap listed by top] In-reply-to: <19904500-5819-47AC-9666-7103ED87C1CA@dsl-only.net> From: "Poul-Henning Kamp" References: <20180113005426.GA48702@www.zefox.net> <19904500-5819-47AC-9666-7103ED87C1CA@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <36826.1515834513.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Jan 2018 09:08:33 +0000 Message-ID: <36827.1515834513@critter.freebsd.dk> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 09:08:59 -0000 -------- In message <19904500-5819-47AC-9666-7103ED87C1CA@dsl-only.net>, Mark Milla= rd wr ites: >> Trying to self-host a build of r327859 using a GENERIC kernel at = >> r327664, make seems to stall, with top showing In all likelyhood you do not have enough swap configured, getting through the llvm compilation takes insane amounts of VM these days. At the very least you can forget anything about make -j N for N>1 -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-hackers@freebsd.org Sat Jan 13 09:32:25 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C4AF7EA538C for ; Sat, 13 Jan 2018 09:32:25 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 89B1E7E354 for ; Sat, 13 Jan 2018 09:32:25 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yw0-x22b.google.com with SMTP id b129so3535736ywa.8 for ; Sat, 13 Jan 2018 01:32:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8nPLfyWdgKrbmrGgOFMsTnki0Xk5Ll33WbVhKqugSS8=; b=Ph5BWQkQIK6wA3/+WgXqrFcXnS5PGQHnYsUCzvHMfDILld45Q41pptMAojfhL9UZiQ EpaqnXTbHD7BuZBbUVYOCYC/u8MqKfk8EpjjX7t1qSiu13dkZ5VcbkWBWpLiTgbb3wT8 qvnpoWPD7R7xru8TWdv039RHdzXbZRx7voPB4= 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=8nPLfyWdgKrbmrGgOFMsTnki0Xk5Ll33WbVhKqugSS8=; b=fZrIoQ/xD0AOouyAeYmqlOfgZntLSbE07JDt10IPD1f6UWL97HWJDAWz2GHGo8/82Z l1pZ0lsFo/fzKilRT47NoHJooLt7TIZqb5DEgJRhsnnplB8Rp50fqxIViYZ9qgtEvrAL 5TNpX8bVknYzwReqyiADUqoAHiBh4RZ0ZnkQDGChOCqr7QQxv8x0EMLWv6Hk3tveS+3f pQOG38m5M6Y+4F46AjCBt5rdm/5VIsqxFnAmFXGyxFrEBVURIujMj7yTyijO/mLdbirj GQZHvubzp+0P8VqsNu0CdtZ978oEQdS6ga4VzgXY7gKIkR0Mpcf0ltumZVcpf0uT+KMM 5zzQ== X-Gm-Message-State: AKwxytd93gOfyAJDX7J5KkrPLth+1EjTVHqg+XkyY6ibj/GRGFsTyanH rbI/n3zK+fcqboODCc2jI7KXbneoU68h7cubbGM5EA== X-Google-Smtp-Source: ACJfBosinC9flQsUyWR89R2dfo1g4mhV+CuX6LWZlCVuioNUZBRXos9HqIfWPXkn3NTs5qH04hB5gdBmvtUBB1kBJko= X-Received: by 10.13.228.1 with SMTP id n1mr9126548ywe.6.1515835944381; Sat, 13 Jan 2018 01:32:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.46.79 with HTTP; Sat, 13 Jan 2018 01:31:53 -0800 (PST) In-Reply-To: References: From: Eitan Adler Date: Sat, 13 Jan 2018 01:31:53 -0800 Message-ID: Subject: Re: 1 << 31 redux To: Warner Losh Cc: Dimitry Andric , Ed Schouten , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 09:32:25 -0000 On 11 January 2018 at 07:47, Warner Losh wrote: > > > If we can't get people to fix the warnings we have in the tree now > (especially the kernel), why enable new warnings that will just be ignored? > We've been doing a reasonable job with warnings until now. Either way, at higher warnings levels we should add what we can. -- Eitan Adler From owner-freebsd-hackers@freebsd.org Sat Jan 13 15:50:50 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 470D6E6F7D4 for ; Sat, 13 Jan 2018 15:50:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-140.reflexion.net [208.70.210.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E967B6A4ED for ; Sat, 13 Jan 2018 15:50:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1360 invoked from network); 13 Jan 2018 15:50:47 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 13 Jan 2018 15:50:47 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.4) with SMTP; Sat, 13 Jan 2018 10:50:47 -0500 (EST) Received: (qmail 22258 invoked from network); 13 Jan 2018 15:50:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Jan 2018 15:50:47 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 086D2EC93F7; Sat, 13 Jan 2018 07:50:47 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Builworld stalls on rpi2 [various processes stuck in pfault and vmwait with 1996M Free Swap listed by top] From: Mark Millard In-Reply-To: <36827.1515834513@critter.freebsd.dk> Date: Sat, 13 Jan 2018 07:50:46 -0800 Cc: bob prohaska , FreeBSD Hackers , Freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <3EDDDF6B-684A-436E-A2F5-3868BB279951@dsl-only.net> References: <20180113005426.GA48702@www.zefox.net> <19904500-5819-47AC-9666-7103ED87C1CA@dsl-only.net> <36827.1515834513@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 15:50:50 -0000 On 2018-Jan-13, at 1:08 AM, Poul-Henning Kamp = wrote: > In message <19904500-5819-47AC-9666-7103ED87C1CA@dsl-only.net>, Mark = Millard wr > ites: >=20 >>> Trying to self-host a build of r327859 using a GENERIC kernel at =20 >>> r327664, make seems to stall, with top showing [That text is Bob Prohaska's, not mine.] > In all likelyhood you do not have enough swap configured, getting > through the llvm compilation takes insane amounts of VM these days. As I remember, for the 1 GiByte of RAM that a RPi2B V1.1 has, the boot sequence complains about having Swap: 2048M Total without also adjusting some other defaults, reporting the intended maximum is smaller. As I remember the figure it reports for the intended maximum for the defaults was between 1.6 GiBytes and 1.7 GiBytes. (I do not remember the detailed figure.) [I assume a RPi2B V1.1 (cortex-a7) based instead of the cortex-a53 based V1.2.] [An RPi3 with 1 GiByte of RAM and the aarch64 FreeBSD allows more swap before complaining, something over 3.5 GiBytes of as I remember.] The interesting part of Bob's report was that top showed only a little swap used at the time: Swap: 2048M Total, 52M Used, 1996M Free, 2% Inuse But it shows: Mem: 527M Active, 16M Inact, 98M Laundry, 148M Wired, 86M Buf, 3272K = Free as well, apparently insufficient free memory to put the available swap space to use? FreeBSD's head looks to need to be more aggressive about swapping out so that it keeps enough free-space to allow swapping to occur (at least for some types of contexts). For reference, the pfaults and vmwaits listed by top were: 28760 root 1 52 0 346M 302M pfault 2 13:59 0.00% = c++ 28812 root 1 52 0 208M 167M pfault 2 2:54 0.00% = c++ 28815 root 1 52 0 212M 171M pfault 1 2:20 0.00% = c++ 28820 root 1 52 0 145M 104M pfault 1 2:00 0.00% = c++ 593 root 1 20 0 8156K 1596K vmwait 1 0:04 0.00% = sendmail 590 root 1 20 0 10148K 1552K vmwait 1 0:02 0.00% = sshd > At the very least you can forget anything about make -j N for N>1 I made a similar suggestion. I'll note that I've seen similar hangups with building large ports after a bunch of other ports had already built. After rebooting when I try again the build completes. So, it appears that the prior activity helped work things into reaching the hung-up state. (Fragmentation of some kind?) In general it has been easier (and faster) to build things on the RPi3 than on the RPi2B V1.1, despite both having 1 GiByte of RAM. This suggests 32-bit address space or armv7 specific issues might be involved. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sat Jan 13 15:48:43 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B459AE6F6A3 for ; Sat, 13 Jan 2018 15:48:43 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.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 9028B6A47B; Sat, 13 Jan 2018 15:48:43 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w0DFmX5o045588; Sat, 13 Jan 2018 07:48:33 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w0DFmW2b045587; Sat, 13 Jan 2018 07:48:32 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201801131548.w0DFmW2b045587@pdx.rh.CN85.dnsmgr.net> Subject: Re: 1 << 31 redux In-Reply-To: To: Eitan Adler Date: Sat, 13 Jan 2018 07:48:32 -0800 (PST) CC: Warner Losh , FreeBSD Hackers , Dimitry Andric , Ed Schouten X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Sat, 13 Jan 2018 17:05:07 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 15:48:43 -0000 > On 11 January 2018 at 07:47, Warner Losh wrote: > > > > > > If we can't get people to fix the warnings we have in the tree now > > (especially the kernel), why enable new warnings that will just be ignored? > > > > We've been doing a reasonable job with warnings until now. Either way, at > higher warnings levels we should add what we can. Is not this 1U<<31 -> signed value really just sweeping the bigger issue that we are using signed values in unsigned ways? -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Sat Jan 13 17:34:41 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D1FCCE74E3A for ; Sat, 13 Jan 2018 17:34:41 +0000 (UTC) (envelope-from kevans91@ksu.edu) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0070.outbound.protection.outlook.com [104.47.42.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT TLS CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 717DC6E4DC for ; Sat, 13 Jan 2018 17:34:40 +0000 (UTC) (envelope-from kevans91@ksu.edu) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ksu.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=r3ZNasU7psAak8Igl91TekyMsnlxRdE31iBI/q3ZLPM=; b=rKos6BNG8T7T5vDEhddf3QaUuezni8wwXZIyFuQAR4qWCSnFlGLrfT1vyHNsZJ8YCLDkbjLc1fwMmBYIJi7/0bBDYBHcpIIsZ2DoEJsnLJ2p42dpIJbUydSYMpTmLCsIJAAcauKPdvh13TiXZ98gEG+hrI9I5jYVP1zFMkEHIxk= Received: from DM5PR05CA0004.namprd05.prod.outlook.com (10.173.226.14) by CY4PR05MB2983.namprd05.prod.outlook.com (10.169.184.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.428.9; Sat, 13 Jan 2018 17:34:39 +0000 Received: from CY1NAM02FT018.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e45::200) by DM5PR05CA0004.outlook.office365.com (2603:10b6:3:d4::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.428.9 via Frontend Transport; Sat, 13 Jan 2018 17:34:38 +0000 Authentication-Results: spf=pass (sender IP is 129.130.18.151) smtp.mailfrom=ksu.edu; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=bestguesspass action=none header.from=ksu.edu; Received-SPF: Pass (protection.outlook.com: domain of ksu.edu designates 129.130.18.151 as permitted sender) receiver=protection.outlook.com; client-ip=129.130.18.151; helo=ome-vm-smtp1.campus.ksu.edu; Received: from ome-vm-smtp1.campus.ksu.edu (129.130.18.151) by CY1NAM02FT018.mail.protection.outlook.com (10.152.75.183) with Microsoft SMTP Server id 15.20.345.12 via Frontend Transport; Sat, 13 Jan 2018 17:34:38 +0000 Received: from calypso.engg.ksu.edu (calypso.engg.ksu.edu [129.130.43.181]) by ome-vm-smtp1.campus.ksu.edu (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id w0DHYbbc017092 for ; Sat, 13 Jan 2018 11:34:38 -0600 Received: by calypso.engg.ksu.edu (Postfix, from userid 110) id C5B6C248316; Sat, 13 Jan 2018 11:34:37 -0600 (CST) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) by calypso.engg.ksu.edu (Postfix) with ESMTPA id A514D248004 for ; Sat, 13 Jan 2018 11:34:35 -0600 (CST) Received: by mail-io0-f172.google.com with SMTP id d11so9112391iog.5 for ; Sat, 13 Jan 2018 09:34:35 -0800 (PST) X-Gm-Message-State: AKGB3mJg1NxsbrBs5TYh/742SfsAuZ15KdoyYq+sdxfVe3LqkPCyB+CX cR06WSM5sxvlSXKU9cbGk8du7Cb2DDy77am7hOo= X-Google-Smtp-Source: ACJfBovcqq7YcZRhcAiHuNJAQwfkbykgbgr7xriTAVF4L1eoIxwevV4KPns4b0WO8JS5GVI1fsAy8NBaTKaQ9CvfHjM= X-Received: by 10.107.21.65 with SMTP id 62mr28641680iov.148.1515864875086; Sat, 13 Jan 2018 09:34:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.149.147 with HTTP; Sat, 13 Jan 2018 09:34:14 -0800 (PST) In-Reply-To: References: From: Kyle Evans Date: Sat, 13 Jan 2018 11:34:14 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: 1 << 31 redux To: Eitan Adler CC: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:129.130.18.151; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(346002)(39380400002)(376002)(396003)(39860400002)(2980300002)(438002)(189003)(199004)(53754006)(24454002)(75432002)(47776003)(61266001)(86362001)(59536001)(356003)(4326008)(106002)(6862004)(50466002)(88552002)(61726006)(55446002)(6246003)(229853002)(246002)(5820100001)(305945005)(2950100002)(2906002)(98316002)(106466001)(478600001)(9896002)(8676002)(5660300001)(23676004)(498394004)(8936002)(966005)(16586007)(95326003)(42186006)(90966002)(93516011)(9686003)(59450400001)(76176011)(316002)(33896004)(53546011)(786003)(6306002)(55456009); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB2983; H:ome-vm-smtp1.campus.ksu.edu; FPR:; SPF:Pass; PTR:ip-18-151.net.ksu.edu; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CY1NAM02FT018; 1:+VEBK9rOfUbB1SeKvYyX+O9Vs/0DaXxmZuSL4mGkTK4fJey1nf9o3w9LDhinQwtWwjIoG69TvpJ6f8InmSwnIkXlWYT2eFT5fxQ05egp7xWFJHduAYLwc01WodmHyHD9 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f588e8e9-034a-4721-bcb4-08d55aabebd9 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(4608076)(2017052603307)(7153060); SRVR:CY4PR05MB2983; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB2983; 3:v/7rofahXSudwHN6wqNFfB8/UVyVN4+0Exhl7cbu5OWvexQjWiwMTZCYodl72mcVIt9RZiEW2Zewtnl66958n5cUC+4gNyoNshzbZrCwiT/I7gVlW3mvQW1q1vcPBZKhJI7X8f1KS6bF7sz0tslArlPTvwPgH8/7dog8GA8PvfJNynVOlYrY5gbwrVTtQskDHP7pYtA1VAw6OF8MAO/LhmsL4UUZpIDXjpTTD/OtIsAndCp06xQQQtBbWFnbL92hXKvVi+Rth0rBiyMu4FoPePnJK0e5wLreDUlyHFLVjGtLod22L/qMtS+NrWdKrEle9k/aaBt8+NS2nTffr9rakKoLI2UJ6V+v32dfLN+DKXw=; 25:BGed8hmh9pdfGoeyOqxLwqRjbBvSZfY1gc0LvyfUA3PtLdUDymuf16w1I3BefNp7GZ8qOacqi8/oCC1UziE+QlSp1u8ZRvBrqYDKOLu5zSNStk6YuFK8Bpif2NB8lvhtYOQb9rZcfySxUqmg2FCUuiACMmWPCzcKLLtl7Jz26TemLm5lIw3vD4OHJtiFKJ8CDGtNapQy377iXgNUw4o4Kz8+Di2SJpLq+e+wYloqzzGQ2he2E5ngX22Pwk/V6H0H9PFzCTNJVei7zYU5u3aW8BS7BkUPevk3COgqLPtYKKuvOnFzU634rNOejv5CgCqWnyFh0Sl2bZva1tBWxJeZfw== X-MS-TrafficTypeDiagnostic: CY4PR05MB2983: X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB2983; 31:Cmwk2kaOaOb3xh5u+PGsblaUIp+xC0hvNMjV9MlwcLBkiPZywbDFBFH2O2jSOqu++ZMgv8tV8qMLIpUdWc1MOLejEHG10kQJ6bZwDYt8EFBcdqtWeruaahc4lNdDoHpvU8Yk5tSvK+qPEQ14Bk8u0MGMdWU3tF8Mg9bk9eEKKbmBtegVH0GB1o5fqeRpzUPgchfEnytZSb2KlM4rok91bgCxtynr74QCVWGH+CBAmsY=; 20:hNw2+xFtGWC0zNQSQssKZxnZ0/aTdGBOqMgehYqz8rOyD++BAXAvuDR5cEZd+cbRB2khv0qQcmQUbz8T4ILmQR9FFkdsStf1dpN0yttxhmCYncoDSvHxZkWTIdJMaiy2dLxzEXnT2DLAPZ8kNSzQ+L3qQSYjXJik4qvYxwGBAsIqPVYHda3e7eY/8e+2A0qBrtMeXqctwv7wUjRKhFmOL6kFbu4rOv9czz5g4hicw5gKV8t6h0sLDjMo7aZgk4GrFHqgmiXgN/YaIPZFNWFFA0yjklpco5WaOMeaoyWQWKqZ5ZhDPKGfPdjl6T4iH9PPSdxGjaMRKypbhhUiJqFIIrutlDWmXyFg2ELoMBCM4B5tVvsH+I20M9lPDsv9NA9UXOYemnU/zj10nbO8J9sMJcFAmgpav+6lX8P9be3C4LzOt3aSibF5c+0Xo9qEvDHdPNOQ0JHNMlvU1jx6sFttlWeBBPgqg1iIyZqolB9eoWGQDefPDTzSlMpceAtQ43qi X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231023)(944501075)(93006095)(93004095)(6041268)(20161123562045)(20161123564045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR05MB2983; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR05MB2983; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB2983; 4:T123D7rzU5fU5vGfN6HEci2hdxiijHFjJqcaPRq09PpNCs1n3+Kaf+HnHlqy+gaPP1vVhtlLvGGUKOiFI1oH+zLYW9bWbyTgL8QfHV139zxo3P9ENsKps/mZ0aV8iJ7b5LIjeQTSJXe5/9yaiJvIhhjkueWUZx9w0P+kVnfK+JqO750rI3FoBpnCUx7myuEMIEnWemp0XH8rSDkJYdVpwup7ki9cO/K7DEU1CH/0T8j5HPOjAoGhHauGDhBHRlOfRtVYrWRgt8YT/dJxyDZ4gg== X-Forefront-PRVS: 05514B7026 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTRQUjA1TUIyOTgzOzIzOnNFbjk0VTR6dHpINlQ3MlY3YjU4TllPSXpR?= =?utf-8?B?b2wxSFJjNHpoK0pyTHBCQnRYUmliY1dpckhHTU1nN3FSSEgvQjRybjR6WVN1?= =?utf-8?B?azc4L0kyTHFPL3NpL21DWmJDZnJXM1NTZEtRTm9Fb21xM0NqOTZSaE9VUlo4?= =?utf-8?B?a1Nlb0o0M0pmYms5d2MzSzZiYXFOMGdBQ1gwUmxhTUlQSzJ5bXE5R080Vmo1?= =?utf-8?B?K1dZSS9XajZ1SmFJL3JFQ3l3SkVVVHVseWJwS3pySWpnc1Y4dHd6MWN6di9Z?= =?utf-8?B?L1J2VFFLdTkwTkc3ZzBUeXlyVjVVVmJJOXRoSlBHVUx1ZEY1YzlZS1RZakZR?= =?utf-8?B?R3o4ZURlZ2YrUFdZa2NJTzVpcXRsb1JXbVNVWEhrYkxoTWpZaFdEczc5aGFV?= =?utf-8?B?Q0xqeEU1MkNBN1I1ZlpWOVlxdk1YZDRKL280bzBJVGVwQlFlaHE1ZURDMkds?= =?utf-8?B?R2VWMU0wWXlsSU5lUldZbi9ZWUFxemFES0l6QVd0b3FkK0IwMXJ2QXhJT3pJ?= =?utf-8?B?eEZtdHZESXdoWUM5QmIzelQ4dlA3WElsb3Jqak5PSkdtcWV5eVFSeFROMUxj?= =?utf-8?B?ZWUwUi9VbGlxM2RlalNHcHdlUEZIcmRPUVFkdjY3K0t3NG94OEt6akw4WkFL?= =?utf-8?B?UUdrSlJCNWNoU292M0thdzJwZ1NCQ0c2eUM2N2lJSWVzY0lCTU51YXI0dWFQ?= =?utf-8?B?VTJtTjIwM2s3Skw2cTFVa3B0aTFIZUxCc1k4K2pKR2I2VUYrWDVlRlowRlFZ?= =?utf-8?B?RHNLMzZkdmVLVkZzSWozbjhFSFlnalB1Y28yUkNWWWtodVUwT3BoWXQwbUEw?= =?utf-8?B?K0lJbnoyanVNVnlINzVGTXlramRJVVFtSGJld1JzUzdnNkRwKzJWODN4NkpV?= =?utf-8?B?QnI5YlRabGh6aGZnR2hJdmpBdVJTbG9iSnVlSG9aQlcyUTRpOEZzVDFJbFAv?= =?utf-8?B?LzdURVE3VmEzaHI3WXRkNGNTZ1R2YkdNNnh1NTJqOERiSFNFVlNJR1lzTC9I?= =?utf-8?B?d1phYmZPdThFbEtpbTZJVklMRTlHeFo0enZzMFY5YXNjQm1RNmtYTHg4bU5Z?= =?utf-8?B?Y0tMSjg0RDloNVhXY002U085cmlBdXBIa0JsZkJSTWR2TitDUE5YYWhVdjk2?= =?utf-8?B?UUZhU01INGpQUUxvR01abG9nb2ZDTFNOcFR2VVNQN1dtbVNPWTRaOGxKZkRh?= =?utf-8?B?MFVNTGc0bWNrQ1pMS0IyOHZhb2s1RjlYa28rOGd5bHVLU3BGZXBNSWR5Y2lF?= =?utf-8?B?SzhIRTFvbmlBNHRaVnY2V1NJazQvaUdhOFNsVFYxdTN4UllqMVE4cjZWT2NW?= =?utf-8?B?bVJoeWxkQ0RFSHFGeEtINDkzc2tESG9RVmFHRXFmSXF6aHFJTGNSTmMvelZu?= =?utf-8?B?S3hXY3RocTVrYW44TTNENEFMVkNyRjl0c3NzdjE1QTZibFhZSDhSYTU5K20y?= =?utf-8?B?bFhSeHhvT0hLTEEwL2hMdnY5Y1EwNGFYbWd0UzkzcS9JWXlPam5HR08zL1pK?= =?utf-8?B?bndZMWRxZ3gyTFNScHpWVzZDRGNFaWtvMUR1cFRhbnZhWHBnVGw0QnRUZDlD?= =?utf-8?B?VDRRQk9MSzF5TTNZY0cwbXhaY3I3dmZKTUsvY2lLdURiRFpFcmZhdEZiOXlG?= =?utf-8?B?dkFuNFp0VlZDSlBDeHl6eWw3TG5rM1I3TmlBVlFScTE0TDA5UmZzK3JtcGFn?= =?utf-8?Q?5R/uKHLADT2ab7z16+0W+n+3sCgC7VhOtKKqEsZ?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB2983; 6:9dCLoUo/9V92qFYTyO5IMsNRYOpxR8D/s4Z2kNCPeaLPzAgjwxUIw7EabQn0N4+SlTgG3NFnYMJ/+WDzkFFi+w4azAx1jay1mzzVrqYv0dBMZ3JzTNkeahWRKrNC+ny6kE7eVvQ7XJRe+EEHNwKvH8mH4R8mkUl6Ul1APmCoIazlBcXUUYhV6szR2VChA8HV1MP8Hl686au9LiL0TWGCOTTUv1OGhqEKxto8PW9hALrMCFXRahKfbv4lFS61hFSU0THz2Pi8jvmP9NSFEsH/EF52WmPuT5Is236LC81SgNeiLmSUjkXVJC2NrhBUynz0Pl01xtRZpmXaBnT+SlKmDUedJexOGh1B2NvI4DK7R8o=; 5:cyM6ygbCJUIAjpqeuhAeBZPMdhk/NL6noOkTfuetYh3gxdcye4jfNFvmRPA/XxHTTNobFvKkh7wawUaZCZG8LkOKb8XAv2Kx8CEYKQrqd/va7PR3D3oVGP5zyHw5HdJek8g7bkPL+XO4olLNtigZDPW1AOcfxGITwTQRejz3hOY=; 24:l2XDa3T6CtZPNlaEDf/68/jr97llQy+HZSHSak/3p3AxuSA/xEDwFgRfbbCco05AhzIEqSKFloygu3iqNcjNid56cKtAJPrnpDHhzyEQNzY=; 7:M3aUrTascgDI054+6NUhlNdLDuLkKeKfkNl8EjSWZ/g+vH9wrwZNlx9qBSClIuC8sGta/Mz6JLbyCBdkrWkIrDgaXgmzgfuypH/XGvsotzteUQXi5RJhRSkzGDwAk+MK19pGWWMcWS9npwDDLb+uJhrBTn7Hq5iD5RE5FeJPP8+DHbqZV+tv8yZb9jID8jIk5dTKVOZTEQZLKOL+nLt9sg7BtifExjrmTNZmWsIhCL8aO78jb4qz7WPrVfT7huXU SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB2983; 20:gjd8545rCPPosQ9Cd9k3tjgSmeu8DYNGbekvyOakuabD2dzKO69MJLaQ0k4RffluhBJ+W9ABO3JiaN+Ymj4nlTjCqrQXmSNEL1cb9M+mnIJ14Dc9H+ZH/7yu39DPoQCvK1PB76GauHSE4BAAecEnOTiqoTTUoVc4VBZQRfT3cIE= X-OriginatorOrg: ksu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2018 17:34:38.3428 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f588e8e9-034a-4721-bcb4-08d55aabebd9 X-MS-Exchange-CrossTenant-Id: d9a2fa71-d67d-4cb6-b541-06ccaa8013fb X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d9a2fa71-d67d-4cb6-b541-06ccaa8013fb; Ip=[129.130.18.151]; Helo=[ome-vm-smtp1.campus.ksu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB2983 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 17:34:41 -0000 On Thu, Jan 11, 2018 at 6:03 AM, Eitan Adler wrote: > Hi all, > > A few years ago I fixed most of the cases where we used 1 << 31 in FreeBSD. > This expression is illegal in C. Since then the issue has arisen again. > > https://reviews.freebsd.org/D13858 fixed most of the non-contrib cases. > > I'd also like to see if we could find some more general solution, be it a > compiler warning, bit set macro, or otherwise. > For what it's worth, I've really come to like and appreciate NetBSD's approach with __BIT/__BITS. See [1] for implementation, [2] for usage. [1] http://src.illumos.org/source/xref/netbsd-src/sys/sys/cdefs.h#577 [2] http://src.illumos.org/source/xref/netbsd-src/sys/arch/arm/sunxi/sunxi_usbphy.c#L44 From owner-freebsd-hackers@freebsd.org Sat Jan 13 17:51:44 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD90FE75DA0 for ; Sat, 13 Jan 2018 17:51:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-118.reflexion.net [208.70.210.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7D5D76F34A for ; Sat, 13 Jan 2018 17:51:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10496 invoked from network); 13 Jan 2018 17:51:42 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 13 Jan 2018 17:51:42 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.4) with SMTP; Sat, 13 Jan 2018 12:51:42 -0500 (EST) Received: (qmail 7965 invoked from network); 13 Jan 2018 17:51:42 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Jan 2018 17:51:42 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id CD77BEC942D; Sat, 13 Jan 2018 09:51:41 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Builworld stalls on rpi2 [various processes stuck in pfault and vmwait with 1996M Free Swap listed by top] From: Mark Millard In-Reply-To: <20180113172731.GB51530@www.zefox.net> Date: Sat, 13 Jan 2018 09:51:41 -0800 Cc: Freebsd-arm , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180113005426.GA48702@www.zefox.net> <5D61DF2C-2CEB-442C-8CBC-1EE0988CF2BC@dsl-only.net> <20180113172731.GB51530@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 17:51:44 -0000 On 2018-Jan-13, at 9:27 AM, bob prohaska wrote: > On Sat, Jan 13, 2018 at 08:32:20AM -0800, Mark Millard wrote: >> Does your 2 GiByte swap-space RPi2 "dmesg -a" output >> (or serial console history) show any messages about the >> swap-space size and a potential adjustment to a related >> kernel parameter? >>=20 > Yes, console history contains the line >=20 > warning: total configured swap (524288 pages) exceeds maximum = recommended amount (405460 pages). >=20 > Since top reported what looked like ample swap, and buildworld seemed = to > run successfully, I didn't heed the >=20 > warning: increase kern.maxswzone or reduce amount of swap. >=20 > message.=20 >=20 > Would it be helpful to do so now? gpart show da0 reports >=20 > =3D> 0 122544516 da0 BSD (58G) > 0 4194304 1 freebsd-ufs (2.0G) > 4194304 4194304 2 freebsd-swap (2.0G) > 8388608 6291456 4 freebsd-ufs (3.0G) > 14680064 107864452 5 freebsd-ufs (51G) >=20 > The units are somewhat baffling, since the apparent swap partition > size does not match (numerically) the dmesg value. [gpart is showing in 512 Byte units, probably matching a drive-organization characteristic.] page =3D 4 KiBytes So 405460 pages =3D 1621840 KiBytes, so a little over 1.54 GiBytes. For reference: 524288 pages =3D 2097152 KiBytes, so exactly 2.0 GiBytes. Note: 2*2097152 =3D=3D 4194304 exactly, so the 512 Byte count is an exact match to the 2.0 GiByte swap size. When there is only 1 GiByte of RAM, I'm not sure if increasing kern.maxswzone is a good tradeoff or not. Historically I've kept the swap space within the recommended maximum for the default kern.maxswzone value. But for the RPi2B V1.1 context, I've not tried a self-hosted buildworld in a long time, doing cross builds instead. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sat Jan 13 22:09:05 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 818BFEB215A for ; Sat, 13 Jan 2018 22:09:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-152.reflexion.net [208.70.210.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F9807A6A6 for ; Sat, 13 Jan 2018 22:09:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23587 invoked from network); 13 Jan 2018 22:02:18 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 13 Jan 2018 22:02:18 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.4) with SMTP; Sat, 13 Jan 2018 17:02:18 -0500 (EST) Received: (qmail 29175 invoked from network); 13 Jan 2018 22:02:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Jan 2018 22:02:18 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 5BB56EC9004; Sat, 13 Jan 2018 14:02:17 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Builworld stalls on rpi2 [various processes stuck in pfault and vmwait with 1996M Free Swap listed by top] From: Mark Millard In-Reply-To: Date: Sat, 13 Jan 2018 14:02:16 -0800 Cc: FreeBSD Hackers , Freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <3CEAAA69-1C79-4545-8ED6-D277A65BBAB1@dsl-only.net> References: <20180113005426.GA48702@www.zefox.net> <5D61DF2C-2CEB-442C-8CBC-1EE0988CF2BC@dsl-only.net> <20180113172731.GB51530@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 22:09:05 -0000 On 2018-Jan-13, at 9:51 AM, Mark Millard wrote: > On 2018-Jan-13, at 9:27 AM, bob prohaska = wrote: >=20 >> On Sat, Jan 13, 2018 at 08:32:20AM -0800, Mark Millard wrote: >>> Does your 2 GiByte swap-space RPi2 "dmesg -a" output >>> (or serial console history) show any messages about the >>> swap-space size and a potential adjustment to a related >>> kernel parameter? >>>=20 >> Yes, console history contains the line >>=20 >> warning: total configured swap (524288 pages) exceeds maximum = recommended amount (405460 pages). >>=20 >> Since top reported what looked like ample swap, and buildworld seemed = to >> run successfully, I didn't heed the >>=20 >> warning: increase kern.maxswzone or reduce amount of swap. >>=20 >> message.=20 >>=20 >> Would it be helpful to do so now? gpart show da0 reports >>=20 >> =3D> 0 122544516 da0 BSD (58G) >> 0 4194304 1 freebsd-ufs (2.0G) >> 4194304 4194304 2 freebsd-swap (2.0G) >> 8388608 6291456 4 freebsd-ufs (3.0G) >> 14680064 107864452 5 freebsd-ufs (51G) >>=20 >> The units are somewhat baffling, since the apparent swap partition >> size does not match (numerically) the dmesg value. >=20 > [gpart is showing in 512 Byte units, probably matching > a drive-organization characteristic.] >=20 > page =3D 4 KiBytes > So 405460 pages =3D 1621840 KiBytes, so a little over 1.54 GiBytes. >=20 > For reference: > 524288 pages =3D 2097152 KiBytes, so exactly 2.0 GiBytes. >=20 > Note: 2*2097152 =3D=3D 4194304 exactly, so the 512 Byte count > is an exact match to the 2.0 GiByte swap size. >=20 > When there is only 1 GiByte of RAM, I'm not sure if increasing > kern.maxswzone is a good tradeoff or not. >=20 > Historically I've kept the swap space within the recommended > maximum for the default kern.maxswzone value. But for the RPi2B > V1.1 context, I've not tried a self-hosted buildworld in a > long time, doing cross builds instead. On a RPi2B V1.1 I get: db> print *maxswzone 0 The code in swap_pager_swap_init has : /* * Initialize our zone, guessing on the number we need based * on the number of pages in the system. */ n =3D vm_cnt.v_page_count / 2; if (maxswzone && n > maxswzone / sizeof(struct swblk)) n =3D maxswzone / sizeof(struct swblk); which means that maxswzone is ignored because it is zero and vm_cnt.v_page_count / 2 is used directly. Setting maxswzone can not make n any larger, only smaller. it would appear that "increase kern.maxswzone" only applies when one already has set the figure manually in a manor that restricts n. Quoting "man 8 loader" : kern.maxswzone Limits the amount of KVM to be used to hold swap = metadata, which directly governs the maximum amount of swap the system can support, at the rate of approximately 200 = MB of swap space per 1 MB of metadata. This value is = specified in bytes of KVA space. If no value is provided, the = system allocates enough memory to handle an amount of swap = that corresponds to eight times the amount of physical = memory present in the system. Note that swap metadata can be fragmented, which = means that the system can run out of space before it reaches the theoretical limit. Therefore, care should be taken = to not configure more swap than approximately half of the theoretical maximum. Running out of space for swap metadata can leave the = system in an unrecoverable state. Therefore, you should = only change this parameter if you need to greatly extend = the KVM reservation for other resources such as the buffer = cache or kern.ipc.nmbclusters. Modifies kernel option VM_SWZONE_SIZE_MAX. Multiple points relative to the above: Note that "care should be taken to not configure more swap than = approximately half of the theoretical maximum" because "swap metadata can be = fragmented" and "the system can run out of space before it reaches the theoretical = limit". Looking at the swapon_check_swzone code the message is reporting the "half" figure, not the theoretical maximum. But there is also: you should only change this parameter if you need to greatly extend = the KVM reservation for other resources such as the buffer = cache or kern.ipc.nmbclusters. Modifies kernel option VM_SWZONE_SIZE_MAX. If I read all this right, it says that reducing swap is normally the intended handling when the message is reported unless one has been adjusting various kernel resource reservations. That would be consistent with the maxswzone only being able to decrease n in the code that I quoted earlier. Given that 1 GiByte of RAM and 2 GiByte of Swap reports that the maximum recommended swap is about 1.54 GiBytes (converting from pages), the: If no value is provided, the system allocates enough memory to handle an amount of swap = that corresponds to eight times the amount of physical = memory present in the system. just seems to not apply directly to an RPi2B V1.1: 1.54 is much less = than 8*1. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sat Jan 13 23:24:48 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05DD6E5C00E for ; Sat, 13 Jan 2018 23:24:48 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8ED357D8B6 for ; Sat, 13 Jan 2018 23:24:47 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: by mail-wm0-x229.google.com with SMTP id f140so18078190wmd.2 for ; Sat, 13 Jan 2018 15:24:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to :content-transfer-encoding; bh=kXopWmSsbkf+pKHapcqLFvftpNmSDISAtRtNCpzw5sM=; b=j5qbSSDi9929R9V4Mmj0zTcaWS/t1wfzNL3qP29ktVSU0j+CN0oKfbK9CUCi4a6++9 coN0y0COjTzgHoI8gi0yWRQOVKw2kvj1zik0XgAuEAoJw4D08om7s3Vqn615R/kxZlJ/ RB5xgK6Y14fOWjUrhqaLp8KM6EySdLWxvfFUtZMUGObhZ3CFdyHI609KdxZTTTP52cm7 uJ8wvddfG7vdXoT6SKCEBsq4vrjm30RTM/mx4KqB7K7C8FT1WkhyfPLrudd7XruoZ4pH iYWhtHpFGskl0PBbWLtv+tdQv34EI1X74YFX3tt9qOXuikNHFSiaPs4bgBtRIDyN6TIt fcdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:content-transfer-encoding; bh=kXopWmSsbkf+pKHapcqLFvftpNmSDISAtRtNCpzw5sM=; b=HfJ0BPkKbo7CNY3m9xv8PU22q+iof3LQCXGmlDPxm2ZChq9h8LJIWCMAr7e9rdB1AC 4gxAwVZIG9y8ARFZFDXm1KOBQLL8X30kOfyXdpc01a8CxS9ToJdOez5QIGPVaz09oTrn 80DrZbyLtu/yxB4Gps1YufPc2V9KkdtWCY9TvaZ5u1YYemJzHoja+7xcpLoIFYEXEejI tQna89w1OHeXfHyz4ucR/NUETuMtUwFtRrEZsF9P7r+vMzyjLUOqLAIOyHM/TEgLDsUB Sn4B4j+3Uy+6+sh6gidBMmnw8MwsXJbo+RM289zFsRYmfT/mM92dSousmkrpK4VVVfls UP9Q== X-Gm-Message-State: AKwxytccsJUT0gH+/gFjXGxLmT4gVsjOsO/vrB0TOiuLAEKTyTZG0/go fYXg825Y6ToxkjxnZPFlcuU8rp5wEjaADV6RYCI25g== X-Google-Smtp-Source: ACJfBoux+mZzxoDPEILkd3X9FAlp88pFq37PCj3diBidiV0GjS19Aghe25KtFzQdvKi1QUP6EGPUxidxSWFPLxkzTTY= X-Received: by 10.80.141.23 with SMTP id s23mr2474176eds.234.1515885885457; Sat, 13 Jan 2018 15:24:45 -0800 (PST) MIME-Version: 1.0 Sender: jdavidlists@gmail.com Received: by 10.80.174.213 with HTTP; Sat, 13 Jan 2018 15:24:45 -0800 (PST) From: J David Date: Sat, 13 Jan 2018 18:24:45 -0500 X-Google-Sender-Auth: KRlp1EmSvvd18i-bUQS0HNGAvEM Message-ID: Subject: FreeBSD 11.1 + Clang 4.0 + PHP source = Core dumps To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 23:24:48 -0000 Starting with Clang 4.0 on FreeBSD 11.1 we are seeing really odd behavior and crashes on a version of PHP that we compile in house. It=E2=80=99s not clear if this is a compiler bug, or what exactly is happening. For example, this code (from PHP=E2=80=99s intl extension) core dumps: U_CFUNC TimeZone *timezone_process_timezone_argument(zval *zv_timezone, intl_error *outside_er= ror, const char *func) { zval local_zv_tz; char *message =3D NULL; TimeZone *timeZone; if (zv_timezone =3D=3D NULL || Z_TYPE_P(zv_timezone) =3D=3D IS_NULL) { timelib_tzinfo *tzinfo =3D get_timezone_info(); ZVAL_STRING(&local_zv_tz, tzinfo->name); zv_timezone =3D &local_zv_tz; } else { ZVAL_NULL(&local_zv_tz); } if (Z_TYPE_P(zv_timezone) =3D=3D IS_OBJECT && instanceof_function(Z_OBJCE_P(zv_timezone), TimeZone_ce_ptr)) { If zv_timezone is passed in as a NULL pointer, this code core dumps on the =E2=80=9Cif (Z_TYPE_P(zv_timezone)=E2=80=9D and gdb says that zv_timezo= ne is NULL. But if you look immediately above, if zv_timezone is NULL it is set to another value. If you add a printf of the zv_timezone pointer above the second if block, it will show that zv_timezone is no longer NULL (because it was just set to &local_zv_tz), and the program will no longer crash. This crash can also be =E2=80=9Cfixed=E2=80=9D by placing the following lin= e (a memory barrier) above the second if statement: __asm__ volatile(=E2=80=9C" : : : "memory"); Although that addresses this one, it seems like there may be a number of other similar issues throughout the PHP code base. This just can=E2=80=99t be right; that should not be necessary. What=E2=80= =99s going on? Is this a bug in clang? Is PHP doing something dodgy? User error on our part? We don=E2=80=99t see this behavior compiling the same source wit= h clang 3.x / FreeBSD 10.x. Thanks for any insight!