All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: DJ Delorie <dj@redhat.com>
Cc: linux-man@vger.kernel.org
Subject: Re: [PATCH v5 2/4] man/man5/tunables.conf: Document system-wide tunables config
Date: Fri, 7 Aug 2026 02:11:01 +0200	[thread overview]
Message-ID: <anUiQua2QnWnzBeR@devuan> (raw)
In-Reply-To: <anUbLZzOLY2qM6iP@devuan>

[-- Attachment #1: Type: text/plain, Size: 3104 bytes --]

> Date: 2026-08-07 02:07:00+0200
> From: Alejandro Colomar <alx@kernel.org>
>
> Hi DJ,
> 
> > Date: 2026-08-06 18:15:15-0400
> > From: DJ Delorie <dj@redhat.com>
> >
> > Alejandro Colomar <alx@kernel.org> writes:
> > > You forgot to sign.
> > 
> > I will never remember that... :-P
> > 
> > >> +The resulting data is read when a new process is created by
> > >> +.IR ld.so .
> > >
> > > Sorry for noticing this in v4; I forgot about it.  I see this unresolved
> > > issue from earlier versions remains.
> > 
> > A program is a file on disk.  A process is a running memory image.
> 
> Yup.  fork(3) creates a process (produces a new PID).  execve(2)
> replaces the image of the current process with a program read from disk
> (or in short, executes a program in the current process).
> 
> > 
> > Neither fork() nor exec() cause the tunables to be loaded, the process
> > itself has to do that.  For dynamic ELF programs/processes built with
> > glibc, ld.so does it before it passes control to the ELF image.  There
> > are other types of programs/processes that do not use ld.so and thus do
> > not read the tunables cache (which is called "ld.so.cache" for a reason ;-)
> 
> Hmmmmm, let's say you call execve(2) several times without any fork(2)s.
> Assuming a that the program paths that you pass to execve(2) are all
> dynamic ELF programs built with glibc, I guess for every time you call
> execve(2), ld.so(8) will be run, and the tunables stored in ld.so.cache
> will be used.  Is this correct?
> 
> 	#include <unistd.h>
> 	int
> 	main(int, char *argv[])
> 	{
> 		sleep(1);
> 		execve("proc/self/exe", argv, NULL);
> 	}

Oh, I thought this would work as a recursive infinite-loop program.  It
doesn't seem to work.  I guess there's some race condition?  :D

	alx@devuan:~$ cd tmp/
	alx@devuan:~/tmp$ cat ex.c 
	#include <unistd.h>
	int
	main(int, char *argv[])
	{
		sleep(1);
		execve("proc/self/exe", argv, NULL);
	}

	alx@devuan:~/tmp$ gcc -Wall -Wextra ex.c 
	alx@devuan:~/tmp$ time ./a.out 

	real	0m1.003s
	user	0m0.003s
	sys	0m0.000s


Cheers,
Alex

> 
> Let's also say you fork(2) several times, without any execve(2) calls.
> I suppose that won't trigger any of this, right?
> 
> 	#include <unistd.h>
> 	int
> 	main(void)
> 	{
> 		for (int i = 0; i < 10; i++) {
> 			sleep(1);
> 			fork();
> 		}
> 	}
> 
> From my understanding, only the first program will trigger this more
> than once, right?
> 
> If so, I'd use the same wording that execve(2) uses:
> 
> 	execve() executes the program referred to by path.
> 
> That is, execve(2) executes programs, and ld.so.cache is read when
> a program is executed (in the current process).
> 
> > 
> > I don't know how to say this clearly with fewer words...
> > 
> > >> +The syntax allows lines to start with the keyword
> > >> +.I include
> > >
> > > s/I/B/  (since it's a literal, not a variable)
> > 
> > Fixed.
> > 
> 
> 
> Cheers,
> Alex
> 
> -- 
> <https://www.alejandro-colomar.es>



-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2026-08-07  0:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-06 20:44 [PATCH v5 2/4] man/man5/tunables.conf: Document system-wide tunables config DJ Delorie
2026-08-06 22:02 ` Alejandro Colomar
2026-08-06 22:15   ` DJ Delorie
2026-08-07  0:06     ` Alejandro Colomar
2026-08-07  0:11       ` Alejandro Colomar [this message]
2026-08-07  0:15         ` Alejandro Colomar
2026-08-07  3:25       ` DJ Delorie
2026-08-07 22:36         ` Alejandro Colomar
2026-08-08  3:08           ` DJ Delorie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=anUiQua2QnWnzBeR@devuan \
    --to=alx@kernel.org \
    --cc=dj@redhat.com \
    --cc=linux-man@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.