From owner-freebsd-arch@FreeBSD.ORG Tue Sep 23 08:41:24 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4A67366; Tue, 23 Sep 2014 08:41:24 +0000 (UTC) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A6762BD; Tue, 23 Sep 2014 08:41:24 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id ey11so6837809pad.35 for ; Tue, 23 Sep 2014 01:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:content-type:message-id:date:cc :content-transfer-encoding:to; bh=pU3QLtMnzP5H44m0jiy031GDmTYPXW9x/e45wcudt+o=; b=uZhMm1hhLWsIYT1hmnAkn2NBMeV80K0j0IIQb2QkMTPQBHRHWt54kxleNrQIw23m+a IrQt02cgk+Uo8qiVtDv8WzI/NBHrliywR3+W/IHXTY78xpOjxiZPdID8WglTI1W/cOas jHrmpn3spTBaJBXxBzvcbt7w8eyUFgXtwSQKTL5pQQ/14QbCVtFz2/BCi/EOHLTU1tnr svWk/m2lAfrdZpRkddEdBFoP/UgzBG5G5aTnZZYiBB1KJLiW02h3Ual5u751/yf8X0/s 22ZaqBks6c/Ot6so4ay9cgXdzdi0Zyq140/47i3KIqgUxz0ChHGtZAl31u55EAUgmjxG 0EvA== X-Received: by 10.68.139.163 with SMTP id qz3mr32408754pbb.26.1411461683702; Tue, 23 Sep 2014 01:41:23 -0700 (PDT) Received: from [192.168.20.11] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id yh3sm11402865pbb.38.2014.09.23.01.41.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Sep 2014 01:41:22 -0700 (PDT) Subject: [RFC] fully integrate etc/Makefile into bsd.prog.mk Mime-Version: 1.0 (1.0) From: Garrett Cooper Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (11D257) Message-Id: <11E49217-8154-47AC-8D39-68256017D3A8@gmail.com> Date: Tue, 23 Sep 2014 01:41:22 -0700 Content-Transfer-Encoding: quoted-printable To: "freebsd-rc@freebsd.org" Cc: Mark Johnston , Benno Rice , "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 08:41:24 -0000 Hi all, I was wondering if anyone would have any serious objections to me conver= ting etc/Makefile . The rationale for doing this work would be to ease maint= enance/customization. Thanks! -Garrett= From owner-freebsd-arch@FreeBSD.ORG Tue Sep 23 15:07:11 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5980F7AB for ; Tue, 23 Sep 2014 15:07:11 +0000 (UTC) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1CB60AF1 for ; Tue, 23 Sep 2014 15:07:10 +0000 (UTC) Received: by mail-ig0-f173.google.com with SMTP id l13so4751321iga.6 for ; Tue, 23 Sep 2014 08:07:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=1G2Adxmbt9XHPLSZEK/PZZxN0W30Ab1Okd5k8tDtCts=; b=Zd3exd4Mg5Fo7NoJ3RSm6/FgZCVUl2ZUTM6PWDtOiIN81vo2RYsjzxongk6T9p5vtp Z3KVthIo9yN0haHfpwWM4AZ3EZM4/xMPDfjk0sYuXSKrYesruusOJzWcT3mlCdoA5iP1 T1oUcR5y6nGKmfpxBKHA+jShwY54uU+0dZWbmgzaBixOtS49eTbbqAjFDJAlxXyq+hjZ 03+Ajj4t/P/JL1FE4D6YekoeTyVqTk8fix44x/3HBYJZAIZ65RI2mJHtX0HRXrvSiTMC XmwR/QJCnB0psZgApVv8/H/TjZ3V0V7+zmPY1O5vB2K5gAoH94TKriL+wYjs4ELzFzAc 1MNA== X-Gm-Message-State: ALoCoQmfyyuzV/Fx7NwaznEyZtkM1g7pY7RVUCq11q4wixvji+U8Sw7qTreUZOMiW8HnsCXWxn6+ X-Received: by 10.51.17.2 with SMTP id ga2mr22906282igd.12.1411484829396; Tue, 23 Sep 2014 08:07:09 -0700 (PDT) Received: from [10.1.10.70] ([50.253.99.174]) by mx.google.com with ESMTPSA id mj4sm1878187igb.2.2014.09.23.08.07.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Sep 2014 08:07:08 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_75473453-65BF-4882-BBE0-56A8BBD4C51A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [RFC] fully integrate etc/Makefile into bsd.prog.mk From: Warner Losh In-Reply-To: <11E49217-8154-47AC-8D39-68256017D3A8@gmail.com> Date: Tue, 23 Sep 2014 09:07:06 -0600 Message-Id: <0A216B9F-3437-461E-A52A-032F6B86B5F2@bsdimp.com> References: <11E49217-8154-47AC-8D39-68256017D3A8@gmail.com> To: Garrett Cooper X-Mailer: Apple Mail (2.1878.6) Cc: Mark Johnston , "freebsd-rc@freebsd.org" , Benno Rice , "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 15:07:11 -0000 --Apple-Mail=_75473453-65BF-4882-BBE0-56A8BBD4C51A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 23, 2014, at 2:41 AM, Garrett Cooper = wrote: > Hi all, > I was wondering if anyone would have any serious objections to me = converting etc/Makefile . The rationale for doing this work would be to = ease maintenance/customization. Converting it from what to what? Warner --Apple-Mail=_75473453-65BF-4882-BBE0-56A8BBD4C51A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUIYyaAAoJEGwc0Sh9sBEANG0P/Rsawvcj41cbDFWb8MuoPEcK Rv92qOEsEoD4CJuJ268f4YQi7eXRVY+RAchYM0vDRg9J+ne3jqYteJOqHoO36quF ZnfA3fD9eC9n+iQ+UOetfdW8Y0l03Jtq/BliVycxWAc7P1STmU7xA6ZpQJGp8q1v hKd7Gd+1wCOCfi3FyR5GbD+KETXKGRY6LEicvcrLY+wCfKZLyiLucAdG2uIwIYY4 0yWsCELP4C8TfrhbXTWu1Yd/fKr5NHMNMTW3p6bAsL53SloSbBoEEAxTtLLwmsf9 uPw/ZMi4RLqwsusPOetYpOdxDOG+rPzLIAGnfuI9v/jms5B3kP6evq5xwdxLl6ky IITMb/U1iUalwMwTsgAWSTVKp+mxSdBu5prqYm0QXmQMiqWrI5qjRzmp9wb5OqvB NNhGjleXcnbja/I4uN/7Z4XIHQdfkrG9YIGTNQAlwBqLHSpZS7IO/J0rqc2xU1YF g2LnDMKWxSlFxj5sT+ZBFrdE22EPPXAxtQ0b+RsBLU+MBk9jMvRP+0hrLTlyx7n+ HyAJ6LLJMspES2ldDdbOlyLbPagAP7/AHNJRe+TkpaDKDYUaecO9N0TKpdcUWTN3 iMgdoTClf+QPZTKpqH3ve6k+kvpjjthJTDllB+Q68hINdIdMYkfoS/6+v8IKMmeK u43+Mxq+wejK+7QEZV6h =ezXq -----END PGP SIGNATURE----- --Apple-Mail=_75473453-65BF-4882-BBE0-56A8BBD4C51A-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 23 22:01:04 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88E17FA4; Tue, 23 Sep 2014 22:01:04 +0000 (UTC) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 365F5F76; Tue, 23 Sep 2014 22:01:04 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id hn15so5450947igb.16 for ; Tue, 23 Sep 2014 15:01:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lcgRhTcQ+QYFMaJQoN14jE4xo/+Rpllm4CRzneWYDlo=; b=HAFWsWiZbrFy5Zzrf3Jai+Nfk/40mOaqEIbgafHguCQ8COFhIdK6mXrseii17uz9t3 NGxYxi601VT0gFzyUY1PEz1axYvBBi32/0389GewJSgls94GXBJQ0RakdBHZ02yCsI4U Z7xcj4OcqnMpQr6s4f+CszAz6Br/T3gBruZ/kLTF455X6CkkKm7f+jVtdhVJOEgUCahU u+q7yRwbcx3e6QV9xI1fKv/kB2HBByI5JUaRGXoh6hSPp/I/dHfDzaYIY0/0zUntbLZt 7xijI2AbJN25H1gyzhkAAxn8q3RXNXXOu+cIE8j6cHKEn9qQoDUW9rjQ19ep0HdX4ogz FueQ== MIME-Version: 1.0 X-Received: by 10.42.63.129 with SMTP id c1mr3805530ici.82.1411509663565; Tue, 23 Sep 2014 15:01:03 -0700 (PDT) Received: by 10.50.72.69 with HTTP; Tue, 23 Sep 2014 15:01:03 -0700 (PDT) In-Reply-To: <0A216B9F-3437-461E-A52A-032F6B86B5F2@bsdimp.com> References: <11E49217-8154-47AC-8D39-68256017D3A8@gmail.com> <0A216B9F-3437-461E-A52A-032F6B86B5F2@bsdimp.com> Date: Tue, 23 Sep 2014 15:01:03 -0700 Message-ID: Subject: Re: [RFC] fully integrate etc/Makefile into bsd.prog.mk From: NGie Cooper To: Warner Losh Content-Type: text/plain; charset=UTF-8 Cc: Mark Johnston , "freebsd-rc@freebsd.org" , Benno Rice , "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 22:01:04 -0000 On Tue, Sep 23, 2014 at 8:07 AM, Warner Losh wrote: > > On Sep 23, 2014, at 2:41 AM, Garrett Cooper wrote: > >> Hi all, >> I was wondering if anyone would have any serious objections to me converting etc/Makefile . The rationale for doing this work would be to ease maintenance/customization. > > Converting it from what to what? Looking at etc/Makefile , there are a lot of "custom" targets/ad hoc install rules for installing things like kerberos, openssh, sendmail, etc, in the distribution target: 259 .if ${MK_SENDMAIL} != "no" 260 ${_+_}cd ${.CURDIR}/sendmail; ${MAKE} distribution 261 .endif 262 .if ${MK_OPENSSH} != "no" 263 cd ${.CURDIR}; ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 644 \ 264 ${SSH} ${DESTDIR}/etc/ssh 265 .endif 266 .if ${MK_OPENSSL} != "no" 267 cd ${.CURDIR}; ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 644 \ 268 ${SSL} ${DESTDIR}/etc/ssl 269 .endif 270 .if ${MK_KERBEROS} != "no" 271 cd ${.CURDIR}/root; \ 272 ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 644 \ 273 dot.k5login ${DESTDIR}/root/.k5login; 274 .endif 275 cd ${.CURDIR}/root; \ 276 ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 644 \ 277 dot.profile ${DESTDIR}/root/.profile; \ 278 rm -f ${DESTDIR}/.profile; \ 279 ln ${DESTDIR}/root/.profile ${DESTDIR}/.profile 280 .if ${MK_TCSH} != "no" 281 cd ${.CURDIR}/root; \ 282 ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 644 \ 283 dot.cshrc ${DESTDIR}/root/.cshrc; \ 284 ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 644 \ 285 dot.login ${DESTDIR}/root/.login; \ 286 rm -f ${DESTDIR}/.cshrc; \ 287 ln ${DESTDIR}/root/.cshrc ${DESTDIR}/.cshrc 288 .endif 289 cd ${.CURDIR}/mtree; ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 444 \ 290 ${MTREE} ${DESTDIR}/etc/mtree 291 .if ${MK_PPP} != "no" 292 cd ${.CURDIR}/ppp; ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 600 \ 293 ${PPPCNF} ${DESTDIR}/etc/ppp 294 .endif 1. Some of these items can be easily pushed into SUBDIRs with an appropriate knob to say "I am running make distribution", as they leverage the system Makefiles. Having a cleaner layout would improve maintenance and make the code clearer to follow and it encourages others to not make a mess because it would follow patterns throughout other portions of the tree. 2. Some of these pieces should be placed under knobs because they aren't needed in all configurations. 3. Using variables to specify the install files will allow people/organizations customizing FreeBSD to better leverage make logic and variables (say via custom make.conf/src.conf hooks) to avoid installing the entire "make distribution" kitchensink with ${BIN1:N*firewall*}, etc. The Isilon etc/Makefile for instance is convoluted, in part because of 2. and in part because we have dropped things into /etc/ in non-standard ways in the past. The three observations above are separate items and somewhat orthogonal/parallel to the work being discussed above (maybe I should have titled the thread "cleaning up the etc/Makefile kitchensink", but I was trying to be less bikesheddy). Thanks, -Garrett From owner-freebsd-arch@FreeBSD.ORG Tue Sep 23 22:17:10 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAB7592C for ; Tue, 23 Sep 2014 22:17:10 +0000 (UTC) Received: from smtp2.wemm.org (smtp2.wemm.org [IPv6:2001:470:67:39d::78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp2.wemm.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A9392142 for ; Tue, 23 Sep 2014 22:17:10 +0000 (UTC) Received: from hater-dm.corp.yahoo.com (nat-dip4.cfw-a-gci.corp.yahoo.com [209.131.62.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: peter) by smtp2.wemm.org (Postfix) with ESMTPSA id 6C9EE7A1 for ; Tue, 23 Sep 2014 15:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1411510630; bh=6pfxl1fG/K8yOw0EOs+upd4KNKuVvb2/js+c2zxCjpk=; h=Date:From:To:Subject:References:In-Reply-To; b=Jy5AEVTsMgHIPhJWus0kWXc/MIkYM0j3ZzJHsiLv+mX8NUxcEfZo82qHp1bU0ukfA fSYm7CygNr5FGdaOUHQ5rOnwvBp2jnIDf/q+2q+hbS3yVm0Z0nmq4qcFg3fa0T0LLh ssqwApxpIIAwPwqN4pdQMeLygagP+gsWAZ9r1yfw= Message-ID: <5421F165.7030304@wemm.org> Date: Tue, 23 Sep 2014 15:17:09 -0700 From: Peter Wemm User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: [RFC] fully integrate etc/Makefile into bsd.prog.mk References: <11E49217-8154-47AC-8D39-68256017D3A8@gmail.com> <0A216B9F-3437-461E-A52A-032F6B86B5F2@bsdimp.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lqNQQP0QkqoEXnWCKgfihtM0qThktO67X" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 22:17:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lqNQQP0QkqoEXnWCKgfihtM0qThktO67X Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/23/14 3:01 PM, NGie Cooper wrote: > On Tue, Sep 23, 2014 at 8:07 AM, Warner Losh wrote: >> >> On Sep 23, 2014, at 2:41 AM, Garrett Cooper wr= ote: >> >>> Hi all, >>> I was wondering if anyone would have any serious objections to me = converting etc/Makefile . The rationale for doing this work would be to e= ase maintenance/customization. >> >> Converting it from what to what? >=20 [..] > The three observations above are separate items and somewhat > orthogonal/parallel to the work being discussed above (maybe I should > have titled the thread "cleaning up the etc/Makefile kitchensink", but > I was trying to be less bikesheddy). Please keep in mind that the interface here to release build processes ha= s been relatively stable for a long time. Gratuitous changes for no clear benefit would not be well received if it means having to do things significantly differently on some branches to others. Knowledge of how this works, and/or workarounds for the quirks in it embedded in at least the following: mergemaster etcupdate snapshot builder release build process cluster release build process my employer's release build process, along with other people's. If there's a clear benefit that makes disrupting those all worth it, it h= ad better be more tangible than "it looks cleaner". You're right that it's far from pretty, but its dealt with the same way a= t least as far back as stable/4 and consistency is important to some of us.= --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6F= JV --lqNQQP0QkqoEXnWCKgfihtM0qThktO67X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Darwin) iQEcBAEBAgAGBQJUIfFlAAoJEDXWlwnsgJ4EeNwH/RyMCpxZ9DJQg54urQ13uSrg FbYCsHtRS214XRNzbrvCLuUsS5spPNWIJb/BBGvGGA5799TDfH01qhHXBkAgM5rg FUaE8FniYEmlqmdQ+gQiCgM4TXCvrXih1rjvOa7LOX2eVqjkpQchM4FXlSKcK/Is FQngL84rEZK1VYGPQ1pmghca4rNlJEJ+xAhocxY+j1+vjw2RIDcMkFCnfVM5c9+S bErCFjk26y1AanNYxLNYyrSQ4tyekMW01f21Cd9x32jnBVO9PAA9HYKZLhOt9Vz7 QpGS1YPl50yjZSu/2dcbgyKmu6DcceEhRc53SVJPwjIUq5CsmvkgSJBnFMP43e8= =aPO2 -----END PGP SIGNATURE----- --lqNQQP0QkqoEXnWCKgfihtM0qThktO67X-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 23 22:37:55 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51FC4590 for ; Tue, 23 Sep 2014 22:37:55 +0000 (UTC) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 20CF733E for ; Tue, 23 Sep 2014 22:37:55 +0000 (UTC) Received: by mail-ig0-f178.google.com with SMTP id r10so5481997igi.17 for ; Tue, 23 Sep 2014 15:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zxx8WpRgCy4kEQLn4ENu0oqpKX7lT9zVdTcGgrrmd8c=; b=lauvZNTrNKgKRSteAWSOv9XQTKngXUigPzzHVcsDPUyEzN63dUex6WJZvFVXnc8SJL a6KTs+sLOeJcgXECQHNSFmBLGouo1sjQY3+5oXKMjSJzRFX2RlKIz+0EYNTK/+46qz71 Qz0KynlniB6UO9Fu5YrwerzVQjCAi8cqKj5DCj0sIW6PX5H6ZNqC/q6XhCCHfieaZdy6 5obxCAmY/7L0c2t/T5FkVh+dAI/YQpBMDgFu13fZHMz7DbmO1ntD+h2RvJdDOHFKGEQf /agdwRL+gy1ACFg+e84p3VSMsET+j/jFcBupWuKHK3fd56Hydx9REUI8+HqyzjYK06JZ e0gQ== MIME-Version: 1.0 X-Received: by 10.50.51.2 with SMTP id g2mr26490772igo.7.1411511874477; Tue, 23 Sep 2014 15:37:54 -0700 (PDT) Received: by 10.50.72.69 with HTTP; Tue, 23 Sep 2014 15:37:54 -0700 (PDT) In-Reply-To: <5421F165.7030304@wemm.org> References: <11E49217-8154-47AC-8D39-68256017D3A8@gmail.com> <0A216B9F-3437-461E-A52A-032F6B86B5F2@bsdimp.com> <5421F165.7030304@wemm.org> Date: Tue, 23 Sep 2014 15:37:54 -0700 Message-ID: Subject: Re: [RFC] fully integrate etc/Makefile into bsd.prog.mk From: NGie Cooper To: Peter Wemm Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 22:37:55 -0000 Hi Peter! On Tue, Sep 23, 2014 at 3:17 PM, Peter Wemm wrote: ... > Please keep in mind that the interface here to release build processes has > been relatively stable for a long time. Gratuitous changes for no clear > benefit would not be well received if it means having to do things > significantly differently on some branches to others. Understood. > Knowledge of how this works, and/or workarounds for the quirks in it > embedded in at least the following: > mergemaster > etcupdate > snapshot builder > release build process > cluster release build process > my employer's release build process, along with other people's. I'll take a look at how this is done in mergemaster, etcupdate, release, etc. Do you have a pointer to the snapshot builder/cluster release build process as well? Links offline would be much appreciated. > If there's a clear benefit that makes disrupting those all worth it, it had > better be more tangible than "it looks cleaner". Well, more consistent, cleaner, and easier for others to customize in the future. I don't want to change external interfaces for etc/Makefile (make distribution/make distribute/make install). > You're right that it's far from pretty, but its dealt with the same way at > least as far back as stable/4 and consistency is important to some of us. I totally understand, which is why I'm reaching out for comment. I've only been using FreeBSD since 5.2, so I still consider myself new on the block, such that I don't know all the ins and outs of older releases (and I need guidance from others who have been working with older releases to avoid breaking their processes). Thank you very much for the input! -Garrett From owner-freebsd-arch@FreeBSD.ORG Tue Sep 23 23:12:10 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B519B3C2; Tue, 23 Sep 2014 23:12:09 +0000 (UTC) Date: Tue, 23 Sep 2014 19:12:05 -0400 From: Glen Barber To: NGie Cooper Subject: Re: [RFC] fully integrate etc/Makefile into bsd.prog.mk Message-ID: <20140923231205.GA40545@hub.FreeBSD.org> References: <11E49217-8154-47AC-8D39-68256017D3A8@gmail.com> <0A216B9F-3437-461E-A52A-032F6B86B5F2@bsdimp.com> <5421F165.7030304@wemm.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 23:12:10 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 23, 2014 at 03:37:54PM -0700, NGie Cooper wrote: > On Tue, Sep 23, 2014 at 3:17 PM, Peter Wemm wrote: > > Please keep in mind that the interface here to release build processes = has > > been relatively stable for a long time. Gratuitous changes for no clear > > benefit would not be well received if it means having to do things > > significantly differently on some branches to others. >=20 > Understood. >=20 > > Knowledge of how this works, and/or workarounds for the quirks in it > > embedded in at least the following: > > mergemaster > > etcupdate > > snapshot builder > > release build process > > cluster release build process > > my employer's release build process, along with other people's. >=20 And the "other people's" is exactly why etc/Makefile should remain untouched. Many companies build their own releases, and touching something for the sake of touching something will inevitably break something that has worked for a long time. In my opinion, etc/Makefile is not broken, so there is no reason to "fix" it. You can consider my reply an objection to arbitrary changes to etc/Makefile, in this case. Glen --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUIf5FAAoJELls3eqvi17QGQsQAIMfpcOGOVYKP0nqxW/4ofuf vTKZPHqps7nF0K1EOisFQHhhe/xNNOR44S8Fsq+CpyB5F4OWDvgLKz/UxP80wL7l mKW8BGxNysJvnoJsKbMWmWCG1bRq0VtSXaMDxeM30cW1XuudWX+xxwlBQ1JoJiK5 imL3McX4NJ4FdJc3hMO75EOEEXPFCUU9G84YcsTWDNUwrO3Zp6dEwOlUGsGFryy0 +jVXXa2Sf0jOxSO9gTMhXSrTxwPbv409A1WZBUxI+Oj5JFaLbTH9ZtC5Zi6t9+nS eycAreFR8JQQgCuSDF1mOPGXcc16iTd4qYdHGDsUkBA/glCx3OlDHiw9Xfr1XGYk pQNebJjFI6WAvAnRo4TGicM4LRzEtA3Xu/Vc0326kLr7mrVzCyrcMBPh6Evlpdnm zFyhZypqIjWUbOJcoLo0RccIi87hZPSicXTThNx8DxCMBldz1m7lmVVoeVXbb0vG ntWbUPfG7notd0oFiBvqaBkNqWr03wYqz2HE1KAvmbcfyiQVnilMEEHv3S/6VWVl TJRUKth9186t7k1Qvf7kzmDydZqWM+6oQb2TQvdTnaYEyIRNbVckEZa5N53oFUIn ZLdMSMyTvcOTsuWW0lcni0WnAZwAoVMhyQIIv5w55Zpy8QBoRkHaKfh62IbiJokM Jn8UIv9zpmaNbF8iSHq3 =KFGw -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 23 23:20:21 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C4D75DC; Tue, 23 Sep 2014 23:20:21 +0000 (UTC) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D7DDA9D2; Tue, 23 Sep 2014 23:20:20 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id fp1so3243839pdb.14 for ; Tue, 23 Sep 2014 16:20:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=TSGk27i/6aBfOQpA+yNLkMUaW52LsxuO8vkOWU8iCKU=; b=cM/nCAU4FZioBAFY6Q8s7D/U6btAJ7AJP640ZG8JU5AaaYEQvwSX/paHl8Xq+q5AxL E0FKOoArdC7o+ZqgcfLNgeD1C1H7EB4sJEHIv/3TB9uIdNhcmxFIp2ZUwy1Mx8CX3edV jdk3c5e6Re25/Z/OQY2+wGk8KgRVRG1MDB2KYJq1mdsi+g4RAazf2bwUyG1AWChKJSzd P4Z1wutPKSAwJawoSzDNu3r1kSOjcKH0wxBS6RbXVjI5nwiH628yNItX5WYW8BA7UyDm 0UZ17KPv4MbopYS0sTxBT4VC1ahaok0gwMjtnFLVHyOhsYFc5PtgjC4EH16jqg+ipvnu +sPw== X-Received: by 10.68.216.35 with SMTP id on3mr3902024pbc.34.1411514420330; Tue, 23 Sep 2014 16:20:20 -0700 (PDT) Received: from [192.168.242.58] (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by mx.google.com with ESMTPSA id fk10sm13121354pab.29.2014.09.23.16.20.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Sep 2014 16:20:19 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_BEC49B27-96DC-4630-A05A-E275E36CFA2E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [RFC] fully integrate etc/Makefile into bsd.prog.mk From: Garrett Cooper In-Reply-To: <20140923231205.GA40545@hub.FreeBSD.org> Date: Tue, 23 Sep 2014 16:20:17 -0700 Message-Id: <8CE07FF2-6D08-4270-8214-1C8493E56536@gmail.com> References: <11E49217-8154-47AC-8D39-68256017D3A8@gmail.com> <0A216B9F-3437-461E-A52A-032F6B86B5F2@bsdimp.com> <5421F165.7030304@wemm.org> <20140923231205.GA40545@hub.FreeBSD.org> To: Glen Barber X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 23:20:21 -0000 --Apple-Mail=_BEC49B27-96DC-4630-A05A-E275E36CFA2E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 23, 2014, at 16:12, Glen Barber wrote: ... > And the "other people's" is exactly why etc/Makefile should remain > untouched. Many companies build their own releases, and touching > something for the sake of touching something will inevitably break > something that has worked for a long time. >=20 > In my opinion, etc/Makefile is not broken, so there is no reason to > "fix" it. You can consider my reply an objection to arbitrary changes > to etc/Makefile, in this case. Ok. I=92ll rescind my proposal to cleanup/change the = structure/method used for installing things in etc/Makefile, and instead = focus on testing and review of the removal of optional pieces from the = install which are always installed. Thank you for the input, -Garrett --Apple-Mail=_BEC49B27-96DC-4630-A05A-E275E36CFA2E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUIgAxAAoJEMZr5QU6S73eiXMIAI8h5AmsHpLazcKuOKPSTsN7 RM/WPLMBcaIpVT7Z2+9SPo+Rf7swbblU5Ef28d6dlg2AyXwFk8KyEFMrb/iSTGVz UIHKKWDJKJ946WQZAMlcz1b3nFzTLC4Zl6QJX039EappV1epU3pzLAjUALA9l7Bl rQPYyBlV3ccpSyPqG6URhAHWY7jMnYdhAeEA/YSGwrTN4qKmq5HKrFtnzekffbpL d6eKVyheoffZnRhGU5ZT6BfkVsOl84FrOev49SNr1aVzd2qJiCUoSgqWUZZkHRew gvn3uf7P5ngAJOQqkM+yi0UEYpwM9EDAxRk9ovoaZOZ2RNWbUlXoRN9YgmR2Ssk= =VK82 -----END PGP SIGNATURE----- --Apple-Mail=_BEC49B27-96DC-4630-A05A-E275E36CFA2E-- From owner-freebsd-arch@FreeBSD.ORG Wed Sep 24 12:27:34 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0DEF0456 for ; Wed, 24 Sep 2014 12:27:34 +0000 (UTC) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C5283234 for ; Wed, 24 Sep 2014 12:27:33 +0000 (UTC) Received: by mail-qg0-f47.google.com with SMTP id z107so5832062qgd.34 for ; Wed, 24 Sep 2014 05:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=tjvLRvh+OU6At2W0C840Us81+mvhZoQBiOWFSD7E7bI=; b=zX1ksxPR0gaXoW14s3JWaD7bPNBJrFvOY64F0u5HRzj4yjirrfyiRedjXoUm1yP2nL Q/2OK3V+g7yEQXnuHyLYBoCDO24KU5Zpid2HptKHuiTKZTuOqFlM7ex8tXIUAYQ2ROlT 5ck5P7g91dtYWXnijUN2lHpm48DaGr7p4U1+FIZy9A4Bq/IVfhb2J90QA8a+zbAUCUoz lSImOxY3f40HhDmB1cxoaJMWUi87ySL40N7qKD2tsqE4YUX6k8Z68jQMvXQd9iTWnGD7 JbfRpySR4q8lwN5b7NzvPvxJ8Z+WMW8/zjWvWWAYNbZRmnaDuES+pU+mUz2aaTjoptKL AUhQ== MIME-Version: 1.0 X-Received: by 10.229.100.68 with SMTP id x4mr8240965qcn.29.1411561652949; Wed, 24 Sep 2014 05:27:32 -0700 (PDT) Received: by 10.140.23.242 with HTTP; Wed, 24 Sep 2014 05:27:32 -0700 (PDT) Date: Wed, 24 Sep 2014 14:27:32 +0200 Message-ID: Subject: vm_page_array and VM_PHYSSEG_SPARSE From: Svatopluk Kraus To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 12:27:34 -0000 Hi, I and Michal are finishing new ARM pmap-v6 code. There is one problem we've dealt with somehow, but now we would like to do it better. It's about physical pages which are allocated before vm subsystem is initialized. While later on these pages could be found in vm_page_array when VM_PHYSSEG_DENSE memory model is used, it's not true for VM_PHYSSEG_SPARSE memory model. And ARM world uses VM_PHYSSEG_SPARSE model. It really would be nice to utilize vm_page_array for such preallocated physical pages even when VM_PHYSSEG_SPARSE memory model is used. Things could be much easier then. In our case, it's about pages which are used for level 2 page tables. In VM_PHYSSEG_SPARSE model, we have two sets of such pages. First ones are preallocated and second ones are allocated after vm subsystem was inited. We must deal with each set differently. So code is more complex and so is debugging. Thus we need some method how to say that some part of physical memory should be included in vm_page_array, but the pages from that region should not be put to free list during initialization. We think that such possibility could be utilized in general. There could be a need for some physical space which: (1) is needed only during boot and later on it can be freed and put to vm subsystem, (2) is needed for something else and vm_page_array code could be used without some kind of its duplication. There is already some code which deals with blacklisted pages in vm_page.c file. So the easiest way how to deal with presented situation is to add some callback to this part of code which will be able to either exclude whole phys_avail[i], phys_avail[i+1] region or single pages. As the biggest phys_avail region is used for vm subsystem allocations, there should be some more coding. (However, blacklisted pages are not dealt with on that part of region.) We would like to know if there is any objection: (1) to deal with presented problem, (2) to deal with the problem presented way. Some help is very appreciated. Thanks Svatopluk Kraus From owner-freebsd-arch@FreeBSD.ORG Wed Sep 24 16:08:00 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD3F8EF1 for ; Wed, 24 Sep 2014 16:08:00 +0000 (UTC) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F5C7273 for ; Wed, 24 Sep 2014 16:08:00 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id h18so6781903igc.2 for ; Wed, 24 Sep 2014 09:07:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=7hDY985Gx0C4TZUY69zeuPYgwo+L7sFjGuMbyZSLJ6E=; b=JgsD+dEox2mDah3vipmtwQyng64UGBec1t6HaSiRiL1HMvV9gnEcRDbMk3oNDQpBgw NHE3q3VQ2yeQEQqAi17VwBtJD7cltodSW3qpY7C6iCxuqqquCgbw12lpPFp6yYHtu3df u+bwuJeeSE681t4s2nG9V5CreFaM6u6R1qOvav8sBFamIbyEnzfiXK+BlSTE0ibsX2FB V413KXR391icxWJ+yoaSEPMEWO+U6Gks4tOZqi/Dj314v2FZeSWaCb8krlPzC0KnBPPq 3xXF7iGcIpUBjbOm1gO3p7Sm1jWnGGj21ZtrtCbW4DLsHRYBzP9gvbjy6NsvIQf3OSiJ Tygg== X-Gm-Message-State: ALoCoQmsh8T1yA/8Q+fo6hijHzZmqfJ6AHWbJQoGv7gBDE0v44Mjz8jptyuXujDqjrTbhrH947uG X-Received: by 10.50.72.73 with SMTP id b9mr10922776igv.0.1411574874402; Wed, 24 Sep 2014 09:07:54 -0700 (PDT) Received: from [10.1.10.70] ([50.253.99.174]) by mx.google.com with ESMTPSA id qo8sm4610308igb.7.2014.09.24.09.07.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Sep 2014 09:07:53 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_249F6AAF-08C8-499C-A5AC-86A2F38D3450"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [RFC] fully integrate etc/Makefile into bsd.prog.mk From: Warner Losh In-Reply-To: <8CE07FF2-6D08-4270-8214-1C8493E56536@gmail.com> Date: Wed, 24 Sep 2014 10:07:50 -0600 Message-Id: <8D6B4CD4-D099-4BA9-9BE1-39FC4658A992@bsdimp.com> References: <11E49217-8154-47AC-8D39-68256017D3A8@gmail.com> <0A216B9F-3437-461E-A52A-032F6B86B5F2@bsdimp.com> <5421F165.7030304@wemm.org> <20140923231205.GA40545@hub.FreeBSD.org> <8CE07FF2-6D08-4270-8214-1C8493E56536@gmail.com> To: Garrett Cooper X-Mailer: Apple Mail (2.1878.6) Cc: Glen Barber , "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 16:08:01 -0000 --Apple-Mail=_249F6AAF-08C8-499C-A5AC-86A2F38D3450 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 23, 2014, at 5:20 PM, Garrett Cooper = wrote: > On Sep 23, 2014, at 16:12, Glen Barber wrote: >=20 > ... >=20 >> And the "other people's" is exactly why etc/Makefile should remain >> untouched. Many companies build their own releases, and touching >> something for the sake of touching something will inevitably break >> something that has worked for a long time. >>=20 >> In my opinion, etc/Makefile is not broken, so there is no reason to >> "fix" it. You can consider my reply an objection to arbitrary = changes >> to etc/Makefile, in this case. >=20 > Ok. I=92ll rescind my proposal to cleanup/change the = structure/method used for installing things in etc/Makefile, and instead = focus on testing and review of the removal of optional pieces from the = install which are always installed. > Thank you for the input, That=92s why I asked what the plan was. etc/Makefile is simply fraught = with danger. Warner --Apple-Mail=_249F6AAF-08C8-499C-A5AC-86A2F38D3450 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUIuxXAAoJEGwc0Sh9sBEAdGAQALSFs2rlphDJLcDkY7NdBRfs /CgMypPzS6AI9AdMe+g/J65jjJ6trAlgJY8jkLvkTJ0G/98ahNhcPUDgYfuf3PBd hF5VenO54LxXwxOZ7GLuZqxu2DhdFK6RArskemMXEghtfJ1PjcCCoA1AeKXJSfmL idB8DLtyapO/vOECv5NXXezZX9J7ToC6Q3rlUd+fBnOV3twm7scrhOsqtx47FLsy x723vMs1f0XOyvjvWt8AhaH9dFMu+khPd2aPF+yRtUnYj+W6Z6NfhaWSu6oth6Tk G7sANpBLyuYTPvGgm4632Gy/V4guu4fjE/gGME6hXpRAyjBk+bqsN2ekWjLWqxEn o3wH3uFn1BxET2eVkxp+Dk5q8MkrkLYQdnX3CG0Jy9CbhROA2fTrHuYgfOW/RrOX aPqioIZT1XOBMLicxY1W26EcRneZepNAzDMc5TttBFdrFITCvyYQhHs2e5K2dQuY 54lLWcyqKCSfCXsBP5CpMb1JE8ci14rgglGLGP21RQF8rj0VxOYpCB0sHzr52z92 uRJE9vUf37qIiBRFX51NOzo3WDLOjJPzviMWRrtaVmHKqs8DIKOylariHBRvefQj DMk6iFyqAWvoAY49KxlpV9mwotIeohOYPb82oZVZJYEjViNFiA8cCIhOEq47wNiJ SAA5ShBEZNM8ndlLbXiv =CpoB -----END PGP SIGNATURE----- --Apple-Mail=_249F6AAF-08C8-499C-A5AC-86A2F38D3450-- From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 01:16:19 2014 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 623594E8 for ; Thu, 25 Sep 2014 01:16:19 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 40707829 for ; Thu, 25 Sep 2014 01:16:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s8P1GJ16000562 for ; Thu, 25 Sep 2014 01:16:19 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s8P1GIQ7000561 for arch@FreeBSD.org; Thu, 25 Sep 2014 01:16:18 GMT (envelope-from bdrewery) Received: (qmail 34552 invoked from network); 24 Sep 2014 20:16:13 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 24 Sep 2014 20:16:13 -0500 Message-ID: <54236CD6.4050807@FreeBSD.org> Date: Wed, 24 Sep 2014 20:16:06 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: arch@FreeBSD.org Subject: KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X6QTeF9kHuvhb6A6pUts68oMf7cXfQl9O" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 01:16:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --X6QTeF9kHuvhb6A6pUts68oMf7cXfQl9O Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I've placed 2 reviews out in relation to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193696: Add KASSERT_WARN which will work just like KASSERT except that no panic will occur. My own expectation would be that any use of it would eventually be promoted to a full KASSERT. It would only be used where the impact is not known yet on all hardware/devices. We don't want to go adding a KASSERT and break boot for a whole class of systems. https://reviews.freebsd.org/D829 - KASSERT_WARN Add the KASSERT_WARN to malloc(9) and uma_zalloc_arg(9) to ensure they are not called from a non-sleepable thread. This is currently violated by cam, namely xpt_done_td() [see bug 193696]. https://reviews.freebsd.org/D830 - Use KASSERT_WARN in malloc(9) and uma_zalloc_arg(9) One flaw of this is that the KASSERT_WARN in malloc(9) is called, prints to console, continues, and then the uma_zalloc_arg(9) is called and does the same. I thought perhaps the KASSERT_WARN could only be added in uma_zalloc_arg(9) for now and later the full KASSERT could be added in malloc(9), but I think this could miss some cases for memguard and maybe redzone uses. By the way, it was mentioned to me that the interrupt assert may be wrong but from my understanding the thread is in an interrupt context if td_intr_nesting_level>0, so the check seems fine to me. Example output: > ada3: s/n STF605MH1THSXW detached > KASSERT failed: malloc(M_WAITOK) in no_sleeping context > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe349= 829a340 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe349829a3f0 > _kassert_panic() at _kassert_panic+0xd7/frame 0xfffffe349829a470 > malloc() at malloc+0x2e4/frame 0xfffffe349829a4c0 > g_post_event_x() at g_post_event_x+0x84/frame 0xfffffe349829a510 > g_post_event() at g_post_event+0x5d/frame 0xfffffe349829a580 > adacleanup() at adacleanup+0x62/frame 0xfffffe349829a5a0 > cam_periph_release_locked_buses() at cam_periph_release_locked_buses+0x= de/frame 0xfffffe349829aaa0 > cam_periph_release_locked() at cam_periph_release_locked+0x1b/frame 0xf= ffffe349829aac0 > adadone() at adadone+0x26e/frame 0xfffffe349829ab20 > xpt_done_process() at xpt_done_process+0x3a4/frame 0xfffffe349829ab60 > xpt_done_td() at xpt_done_td+0x136/frame 0xfffffe349829abb0 > fork_exit() at fork_exit+0x84/frame 0xfffffe349829abf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe349829abf0 > --- trap 0, rip =3D 0, rsp =3D 0xfffffe349829acb0, rbp =3D 0 --- > KASSERT failed: uma_zalloc_arg(M_WAITOK) in no_sleeping context > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe349= 829a2d0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe349829a380 > _kassert_panic() at _kassert_panic+0xd7/frame 0xfffffe349829a400 > uma_zalloc_arg() at uma_zalloc_arg+0x6c5/frame 0xfffffe349829a470 > malloc() at malloc+0x1c7/frame 0xfffffe349829a4c0 > g_post_event_x() at g_post_event_x+0x84/frame 0xfffffe349829a510 > g_post_event() at g_post_event+0x5d/frame 0xfffffe349829a580 > adacleanup() at adacleanup+0x62/frame 0xfffffe349829a5a0 > cam_periph_release_locked_buses() at cam_periph_release_locked_buses+0x= de/frame 0xfffffe349829aaa0 > cam_periph_release_locked() at cam_periph_release_locked+0x1b/frame 0xf= ffffe349829aac0 > adadone() at adadone+0x26e/frame 0xfffffe349829ab20 > xpt_done_process() at xpt_done_process+0x3a4/frame 0xfffffe349829ab60 > xpt_done_td() at xpt_done_td+0x136/frame 0xfffffe349829abb0 > fork_exit() at fork_exit+0x84/frame 0xfffffe349829abf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe349829abf0 > --- trap 0, rip =3D 0, rsp =3D 0xfffffe349829acb0, rbp =3D 0 --- > (ada3:ahcich3:0:0:0): Periph destroyed --=20 Regards, Bryan Drewery --X6QTeF9kHuvhb6A6pUts68oMf7cXfQl9O Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJUI2zWAAoJEDXXcbtuRpfPnREH/RM90JrAEzfoiZR8j8+lP3Zm m1PxVrLFZs4pDsMS0CXMJCtlL1Q/Cna9yo9c6XXk/hOCT9jrZWrgGiVTJMCdVGVh jdePOukAITndpzr1ayJH1E0h5OBtmn0r+0BVgAmEpMk6bW+35z+KqiwaGY2vS2m6 I0Saksc9hu58sSQdn3rR26moXJB1AO2VCxQkyhE+ir9Ac78NGeZcrUnR/KCfO9qE maVQkk8wF8T1GbW6UVHq38q0FC+PVXmAUqRUlzUv/acHRSxoa/JedFsY+SRRdIED qKaFXVx/iYCPzzyI6xAiNxTxNPt6IOSj79p8ovuZM7Y9IN34y7mAod6m8Sa8wXE= =KmhT -----END PGP SIGNATURE----- --X6QTeF9kHuvhb6A6pUts68oMf7cXfQl9O-- From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 01:22:37 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4C395D1; Thu, 25 Sep 2014 01:22:37 +0000 (UTC) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 769F08D5; Thu, 25 Sep 2014 01:22:37 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id rl12so6246651iec.6 for ; Wed, 24 Sep 2014 18:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=su12T/qZOueRWE4QBlFUo3HcjH2vTjfb4dItg6ZDT30=; b=o+dPRfi8KSGjl9YehoBmrV9Utj/dbuoiQLBaRIMghXaoud31rpi9NnjIDIzBoD2VBR 0tAFtDv4QzMzIYWYBrdAQt4Uwc3jndykYqfgjVYLmcr7T7MLaop/eWrKSMV//6logeJE x1hw66HkT5UaTpWw3Ml4HWG8jPNky7cRk/su4FjR9ZbaZpss6tvL+dK6JytRUuFElqlv YQQJ04d5jc+v0YH+nYZbyt6VwLWXm42aC1zgscKqo1Aa97HieSEc26+kenmHQW+0t3bE uAiCg7A1P97ovnIfUfSHneVVzxT+j31+r/wJZ/jirGk4tFAmKPZd70gtm2G4v9Gm+0rU 4RRA== MIME-Version: 1.0 X-Received: by 10.50.57.110 with SMTP id h14mr627110igq.26.1411608156635; Wed, 24 Sep 2014 18:22:36 -0700 (PDT) Received: by 10.50.72.69 with HTTP; Wed, 24 Sep 2014 18:22:36 -0700 (PDT) In-Reply-To: <8D6B4CD4-D099-4BA9-9BE1-39FC4658A992@bsdimp.com> References: <11E49217-8154-47AC-8D39-68256017D3A8@gmail.com> <0A216B9F-3437-461E-A52A-032F6B86B5F2@bsdimp.com> <5421F165.7030304@wemm.org> <20140923231205.GA40545@hub.FreeBSD.org> <8CE07FF2-6D08-4270-8214-1C8493E56536@gmail.com> <8D6B4CD4-D099-4BA9-9BE1-39FC4658A992@bsdimp.com> Date: Wed, 24 Sep 2014 18:22:36 -0700 Message-ID: Subject: Re: [RFC] fully integrate etc/Makefile into bsd.prog.mk From: NGie Cooper To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Glen Barber , "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 01:22:37 -0000 On Wed, Sep 24, 2014 at 9:07 AM, Warner Losh wrote: > > On Sep 23, 2014, at 5:20 PM, Garrett Cooper wrote= : > >> On Sep 23, 2014, at 16:12, Glen Barber wrote: >> >> ... >> >>> And the "other people's" is exactly why etc/Makefile should remain >>> untouched. Many companies build their own releases, and touching >>> something for the sake of touching something will inevitably break >>> something that has worked for a long time. >>> >>> In my opinion, etc/Makefile is not broken, so there is no reason to >>> "fix" it. You can consider my reply an objection to arbitrary changes >>> to etc/Makefile, in this case. >> >> Ok. I=E2=80=99ll rescind my proposal to cleanup/change the structu= re/method used for installing things in etc/Makefile, and instead focus on = testing and review of the removal of optional pieces from the install which= are always installed. >> Thank you for the input, > > That=E2=80=99s why I asked what the plan was. etc/Makefile is simply frau= ght with danger. My lack of a plan was probably what caused the FUD. I didn't have one yet because I was doing initial investigation to see whether or not what I was proposing was even plausible. Basically, the idea was to do the following: Goal: - All high level/documented targets (all, clean, distribute, distribution, install, etc) would remain untouched. No backwards compatibility would be broken when doing this work. Tasks: 1. Any "missing" Makefiles in subdirectories would be added/converted as needed to bsd.prog.mk in order to handle "make distribution" cleanly. 2. All lines like "cd ${.CURDIR}/some-dir; make install" executed under the distribution target would turn into something like this: # Only install these items with make distribution. .if make(distribution) SUBDIR+=3D some-dir .endif I would need to change ${.TARGET} to execute install like is currently being done today (with exception of sendmail -- which handles make distribution), unless I created a Makefile.inc in the directory which created the distribution target as needed. 3. Everything would be converted over to FILES/FILESDIR or SCRIPTS/SCRIPTSDIR in etc/Makefile that is installed from etc. 4. Everything that's not installed from /etc would be moved to their relevant subdir Makefile. 5. Targets that handle creating login.conf.db, etc would be moved to the end of the target, or be moved to a supporting target which would ensure that vendors/users would have the ability to customize ${DESTDIR}/etc before cap_mkdb, etc are run, eliminating the need for duplicated logic in scripts. Thanks, -Garrett From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 02:56:19 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AFF1B3FE; Thu, 25 Sep 2014 02:56:19 +0000 (UTC) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F028122; Thu, 25 Sep 2014 02:56:18 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id q1so105690lam.7 for ; Wed, 24 Sep 2014 19:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oyu5FGtdWv/WXbVJMks+dXE7Hd0bMVBXO7D6NzRGmh8=; b=Zf0GkRXyzV2x+VddHE0d4qR5XKWwEpvT8CO3rg/lLsMzTsQ2/qLgO5X+Z17qV4TMaR pQnB1irKRmrE7Rv3vfDUJRX0xWnhJ9JkXn4hWx7i4dZ/szSkUqGc2ru5AqlV60BWhvHG A93IcH1Srikhdfd9gNKV2WxiFqifmzcfROaOMT9DHRPYRGhzTQ1zH1MvE9FI/sIuLFcz Dr+N39kYrWLj2V+x/049EuIUcTJmJyTxrUw3NqoZ/l/WeSPJxOpwxbm4aZsMk2C/iB0d UC3FJGDQHakPMbdwmjNsufnVK8FKAEm2CDBC0eX79uAtKWfTTGn7+4882AdsIO3nBM/a MEYw== MIME-Version: 1.0 X-Received: by 10.112.35.201 with SMTP id k9mr6320288lbj.88.1411613776810; Wed, 24 Sep 2014 19:56:16 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.25.207.74 with HTTP; Wed, 24 Sep 2014 19:56:16 -0700 (PDT) In-Reply-To: <54236CD6.4050807@FreeBSD.org> References: <54236CD6.4050807@FreeBSD.org> Date: Wed, 24 Sep 2014 19:56:16 -0700 X-Google-Sender-Auth: XNRTeAkyGp4BP1WTxPfoltlMd4A Message-ID: Subject: Re: KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread From: Davide Italiano To: Bryan Drewery Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 02:56:19 -0000 On Wed, Sep 24, 2014 at 6:16 PM, Bryan Drewery wrote: > Hi, > > I've placed 2 reviews out in relation to > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193696: > > Add KASSERT_WARN which will work just like KASSERT except that no panic > will occur. My own expectation would be that any use of it would > eventually be promoted to a full KASSERT. It would only be used where > the impact is not known yet on all hardware/devices. We don't want to > go adding a KASSERT and break boot for a whole class of systems. > > https://reviews.freebsd.org/D829 - KASSERT_WARN > FYI, I'm not excited about the idea. If you introduce an assert you want some invariant to not be violated. If it's violated, there's something clearly going wrong and you need to stop and think about it. I guess that in most cases is just better fail early, rather than keep going with the system in a semi-functional state. Also, please note that once a KPI is introduced in the kernel, everybody may start abusing it. A previous attempt (in my opinion wrong) was made to have KASSERT to log rather than panic. It actually didn't lead to any benefit, apparently. FWIW, at least your approach is more fine grained. -- Davide From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 02:57:20 2014 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11BE54AD for ; Thu, 25 Sep 2014 02:57:20 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 E6802132 for ; Thu, 25 Sep 2014 02:57:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s8P2vJBB033650 for ; Thu, 25 Sep 2014 02:57:19 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s8P2vJFu033649 for arch@FreeBSD.org; Thu, 25 Sep 2014 02:57:19 GMT (envelope-from bdrewery) Received: (qmail 87317 invoked from network); 24 Sep 2014 21:57:17 -0500 Received: from unknown (HELO blah) (freebsd@shatow.net@10.10.1.90) by sweb.xzibition.com with ESMTPA; 24 Sep 2014 21:57:17 -0500 Message-ID: <5423848D.9050602@FreeBSD.org> Date: Wed, 24 Sep 2014 21:57:17 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: arch@FreeBSD.org Subject: Re: KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread References: <54236CD6.4050807@FreeBSD.org> In-Reply-To: <54236CD6.4050807@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 02:57:20 -0000 On 9/24/14, 8:16 PM, Bryan Drewery wrote: > Hi, > > I've placed 2 reviews out in relation to > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193696: > > Add KASSERT_WARN which will work just like KASSERT except that no panic > will occur. My own expectation would be that any use of it would > eventually be promoted to a full KASSERT. It would only be used where > the impact is not known yet on all hardware/devices. We don't want to > go adding a KASSERT and break boot for a whole class of systems. > > https://reviews.freebsd.org/D829 - KASSERT_WARN > > > Add the KASSERT_WARN to malloc(9) and uma_zalloc_arg(9) to ensure they > are not called from a non-sleepable thread. This is currently violated > by cam, namely xpt_done_td() [see bug 193696]. > > https://reviews.freebsd.org/D830 - Use KASSERT_WARN in malloc(9) and > uma_zalloc_arg(9) > > One flaw of this is that the KASSERT_WARN in malloc(9) is called, prints > to console, continues, and then the uma_zalloc_arg(9) is called and does > the same. I thought perhaps the KASSERT_WARN could only be added in > uma_zalloc_arg(9) for now and later the full KASSERT could be added in > malloc(9), but I think this could miss some cases for memguard and maybe > redzone uses. > > By the way, it was mentioned to me that the interrupt assert may be > wrong but from my understanding the thread is in an interrupt context if > td_intr_nesting_level>0, so the check seems fine to me. > > Example output: > >> ada3: s/n STF605MH1THSXW detached >> KASSERT failed: malloc(M_WAITOK) in no_sleeping context >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe349829a340 >> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe349829a3f0 >> _kassert_panic() at _kassert_panic+0xd7/frame 0xfffffe349829a470 >> malloc() at malloc+0x2e4/frame 0xfffffe349829a4c0 >> g_post_event_x() at g_post_event_x+0x84/frame 0xfffffe349829a510 >> g_post_event() at g_post_event+0x5d/frame 0xfffffe349829a580 >> adacleanup() at adacleanup+0x62/frame 0xfffffe349829a5a0 >> cam_periph_release_locked_buses() at cam_periph_release_locked_buses+0xde/frame 0xfffffe349829aaa0 >> cam_periph_release_locked() at cam_periph_release_locked+0x1b/frame 0xfffffe349829aac0 >> adadone() at adadone+0x26e/frame 0xfffffe349829ab20 >> xpt_done_process() at xpt_done_process+0x3a4/frame 0xfffffe349829ab60 >> xpt_done_td() at xpt_done_td+0x136/frame 0xfffffe349829abb0 >> fork_exit() at fork_exit+0x84/frame 0xfffffe349829abf0 >> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe349829abf0 >> --- trap 0, rip = 0, rsp = 0xfffffe349829acb0, rbp = 0 --- >> KASSERT failed: uma_zalloc_arg(M_WAITOK) in no_sleeping context >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe349829a2d0 >> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe349829a380 >> _kassert_panic() at _kassert_panic+0xd7/frame 0xfffffe349829a400 >> uma_zalloc_arg() at uma_zalloc_arg+0x6c5/frame 0xfffffe349829a470 >> malloc() at malloc+0x1c7/frame 0xfffffe349829a4c0 >> g_post_event_x() at g_post_event_x+0x84/frame 0xfffffe349829a510 >> g_post_event() at g_post_event+0x5d/frame 0xfffffe349829a580 >> adacleanup() at adacleanup+0x62/frame 0xfffffe349829a5a0 >> cam_periph_release_locked_buses() at cam_periph_release_locked_buses+0xde/frame 0xfffffe349829aaa0 >> cam_periph_release_locked() at cam_periph_release_locked+0x1b/frame 0xfffffe349829aac0 >> adadone() at adadone+0x26e/frame 0xfffffe349829ab20 >> xpt_done_process() at xpt_done_process+0x3a4/frame 0xfffffe349829ab60 >> xpt_done_td() at xpt_done_td+0x136/frame 0xfffffe349829abb0 >> fork_exit() at fork_exit+0x84/frame 0xfffffe349829abf0 >> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe349829abf0 >> --- trap 0, rip = 0, rsp = 0xfffffe349829acb0, rbp = 0 --- >> (ada3:ahcich3:0:0:0): Periph destroyed > > Here's another one... > KASSERT failed: malloc(M_WAITOK) in no_sleeping context > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe3509bd7800 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe3509bd78b0 > _kassert_panic() at _kassert_panic+0xd7/frame 0xfffffe3509bd7930 > malloc() at malloc+0x2e4/frame 0xfffffe3509bd7980 > zfs_dbgmsg() at zfs_dbgmsg+0x6d/frame 0xfffffe3509bd7a00 > spa_deadman() at spa_deadman+0x70/frame 0xfffffe3509bd7a30 > softclock_call_cc() at softclock_call_cc+0x19c/frame 0xfffffe3509bd7b10 > softclock() at softclock+0x47/frame 0xfffffe3509bd7b30 > intr_event_execute_handlers() at intr_event_execute_handlers+0x93/frame 0xfffffe3509bd7b70 > ithread_loop() at ithread_loop+0xa6/frame 0xfffffe3509bd7bb0 > fork_exit() at fork_exit+0x84/frame 0xfffffe3509bd7bf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe3509bd7bf0 -- Regards, Bryan Drewery From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 04:19:14 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5784F36; Thu, 25 Sep 2014 04:19:14 +0000 (UTC) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A2017B4E; Thu, 25 Sep 2014 04:19:14 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id ar1so10075927iec.11 for ; Wed, 24 Sep 2014 21:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0Vh2DDjl2iMQdWZteIpnq110lalXz1ave0JXH319eoM=; b=irGZgCriYvltd/wAMkIiTh0AzuuJ+8DHsJxq7ZVMD7lYAF0WqLZ7Hyxnp9RRkImUX4 K5udphiaxzwl22TW6p27EG1zsFEweIEECVcApMtK6xOjBYbvQ1NRRLqloGMOv+rGnz1a VGLUnBuAb3yGdYA15R05MeImHYni568VqZx0wZ8tf57z/R5FDBdDjuA/o1fYlMDK5thc 6O18H6O4HNHwze4/NKl2S6HWpOiefZorGDgKNlvgVb505SGCJSEUs8ehqG6pQud6M4lK HlWANCmGkjRrm0Ir4NYxh3Jmn0FZA2iPEKV6L69RvgBlxICXj1njic7zbkTBiTyX/PDR T/Lw== MIME-Version: 1.0 X-Received: by 10.50.32.10 with SMTP id e10mr18785391igi.7.1411618754120; Wed, 24 Sep 2014 21:19:14 -0700 (PDT) Received: by 10.50.72.69 with HTTP; Wed, 24 Sep 2014 21:19:14 -0700 (PDT) In-Reply-To: References: <54236CD6.4050807@FreeBSD.org> Date: Wed, 24 Sep 2014 21:19:14 -0700 Message-ID: Subject: Re: KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread From: NGie Cooper To: Davide Italiano Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arch@freebsd.org" , Bryan Drewery X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 04:19:15 -0000 On Wed, Sep 24, 2014 at 7:56 PM, Davide Italiano wrote: > On Wed, Sep 24, 2014 at 6:16 PM, Bryan Drewery wrote: >> Hi, >> >> I've placed 2 reviews out in relation to >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193696: >> >> Add KASSERT_WARN which will work just like KASSERT except that no panic >> will occur. My own expectation would be that any use of it would >> eventually be promoted to a full KASSERT. It would only be used where >> the impact is not known yet on all hardware/devices. We don't want to >> go adding a KASSERT and break boot for a whole class of systems. >> >> https://reviews.freebsd.org/D829 - KASSERT_WARN > > FYI, I'm not excited about the idea. If you introduce an assert you > want some invariant to not be violated. If it's violated, there's > something clearly going wrong and you need to stop and think about it. > I guess that in most cases is just better fail early, rather than keep > going with the system in a semi-functional state. Also, please note > that once a KPI is introduced in the kernel, everybody may start > abusing it. > A previous attempt (in my opinion wrong) was made to have KASSERT to > log rather than panic. It actually didn't lead to any benefit, > apparently. FWIW, at least your approach is more fine grained. The probability of hitting bug 193696 is unknown but the potential impact is great, so until most of the code paths are fixed and/or we have enough data to quantify the impact (and the data suggests that the probability is in fact low), it would be unadvisable to replace the KASSERT_WARN Bryan's introducing with a KASSERT. Eventually it should probably turn into a KASSERT. I agree that developers should use KASSERT_WARN sparingly and carefully. Maybe a comment should be added to note that? Thanks! -Garrett From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 07:46:59 2014 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0D79B8E; Thu, 25 Sep 2014 07:46:59 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 4DF85131; Thu, 25 Sep 2014 07:46:58 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s8P7krrW030761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2014 10:46:53 +0300 (EEST) (envelope-from kostik@tom.home) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s8P7krrW030761 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s8P7krJD030760; Thu, 25 Sep 2014 10:46:53 +0300 (EEST) (envelope-from kostik) Date: Thu, 25 Sep 2014 10:46:53 +0300 From: Konstantin Belousov To: Bryan Drewery Subject: Re: KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread Message-ID: <20140925074653.GP8870@kib.kiev.ua> References: <54236CD6.4050807@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54236CD6.4050807@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 07:46:59 -0000 On Wed, Sep 24, 2014 at 08:16:06PM -0500, Bryan Drewery wrote: > By the way, it was mentioned to me that the interrupt assert may be > wrong but from my understanding the thread is in an interrupt context if > td_intr_nesting_level>0, so the check seems fine to me. It is wrong not due to the test for the interrupt level, but because you must not call malloc(9) from the interrupt context at all, regardless of flags. At very least, it causes recursion on the malloc/uma locks, but also it should damage the uma state. From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 15:30:43 2014 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A9CB4B8 for ; Thu, 25 Sep 2014 15:30:43 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 639CFD91 for ; Thu, 25 Sep 2014 15:30:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s8PFUhsf085013 for ; Thu, 25 Sep 2014 15:30:43 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s8PFUhYv085012 for arch@FreeBSD.org; Thu, 25 Sep 2014 15:30:43 GMT (envelope-from bdrewery) Received: (qmail 55550 invoked from network); 25 Sep 2014 10:30:38 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 25 Sep 2014 10:30:38 -0500 Message-ID: <54243510.7090009@FreeBSD.org> Date: Thu, 25 Sep 2014 10:30:24 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread References: <54236CD6.4050807@FreeBSD.org> <20140925074653.GP8870@kib.kiev.ua> In-Reply-To: <20140925074653.GP8870@kib.kiev.ua> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PLqg260PPcR5Pj9vMN99dXkufH61t4nL2" Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 15:30:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PLqg260PPcR5Pj9vMN99dXkufH61t4nL2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/25/2014 2:46 AM, Konstantin Belousov wrote: > On Wed, Sep 24, 2014 at 08:16:06PM -0500, Bryan Drewery wrote: >> By the way, it was mentioned to me that the interrupt assert may be >> wrong but from my understanding the thread is in an interrupt context = if >> td_intr_nesting_level>0, so the check seems fine to me. >=20 > It is wrong not due to the test for the interrupt level, but because > you must not call malloc(9) from the interrupt context at all, regardle= ss > of flags. At very least, it causes recursion on the malloc/uma locks, > but also it should damage the uma state. Ah. I understand now, the check for M_WAITOK is wrong, the KASSERT needs to move out of that. --=20 Regards, Bryan Drewery --PLqg260PPcR5Pj9vMN99dXkufH61t4nL2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJUJDUWAAoJEDXXcbtuRpfPJ0sH/3fWPG9KrydXujjQtVZLUIol coibag1N5CdrMkSb9qpWId3TrPcuzZiE448snxXnpuxSyorgjFje+52qRc4ukPva 4Pl9LVRt2WsXdf8pLP9Q4HmxdEN0ple+cw8zkN0e33qngcG0hJAgGdNQhkF0PV1H 6urdrR1xvJLf3ZMpL0WQd8RHh6y0vxI+RkyOSL+52mnKweygDxGfU0UeseSqJwzC mC0MZ9sAXSXKFvF2V5rTnPLeZU0RWvW6KPCu7f93yS1eyT8zJ3EpTqslVN7C8Twx xD/jV8N9vgirMejEyrUTKBgwin3pkdu6dNqa6pxmI8FfXc4ilEq88UgHHhp31q8= =oZA2 -----END PGP SIGNATURE----- --PLqg260PPcR5Pj9vMN99dXkufH61t4nL2-- From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 15:48:07 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9BFEC81 for ; Thu, 25 Sep 2014 15:48:07 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 A9F22F89 for ; Thu, 25 Sep 2014 15:48:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s8PFm7u2091496 for ; Thu, 25 Sep 2014 15:48:07 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s8PFm7P4091495 for freebsd-arch@freebsd.org; Thu, 25 Sep 2014 15:48:07 GMT (envelope-from bdrewery) Received: (qmail 92384 invoked from network); 25 Sep 2014 10:48:06 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 25 Sep 2014 10:48:06 -0500 Message-ID: <5424392D.9030201@FreeBSD.org> Date: Thu, 25 Sep 2014 10:47:57 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread References: <54236CD6.4050807@FreeBSD.org> In-Reply-To: OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jiHQEwHe0AgVBGmR73xkDD8jHW6UADXQr" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 15:48:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jiHQEwHe0AgVBGmR73xkDD8jHW6UADXQr Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/24/2014 9:56 PM, Davide Italiano wrote: > On Wed, Sep 24, 2014 at 6:16 PM, Bryan Drewery w= rote: >> Hi, >> >> I've placed 2 reviews out in relation to >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193696: >> >> Add KASSERT_WARN which will work just like KASSERT except that no pani= c >> will occur. My own expectation would be that any use of it would >> eventually be promoted to a full KASSERT. It would only be used where= >> the impact is not known yet on all hardware/devices. We don't want to= >> go adding a KASSERT and break boot for a whole class of systems. >> >> https://reviews.freebsd.org/D829 - KASSERT_WARN >> >=20 > FYI, I'm not excited about the idea. If you introduce an assert you > want some invariant to not be violated. If it's violated, there's > something clearly going wrong and you need to stop and think about it. > I guess that in most cases is just better fail early, rather than keep > going with the system in a semi-functional state. Also, please note > that once a KPI is introduced in the kernel, everybody may start > abusing it. > A previous attempt (in my opinion wrong) was made to have KASSERT to > log rather than panic. It actually didn't lead to any benefit, > apparently. FWIW, at least your approach is more fine grained. >=20 > -- > Davide I would be comfortable adding it in as a full KASSERT (and not bringing in KASSERT_WARN) if other people test the patch in https://reviews.freebsd.org/D830 and change them to KASSERT. If the fallout is not too bad then we can commit the real assert. --=20 Regards, Bryan Drewery --jiHQEwHe0AgVBGmR73xkDD8jHW6UADXQr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJUJDktAAoJEDXXcbtuRpfPjRwH/3IoiP7zk2EjJIVvHwoP403z zZkRZmGOvu9Fd2uMH3+Nx042RI1TXLMtoKvrorPo94nLmYRyusj15VMqwY+SWKGc AgQlULUC5Q9UWRaOS4W1zp4OtM4URYO2nvN3pY3IYDbGhc620nnN72GUDFUKsYKr w8WX9jxK4r1vEKksNG919DjBOjS821XxOSmgfQlBS3W4lmMVIfRCCZTfLUeUJWIA 1DJFOxLzy9bFqzLqOoLE1MLrwigung4gKdGXzd37ioFK63DR5assZHTJ05Znx0cw EySgX2vRkHiIy4G5R/+FBn2C7rwr3lAf4sDGSzt1TjN9okwEIhkpyelOHju9DgU= =Xy6B -----END PGP SIGNATURE----- --jiHQEwHe0AgVBGmR73xkDD8jHW6UADXQr-- From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 16:15:01 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 396D95A2; Thu, 25 Sep 2014 16:15:01 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A2E199C3; Thu, 25 Sep 2014 16:15:00 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id a1so7818713wgh.5 for ; Thu, 25 Sep 2014 09:14:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZnxAR8YQYefbeAInVbmUkWd8j2IfbpYszgJQLmkOprQ=; b=Ett4t7Pyy5d/O99L06Wdrm4RHE8vUcMmWLOm9TUEhtPvF65yP3qOGvigXEd24jYaYN m7GPqfv1GejsEGjt/mv85BpDKLz8ELEin0zT1TTVKmql4vGbMn37x3IHPKggHxl3y1a8 ZUnCIV0TKGnUCskx4j/D+o6jyz3BIZzq5EC92TshEK8Smy5M9mCrcjv9dJhP7IhTDVtP qP71NCtfLCv8ZbXeM8YzstgEcE+MaiIAJ6GFeDKK0hajpaXNBlpl0XAZ2fkro9aSw4Xw rNGvexSXDesjTK1FmqQcbtsF9eNrASsO4v3cumf37TJ6PZag9gzYbTkNv/i/zz7Btfav cU2Q== MIME-Version: 1.0 X-Received: by 10.180.9.73 with SMTP id x9mr20052765wia.20.1411661698802; Thu, 25 Sep 2014 09:14:58 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Thu, 25 Sep 2014 09:14:58 -0700 (PDT) In-Reply-To: <5424392D.9030201@FreeBSD.org> References: <54236CD6.4050807@FreeBSD.org> <5424392D.9030201@FreeBSD.org> Date: Thu, 25 Sep 2014 09:14:58 -0700 X-Google-Sender-Auth: -425onM09PD7em5kHnAAN6UAwwg Message-ID: Subject: Re: KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread From: Adrian Chadd To: Bryan Drewery Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 16:15:01 -0000 Hi, Please bring in KASSERT_WARN(). I'm grown up enough to use KASSERT_WARN() along with handling the invariant check myself in code. Having KASSERT_WARN() means I can add in this rather than printf()s or device_printf()'s with various knobs to remove it. (This is absolutely _not_ the "should KASSERT() optionally just log" argument. I'm not going to get into that a second time.) -a On 25 September 2014 08:47, Bryan Drewery wrote: > On 9/24/2014 9:56 PM, Davide Italiano wrote: >> On Wed, Sep 24, 2014 at 6:16 PM, Bryan Drewery wrote: >>> Hi, >>> >>> I've placed 2 reviews out in relation to >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193696: >>> >>> Add KASSERT_WARN which will work just like KASSERT except that no panic >>> will occur. My own expectation would be that any use of it would >>> eventually be promoted to a full KASSERT. It would only be used where >>> the impact is not known yet on all hardware/devices. We don't want to >>> go adding a KASSERT and break boot for a whole class of systems. >>> >>> https://reviews.freebsd.org/D829 - KASSERT_WARN >>> >> >> FYI, I'm not excited about the idea. If you introduce an assert you >> want some invariant to not be violated. If it's violated, there's >> something clearly going wrong and you need to stop and think about it. >> I guess that in most cases is just better fail early, rather than keep >> going with the system in a semi-functional state. Also, please note >> that once a KPI is introduced in the kernel, everybody may start >> abusing it. >> A previous attempt (in my opinion wrong) was made to have KASSERT to >> log rather than panic. It actually didn't lead to any benefit, >> apparently. FWIW, at least your approach is more fine grained. >> >> -- >> Davide > > I would be comfortable adding it in as a full KASSERT (and not bringing > in KASSERT_WARN) if other people test the patch in > https://reviews.freebsd.org/D830 and change them to KASSERT. If the > fallout is not too bad then we can commit the real assert. > > -- > Regards, > Bryan Drewery > From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 16:31:05 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B79F9B7 for ; Thu, 25 Sep 2014 16:31:05 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 E505DB17 for ; Thu, 25 Sep 2014 16:31:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s8PGV4HI008146 for ; Thu, 25 Sep 2014 16:31:04 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s8PGV4Dc008145 for freebsd-arch@freebsd.org; Thu, 25 Sep 2014 16:31:04 GMT (envelope-from bdrewery) Received: (qmail 37536 invoked from network); 25 Sep 2014 11:30:59 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 25 Sep 2014 11:30:59 -0500 Message-ID: <5424433A.20809@FreeBSD.org> Date: Thu, 25 Sep 2014 11:30:50 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread References: <54236CD6.4050807@FreeBSD.org> <5424392D.9030201@FreeBSD.org> In-Reply-To: OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V60Dxl31Sv7EgWsAKel1WTptM704eex7J" Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 16:31:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --V60Dxl31Sv7EgWsAKel1WTptM704eex7J Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 9/25/2014 11:14 AM, Adrian Chadd wrote: > Hi, >=20 > Please bring in KASSERT_WARN(). >=20 > I'm grown up enough to use KASSERT_WARN() along with handling the > invariant check myself in code. Having KASSERT_WARN() means I can add > in this rather than printf()s or device_printf()'s with various knobs > to remove it. >=20 > (This is absolutely _not_ the "should KASSERT() optionally just log" > argument. I'm not going to get into that a second time.) Agreed on this 2nd point. I am against that. Plus we already have debug.kassert.log_panic_at to effectively do that. >=20 >=20 > -a >=20 >=20 --=20 Regards, Bryan Drewery --V60Dxl31Sv7EgWsAKel1WTptM704eex7J Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJUJEM6AAoJEDXXcbtuRpfPA64H/0nIdIOMWU/sXHg8W2yW/nXQ mzf/odn6i4a+nXrevhAFwZsgmSQ0lEBF8UIq1hMSCnjuqz8Lsg8htF8ixfO5sqHn oGPKZPPq9c2SIt4VgeULLZ8RDlsujq6L2HehilFefuHuzgDV9Qf45bBgSSpBnZlS 82bL8qofK7B4gkvR+gHJa7I3iNO1jFiEcuRt29q4u7hL1sIg8XHWCgz4RlrtMskc HMxxxAuPrwtN27U8TQI3KKB1SIyNvD66/gH+Qzix/gwOfvhX3rrIQ+J5s6mfJIlS 7UVM5+6cCBtSBVaZupWKuVY7ToHXYx9dtrXQ9pE6vo3CDZKtmEUQdDrINIBOFdM= =Y0sM -----END PGP SIGNATURE----- --V60Dxl31Sv7EgWsAKel1WTptM704eex7J-- From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 17:12:15 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA3B5460; Thu, 25 Sep 2014 17:12:14 +0000 (UTC) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B0C27C9; Thu, 25 Sep 2014 17:12:14 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id rd3so659757pab.34 for ; Thu, 25 Sep 2014 10:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=jMnAu3VXgEAbhUbqOZFpSSWoylmkGeHBrd/hvopOcP0=; b=nWFBkwq0Qx9Atjx9XDZPi7ZsgZ5Asls5WBz6bKjIXaN9hsT6fzsiKS2cA3BzJFC3Qa 42X2nYk3u2sfHaFDjcCcjx8oST8nppTqrnvJeMxrOzltKVS47eUgpK5aVtfYKvZvae0b B/tii36YVIRHmTJqbT31WwW3eqCdXxWekR1p6uz0UyteCYA7QEBpIsgfdhlmyTcmZPsy XRpGOmlsClyRfMjyaiE3KaYz0hTJNUlybL7WNdxbZsr8yvQBbTaV6f3nmqDfxKBbwLTv 16Y8We3cuCjgjRtL2ysdIQ5jT7GdtrCTiE44vkDBnJZetqfeAtpq5XnsfxMdmMX867+h E/Cw== X-Received: by 10.66.240.197 with SMTP id wc5mr21126412pac.87.1411665134325; Thu, 25 Sep 2014 10:12:14 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPSA id ra7sm2736797pab.22.2014.09.25.10.12.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Sep 2014 10:12:13 -0700 (PDT) Sender: Navdeep Parhar Message-ID: <54244CEB.2010204@FreeBSD.org> Date: Thu, 25 Sep 2014 10:12:11 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Adrian Chadd , Bryan Drewery Subject: Re: KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread References: <54236CD6.4050807@FreeBSD.org> <5424392D.9030201@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 17:12:15 -0000 On 09/25/14 09:14, Adrian Chadd wrote: > Hi, > > Please bring in KASSERT_WARN(). > > I'm grown up enough to use KASSERT_WARN() along with handling the > invariant check myself in code. Having KASSERT_WARN() means I can add > in this rather than printf()s or device_printf()'s with various knobs > to remove it. > > (This is absolutely _not_ the "should KASSERT() optionally just log" > argument. I'm not going to get into that a second time.) Yeah, let's avoid a repeat. You could call it KWARN (no form of "assert" anywhere in its name) to sidestep any discussion on whether invariants and assertions are ironclad or not. It's easier/shorter to type in as well. Regards, Navdeep > > > -a > > > On 25 September 2014 08:47, Bryan Drewery wrote: >> On 9/24/2014 9:56 PM, Davide Italiano wrote: >>> On Wed, Sep 24, 2014 at 6:16 PM, Bryan Drewery wrote: >>>> Hi, >>>> >>>> I've placed 2 reviews out in relation to >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193696: >>>> >>>> Add KASSERT_WARN which will work just like KASSERT except that no panic >>>> will occur. My own expectation would be that any use of it would >>>> eventually be promoted to a full KASSERT. It would only be used where >>>> the impact is not known yet on all hardware/devices. We don't want to >>>> go adding a KASSERT and break boot for a whole class of systems. >>>> >>>> https://reviews.freebsd.org/D829 - KASSERT_WARN >>>> >>> >>> FYI, I'm not excited about the idea. If you introduce an assert you >>> want some invariant to not be violated. If it's violated, there's >>> something clearly going wrong and you need to stop and think about it. >>> I guess that in most cases is just better fail early, rather than keep >>> going with the system in a semi-functional state. Also, please note >>> that once a KPI is introduced in the kernel, everybody may start >>> abusing it. >>> A previous attempt (in my opinion wrong) was made to have KASSERT to >>> log rather than panic. It actually didn't lead to any benefit, >>> apparently. FWIW, at least your approach is more fine grained. >>> >>> -- >>> Davide >> >> I would be comfortable adding it in as a full KASSERT (and not bringing >> in KASSERT_WARN) if other people test the patch in >> https://reviews.freebsd.org/D830 and change them to KASSERT. If the >> fallout is not too bad then we can commit the real assert. >> >> -- >> Regards, >> Bryan Drewery >> > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 17:51:18 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 080192E5; Thu, 25 Sep 2014 17:51:18 +0000 (UTC) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B9D7798; Thu, 25 Sep 2014 17:51:16 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id z12so12898561lbi.22 for ; Thu, 25 Sep 2014 10:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LvsYcvcOzUXCVb6/Ux/xb8aWyyQHmus2R6syHLZNVsI=; b=aNM8DOe6PMvJJxcyyuknwYArJT4lph1ECgE9d9h2xwwEn5aQhCDtKU/Z/oatjG14Fw W+pmEqmUFO5dCrb+4ILakSkwgijwHrIqDlFkGwbrxAYFd3XmSV/QKENNwl3P3ym8SMUJ MPva3ndi/N6r3mbRIjM/+Dh4PZROzc/mDpx+CV3UhGfxbqyuScoTC8Yb50PxXhBOnQkF mb1dXhExUibPutVW4WPHoE68Y7hzN6WZogp8WoVFYgakQXTvjFhbcCeNkLGnEfzRqXpp ON7XDcBEWqTWkObk0hzc2Ra42d2dXnJnyLwgLmIz7sWL7fNinbY8uaL8Ur9dq9lyCRov 7anA== MIME-Version: 1.0 X-Received: by 10.113.3.130 with SMTP id bw2mr215005lbd.39.1411667474974; Thu, 25 Sep 2014 10:51:14 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.25.207.74 with HTTP; Thu, 25 Sep 2014 10:51:14 -0700 (PDT) In-Reply-To: References: <54236CD6.4050807@FreeBSD.org> <5424392D.9030201@FreeBSD.org> Date: Thu, 25 Sep 2014 10:51:14 -0700 X-Google-Sender-Auth: 5sWxiJdl6Dc1dmPbD80BSIfjbro Message-ID: Subject: Re: KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread From: Davide Italiano To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arch@freebsd.org" , Bryan Drewery X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 17:51:18 -0000 On Thu, Sep 25, 2014 at 9:14 AM, Adrian Chadd wrote: > Hi, > > Please bring in KASSERT_WARN(). > > I'm grown up enough to use KASSERT_WARN() along with handling the > invariant check myself in code. Having KASSERT_WARN() means I can add > in this rather than printf()s or device_printf()'s with various knobs > to remove it. > > (This is absolutely _not_ the "should KASSERT() optionally just log" > argument. I'm not going to get into that a second time.) > > If you put a KASSERT() inside your code -- probably you should be careful enough to put that iff you're sure that it should be always verified. No exceptions. People tend to be very lazy (including me). I don't expect everybody diligently upgrading KASSERT_WARN to KASSERT. So KASSERT_WARN start becoming more and more widespread, and people realize all of these need to be upgraded to KASSERT or removed. This generally happens after years. Yet. Another. Crusade. There's a lot of work in the kernel to remove old/wrong/naive KPI from the kernel. jhb@ is looking at timeout()-> callout() conversion. I'm personally looking at dev_clone() removal. There are a lot of other examples. Adding KASSERT_WARN is a step backward, not a step forward, IMHO. That said, if you want to pollute the kernel, fine. I expressed my opinion, and I'm personally not happy about this, but I never stated I'm gonna stop you from doing that. Thanks, -- Davide From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 18:09:42 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0FF479B6; Thu, 25 Sep 2014 18:09:42 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (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 D219099B; Thu, 25 Sep 2014 18:09:41 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XXDTx-000CaH-Ji; Thu, 25 Sep 2014 18:09:33 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s8PI9WgM003641; Thu, 25 Sep 2014 12:09:32 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+6omboXhQ6wXqgHM4i62XN X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread From: Ian Lepore To: Davide Italiano In-Reply-To: References: <54236CD6.4050807@FreeBSD.org> <5424392D.9030201@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Sep 2014 12:09:31 -0600 Message-ID: <1411668571.66615.247.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , Bryan Drewery , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 18:09:42 -0000 On Thu, 2014-09-25 at 10:51 -0700, Davide Italiano wrote: > On Thu, Sep 25, 2014 at 9:14 AM, Adrian Chadd wrote: > > Hi, > > > > Please bring in KASSERT_WARN(). > > > > I'm grown up enough to use KASSERT_WARN() along with handling the > > invariant check myself in code. Having KASSERT_WARN() means I can add > > in this rather than printf()s or device_printf()'s with various knobs > > to remove it. > > > > (This is absolutely _not_ the "should KASSERT() optionally just log" > > argument. I'm not going to get into that a second time.) > > > > > > If you put a KASSERT() inside your code -- probably you should be > careful enough to put that iff you're sure that it should be always > verified. No exceptions. > People tend to be very lazy (including me). I don't expect everybody > diligently upgrading KASSERT_WARN to KASSERT. So KASSERT_WARN start > becoming more and more widespread, and people realize all of these > need to be upgraded to KASSERT or removed. This generally happens > after years. Yet. Another. Crusade. > There's a lot of work in the kernel to remove old/wrong/naive KPI > from the kernel. jhb@ is looking at timeout()-> callout() conversion. > I'm personally looking at dev_clone() removal. There are a lot of > other examples. > Adding KASSERT_WARN is a step backward, not a step forward, IMHO. > That said, if you want to pollute the kernel, fine. I expressed my > opinion, and I'm personally not happy about this, but I never stated > I'm gonna stop you from doing that. > > Thanks, > > -- IMO, this entire argument is ridiculous. Some conditions are so insane that you've got to stop immediately rather than make things worse. Other conditions indicate problems, but the code can recover or otherwise continue to operate safely. Trying to define every possible anomalous condition as either fatal or not worth mentioning is insane. Everyone is free to write code such as #ifdef INVARIANTS if (some_condition) printf("whatever warning\n"); #endif So let's be clear here: the objections are to spelling that code sequence KASSERT_WARN. If you object, please explain what's wrong with that spelling and how you would prefer it to be spelled. -- Ian From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 18:16:14 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0DD98BA4; Thu, 25 Sep 2014 18:16:14 +0000 (UTC) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 026A9A81; Thu, 25 Sep 2014 18:16:12 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id pn19so13174409lab.36 for ; Thu, 25 Sep 2014 11:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=zYNZSzOC0mpiTYeWopuRIv5Tt1wIZTQTF2TcgBjmNFk=; b=DwcmQ2uVgaFReshYmIDEK0OwCI1EhpBKYNaQ47/VFM7b8FC6CQ82JxLmIHI/TDAXr3 /j1fi8s4OEwDuA+6Eqmf82nIV2w4nBisl3iTqGjUerAbWvSnmOHub7uPRauim69KhBDn g8VmJUAign+vJEkjBLLZQBfsbCYp8fbVZs52EpJKsl10KgWf0YL2aKauTwPswpYF+8tn 9lx+wIqsnkrZfV1L/N9YRfPZ5iY7NgbvoTGBgfPRKQPJvLQwVEVB//bx6UAn+GmaZ+u6 bG2yaCZ0KIwQGbxOR/lBNqG7bxpmYDdWI0EuIANAlpT+o8D0yJzmiDDrWwADcYQyfIMp hE4w== MIME-Version: 1.0 X-Received: by 10.152.88.97 with SMTP id bf1mr15156788lab.58.1411668970822; Thu, 25 Sep 2014 11:16:10 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.25.207.74 with HTTP; Thu, 25 Sep 2014 11:16:10 -0700 (PDT) In-Reply-To: <1411668571.66615.247.camel@revolution.hippie.lan> References: <54236CD6.4050807@FreeBSD.org> <5424392D.9030201@FreeBSD.org> <1411668571.66615.247.camel@revolution.hippie.lan> Date: Thu, 25 Sep 2014 11:16:10 -0700 X-Google-Sender-Auth: nX_F4wYQsxQMLbkLHQwHHGqEWCA Message-ID: Subject: Re: KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread From: Davide Italiano To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: Adrian Chadd , Bryan Drewery , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 18:16:14 -0000 On Thu, Sep 25, 2014 at 11:09 AM, Ian Lepore wrote: > On Thu, 2014-09-25 at 10:51 -0700, Davide Italiano wrote: >> On Thu, Sep 25, 2014 at 9:14 AM, Adrian Chadd wrote: >> > Hi, >> > >> > Please bring in KASSERT_WARN(). >> > >> > I'm grown up enough to use KASSERT_WARN() along with handling the >> > invariant check myself in code. Having KASSERT_WARN() means I can add >> > in this rather than printf()s or device_printf()'s with various knobs >> > to remove it. >> > >> > (This is absolutely _not_ the "should KASSERT() optionally just log" >> > argument. I'm not going to get into that a second time.) >> > >> > >> >> If you put a KASSERT() inside your code -- probably you should be >> careful enough to put that iff you're sure that it should be always >> verified. No exceptions. >> People tend to be very lazy (including me). I don't expect everybody >> diligently upgrading KASSERT_WARN to KASSERT. So KASSERT_WARN start >> becoming more and more widespread, and people realize all of these >> need to be upgraded to KASSERT or removed. This generally happens >> after years. Yet. Another. Crusade. >> There's a lot of work in the kernel to remove old/wrong/naive KPI >> from the kernel. jhb@ is looking at timeout()-> callout() conversion. >> I'm personally looking at dev_clone() removal. There are a lot of >> other examples. >> Adding KASSERT_WARN is a step backward, not a step forward, IMHO. >> That said, if you want to pollute the kernel, fine. I expressed my >> opinion, and I'm personally not happy about this, but I never stated >> I'm gonna stop you from doing that. >> >> Thanks, >> >> -- > > IMO, this entire argument is ridiculous. Some conditions are so insane > that you've got to stop immediately rather than make things worse. > Other conditions indicate problems, but the code can recover or > otherwise continue to operate safely. Trying to define every possible > anomalous condition as either fatal or not worth mentioning is insane. > > Everyone is free to write code such as > > #ifdef INVARIANTS > if (some_condition) > printf("whatever warning\n"); > #endif > > So let's be clear here: the objections are to spelling that code > sequence KASSERT_WARN. If you object, please explain what's wrong with > that spelling and how you would prefer it to be spelled. > > -- Ian > > Take the assert out of the name. Call it DEBUG_WARN, or something else if you like. assert as a pretty *clear* and specific semantic, no need to mess around with it. Thanks, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 18:22:53 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B808CC4; Thu, 25 Sep 2014 18:22:53 +0000 (UTC) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C6E47B40; Thu, 25 Sep 2014 18:22:51 +0000 (UTC) Received: by mail-la0-f44.google.com with SMTP id gi9so2859888lab.31 for ; Thu, 25 Sep 2014 11:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=o63mowZLNH6MkCcqsMexxieCc0BqrL9kJQuzOYTlZyU=; b=L+Je7u5WS1t+P/fofMVuqAb3m9U5kjH/8SAQHowfp7Ny6IZGb/HtPhGFVrB22oUT/X HHuLZCFCv2Oax7yFzrrwFtSlXQ6VJEgioNf9Su0QHABzIGvThMwIyaXIWtCvG2Q98446 3KLqyLcI/I8cRj5GvgAdNMdscWgnUVrf5F4PyqRrv4UVqDkSQamctq6NGA3q9ZBOERbE s0FzC3n4eVo7CEmYpjt6XVo5dPtxDd8z/iAdLbTCfquaB3bcLNwAyr1R10C7yA2giCMs ErKOZYepDmcwlT8MHSVYffHOtInMrwx3daBGfE+zP+DZWNh+Lw2yShcGnEoY96bFEj76 1JeA== MIME-Version: 1.0 X-Received: by 10.112.201.42 with SMTP id jx10mr4671220lbc.101.1411669369467; Thu, 25 Sep 2014 11:22:49 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.25.15.29 with HTTP; Thu, 25 Sep 2014 11:22:49 -0700 (PDT) In-Reply-To: References: <54236CD6.4050807@FreeBSD.org> <5424392D.9030201@FreeBSD.org> <1411668571.66615.247.camel@revolution.hippie.lan> Date: Thu, 25 Sep 2014 11:22:49 -0700 X-Google-Sender-Auth: I-Quc5vswDLjrMoyU5uH5pE2ao4 Message-ID: Subject: Re: KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread From: Justin Hibbits To: Davide Italiano Content-Type: text/plain; charset=UTF-8 Cc: Adrian Chadd , "freebsd-arch@freebsd.org" , Ian Lepore , Bryan Drewery X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 18:22:53 -0000 On Thu, Sep 25, 2014 at 11:16 AM, Davide Italiano wrote: > On Thu, Sep 25, 2014 at 11:09 AM, Ian Lepore wrote: >> On Thu, 2014-09-25 at 10:51 -0700, Davide Italiano wrote: >>> On Thu, Sep 25, 2014 at 9:14 AM, Adrian Chadd wrote: >>> > Hi, >>> > >>> > Please bring in KASSERT_WARN(). >>> > >>> > I'm grown up enough to use KASSERT_WARN() along with handling the >>> > invariant check myself in code. Having KASSERT_WARN() means I can add >>> > in this rather than printf()s or device_printf()'s with various knobs >>> > to remove it. >>> > >>> > (This is absolutely _not_ the "should KASSERT() optionally just log" >>> > argument. I'm not going to get into that a second time.) >>> > >>> > >>> >>> If you put a KASSERT() inside your code -- probably you should be >>> careful enough to put that iff you're sure that it should be always >>> verified. No exceptions. >>> People tend to be very lazy (including me). I don't expect everybody >>> diligently upgrading KASSERT_WARN to KASSERT. So KASSERT_WARN start >>> becoming more and more widespread, and people realize all of these >>> need to be upgraded to KASSERT or removed. This generally happens >>> after years. Yet. Another. Crusade. >>> There's a lot of work in the kernel to remove old/wrong/naive KPI >>> from the kernel. jhb@ is looking at timeout()-> callout() conversion. >>> I'm personally looking at dev_clone() removal. There are a lot of >>> other examples. >>> Adding KASSERT_WARN is a step backward, not a step forward, IMHO. >>> That said, if you want to pollute the kernel, fine. I expressed my >>> opinion, and I'm personally not happy about this, but I never stated >>> I'm gonna stop you from doing that. >>> >>> Thanks, >>> >>> -- >> >> IMO, this entire argument is ridiculous. Some conditions are so insane >> that you've got to stop immediately rather than make things worse. >> Other conditions indicate problems, but the code can recover or >> otherwise continue to operate safely. Trying to define every possible >> anomalous condition as either fatal or not worth mentioning is insane. >> >> Everyone is free to write code such as >> >> #ifdef INVARIANTS >> if (some_condition) >> printf("whatever warning\n"); >> #endif >> >> So let's be clear here: the objections are to spelling that code >> sequence KASSERT_WARN. If you object, please explain what's wrong with >> that spelling and how you would prefer it to be spelled. >> >> -- Ian >> >> > > Take the assert out of the name. Call it DEBUG_WARN, or something else > if you like. > assert as a pretty *clear* and specific semantic, no need to mess > around with it. > > Thanks, > > -- > Davide I like my bikeshed a nice royal blue. At a previous job we used ASSERT and VERIFY macros. VERIFY was comparable to this (warn if condition not met, don't panic), so how about KVERIFY() (I'll also support KWARN, but I think KVERIFY() conveys a better message by name). - Justin From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 18:23:38 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C9B9D7C for ; Thu, 25 Sep 2014 18:23:38 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 7729CB54 for ; Thu, 25 Sep 2014 18:23:38 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s8PINca7045277 for ; Thu, 25 Sep 2014 18:23:38 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s8PINcMc045271 for freebsd-arch@freebsd.org; Thu, 25 Sep 2014 18:23:38 GMT (envelope-from bdrewery) Received: (qmail 92705 invoked from network); 25 Sep 2014 13:23:36 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 25 Sep 2014 13:23:36 -0500 Message-ID: <54245D9F.6080502@FreeBSD.org> Date: Thu, 25 Sep 2014 13:23:27 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Davide Italiano , Ian Lepore Subject: Re: KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread References: <54236CD6.4050807@FreeBSD.org> <5424392D.9030201@FreeBSD.org> <1411668571.66615.247.camel@revolution.hippie.lan> In-Reply-To: OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7lsX8KOIoNVoRLafMnHXkHJ3d1BQrVab7" Cc: Adrian Chadd , "freebsd-arch@freebsd.org" , Bryan Drewery X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 18:23:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7lsX8KOIoNVoRLafMnHXkHJ3d1BQrVab7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/25/2014 1:16 PM, Davide Italiano wrote: > On Thu, Sep 25, 2014 at 11:09 AM, Ian Lepore wrote: >> On Thu, 2014-09-25 at 10:51 -0700, Davide Italiano wrote: >>> On Thu, Sep 25, 2014 at 9:14 AM, Adrian Chadd wr= ote: >>>> Hi, >>>> >>>> Please bring in KASSERT_WARN(). >>>> >>>> I'm grown up enough to use KASSERT_WARN() along with handling the >>>> invariant check myself in code. Having KASSERT_WARN() means I can ad= d >>>> in this rather than printf()s or device_printf()'s with various knob= s >>>> to remove it. >>>> >>>> (This is absolutely _not_ the "should KASSERT() optionally just log"= >>>> argument. I'm not going to get into that a second time.) >>>> >>>> >>> >>> If you put a KASSERT() inside your code -- probably you should be >>> careful enough to put that iff you're sure that it should be always >>> verified. No exceptions. >>> People tend to be very lazy (including me). I don't expect everybody >>> diligently upgrading KASSERT_WARN to KASSERT. So KASSERT_WARN start >>> becoming more and more widespread, and people realize all of these >>> need to be upgraded to KASSERT or removed. This generally happens >>> after years. Yet. Another. Crusade. >>> There's a lot of work in the kernel to remove old/wrong/naive KPI >>> from the kernel. jhb@ is looking at timeout()-> callout() conversion.= >>> I'm personally looking at dev_clone() removal. There are a lot of >>> other examples. >>> Adding KASSERT_WARN is a step backward, not a step forward, IMHO. >>> That said, if you want to pollute the kernel, fine. I expressed my >>> opinion, and I'm personally not happy about this, but I never stated >>> I'm gonna stop you from doing that. >>> >>> Thanks, >>> >>> -- >> >> IMO, this entire argument is ridiculous. Some conditions are so insan= e >> that you've got to stop immediately rather than make things worse. >> Other conditions indicate problems, but the code can recover or >> otherwise continue to operate safely. Trying to define every possible= >> anomalous condition as either fatal or not worth mentioning is insane.= >> >> Everyone is free to write code such as >> >> #ifdef INVARIANTS >> if (some_condition) >> printf("whatever warning\n"); >> #endif >> >> So let's be clear here: the objections are to spelling that code >> sequence KASSERT_WARN. If you object, please explain what's wrong wit= h >> that spelling and how you would prefer it to be spelled. >> >> -- Ian >> >> >=20 > Take the assert out of the name. Call it DEBUG_WARN, or something else > if you like. > assert as a pretty *clear* and specific semantic, no need to mess > around with it. >=20 > Thanks, >=20 I like the suggested KWARN from earlier. --=20 Regards, Bryan Drewery --7lsX8KOIoNVoRLafMnHXkHJ3d1BQrVab7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJUJF2fAAoJEDXXcbtuRpfPSSkIAMdd1y+gs7P3zer01dSe6IGo wYFFEJGCTZNf7pWiJK4HWYGKWqPeBLKDmA8ZUbrArETD2poBMlg/Y/4C9vmZcsx/ BXdC7yA4ovdg8au082DLBoxnXqo4/zMLB8dqJWiKISFyIQ985+vEL78tGp1jQVau JN0hEcwgQE3ZoKIfjV/C0uFaritmhMHx+cKhkp3/Gy1CNe29QsjbHAQ+Io1OWdcP 6jpI4Ea8HqabQ9gGChZM59eduDk/4m5glORW/61V7gPSjIz9AxlHfdp9JWWOkgd2 Tyh26HxK3VcWawktPb499atR4Rbk3TRHsbKezQlCsyaFP+JuJ62pTsboK71bWKw= =hJAf -----END PGP SIGNATURE----- --7lsX8KOIoNVoRLafMnHXkHJ3d1BQrVab7-- From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 18:31:45 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF1517A; Thu, 25 Sep 2014 18:31:44 +0000 (UTC) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 772C7C41; Thu, 25 Sep 2014 18:31:43 +0000 (UTC) Received: by mail-lb0-f170.google.com with SMTP id n15so1437061lbi.15 for ; Thu, 25 Sep 2014 11:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oWfi+gITm3ANQ9NgkcojSr+H/516WMV1OB1KIJX/7K0=; b=TjJfq+leWSTjAHUWNk62j0ilwtghZXcHWKKUUWSzeRfES/zeb+p1TGES8kwUuJq5j4 k0ricTRC+yeXpCnFCnUscdT8mLWijsVjSBO0lL2u+zt/fbPllqW8MR9XeyS0N+Zl911+ Enl67EqXDGvzyj2E1Th1bKwxzicsn+tXtPpSiPLDOWcQ7b1vAYe/9I2QqzBvF2Y46wTx CF+d0vrU6QmggVwjAjyNgRDqNCvLqpHIrc77mLPZiT1AQHcdSX1I9ZiAfmPCFQDhVM6M uYOPrTOQeHQ5U2ChUDfnvzLP5qhyGa7lYKrECBaNAI7dkqJG21uQZRBWO3Xg/gckk8Jb 3JBQ== MIME-Version: 1.0 X-Received: by 10.152.9.37 with SMTP id w5mr15255500laa.28.1411669901256; Thu, 25 Sep 2014 11:31:41 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.25.86.18 with HTTP; Thu, 25 Sep 2014 11:31:41 -0700 (PDT) In-Reply-To: References: <54236CD6.4050807@FreeBSD.org> <5424392D.9030201@FreeBSD.org> <1411668571.66615.247.camel@revolution.hippie.lan> Date: Thu, 25 Sep 2014 11:31:41 -0700 X-Google-Sender-Auth: kQWyBFRKdWHYfZ36VW89M-8v0-U Message-ID: Subject: Re: KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread From: "K. Macy" To: Justin Hibbits Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Davide Italiano , Adrian Chadd , Bryan Drewery , Ian Lepore , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 18:31:45 -0000 > > > I like my bikeshed a nice royal blue. At a previous job we used > ASSERT and VERIFY macros. VERIFY was comparable to this (warn if > condition not met, don't panic), so how about KVERIFY() (I'll also > support KWARN, but I think KVERIFY() conveys a better message by > name). > Assert has a long established meaning in C that if a condition is not met, abort _now_. So his reservations about KASSERT_WARN aren't just spouting off. And while bikesheds are in fact all too prevalent your flippant comment about the color of the bikeshed is rather condescending and does not contribute positively to the tone of the discussion. Either of your suggestions is fine and a clear improvement over the initial name. KVERIFY would have clearer implications that this isn't a simple log message. Thanks for presenting these alternatives. -K From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 19:21:25 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E89D7637; Thu, 25 Sep 2014 19:21:24 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (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 A3437214; Thu, 25 Sep 2014 19:21:24 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XXDf7-0005AH-Bm; Thu, 25 Sep 2014 18:21:05 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s8PIL4G7003660; Thu, 25 Sep 2014 12:21:04 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19e8RvCcEeiqcMsZXlOfnoC X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread From: Ian Lepore To: Davide Italiano In-Reply-To: References: <54236CD6.4050807@FreeBSD.org> <5424392D.9030201@FreeBSD.org> <1411668571.66615.247.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Sep 2014 12:21:03 -0600 Message-ID: <1411669263.66615.249.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , "freebsd-arch@freebsd.org" , Bryan Drewery X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 19:21:25 -0000 On Thu, 2014-09-25 at 11:16 -0700, Davide Italiano wrote: > On Thu, Sep 25, 2014 at 11:09 AM, Ian Lepore wrote: > > On Thu, 2014-09-25 at 10:51 -0700, Davide Italiano wrote: > >> On Thu, Sep 25, 2014 at 9:14 AM, Adrian Chadd wrote: > >> > Hi, > >> > > >> > Please bring in KASSERT_WARN(). > >> > > >> > I'm grown up enough to use KASSERT_WARN() along with handling the > >> > invariant check myself in code. Having KASSERT_WARN() means I can add > >> > in this rather than printf()s or device_printf()'s with various knobs > >> > to remove it. > >> > > >> > (This is absolutely _not_ the "should KASSERT() optionally just log" > >> > argument. I'm not going to get into that a second time.) > >> > > >> > > >> > >> If you put a KASSERT() inside your code -- probably you should be > >> careful enough to put that iff you're sure that it should be always > >> verified. No exceptions. > >> People tend to be very lazy (including me). I don't expect everybody > >> diligently upgrading KASSERT_WARN to KASSERT. So KASSERT_WARN start > >> becoming more and more widespread, and people realize all of these > >> need to be upgraded to KASSERT or removed. This generally happens > >> after years. Yet. Another. Crusade. > >> There's a lot of work in the kernel to remove old/wrong/naive KPI > >> from the kernel. jhb@ is looking at timeout()-> callout() conversion. > >> I'm personally looking at dev_clone() removal. There are a lot of > >> other examples. > >> Adding KASSERT_WARN is a step backward, not a step forward, IMHO. > >> That said, if you want to pollute the kernel, fine. I expressed my > >> opinion, and I'm personally not happy about this, but I never stated > >> I'm gonna stop you from doing that. > >> > >> Thanks, > >> > >> -- > > > > IMO, this entire argument is ridiculous. Some conditions are so insane > > that you've got to stop immediately rather than make things worse. > > Other conditions indicate problems, but the code can recover or > > otherwise continue to operate safely. Trying to define every possible > > anomalous condition as either fatal or not worth mentioning is insane. > > > > Everyone is free to write code such as > > > > #ifdef INVARIANTS > > if (some_condition) > > printf("whatever warning\n"); > > #endif > > > > So let's be clear here: the objections are to spelling that code > > sequence KASSERT_WARN. If you object, please explain what's wrong with > > that spelling and how you would prefer it to be spelled. > > > > -- Ian > > > > > > Take the assert out of the name. Call it DEBUG_WARN, or something else > if you like. > assert as a pretty *clear* and specific semantic, no need to mess > around with it. > > Thanks, > To me, another "clear and specific semantic" that's associated with the word 'assert' in C programming is that the test expression itself is automatically printed as part of the diagnostic message. That's not the case in the FreeBSD kernel, so I guess we need to rename KASSERT as well? -- Ian From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 19:40:39 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 81588D55; Thu, 25 Sep 2014 19:40:39 +0000 (UTC) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 45D42661; Thu, 25 Sep 2014 19:40:38 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id gb8so3751522lab.30 for ; Thu, 25 Sep 2014 12:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZOpE4UhU7SAegE5aQtQm6vvnQB0O/9qmMkvKZVAd9VU=; b=pdht5swNRefqd1eV+bNQsEx7OzSegD5t+ibaEHWumx2pWkZZNRap17D0Y1HRiGAhBv kEf22zkFaPi2U77F1AHv0+x8avaACNdIMe/UzQGzxiDn9XWI3aPkkIQRAciO42TtGu55 yb1HnNSmpMuOXlR34SNvPEdB0nSkHHYc0KbykfJZuKcVv3CBIwyNT03gk+f+ql3xzOrW 4ASWudCMjv+2AsaLKbgqK5YRgdAPgz7UBFomgPVmHBIndSCsVivL6nvAavfA+5WQp0N7 4gTP/nVhleYi2si/WVEC3ibLghjT/Y3Od+8TGSaynB0O196HtUkX/n451lpv4FL63Hp4 yttw== MIME-Version: 1.0 X-Received: by 10.112.135.137 with SMTP id ps9mr15063048lbb.24.1411674036159; Thu, 25 Sep 2014 12:40:36 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.25.86.18 with HTTP; Thu, 25 Sep 2014 12:40:36 -0700 (PDT) In-Reply-To: <1411669263.66615.249.camel@revolution.hippie.lan> References: <54236CD6.4050807@FreeBSD.org> <5424392D.9030201@FreeBSD.org> <1411668571.66615.247.camel@revolution.hippie.lan> <1411669263.66615.249.camel@revolution.hippie.lan> Date: Thu, 25 Sep 2014 12:40:36 -0700 X-Google-Sender-Auth: HYxDJvSX8MipFwjQG0Bha2KMw1w Message-ID: Subject: Re: KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread From: "K. Macy" To: Ian Lepore Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Davide Italiano , Adrian Chadd , Bryan Drewery , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 19:40:39 -0000 > > > > To me, another "clear and specific semantic" that's associated with the > word 'assert' in C programming is that the test expression itself is > automatically printed as part of the diagnostic message. That's not the > case in the FreeBSD kernel, so I guess we need to rename KASSERT as > well? > Funny you mention that. It's always been a pet peeve of mine that KASSERT doesn't print the assertion. I always reasoned it away that instead it prints a string that is supposed to convey the significance of the expression. So I think it clearly still follows the original intent. Thanks for the suggestion though. -K From owner-freebsd-arch@FreeBSD.ORG Fri Sep 26 17:41:14 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C27F9742 for ; Fri, 26 Sep 2014 17:41:14 +0000 (UTC) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 90F7EC18 for ; Fri, 26 Sep 2014 17:41:14 +0000 (UTC) Received: by mail-pd0-f178.google.com with SMTP id ft15so13085220pdb.23 for ; Fri, 26 Sep 2014 10:41:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=8Pxoh2P6+ydqjkzum32KfkaWqMxBLCwoZbsL9IGOvQ4=; b=BS/KLW3IxRb2zyypV02jUPqi8V+mGBiqRL19CaJMGog9PW+ZnF89rPGGsvVye5fyV7 Vdr8g5Y9e01QMaTviq7lPDXbGu/CYi7s+dZgaQyyUwHiDxVcocqHoxI/5YDzIUoDuKCf VgRYWkWkUZzNi5I5Mip/OfdfNGzS9Z3ELepVeLVOgjISiTrr63Jldfit7qPzbeXA5d5H qWc8EXEy/oQ8s405NJnP3QqwJikAT1uZHaLm/OQBzyIRtRhzvrcj7pALtltfhdoQiY0v 0sFKNRYsh3cgjZ2uIF1lFtIC3l3Xtaa6GGyktPoax8UzILpzV33XKbRSM4JDRGwKUJ0E Ac5w== X-Gm-Message-State: ALoCoQmG8tuXf/DaJVXOpmM9F3B5BuxzyMVeL6Xml7fUIT7he2uKSsQApZlGCiJoLKSIm3ebS4Mq X-Received: by 10.70.21.228 with SMTP id y4mr34194257pde.19.1411753273219; Fri, 26 Sep 2014 10:41:13 -0700 (PDT) Received: from [172.24.39.159] ([64.186.236.200]) by mx.google.com with ESMTPSA id tc5sm5458677pbc.51.2014.09.26.10.41.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Sep 2014 10:41:12 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_D7062E12-134B-4F23-AC54-6CC8C3C96A92"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: vm_page_array and VM_PHYSSEG_SPARSE From: Warner Losh In-Reply-To: Date: Fri, 26 Sep 2014 10:41:12 -0700 Message-Id: <2F2CA5C3-3F0A-4F7D-B9C5-E78DC9E9F92A@bsdimp.com> References: To: Svatopluk Kraus X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 17:41:14 -0000 --Apple-Mail=_D7062E12-134B-4F23-AC54-6CC8C3C96A92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 24, 2014, at 5:27 AM, Svatopluk Kraus wrote: > Hi, >=20 > I and Michal are finishing new ARM pmap-v6 code. There is one problem = we've > dealt with somehow, but now we would like to do it better. It's about > physical pages which are allocated before vm subsystem is initialized. > While later on these pages could be found in vm_page_array when > VM_PHYSSEG_DENSE memory model is used, it's not true for = VM_PHYSSEG_SPARSE > memory model. And ARM world uses VM_PHYSSEG_SPARSE model. >=20 > It really would be nice to utilize vm_page_array for such preallocated > physical pages even when VM_PHYSSEG_SPARSE memory model is used. = Things > could be much easier then. In our case, it's about pages which are = used for > level 2 page tables. In VM_PHYSSEG_SPARSE model, we have two sets of = such > pages. First ones are preallocated and second ones are allocated after = vm > subsystem was inited. We must deal with each set differently. So code = is > more complex and so is debugging. That would be nice. Right now the memory allocation code early in the = ARM code is very simplistic on all the platforms I=92ve looked at: we get a base = address and just increment it as we allocate the page tables, etc. It would be = straight forward to add calls to note all of these pages. > Thus we need some method how to say that some part of physical memory > should be included in vm_page_array, but the pages from that region = should > not be put to free list during initialization. We think that such > possibility could be utilized in general. There could be a need for = some > physical space which: >=20 > (1) is needed only during boot and later on it can be freed and put to = vm > subsystem, I don=92t think we have any pages that are like this. The pages that = could be freed today are just wasted. > (2) is needed for something else and vm_page_array code could be used > without some kind of its duplication. >=20 > There is already some code which deals with blacklisted pages in = vm_page.c > file. So the easiest way how to deal with presented situation is to = add > some callback to this part of code which will be able to either = exclude > whole phys_avail[i], phys_avail[i+1] region or single pages. As the = biggest > phys_avail region is used for vm subsystem allocations, there should = be > some more coding. (However, blacklisted pages are not dealt with on = that > part of region.) Usually just not putting them into the free pool would be enough to keep = the vm=92s hands off of them. What are you proposing over that? > We would like to know if there is any objection: >=20 > (1) to deal with presented problem, > (2) to deal with the problem presented way. > Some help is very appreciated. Thanks I generally like the idea, so long as the vm_page_array doesn=92t eat a = lot of memory. In the early days, we went with SPARSE, I believe, to avoid = having huge arrays for those platforms whose memory started at 0xfxxxxxxx or 0xexxxxxxx=85 But memory here is a bit hazy... Warner --Apple-Mail=_D7062E12-134B-4F23-AC54-6CC8C3C96A92 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUJaU4AAoJEGwc0Sh9sBEAAi4QAIZ+XlJ+3BWdd3GJq1mOCK2N fp/re18Wrp8aNqPsBB4xxeO4Ju18+1tuO/BP+4zvuBmnBt5YkWwXaDUpZlSYZE5F BsjOBOvAV1COJSYhavxFOCHu7Uguv5oOqPkcAiW8nDmPeCcWzU0T8aVZOQ56ZW9r 2MCadr7nzJNWS3hsZ2FWNZmDxeHhY2+t+NSF1s7oL5WrzGTYzlgFvbQhtgMx1vzJ pdrUsJXqMnWk2b1R8OveN58gGCDJFy2kmHQGLsetCe4A0XI4uKom+8gsPgHEbH6Z Hhhe4x82CKXVHhs9fwvV862c905lI4cPRLcbPSx2jUAHFdCxZeQxHJFBuXTYhfnp 3FWrMbAywCKlOi0WiZgLnjYo56dlKFKhavTbjMIBd05LC7rwo8CnUJPEjHNDuhVR NpGQDE4jrSp5j4haWEDroyu1BNH4QpwGsbbk4bWMJUJLBOLJHNvff311z6yfwRSr PFsxO09HAZaXcSd9b9BRrfdnKI1AJ6iGxQaJ2cA7wgz/pdGO5ml+BOsOKQxFdS7p KIGDMmJjHbp0mzS2cKiaGDbxIbbniczS8eYPwDxIPwIGHTQ103cosSC3/IUCkCPt /5Em+DlCu+DP3Gfy9kItHhCXdb3lIIw4YK7M3u37E36ayaH2+7dAwoQwUkkm0ODn lM70Nzw63G5nBwQqvWhi =ATk/ -----END PGP SIGNATURE----- --Apple-Mail=_D7062E12-134B-4F23-AC54-6CC8C3C96A92-- From owner-freebsd-arch@FreeBSD.ORG Fri Sep 26 18:08:46 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 233D6BB9 for ; Fri, 26 Sep 2014 18:08:46 +0000 (UTC) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9EF70F19 for ; Fri, 26 Sep 2014 18:08:45 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id q1so3275912lam.7 for ; Fri, 26 Sep 2014 11:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=MuG6UdZE5iAXYS25rPUiq3LxcXA0AERkMXKmXAQ9k88=; b=L0wR5vcsBUys/uAhoFl2adpb24UiMsLzrJMzzvPYJKQr2vIItncNseevsi+NXz1GU1 VZ6v340g7iqjDPIGklJCJuZMnbjGW+szxz/LNjpYvi9dnh9vbnoSoAq7ApLAtiv4Qvox laXwJoB3XLhA4X5vYvZ+jYq1gZbS8ySyOxxi8InCBnd8mHhjPTasejh0ukjTHs/T63K2 a53eQ+Sbewwq+G5HWtwIIsNN9wXmgFHE9dhsKf4dhNoa1HjIdxs0pg0P67tLotGLZXf/ 7FeDyUhJeX5aOh0XVFFEJfTKDDcWkBLcFWYZFBsVAG+LaBMyLnXugOUTlOKoE8czO8t4 3TqQ== MIME-Version: 1.0 X-Received: by 10.152.22.100 with SMTP id c4mr3458772laf.0.1411754920710; Fri, 26 Sep 2014 11:08:40 -0700 (PDT) Received: by 10.25.15.95 with HTTP; Fri, 26 Sep 2014 11:08:40 -0700 (PDT) Reply-To: alc@freebsd.org In-Reply-To: References: Date: Fri, 26 Sep 2014 13:08:40 -0500 Message-ID: Subject: Re: vm_page_array and VM_PHYSSEG_SPARSE From: Alan Cox To: Svatopluk Kraus Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 18:08:46 -0000 On Wed, Sep 24, 2014 at 7:27 AM, Svatopluk Kraus wrote: > Hi, > > I and Michal are finishing new ARM pmap-v6 code. There is one problem we've > dealt with somehow, but now we would like to do it better. It's about > physical pages which are allocated before vm subsystem is initialized. > While later on these pages could be found in vm_page_array when > VM_PHYSSEG_DENSE memory model is used, it's not true for VM_PHYSSEG_SPARSE > memory model. And ARM world uses VM_PHYSSEG_SPARSE model. > > It really would be nice to utilize vm_page_array for such preallocated > physical pages even when VM_PHYSSEG_SPARSE memory model is used. Things > could be much easier then. In our case, it's about pages which are used for > level 2 page tables. In VM_PHYSSEG_SPARSE model, we have two sets of such > pages. First ones are preallocated and second ones are allocated after vm > subsystem was inited. We must deal with each set differently. So code is > more complex and so is debugging. > > Thus we need some method how to say that some part of physical memory > should be included in vm_page_array, but the pages from that region should > not be put to free list during initialization. We think that such > possibility could be utilized in general. There could be a need for some > physical space which: > > (1) is needed only during boot and later on it can be freed and put to vm > subsystem, > > (2) is needed for something else and vm_page_array code could be used > without some kind of its duplication. > > There is already some code which deals with blacklisted pages in vm_page.c > file. So the easiest way how to deal with presented situation is to add > some callback to this part of code which will be able to either exclude > whole phys_avail[i], phys_avail[i+1] region or single pages. As the biggest > phys_avail region is used for vm subsystem allocations, there should be > some more coding. (However, blacklisted pages are not dealt with on that > part of region.) > > We would like to know if there is any objection: > > (1) to deal with presented problem, > (2) to deal with the problem presented way. > Some help is very appreciated. Thanks > > As an experiment, try modifying vm_phys.c to use dump_avail instead of phys_avail when sizing vm_page_array. On amd64, where the same problem exists, this allowed me to use VM_PHYSSEG_SPARSE. Right now, this is probably my preferred solution. The catch being that not all architectures implement dump_avail, but my recollection is that arm does. From owner-freebsd-arch@FreeBSD.ORG Fri Sep 26 19:46:56 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C135B13A for ; Fri, 26 Sep 2014 19:46:56 +0000 (UTC) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8DE4DC0A for ; Fri, 26 Sep 2014 19:46:56 +0000 (UTC) Received: by mail-pd0-f175.google.com with SMTP id v10so12326630pde.6 for ; Fri, 26 Sep 2014 12:46:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=upMA5FeGjr3Oh1Uu35W2YUNJu0U4GsFOyzGVJPb89aY=; b=KWRd+YGj4csBG6L5OnoJniOuKFP+XJXK6qdV4LvhhW8idRmnk9qLLzj6WDMbvcaDaX Gs3k2bwGtc2BnO9tsVAotgxTiBGaQfh8O84U/sP+xkp3CPMhBdSWpTWLo3Vk/KZ+HghL i2heQlnFkXkhZtn2iExaqQ2KOpjgQPw3e7TI61dm14jcPbk7wS3hwKE2gTihj7avXGZv 6X7/tP+rt1mKc86GcpXeAS472EcpHEym7vTxkt2dTJJx1bJlipPIK/IZzelrp1iDcvK3 ArDSjWAu+UNanU+VViyP6515N3+suQkIMv31mkVG6dEWU7hJ7Trh6x6i+n3ZQ5GaClZN jPIQ== X-Gm-Message-State: ALoCoQnlyYIJ//b75Oq/tq3J26sgwO17fTMrDI4/vzmWN7IQXy+0t6Q4iU4c1CpaicJMC3jLrwmX X-Received: by 10.66.119.175 with SMTP id kv15mr35196584pab.30.1411760815195; Fri, 26 Sep 2014 12:46:55 -0700 (PDT) Received: from [172.20.12.175] ([12.145.98.24]) by mx.google.com with ESMTPSA id rz8sm5627441pbc.63.2014.09.26.12.46.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Sep 2014 12:46:54 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_1A9EC1DD-0BDF-4731-8C48-D328770FF63A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: vm_page_array and VM_PHYSSEG_SPARSE From: Warner Losh In-Reply-To: Date: Fri, 26 Sep 2014 12:46:51 -0700 Message-Id: <87094DEA-B403-49ED-9C63-A06FBF46D7EE@bsdimp.com> References: To: alc@freebsd.org X-Mailer: Apple Mail (2.1878.6) Cc: Svatopluk Kraus , FreeBSD Arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 19:46:56 -0000 --Apple-Mail=_1A9EC1DD-0BDF-4731-8C48-D328770FF63A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 26, 2014, at 11:08 AM, Alan Cox wrote: > On Wed, Sep 24, 2014 at 7:27 AM, Svatopluk Kraus = wrote: >=20 >> Hi, >>=20 >> I and Michal are finishing new ARM pmap-v6 code. There is one problem = we've >> dealt with somehow, but now we would like to do it better. It's about >> physical pages which are allocated before vm subsystem is = initialized. >> While later on these pages could be found in vm_page_array when >> VM_PHYSSEG_DENSE memory model is used, it's not true for = VM_PHYSSEG_SPARSE >> memory model. And ARM world uses VM_PHYSSEG_SPARSE model. >>=20 >> It really would be nice to utilize vm_page_array for such = preallocated >> physical pages even when VM_PHYSSEG_SPARSE memory model is used. = Things >> could be much easier then. In our case, it's about pages which are = used for >> level 2 page tables. In VM_PHYSSEG_SPARSE model, we have two sets of = such >> pages. First ones are preallocated and second ones are allocated = after vm >> subsystem was inited. We must deal with each set differently. So code = is >> more complex and so is debugging. >>=20 >> Thus we need some method how to say that some part of physical memory >> should be included in vm_page_array, but the pages from that region = should >> not be put to free list during initialization. We think that such >> possibility could be utilized in general. There could be a need for = some >> physical space which: >>=20 >> (1) is needed only during boot and later on it can be freed and put = to vm >> subsystem, >>=20 >> (2) is needed for something else and vm_page_array code could be used >> without some kind of its duplication. >>=20 >> There is already some code which deals with blacklisted pages in = vm_page.c >> file. So the easiest way how to deal with presented situation is to = add >> some callback to this part of code which will be able to either = exclude >> whole phys_avail[i], phys_avail[i+1] region or single pages. As the = biggest >> phys_avail region is used for vm subsystem allocations, there should = be >> some more coding. (However, blacklisted pages are not dealt with on = that >> part of region.) >>=20 >> We would like to know if there is any objection: >>=20 >> (1) to deal with presented problem, >> (2) to deal with the problem presented way. >> Some help is very appreciated. Thanks >>=20 >>=20 >=20 > As an experiment, try modifying vm_phys.c to use dump_avail instead of > phys_avail when sizing vm_page_array. On amd64, where the same = problem > exists, this allowed me to use VM_PHYSSEG_SPARSE. Right now, this is > probably my preferred solution. The catch being that not all = architectures > implement dump_avail, but my recollection is that arm does. For those architectures where it isn=92t implemented now, it is easy to = implement=85. Warner --Apple-Mail=_1A9EC1DD-0BDF-4731-8C48-D328770FF63A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUJcKrAAoJEGwc0Sh9sBEAGhsQAKhhqwIHhgu9Isb49arTxque MZJICVBZ2Xhx5Sl2wnCVt30Yvu5dCCgjrayb1gNMG0e+GOFLACW9CtmFJSMKeAub Aqyz3tz6ifJlZj55C/Td7XBDyS2CeoV8xtcGCF6p4Mxocdy45Gg8yL9tvBMPWCSL so43A32oJQsz1wtX3nJ8f9g6wekgCZ9pbFwSWPeAKtYZUdvYSyjJg+IZI9bhD0iZ cDt0fdE2a8IRyo9GpHku3kKvnTkcLE7MvS5X392o1MKMui2XNTYTVNLJXG+dgfGj K+SNn1PT/piUXH20C62frc0eovvLeZYm41l5q2zH+b0LxWsNZlIn6StjF45PZcFA +L8MHBNFuS4h9ykbzZ4DRuXGyRZ/h+vTNIjxVwl0Rrvo+lEgMAVIc0QzDOGs2Wzz dQE+NY/OL3tVkDLdbvIF+D2VtB/DlTHb0hGfZp33PSn+KRZh5GmQG3AUQbiDbxXw PHZzmYFL3JiuNNNcC890pag76bZOsZb1uSlHivQ7JhixQH960X1xZZpLKsci/Wif LD8kebDPjcicJWDSHRS9dwPOt8AYyChuDI4vW6zovZRsAWEtjtzyp0v368nR8XB9 NkCKRmpLzqhCIdx0RCv1EYgnQVSkPg6/9Va3RyljQ3S9sWZzPIhuvx1to0xLFJe5 T1582JFnqWZFyHHoQ7z2 =yzPg -----END PGP SIGNATURE----- --Apple-Mail=_1A9EC1DD-0BDF-4731-8C48-D328770FF63A-- From owner-freebsd-arch@FreeBSD.ORG Fri Sep 26 19:55:22 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 157DA665 for ; Fri, 26 Sep 2014 19:55:22 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DCEECD16 for ; Fri, 26 Sep 2014 19:55:21 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DC7D7B999; Fri, 26 Sep 2014 15:55:19 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org, John-Mark Gurney Subject: Re: callout(9) really this complicated? Date: Fri, 26 Sep 2014 15:52:53 -0400 Message-ID: <1831172.E2TVxmQund@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) In-Reply-To: <201407091211.47642.jhb@freebsd.org> References: <20140704041521.GW45513@funkthat.com> <20140704155752.GB45513@funkthat.com> <201407091211.47642.jhb@freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 26 Sep 2014 15:55:20 -0400 (EDT) Cc: Hans Petter Selasky X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 19:55:22 -0000 On Wednesday, July 09, 2014 12:11:47 PM John Baldwin wrote: > On Friday, July 04, 2014 11:57:52 am John-Mark Gurney wrote: > > Hans Petter Selasky wrote this message on Fri, Jul 04, 2014 at 08:15 +0200: > > > Probably the documentation needs an update. The implementation is fine. > > > > Probably... But w/ bad docs, it makes you wonder about the > > implementation... > > If you use callout_init_mtx(), then you can use callout_reset() and > callout_stop() while holding the mutex and everything will work as expected. > You typically only need to use callout_drain() during a device detach > routine to "destroy" the callout(). > > (A typical "detach" routine looks something like this: > > - detach external connections (ifnet, cdev, etc.) > - stop the hardware itself (foo_stop in various NIC drivers) > - this step typically does a callout_stop() with the relevant lock held > - drain any pending async events > - bus_teardown_intr() will block until the interrupt handler is > idle > - callout_drain() will block if the callout is pending because softclock > had already dequeued it and it was waiting for the driver lock when > you called callout_stop() earlier > - taskqueue_drain() (note that tasks do not have implicit locking ala > callout_init_mtx(), so you need to set some sort of flag that your > task function checks and breaks out of any loops for in the > "stop the hardware" step) > - free resources and destroy locks, etc. > > > > drain is always called unlocked. > > > > Then why the whole long section about avoiding races? Point #3 is > > the main one that I'm talking about... It seems like it'd be easier > > for callout to properly maintain the active flag (maybe set a flag to > > tell callout to do so), or not even maintain it since it really isn't > > used for anything important if you can munge it all you want... There > > aren't any statements about bad things happening if you call _deactivate > > before the callout is called... > > The language is unclear, but you only need to use one of the 3 options to > work around the races. Note that if you use callout_init_mtx() you fall > into case #1 and don't need to worry about the others. If you want to > use callout_init(.., CALLOUT_MPSAFE) and manage all the locking in your > callout handler directly, then you need to handle the assorted races. > However, you can generally get by with something far simpler than it > suggests. You can just do what I described above for taskqueue_drain(), > i.e. have your timer function do: > > foo(void *arg) > { > struct foo_softc *sc; > > sc = arg; > FOO_LOCK(sc); > if (sc->is_dead) { > FOO_UNLOCK(sc); > return; > } > .... > callout_reset(...); > FOO_UNLOCK(sc); > } > > In this case, simply setting 'is_dead' in the "stop the hardware" step and > using callout_drain() will work fine. I've overhauled the timeout(9) manpage a bit (my primary motivation is I'm getting close to removing timeout() from HEAD and I want the docs to be callout centric instead of timeout-centric). I did not mention my 'is_dead' flag approach above, but I think I might have covered the other issues (as well as documenting several current gaps). https://reviews.freebsd.org/D847 -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Sep 26 20:21:23 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB5C5475 for ; Fri, 26 Sep 2014 20:21:23 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 C8185FB1 for ; Fri, 26 Sep 2014 20:21:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s8QKLNVn066060 for ; Fri, 26 Sep 2014 20:21:23 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s8QKLNEa066059 for freebsd-arch@freebsd.org; Fri, 26 Sep 2014 20:21:23 GMT (envelope-from bdrewery) Received: (qmail 46032 invoked from network); 26 Sep 2014 15:21:21 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 26 Sep 2014 15:21:21 -0500 Message-ID: <5425CAB6.2010102@FreeBSD.org> Date: Fri, 26 Sep 2014 15:21:10 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread References: <54236CD6.4050807@FreeBSD.org> <5424392D.9030201@FreeBSD.org> <1411668571.66615.247.camel@revolution.hippie.lan> In-Reply-To: OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vT9xP5a5iEOx7EPSkSIr1W7RpGlk8StJp" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 20:21:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vT9xP5a5iEOx7EPSkSIr1W7RpGlk8StJp Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/25/2014 1:22 PM, Justin Hibbits wrote: > On Thu, Sep 25, 2014 at 11:16 AM, Davide Italiano = wrote: >> On Thu, Sep 25, 2014 at 11:09 AM, Ian Lepore wrote: >>> On Thu, 2014-09-25 at 10:51 -0700, Davide Italiano wrote: >>>> On Thu, Sep 25, 2014 at 9:14 AM, Adrian Chadd w= rote: >>>>> Hi, >>>>> >>>>> Please bring in KASSERT_WARN(). >>>>> >>>>> I'm grown up enough to use KASSERT_WARN() along with handling the >>>>> invariant check myself in code. Having KASSERT_WARN() means I can a= dd >>>>> in this rather than printf()s or device_printf()'s with various kno= bs >>>>> to remove it. >>>>> >>>>> (This is absolutely _not_ the "should KASSERT() optionally just log= " >>>>> argument. I'm not going to get into that a second time.) >>>>> >>>>> >>>> >>>> If you put a KASSERT() inside your code -- probably you should be >>>> careful enough to put that iff you're sure that it should be always >>>> verified. No exceptions. >>>> People tend to be very lazy (including me). I don't expect everybody= >>>> diligently upgrading KASSERT_WARN to KASSERT. So KASSERT_WARN start >>>> becoming more and more widespread, and people realize all of these >>>> need to be upgraded to KASSERT or removed. This generally happens >>>> after years. Yet. Another. Crusade. >>>> There's a lot of work in the kernel to remove old/wrong/naive KPI >>>> from the kernel. jhb@ is looking at timeout()-> callout() conversion= =2E >>>> I'm personally looking at dev_clone() removal. There are a lot of >>>> other examples. >>>> Adding KASSERT_WARN is a step backward, not a step forward, IMHO. >>>> That said, if you want to pollute the kernel, fine. I expressed my >>>> opinion, and I'm personally not happy about this, but I never stated= >>>> I'm gonna stop you from doing that. >>>> >>>> Thanks, >>>> >>>> -- >>> >>> IMO, this entire argument is ridiculous. Some conditions are so insa= ne >>> that you've got to stop immediately rather than make things worse. >>> Other conditions indicate problems, but the code can recover or >>> otherwise continue to operate safely. Trying to define every possibl= e >>> anomalous condition as either fatal or not worth mentioning is insane= =2E >>> >>> Everyone is free to write code such as >>> >>> #ifdef INVARIANTS >>> if (some_condition) >>> printf("whatever warning\n"); >>> #endif >>> >>> So let's be clear here: the objections are to spelling that code >>> sequence KASSERT_WARN. If you object, please explain what's wrong wi= th >>> that spelling and how you would prefer it to be spelled. >>> >>> -- Ian >>> >>> >> >> Take the assert out of the name. Call it DEBUG_WARN, or something else= >> if you like. >> assert as a pretty *clear* and specific semantic, no need to mess >> around with it. >> >> Thanks, >> >> -- >> Davide >=20 > I like my bikeshed a nice royal blue. At a previous job we used > ASSERT and VERIFY macros. VERIFY was comparable to this (warn if > condition not met, don't panic), so how about KVERIFY() (I'll also > support KWARN, but I think KVERIFY() conveys a better message by > name). >=20 > - Justin I will commit it as KVERIFY tonight based on the majority consensus. Even at work right now we are tracking down an odd bug where this could be useful to have temporarily. --=20 Regards, Bryan Drewery --vT9xP5a5iEOx7EPSkSIr1W7RpGlk8StJp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJUJcq2AAoJEDXXcbtuRpfPBU8H/344+rDMXLWkcAl3Q0kMJVeT aJHga3z4XBAac6tg2GpobTH0todkZIuzqG9OCXq31T/K8JoSd05byQRCi0AfO714 DnyB3lnU2tTbgWxzuBlo4A3on4RLJK4ysDfARf6Y69l7tlPH0a44/xRqDweAHkNG jWCcbnuO1je+09xDYNbgqH+eknhyMdmzjWHJVSoV2mNwneYB7u1+l3Q3svCJ0vFP i2xdX+5P9zD2s4+B/koJKfJgZCWU+MOaHCYMlmBcNjq2iVYIRsPNq12Fg3sdMQ+7 Yp2nHzWdnV0ljQeEXyNMViSssm3Ccf5ClSTIC+dLpUcJ5Rlg/+wNoQTLw2pBvA0= =IEkA -----END PGP SIGNATURE----- --vT9xP5a5iEOx7EPSkSIr1W7RpGlk8StJp-- From owner-freebsd-arch@FreeBSD.ORG Sat Sep 27 08:32:21 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3283D5A6 for ; Sat, 27 Sep 2014 08:32:21 +0000 (UTC) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E4E09F36 for ; Sat, 27 Sep 2014 08:32:20 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id dc16so964254qab.39 for ; Sat, 27 Sep 2014 01:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C9oJdVdQnw0Yufu1uq0x1sbvWcYCzNO0TiplIID4tGQ=; b=0kuwL7I4LyDKd43aGWUL/o9B++rD7q6+TTu7VecCpe5ayTxHs/f639W7wV4nOchPhc iPlVORwoA8K08pSsg0V/dc/i6Ut5KEPkhq2ocBP8Wrqoowxi54XLQHlkjzqU6bPUTFvq ltuZpOv5Bg6qG8119JX0Etr3dx+2sZLAVPiHz/rM3L3lxKn8Rgsp+PEd0De8XaSE/42I znQzCfNAh7U2hJ7QjuU0EFAutnofh7T17X2oT+k/4H3UevKuwWPdPfWkkkcbrHlRZ9oX l8zlZsL6WTRM969BMOKf+YaN7v6PNQ0K9TDzgHR2K2s/NM2qmHL1+E7Z6xINt0SfmHSD a8cQ== MIME-Version: 1.0 X-Received: by 10.224.10.198 with SMTP id q6mr37453504qaq.55.1411806740077; Sat, 27 Sep 2014 01:32:20 -0700 (PDT) Received: by 10.140.23.242 with HTTP; Sat, 27 Sep 2014 01:32:19 -0700 (PDT) In-Reply-To: <2F2CA5C3-3F0A-4F7D-B9C5-E78DC9E9F92A@bsdimp.com> References: <2F2CA5C3-3F0A-4F7D-B9C5-E78DC9E9F92A@bsdimp.com> Date: Sat, 27 Sep 2014 10:32:19 +0200 Message-ID: Subject: Re: vm_page_array and VM_PHYSSEG_SPARSE From: Svatopluk Kraus To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Sep 2014 08:32:21 -0000 On Fri, Sep 26, 2014 at 7:41 PM, Warner Losh wrote: > > On Sep 24, 2014, at 5:27 AM, Svatopluk Kraus wrote: > > > Hi, > > > > I and Michal are finishing new ARM pmap-v6 code. There is one problem > we've > > dealt with somehow, but now we would like to do it better. It's about > > physical pages which are allocated before vm subsystem is initialized. > > While later on these pages could be found in vm_page_array when > > VM_PHYSSEG_DENSE memory model is used, it's not true for > VM_PHYSSEG_SPARSE > > memory model. And ARM world uses VM_PHYSSEG_SPARSE model. > > > > It really would be nice to utilize vm_page_array for such preallocated > > physical pages even when VM_PHYSSEG_SPARSE memory model is used. Things > > could be much easier then. In our case, it's about pages which are used > for > > level 2 page tables. In VM_PHYSSEG_SPARSE model, we have two sets of su= ch > > pages. First ones are preallocated and second ones are allocated after = vm > > subsystem was inited. We must deal with each set differently. So code i= s > > more complex and so is debugging. > > That would be nice. Right now the memory allocation code early in the ARM > code > is very simplistic on all the platforms I=E2=80=99ve looked at: we get a = base > address and > just increment it as we allocate the page tables, etc. It would be > straight forward > to add calls to note all of these pages. > > > Thus we need some method how to say that some part of physical memory > > should be included in vm_page_array, but the pages from that region > should > > not be put to free list during initialization. We think that such > > possibility could be utilized in general. There could be a need for som= e > > physical space which: > > > > (1) is needed only during boot and later on it can be freed and put to = vm > > subsystem, > > I don=E2=80=99t think we have any pages that are like this. The pages tha= t could be > freed today are just wasted. > I'm not sure that I understand the second sentence in the scope of the first one. However, I can imagine that some data which comes from loader, is saved on memory, cannot be processed before vm subsystem initialization, and could be free afterwards, it is good example for (1). Anyhow, it's not a case of today probably. > > > (2) is needed for something else and vm_page_array code could be used > > without some kind of its duplication. > > > > There is already some code which deals with blacklisted pages in > vm_page.c > > file. So the easiest way how to deal with presented situation is to add > > some callback to this part of code which will be able to either exclude > > whole phys_avail[i], phys_avail[i+1] region or single pages. As the > biggest > > phys_avail region is used for vm subsystem allocations, there should be > > some more coding. (However, blacklisted pages are not dealt with on tha= t > > part of region.) > > Usually just not putting them into the free pool would be enough to keep > the > vm=E2=80=99s hands off of them. What are you proposing over that? > If you are asking about case (2), then I just think that it could be convenient to have a possibility to reuse vm_page_array's functions for memory which is not for vm's hands. Again, it's about another possibility which would arise if there will be a method how to put some memory region into vm_page_array but off of vm subsystem. > > > We would like to know if there is any objection: > > > > (1) to deal with presented problem, > > (2) to deal with the problem presented way. > > Some help is very appreciated. Thanks > > I generally like the idea, so long as the vm_page_array doesn=E2=80=99t e= at a lot > of > memory. In the early days, we went with SPARSE, I believe, to avoid havin= g > huge arrays for those platforms whose memory started at 0xfxxxxxxx or > 0xexxxxxxx=E2=80=A6 But memory here is a bit hazy... > > Warner I already have had that in my mind. What I've presented here eats only as much memory as is really needed and nothing more. I like the idea about using dump_avail instead of phys_avail for vm_page_array initialization and segmentation, but it eats more (but not much more). Svata From owner-freebsd-arch@FreeBSD.ORG Sat Sep 27 08:51:45 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 010E0EC9; Sat, 27 Sep 2014 08:51:44 +0000 (UTC) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A3EDD1A6; Sat, 27 Sep 2014 08:51:44 +0000 (UTC) Received: by mail-qc0-f174.google.com with SMTP id i8so6410781qcq.19 for ; Sat, 27 Sep 2014 01:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8xhQMTiw06eFUiCV7Xe8iswA7TM8b7ssQmauCEs3Kjw=; b=xcg53jWufqT4ZHpOSlTWaZj5ma7HOIPzTRJSe9QNzkZmrub5dWV9wqB7gNZjEqyQQy HlQrnrVzfPhOI+zkGmpH+vjQr+SePu/Ki01JzCnxjABgrwzeciqH918x7cgew4byZOsu 1N4V01GNUKD7t9VuurO9st5AT8RqMu4EdZaIWDBtafe1rDSaEFIVLoFccz4IiO22JyDf 6t2WBOvHTQCVnoHBvrkUfRx+MjYR5FzwXw63mNDL45qIOumTHVhD1ezlPfBR6mOY7GR4 OtsQjfUo2Po9v5Okh8a1lPXJyI30FoWJf6i7yt0sm1xxbtWihRZGVkY4Q0GsM+wBXdV1 x7YQ== MIME-Version: 1.0 X-Received: by 10.224.172.198 with SMTP id m6mr37285705qaz.19.1411807903768; Sat, 27 Sep 2014 01:51:43 -0700 (PDT) Received: by 10.140.23.242 with HTTP; Sat, 27 Sep 2014 01:51:43 -0700 (PDT) In-Reply-To: References: Date: Sat, 27 Sep 2014 10:51:43 +0200 Message-ID: Subject: Re: vm_page_array and VM_PHYSSEG_SPARSE From: Svatopluk Kraus To: alc@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Sep 2014 08:51:45 -0000 On Fri, Sep 26, 2014 at 8:08 PM, Alan Cox wrote: > > > On Wed, Sep 24, 2014 at 7:27 AM, Svatopluk Kraus > wrote: > >> Hi, >> >> I and Michal are finishing new ARM pmap-v6 code. There is one problem >> we've >> dealt with somehow, but now we would like to do it better. It's about >> physical pages which are allocated before vm subsystem is initialized. >> While later on these pages could be found in vm_page_array when >> VM_PHYSSEG_DENSE memory model is used, it's not true for VM_PHYSSEG_SPARSE >> memory model. And ARM world uses VM_PHYSSEG_SPARSE model. >> >> It really would be nice to utilize vm_page_array for such preallocated >> physical pages even when VM_PHYSSEG_SPARSE memory model is used. Things >> could be much easier then. In our case, it's about pages which are used >> for >> level 2 page tables. In VM_PHYSSEG_SPARSE model, we have two sets of such >> pages. First ones are preallocated and second ones are allocated after vm >> subsystem was inited. We must deal with each set differently. So code is >> more complex and so is debugging. >> >> Thus we need some method how to say that some part of physical memory >> should be included in vm_page_array, but the pages from that region should >> not be put to free list during initialization. We think that such >> possibility could be utilized in general. There could be a need for some >> physical space which: >> >> (1) is needed only during boot and later on it can be freed and put to vm >> subsystem, >> >> (2) is needed for something else and vm_page_array code could be used >> without some kind of its duplication. >> >> There is already some code which deals with blacklisted pages in vm_page.c >> file. So the easiest way how to deal with presented situation is to add >> some callback to this part of code which will be able to either exclude >> whole phys_avail[i], phys_avail[i+1] region or single pages. As the >> biggest >> phys_avail region is used for vm subsystem allocations, there should be >> some more coding. (However, blacklisted pages are not dealt with on that >> part of region.) >> >> We would like to know if there is any objection: >> >> (1) to deal with presented problem, >> (2) to deal with the problem presented way. >> Some help is very appreciated. Thanks >> >> > > As an experiment, try modifying vm_phys.c to use dump_avail instead of > phys_avail when sizing vm_page_array. On amd64, where the same problem > exists, this allowed me to use VM_PHYSSEG_SPARSE. Right now, this is > probably my preferred solution. The catch being that not all architectures > implement dump_avail, but my recollection is that arm does. > Frankly, I would prefer this too, but there is one big open question: What is dump_avail for? Using it for vm_page_array initialization and segmentation means that phys_avail must be a subset of it. And this must be stated and be visible enough. Maybe it should be even checked in code. I like the idea of thinking about dump_avail as something what desribes all memory in a system, but it's not how dump_avail is defined in archs now. I will experiment with it on monday then. However, it's not only about how memory segments are created in vm_phys.c, but it's about how vm_page_array size is computed in vm_page.c too. Svata From owner-freebsd-arch@FreeBSD.ORG Sat Sep 27 09:01:56 2014 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 561893EF; Sat, 27 Sep 2014 09:01:56 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4447027E; Sat, 27 Sep 2014 09:01:54 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA22176; Sat, 27 Sep 2014 12:01:52 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XXnt2-0002oO-6j; Sat, 27 Sep 2014 12:01:52 +0300 Message-ID: <54267CAE.4090009@FreeBSD.org> Date: Sat, 27 Sep 2014 12:00:30 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Bryan Drewery , freebsd-arch@FreeBSD.org Subject: Re: KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread References: <54236CD6.4050807@FreeBSD.org> <5424392D.9030201@FreeBSD.org> <1411668571.66615.247.camel@revolution.hippie.lan> <5425CAB6.2010102@FreeBSD.org> In-Reply-To: <5425CAB6.2010102@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: jhibbits@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Sep 2014 09:01:56 -0000 On 26/09/2014 23:21, Bryan Drewery wrote: > On 9/25/2014 1:22 PM, Justin Hibbits wrote: >> I like my bikeshed a nice royal blue. At a previous job we used >> ASSERT and VERIFY macros. VERIFY was comparable to this (warn if >> condition not met, don't panic), so how about KVERIFY() (I'll also >> support KWARN, but I think KVERIFY() conveys a better message by >> name). > > I will commit it as KVERIFY tonight based on the majority consensus. > Even at work right now we are tracking down an odd bug where this could > be useful to have temporarily. > Not sure if the following bit of information will influence your decision, but anyway. In the Solaris source code ASSERT is used like our KASSERT where DEBUG macro controls its definition like our INVARIANTS do. But VERIFY is used like KASSERT that is never compiled out. So, my personal preference would be to use KWARN for something that only warns. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Sat Sep 27 14:53:29 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D0A5AF4; Sat, 27 Sep 2014 14:53:29 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BB9BF84D; Sat, 27 Sep 2014 14:53:28 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id pv20so6419357lab.10 for ; Sat, 27 Sep 2014 07:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=dqDKvi7EHYu8ONxVoxVT9vAprii8gHkmbpb2Ueuok5Q=; b=U4q0d1EcDACBqGwmxM8uSESsT5CWAAwQSnn7pQT8YZlbpvf18qwIKDxewv4FQQEUWF CGDE/145pSwM1fdA9zNuk0xnE8iRLhVnFxxNO3xCeEEcsJDtQEwzXhAkeGKCnAsenagJ LVnJkwxwBwrNHx6Sr3WqJcLrUQXq2WjkxuzcwsBmQyXWPYfdtdo1oN5xIAD2hzLMLgm2 Sctl4Rh0qPqiLHUvmXL0sbnx+WzVgMXop9rHhRNxyQ00aR4NqzxhLvVxHA5Ux/Hjdf+t sGVvUcRhlC3m1i8e1i6Pif46bYq9kpFb5fmHOJIieu9+y8mZCUZykdeUAF1dBe2RxkhL ZwvQ== MIME-Version: 1.0 X-Received: by 10.112.201.42 with SMTP id jx10mr2761716lbc.101.1411829606664; Sat, 27 Sep 2014 07:53:26 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.25.15.29 with HTTP; Sat, 27 Sep 2014 07:53:26 -0700 (PDT) Received: by 10.25.15.29 with HTTP; Sat, 27 Sep 2014 07:53:26 -0700 (PDT) In-Reply-To: <54267CAE.4090009@FreeBSD.org> References: <54236CD6.4050807@FreeBSD.org> <5424392D.9030201@FreeBSD.org> <1411668571.66615.247.camel@revolution.hippie.lan> <5425CAB6.2010102@FreeBSD.org> <54267CAE.4090009@FreeBSD.org> Date: Sat, 27 Sep 2014 07:53:26 -0700 X-Google-Sender-Auth: BGQxI6NUqm6BeU-_czUBM7c--Ec Message-ID: Subject: Re: KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread From: Justin Hibbits To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Bryan Drewery , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Sep 2014 14:53:29 -0000 On Sep 27, 2014 2:01 AM, "Andriy Gapon" wrote: > > On 26/09/2014 23:21, Bryan Drewery wrote: > > On 9/25/2014 1:22 PM, Justin Hibbits wrote: > >> I like my bikeshed a nice royal blue. At a previous job we used > >> ASSERT and VERIFY macros. VERIFY was comparable to this (warn if > >> condition not met, don't panic), so how about KVERIFY() (I'll also > >> support KWARN, but I think KVERIFY() conveys a better message by > >> name). > > > > I will commit it as KVERIFY tonight based on the majority consensus. > > Even at work right now we are tracking down an odd bug where this could > > be useful to have temporarily. > > > > Not sure if the following bit of information will influence your decision, but > anyway. In the Solaris source code ASSERT is used like our KASSERT where DEBUG > macro controls its definition like our INVARIANTS do. But VERIFY is used like > KASSERT that is never compiled out. So, my personal preference would be to use > KWARN for something that only warns. > That sounds like pretty good precedent. I fully support it or Davide's DEBUG_WARN suggestion, and agree it makes more sense than KVERIFY from this context. -Justin