From owner-freebsd-bugs@freebsd.org Thu Dec 28 17:36:33 2017 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1CC53EAAD36 for ; Thu, 28 Dec 2017 17:36:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 0AFD3632CF for ; Thu, 28 Dec 2017 17:36:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id vBSHaVLE000886 for ; Thu, 28 Dec 2017 17:36:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 224479] kernel panic in reboot+swapoff sys call Date: Thu, 28 Dec 2017 17:36:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 17:36:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224479 --- Comment #18 from Konstantin Belousov --- (In reply to Andriy Gapon from comment #15) This is perhaps going too far on the silly fest. Andrey, you do understand VFS, so I am quite frustrated. 1. If the vnode carriers some database, should kernel stop the database on = the basis that otherwise user data might be corrupted ? Should kernel print (Abort, Retry, Ignore ?) 2.If force unmount is not allowed because there is the swap on a file, would the next request be to add really-force option which causes unmount to proc= eed even in this case. 3. You agree on your own that io to reclaimed vnode is not possible. May b= e we should not reclaim such vnode, but then add VOP_RECLAIMFORREAL. It is very clear situation, system was directed to change its configuration= in a way which makes the continuation of the operations sometimes problematic, sometimes not. Why people consider it is reasonable to either deny the reconfiguration or to deny and have kernel to spit the whole man page on the console as the additional punishment, is beyond me. --=20 You are receiving this mail because: You are the assignee for the bug.=