From nobody Fri Dec 23 15:27:53 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 4NdrfN0pkPz1LqMs for ; Fri, 23 Dec 2022 15:27:56 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com [IPv6:2001:4860:4864:20::32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NdrfM5Pvyz3w38 for ; Fri, 23 Dec 2022 15:27:55 +0000 (UTC) (envelope-from mjguzik@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-12c8312131fso6260810fac.4 for ; Fri, 23 Dec 2022 07:27:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=eGQlFsUOUKtaq95xtCJBqVL0R2iH0hrGzT+QWjGosRs=; b=A7Qog7cA7wyGeD1Rye1taA/T2aCmKMYh45+WtIw0Ysyednd/D2jcw0ST0/WO9EvHGo rivLHGxITOYTTUTOGNKF/hW1xV3OLtEp66XFAY13npyPYKPW3Mt5G0ZW1oSligzGJZFT TSmb4zkn+rRS++HiPrvo7pCOQaJYyoGK+X8yrRHlX1ASMtBNhg2pVYRgll5DAuFu3mfm NfIff04xUM+1CW0N1J44RfkWqS3T+5kBEPKJk1d7ll8vKsSpc0Ez/VY/XkrMpwYewCta E/ZRoVUhD1iaW55J+m5ihzYoVofhdaqntSh+spPW6wXyFkRnBUdg6cbIMeGahpw0Q1dV Gozw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=eGQlFsUOUKtaq95xtCJBqVL0R2iH0hrGzT+QWjGosRs=; b=5eWIL5I2ogHdvv+6JznGit+wPTQaESWnhMtweKTMzhsL65oeQBta9SJhYmKtP/BfPd aMflUPAlTy/fMu5dMfKRGYnZT8tiLByS2fbY10j/hA8F1c1kDjcrzVORVeZMxnT6b+71 9m3ErZUUKdJbQJ7/mkdXGCRNbHNXFINaOFEbxNhOV3nMmm9nlrcVNwycf2YxOjHmQ8YG vYVSxMLBBgf9dpBOBp4jcdabf1TIa/NAgyrqwFO30NQ2fD875CGmF0+Z9EeRO0DKqG+V VytbMJhCAgEOrzYFSyPBLAdRKFZf9B8lT6xx9Fva/o7cq6g3Znruuv06QCL4Hc43l1zZ ucgg== X-Gm-Message-State: AFqh2krIStY6fpMcfhtvM1Twr1e3iKIUvovd33ttik+QXc/aOqsIMiLC nggJHdI5inpGPYBHUC1iaawxPaMjiiZwuxm47skoIB+S X-Google-Smtp-Source: AMrXdXsTyIJsmK51Dc+kfLd+GJLtSJHJFVyl4FVy9amwH6cEUXoDKRRA6rFeoVtv7Stsb6NXmNoKHy9fUL88PAd4SFk= X-Received: by 2002:a05:6870:e9a:b0:144:68b8:88eb with SMTP id mm26-20020a0568700e9a00b0014468b888ebmr658188oab.159.1671809273886; Fri, 23 Dec 2022 07:27:53 -0800 (PST) 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 Received: by 2002:ac9:77d5:0:b0:491:8368:9bdd with HTTP; Fri, 23 Dec 2022 07:27:53 -0800 (PST) In-Reply-To: <4E70D6D2-4E80-4AAD-BB3C-9295F586D1FF@ipfw.ru> References: <9BD54A54-A809-4D3E-BCBA-639E6C61FE37@FreeBSD.org> <4E70D6D2-4E80-4AAD-BB3C-9295F586D1FF@ipfw.ru> From: Mateusz Guzik Date: Fri, 23 Dec 2022 16:27:53 +0100 Message-ID: Subject: Re: Is it possible to employ epoch to simplify managing prison lifecycle To: "Alexander V. Chernikov" Cc: Zhenlei Huang , freebsd-jail@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4NdrfM5Pvyz3w38 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 12/23/22, Alexander V. Chernikov wrote: > > >> On 16 Dec 2022, at 16:29, Mateusz Guzik wrote: >> >> On 12/16/22, Zhenlei Huang wrote: >>> Hi, >>> >>> While hacking `sys/kern/kern_jail.c` I got lost. >>> >>> There're lots of ref / unref and flags to prevent visit invalid prison >>> while >>> concurrent modification is possible and some refs looks weird. >>> >>> Is it possible to employ epoch(9) to simplify managing of prison >>> lifecycle >>> ? >>> >> >> 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. >> >> 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 th= at one. > Do you envision similar semantics as Linux percpu_ref? I mean, does one n= eed > to explicitly mark =E2=80=9Cnot in active use=E2=80=9D stage? There *something* needed to disable per-cpu operation, otherwise how can you ever know if the count is 0, apart from going over all cpus every time, which defeats the point. More specifically, I have a on/off switch for said per-cpu op. This is modeled after what I did for counters in vfs, see vfs_ref et al. --=20 Mateusz Guzik