From nobody Sun Nov 28 07:53:06 2021 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1454318B2D03; Sun, 28 Nov 2021 07:53:13 +0000 (UTC) (envelope-from peterj@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J211h6PDkz4WTT; Sun, 28 Nov 2021 07:53:12 +0000 (UTC) (envelope-from peterj@freebsd.org) Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: peterj) by smtp.freebsd.org (Postfix) with ESMTPSA id 494BDB52D; Sun, 28 Nov 2021 07:53:11 +0000 (UTC) (envelope-from peterj@freebsd.org) Date: Sun, 28 Nov 2021 18:53:06 +1100 From: Peter Jeremy To: Konstantin Belousov Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: b19740f4ce7a - main - swap_pager: lock vnode in swapdev_strategy() Message-ID: References: <202111251935.1APJZA1e094731@gitrepo.freebsd.org> List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="silS3mqwC8aP56W6" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638085992; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CEMqXOHSJd5Hr8ke2P/mjuHO3g8NRKXokwX76ZJLE3w=; b=bl1P1TmYkGIBLQvv++IVGNx3G2A2sxEcDUBTvIK2EQ1Du0VbpZ9f/ax30YGEBuYUQbFAEF 7Kgni1ekeWEL/C6G7OoJ5bX2ln6JGjz2uJ23tmcsph28qamVChpbz70eNSVgAk2o5USRNK 4Ni4PTwVcwh55Il05/YBYRS71TdgMIzPcNIMlHv0NBAy/SGielD5uELOKAspDss7kGnjZE iPpSSOQETYfoXB9TB0GWJz8UM5322FI4cit0s06K7q1Z/UkNtTi3+cnHLxHHJVac3ySOyA D1QSczryGV37TCBYlo+03JxTu7dmWtGDfwy+PwD55v4xziqJR9gr2OZcs+sSTQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638085992; a=rsa-sha256; cv=none; b=LUFVxKjzdjBoz2veJDw9D0nk0GNN3BMR3hpZdWQDQprw0yDFL3lVZj6gQdazmIuWENdfeB E74jJp4twVGinrQ6quePPGLzWNRFJB68GXDBQDw/FS/6kGpxD38WycB6ACoXufYffAGtjc xb2l7YMaWArAgutKS8QgpmgdjcLIj4p610zZ4Q7Su5pB13b+DmJ+h/qXYgP0KcxeLFbo6S ZpC5/rq5fVs+0bNPb3sRQVAgt0H983bu/MK3yOs+iipRxiij6dhVP1wwv8rK6L/ZDYW83z Te2zG0WgdvAhn2zy08TRgIGV+C0XbNgwVhPKnq13Yqbne7GLEvMQFJVPJu9LVg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --silS3mqwC8aP56W6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-Nov-28 04:00:56 +0200, Konstantin Belousov wr= ote: >On Sun, Nov 28, 2021 at 12:22:46PM +1100, Peter Jeremy wrote: >> On 2021-Nov-27 01:26:17 +0200, Konstantin Belousov = wrote: >The cause for your panic is not the network interface down state (in fact, >I think that interface state up), but as you correctly analyzed, the >call to vop_nostrategy(). It is there in stack because underlying filesys= tem >was unmounted, and the swap vnode was reclaimed, replacing NFS vop vector >with deadfs vop vector, which inherits from the default vop. OK. Thanks for that explanation. I saw deadfs was a potential option but hadn't checked. >The bit that I do not understand from your report, is why swapoff_all() did >not occured earlier. Your earlier report, where spurious ENOMEM came out >from swapoff(2) syscall, and which I fixed by the previous patch, means=20 >that there was an attempt to swapoff. The ENOMEM swapoff is before the actual shutdown. I suspect my inclusion of that confused you, sorry. >Still, the solution is, IMO, to swapoff before unmount. We do not need >swapin for flushing buffers. > >Please try this combined patch. I've had a couple of goes at rebooting whilst thrashing with lots of swap in use and it seems happy so I think the patch is good to go. Thanks for the patches. --=20 Peter Jeremy --silS3mqwC8aP56W6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmGjNVZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzSE0g//a9+oPJ2kgUiAGBYm2CcBgruJfRN2fsDCvvuZgmegnYO5vEpy8CEmQhpo ZmVom0O2uDkPv11fso9F11CUJE3qGf6vwukojFRhycbgSIwO77YrVNv1DKhw3gds K57Jn6TAJaeasL1C3Ki8DSHbrUu8GbeVbKexxGtv6ggR//+Wj4+Ei3NU1cDuCbmX IesDG+X1MzY3/2Wtsq1rg8aX+lDf/V1hpYLyldqou98h7svrb8Q2brZ/DP/kpy4V oLRGlwDL1JZcnKhd/cX8Wb2OMTg8Yd8kSeuUZ0SAgbBGXLonhpamAOxJbvsu0v6W AG12iYE/diCYpEKvPdHRcCGAEin51IjeGN6PMFU/oW2To3dov+PUgwO/zWl7cSqj puDugTaZa/Uop4AlvRCpQN+b4qqLXj1qI0j09QwR3NWvLfQ8ZAWP5uq7/Db9Tlca RiVdizQP5qvSoEih9BOpHEaAcLyN1rWW9uP+wVC9iGDlcvqdaghpPPv1+AeNonxj azWurUmImNbiialD4I8V1+9z3bMJMIOv0+Ox8+o+hJUlsWIlfeljXJPK8VxkOAaN TPjyPiNXWbB9ETon8v259DXSlW+kXfr6CJe0K9hOum1Fkw/gGjgHi1anvcPssubP lbmfE3deKwqgBqyOLnNIsfZ8yWKHPEtPSs3l9GkAUfjA4BUkWkU= =P0xN -----END PGP SIGNATURE----- --silS3mqwC8aP56W6--