From nobody Fri Dec 23 11:15:01 2022 X-Original-To: freebsd-jail@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 4Ndl2v0LkTz1HWs3 for ; Fri, 23 Dec 2022 11:15:19 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward502a.mail.yandex.net (forward502a.mail.yandex.net [IPv6:2a02:6b8:c0e:500:1:45:d181:d502]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ndl2s1Cfmz4XTn for ; Fri, 23 Dec 2022 11:15:16 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ipfw.ru header.s=mail header.b=UfBM6UX+; spf=pass (mx1.freebsd.org: domain of melifaro@ipfw.ru designates 2a02:6b8:c0e:500:1:45:d181:d502 as permitted sender) smtp.mailfrom=melifaro@ipfw.ru; dmarc=none Received: from vla1-27b4fc0f1fa3.qloud-c.yandex.net (vla1-27b4fc0f1fa3.qloud-c.yandex.net [IPv6:2a02:6b8:c0d:4201:0:640:27b4:fc0f]) by forward502a.mail.yandex.net (Yandex) with ESMTP id 2E2575EB5F; Fri, 23 Dec 2022 14:15:13 +0300 (MSK) Received: by vla1-27b4fc0f1fa3.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id BFmn9L9YjeA1-GzVKILLN; Fri, 23 Dec 2022 14:15:12 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1671794112; bh=QgE5v5PhacSC+MN3E4frWwA7qevtOphb3inPgVLv5CU=; h=Message-Id:To:Date:References:Cc:In-Reply-To:From:Subject; b=UfBM6UX+dexEHax/4y6V5QZD/EimZ8W4TK+rZO9JkGgWiTK5EPIo9OsQhtQzH49bW qlOwaKA3Fg3pumKNHYjZWcQfiXUQJ/arSpIsdZWzI0X5mL8JbQUsdEdaq5OeFB1nEN JwMNCpoJuN3H67xnxCWEce6jPWzlVSoQxar3vjIk= Content-Type: text/plain; charset=utf-8 List-Id: Discussion about FreeBSD jail(8) List-Archive: https://lists.freebsd.org/archives/freebsd-jail List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-jail@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: Re: Is it possible to employ epoch to simplify managing prison lifecycle From: "Alexander V. Chernikov" In-Reply-To: Date: Fri, 23 Dec 2022 11:15:01 +0000 Cc: Zhenlei Huang , freebsd-jail@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <4E70D6D2-4E80-4AAD-BB3C-9295F586D1FF@ipfw.ru> References: <9BD54A54-A809-4D3E-BCBA-639E6C61FE37@FreeBSD.org> To: Mateusz Guzik X-Mailer: Apple Mail (2.3731.200.110.1.12) X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a02:6b8:c00::/40]; R_DKIM_ALLOW(-0.20)[ipfw.ru:s=mail]; MIME_GOOD(-0.10)[text/plain]; FREEFALL_USER(0.00)[melifaro]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[ipfw.ru]; TAGGED_RCPT(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-jail@freebsd.org]; DKIM_TRACE(0.00)[ipfw.ru:+]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:208722, ipnet:2a02:6b8::/32, country:FI]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-Rspamd-Queue-Id: 4Ndl2s1Cfmz4XTn X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N > On 16 Dec 2022, at 16:29, Mateusz Guzik wrote: >=20 > On 12/16/22, Zhenlei Huang wrote: >> Hi, >>=20 >> While hacking `sys/kern/kern_jail.c` I got lost. >>=20 >> There're lots of ref / unref and flags to prevent visit invalid = prison >> while >> concurrent modification is possible and some refs looks weird. >>=20 >> Is it possible to employ epoch(9) to simplify managing of prison = lifecycle >> ? >>=20 >=20 > Some of the ref/unref cycles are probably avoidable to begin with, but > ultimately the thing to do here is to employ per-cpu reference > counting, if at all needed. >=20 > I have a wip patch to provide such a mechanism, it may or may not land > this month. That would be nice. I=E2=80=99d love to convert nextops refcounting to = that one. Do you envision similar semantics as Linux percpu_ref? I mean, does one = need to explicitly mark =E2=80=9Cnot in active use=E2=80=9D stage? >=20 > --=20 > Mateusz Guzik >=20