From nobody Tue Jan 10 02:05:04 2023 X-Original-To: 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 4NrYzk6Y4hz2p1ZS for ; Tue, 10 Jan 2023 02:05:06 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from glebi.us (glebi.us [162.251.186.162]) by mx1.freebsd.org (Postfix) with ESMTP id 4NrYzj4JXWz3jx0; Tue, 10 Jan 2023 02:05:05 +0000 (UTC) (envelope-from glebius@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 162.251.186.162 is neither permitted nor denied by domain of glebius@freebsd.org) smtp.mailfrom=glebius@freebsd.org; dmarc=none Received: by glebi.us (Postfix, from userid 1000) id 0BE96C075; Mon, 9 Jan 2023 18:05:05 -0800 (PST) Date: Mon, 9 Jan 2023 18:05:04 -0800 From: Gleb Smirnoff To: "Bjoern A. Zeeb" Cc: Andrew Gallatin , "pjd@FreeBSD.org" , James Gritton , jail@freebsd.org Subject: Re: prison_flag() check in hot path of in_pcblookup() Message-ID: References: <6on81os3-501-s5n2-8nos-p85n8op23232@serrofq.bet> <6r10qop4-7p83-qs6s-q3r0-64756n243rp5@serrofq.bet> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6r10qop4-7p83-qs6s-q3r0-64756n243rp5@serrofq.bet> X-Spamd-Result: default: False [0.51 / 15.00]; VIOLATED_DIRECT_SPF(3.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.989]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; MLMMJ_DEST(0.00)[jail@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; FREEFALL_USER(0.00)[glebius]; TO_DN_EQ_ADDR_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-Rspamd-Queue-Id: 4NrYzj4JXWz3jx0 X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N On Tue, Dec 13, 2022 at 11:54:17PM +0000, Bjoern A. Zeeb wrote: B> On Tue, 13 Dec 2022, Andrew Gallatin wrote: B> B> > [ I added pjd, since the original patch came from him ] B> > B> > Just to make sure I understand, I have a simple yes/no question: B> > B> > Can jails and the host ever share the same (local) port and the same IP? B> B> Can they currently (I tested only for TCP)? B> B> - local binds can overlap like they can with just the base system. B> so bind(... {AF_INET, laddr, lport} ... ) works fine (REUSEPORT). B> B> - tcp connect of a 2nd socket to the same {faddr, fport} from the above B> bind will fail with 'Address already in use' [currently] B> [I believe that would mean your patch could go in? Where does the error come from [%]?] [*] My reading of code confirms your tests. The official way to insert a tuple is in_pcbconnect_setup() which branches into either its own check with in_pcblookup_hash_locked() and returns EADDRINUSE or runs in_pcb_lport_dest() which would also use in_pcblookup_hash_locked() to check for existing entries. Thus, with official KPI it is impossible to insert two completely identical 4-tuples. Alas, we have in_pcbinshash() exposed outside, as it is expected to be called after in_pcblookup_hash_locked(), so there is no 100% source code protection from having identical tuples. ... and I'm lost in researching all possible scenarios that edit the database. We need to tighten this KPI. Anyway, given tests that Bjoern did, given lack of official tests in src/tests/sys and overall agreement on this code looking strange, I'd suggest to go forward with Drew's suggestion: https://reviews.freebsd.org/D38015 What's your opinion? Given that code comes from Drew I'd suggest him to either commandeer the revision and commit himself, or let me commit & push with --author. Or I can commit with my name and be fully resposible for the fallout :) -- Gleb Smirnoff From nobody Tue Jan 17 10:02:31 2023 X-Original-To: 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 4Nx4FM3Tcqz2sr28 for ; Tue, 17 Jan 2023 10:02:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Nx4FM2SdZz3mLJ for ; Tue, 17 Jan 2023 10:02:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1673949751; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=m61cvJq8vVyh3LF8UmzxxazHgrrqf90s9J+J0ItTsqs=; b=hzBbgBI0Xm8DiEkS9PoD04ARAE+PMvAbyGnkkDGql92JclQOsqWkPBLLyoVnjtcZRRoPKW 6Fje+Q2TfOwq3O4F8EkPkNC0mwkUgy/UAk5WmSkrJ/HI1zf0o//S/cANnMKUPFoaSjexaH 7BaAl2A3mu1I2rYEEzJIvhLTItl3YPGjAsIqLKL+UL325nM2sKDCUx6ZREEBg6ZReC9sLF WpAAC3h/ZYiwfgmjWrS55RoJfXL9EFNXzgc52U0T/9amI2XxsMwSzH8Tc3jcV+VnYxccmW JlnVgrrMhE7j7F4PdSawxQjtV3no8FWgGvQh/KzcsSWdzCjThSolp92teTt7fw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1673949751; a=rsa-sha256; cv=none; b=XlgPVZ/pEFKsAtQ0VHpgZn6XsmN2ufpONrK9rstUshnPbVE+wayq5lVqkN0eWNujJYZ2JC nNhxKyD1C7MgbFVxsDFERp5tDtMa6uABCoE7hmGd5F4g6cYaXrlNM0F9GtgQN6W9sOO6wn aO+uLxxzFjLpDP9q9crZ2udBf8zoHbKp9qWKgoiTdpf6ow0fPb4HbfS3+GUaRQO2V4jV5B IBjV1qcD4KrdhD64B9EFwSoWgcFjd+PNck2T5BNuiKeQh/pSM++kJ5gR7sIl7AuyuR1rlX 6VVFe6e8IQyjOjZublu/yiCQDt9kgKVPxXaBi9DSeq82akgl+T9NcujWKZt0qQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Nx4FM1YVjzSKx for ; Tue, 17 Jan 2023 10:02:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 30HA2VkM084693 for ; Tue, 17 Jan 2023 10:02:31 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 30HA2VsQ084692 for jail@FreeBSD.org; Tue, 17 Jan 2023 10:02:31 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: jail@FreeBSD.org Subject: [Bug 222951] Re-starting a jail with mount.devfs mounts devfs multiple times Date: Tue, 17 Jan 2023 10:02:31 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: zlei@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jail@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 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222951 --- Comment #2 from Zhenlei Huang --- (In reply to VK from comment #0) > The problem seems to be when the (nopersist) jail is stopped by itself be= cause all > the processes in it have exited, so it wasn't explicitly `jail -r`. When = that=20 > happens, devfs is not unmounted. For non-persist jails I think this is the expected behavior. `mount.devfs` is a pseudo-parameter and as per jail(8): > There are pseudo-parameters that are not passed to the kernel, but are > used by jail to set up the jail environment, often by running specifi= ed > commands when jails are created or removed. > So next time the jail is started, devfs is mounted again, resulting with = multiple=20 > mounts of devfs into $JAIL_ROOT/dev: Maybe we can teach /usr/sbin/jail to check existing mount of devfs(5) before starting jails. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Tue Jan 17 21:42:25 2023 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 4NxMn265zcz2v8ZV for ; Tue, 17 Jan 2023 21:42:30 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 4NxMn16D9Nz45C9; Tue, 17 Jan 2023 21:42:29 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="n3uHkk4/"; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::830 as permitted sender) smtp.mailfrom=markjdb@gmail.com; dmarc=none Received: by mail-qt1-x830.google.com with SMTP id j9so5640432qtv.4; Tue, 17 Jan 2023 13:42:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=btnAn5kINzIXY2RgOWClnEB3zfosTtjKd7wc1Mo1rmA=; b=n3uHkk4/9P3u+js4jadS1VEBXiN22v4+PDJrVHxYy3A58h89jlXXoErE9kaM7HSH9M reTmelC9Fxx5sXyi6xCOKcChveqyb2gbvRpKhRpTr9j/eFAXhpJCzkGicRAktiRrpGpw GXb1r24ZPl8gnPNSm4+NvrTgVqIZGTJIKmCZmo9O24McwSxBLv1jPOKO1HT2F5En4jBa 3rDOV0CyIeX/dOrSaA4F5PXQ9kfirblygv0niKw8nmvxeWp1zfRKYLShvIFkJl1cSjtS jic4sqY331At+X6IgJZzwY80VmHVgefZXQPo8E0aenlG5XVE8rYNg6HMpE0xE6f2srjt 9O6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=btnAn5kINzIXY2RgOWClnEB3zfosTtjKd7wc1Mo1rmA=; b=R7ZymDphDPsnFhl3H5BN4WJNGBvwIhRTIOoM49HY2Y5hu+5bAsb8lH2ZrGJYyk4bNN Sy5wgyovrveo9MUHwqOMy6o/qvzi5UTgdX1g/yo5itgHHcvo1NIz9bavMGDj+FJik+NV SRVHA6Po4TIZW4Bzu03XMxsbnNyV03sLvLglAJkR5jKMYMirOtBH8Uf03D5aLHL0Fso1 yDFGZMMFg5iJFSq70rU8U+bXL+fBU5sY3zPyK2+ARt49SfDwtfvh442zKtwrt5jUyI+t yyGdN5Ua4R9ybyxrJfZmO6H+vfAx3MPpyy2J9lVcCD5oRcCY0le5Vl9hVzwXCdR0C13D WVPg== X-Gm-Message-State: AFqh2kqJLdpfG/r6ycGzv55Q9Bu5HVA2V7lfW3Lwoyj6u6v7RXwqXi7e bDDOxuwXoIMStXUV1m5KbOWGkeOlNJw= X-Google-Smtp-Source: AMrXdXt4rEbgz1MSh043yxGFMdFz/S/ii6zshdW4RS0mrMAheCWvMcqQnJj1zmWrMreHFsvPRvkbCQ== X-Received: by 2002:a05:622a:508a:b0:3ac:77ed:3995 with SMTP id fp10-20020a05622a508a00b003ac77ed3995mr5240758qtb.26.1673991748547; Tue, 17 Jan 2023 13:42:28 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id b5-20020ac812c5000000b003b63dfad2b4sm1429090qtj.0.2023.01.17.13.42.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Jan 2023 13:42:27 -0800 (PST) Date: Tue, 17 Jan 2023 16:42:25 -0500 From: Mark Johnston To: "Bjoern A. Zeeb" Cc: Kyle Evans , Gleb Smirnoff , Zhenlei Huang , "freebsd-jail@freebsd.org" Subject: Re: What's going on with vnets and epairs w/ addresses? Message-ID: References: <5r22os7n-ro15-27q-r356-rps331o06so5@mnoonqbm.arg> <150A60D6-6757-46DD-988F-05A9FFA36821@FreeBSD.org> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-1.68 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.984]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; MLMMJ_DEST(0.00)[freebsd-jail@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::830:from]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCPT_COUNT_FIVE(0.00)[5]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+]; FREEMAIL_CC(0.00)[freebsd.org,gmail.com] X-Rspamd-Queue-Id: 4NxMn16D9Nz45C9 X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On Tue, Dec 20, 2022 at 08:50:09PM +0000, Bjoern A. Zeeb wrote: > On Tue, 20 Dec 2022, Mark Johnston wrote: > > > On Sun, Dec 18, 2022 at 10:52:58AM -0600, Kyle Evans wrote: > >> On Sat, Dec 17, 2022 at 11:22 AM Gleb Smirnoff wrote: > >>> > >>> Zhenlei, > >>> > >>> On Fri, Dec 16, 2022 at 06:30:57PM +0800, Zhenlei Huang wrote: > >>> Z> I managed to repeat this issue on CURRENT/14 with this small snip: > >>> Z> > >>> Z> ------------------------------------------- > >>> Z> #!/bin/sh > >>> Z> > >>> Z> # test jail name > >>> Z> n="test_ref_leak" > >>> Z> > >>> Z> jail -c name=$n path=/ vnet persist > >>> Z> # The following line trigger jail pr_ref leak > >>> Z> jexec $n ifconfig lo0 inet 127.0.0.1/8 > >>> Z> > >>> Z> jail -R $n > >>> Z> > >>> Z> # wait a moment > >>> Z> sleep 1 > >>> Z> > >>> Z> jls -j $n > >>> Z> > >>> Z> After DDB debugging and tracing , it seems that is triggered by a combine of [1] and [2] > >>> Z> > >>> Z> [1] https://reviews.freebsd.org/rGfec8a8c7cbe4384c7e61d376f3aa5be5ac895915 > >>> Z> [2] https://reviews.freebsd.org/rGeb93b99d698674e3b1cc7139fda98e2b175b8c5b > >>> Z> > >>> Z> > >>> Z> In [1] the per-VNET uma zone is shared with the global one. > >>> Z> `pcbinfo->ipi_zone = pcbstor->ips_zone;` > >>> Z> > >>> Z> In [2] unref `inp->inp_cred` is deferred called in inpcb_dtor() by uma_zfree_smr() . > >>> Z> > >>> Z> Unfortunately inps freed by uma_zfree_smr() are cached and inpcb_dtor() is not called immediately , > >>> Z> thus leaking `inp->inp_cred` ref and hence `prison->pr_ref`. > >>> Z> > >>> Z> And it is also not possible to free up the cache by per-VNET SYSUNINIT tcp_destroy / udp_destroy / rip_destroy. > >>> > >>> This is known issue and I'd prefer not to call it a problem. The "leak" of a jail > >>> happens only if machine is idle wrt the networking activity. > >>> > >>> Getting back to the problem that started this thread - the epair(4)s not immediately > >>> popping back to prison0. IMHO, the problem again lies in the design of if_vmove and > >>> epair(4) in particular. The if_vmove shall not exist, instead we should do a full > >>> if_attach() and if_detach(). The state of an ifnet when it undergoes if_vmove doesn't > >>> carry any useful information. With Alexander melifaro@ we discussed better options > >>> for creating or attaching interfaces to jails that if_vmove. Until they are ready > >>> the most easy workaround to deal with annoying epair(4) come back problem is to > >>> remove it manually before destroying a jail, like I did in 80fc25025ff. > >>> > >> > >> It still behaved much better prior to eb93b99d6986, which you and Mark > >> were going to work on a solution for to allow the cred "leak" to close > >> up much more quickly. CC markj@, since I think it's been six months > >> since the last time I inquired about it, making this a good time to do > >> it again... > > > > I spent some time trying to see if we could fix this in UMA/SMR and > > talked to Jeff about it a bit. At this point I don't think it's the > > right approach, at least for now. Really we have a composability > > problem where different layers are using different techniques to signal > > that they're done with a particular piece of memory, and they just > > aren't compatible. > > > > One thing I tried is to implement a UMA function which walks over all > > SMR zones and synchronizes all cached items (so that their destructors > > are called). This is really expensive, at minimum it has to bind to all > > A semi-unrelated question -- do we have any documentation around SMR > in the tree which is not in subr_smr.c? > > (I have to admit I find it highly confusing that the acronym is more > easily found as "Shingled Magnetic Recording (SMR)" in a different > header file). Sorry for the delayed reply, I was travelling for a few weeks and still haven't caught up. I did at least write a man page which notes the multiple meanings of that acronym. :) Comments and feedback are welcome: https://reviews.freebsd.org/D38108 From nobody Thu Jan 19 15:07:28 2023 X-Original-To: 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 4NyQwJ2cxKz2t8dc for ; Thu, 19 Jan 2023 15:07:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NyQwJ0Vpzz3hPh for ; Thu, 19 Jan 2023 15:07:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1674140848; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LLL3uT6Hdfjr9fx72nttvoVrddD85hl72x9C8NxRHws=; b=MU7bbt9dpBJ5zkeoYvA9h+nY8+nodruBvV6ciU4XHpPmp1dv6v7hdIXfxqNuejw7dD1QNe 0/FzopFIxKBX4aH3A5/WLzRd2gVUK6EOBE3pAHMU4/7h51EqJraTxK91XGWH4sL9q5dOBe NwZDwcFKDCY7ZMJae/XRitOJ97el9M0YSk7QcaQ/FmLR7ClwBhaFoZpF4qwNddDRd1zj1q bkXnicElZRrIGsoxvLceCii28Gh5RJ5z10cpr53rbIaUk9BtZaV5YeC5q9Bzhez4H7IPWR HTXAYmiyxMfnKXsiryndGpd1X9P4sUuxsynvPc95ECtY8KebYWmsV+R9bKga9g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1674140848; a=rsa-sha256; cv=none; b=msAUHTikI4uiPXwB4ayMYDPppuW/OGwOpOeif+4GyQnUASVIpTWu3bj7ND/Nv1To/XEYuw ioubkkHaUry6qZOdl5QBXmLeZUPXYq5vduMAivPBHSnCmNiJvAqYT+sNDkCGFye3VTpEng tfdUIQBk/rAWHpmy10TM7UE/oBT6tmeRH5Ita51SLbf7XKt4Np2CJQ5dU2cA2w57VIa74P hXzF1u+hi+dXrXn0ab+viOtQJnE4SSXYP1zhcJ8ZpxwoXZEctWwSHoldkvjZ7x83BeS3Vj 6AVbEu4pFdqfY09hziBgYTPIGoMBOf/yHt/1NKEAZhCA0+5/8HVWcyBj5a/4bg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4NyQwH6hcRzvGW for ; Thu, 19 Jan 2023 15:07:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 30JF7RWv045628 for ; Thu, 19 Jan 2023 15:07:27 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 30JF7Rsq045627 for jail@FreeBSD.org; Thu, 19 Jan 2023 15:07:27 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: jail@FreeBSD.org Subject: [Bug 228351] cannot unhide log or tty with devfs.rules Date: Thu, 19 Jan 2023 15:07:28 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: conf X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jail@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 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D228351 --- Comment #8 from commit-hook@FreeBSD.org --- A commit in branch stable/12 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3D4d8dd8c29480c4cb8985d65e10689ab83= dae4512 commit 4d8dd8c29480c4cb8985d65e10689ab83dae4512 Author: Zhenlei Huang AuthorDate: 2022-05-24 13:54:38 +0000 Commit: Zhenlei Huang CommitDate: 2023-01-19 15:01:00 +0000 devfs.rules: Do not expose "log" in the default devfs rules /etc/rc.d/jail no longer creates /dev/log as a symbolic link since commit 84b354cb9ab61224713c159b1484e8f070fd37be. PR: 228351 Reviewed by: jamie, markj Differential Revision: https://reviews.freebsd.org/D34563 (cherry picked from commit 2670ea8a075ea29a0eee9d227c4cdf585a7b3b55) (cherry picked from commit 02fe4484379c1e67c22ad6abbeea10c8a20d10eb) sbin/devfs/devfs.rules | 1 - 1 file changed, 1 deletion(-) --=20 You are receiving this mail because: You are the assignee for the bug.=