Date: Sun, 6 Oct 2024 00:40:44 -0700 From: Mark Millard <marklmi@yahoo.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Current FreeBSD <freebsd-current@freebsd.org>, dev-commits-src-main@freebsd.org, Konstantin Belousov <kib@freebsd.org> Subject: Re: git: 2c1963d46335 - main - procfs rlimit: handle pipebuf [and related] :pipebuf . . . Invalid argument Message-ID: <C419D98F-7A9F-46F2-8951-08D545DEA641@yahoo.com> In-Reply-To: <ZwIuobzcUZxm-H0y@kib.kiev.ua> References: <34434D36-A751-477A-8596-72A564113FB8.ref@yahoo.com> <34434D36-A751-477A-8596-72A564113FB8@yahoo.com> <ZwIuobzcUZxm-H0y@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 5, 2024, at 23:30, Konstantin Belousov <kostikbel@gmail.com> = wrote: > On Sat, Oct 05, 2024 at 06:14:40PM -0700, Mark Millard wrote: >> Konstantin Belousov <kib_at_FreeBSD.org> wrote on >> Date: Fri, 20 Sep 2024 21:09:29 UTC : >>=20 >>> The branch main has been updated by kib: >>>=20 >>> URL: = https://cgit.FreeBSD.org/src/commit/?id=3D2c1963d46335576d29fe21a4e7b424c4= 7b711ef4 >>>=20 >>> commit 2c1963d46335576d29fe21a4e7b424c47b711ef4 >>> Author: Konstantin Belousov <kib@FreeBSD.org> >>> AuthorDate: 2024-09-20 15:04:06 +0000 >>> Commit: Konstantin Belousov <kib@FreeBSD.org> >>> CommitDate: 2024-09-20 21:08:51 +0000 >>>=20 >>> procfs rlimit: handle pipebuf >>>=20 >>> Sponsored by: The FreeBSD Foundation >>> MFC after: 1 week >>> --- >>> sys/sys/resource.h | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>=20 >>> diff --git a/sys/sys/resource.h b/sys/sys/resource.h >>> index c18e45d50b30..81346028f1ed 100644 >>> --- a/sys/sys/resource.h >>> +++ b/sys/sys/resource.h >>> @@ -127,7 +127,7 @@ struct __wrusage { >>> */ >>>=20 >>> #ifdef _RLIMIT_IDENT >>> -static const char *rlimit_ident[RLIM_NLIMITS] =3D { >>> +static const char *rlimit_ident[] =3D { >>> "cpu", >>> "fsize", >>> "data", >>> @@ -143,6 +143,7 @@ static const char *rlimit_ident[RLIM_NLIMITS] =3D = { >>> "swap", >>> "kqueues", >>> "umtx", >>> + "pipebuf", >>> }; >>> #endif >>=20 >> As part of an experiment I just had 1500024 (somewhat after the >> libmd.so.{6 -> 7} update) boot with a 1500023 kernel that was >> somewhat before the fairly recent pipebuf related changes, such >> as the above. This produced a bunch of error messages, such as: >>=20 >>=20 >> . . . >> ugen0.7: <Microchip Hub Feature Controller> at usbus0 (disconnected) >> Warning: no time-of-day clock registered, system time will not be set = accurately >> 2024-10-05T17:33:58.032649-07:00 - init 20 - - getting pipebuf = resource limit: Invalid argument >> . . . >> Starting devd. >> limits: setrlimit pipebuf: Invalid argument >> /etc/rc: WARNING: failed to start devd >> Waiting 30s for the default route interface: = ............................. >> . . . >> Starting syslogd. >> limits: setrlimit pipebuf: Invalid argument >> /etc/rc: WARNING: failed to start syslogd >> . . . >> Starting rpcbind. >> limits: setrlimit pipebuf: Invalid argument >> /etc/rc: WARNING: failed to start rpcbind >> NFS access cache time=3D60 >> Starting ntpd. >> limits: setrlimit pipebuf: Invalid argument >> /etc/rc: WARNING: failed to start ntpd >> . . . >> Starting rpcbind. >> limits: setrlimit pipebuf: Invalid argument >> /etc/rc.d/mountd: WARNING: Unable to force rpcbind. It may already be = running. >> Starting mountd. >> limits: setrlimit pipebuf: Invalid argument >> /etc/rc: WARNING: Unable to force mountd. It may already be running. >> /etc/rc: WARNING: failed precmd routine for nfsd >> . . . >> Starting sshd. >> limits: setrlimit pipebuf: Invalid argument >> /etc/rc: WARNING: failed to start sshd >> Starting cron. >> limits: setrlimit pipebuf: Invalid argument >> /etc/rc: WARNING: failed to start cron >> . . . >> 2024-10-06T00:34:50.800786-07:00 aarch64-main-pbase init 1014 - - = getting pipebuf resource limit: Invalid argument >> 2024-10-06T00:34:50.800858-07:00 aarch64-main-pbase init 1015 - - = getting pipebuf resource limit: Invalid argument >> 2024-10-06T00:34:50.800939-07:00 aarch64-main-pbase init 1016 - - = getting pipebuf resource limit: Invalid argument >> 2024-10-06T00:34:50.801101-07:00 aarch64-main-pbase init 1018 - - = getting pipebuf resource limit: Invalid argument >> 2024-10-06T00:34:50.801090-07:00 aarch64-main-pbase init 1017 - - = getting pipebuf resource limit: Invalid argument >> 2024-10-06T00:34:50.801240-07:00 aarch64-main-pbase init 1020 - - = getting pipebuf resource limit: Invalid argument >> 2024-10-06T00:34:50.801250-07:00 aarch64-main-pbase init 1019 - - = getting pipebuf resource limit: Invalid argument >> 2024-10-06T00:34:50.801406-07:00 aarch64-main-pbase init 1021 - - = getting pipebuf resource limit: Invalid argument >> ugen0.6: <PixArt USB Optical Mouse> at usbus0 >> 2024-10-06T00:35:08.833554-07:00 aarch64-main-pbase login 1014 - - = login on ttyv0 as root >> 2024-10-06T00:35:08.833623-07:00 aarch64-main-pbase login 1014 - - = ROOT LOGIN (root) ON ttyv0 >> 2024-10-06T00:35:08.835269-07:00 aarch64-main-pbase login 1022 - - = getting pipebuf resource limit: Invalid argument >> . . . >>=20 >>=20 >> It seems related changes introducing incompatibility with even >> recent older kernels should have had a __FreeBSD_version update >> and might need to be documented for the now-existing >> incompatibility with most of the 1500023 and older history? >=20 > We do not provide forward compatibility between kernel and userspace. > User binaries must be newer than kernel. Well, the official port-packing builders frequently use combinations like: Host OSVERSION: 1500023 [So: kernel and world] Jail OSVERSION: 1500024 [So: Jail world, still 1500023 kernel] I temporarily had kernel: 1500023 (not very old) and world: 1500024, no jail or chroot involved in the activity. [This was by accident of timing, not a deliberate status.] I expect that a world from just before 1500024 would have had the same sort of results, with both then being 1500023, which is part of why I reported what I did. [The change to 1500024 is not tied to the pipebuf changes but to libmd updates.] Are you suggesting that I should not expect two 1500023's (one kernel, one world) to be compatible unless I also know the more detailed timing relationship within 1500023's span? I though the ordering principles were for across distinct values, not for the same value. If I was wrong, it would be good to know that explicitly. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C419D98F-7A9F-46F2-8951-08D545DEA641>