From owner-svn-src-all@freebsd.org Thu Nov 19 19:48:20 2015 Return-Path: Delivered-To: svn-src-all@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 46091A337E6; Thu, 19 Nov 2015 19:48:20 +0000 (UTC) (envelope-from jtl@freebsd.org) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0111.outbound.protection.outlook.com [157.56.110.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7DF6B1E1A; Thu, 19 Nov 2015 19:48:18 +0000 (UTC) (envelope-from jtl@freebsd.org) Received: from SN1PR05CA0022.namprd05.prod.outlook.com (10.163.68.160) by BLUPR05MB054.namprd05.prod.outlook.com (10.255.210.149) with Microsoft SMTP Server (TLS) id 15.1.325.17; Thu, 19 Nov 2015 19:48:11 +0000 Received: from BN1AFFO11OLC003.protection.gbl (2a01:111:f400:7c10::176) by SN1PR05CA0022.outlook.office365.com (2a01:111:e400:5197::32) with Microsoft SMTP Server (TLS) id 15.1.331.20 via Frontend Transport; Thu, 19 Nov 2015 19:48:10 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=freebsd.org; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=freebsd.org; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning freebsd.org discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BN1AFFO11OLC003.mail.protection.outlook.com (10.58.53.74) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Thu, 19 Nov 2015 19:48:09 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 19 Nov 2015 11:48:03 -0800 Received: from [172.29.34.67] ([172.29.34.67]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tAJJlxD66219; Thu, 19 Nov 2015 11:47:59 -0800 (PST) (envelope-from jtl@freebsd.org) User-Agent: Microsoft-MacOutlook/14.5.8.151023 Date: Thu, 19 Nov 2015 14:47:57 -0500 Subject: Re: svn commit: r291074 - in head: share/man/man9 sys/kern sys/vm From: "Jonathan T. Looney" Sender: Jonathan Looney To: John Baldwin CC: "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Message-ID: Thread-Topic: svn commit: r291074 - in head: share/man/man9 sys/kern sys/vm References: <201511191404.tAJE4reJ064779@repo.freebsd.org> <8452745.P4SYfkWpxv@ralph.baldwin.cx> In-Reply-To: <8452745.P4SYfkWpxv@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11OLC003; 1:ZTQ2Dcp7+vgMaWGDZWFwjCn+ZfOao+nwKWO2+TDcaZ7pBzNspqw20hl4aRZQ7ev3qKjbRHMjbp7JUw+nX0un5HZXRQG7rsXsgLPvUFKLO8Y2mpgA/GTLYLmiXQfnEpiwL7fuux45Jrj0dm0QJdafiVCWXnaYKZANNKTz3PCGnmv9/t/SKcxs5UGGyMyFgO1fmK7m83aECHbMZFt7ayBG766/Dp2opljQ/bo+noR14ICxXcn9uE+OUKKaxBP/Svz0bpgcl0FYztxbCCpJX3dAc+fvhOkX8QGohkFrkybGJ9Hx6erVWyXSIsE9N2JXwG1agwcso7RJ7o9D+gGEovnmo7gPDWDa8Rn2kaC1nCs1tBs= X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(189002)(24454002)(479174004)(199003)(377454003)(586003)(97736004)(36756003)(230700001)(16796002)(86362001)(69596002)(77096005)(450100001)(6806005)(19580405001)(5007970100001)(83506001)(92566002)(2950100001)(23726002)(19580395003)(87936001)(105596002)(5001920100001)(5001960100002)(54356999)(46406003)(81156007)(4001350100001)(106466001)(50466002)(50986999)(47776003)(76176999)(110136002)(189998001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB054; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB054; 2:bw4kq91XMVIPThHsiqraLhQLl3igDwc6bVFrhqmKjw7N65EyFMrYuplWuDZK4eUZFt16z7r8VmJe3lPcAv0L2pfHetLI7uTYGssb04mMr3kW3rYkhC2Z1F8TAi29q3D9f0lMbjJJSCmodrkVzXN0en4upm9uojEfVnxoJq9dneo=; 3:e9m1jLpkBpbVrLuYMxaOaiy6AxTnAr3ENjG075UnQPFkPf5V7Hwn0USJ/iT305fzJkrqAAe3OhaZA6mCEbDuA+6GM3FnYOSHuQ8ZBpi1Ir7OgQ3i4SfCl3jRmb386F6XRHQjSfxg4C1k9V2XagzQId2nXeZFVXF/oK5hdriHkKxjzpdfrPMGqM9lnQ36LHXwiJH65JuahcnugY/4bmXsGUCaTuGyiHdRZ1gTFWpXyIA=; 25:ctXmn1hcpnRh9ydWdYIbrkTh4a76ALJI2s7mQj4DQNzMS8uyodtS3/cSGwGAJsicjDRVtiEX8wVGVjAS55u/2r9Zq9BQC2x/67mXZY0Opc7ytSshoJtNqJURLJjghuGMeMZ0AO96AQkEspsKYgpUR7HSvtLgPg1bk3F+CIYFjttQAE6Wlvri+Vpdg5mJIEqeCWgL++Jxe89CBxE4I0R8/ie8HLUeMX8h8obfa04Zb12TWZakplXR/frl0HjTl+q6NROudnAtfFwCNVaALQA1uQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB054; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB054; 20:nCMA8S+NF5b+dn++k+CwpLzzkgrAT+nprpVz6NQ9JV87AEos84/kT2tIdjGym0r/BanisBAPWLKyy0oICIkEs9aVwB2t680KnTuR+FP3dcq/Ih2lp9d7qVHAyiaxdgx+AsRN8zZf8PezMyVJesY5YgjEc94RI/D7B+Zx6jbw2WvY3m4dFJT2VMd/XwyHGkJ06Zs86/uogaD89C+oJWAUJMMis5K3YQMgLqVBxhPP3TyYf5avD/7TYeZq33HpBrCZoaCs3kLx5IDQxn0GwLP0qw0WmdwUYO+/6h1R6ep8T6BticAbPYkReKsS+jUAdrJyY1x3I/FcxTUhvEuSe6Os3O/mBq/20qOT7g9rIdX0PwTwlCV7NsoY0GrIvqD8fm7ITOA+dx6u7UrAE25tBWfASo+AsZnKdXpGl4vmbwB9wsYKA4elNWLyYuz1FlaPBxJjMzuo8gOOyFEpXpAdN1PriFATVtjTkK0UXAjS5zW9Mu+AUgdGHQihndlKRij5kq8S; 4:LbvDvFGirey7PwHhADUmYfaDQJMdFZ5ZVmBEPvLs77yhZLTbvV5QAHCVLplfKQ1O+6Tuerj1vI46sGzs5g/9NdLYVx0oGcTguRJdbmVdT73C4SeINLbCXLJx0nphMRSgLHQhRQEr2TF7ilE2x1NqWDU3VXPBFimEK9h/V+zw7nqZUEAboayyoozuultLkpPMoK6OqGO3jvYZ9FMvtr/a6Lptb1oXTRodY1JrNDVOsUdA17n7ui7wLPP0qRJ3nZtfRzE7NxTRNDzH0v0t27qXzC9r2TadPYgSTiV79pvQ0m5cdn/3HxmLjSW97fLTANdSoLEUWs2Znnb2MEZZX6YegMZBzaRi7bSdxIlNiIalML7AIWb4psB4NtfQxD07w1k1 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001); SRVR:BLUPR05MB054; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB054; X-Forefront-PRVS: 07658B8EA3 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB054; 23:sQW9elS2WP+jo4VY1A9E51gGjZU7LnmtTiCkLBYccO?= =?us-ascii?Q?9xs9+muZQWDucXW7R3ZBxB/tQuFDB/yGGI+cuo6JtBmrq+6YADmcXE6XS9ux?= =?us-ascii?Q?x8p+wSWsiAIpoXbKq9tRi8m9d5H10vlee6asDReVur7AA2e9EQz/5tFvg9Uz?= =?us-ascii?Q?L/sZYyrcxv1c8gg5eOW1kQxMQygZFVSiXzrREKdIAClPDvQTiTLJwKOM+BSK?= =?us-ascii?Q?2LwwFyaDJlA1WvvVoS42wudTqeGoR2oXKSxAyo2/bWPTI9dU6NpZ+Xy2qCjD?= =?us-ascii?Q?8Ln+ZFv8Ds9DngrRHxOw16L0v4+DqK8qVfr11rTVrNL4pQC+WKKweCmGLNIP?= =?us-ascii?Q?2LOO0f23AKoloQpyexuY41qUuDm1EUNMoJmUWoB79jyq4HMEt2C0biGqtByx?= =?us-ascii?Q?LKeG7kl5BMfHYojblqbfczfCVyoAhGJzJSfX+1loy6dRcMdH6XQ2cAOqbz/x?= =?us-ascii?Q?itjQaG0nwPPSctcA4rQAVOKF0qh9D6UA2UZfNc+qsTySkhJ90LX4RzRt8L5s?= =?us-ascii?Q?IP354vjR0vPfR4GzPuNVIc4YU3XqxAyELR7jjiaAiMUK0HL9Wxwy6AlvUmWZ?= =?us-ascii?Q?zbdSq8JylilNRzPmAtTWNOR3F908C19AQPoG+XI2Llv92eHNGvt9FsGEUd8s?= =?us-ascii?Q?FdQKs/ZfXFo+m3wSJqb735OrmTYRndW1K5Z9WtfCtCpLswRXRxKx9cTudpPe?= =?us-ascii?Q?n+ai3sgKPizQGL7aaNSz45FWYbP1o1wm4BjpPI4W7JBXvIhgsFoBIkgokeOC?= =?us-ascii?Q?aBFF19bnLVlE0FqzLxoz8Mz7+zenR7Iyt+DkYtDicXTFB1A17wuigCSEojkJ?= =?us-ascii?Q?m6E7Cyy9SAc5lEiFs3hX3g+ccwNjjI1zKVDceRv/BoDcQmlBKMtOHZxQu8yU?= =?us-ascii?Q?fozSFDgC0buyMXoVxLseaX/nm4pBbm7AobPYj/tHqC3Qcrx3uhdWMupPP3YP?= =?us-ascii?Q?R9Ajg9DhzOVvsUv+XojKw5OXInE7RvWn/RyVgONvBEO/an5BSMsQm7UtK3dG?= =?us-ascii?Q?tQUNwxCSBHYU1JN7o0KGVbtVtT9+OygOSMFadYnDprBSI5UFJUjU3xThrqyf?= =?us-ascii?Q?ZJbTqaVio0Njx/ZbOEvkm6w6VG?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB054; 5:h6+K5TBdic/QFtqCS4mrdVpseLCAiFvo2j6abukQCbhrpJ2BTDOyOWHeQPRY3auchTESQrY8zuD2ZcDyfmKXAhIF+7nDY8ptf0Im+P3YL6NcmkcBT36UDEyV/ywHxBWMtFe4daUFoPJX5pAB0r7YOA==; 24:gqNLfxeK0uWY2xiY55x+vLbCbPfnJ5bEDZBB6vnh4+6oKrD9vIoXw9b9tDaVn6xLdGmrR73D/G383Q7NvccTaH14gvRX7qh9JmhTmjy5cGU=; 20:oZypAzeQp0utHA1sErx+F8PBanLSnl9fWtcbDlKJ0sJf6u5NTnwjIwo3n6fbCmyYBlmJw5tDRGVefOJX9/Un7Q== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Nov 2015 19:48:09.6440 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.17]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB054 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 19:48:20 -0000 On 11/19/15, 12:58 PM, "John Baldwin" wrote: >On Thursday, November 19, 2015 02:04:53 PM Jonathan T. Looney wrote: >> This change clarifies the language of the malloc(9) man page to >>clarify >> the restriction against calling the malloc() family of functions >> while in a critical section or holding a spin lock. It also adds >> KASSERTs at appropriate points to make the enforcement of this >> restriction more consistent. > >All of these KASSERTs are redundant. WITNESS will already warn for all of >these in mtx_lock() itself. If your argument is that you want a panic >when >WITNESS is not present, then the better place to add assertions is in the >locking primitives themselves (e.g. mtx_lock/rw_*lock). The problem is that we don't always acquire a lock when calling malloc or free. In fact, on a lightly-loaded system and tested at low scale, it is possible for a raft of malloc and free calls to be handled in the cache without acquiring a lock. Therefore, even with WITNESS enabled, you won't see any indication that you've just written bad code. >Note that if you are going to document in each section 9 manpage which >APIs >are not safe to call in a critical section, you will need to update just >about every section 9 manpage. A more prudent approach would probably be >to >instead go the sigaction(2) route and instead document the subset of APIs >which are permissible to call in critical_enter(9). The list is probably >not >very long. Off the top of my head I can think of sched_*, swi_sched, >taskqueue_enqueue_fast, and little else. Point taken. >In summary, I would prefer you to revert this. If you want the >assertions to >fire even when WITNESS is disabled then I think we should move them into >the >the non-sleepable lock primitives themselves so that we catch 90+% of the >problem APIs instead of just 1. As noted above, the point wasn't to enable checking when WITNESS was disabled; rather, the point was to make the existing checks more consistent. Basically, if you do something that engenders a panic at high scale, you should get consistent behavior at low scale, too. >Another question you might consider is why are you using spin mutexes in >the >first place (and then calling malloc())? Actually, it was accidental in this case. I hit this while testing some changes. I had accidentally added a malloc inside a critical section, but only realized it while testing at high scale where my free call couldn't be handled from the cache. Granted, that was a bug in my code. But, it would have been nice to have had WITNESS slap me in the face sooner than it did. Jonathan