From nobody Tue Dec 14 17:28:07 2021 X-Original-To: freebsd-current@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 DC9AF18EE7AE; Tue, 14 Dec 2021 17:28:08 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4JD51h4JB4z3shh; Tue, 14 Dec 2021 17:28:08 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id F3E0F4BCE; Tue, 14 Dec 2021 17:28:07 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Tue, 14 Dec 2021 09:28:07 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore Content-Language: en-US To: Gleb Smirnoff Cc: "freebsd-current@freebsd.org" , x11@freebsd.org References: <1db0942e-0e66-4337-ce2f-4e1005107435@FreeBSD.org> <836761df-6eea-462b-9ae7-5d0d00aad38f@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639502888; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=g03RXAbnYo7ibXJRgKBCYLeY9KoObszivTRCMskX2d8=; b=BTca/dTfywaK/Jbr/Pa/vL9JLefKPs7Yj31MsjVyYQkMd9/6xl25BUWqaHbzN2sdA2f/j0 Zp2ZRnfB1rNrVZK9kiArYy7BiC6LhqnJFz2b8TVNXYFXvJNTlJ7ENbi7Z0IgFBl0xrO8+I Hu/TUfUCrzk9ZopatmzEgq+q9bprCR4X5L/M8MlypwxsYytBhOWERLaclpqMSG24dgVHKA slwxqYG9Z2GzBRmGZtXkdZOv9KB32onpBYbCYiek9Q3+pMlUDZhki9v2PPUvtwExcHcz/w tkzHf2JwcnJLC6woSNnochh00Z1jWdiroWg3Wf5YeDAY9ir+HbspbwWRllpkGQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639502888; a=rsa-sha256; cv=none; b=UN8mh6l1f4lAMfbF3vhozWJfmzKb8+9aRk5CIYq+jPo2rxsey+egKfzRqOOXSpbGNanFmU hWEUXuwMa9tQRgi0O3vGPQy+YM+5y5hNYTqz+6UW24XjfibfWn5ROzRzNz4GYXpcSGTZEp CY1vfDNvZmDbN+o3tjDgSMRhfVzw422qLSpJKFIi2ZkmgnVhT4K1T7Fnm9NC3KLtC2V2xr JrzhXMfVhfK9axI3GHGHqQX5GsbpEWl8jaKRQ5SP70kW/1rp7yIxUT2CgbfvPQw+eUy+mt qTcX1HucwInaF+EtbZLt/XtKctGjJM8eG2ztB1F3SBhgf5tfM6MwXgtai+cD9w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 12/13/21 12:25 PM, Gleb Smirnoff wrote: > On Mon, Dec 13, 2021 at 11:56:35AM -0800, John Baldwin wrote: > J> > J> So there are two things here. The root issue is that the devel/apr1 port > J> > J> runs a configure test for TCP_NDELAY being inherited by accepted sockets. > J> > J> This test panics because prison_check_ip4() tries to lock a prison mutex > J> > J> to walk the IPs assigned to a jail, but the caller (in_pcblookup_hash()) has > J> > J> done an smr_enter() which is a critical_enter(): > J> > > J> > The first one is known, and I got a patch to fix it: > J> > > J> > https://reviews.freebsd.org/D33340 > J> > > J> > However, a pre-requisite to this simple patch is more complex: > J> > > J> > https://reviews.freebsd.org/D33339 > J> > > J> > There is some discussion on how to improve that, and I decided to do that > J> > rather than stick to original version. So I takes a few extra days. > J> > > J> > We could push D33340 into main, if the negative effects (raciness of > J> > the prison check) is considered lesser evil then potentially contested > J> > mtx_lock in smr section. > J> > J> I think raciness is probably better than always panicking as it does today. > > AFAIK, today it will always panic only with WITNESS. Without WITNESS it would > pass through mtx_lock as long as the mutex is not locked. Yes, but the default kernel on head is GENERIC which has witness enabled, hence the out of the box kernel panics reliably. :) > So, do you suggest to push D33340 before finalizing D33339? Yes, I think so. -- John Baldwin