From nobody Mon Oct 7 05:05:19 2024 X-Original-To: freebsd-hackers@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 4XMRtS6Sl3z5Z1fr for ; Mon, 07 Oct 2024 05:05:36 +0000 (UTC) (envelope-from dcrosstech@gmail.com) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XMRtS4hMTz4cR9 for ; Mon, 7 Oct 2024 05:05:36 +0000 (UTC) (envelope-from dcrosstech@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qv1-xf36.google.com with SMTP id 6a1803df08f44-6cb3d2ce75eso43941096d6.0 for ; Sun, 06 Oct 2024 22:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728277536; x=1728882336; darn=freebsd.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=GAnTsx8737U0yzWk935qMkt/0nfXNdy1bIjUZAzffFQ=; b=m6xekl7fBWq3RzeFjsBXerqgwUn5VQOFVuEtuF7WA3l+BjzTw6L/Msh37hGamHSWn8 ARy+KwFKZVGCKlCJVNNgZFqbIht/LCs3aWBilgL7D1UI7ipUacWmNRkVuCTaOOdoC5ZC NNmHMJGy58GjyNDXQC8vi6JEdMo7y7eApqsFuEP7eJJttCUZDPa75bK2cXCXoRtNjocq xJzSK8rL4KEaGUQKx66gglYP706PaBBMT4lWndG0dPPZW8/ci8RCl8xsrC5TeFEBtcvr f50KCzqT3qmMTcA7w1kN7MQXUnuypgVDFyziHrUfIJEQcPDrD9z8BwTaFgQ0tbTavBm1 u4Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728277536; x=1728882336; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GAnTsx8737U0yzWk935qMkt/0nfXNdy1bIjUZAzffFQ=; b=t/qThifRAjH8tTZkY7GNoTGtpU3yOag0YBvpdemMJNa+5057GguX/aWP1K9dxUz6PZ kZgAo/PiAjzrkhuEqg/qFZxRY/i/Lz4kjdW9n/mxcEmsSO2Hb/DjzFWNacJdnCCx1bzH FnPRBumOuEdWAkPlhFx5Do/Q1QooUwnFILwaRNB7OtFZE1I9i+aqioRaW1HLpDGM/NbU fuVDFVS/1iRhDWojvDCv653k9eqs1JvwjsAB7OhsJj7mmidlYxIcgyW9vvSpPkgrCJrw 9KIEzXRh2NOT5G7TLD8wtAlpAKo5da6kZs0OKobsgVcIeCILxRfz4qD7LtRIVQDys+tu YjtQ== X-Gm-Message-State: AOJu0Ywy2L8mdqF4AB4Tocn2dj64VujBZRlzH/eWJWjmHok2X+5ETdXF cbLMzTi2wHIjFhSlH9wmq4UCC6bbzrJbMXGFSEFjsdjAd4Mh38l2Rt9Sqg== X-Google-Smtp-Source: AGHT+IEsfrxMZ3G/1K+OJDawEx5ybUGPFTsharMZu8R0Z/Fp1zz9eA+x24pyr+RuELZkzFYGyDPh0Q== X-Received: by 2002:a05:6214:5c44:b0:6cb:584f:ec22 with SMTP id 6a1803df08f44-6cb9ae07b6fmr156818766d6.21.1728277535862; Sun, 06 Oct 2024 22:05:35 -0700 (PDT) Received: from smtpclient.apple (syn-024-097-005-251.biz.spectrum.com. [24.97.5.251]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6cba47513acsm22050856d6.101.2024.10.06.22.05.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Oct 2024 22:05:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Cross List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 (1.0) Subject: Re: Review D38047 ... and then there was one.... Date: Mon, 7 Oct 2024 01:05:19 -0400 Message-Id: References: <1fd47603-0bf2-4fcf-a556-22335d99e203@plan-b.pwste.edu.pl> Cc: freebsd-hackers@freebsd.org In-Reply-To: <1fd47603-0bf2-4fcf-a556-22335d99e203@plan-b.pwste.edu.pl> To: Marek Zarychta X-Mailer: iPhone Mail (22A3370) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4XMRtS4hMTz4cR9 X-Spamd-Bar: ---- How many entries are in your ldap structure? I can attempt a replication he= re > On Oct 7, 2024, at 12:08=E2=80=AFAM, Marek Zarychta wrote: >=20 > =EF=BB=BFW dniu 7.10.2024 o 00:36, Mark Millard pisze: >> Marek Zarychta wrote on >> Date: Sun, 06 Oct 2024 20:13:58 UTC : >>=20 >>> W dniu 6.10.2024 o 22:04, David Cross pisze: >>>> Here=E2=80=99s the thing. The current implementation of nscd DOESN=E2=80= =99T WORK at all. There is a symbol that nscd exports that libc is supposed t= o use as a flag to bypass lookups for nscd itself. But that symbol isn=E2=80= =99t exported right. >>>>=20 >>>> You will need to recompile libc and nscd. (I just do a buildworld to ma= ke sure i get everything as there are makefile changes related to the aforem= entioned symbol changes. >>> Yes, without world installed this patched nscd won't even start: >>>=20 >>> [host] /usr/src# service nscd start >>> Starting nscd. >>> limits: setrlimit pipebuf: Invalid argument >>> /etc/rc.d/nscd: WARNING: failed to start nscd >> . . . >>=20 >> This note is only about the "limits: setrlimit pipebuf: >> Invalid argument" notice. >>=20 >> The main [so: 15] pipebuf related commits were done during >> 2024-Sep-20 UTC. If one has a kernel that predates those but >> a world for which limits now tries to use the new pipebuf >> material, the result is messages like that: >>=20 >> limits: setrlimit pipebuf: Invalid argument >>=20 >> (or related such messages). >>=20 >>=20 >> For reference for main [so: 15]: >>=20 >> Fri, 20 Sep 2024 >> . . . >> =E2=80=A2 git: 3458bbd39778 - main - kernel: add RLIMIT_PIPEBUF Konst= antin Belousov >> =E2=80=A2 git: 54a8d1fbbf65 - main - getrlimit(2): document RLIMIT_PI= PEBUF Konstantin Belousov >> =E2=80=A2 git: a4c04958f526 - main - libutil: support RLIMIT_PIPEBUF K= onstantin Belousov >> =E2=80=A2 git: 5d92f20c7d31 - main - bin/sh: support RLIMIT_PIPEBUF K= onstantin Belousov >> =E2=80=A2 git: f54f41403d14 - main - usr.bin/limits: support RLIMIT_P= IPEBUF Konstantin Belousov >> =E2=80=A2 git: b029e29e0d8b - main - login.conf: add a placeholder fo= r the pipebuf limit Konstantin Belousov >> =E2=80=A2 git: 80133d678ecb - main - procstat: support RLIMIT_PIPEBUF= Konstantin Belousov >> =E2=80=A2 git: 8ae779832c6f - main - privs: add PRIV_PIPEBUF Konstant= in Belousov >> =E2=80=A2 git: 7672cbef2c1e - main - pipes: reserve configured percen= tage of buffers zone to superuser Konstantin Belousov >> . . . >> =E2=80=A2 git: d6074f73af5c - main - pipe: use pipe subsystem KVA cou= nter instead of pipe_map size Konstantin Belousov >> =E2=80=A2 git: 40769168a5ee - main - pipespace_new(): decrease uidinf= o pipebuf usage if reservation check failed Konstantin Belousov >> . . . >> =E2=80=A2 git: a52b30ff98cd - main - sys_pipe: consistently use cr_ru= idinfo for accounting of pipebuf Konstantin Belousov >> =E2=80=A2 git: af96ccc6a508 - main - uifree(9): report non-zero value= s for all shared resources Konstantin Belousov >> =E2=80=A2 git: 2c1963d46335 - main - procfs rlimit: handle pipebuf Ko= nstantin Belousov >> =E2=80=A2 git: c84d8db0ab3d - main - procfs: ensure that RLIMIT_IDENT= is properly updated when a limit is added Konstantin Belousov >>=20 >> The combination of an older kernel and a newer world will not be >> nicely behaved when any non-kernel code from the above ends up >> involved. >>=20 >>=20 >> stable/14 has now also had the commits: >>=20 >> Sat, 05 Oct 2024 >> =E2=80=A2 git: 1508dce2502d - stable/14 - procfs: ensure that RLIMIT_= IDENT is properly updated when a limit is added Konstantin Belousov >> . . . >> =E2=80=A2 git: b7eecc86c3bd - stable/14 - kernel: add RLIMIT_PIPEBUF K= onstantin Belousov >> =E2=80=A2 git: d20f0dae2f97 - stable/14 - getrlimit(2): document RLIM= IT_PIPEBUF Konstantin Belousov >> =E2=80=A2 git: a03f7c040ce7 - stable/14 - libutil: support RLIMIT_PIP= EBUF Konstantin Belousov >> =E2=80=A2 git: d5ed8778bf3b - stable/14 - bin/sh: support RLIMIT_PIPE= BUF Konstantin Belousov >> =E2=80=A2 git: 25902860b270 - stable/14 - usr.bin/limits: support RLI= MIT_PIPEBUF Konstantin Belousov >> =E2=80=A2 git: 524b9810de6a - stable/14 - login.conf: add a placehold= er for the pipebuf limit Konstantin Belousov >> =E2=80=A2 git: 6600090e678e - stable/14 - procstat: support RLIMIT_PI= PEBUF Konstantin Belousov >> =E2=80=A2 git: fd9babb1b85f - stable/14 - privs: add PRIV_PIPEBUF Kon= stantin Belousov >> =E2=80=A2 git: d532d9926ee7 - stable/14 - pipes: reserve configured p= ercentage of buffers zone to superuser Konstantin Belousov >> =E2=80=A2 git: 6536b979b856 - stable/14 - pipe: use pipe subsystem KV= A counter instead of pipe_map size Konstantin Belousov >> =E2=80=A2 git: a8c663bb4261 - stable/14 - pipespace_new(): decrease u= idinfo pipebuf usage if reservation check failed Konstantin Belousov >> =E2=80=A2 git: c15b2e046e8c - stable/14 - sys_pipe: consistently use c= r_ruidinfo for accounting of pipebuf Konstantin Belousov >> . . . >> =E2=80=A2 git: fc9070bf1d16 - stable/14 - procfs rlimit: handle pipeb= uf Konstantin Belousov >> . . . >>=20 >> Again, the combination of an older kernel and a newer world will not be >> nicely behaved. >>=20 >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >>=20 >>=20 >>=20 > Thank you for this deep investigation. Anyway, after the kernel and world u= pdate, I could test the patch, but there was no significant progress, at lea= st in lookup timing (as I pointed out before). >=20 > -- > Marek Zarychta >=20 >=20