Jakub Głogowski [Fri, 14 Nov 2025 14:29:30 +0000 (15:29 +0100)]
man/man7/ip.7: Clarify IP_PKTINFO's semantics depending on packet direction
For recvmsg(2), ipi_spec_dst is set by ipv4_pktinfo_prepare() to the
result of fib_compute_sec_dst(). The latter was introduced in
linux.git 35ebf65e851c6d97 ("ipv4: Create and use fib_compute_spec_dst() helper.").
Quoting its commit message:
> The specific destination is the host we direct unicast replies to.
> Usually this is the original packet source address, but if we are
> responding to a multicast or broadcast packet we have to use something
> different.
>
> Specifically we must use the source address we would use if we were to
> send a packet to the unicast source of the original packet.
Experimentation seems to confirm that behavior.
As for the note about ipi_spec_dst being on a different interface:
- For unicast packets (for which ipi_spec_dst is the original
destination address), I believe this is trivially true because Linux
uses the weak host model (unless there's some interaction with
RTCF_LOCAL that I'm missing).
- For multicast/broadcast packets, fib_compute_sec_dst() only passes the
original interface to the lookup in the context of L3M. In
particular, the original implementation (cited above) set iif and oof
to 0. Also, citing
linux.git e7372197e15856ec ("net/ipv4: Set oif in fib_compute_spec_dst"),
> If the device is not enslaved, oif is still 0 so no affect.
It doesn't seem like using an address specifically from the interface
the packet was received on was ever the intention. I've also confirmed
this behavior (sending a multicast packet from another machine, whose IP
I've routed to a dummy interface).
I'm focusing on this because that's a misconception I've had before
digging into the code - the sendmsg behavior explained in the same
paragraph made me think ipi_spec_dst was the (primary?) address of
ipi_ifindex. I think this is worth clarifying.
I've made it explicit that ipi_addr isn't used by sendmsg because that's
another possible misconception.
The (first) extra comma in sendmsg's ipi_spec_dst's description is meant
to emphasize that it's used as the local source address _and_ for the
routing table lookup, as opposed to just affecting the routing table
lookup.
Stylistically it might be a bit weird but idk how to convey this better.
Apart from the cited commits I was referencing the linux-6.17.7 tarball.
__fib_validate_source (and the comment near it) might also be of
interest to people trying to figure out what "specific destinations"
are, exactly.
Signed-off-by: Jakub Głogowski <not@dzwdz.net>
Message-ID: <fb3980b64d1c827ad59726bb30761d735396e109.1763130571.git.not@dzwdz.net> Cc: <linux-kernel@vger.kernel.org> Cc: <linux-api@vger.kernel.org> Cc: Jan Engelhardt <ej@inai.de> Signed-off-by: Alejandro Colomar <alx@kernel.org>
man/man2/flock.2: Mention non-atomicity w.r.t close
Ideally one should be able to use flock to synchronize with another
process (or thread) closing that file, for instance before attempting
to execve it (as execve of a file open for writing fails with ETXTBSY).
Unfortunately, on Linux it is not reliable, because in the process of
closing a file its locks are dropped before the refcounts of the file
(as well as its underlying filesystem) are decremented, creating a race
window where execve of the just-unlocked file sees it as if still open.
Linux developers have indicated that it is not easy to fix, and the
appropriate course of action for now is to document this limitation.
Signed-off-by: Alexander Monakov <amonakov@ispras.ru>
Message-ID: <181d561860e52955b29fe388ad089bde4f67241a.1760627023.git.amonakov@ispras.ru> Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Usama Arif [Wed, 5 Nov 2025 13:48:11 +0000 (13:48 +0000)]
man/man2/madvise.2, man/man2const/PR_[GS]ET_THP_DISABLE.2const: document addition of PR_THP_DISABLE_EXCEPT_ADVISED
PR_THP_DISABLE_EXCEPT_ADVISED extended PR_SET_THP_DISABLE to only provide
THPs when advised. IOW, it allows individual processes to opt-out of
THP = "always" into THP = "madvise", without affecting other workloads
on the system. The series has been merged in [1]. Before [1], the
following 2 calls were allowed with PR_SET_THP_DISABLE:
This patch documents the changes introduced due to the addition of
PR_THP_DISABLE_EXCEPT_ADVISED flag:
- PR_GET_THP_DISABLE returns a value whose bits indicate how
THP-disable is configured for the calling thread (with or without
PR_THP_DISABLE_EXCEPT_ADVISED).
- PR_SET_THP_DISABLE now uses arg3 to specify whether to disable THP
completely for the process, or disable except madvise
(PR_THP_DISABLE_EXCEPT_ADVISED).
This was necessary when we used one pcre2grep(1) call per regex.
but long ago we switched to a single pcre2grep(1) call for all regexes,
which only prints each file once, and thus we don't need uniq(1).
src/bin/grepc_c: Split grepc_c_body_() and grepc_c_u_body_()
grepc_c_u_body_() consumes a lot of resources unnecessarily.
This is especially true within grepc_c_t_td_braced(), which was crashing
with relatively small code. The reason is that grepc_c_t_td_braced()
searches for code where the identifier is last, so it needs to store
a lot of code just in case. For that, an optimized grepc_c_body_() is
more appropriate.
In the last case, it removes part of the regex, but I believe that
wasn't necessary.
Also, while at this, make the trailing of the regexes to be consistently
'[^;];', which is simpler, and seems to work just fine. If we ever see
some false positives or negatives with this regex, we should fix them
all at once, and maybe put them in a helper function.
src/bin/grepc_c: -tum: Split regex part for the replacement list
While splitting, improve the regex part in two ways:
- Use a non-capturing group. This improves performance.
- Use negative lookahead instead of '[^\\]$'. This allows matching
a macro where the searched identifier is the last thing in the
replacement list.
The regex for a function declarator is too complex. Split it into
helper functions that prints the parts of the regex, so that each one
is easier to understand.
src/bin/grepc{,_c,_mk}: Split grepc(1) into helper programs
These programs print the PCRE2 patterns used by grepc(1). This allows
easily implementing different drivers for parsing different languages.
It also allows easily using pcre2grep(1) in cases where grepc(1) might
be limited; for example, searching in non-regular files, or passing
other flags that grepc(1) doesn't pass to pcre2grep(1).
'xargs grep' is hard, because grep(1) exits with a status of 1 for no
match, which is not an error, but xargs(1) takes that as an error, which
is confused with other errors.
This trick with sh(1) was suggested by Paul, and nicely solves this
problem.
We also need to change $opts to be a normal variable.
We can't export bash array variables, and passing them to sh(1) -c is
not great; escapes could be messed. It's more robust to use a normal
variable.
Link: <https://lists.gnu.org/archive/html/bug-grep/2025-10/msg00029.html> Suggested-by: Paul Eggert <eggert@cs.ucla.edu> Signed-off-by: Alejandro Colomar <alx@kernel.org>
If nothing matches, it's a success, and it exits with 0 normally.
This is different from grep(1), but I don't know how to write
the script to exit with 1 if nothing matches.
This implementation may also ignore some xargs(1) errors. A future
commit --with code suggested by Paul Eggert-- will fix this.
In theory, getopts(1) will make sure that no other values arrive here.
However, it's easy to add a check, and that will be safer than silencing
shellcheck(1).
Import grepc(1) (script and manual page) from separate project
It started as a script in the Linux man-pages project, under scripts/
within scripts/bash_aliases.
Eventually, I turned it into a large script, and moved it into a
separate project, to be able to work on it more freely.
The original scripts were removed from this project in commit c3752af0549c (2022-11-22; "bash_aliases: Remove grep_syscall(),
grep_syscall_def(), and grep_glibc_prototype()").
Now, grepc(1) has stabilized, and I find it very useful for maintaining
this project (as well as others), so let's merge it back. This will
allow distros to package it sooner than if it remained as a standalone
project.
I've imported the git history (ignoring files we don't care about) with
the help of git-filter-repo(1).
Files are simpler to handle. It results in less flags, and simpler
command invocations. And it allows breaking the line more nicely,
without having to break in the middle of a quoted region.
projects / thirdparty / man-pages.git / log
