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:06:57 +0200	[thread overview]
Message-ID: <anUbLZzOLY2qM6iP@devuan> (raw)
In-Reply-To: <xnwlu23ngs.fsf@greed.delorie.com>

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

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);
	}

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>

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

  reply	other threads:[~2026-08-07  0:07 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 [this message]
2026-08-07  0:11       ` Alejandro Colomar
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=anUbLZzOLY2qM6iP@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.