[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RFC] Various pages: Use consistent style for lists (.IP)
|
From: |
Alejandro Colomar |
|
Subject: |
[RFC] Various pages: Use consistent style for lists (.IP) |
|
Date: |
Tue, 25 Oct 2022 00:57:43 +0200 |
Reported-by: Mike Frysinger <vapier@gentoo.org>
Cc: <groff@gnu.org>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
---
Hi Mike,
I started doing this change to have a consistent style for lists.
I used a few commands to find issues, and to check that the fixes are
correct (i.e., I don't introduce typos):
$ grep -r '^.IP ' man* \
| sort \
| grep -v -e '^man[78]' -e '^man5/[r-t]' \
| tee >(wc -l) \
| uniq \
| tee >(wc -l) \
| tail -n20;
man5/proc.5:.IP D
man5/proc.5:.IP I
man5/proc.5:.IP K
man5/proc.5:.IP P
man5/proc.5:.IP R 3
man5/proc.5:.IP S
man5/proc.5:.IP SEMMNI 8
man5/proc.5:.IP SEMMNS 8
man5/proc.5:.IP SEMMSL 8
man5/proc.5:.IP SEMOPM 8
man5/proc.5:.IP T
man5/proc.5:.IP W
man5/proc.5:.IP X
man5/proc.5:.IP Z
man5/proc.5:.IP \(bu
man5/proc.5:.IP \(bu 3
man5/proc.5:.IP t
man5/proc.5:.IP x
1074
501
$ git diff \
| grep '^+[^+]' \
| sort \
| tee >(wc -l) \
| uniq
+(1) the signal handler calls only async-signal-safe functions,
+(1.2) make a process a member of
+(2) the signal handler itself is reentrant
+.B If using an event cache...
+.B Starvation (edge-triggered)
+.IP
+.IP (1) 5
+.IP (1.1) 7
+.IP (1.2)
+.IP (1.3)
+.IP (1.4)
+.IP (2)
+.IP (3)
+.IP (4)
+.IP (5)
+.IP (a) 5
+.IP (b)
+.IP (c)
+.IP \(bu
+.IP \(bu 3
+.RS
+.in
+.in +4n
+Before Linux 4.9, bugs similar to points (a) and (c) could also occur
+Multiple processes could pass point (1) simultaneously,
+and then allocate pipe buffers that were accounted for only in step (3),
+we (1.1) enable one or more threaded controllers and
632
I'll finish in a few days, I guess. Then we can document that in
man-pages(7).
Cheers,
Alex
man2/mount.2 | 2 +-
man2/request_key.2 | 2 +-
man2/timerfd_create.2 | 2 +-
man5/proc.5 | 16 +--
man5/slabinfo.5 | 6 +-
man5/tmpfs.5 | 6 +-
man7/boot.7 | 10 +-
man7/capabilities.7 | 270 ++++++++++++++++++-------------------
man7/cgroup_namespaces.7 | 10 +-
man7/cgroups.7 | 116 ++++++++--------
man7/cpuset.7 | 44 +++---
man7/credentials.7 | 18 +--
man7/environ.7 | 20 +--
man7/epoll.7 | 54 ++++----
man7/fanotify.7 | 6 +-
man7/feature_test_macros.7 | 12 +-
man7/inotify.7 | 14 +-
man7/ip.7 | 10 +-
man7/ipc_namespaces.7 | 6 +-
man7/kernel_lockdown.7 | 4 +-
man7/keyrings.7 | 12 +-
man7/locale.7 | 6 +-
man7/man-pages.7 | 56 ++++----
man7/mount_namespaces.7 | 8 +-
man7/mq_overview.7 | 12 +-
man7/namespaces.7 | 36 ++---
man7/nptl.7 | 10 +-
man7/packet.7 | 12 +-
man7/pipe.7 | 19 +--
man7/pthreads.7 | 90 ++++++-------
man7/queue.7 | 44 +++---
man7/random.7 | 4 +-
man7/rtld-audit.7 | 6 +-
man7/sched.7 | 40 +++---
man7/signal-safety.7 | 20 +--
man7/signal.7 | 100 +++++++-------
man7/symlink.7 | 26 ++--
man7/time_namespaces.7 | 4 +-
man7/unicode.7 | 12 +-
man7/unix.7 | 12 +-
man7/uri.7 | 4 +-
man7/user_namespaces.7 | 76 +++++------
man8/ld.so.8 | 26 ++--
43 files changed, 632 insertions(+), 631 deletions(-)
diff --git a/man2/mount.2 b/man2/mount.2
index 60622dfe8..2f01be1e4 100644
--- a/man2/mount.2
+++ b/man2/mount.2
@@ -134,7 +134,7 @@ .SS Additional mount flags
by maintaining these changes only in memory.
The on-disk timestamps are updated only when:
.RS
-.IP (a) 4
+.IP (a) 5
the inode needs to be updated for some change unrelated to file timestamps;
.IP (b)
the application employs
diff --git a/man2/request_key.2 b/man2/request_key.2
index dec25f089..2903febb5 100644
--- a/man2/request_key.2
+++ b/man2/request_key.2
@@ -217,7 +217,7 @@ .SS Requesting user-space instantiation of a key
.BR request_key ()
is:
.RS
-.IP (1) 4
+.IP (1) 5
the context in which the key U should be instantiated and secured, and
.IP (2)
the context from which associated key requests may be satisfied.
diff --git a/man2/timerfd_create.2 b/man2/timerfd_create.2
index c89065f5b..405629636 100644
--- a/man2/timerfd_create.2
+++ b/man2/timerfd_create.2
@@ -480,7 +480,7 @@ .SH NOTES
.B CLOCK_REALTIME_ALARM
timer that was created with
.BR timerfd_create ():
-.IP (a) 4
+.IP (a) 5
The timer has been started
.RB ( timerfd_settime ())
with the
diff --git a/man5/proc.5 b/man5/proc.5
index c35f890f3..5c7ba7de5 100644
--- a/man5/proc.5
+++ b/man5/proc.5
@@ -244,12 +244,12 @@ .SS Files and directories
.IP
The process's "dumpable" attribute may change for the following reasons:
.RS
-.IP * 3
+.IP \(bu 3
The attribute was explicitly set via the
.BR prctl (2)
.B PR_SET_DUMPABLE
operation.
-.IP *
+.IP \(bu
The attribute was reset to the value in the file
.I /proc/sys/fs/suid_dumpable
(described below), for the reasons described in
@@ -1638,7 +1638,7 @@ .SS Files and directories
.\" See mm/oom_kill.c::oom_badness() after 2.6.36
.\" commit a63d83f427fbce97a6cea0db2e64b0eb8435cd10
.RS
-.IP * 2
+.IP \(bu 3
whether the process is privileged (\-).
.\" More precisely, if it has CAP_SYS_ADMIN or (pre 2.6.36) CAP_SYS_RESOURCE
.RE
@@ -1646,16 +1646,16 @@ .SS Files and directories
Before kernel 2.6.36
the following factors were also used in the calculation of oom_score:
.RS
-.IP * 2
+.IP \(bu 3
whether the process creates a lot of children using
.BR fork (2)
(+);
-.IP *
+.IP \(bu
whether the process has been running a long time,
or has used a lot of CPU time (\-);
-.IP *
+.IP \(bu
whether the process has a low nice value (i.e., > 0) (+); and
-.IP *
+.IP \(bu
whether the process is making direct hardware access (\-).
.\" More precisely, if it has CAP_SYS_RAWIO
.RE
@@ -3431,7 +3431,7 @@ .SS Files and directories
.IP
The fields shown in each line are as follows:
.RS
-.IP (1) 4
+.IP (1) 5
The ordinal position of the lock in the list.
.IP (2)
The lock type.
diff --git a/man5/slabinfo.5 b/man5/slabinfo.5
index 1a7a3b51a..e8cfac73a 100644
--- a/man5/slabinfo.5
+++ b/man5/slabinfo.5
@@ -39,11 +39,11 @@ .SH DESCRIPTION
Each of the remaining lines displays information about a specified cache.
Following the cache name,
the output shown in each line shows three components for each cache:
-.IP * 3
+.IP \(bu 3
statistics
-.IP *
+.IP \(bu
tunables
-.IP *
+.IP \(bu
slabdata
.PP
The statistics are as follows:
diff --git a/man5/tmpfs.5 b/man5/tmpfs.5
index 45ba9bd59..f914a1912 100644
--- a/man5/tmpfs.5
+++ b/man5/tmpfs.5
@@ -27,13 +27,13 @@ .SH DESCRIPTION
A
.B tmpfs
filesystem has the following properties:
-.IP * 3
+.IP \(bu 3
The filesystem can employ swap space when physical memory pressure
demands it.
-.IP *
+.IP \(bu
The filesystem consumes only as much physical memory and swap space
as is required to store the current contents of the filesystem.
-.IP *
+.IP \(bu
During a remount operation
.RI ( "mount\ \-o\ remount" ),
the filesystem size can be changed
diff --git a/man7/boot.7 b/man7/boot.7
index 9b4e0171a..b9a25cb53 100644
--- a/man7/boot.7
+++ b/man7/boot.7
@@ -17,15 +17,15 @@ .SH DESCRIPTION
The \fBbootup process\fR (or "\fBboot sequence\fR") varies in details
among systems, but can be roughly divided into phases controlled by
the following components:
-.IP 1. 4
+.IP (1) 5
hardware
-.IP 2. 4
+.IP (2)
operating system (OS) loader
-.IP 3. 4
+.IP (3)
kernel
-.IP 4. 4
+.IP (4)
root user-space process (\fIinit\fR and \fIinittab\fR)
-.IP 5. 4
+.IP (5)
boot scripts
.PP
Each of these is described below in more detail.
diff --git a/man7/capabilities.7 b/man7/capabilities.7
index 921ff5ebe..d85c62f46 100644
--- a/man7/capabilities.7
+++ b/man7/capabilities.7
@@ -85,12 +85,12 @@ .SS Capabilities list
.\" commit 124ea650d3072b005457faed69909221c2905a1f
.PD 0
.RS
-.IP * 2
+.IP \(bu 3
Update
.I /proc/sys/kernel/ns_last_pid
(see
.BR pid_namespaces (7));
-.IP *
+.IP \(bu
employ the
.I set_tid
feature of
@@ -98,7 +98,7 @@ .SS Capabilities list
.\" FIXME There is also some use case relating to
.\" prctl_set_mm_exe_file(); in the 5.9 sources, see
.\" prctl_set_mm_map().
-.IP *
+.IP \(bu
read the contents of the symbolic links in
.IR /proc/ pid /map_files
for other processes.
@@ -121,13 +121,13 @@ .SS Capabilities list
.B CAP_DAC_READ_SEARCH
.PD 0
.RS
-.IP * 2
+.IP \(bu 3
Bypass file read permission checks and
directory read and execute permission checks;
-.IP *
+.IP \(bu
invoke
.BR open_by_handle_at (2);
-.IP *
+.IP \(bu
use the
.BR linkat (2)
.B AT_EMPTY_PATH
@@ -138,7 +138,7 @@ .SS Capabilities list
.B CAP_FOWNER
.PD 0
.RS
-.IP * 2
+.IP \(bu 3
Bypass permission checks on operations that normally
require the filesystem UID of the process to match the UID of
the file (e.g.,
@@ -148,19 +148,19 @@ .SS Capabilities list
.B CAP_DAC_OVERRIDE
and
.BR CAP_DAC_READ_SEARCH ;
-.IP *
+.IP \(bu
set inode flags (see
.BR ioctl_iflags (2))
on arbitrary files;
-.IP *
+.IP \(bu
set Access Control Lists (ACLs) on arbitrary files;
-.IP *
+.IP \(bu
ignore directory sticky bit on file deletion;
-.IP *
+.IP \(bu
modify
.I user
extended attributes on sticky directory owned by any user;
-.IP *
+.IP \(bu
specify
.B O_NOATIME
for arbitrary files in
@@ -173,10 +173,10 @@ .SS Capabilities list
.B CAP_FSETID
.PD 0
.RS
-.IP * 2
+.IP \(bu 3
Don't clear set-user-ID and set-group-ID mode
bits when a file is modified;
-.IP *
+.IP \(bu
set the set-group-ID bit for a file whose GID does not match
the filesystem or any of the supplementary GIDs of the calling process.
.RE
@@ -187,13 +187,13 @@ .SS Capabilities list
.\" in other places; they probably should be replaced with something else.
.PD 0
.RS
-.IP * 2
+.IP \(bu 3
Lock memory
.RB ( mlock (2),
.BR mlockall (2),
.BR mmap (2),
.BR shmctl (2));
-.IP *
+.IP \(bu
Allocate memory using huge pages
.RB ( memfd_create (2),
.BR mmap (2),
@@ -245,23 +245,23 @@ .SS Capabilities list
Perform various network-related operations:
.PD 0
.RS
-.IP * 2
+.IP \(bu 3
interface configuration;
-.IP *
+.IP \(bu
administration of IP firewall, masquerading, and accounting;
-.IP *
+.IP \(bu
modify routing tables;
-.IP *
+.IP \(bu
bind to any address for transparent proxying;
-.IP *
+.IP \(bu
set type-of-service (TOS);
-.IP *
+.IP \(bu
clear driver statistics;
-.IP *
+.IP \(bu
set promiscuous mode;
-.IP *
+.IP \(bu
enabling multicasting;
-.IP *
+.IP \(bu
use
.BR setsockopt (2)
to set the following socket options:
@@ -287,9 +287,9 @@ .SS Capabilities list
.B CAP_NET_RAW
.PD 0
.RS
-.IP * 2
+.IP \(bu 3
Use RAW and PACKET sockets;
-.IP *
+.IP \(bu
bind to any address for transparent proxying.
.RE
.PD
@@ -298,11 +298,11 @@ .SS Capabilities list
.BR CAP_PERFMON " (since Linux 5.8)"
Employ various performance-monitoring mechanisms, including:
.RS
-.IP * 2
+.IP \(bu 3
.PD 0
call
.BR perf_event_open (2);
-.IP *
+.IP \(bu
employ various BPF operations that have performance implications.
.RE
.PD
@@ -317,11 +317,11 @@ .SS Capabilities list
.B CAP_SETGID
.RS
.PD 0
-.IP * 2
+.IP \(bu 3
Make arbitrary manipulations of process GIDs and supplementary GID list;
-.IP *
+.IP \(bu
forge GID when passing socket credentials via UNIX domain sockets;
-.IP *
+.IP \(bu
write a group ID mapping in a user namespace (see
.BR user_namespaces (7)).
.PD
@@ -360,15 +360,15 @@ .SS Capabilities list
.B CAP_SETUID
.RS
.PD 0
-.IP * 2
+.IP \(bu 3
Make arbitrary manipulations of process UIDs
.RB ( setuid (2),
.BR setreuid (2),
.BR setresuid (2),
.BR setfsuid (2));
-.IP *
+.IP \(bu
forge UID when passing socket credentials via UNIX domain sockets;
-.IP *
+.IP \(bu
write a user ID mapping in a user namespace (see
.BR user_namespaces (7)).
.PD
@@ -383,7 +383,7 @@ .SS Capabilities list
.IP
.PD 0
.RS
-.IP * 2
+.IP \(bu 3
Perform a range of system administration operations including:
.BR quotactl (2),
.BR mount (2),
@@ -394,53 +394,53 @@ .SS Capabilities list
.BR sethostname (2),
and
.BR setdomainname (2);
-.IP *
+.IP \(bu
perform privileged
.BR syslog (2)
operations (since Linux 2.6.37,
.B CAP_SYSLOG
should be used to permit such operations);
-.IP *
+.IP \(bu
perform
.B VM86_REQUEST_IRQ
.BR vm86 (2)
command;
-.IP *
+.IP \(bu
access the same checkpoint/restore functionality that is governed by
.B CAP_CHECKPOINT_RESTORE
(but the latter, weaker capability is preferred for accessing
that functionality).
-.IP *
+.IP \(bu
perform the same BPF operations as are governed by
.B CAP_BPF
(but the latter, weaker capability is preferred for accessing
that functionality).
-.IP *
+.IP \(bu
employ the same performance monitoring mechanisms as are governed by
.B CAP_PERFMON
(but the latter, weaker capability is preferred for accessing
that functionality).
-.IP *
+.IP \(bu
perform
.B IPC_SET
and
.B IPC_RMID
operations on arbitrary System V IPC objects;
-.IP *
+.IP \(bu
override
.B RLIMIT_NPROC
resource limit;
-.IP *
+.IP \(bu
perform operations on
.I trusted
and
.I security
extended attributes (see
.BR xattr (7));
-.IP *
+.IP \(bu
use
.BR lookup_dcookie (2);
-.IP *
+.IP \(bu
use
.BR ioprio_set (2)
to assign
@@ -448,9 +448,9 @@ .SS Capabilities list
and (before Linux 2.6.25)
.B IOPRIO_CLASS_IDLE
I/O scheduling classes;
-.IP *
+.IP \(bu
forge PID when passing socket credentials via UNIX domain sockets;
-.IP *
+.IP \(bu
exceed
.IR /proc/sys/fs/file\-max ,
the system-wide limit on the number of open files,
@@ -459,7 +459,7 @@ .SS Capabilities list
.BR execve (2),
.BR open (2),
.BR pipe (2));
-.IP *
+.IP \(bu
employ
.B CLONE_*
flags that create new namespaces with
@@ -468,11 +468,11 @@ .SS Capabilities list
.BR unshare (2)
(but, since Linux 3.8,
creating user namespaces does not require any capability);
-.IP *
+.IP \(bu
access privileged
.I perf
event information;
-.IP *
+.IP \(bu
call
.BR setns (2)
(requires
@@ -480,73 +480,73 @@ .SS Capabilities list
in the
.I target
namespace);
-.IP *
+.IP \(bu
call
.BR fanotify_init (2);
-.IP *
+.IP \(bu
perform privileged
.B KEYCTL_CHOWN
and
.B KEYCTL_SETPERM
.BR keyctl (2)
operations;
-.IP *
+.IP \(bu
perform
.BR madvise (2)
.B MADV_HWPOISON
operation;
-.IP *
+.IP \(bu
employ the
.B TIOCSTI
.BR ioctl (2)
to insert characters into the input queue of a terminal other than
the caller's controlling terminal;
-.IP *
+.IP \(bu
employ the obsolete
.BR nfsservctl (2)
system call;
-.IP *
+.IP \(bu
employ the obsolete
.BR bdflush (2)
system call;
-.IP *
+.IP \(bu
perform various privileged block-device
.BR ioctl (2)
operations;
-.IP *
+.IP \(bu
perform various privileged filesystem
.BR ioctl (2)
operations;
-.IP *
+.IP \(bu
perform privileged
.BR ioctl (2)
operations on the
.I /dev/random
device (see
.BR random (4));
-.IP *
+.IP \(bu
install a
.BR seccomp (2)
filter without first having to set the
.I no_new_privs
thread attribute;
-.IP *
+.IP \(bu
modify allow/deny rules for device control groups;
-.IP *
+.IP \(bu
employ the
.BR ptrace (2)
.B PTRACE_SECCOMP_GET_FILTER
operation to dump tracee's seccomp filters;
-.IP *
+.IP \(bu
employ the
.BR ptrace (2)
.B PTRACE_SETOPTIONS
operation to suspend the tracee's seccomp protections (i.e., the
.B PTRACE_O_SUSPEND_SECCOMP
flag);
-.IP *
+.IP \(bu
perform administrative operations on many device drivers;
-.IP *
+.IP \(bu
modify autogroup nice values by writing to
.IR /proc/ pid /autogroup
(see
@@ -563,10 +563,10 @@ .SS Capabilities list
.B CAP_SYS_CHROOT
.RS
.PD 0
-.IP * 2
+.IP \(bu 3
Use
.BR chroot (2);
-.IP *
+.IP \(bu
change mount namespaces using
.BR setns (2).
.PD
@@ -575,13 +575,13 @@ .SS Capabilities list
.B CAP_SYS_MODULE
.RS
.PD 0
-.IP * 2
+.IP \(bu 3
Load and unload kernel modules
(see
.BR init_module (2)
and
.BR delete_module (2));
-.IP *
+.IP \(bu
in kernels before 2.6.25:
drop capabilities from the system-wide capability bounding set.
.PD
@@ -590,24 +590,24 @@ .SS Capabilities list
.B CAP_SYS_NICE
.PD 0
.RS
-.IP * 2
+.IP \(bu 3
Lower the process nice value
.RB ( nice (2),
.BR setpriority (2))
and change the nice value for arbitrary processes;
-.IP *
+.IP \(bu
set real-time scheduling policies for calling process,
and set scheduling policies and priorities for arbitrary processes
.RB ( sched_setscheduler (2),
.BR sched_setparam (2),
.BR sched_setattr (2));
-.IP *
+.IP \(bu
set CPU affinity for arbitrary processes
.RB ( sched_setaffinity (2));
-.IP *
+.IP \(bu
set I/O scheduling class and priority for arbitrary processes
.RB ( ioprio_set (2));
-.IP *
+.IP \(bu
apply
.BR migrate_pages (2)
to arbitrary processes and allow processes
@@ -618,11 +618,11 @@ .SS Capabilities list
.\" capable(CAP_SYS_NICE) ? MPOL_MF_MOVE_ALL : MPOL_MF_MOVE);
.\"
.\" Document this.
-.IP *
+.IP \(bu
apply
.BR move_pages (2)
to arbitrary processes;
-.IP *
+.IP \(bu
use the
.B MPOL_MF_MOVE_ALL
flag with
@@ -639,19 +639,19 @@ .SS Capabilities list
.B CAP_SYS_PTRACE
.PD 0
.RS
-.IP * 2
+.IP \(bu 3
Trace arbitrary processes using
.BR ptrace (2);
-.IP *
+.IP \(bu
apply
.BR get_robust_list (2)
to arbitrary processes;
-.IP *
+.IP \(bu
transfer data to or from the memory of arbitrary processes using
.BR process_vm_readv (2)
and
.BR process_vm_writev (2);
-.IP *
+.IP \(bu
inspect processes using
.BR kcmp (2).
.RE
@@ -660,45 +660,45 @@ .SS Capabilities list
.B CAP_SYS_RAWIO
.PD 0
.RS
-.IP * 2
+.IP \(bu 3
Perform I/O port operations
.RB ( iopl (2)
and
.BR ioperm (2));
-.IP *
+.IP \(bu
access
.IR /proc/kcore ;
-.IP *
+.IP \(bu
employ the
.B FIBMAP
.BR ioctl (2)
operation;
-.IP *
+.IP \(bu
open devices for accessing x86 model-specific registers (MSRs, see
.BR msr (4));
-.IP *
+.IP \(bu
update
.IR /proc/sys/vm/mmap_min_addr ;
-.IP *
+.IP \(bu
create memory mappings at addresses below the value specified by
.IR /proc/sys/vm/mmap_min_addr ;
-.IP *
+.IP \(bu
map files in
.IR /proc/bus/pci ;
-.IP *
+.IP \(bu
open
.I /dev/mem
and
.IR /dev/kmem ;
-.IP *
+.IP \(bu
perform various SCSI device commands;
-.IP *
+.IP \(bu
perform certain operations on
.BR hpsa (4)
and
.BR cciss (4)
devices;
-.IP *
+.IP \(bu
perform a range of device-specific operations on other devices.
.RE
.PD
@@ -706,28 +706,28 @@ .SS Capabilities list
.B CAP_SYS_RESOURCE
.PD 0
.RS
-.IP * 2
+.IP \(bu 3
Use reserved space on ext2 filesystems;
-.IP *
+.IP \(bu
make
.BR ioctl (2)
calls controlling ext3 journaling;
-.IP *
+.IP \(bu
override disk quota limits;
-.IP *
+.IP \(bu
increase resource limits (see
.BR setrlimit (2));
-.IP *
+.IP \(bu
override
.B RLIMIT_NPROC
resource limit;
-.IP *
+.IP \(bu
override maximum number of consoles on console allocation;
-.IP *
+.IP \(bu
override maximum number of keymaps;
-.IP *
+.IP \(bu
allow more than 64hz interrupts from the real-time clock;
-.IP *
+.IP \(bu
raise
.I msg_qbytes
limit for a System V message queue above the limit in
@@ -736,26 +736,26 @@ .SS Capabilities list
.BR msgop (2)
and
.BR msgctl (2));
-.IP *
+.IP \(bu
allow the
.B RLIMIT_NOFILE
resource limit on the number of "in-flight" file descriptors
to be bypassed when passing file descriptors to another process
via a UNIX domain socket (see
.BR unix (7));
-.IP *
+.IP \(bu
override the
.I /proc/sys/fs/pipe\-size\-max
limit when setting the capacity of a pipe using the
.B F_SETPIPE_SZ
.BR fcntl (2)
command;
-.IP *
+.IP \(bu
use
.B F_SETPIPE_SZ
to increase the capacity of a pipe above the limit specified by
.IR /proc/sys/fs/pipe\-max\-size ;
-.IP *
+.IP \(bu
override
.IR /proc/sys/fs/mqueue/queues_max ,
.IR /proc/sys/fs/mqueue/msg_max ,
@@ -763,12 +763,12 @@ .SS Capabilities list
.I /proc/sys/fs/mqueue/msgsize_max
limits when creating POSIX message queues (see
.BR mq_overview (7));
-.IP *
+.IP \(bu
employ the
.BR prctl (2)
.B PR_SET_MM
operation;
-.IP *
+.IP \(bu
set
.IR /proc/ pid /oom_score_adj
to a value lower than the value last set by a process with
@@ -793,14 +793,14 @@ .SS Capabilities list
.BR CAP_SYSLOG " (since Linux 2.6.37)"
.RS
.PD 0
-.IP * 2
+.IP \(bu 3
Perform privileged
.BR syslog (2)
operations.
See
.BR syslog (2)
for information on which operations require privilege.
-.IP *
+.IP \(bu
View kernel addresses exposed via
.I /proc
and other interfaces when
@@ -822,14 +822,14 @@ .SS Capabilities list
.\"
.SS Past and current implementation
A full implementation of capabilities requires that:
-.IP 1. 3
+.IP \(bu 3
For all privileged operations,
the kernel must check whether the thread has the required
capability in its effective set.
-.IP 2.
+.IP \(bu
The kernel must provide system calls allowing a thread's capability sets to
be changed and retrieved.
-.IP 3.
+.IP \(bu
The filesystem must support attaching capabilities to an executable file,
so that a process gains those capabilities when the file is executed.
.PP
@@ -839,12 +839,12 @@ .SS Past and current implementation
.SS Notes to kernel developers
When adding a new kernel feature that should be governed by a capability,
consider the following points.
-.IP * 3
+.IP \(bu 3
The goal of capabilities is divide the power of superuser into pieces,
such that if a program that has one or more capabilities is compromised,
its power to do damage to the system would be less than the same program
running with root privilege.
-.IP *
+.IP \(bu
You have the choice of either creating a new capability for your new feature,
or associating the feature with one of the existing capabilities.
In order to keep the set of capabilities to a manageable size,
@@ -852,7 +852,7 @@ .SS Notes to kernel developers
unless there are compelling reasons to take the former option.
(There is also a technical limit:
the size of capability sets is currently limited to 64 bits.)
-.IP *
+.IP \(bu
To determine which existing capability might best be associated
with your new feature, review the list of capabilities above in order
to find a "silo" into which your new feature best fits.
@@ -860,7 +860,7 @@ .SS Notes to kernel developers
requiring capabilities that will always be used along with the new feature.
If the new feature is useless without these other features,
you should use the same capability as the other features.
-.IP *
+.IP \(bu
.I Don't
choose
.B CAP_SYS_ADMIN
@@ -878,7 +878,7 @@ .SS Notes to kernel developers
are ones that
.I closely
match existing uses in that silo.
-.IP *
+.IP \(bu
If you have determined that it really is necessary to create
a new capability for your feature,
don't make or name it as a "single-use" capability.
@@ -1102,11 +1102,11 @@ .SS File capability extended attribute versioning
a version 3
.RB ( VFS_CAP_REVISION_3 )
attribute if both of the following are true:
-.IP (1) 4
+.IP \(bu 3
The thread writing the attribute resides in a noninitial user namespace.
(More precisely: the thread resides in a user namespace other
than the one from which the underlying filesystem was mounted.)
-.IP (2)
+.IP \(bu
The thread has the
.B CAP_SETFCAP
capability over the file inode,
@@ -1209,13 +1209,13 @@ .SS Transformation of capabilities during execve()
.PP
Note the following details relating to the above capability
transformation rules:
-.IP * 3
+.IP \(bu 3
The ambient capability set is present only since Linux 4.3.
When determining the transformation of the ambient set during
.BR execve (2),
a privileged file is one that has capabilities or
has the set-user-ID or set-group-ID bit set.
-.IP *
+.IP \(bu
Prior to Linux 2.6.25,
the bounding set was a system-wide attribute shared by all threads.
That system-wide value was employed to calculate the new permitted set during
@@ -1294,7 +1294,7 @@ .SS Capabilities and execution of programs by root
switching the effective user ID to 0 (root) because
a set-user-ID-root program was executed\(emthe
kernel calculates the file capability sets as follows:
-.IP 1. 3
+.IP (1) 5
If the real or effective user ID of the process is 0 (root),
then the file inheritable and permitted sets are ignored;
instead they are notionally considered to be all ones
@@ -1302,7 +1302,7 @@ .SS Capabilities and execution of programs by root
(There is one exception to this behavior, described in
.I Set-user-ID-root programs that have file capabilities
below.)
-.IP 2.
+.IP (2)
If the effective user ID of the process is 0 (root) or
the file effective bit is in fact enabled,
then the file effective bit is notionally defined to be one (enabled).
@@ -1370,7 +1370,7 @@ .SS Capability bounding set
to limit the capabilities that can be gained during an
.BR execve (2).
The bounding set is used in the following ways:
-.IP * 2
+.IP \(bu 3
During an
.BR execve (2),
the capability bounding set is ANDed with the file permitted
@@ -1378,7 +1378,7 @@ .SS Capability bounding set
thread's permitted capability set.
The capability bounding set thus places a limit on the permitted
capabilities that may be granted by an executable file.
-.IP *
+.IP \(bu
(Since Linux 2.6.25)
The capability bounding set acts as a limiting superset for
the capabilities that a thread can add to its inheritable set using
@@ -1491,19 +1491,19 @@ .SS Effect of user ID changes on capabilities
.BR setuid (2),
.BR setresuid (2),
or similar):
-.IP 1. 3
+.IP \(bu 3
If one or more of the real, effective, or saved set user IDs
was previously 0, and as a result of the UID changes all of these IDs
have a nonzero value,
then all capabilities are cleared from the permitted, effective, and ambient
capability sets.
-.IP 2.
+.IP \(bu
If the effective user ID is changed from 0 to nonzero,
then all capabilities are cleared from the effective set.
-.IP 3.
+.IP \(bu
If the effective user ID is changed from nonzero to 0,
then the permitted set is copied to the effective set.
-.IP 4.
+.IP \(bu
If the filesystem user ID is changed from 0 to nonzero (see
.BR setfsuid (2)),
then the following capabilities are cleared from the effective set:
@@ -1544,21 +1544,21 @@ .SS Programmatically adjusting capability sets
package,
is preferred for this purpose.
The following rules govern changes to the thread capability sets:
-.IP 1. 3
+.IP \(bu 3
If the caller does not have the
.B CAP_SETPCAP
capability,
the new inheritable set must be a subset of the combination
of the existing inheritable and permitted sets.
-.IP 2.
+.IP \(bu
(Since Linux 2.6.25)
The new inheritable set must be a subset of the combination of the
existing inheritable set and the capability bounding set.
-.IP 3.
+.IP \(bu
The new permitted set must be a subset of the existing permitted set
(i.e., it is not possible to acquire permitted capabilities
that the thread does not currently have).
-.IP 4.
+.IP \(bu
The new effective set must be a subset of the new permitted set.
.SS The securebits flags: establishing a capabilities-only environment
.\" For some background:
@@ -1824,14 +1824,14 @@ .SH NOTES
since no thread ever has
.B CAP_SETPCAP
in either of these cases:
-.IP * 2
+.IP \(bu 3
In the pre-2.6.25 implementation the system-wide capability bounding set,
.IR /proc/sys/kernel/cap\-bound ,
always masks out the
.B CAP_SETPCAP
capability, and this can not be changed
without modifying the kernel source and rebuilding the kernel.
-.IP *
+.IP \(bu
If file capabilities are disabled (i.e., the kernel
.B CONFIG_SECURITY_FILE_CAPABILITIES
option is disabled), then
diff --git a/man7/cgroup_namespaces.7 b/man7/cgroup_namespaces.7
index 134c2e6e0..96960f53b 100644
--- a/man7/cgroup_namespaces.7
+++ b/man7/cgroup_namespaces.7
@@ -168,13 +168,13 @@ .SH NOTES
option.
.PP
The virtualization provided by cgroup namespaces serves a number of purposes:
-.IP * 2
+.IP \(bu 3
It prevents information leaks whereby cgroup directory paths outside of
a container would otherwise be visible to processes in the container.
Such leakages could, for example,
reveal information about the container framework
to containerized applications.
-.IP *
+.IP \(bu
It eases tasks such as container migration.
The virtualization provided by cgroup namespaces
allows containers to be isolated from knowledge of
@@ -184,13 +184,13 @@ .SH NOTES
would need to be replicated on the target system when migrating a container;
those pathnames would also need to be unique,
so that they don't conflict with other pathnames on the target system.
-.IP *
+.IP \(bu
It allows better confinement of containerized processes,
because it is possible to mount the container's cgroup filesystems such that
the container processes can't gain access to ancestor cgroup directories.
Consider, for example, the following scenario:
-.RS 4
-.IP \(bu 2
+.RS
+.IP \(bu 3
We have a cgroup directory,
.IR /cg/1 ,
that is owned by user ID 9000.
diff --git a/man7/cgroups.7 b/man7/cgroups.7
index 6f6ac289c..94f89cab9 100644
--- a/man7/cgroups.7
+++ b/man7/cgroups.7
@@ -559,20 +559,20 @@ .SH CGROUPS VERSION 2
.PP
The new behaviors in cgroups v2 are summarized here,
and in some cases elaborated in the following subsections.
-.IP 1. 3
+.IP \(bu 3
Cgroups v2 provides a unified hierarchy against
which all controllers are mounted.
-.IP 2.
+.IP \(bu
"Internal" processes are not permitted.
With the exception of the root cgroup, processes may reside
only in leaf nodes (cgroups that do not themselves contain child cgroups).
The details are somewhat more subtle than this, and are described below.
-.IP 3.
+.IP \(bu
Active cgroups must be specified via the files
.I cgroup.controllers
and
.IR cgroup.subtree_control .
-.IP 4.
+.IP \(bu
The
.I tasks
file has been removed.
@@ -581,7 +581,7 @@ .SH CGROUPS VERSION 2
file that is employed by the
.I cpuset
controller has been removed.
-.IP 5.
+.IP \(bu
An improved mechanism for notification of empty cgroups is provided by the
.I cgroup.events
file.
@@ -920,14 +920,14 @@ .SS Cgroup v2 release notification
offers the following advantages over the cgroups v1
.I release_agent
mechanism:
-.IP * 3
+.IP \(bu 3
It allows for cheaper notification,
since a single process can monitor multiple
.I cgroup.events
files (using the techniques described earlier).
By contrast, the cgroups v1 mechanism requires the expense of creating
a process for each notification.
-.IP *
+.IP \(bu
Notification for different cgroup subhierarchies can be delegated
to different processes.
By contrast, the cgroups v1 mechanism allows only one release agent
@@ -1114,7 +1114,7 @@ .SS Cgroups v2 delegation: nsdelegate and cgroup
namespaces
to automatically become delegation boundaries.
More specifically,
the following restrictions apply for processes inside the cgroup namespace:
-.IP * 3
+.IP \(bu 3
Writes to controller interface files in the root directory of the namespace
will fail with the error
.BR EPERM .
@@ -1124,7 +1124,7 @@ .SS Cgroups v2 delegation: nsdelegate and cgroup
namespaces
and
.IR cgroup.subtree_control ,
and can create subhierarchy underneath the root directory.
-.IP *
+.IP \(bu
Attempts to migrate processes across the namespace boundary are denied
(with the error
.BR ENOENT ).
@@ -1151,7 +1151,7 @@ .SS Cgroups v2 delegation: nsdelegate and cgroup
namespaces
because both hierarchies are owned by the unprivileged user
.IR cecilia ,
the following illegitimate actions could be performed:
-.IP * 3
+.IP \(bu 3
A process in the inferior hierarchy could change the
resource controller settings in the root directory of that hierarchy.
(These resource controller settings are intended to allow control to
@@ -1159,7 +1159,7 @@ .SS Cgroups v2 delegation: nsdelegate and cgroup
namespaces
.I parent
cgroup;
a process inside the child cgroup should not be allowed to modify them.)
-.IP *
+.IP \(bu
A process inside the inferior hierarchy could move processes
into and out of the inferior hierarchy if the cgroups in the
superior hierarchy were somehow visible.
@@ -1208,11 +1208,11 @@ .SS Cgroup delegation containment rules
a "target" process into a
.I cgroup.procs
file only if all of the following are true:
-.IP * 3
+.IP \(bu 3
The writer has write permission on the
.I cgroup.procs
file in the destination cgroup.
-.IP *
+.IP \(bu
The writer has write permission on the
.I cgroup.procs
file in the nearest common ancestor of the source and destination cgroups.
@@ -1222,12 +1222,12 @@ .SS Cgroup delegation containment rules
with the consequence that containment in v1 is less strict than in v2.
(For example, in cgroups v1 the user that owns two distinct
delegated subhierarchies can move a process between the hierarchies.)
-.IP *
+.IP \(bu
If the cgroup v2 filesystem was mounted with the
.I nsdelegate
option, the writer must be able to see the source and destination cgroups
from its cgroup namespace.
-.IP *
+.IP \(bu
In cgroups v1:
the effective UID of the writer (i.e., the delegatee) matches the
real user ID or the saved set-user-ID of the target process.
@@ -1248,10 +1248,10 @@ .SS Cgroup delegation containment rules
.SH CGROUPS VERSION 2 THREAD MODE
Among the restrictions imposed by cgroups v2 that were not present
in cgroups v1 are the following:
-.IP * 3
+.IP \(bu 3
.IR "No thread-granularity control" :
all of the threads of a process must be in the same cgroup.
-.IP *
+.IP \(bu
.IR "No internal processes" :
a cgroup can't both have member processes and
exercise controllers on child cgroups.
@@ -1278,17 +1278,17 @@ .SH CGROUPS VERSION 2 THREAD MODE
for cgroups v2.
.PP
Thread mode allows the following:
-.IP * 3
+.IP \(bu 3
The creation of
.I threaded subtrees
in which the threads of a process may
be spread across cgroups inside the tree.
(A threaded subtree may contain multiple multithreaded processes.)
-.IP *
+.IP \(bu
The concept of
.IR "threaded controllers" ,
which can distribute resources across the cgroups in a threaded subtree.
-.IP *
+.IP \(bu
A relaxation of the "no internal processes rule",
so that, within a threaded subtree,
a cgroup can both contain member threads and
@@ -1343,7 +1343,7 @@ .SH CGROUPS VERSION 2 THREAD MODE
.SS Threaded versus domain controllers
With the addition of threads mode,
cgroups v2 now distinguishes two types of resource controllers:
-.IP * 3
+.IP \(bu 3
.I Threaded
.\" In the kernel source, look for ".threaded[ \t]*= true" in
.\" initializations of struct cgroup_subsys
@@ -1356,7 +1356,7 @@ .SS Threaded versus domain controllers
.IR perf_event ,
and
.IR pids .
-.IP *
+.IP \(bu
.I Domain
controllers: these controllers support only process granularity
for resource control.
@@ -1367,7 +1367,7 @@ .SS Threaded versus domain controllers
.SS Creating a threaded subtree
There are two pathways that lead to the creation of a threaded subtree.
The first pathway proceeds as follows:
-.IP 1. 3
+.IP (1) 5
We write the string
.I """threaded"""
to the
@@ -1378,19 +1378,19 @@ .SS Creating a threaded subtree
.IR domain .
This has the following effects:
.RS
-.IP * 3
+.IP \(bu 3
The type of the cgroup
.I y/z
becomes
.IR threaded .
-.IP *
+.IP \(bu
The type of the parent cgroup,
.IR y ,
becomes
.IR "domain threaded" .
The parent cgroup is the root of a threaded subtree
(also known as the "threaded root").
-.IP *
+.IP \(bu
All other cgroups under
.I y
that were not already of type
@@ -1404,7 +1404,7 @@ .SS Creating a threaded subtree
will also have the type
.IR "domain invalid" .
.RE
-.IP 2.
+.IP (2)
We write the string
.I """threaded"""
to each of the
@@ -1423,23 +1423,23 @@ .SS Creating a threaded subtree
but allows for possible future extensions to the thread-mode model.
.PP
The second way of creating a threaded subtree is as follows:
-.IP 1. 3
+.IP (1) 5
In an existing cgroup,
.IR z ,
that currently has the type
.IR domain ,
-we (1) enable one or more threaded controllers and
-(2) make a process a member of
+we (1.1) enable one or more threaded controllers and
+(1.2) make a process a member of
.IR z .
(These two steps can be done in either order.)
This has the following consequences:
.RS
-.IP * 3
+.IP \(bu 3
The type of
.I z
becomes
.IR "domain threaded" .
-.IP *
+.IP \(bu
All of the descendant cgroups of
.I x
that were not already of type
@@ -1447,7 +1447,7 @@ .SS Creating a threaded subtree
are converted to type
.IR "domain invalid" .
.RE
-.IP 2.
+.IP (2)
As before, we make the threaded subtree usable by writing the string
.I """threaded"""
to each of the
@@ -1498,17 +1498,17 @@ .SS Using a threaded subtree
some containment rules apply when writing to the
.I cgroup.threads
file:
-.IP * 3
+.IP \(bu 3
The writer must have write permission on the
cgroup.threads
file in the destination cgroup.
-.IP *
+.IP \(bu
The writer must have write permission on the
.I cgroup.procs
file in the common ancestor of the source and destination cgroups.
(In some cases,
the common ancestor may be the source or destination cgroup itself.)
-.IP *
+.IP \(bu
The source and destination cgroups must be in the same threaded subtree.
(Outside a threaded subtree, an attempt to move a thread by writing
its thread ID to the
@@ -1551,7 +1551,7 @@ .SS Rules for writing to cgroup.type and creating
threaded subtrees
A number of rules apply when writing to the
.I cgroup.type
file:
-.IP * 3
+.IP \(bu 3
Only the string
.I """threaded"""
may be written.
@@ -1559,7 +1559,7 @@ .SS Rules for writing to cgroup.type and creating
threaded subtrees
.I domain
cgroup to type
.IR threaded .
-.IP *
+.IP \(bu
The effect of writing
.I """threaded"""
depends on the current value in
@@ -1582,7 +1582,7 @@ .SS Rules for writing to cgroup.type and creating
threaded subtrees
.IR threaded :
no effect (a "no-op").
.RE
-.IP *
+.IP \(bu
We can't write to a
.I cgroup.type
file if the parent's type is
@@ -1594,13 +1594,13 @@ .SS Rules for writing to cgroup.type and creating
threaded subtrees
There are also some constraints that must be satisfied
in order to create a threaded subtree rooted at the cgroup
.IR x :
-.IP * 3
+.IP \(bu 3
There can be no member processes in the descendant cgroups of
.IR x .
(The cgroup
.I x
can itself have member processes.)
-.IP *
+.IP \(bu
No domain controllers may be enabled in
.IR x 's
.I cgroup.subtree_control
@@ -1618,11 +1618,11 @@ .SS The """domain threaded""" cgroup type
the type of a cgroup can change to
.I domain threaded
in either of the following cases:
-.IP * 3
+.IP \(bu 3
The string
.I """threaded"""
is written to a child cgroup.
-.IP *
+.IP \(bu
A threaded controller is enabled inside the cgroup and
a process is made a member of the cgroup.
.PP
@@ -1647,14 +1647,14 @@ .SS The """domain threaded""" cgroup type
.I x
reverts to the type
.IR domain :
-.IP * 3
+.IP \(bu 3
All
.I domain invalid
descendants of
.I x
that are not in lower-level threaded subtrees revert to the type
.IR domain .
-.IP *
+.IP \(bu
The root cgroups in any lower-level threaded subtrees revert to the type
.IR "domain threaded" .
.\"
@@ -1670,10 +1670,10 @@ .SS Exceptions for the root cgroup
is written to the
.I cgroup.type
file of one of the children of the root cgroup, then
-.IP * 3
+.IP \(bu 3
The type of that cgroup becomes
.IR threaded .
-.IP *
+.IP \(bu
The type of any descendants of that cgroup that
are not part of lower-level threaded subtrees changes to
.IR "domain invalid" .
@@ -1772,24 +1772,24 @@ .SS /proc files
.IP
The fields in this file are, from left to right:
.RS
-.IP 1. 3
+.IP (1) 5
The name of the controller.
-.IP 2.
+.IP (2)
The unique ID of the cgroup hierarchy on which this controller is mounted.
If multiple cgroups v1 controllers are bound to the same hierarchy,
then each will show the same hierarchy ID in this field.
The value in this field will be 0 if:
-.RS 5
-.IP a) 3
+.RS
+.IP (a) 5
the controller is not mounted on a cgroups v1 hierarchy;
-.IP b)
+.IP (b)
the controller is bound to the cgroups v2 single unified hierarchy; or
-.IP c)
+.IP (c)
the controller is disabled (see below).
.RE
-.IP 3.
+.IP (3)
The number of control groups in this hierarchy using this controller.
-.IP 4.
+.IP (4)
This field contains the value 1 if this controller is enabled,
or 0 if it has been disabled (via the
.I cgroup_disable
@@ -1821,18 +1821,18 @@ .SS /proc files
.IP
The colon-separated fields are, from left to right:
.RS
-.IP 1. 3
+.IP (1) 5
For cgroups version 1 hierarchies,
this field contains a unique hierarchy ID number
that can be matched to a hierarchy ID in
.IR /proc/cgroups .
For the cgroups version 2 hierarchy, this field contains the value 0.
-.IP 2.
+.IP (2)
For cgroups version 1 hierarchies,
this field contains a comma-separated list of the controllers
bound to the hierarchy.
For the cgroups version 2 hierarchy, this field is empty.
-.IP 3.
+.IP (3)
This field contains the pathname of the control group in the hierarchy
to which the process belongs.
This pathname is relative to the mount point of the hierarchy.
diff --git a/man7/cpuset.7 b/man7/cpuset.7
index 01abdc05d..aae3ac04c 100644
--- a/man7/cpuset.7
+++ b/man7/cpuset.7
@@ -519,17 +519,17 @@ .SS Memory pressure
See the \fBWARNINGS\fR section, below.
.PP
A per-cpuset, running average is employed for the following reasons:
-.IP * 3
+.IP \(bu 3
Because this meter is per-cpuset rather than per-process or per virtual
memory region, the system load imposed by a batch scheduler monitoring
this metric is sharply reduced on large systems, because a scan of
the tasklist can be avoided on each set of queries.
-.IP *
+.IP \(bu
Because this meter is a running average rather than an accumulating
counter, a batch scheduler can detect memory pressure with a
single read, instead of having to read and accumulate results
for a period of time.
-.IP *
+.IP \(bu
Because this meter is per-cpuset rather than per-process,
the batch scheduler can obtain the key information\(emmemory
pressure in a cpuset\(emwith a single read, rather than having to
@@ -629,11 +629,11 @@ .SS Memory spread
.PP
Cpuset-specified memory spreading can provide substantial performance
improvements for jobs that:
-.IP a) 3
+.IP \(bu 3
need to place thread-local data on
memory nodes close to the CPUs which are running the threads that most
frequently access that data; but also
-.IP b)
+.IP \(bu
need to access large filesystem data sets that must to be spread
across the several nodes in the job's cpuset in order to fit.
.PP
@@ -705,11 +705,11 @@ .SS Scheduler load balancing
.PP
This default load balancing across all CPUs is not well suited to
the following two situations:
-.IP * 3
+.IP \(bu 3
On large systems, load balancing across many CPUs is expensive.
If the system is managed using cpusets to place independent jobs
on separate sets of CPUs, full load balancing is unnecessary.
-.IP *
+.IP \(bu
Systems supporting real-time on some CPUs need to minimize
system overhead on those CPUs, including avoiding process load
balancing if that is not needed.
@@ -911,22 +911,22 @@ .SS List format
.\" ================== RULES ==================
.SH RULES
The following rules apply to each cpuset:
-.IP * 3
+.IP \(bu 3
Its CPUs and memory nodes must be a (possibly equal)
subset of its parent's.
-.IP *
+.IP \(bu
It can be marked
.I cpu_exclusive
only if its parent is.
-.IP *
+.IP \(bu
It can be marked
.I mem_exclusive
only if its parent is.
-.IP *
+.IP \(bu
If it is
.IR cpu_exclusive ,
its CPUs may not overlap any sibling.
-.IP *
+.IP \(bu
If it is
.IR mem_exclusive ,
its memory nodes may not overlap any sibling.
@@ -1357,16 +1357,16 @@ .SS Creating and attaching to a cpuset.
the steps are:
.PP
.PD 0
-.IP 1) 4
+.IP (1) 5
mkdir /dev/cpuset (if not already done)
-.IP 2)
+.IP (2)
mount \-t cpuset none /dev/cpuset (if not already done)
-.IP 3)
+.IP (3)
Create the new cpuset using
.BR mkdir (1).
-.IP 4)
+.IP (4)
Assign CPUs and memory nodes to the new cpuset.
-.IP 5)
+.IP (5)
Attach the shell to the new cpuset.
.PD
.PP
@@ -1397,24 +1397,24 @@ .SS Migrating a job to different memory nodes.
perform the following steps.
.PP
.PD 0
-.IP 1) 4
+.IP (1) 5
Let's say we want to move the job in cpuset
.I alpha
(CPUs 4\(en7 and memory nodes 2\(en3) to a new cpuset
.I beta
(CPUs 16\(en19 and memory nodes 8\(en9).
-.IP 2)
+.IP (2)
First create the new cpuset
.IR beta .
-.IP 3)
+.IP (3)
Then allow CPUs 16\(en19 and memory nodes 8\(en9 in
.IR beta .
-.IP 4)
+.IP (4)
Then enable
.I memory_migration
in
.IR beta .
-.IP 5)
+.IP (5)
Then move each process from
.I alpha
to
diff --git a/man7/credentials.7 b/man7/credentials.7
index 01a531974..60f4aeba4 100644
--- a/man7/credentials.7
+++ b/man7/credentials.7
@@ -154,13 +154,13 @@ .SS User and group identifiers
.IR <sys/types.h> ).
.PP
On Linux, each process has the following user and group identifiers:
-.IP * 3
+.IP \(bu 3
Real user ID and real group ID.
These IDs determine who owns the process.
A process can obtain its real user (group) ID using
.BR getuid (2)
.RB ( getgid (2)).
-.IP *
+.IP \(bu
Effective user ID and effective group ID.
These IDs are used by the kernel to determine the permissions
that the process will have when accessing shared resources such
@@ -172,7 +172,7 @@ .SS User and group identifiers
A process can obtain its effective user (group) ID using
.BR geteuid (2)
.RB ( getegid (2)).
-.IP *
+.IP \(bu
Saved set-user-ID and saved set-group-ID.
These IDs are used in set-user-ID and set-group-ID programs to save
a copy of the corresponding effective IDs that were set when
@@ -194,7 +194,7 @@ .SS User and group identifiers
A process can obtain its saved set-user-ID (set-group-ID) using
.BR getresuid (2)
.RB ( getresgid (2)).
-.IP *
+.IP \(bu
Filesystem user ID and filesystem group ID (Linux-specific).
These IDs, in conjunction with the supplementary group IDs described
below, are used to determine permissions for accessing files; see
@@ -211,7 +211,7 @@ .SS User and group identifiers
.BR setfsuid (2)
and
.BR setfsgid (2).
-.IP *
+.IP \(bu
Supplementary group IDs.
This is a set of additional group IDs that are used for permission
checks when accessing files and other shared resources.
@@ -241,10 +241,10 @@ .SS User and group identifiers
.PP
Aside from the purposes noted above,
a process's user IDs are also employed in a number of other contexts:
-.IP * 3
+.IP \(bu 3
when determining the permissions for sending signals (see
.BR kill (2));
-.IP *
+.IP \(bu
when determining the permissions for setting
process-scheduling parameters (nice value, real time
scheduling policy and priority, CPU affinity, I/O priority) using
@@ -255,10 +255,10 @@ .SS User and group identifiers
.BR sched_setattr (2),
and
.BR ioprio_set (2);
-.IP *
+.IP \(bu
when checking resource limits (see
.BR getrlimit (2));
-.IP *
+.IP \(bu
when checking the limit on the number of inotify instances
that the process may create (see
.BR inotify (7)).
diff --git a/man7/environ.7 b/man7/environ.7
index e62164df1..99b49351d 100644
--- a/man7/environ.7
+++ b/man7/environ.7
@@ -198,7 +198,7 @@ .SH DESCRIPTION
Note that the behavior of many programs and library routines is
influenced by the presence or value of certain environment variables.
Examples include the following:
-.IP * 3
+.IP \(bu 3
The variables
.BR LANG ", " LANGUAGE ", " NLSPATH ", " LOCPATH ,
.BR LC_ALL ", " LC_MESSAGES ,
@@ -207,37 +207,37 @@ .SH DESCRIPTION
.BR gettext (3),
and
.BR locale (7).
-.IP *
+.IP \(bu
.B TMPDIR
influences the path prefix of names created by
.BR tempnam (3)
and other routines, and the temporary directory used by
.BR sort (1)
and other programs.
-.IP *
+.IP \(bu
.BR LD_LIBRARY_PATH ", " LD_PRELOAD ,
and other
.B LD_*
variables influence the behavior of the dynamic loader/linker.
See also
.BR ld.so (8).
-.IP *
+.IP \(bu
.B POSIXLY_CORRECT
makes certain programs and library routines follow
the prescriptions of POSIX.
-.IP *
+.IP \(bu
The behavior of
.BR malloc (3)
is influenced by
.B MALLOC_*
variables.
-.IP *
+.IP \(bu
The variable
.B HOSTALIASES
gives the name of a file containing aliases
to be used with
.BR gethostbyname (3).
-.IP *
+.IP \(bu
.BR TZ " and " TZDIR
give timezone information used by
.BR tzset (3)
@@ -248,14 +248,14 @@ .SH DESCRIPTION
.BR strftime (3).
See also
.BR tzselect (8).
-.IP *
+.IP \(bu
.B TERMCAP
gives information on how to address a given terminal
(or gives the name of a file containing such information).
-.IP *
+.IP \(bu
.BR COLUMNS " and " LINES
tell applications about the window size, possibly overriding the actual size.
-.IP *
+.IP \(bu
.BR PRINTER " or " LPDEST
may specify the desired printer to use.
See
diff --git a/man7/epoll.7 b/man7/epoll.7
index 29ae4c307..146cc815a 100644
--- a/man7/epoll.7
+++ b/man7/epoll.7
@@ -29,7 +29,7 @@ .SH DESCRIPTION
.IR instance ,
an in-kernel data structure which, from a user-space perspective,
can be considered as a container for two lists:
-.IP \(bu 2
+.IP \(bu 3
The
.I interest
list (sometimes also called the
@@ -50,7 +50,7 @@ .SH DESCRIPTION
create and manage an
.B epoll
instance:
-.IP \(bu 2
+.IP \(bu 3
.BR epoll_create (2)
creates a new
.B epoll
@@ -83,24 +83,24 @@ .SS Level-triggered and edge-triggered
can be described as follows.
Suppose that
this scenario happens:
-.IP 1. 3
+.IP (1) 5
The file descriptor that represents the read side of a pipe
.RI ( rfd )
is registered on the
.B epoll
instance.
-.IP 2.
+.IP (2)
A pipe writer writes 2\ kB of data on the write side of the pipe.
-.IP 3.
+.IP (3)
A call to
.BR epoll_wait (2)
is done that will return
.I rfd
as a ready file descriptor.
-.IP 4.
+.IP (4)
The pipe reader reads 1\ kB of data from
.IR rfd .
-.IP 5.
+.IP (5)
A call to
.BR epoll_wait (2)
is done.
@@ -149,9 +149,9 @@ .SS Level-triggered and edge-triggered
as an edge-triggered
.RB ( EPOLLET )
interface is as follows:
-.IP a) 3
+.IP (1) 5
with nonblocking file descriptors; and
-.IP b)
+.IP (2)
by waiting for an event only after
.BR read (2)
or
@@ -355,7 +355,7 @@ .SS Example for suggested usage
with
.BR EPOLL_CTL_MOD .
.SS Questions and answers
-.IP 0. 4
+.IP \(bu 3
What is the key used to distinguish the file descriptors registered in an
interest list?
.IP
@@ -363,7 +363,7 @@ .SS Questions and answers
the open file description
(also known as an "open file handle",
the kernel's internal representation of an open file).
-.IP 1.
+.IP \(bu
What happens if you register the same file descriptor on an
.B epoll
instance twice?
@@ -397,7 +397,7 @@ .SS Questions and answers
if the duplicate file descriptors are registered with different
.I events
masks.
-.IP 2.
+.IP \(bu
Can two
.B epoll
instances wait for the same file descriptor?
@@ -407,7 +407,7 @@ .SS Questions and answers
.IP
Yes, and events would be reported to both.
However, careful programming may be needed to do this correctly.
-.IP 3.
+.IP \(bu
Is the
.B epoll
file descriptor itself poll/epoll/selectable?
@@ -417,7 +417,7 @@ .SS Questions and answers
.B epoll
file descriptor has events waiting, then it will
indicate as being readable.
-.IP 4.
+.IP \(bu
What happens if one attempts to put an
.B epoll
file descriptor into its own file descriptor set?
@@ -431,14 +431,14 @@ .SS Questions and answers
file descriptor inside another
.B epoll
file descriptor set.
-.IP 5.
+.IP \(bu
Can I send an
.B epoll
file descriptor over a UNIX domain socket to another process?
.IP
Yes, but it does not make sense to do this, since the receiving process
would not have copies of the file descriptors in the interest list.
-.IP 6.
+.IP \(bu
Will closing a file descriptor cause it to be removed from all
.B epoll
interest lists?
@@ -477,13 +477,13 @@ .SS Questions and answers
.BR dup (2)
or
.BR fork (2)).
-.IP 7.
+.IP \(bu
If more than one event occurs between
.BR epoll_wait (2)
calls, are they combined or reported separately?
.IP
They will be combined.
-.IP 8.
+.IP \(bu
Does an operation on a file descriptor affect the
already collected but not yet reported events?
.IP
@@ -491,7 +491,7 @@ .SS Questions and answers
Remove would be meaningless for
this case.
Modify will reread available I/O.
-.IP 9.
+.IP \(bu
Do I need to continuously read/write a file descriptor
until
.B EAGAIN
@@ -530,15 +530,15 @@ .SS Questions and answers
(Avoid this latter technique if you cannot guarantee that
the monitored file descriptor always refers to a stream-oriented file.)
.SS Possible pitfalls and ways to avoid them
-.TP
-.B o Starvation (edge-triggered)
-.PP
+.IP \(bu 3
+.B Starvation (edge-triggered)
+.IP
If there is a large amount of I/O space,
it is possible that by trying to drain
it the other files will not get processed causing starvation.
(This problem is not specific to
.BR epoll .)
-.PP
+.IP
The solution is to maintain a ready list
and mark the file descriptor as ready
in its associated data structure, thereby allowing the application to
@@ -546,9 +546,9 @@ .SS Possible pitfalls and ways to avoid them
all the ready files.
This also supports ignoring subsequent events you
receive for file descriptors that are already ready.
-.TP
-.B o If using an event cache...
-.PP
+.IP \(bu
+.B If using an event cache...
+.IP
If you use an event cache or store all the file descriptors returned from
.BR epoll_wait (2),
then make sure to provide a way to mark
@@ -562,7 +562,7 @@ .SS Possible pitfalls and ways to avoid them
the file descriptor for event #13, then your
event cache might still say there are events waiting for that
file descriptor causing confusion.
-.PP
+.IP
One solution for this is to call, during the processing of event 47,
.BR epoll_ctl ( EPOLL_CTL_DEL )
to delete file descriptor 13 and
diff --git a/man7/fanotify.7 b/man7/fanotify.7
index fd477802c..6531f2eae 100644
--- a/man7/fanotify.7
+++ b/man7/fanotify.7
@@ -968,7 +968,7 @@ .SH BUGS
.PP
As of Linux 3.17,
the following bugs exist:
-.IP * 3
+.IP \(bu 3
On Linux, a filesystem object may be accessible through multiple paths,
for example, a part of a filesystem may be remounted using the
.I \-\-bind
@@ -977,7 +977,7 @@ .SH BUGS
A listener that marked a mount will be notified only of events that were
triggered for a filesystem object using the same mount.
Any other event will pass unnoticed.
-.IP *
+.IP \(bu
.\" FIXME . A patch was proposed.
When an event is generated,
no check is made to see whether the user ID of the
@@ -986,7 +986,7 @@ .SH BUGS
This poses a security risk, when the
.B CAP_SYS_ADMIN
capability is set for programs executed by unprivileged users.
-.IP *
+.IP \(bu
If a call to
.BR read (2)
processes multiple events from the fanotify queue and an error occurs,
diff --git a/man7/feature_test_macros.7 b/man7/feature_test_macros.7
index 2a0d8be2a..6a5f1de62 100644
--- a/man7/feature_test_macros.7
+++ b/man7/feature_test_macros.7
@@ -129,7 +129,7 @@ .SS Feature test macros understood by glibc
> 0.
.PP
First, though, a summary of a few details for the impatient:
-.IP * 3
+.IP \(bu 3
The macros that you most likely need to use in modern source code are
.B _POSIX_C_SOURCE
(for definitions from various versions of POSIX.1),
@@ -139,13 +139,13 @@ .SS Feature test macros understood by glibc
(for GNU and/or Linux specific stuff), and
.B _DEFAULT_SOURCE
(to get definitions that would normally be provided by default).
-.IP *
+.IP \(bu
Certain macros are defined with default values.
Thus, although one or more macros may be indicated as being
required in the SYNOPSIS of a man page,
it may not be necessary to define them explicitly.
Full details of the defaults are given later in this man page.
-.IP *
+.IP \(bu
Defining
.B _XOPEN_SOURCE
with a value of 600 or greater produces the same effects as defining
@@ -167,7 +167,7 @@ .SS Feature test macros understood by glibc
_XOPEN_SOURCE >= 600
.EE
.in
-.IP *
+.IP \(bu
Defining
.B _XOPEN_SOURCE
with a value of 700 or greater produces the same effects as defining
@@ -712,10 +712,10 @@ .SS Default definitions, implicit definitions, and
combining definitions
is not defined or
.B _XOPEN_SOURCE
is defined with a value of 500 or more, then
-.IP * 3
+.IP \(bu 3
.B _POSIX_SOURCE
is defined with the value 1; and
-.IP *
+.IP \(bu
.B _POSIX_C_SOURCE
is defined with one of the following values:
.RS 3
diff --git a/man7/inotify.7 b/man7/inotify.7
index 2bb576e25..dba592c25 100644
--- a/man7/inotify.7
+++ b/man7/inotify.7
@@ -16,7 +16,7 @@ .SH DESCRIPTION
for the directory itself, and for files inside the directory.
.PP
The following system calls are used with this API:
-.IP * 3
+.IP \(bu 3
.BR inotify_init (2)
creates an inotify instance and returns a file descriptor
referring to the inotify instance.
@@ -27,7 +27,7 @@ .SH DESCRIPTION
but has a
.I flags
argument that provides access to some extra functionality.
-.IP *
+.IP \(bu
.BR inotify_add_watch (2)
manipulates the "watch list" associated with an inotify instance.
Each item ("watch") in the watch list specifies the pathname of
@@ -40,16 +40,16 @@ .SH DESCRIPTION
returned by
.BR inotify_add_watch (2)
when the watch is created.
-.IP *
+.IP \(bu
When events occur for monitored files and directories,
those events are made available to the application as structured data that
can be read from the inotify file descriptor using
.BR read (2)
(see below).
-.IP *
+.IP \(bu
.BR inotify_rm_watch (2)
removes an item from an inotify watch list.
-.IP *
+.IP \(bu
When all file descriptors referring to an inotify
instance have been closed (using
.BR close (2)),
@@ -259,10 +259,10 @@ .SS inotify events
(in the same or a different directory).
.PP
When monitoring a directory:
-.IP * 3
+.IP \(bu 3
the events marked above with an asterisk (*) can occur both
for the directory itself and for objects inside the directory; and
-.IP *
+.IP \(bu
the events marked with a plus sign (+) occur only for objects
inside the directory (not for the directory itself).
.PP
diff --git a/man7/ip.7 b/man7/ip.7
index e93ccb840..cd6d25b51 100644
--- a/man7/ip.7
+++ b/man7/ip.7
@@ -89,7 +89,7 @@ .SH DESCRIPTION
Valid values for
.I protocol
include:
-.IP \(bu 2
+.IP \(bu 3
0 and
.B IPPROTO_TCP
for
@@ -1147,16 +1147,16 @@ .SS /proc interfaces
.IR "ephemeral ports" .
An ephemeral port is allocated to a socket in the following circumstances:
.RS
-.IP * 3
+.IP \(bu 3
the port number in a socket address is specified as 0 when calling
.BR bind (2);
-.IP *
+.IP \(bu
.BR listen (2)
is called on a stream socket that was not previously bound;
-.IP *
+.IP \(bu
.BR connect (2)
was called on a socket that was not previously bound;
-.IP *
+.IP \(bu
.BR sendto (2)
is called on a datagram socket that was not previously bound.
.RE
diff --git a/man7/ipc_namespaces.7 b/man7/ipc_namespaces.7
index 754e3c88a..a284d09c8 100644
--- a/man7/ipc_namespaces.7
+++ b/man7/ipc_namespaces.7
@@ -28,10 +28,10 @@ .SH DESCRIPTION
The following
.I /proc
interfaces are distinct in each IPC namespace:
-.IP * 3
+.IP \(bu 3
The POSIX message queue interfaces in
.IR /proc/sys/fs/mqueue .
-.IP *
+.IP \(bu
The System V IPC interfaces in
.IR /proc/sys/kernel ,
namely:
@@ -44,7 +44,7 @@ .SH DESCRIPTION
.IR shmmni ,
and
.IR shm_rmid_forced .
-.IP *
+.IP \(bu
The System V IPC interfaces in
.IR /proc/sysvipc .
.PP
diff --git a/man7/kernel_lockdown.7 b/man7/kernel_lockdown.7
index a6528f245..883f96255 100644
--- a/man7/kernel_lockdown.7
+++ b/man7/kernel_lockdown.7
@@ -50,7 +50,7 @@ .SS Coverage
.PP
and the ability to directly configure and control devices, so as to prevent
the use of a device to access or modify a kernel image:
-.IP \(bu 2
+.IP \(bu 3
The use of module parameters that directly specify hardware parameters to
drivers through the kernel command line or when loading a module.
.IP \(bu
@@ -75,7 +75,7 @@ .SS Coverage
The use of ACPI custom methods.
.PP
Certain facilities are restricted:
-.IP \(bu 2
+.IP \(bu 3
Only validly signed modules may be loaded (waived if the module file being
loaded is vouched for by IMA appraisal).
.IP \(bu
diff --git a/man7/keyrings.7 b/man7/keyrings.7
index 56c9fbe2b..f6f9594ba 100644
--- a/man7/keyrings.7
+++ b/man7/keyrings.7
@@ -314,7 +314,7 @@ .SS Possession
The concept of possession is important to understanding the keyrings
security model.
Whether a thread possesses a key is determined by the following rules:
-.IP (1) 4
+.IP (1) 5
Any key or keyring that does not grant
.I search
permission to the caller is ignored in all the following rules.
@@ -353,13 +353,13 @@ .SS Possession
.\"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
.SS Access rights
Each key has the following security-related attributes:
-.IP * 3
+.IP \(bu 3
The owning user ID
-.IP *
+.IP \(bu
The ID of a group that is permitted to access the key
-.IP *
+.IP \(bu
A security label
-.IP *
+.IP \(bu
A permissions mask
.PP
The permissions mask contains four sets of rights.
@@ -449,7 +449,7 @@ .SS Searching for keys
for use by internal components that make use of keys.)
.PP
The search algorithm works as follows:
-.IP (1) 4
+.IP (1) 5
The process keyrings are searched in the following order: the thread
.BR thread\-keyring (7)
if it exists, the
diff --git a/man7/locale.7 b/man7/locale.7
index 80492c281..696124187 100644
--- a/man7/locale.7
+++ b/man7/locale.7
@@ -219,16 +219,16 @@ .SH DESCRIPTION
is an empty string,
.IR \(dq\(dq ,
for the default locale, it is determined using the following steps:
-.IP 1. 3
+.IP (1) 5
If there is a non-null environment variable
.BR LC_ALL ,
the value of
.B LC_ALL
is used.
-.IP 2.
+.IP (2)
If an environment variable with the same name as one of the categories
above exists and is non-null, its value is used for that category.
-.IP 3.
+.IP (3)
If there is a non-null environment variable
.BR LANG ,
the value of
diff --git a/man7/man-pages.7 b/man7/man-pages.7
index 52446b769..cda5b4d0f 100644
--- a/man7/man-pages.7
+++ b/man7/man-pages.7
@@ -482,17 +482,17 @@ .SS SYNOPSIS
However, blank lines (achieved using
.IR .PP )
may be added in the following cases:
-.IP * 3
+.IP \(bu 3
to separate long lists of function prototypes into related groups
(see for example
.BR list (3));
-.IP *
+.IP \(bu
in other cases that may improve readability.
.PP
In the SYNOPSIS, a long function prototype may need to be
continued over to the next line.
The continuation line is indented according to the following rules:
-.IP 1. 3
+.IP (1) 5
If there is a single such prototype that needs to be continued,
then align the continuation line so that when the page is
rendered on a fixed-width font device (e.g., on an xterm) the
@@ -503,14 +503,14 @@ .SS SYNOPSIS
or a further continuation line where the function prototype is
very long.)
As an example:
-.PP
-.RS
+.IP
+.in +4n
.nf
.BI "int tcsetattr(int " fd ", int " optional_actions ,
.BI " const struct termios *" termios_p );
.fi
-.RE
-.IP 2. 3
+.in
+.IP (2)
But, where multiple functions in the SYNOPSIS require
continuation lines, and the function names have different
lengths, then align all continuation lines to start in the
@@ -542,19 +542,19 @@ .SS RETURN VALUE
.SS ATTRIBUTES
.\" See man-pages commit c466875ecd64ed3d3cd3e578406851b7dfb397bf
Note the following:
-.IP * 3
+.IP \(bu 3
Wrap the table in this section in a
.IR ".ad\ l" / .ad
pair to disable text filling and a
.IR .nh / .hy
pair to disable hyphenation.
-.IP *
+.IP \(bu
Ensure that the table occupies the full page width through the use of an
.I lbx
description for one of the columns
(usually the first column,
though in some cases the last column if it contains a lot of text).
-.IP *
+.IP \(bu
Make free use of
.IR T{ / T}
macro pairs to allow table cells to be broken over multiple lines
@@ -712,11 +712,11 @@ .SS Spelling
.PP
Aside from the well-known spelling differences,
there are a few other subtleties to watch for:
-.IP * 3
+.IP \(bu 3
American English tends to use the forms "backward", "upward", "toward",
and so on
rather than the British forms "backwards", "upwards", "towards", and so on.
-.IP *
+.IP \(bu
Opinions are divided on "acknowledgement" vs "acknowledgment".
The latter is predominant, but not universal usage in American English.
POSIX and the BSD license use the former spelling.
@@ -1017,11 +1017,11 @@ .SS Generating optimal glyphs
.PP
The use of real minus signs serves the following purposes:
.\"
https://lore.kernel.org/linux-man/20210121061158.5ul7226fgbrmodbt@localhost.localdomain/
-.IP * 3
+.IP \(bu 3
To provide better renderings on various targets other than
ASCII terminals,
notably in PDF and on Unicode/UTF\-8-capable terminals.
-.IP *
+.IP \(bu
To generate glyphs that when copied from rendered pages will
produce real minus signs when pasted into a terminal.
.PP
@@ -1053,22 +1053,22 @@ .SS Example programs and shell sessions
Manual pages may include example programs demonstrating how to
use a system call or library function.
However, note the following:
-.IP * 3
+.IP \(bu 3
Example programs should be written in C.
-.IP *
+.IP \(bu
An example program is necessary and useful only if it demonstrates
something beyond what can easily be provided in a textual
description of the interface.
An example program that does nothing
other than call an interface usually serves little purpose.
-.IP *
+.IP \(bu
Example programs should ideally be short
(e.g., a good example can often be provided in less than 100 lines of code),
though in some cases longer programs may be necessary
to properly illustrate the use of an API.
-.IP *
+.IP \(bu
Expressive code is appreciated.
-.IP *
+.IP \(bu
Comments should included where helpful.
Complete sentences in free-standing comments should be
terminated by a period.
@@ -1076,18 +1076,18 @@ .SS Example programs and shell sessions
(i.e., comments that are placed on the same line of code);
such comments are in any case typically brief phrases
rather than complete sentences.
-.IP *
+.IP \(bu
Example programs should do error checking after system calls and
library function calls.
-.IP *
+.IP \(bu
Example programs should be complete, and compile without
warnings when compiled with \fIcc\ \-Wall\fP.
-.IP *
+.IP \(bu
Where possible and appropriate, example programs should allow
experimentation, by varying their behavior based on inputs
(ideally from command-line arguments, or alternatively, via
input read by the program).
-.IP *
+.IP \(bu
Example programs should be laid out according to Kernighan and
Ritchie style, with 4-space indents.
(Avoid the use of TAB characters in source code!)
@@ -1099,7 +1099,7 @@ .SS Example programs and shell sessions
indent \-npro \-kr \-i4 \-ts4 \-sob \-l72 \-ss \-nut \-psl prog.c
.EE
.in
-.IP *
+.IP \(bu
For consistency, all example programs should terminate using either of:
.IP
.in +4n
@@ -1118,7 +1118,7 @@ .SS Example programs and shell sessions
return n;
.EE
.in
-.IP *
+.IP \(bu
If there is extensive explanatory text before the
program source code, mark off the source code
with a subsection heading
@@ -1135,11 +1135,11 @@ .SS Example programs and shell sessions
.PP
If you include a shell session log demonstrating the use of a program
or other system feature:
-.IP * 3
+.IP \(bu 3
Place the session log above the source code listing.
-.IP *
+.IP \(bu
Indent the session log by four spaces.
-.IP *
+.IP \(bu
Boldface the user input text,
to distinguish it from output produced by the system.
.PP
diff --git a/man7/mount_namespaces.7 b/man7/mount_namespaces.7
index a1e0c0d36..5530ce704 100644
--- a/man7/mount_namespaces.7
+++ b/man7/mount_namespaces.7
@@ -37,12 +37,12 @@ .SH DESCRIPTION
flag.
When a new mount namespace is created,
its mount list is initialized as follows:
-.IP * 3
+.IP \(bu 3
If the namespace is created using
.BR clone (2),
the mount list of the child's namespace is a copy
of the mount list in the parent process's mount namespace.
-.IP *
+.IP \(bu
If the namespace is created using
.BR unshare (2),
the mount list of the new namespace is a copy of
@@ -144,9 +144,9 @@ .SH SHARED SUBTREES
Members are added to a
.I peer group
when a mount is marked as shared and either:
-.IP * 3
+.IP (a) 5
the mount is replicated during the creation of a new mount namespace; or
-.IP *
+.IP (b)
a new bind mount is created from the mount.
.PP
In both of these cases, the new mount joins the peer group
diff --git a/man7/mq_overview.7 b/man7/mq_overview.7
index dcab4ced8..10ae3ae5a 100644
--- a/man7/mq_overview.7
+++ b/man7/mq_overview.7
@@ -168,13 +168,13 @@ .SS /proc interfaces
.B HARD_MSGMAX
has changed across kernel versions:
.RS
-.IP * 3
+.IP \(bu 3
Up to Linux 2.6.32:
.I 131072\~/\~sizeof(void\~*)
-.IP *
+.IP \(bu
Linux 2.6.33 to 3.4:
.I (32768\~*\~sizeof(void\~*) / 4)
-.IP *
+.IP \(bu
Since Linux 3.5:
.\" commit 5b5c4d1a1440e94994c73dddbad7be0676cd8b9a
65,536
@@ -222,12 +222,12 @@ .SS /proc interfaces
.I msgsize_max
has varied across kernel versions:
.RS
-.IP * 3
+.IP \(bu 3
Before Linux 2.6.28, the upper limit is
.BR INT_MAX .
-.IP *
+.IP \(bu
From Linux 2.6.28 to 3.4, the limit is 1,048,576.
-.IP *
+.IP \(bu
Since Linux 3.5, the limit is 16,777,216
.RB ( HARD_MSGSIZEMAX ).
.RE
diff --git a/man7/namespaces.7 b/man7/namespaces.7
index dcae034c4..b7d314255 100644
--- a/man7/namespaces.7
+++ b/man7/namespaces.7
@@ -310,48 +310,48 @@ .SS The /proc/sys/user directory
uts namespaces that may be created in the user namespace.
.PP
Note the following details about these files:
-.IP * 3
+.IP \(bu 3
The values in these files are modifiable by privileged processes.
-.IP *
+.IP \(bu
The values exposed by these files are the limits for the user namespace
in which the opening process resides.
-.IP *
+.IP \(bu
The limits are per-user.
Each user in the same user namespace
can create namespaces up to the defined limit.
-.IP *
+.IP \(bu
The limits apply to all users, including UID 0.
-.IP *
+.IP \(bu
These limits apply in addition to any other per-namespace
limits (such as those for PID and user namespaces) that may be enforced.
-.IP *
+.IP \(bu
Upon encountering these limits,
.BR clone (2)
and
.BR unshare (2)
fail with the error
.BR ENOSPC .
-.IP *
+.IP \(bu
For the initial user namespace,
the default value in each of these files is half the limit on the number
of threads that may be created
.RI ( /proc/sys/kernel/threads\-max ).
In all descendant user namespaces, the default value in each file is
.BR MAXINT .
-.IP *
+.IP \(bu
When a namespace is created, the object is also accounted
against ancestor namespaces.
More precisely:
.RS
-.IP + 3
+.IP \(bu 3
Each user namespace has a creator UID.
-.IP +
+.IP \(bu
When a namespace is created,
it is accounted against the creator UIDs in each of the
ancestor user namespaces,
and the kernel ensures that the corresponding namespace limit
for the creator UID in the ancestor namespace is not exceeded.
-.IP +
+.IP \(bu
The aforementioned point ensures that creating a new user namespace
cannot be used as a means to escape the limits in force
in the current user namespace.
@@ -364,32 +364,32 @@ .SS Namespace lifetime
However, there are a number of other factors that may pin
a namespace into existence even though it has no member processes.
These factors include the following:
-.IP * 3
+.IP \(bu 3
An open file descriptor or a bind mount exists for the corresponding
.IR /proc/ pid /ns/*
file.
-.IP *
+.IP \(bu
The namespace is hierarchical (i.e., a PID or user namespace),
and has a child namespace.
-.IP *
+.IP \(bu
It is a user namespace that owns one or more nonuser namespaces.
-.IP *
+.IP \(bu
It is a PID namespace,
and there is a process that refers to the namespace via a
.IR /proc/ pid /ns/pid_for_children
symbolic link.
-.IP *
+.IP \(bu
It is a time namespace,
and there is a process that refers to the namespace via a
.IR /proc/ pid /ns/time_for_children
symbolic link.
-.IP *
+.IP \(bu
It is an IPC namespace, and a corresponding mount of an
.I mqueue
filesystem (see
.BR mq_overview (7))
refers to this namespace.
-.IP *
+.IP \(bu
It is a PID namespace, and a corresponding mount of a
.BR proc (5)
filesystem refers to this namespace.
diff --git a/man7/nptl.7 b/man7/nptl.7
index f7cabc4ef..5a17e0541 100644
--- a/man7/nptl.7
+++ b/man7/nptl.7
@@ -26,10 +26,10 @@ .SS NPTL and signals
various glibc library functions and system call wrapper functions
attempt to hide these signals from applications,
as follows:
-.IP * 3
+.IP \(bu 3
.B SIGRTMIN
is defined with the value 34 (rather than 32).
-.IP *
+.IP \(bu
The
.BR sigwaitinfo (2),
.BR sigtimedwait (2),
@@ -37,13 +37,13 @@ .SS NPTL and signals
.BR sigwait (3)
interfaces silently ignore requests to wait for these two signals
if they are specified in the signal set argument of these calls.
-.IP *
+.IP \(bu
The
.BR sigprocmask (2)
and
.BR pthread_sigmask (3)
interfaces silently ignore attempts to block these two signals.
-.IP *
+.IP \(bu
The
.BR sigaction (2),
.BR pthread_kill (3),
@@ -52,7 +52,7 @@ .SS NPTL and signals
interfaces fail with the error
.B EINVAL
(indicating an invalid signal number) if these signals are specified.
-.IP *
+.IP \(bu
.BR sigfillset (3)
does not include these two signals when it creates a full signal set.
.\"
diff --git a/man7/packet.7 b/man7/packet.7
index 6a32d1b5c..c3650cfec 100644
--- a/man7/packet.7
+++ b/man7/packet.7
@@ -297,7 +297,7 @@ .SS Socket options
Fanout supports multiple algorithms to spread traffic between sockets,
as follows:
.RS
-.IP * 3
+.IP \(bu 3
The default mode,
.BR PACKET_FANOUT_HASH ,
sends packets from the same flow to the same socket to maintain
@@ -305,21 +305,21 @@ .SS Socket options
For each packet, it chooses a socket by taking the packet flow hash
modulo the number of sockets in the group, where a flow hash is a hash
over network-layer address and optional transport-layer port fields.
-.IP *
+.IP \(bu
The load-balance mode
.B PACKET_FANOUT_LB
implements a round-robin algorithm.
-.IP *
+.IP \(bu
.B PACKET_FANOUT_CPU
selects the socket based on the CPU that the packet arrived on.
-.IP *
+.IP \(bu
.B PACKET_FANOUT_ROLLOVER
processes all data on a single socket, moving to the next when one
becomes backlogged.
-.IP *
+.IP \(bu
.B PACKET_FANOUT_RND
selects the socket using a pseudo-random number generator.
-.IP *
+.IP \(bu
.B PACKET_FANOUT_QM
.\" commit 2d36097d26b5991d71a2cf4a20c1a158f0f1bfcd
(available since Linux 3.14)
diff --git a/man7/pipe.7 b/man7/pipe.7
index 0194bff8a..40d08d809 100644
--- a/man7/pipe.7
+++ b/man7/pipe.7
@@ -334,7 +334,7 @@ .SS BUGS
.\" These bugs where remedied by a series of patches, in particular,
.\" commit b0b91d18e2e97b741b294af9333824ecc3fadfd8 and
.\" commit a005ca0e6813e1d796a7422a7e31d8b8d6555df1
-.IP (1) 5
+.IP (a) 5
When increasing the pipe capacity, the checks against the soft and
hard limits were made against existing consumption,
and excluded the memory required for the increased pipe capacity.
@@ -344,7 +344,7 @@ .SS BUGS
.IP
Starting with Linux 4.9,
the limit checking includes the memory required for the new pipe capacity.
-.IP (2)
+.IP (b)
The limit checks were performed even when the new pipe capacity was
less than the existing pipe capacity.
This could lead to problems if a user set a large pipe capacity,
@@ -354,22 +354,23 @@ .SS BUGS
Starting with Linux 4.9, checks against the limits
are performed only when increasing a pipe's capacity;
an unprivileged user can always decrease a pipe's capacity.
-.IP (3)
+.IP (c)
The accounting and checking against the limits were done as follows:
+.IP
.RS
.PD 0
-.IP (a) 4
+.IP (1) 5
Test whether the user has exceeded the limit.
-.IP (b)
+.IP (2)
Make the new pipe buffer allocation.
-.IP (c)
+.IP (3)
Account new allocation against the limits.
.PD
.RE
.IP
This was racey.
-Multiple processes could pass point (a) simultaneously,
-and then allocate pipe buffers that were accounted for only in step (c),
+Multiple processes could pass point (1) simultaneously,
+and then allocate pipe buffers that were accounted for only in step (3),
with the result that the user's pipe buffer
allocation could be pushed over the limit.
.IP
@@ -377,7 +378,7 @@ .SS BUGS
the accounting step is performed before doing the allocation,
and the operation fails if the limit would be exceeded.
.PP
-Before Linux 4.9, bugs similar to points (1) and (3) could also occur
+Before Linux 4.9, bugs similar to points (a) and (c) could also occur
when the kernel allocated memory for a new pipe buffer;
that is, when calling
.BR pipe (2)
diff --git a/man7/pthreads.7 b/man7/pthreads.7
index d2c010b0e..606085d8e 100644
--- a/man7/pthreads.7
+++ b/man7/pthreads.7
@@ -15,44 +15,44 @@ .SH DESCRIPTION
.PP
POSIX.1 also requires that threads share a range of other attributes
(i.e., these attributes are process-wide rather than per-thread):
-.IP \- 3
+.IP \(bu 3
process ID
-.IP \- 3
+.IP \(bu
parent process ID
-.IP \- 3
+.IP \(bu
process group ID and session ID
-.IP \- 3
+.IP \(bu
controlling terminal
-.IP \- 3
+.IP \(bu
user and group IDs
-.IP \- 3
+.IP \(bu
open file descriptors
-.IP \- 3
+.IP \(bu
record locks (see
.BR fcntl (2))
-.IP \- 3
+.IP \(bu
signal dispositions
-.IP \- 3
+.IP \(bu
file mode creation mask
.RB ( umask (2))
-.IP \- 3
+.IP \(bu
current directory
.RB ( chdir (2))
and
root directory
.RB ( chroot (2))
-.IP \- 3
+.IP \(bu
interval timers
.RB ( setitimer (2))
and POSIX timers
.RB ( timer_create (2))
-.IP \- 3
+.IP \(bu
nice value
.RB ( setpriority (2))
-.IP \- 3
+.IP \(bu
resource limits
.RB ( setrlimit (2))
-.IP \- 3
+.IP \(bu
measurements of the consumption of CPU time
.RB ( times (2))
and resources
@@ -60,29 +60,29 @@ .SH DESCRIPTION
.PP
As well as the stack, POSIX.1 specifies that various other
attributes are distinct for each thread, including:
-.IP \- 3
+.IP \(bu 3
thread ID (the
.I pthread_t
data type)
-.IP \- 3
+.IP \(bu
signal mask
.RB ( pthread_sigmask (3))
-.IP \- 3
+.IP \(bu
the
.I errno
variable
-.IP \- 3
+.IP \(bu
alternate signal stack
.RB ( sigaltstack (2))
-.IP \- 3
+.IP \(bu
real-time scheduling policy and priority
.RB ( sched (7))
.PP
The following Linux-specific features are also per-thread:
-.IP \- 3
+.IP \(bu 3
capabilities (see
.BR capabilities (7))
-.IP \- 3
+.IP \(bu
CPU affinity
.RB ( sched_setaffinity (2))
.SS Pthreads function return values
@@ -681,14 +681,14 @@ .SS Linux implementations of POSIX threads
system call.
.SS LinuxThreads
The notable features of this implementation are the following:
-.IP \- 3
+.IP \(bu 3
In addition to the main (initial) thread,
and the threads that the program creates using
.BR pthread_create (3),
the implementation creates a "manager" thread.
This thread handles thread creation and termination.
(Problems can result if this thread is inadvertently killed.)
-.IP \- 3
+.IP \(bu
Signals are used internally by the implementation.
On Linux 2.2 and later, the first three real-time signals are used
(see also
@@ -700,7 +700,7 @@ .SS LinuxThreads
are used.
Applications must avoid the use of whichever set of signals is
employed by the implementation.
-.IP \- 3
+.IP \(bu
Threads do not share process IDs.
(In effect, LinuxThreads threads are implemented as processes which share
more information than usual, but which do not share a common process ID.)
@@ -710,11 +710,11 @@ .SS LinuxThreads
.PP
The LinuxThreads implementation deviates from the POSIX.1
specification in a number of ways, including the following:
-.IP \- 3
+.IP \(bu 3
Calls to
.BR getpid (2)
return a different value in each thread.
-.IP \- 3
+.IP \(bu
Calls to
.BR getppid (2)
in threads other than the main thread return the process ID of the
@@ -723,7 +723,7 @@ .SS LinuxThreads
in these threads should return the same value as
.BR getppid (2)
in the main thread.
-.IP \- 3
+.IP \(bu
When one thread creates a new child process using
.BR fork (2),
any thread should be able to
@@ -733,39 +733,39 @@ .SS LinuxThreads
created the child to
.BR wait (2)
on it.
-.IP \- 3
+.IP \(bu
When a thread calls
.BR execve (2),
all other threads are terminated (as required by POSIX.1).
However, the resulting process has the same PID as the thread that called
.BR execve (2):
it should have the same PID as the main thread.
-.IP \- 3
+.IP \(bu
Threads do not share user and group IDs.
This can cause complications with set-user-ID programs and
can cause failures in Pthreads functions if an application
changes its credentials using
.BR seteuid (2)
or similar.
-.IP \- 3
+.IP \(bu
Threads do not share a common session ID and process group ID.
-.IP \- 3
+.IP \(bu
Threads do not share record locks created using
.BR fcntl (2).
-.IP \- 3
+.IP \(bu
The information returned by
.BR times (2)
and
.BR getrusage (2)
is per-thread rather than process-wide.
-.IP \- 3
+.IP \(bu
Threads do not share semaphore undo values (see
.BR semop (2)).
-.IP \- 3
+.IP \(bu
Threads do not share interval timers.
-.IP \- 3
+.IP \(bu
Threads do not share a common nice value.
-.IP \- 3
+.IP \(bu
POSIX.1 distinguishes the notions of signals that are directed
to the process as a whole and signals that are directed to individual
threads.
@@ -775,7 +775,7 @@ .SS LinuxThreads
arbitrarily selected thread within the process.
LinuxThreads does not support the notion of process-directed signals:
signals may be sent only to specific threads.
-.IP \- 3
+.IP \(bu
Threads have distinct alternate signal stack settings.
However, a new thread's alternate signal stack settings
are copied from the thread that created it, so that
@@ -797,7 +797,7 @@ .SS NPTL
for further details.
.PP
NPTL still has at least one nonconformance with POSIX.1:
-.IP \- 3
+.IP \(bu 3
Threads do not share a common nice value.
.\" FIXME . bug report filed for NPTL nice nonconformance
.\" http://bugzilla.kernel.org/show_bug.cgi?id=6258
@@ -806,26 +806,26 @@ .SS NPTL
.\" Monitor this to see if it makes it into mainline.
.PP
Some NPTL nonconformances occur only with older kernels:
-.IP \- 3
+.IP \(bu 3
The information returned by
.BR times (2)
and
.BR getrusage (2)
is per-thread rather than process-wide (fixed in kernel 2.6.9).
-.IP \- 3
+.IP \(bu
Threads do not share resource limits (fixed in kernel 2.6.10).
-.IP \- 3
+.IP \(bu
Threads do not share interval timers (fixed in kernel 2.6.12).
-.IP \- 3
+.IP \(bu
Only the main thread is permitted to start a new session using
.BR setsid (2)
(fixed in kernel 2.6.16).
-.IP \- 3
+.IP \(bu
Only the main thread is permitted to make the process into a
process group leader using
.BR setpgid (2)
(fixed in kernel 2.6.16).
-.IP \- 3
+.IP \(bu
Threads have distinct alternate signal stack settings.
However, a new thread's alternate signal stack settings
are copied from the thread that created it, so that
@@ -833,7 +833,7 @@ .SS NPTL
(fixed in kernel 2.6.16).
.PP
Note the following further points about the NPTL implementation:
-.IP \- 3
+.IP \(bu 3
If the stack size soft resource limit (see the description of
.B RLIMIT_STACK
in
diff --git a/man7/queue.7 b/man7/queue.7
index 78fb4d33e..919262b52 100644
--- a/man7/queue.7
+++ b/man7/queue.7
@@ -30,13 +30,13 @@ .SH DESCRIPTION
doubly linked circular queues
.PP
All structures support the following functionality:
-.IP * 3
+.IP \(bu 3
Insertion of a new entry at the head of the list.
-.IP *
+.IP \(bu
Insertion of a new entry after any element in the list.
-.IP *
+.IP \(bu
O(1) removal of an entry from the head of the list.
-.IP *
+.IP \(bu
Forward traversal through the list.
.\".IP *
.\" Swapping the contents of two lists.
@@ -51,21 +51,21 @@ .SS Singly linked lists (SLIST)
large datasets and few or no removals,
or for implementing a LIFO queue.
Singly linked lists add the following functionality:
-.IP * 3
+.IP \(bu 3
O(n) removal of any entry in the list.
.SS Singly linked tail queues (STAILQ)
Singly linked tail queues add the following functionality:
-.IP * 3
+.IP \(bu 3
Entries can be added at the end of a list.
-.IP *
+.IP \(bu
O(n) removal of any entry in the list.
-.IP *
+.IP \(bu
They may be concatenated.
.PP
However:
-.IP * 3
+.IP \(bu 3
All list insertions must specify the head of the list.
-.IP *
+.IP \(bu
Each head entry requires two pointers rather than one.
.PP
Singly linked tail queues are ideal for applications with
@@ -74,45 +74,45 @@ .SS Singly linked tail queues (STAILQ)
.SS Doubly linked data structures
All doubly linked types of data structures (lists and tail queues)
additionally allow:
-.IP * 3
+.IP \(bu 3
Insertion of a new entry before any element in the list.
-.IP *
+.IP \(bu
O(1) removal of any entry in the list.
.PP
However:
-.IP * 3
+.IP \(bu 3
Each element requires two pointers rather than one.
.SS Doubly linked lists (LIST)
Linked lists are the simplest of the doubly linked data structures.
They add the following functionality over the above:
-.IP * 3
+.IP \(bu 3
They may be traversed backwards.
.PP
However:
-.IP * 3
+.IP \(bu 3
To traverse backwards, an entry to begin the traversal and the list in
which it is contained must be specified.
.SS Doubly linked tail queues (TAILQ)
Tail queues add the following functionality:
-.IP * 3
+.IP \(bu 3
Entries can be added at the end of a list.
-.IP *
+.IP \(bu
They may be traversed backwards, from tail to head.
-.IP *
+.IP \(bu
They may be concatenated.
.PP
However:
-.IP * 3
+.IP \(bu 3
All list insertions and removals must specify the head of the list.
-.IP *
+.IP \(bu
Each head entry requires two pointers rather than one.
.SS Doubly linked circular queues (CIRCLEQ)
Circular queues add the following functionality over the above:
-.IP * 3
+.IP \(bu 3
The first and last entries are connected.
.PP
However:
-.IP * 3
+.IP \(bu 3
The termination condition for traversal is more complex.
.SH STANDARDS
Not in POSIX.1, POSIX.1-2001, or POSIX.1-2008.
diff --git a/man7/random.7 b/man7/random.7
index 9a7e49ee7..666e13332 100644
--- a/man7/random.7
+++ b/man7/random.7
@@ -18,7 +18,7 @@ .SH DESCRIPTION
It is designed for security, rather than speed.
.PP
The following interfaces provide access to output from the kernel CSPRNG:
-.IP * 3
+.IP \(bu 3
The
.I /dev/urandom
and
@@ -27,7 +27,7 @@ .SH DESCRIPTION
.BR random (4).
These devices have been present on Linux since early times,
and are also available on many other systems.
-.IP *
+.IP \(bu
The Linux-specific
.BR getrandom (2)
system call, available since Linux 3.17.
diff --git a/man7/rtld-audit.7 b/man7/rtld-audit.7
index 92ca2f176..42c1795ea 100644
--- a/man7/rtld-audit.7
+++ b/man7/rtld-audit.7
@@ -464,11 +464,11 @@ .SH STANDARDS
.SH NOTES
Note the following differences from the Solaris dynamic linker
auditing API:
-.IP * 3
+.IP \(bu 3
The Solaris
.BR la_objfilter ()
interface is not supported by the GNU implementation.
-.IP *
+.IP \(bu
The Solaris
.BR la_symbind32 ()
and
@@ -476,7 +476,7 @@ .SH NOTES
functions do not provide a
.I symname
argument.
-.IP *
+.IP \(bu
The Solaris
.BR la_pltexit ()
function does not provide
diff --git a/man7/sched.7 b/man7/sched.7
index 5baf6fad4..843255215 100644
--- a/man7/sched.7
+++ b/man7/sched.7
@@ -137,15 +137,15 @@ .SS SCHED_FIFO: First in-first out scheduling
algorithm without time slicing.
For threads scheduled under the
\fBSCHED_FIFO\fP policy, the following rules apply:
-.IP 1) 3
+.IP \(bu 3
A running \fBSCHED_FIFO\fP thread that has been preempted by another thread of
higher priority will stay at the head of the list for its priority and
will resume execution as soon as all threads of higher priority are
blocked again.
-.IP 2)
+.IP \(bu
When a blocked \fBSCHED_FIFO\fP thread becomes runnable, it
will be inserted at the end of the list for its priority.
-.IP 3)
+.IP \(bu
If a call to
.BR sched_setscheduler (2),
.BR sched_setparam (2),
@@ -160,15 +160,15 @@ .SS SCHED_FIFO: First in-first out scheduling
the effect on the thread's position in the list depends on
the direction of the change to threads priority:
.RS
-.IP \(bu 3
+.IP (a) 5
If the thread's priority is raised,
it is placed at the end of the list for its new priority.
As a consequence,
it may preempt a currently running thread with the same priority.
-.IP \(bu
+.IP (b)
If the thread's priority is unchanged,
its position in the run list is unchanged.
-.IP \(bu
+.IP (c)
If the thread's priority is lowered,
it is placed at the front of the list for its new priority.
.RE
@@ -180,7 +180,7 @@ .SS SCHED_FIFO: First in-first out scheduling
the list for its priority.
.\" In 2.2.x and 2.4.x, the thread is placed at the front of the queue
.\" In 2.0.x, the Right Thing happened: the thread went to the back -- MTK
-.IP 4)
+.IP \(bu
A thread calling
.BR sched_yield (2)
will be put at the end of the list.
@@ -492,7 +492,7 @@ .SS Resetting scheduling policy for child processes
.BR fork (2)
do not inherit privileged scheduling policies.
The reset-on-fork flag can be set by either:
-.IP * 3
+.IP \(bu 3
ORing the
.B SCHED_RESET_ON_FORK
flag into the
@@ -501,7 +501,7 @@ .SS Resetting scheduling policy for child processes
.BR sched_setscheduler (2)
(since Linux 2.6.32);
or
-.IP *
+.IP \(bu
specifying the
.B SCHED_FLAG_RESET_ON_FORK
flag in
@@ -524,7 +524,7 @@ .SS Resetting scheduling policy for child processes
.PP
More precisely, if the reset-on-fork flag is set,
the following rules apply for subsequently created children:
-.IP * 3
+.IP \(bu 3
If the calling thread has a scheduling policy of
.B SCHED_FIFO
or
@@ -532,7 +532,7 @@ .SS Resetting scheduling policy for child processes
the policy is reset to
.B SCHED_OTHER
in child processes.
-.IP *
+.IP \(bu
If the calling process has a negative nice value,
the nice value is reset to zero in child processes.
.PP
@@ -571,7 +571,7 @@ .SS Privileges and resource limits
.B SCHED_FIFO
policies.
The rules for changing scheduling policy and priority are as follows:
-.IP * 3
+.IP \(bu 3
If an unprivileged thread has a nonzero
.B RLIMIT_RTPRIO
soft limit, then it can change its scheduling policy and priority,
@@ -579,17 +579,17 @@ .SS Privileges and resource limits
value higher than the maximum of its current priority and its
.B RLIMIT_RTPRIO
soft limit.
-.IP *
+.IP \(bu
If the
.B RLIMIT_RTPRIO
soft limit is 0, then the only permitted changes are to lower the priority,
or to switch to a non-real-time policy.
-.IP *
+.IP \(bu
Subject to the same rules,
another unprivileged thread can also make these changes,
as long as the effective user ID of the thread making the change
matches the real or effective user ID of the target thread.
-.IP *
+.IP \(bu
Special rules apply for the
.B SCHED_IDLE
policy.
@@ -832,11 +832,11 @@ .SS The nice value and group scheduling
rooted under the initial task group on the system,
known as the "root task group".
Task groups are formed in the following circumstances:
-.IP * 3
+.IP \(bu 3
All of the threads in a CPU cgroup form a task group.
The parent of this task group is the task group of the
corresponding parent cgroup.
-.IP *
+.IP \(bu
If autogrouping is enabled,
then all of the threads that are (implicitly) placed in an autogroup
(i.e., the same session, as created by
@@ -844,14 +844,14 @@ .SS The nice value and group scheduling
form a task group.
Each new autogroup is thus a separate task group.
The root task group is the parent of all such autogroups.
-.IP *
+.IP \(bu
If autogrouping is enabled, then the root task group consists of
all processes in the root CPU cgroup that were not
otherwise implicitly placed into a new autogroup.
-.IP *
+.IP \(bu
If autogrouping is disabled, then the root task group consists of
all processes in the root CPU cgroup.
-.IP *
+.IP \(bu
If group scheduling was disabled (i.e., the kernel was configured without
.BR CONFIG_FAIR_GROUP_SCHED ),
then all of the processes on the system are notionally placed
diff --git a/man7/signal-safety.7 b/man7/signal-safety.7
index 91e3d5132..b6a563b91 100644
--- a/man7/signal-safety.7
+++ b/man7/signal-safety.7
@@ -39,13 +39,13 @@ .SH DESCRIPTION
will operate on inconsistent data, with unpredictable results.
.PP
To avoid problems with unsafe functions, there are two possible choices:
-.IP 1. 3
+.IP (a) 5
Ensure that
-(a) the signal handler calls only async-signal-safe functions,
+(1) the signal handler calls only async-signal-safe functions,
and
-(b) the signal handler itself is reentrant
+(2) the signal handler itself is reentrant
with respect to global variables in the main program.
-.IP 2.
+.IP (b)
Block signal delivery in the main program when calling functions
that are unsafe or operating on global data that is also accessed
by the signal handler.
@@ -273,14 +273,14 @@ .SH DESCRIPTION
.TE
.PP
Notes:
-.IP * 3
+.IP \(bu 3
POSIX.1-2001 and POSIX.1-2001 TC2 required the functions
.BR fpathconf (3),
.BR pathconf (3),
and
.BR sysconf (3)
to be async-signal-safe, but this requirement was removed in POSIX.1-2008.
-.IP *
+.IP \(bu
If a signal handler interrupts the execution of an unsafe function,
and the handler terminates via a call to
.BR longjmp (3)
@@ -288,7 +288,7 @@ .SH DESCRIPTION
.BR siglongjmp (3)
and the program subsequently calls an unsafe function,
then the behavior of the program is undefined.
-.IP *
+.IP \(bu
POSIX.1-2001 TC1 clarified
that if an application calls
.BR fork (2)
@@ -301,7 +301,7 @@ .SH DESCRIPTION
.BR fork (2)
from the list of async-signal-safe functions.
.\"
-.IP * 3
+.IP \(bu
Asynchronous signal handlers that call functions which are cancelation
points and nest over regions of deferred cancelation may trigger
cancelation whose behavior is as if asynchronous cancelation had
@@ -317,7 +317,7 @@ .SS errno
.SS Deviations in the GNU C library
The following known deviations from the standard occur in
the GNU C library:
-.IP * 3
+.IP \(bu 3
Before glibc 2.24,
.BR execl (3)
and
@@ -327,7 +327,7 @@ .SS Deviations in the GNU C library
internally and were consequently not async-signal-safe.
.\" https://sourceware.org/bugzilla/show_bug.cgi?id=19534
This was fixed in glibc 2.24.
-.IP *
+.IP \(bu
.\" FIXME . https://sourceware.org/bugzilla/show_bug.cgi?id=13172
The glibc implementation of
.BR aio_suspend (3)
diff --git a/man7/signal.7 b/man7/signal.7
index 98e6e3520..0d5f21927 100644
--- a/man7/signal.7
+++ b/man7/signal.7
@@ -135,7 +135,7 @@ .SS Synchronously accepting a signal
at which point the kernel returns information about the
signal to the caller.
There are two general ways to do this:
-.IP * 2
+.IP \(bu 3
.BR sigwaitinfo (2),
.BR sigtimedwait (2),
and
@@ -143,7 +143,7 @@ .SS Synchronously accepting a signal
suspend execution until one of the signals in a specified
set is delivered.
Each of these calls returns information about the delivered signal.
-.IP *
+.IP \(bu
.BR signalfd (2)
returns a file descriptor that can be used to read information
about signals that are delivered to the caller.
@@ -244,13 +244,13 @@ .SS Execution of signal handlers
the kernel checks whether there is a pending unblocked signal
for which the process has established a signal handler.
If there is such a pending signal, the following steps occur:
-.IP 1. 3
+.IP (1) 5
The kernel performs the necessary preparatory steps for execution of
the signal handler:
.RS
-.IP a) 3
+.IP (1.1) 7
The signal is removed from the set of pending signals.
-.IP b)
+.IP (1.2)
If the signal handler was installed by a call to
.BR sigaction (2)
that specified the
@@ -258,21 +258,21 @@ .SS Execution of signal handlers
flag and the thread has defined an alternate signal stack (using
.BR sigaltstack (2)),
then that stack is installed.
-.IP c)
+.IP (1.3)
Various pieces of signal-related context are saved
into a special frame that is created on the stack.
The saved information includes:
.RS
-.IP + 2
+.IP \(bu 3
the program counter register
(i.e., the address of the next instruction in the main program that
should be executed when the signal handler returns);
-.IP +
+.IP \(bu
architecture-specific register state required for resuming the
interrupted program;
-.IP +
+.IP \(bu
the thread's current signal mask;
-.IP +
+.IP \(bu
the thread's alternate signal stack settings.
.RE
.IP
@@ -282,7 +282,7 @@ .SS Execution of signal handlers
flag, then the above information is accessible via the
.I ucontext_t
object that is pointed to by the third argument of the signal handler.)
-.IP d)
+.IP (1.4)
Any signals specified in
.I act\->sa_mask
when registering the handler with
@@ -294,19 +294,19 @@ .SS Execution of signal handlers
was specified when registering the handler.
These signals are thus blocked while the handler executes.
.RE
-.IP 2.
+.IP (2)
The kernel constructs a frame for the signal handler on the stack.
The kernel sets the program counter for the thread to point to the first
instruction of the signal handler function,
and configures the return address for that function to point to a piece
of user-space code known as the signal trampoline (described in
.BR sigreturn (2)).
-.IP 3.
+.IP (3)
The kernel passes control back to user-space, where execution
commences at the start of the signal handler function.
-.IP 4.
+.IP (4)
When the signal handler returns, control passes to the signal trampoline code.
-.IP 5.
+.IP (5)
The signal trampoline calls
.BR sigreturn (2),
a system call that uses the information in the stack frame created in step 1
@@ -511,7 +511,7 @@ .SS Signal numbering for standard signals
.TE
.PP
Note the following:
-.IP * 3
+.IP \(bu 3
Where defined,
.B SIGUNUSED
is synonymous with
@@ -519,7 +519,7 @@ .SS Signal numbering for standard signals
Since glibc 2.26,
.B SIGUNUSED
is no longer defined on any architecture.
-.IP *
+.IP \(bu
Signal 29 is
.BR SIGINFO / SIGPWR
(synonyms for the same value) on Alpha but
@@ -568,11 +568,11 @@ .SS Real-time signals
receiving process.
.PP
Real-time signals are distinguished by the following:
-.IP 1. 4
+.IP \(bu 3
Multiple instances of real-time signals can be queued.
By contrast, if multiple instances of a standard signal are delivered
while that signal is currently blocked, then only one instance is queued.
-.IP 2. 4
+.IP \(bu
If the signal is sent using
.BR sigqueue (3),
an accompanying value (either an integer or a pointer) can be sent
@@ -592,7 +592,7 @@ .SS Real-time signals
.I si_uid
fields of this structure can be used to obtain the PID
and real user ID of the process sending the signal.
-.IP 3. 4
+.IP \(bu
Real-time signals are delivered in a guaranteed order.
Multiple real-time signals of the same type are delivered in the order
they were sent.
@@ -652,9 +652,9 @@ .SS Real-time signals
.SS Interruption of system calls and library functions by signal handlers
If a signal handler is invoked while a system call or library
function call is blocked, then either:
-.IP * 2
+.IP \(bu 3
the call is automatically restarted after the signal handler returns; or
-.IP *
+.IP \(bu
the call fails with the error
.BR EINTR .
.PP
@@ -674,7 +674,7 @@ .SS Interruption of system calls and library functions by
signal handlers
.BR EINTR :
.\" The following system calls use ERESTARTSYS,
.\" so that they are restartable
-.IP * 2
+.IP \(bu 3
.BR read (2),
.BR readv (2),
.BR write (2),
@@ -690,18 +690,18 @@ .SS Interruption of system calls and library functions by
signal handlers
(normally, the number of bytes transferred).
Note that a (local) disk is not a slow device according to this definition;
I/O operations on disk devices are not interrupted by signals.
-.IP *
+.IP \(bu
.BR open (2),
if it can block (e.g., when opening a FIFO; see
.BR fifo (7)).
-.IP *
+.IP \(bu
.BR wait (2),
.BR wait3 (2),
.BR wait4 (2),
.BR waitid (2),
and
.BR waitpid (2).
-.IP *
+.IP \(bu
Socket interfaces:
.\" If a timeout (setsockopt()) is in effect on the socket, then these
.\" system calls switch to using EINTR. Consequently, they and are not
@@ -719,7 +719,7 @@ .SS Interruption of system calls and library functions by
signal handlers
.BR sendmsg (2),
.\" FIXME What about sendmmsg()?
unless a timeout has been set on the socket (see below).
-.IP *
+.IP \(bu
File locking interfaces:
.BR flock (2)
and
@@ -729,30 +729,30 @@ .SS Interruption of system calls and library functions by
signal handlers
.B F_OFD_SETLKW
operations of
.BR fcntl (2)
-.IP *
+.IP \(bu
POSIX message queue interfaces:
.BR mq_receive (3),
.BR mq_timedreceive (3),
.BR mq_send (3),
and
.BR mq_timedsend (3).
-.IP *
+.IP \(bu
.BR futex (2)
.B FUTEX_WAIT
(since Linux 2.6.22;
.\" commit 72c1bbf308c75a136803d2d76d0e18258be14c7a
beforehand, always failed with
.BR EINTR ).
-.IP *
+.IP \(bu
.BR getrandom (2).
-.IP *
+.IP \(bu
.BR pthread_mutex_lock (3),
.BR pthread_cond_wait (3),
and related APIs.
-.IP *
+.IP \(bu
.BR futex (2)
.BR FUTEX_WAIT_BITSET .
-.IP *
+.IP \(bu
POSIX semaphore interfaces:
.BR sem_wait (3)
and
@@ -761,7 +761,7 @@ .SS Interruption of system calls and library functions by
signal handlers
.\" as a consequence of the 2.6.22 changes in the futex() implementation
beforehand, always failed with
.BR EINTR ).
-.IP *
+.IP \(bu
.BR read (2)
from an
.BR inotify (7)
@@ -780,7 +780,7 @@ .SS Interruption of system calls and library functions by
signal handlers
when interrupted by a signal handler:
.\" These are the system calls that give EINTR or ERESTARTNOHAND
.\" on interruption by a signal handler.
-.IP * 2
+.IP \(bu 3
"Input" socket interfaces, when a timeout
.RB ( SO_RCVTIMEO )
has been set on the socket using
@@ -794,7 +794,7 @@ .SS Interruption of system calls and library functions by
signal handlers
argument),
and
.BR recvmsg (2).
-.IP *
+.IP \(bu
"Output" socket interfaces, when a timeout
.RB ( SO_RCVTIMEO )
has been set on the socket using
@@ -805,14 +805,14 @@ .SS Interruption of system calls and library functions by
signal handlers
and
.BR sendmsg (2).
.\" FIXME What about sendmmsg()?
-.IP *
+.IP \(bu
Interfaces used to wait for signals:
.BR pause (2),
.BR sigsuspend (2),
.BR sigtimedwait (2),
and
.BR sigwaitinfo (2).
-.IP *
+.IP \(bu
File descriptor multiplexing interfaces:
.BR epoll_wait (2),
.BR epoll_pwait (2),
@@ -821,7 +821,7 @@ .SS Interruption of system calls and library functions by
signal handlers
.BR select (2),
and
.BR pselect (2).
-.IP *
+.IP \(bu
System V IPC interfaces:
.\" On some other systems, SA_RESTART does restart these system calls
.BR msgrcv (2),
@@ -829,13 +829,13 @@ .SS Interruption of system calls and library functions by
signal handlers
.BR semop (2),
and
.BR semtimedop (2).
-.IP *
+.IP \(bu
Sleep interfaces:
.BR clock_nanosleep (2),
.BR nanosleep (2),
and
.BR usleep (3).
-.IP *
+.IP \(bu
.BR io_getevents (2).
.PP
The
@@ -862,7 +862,7 @@ .SS Interruption of system calls and library functions by
stop signals
on other systems.
.PP
The Linux interfaces that display this behavior are:
-.IP * 2
+.IP \(bu 3
"Input" socket interfaces, when a timeout
.RB ( SO_RCVTIMEO )
has been set on the socket using
@@ -876,7 +876,7 @@ .SS Interruption of system calls and library functions by
stop signals
argument),
and
.BR recvmsg (2).
-.IP *
+.IP \(bu
"Output" socket interfaces, when a timeout
.RB ( SO_RCVTIMEO )
has been set on the socket using
@@ -890,33 +890,33 @@ .SS Interruption of system calls and library functions by
stop signals
if a send timeout
.RB ( SO_SNDTIMEO )
has been set.
-.IP * 2
+.IP \(bu
.BR epoll_wait (2),
.BR epoll_pwait (2).
-.IP *
+.IP \(bu
.BR semop (2),
.BR semtimedop (2).
-.IP *
+.IP \(bu
.BR sigtimedwait (2),
.BR sigwaitinfo (2).
-.IP *
+.IP \(bu
Linux 3.7 and earlier:
.BR read (2)
from an
.BR inotify (7)
file descriptor
.\" commit 1ca39ab9d21ac93f94b9e3eb364ea9a5cf2aba06
-.IP *
+.IP \(bu
Linux 2.6.21 and earlier:
.BR futex (2)
.BR FUTEX_WAIT ,
.BR sem_timedwait (3),
.BR sem_wait (3).
-.IP *
+.IP \(bu
Linux 2.6.8 and earlier:
.BR msgrcv (2),
.BR msgsnd (2).
-.IP *
+.IP \(bu
Linux 2.4 and earlier:
.BR nanosleep (2).
.SH STANDARDS
diff --git a/man7/symlink.7 b/man7/symlink.7
index f8147a6ed..01eb17cfb 100644
--- a/man7/symlink.7
+++ b/man7/symlink.7
@@ -168,12 +168,12 @@ .SS Handling of symbolic links by system calls and
commands
.PP
There are three separate areas that need to be discussed.
They are as follows:
-.IP 1. 3
+.IP \(bu 3
Symbolic links used as filename arguments for system calls.
-.IP 2.
+.IP \(bu
Symbolic links specified as command-line arguments to utilities that
are not traversing a file tree.
-.IP 3.
+.IP \(bu
Symbolic links encountered by utilities that are traversing a file tree
(either specified on the command line or encountered as part of the
file hierarchy walk).
@@ -198,7 +198,7 @@ .SS Treatment of symbolic links in system calls
.PP
The treatment of symbolic links within a pathname passed to
a system call is as follows:
-.IP 1. 3
+.IP (1) 5
Within the dirname component of a pathname,
symbolic links are always followed in nearly every system call.
(This is also true for commands.)
@@ -206,7 +206,7 @@ .SS Treatment of symbolic links in system calls
.BR openat2 (2),
which provides flags that can be used to explicitly
prevent following of symbolic links in the dirname component.
-.IP 2.
+.IP (2)
Except as noted below,
all system calls follow symbolic links
in the basename component of a pathname.
@@ -315,7 +315,7 @@ .SS Commands not traversing a file tree
itself.
.PP
There are some exceptions to this rule:
-.IP * 2
+.IP \(bu 3
The
.BR mv (1)
and
@@ -325,7 +325,7 @@ .SS Commands not traversing a file tree
(Note, if the symbolic link references a file via a relative path,
moving it to another directory may very well cause it to stop working,
since the path may no longer be correct.)
-.IP *
+.IP \(bu
The
.BR ls (1)
command is also an exception to this rule.
@@ -355,7 +355,7 @@ .SS Commands not traversing a file tree
.I \-L
options affect its behavior even though it is not doing a walk of
a file tree.)
-.IP *
+.IP \(bu
The
.BR file (1)
command is also an exception to this rule.
@@ -415,7 +415,7 @@ .SS Commands traversing a file tree
.PP
Certain conventions are (should be) followed as consistently as
possible by commands that perform file tree walks:
-.IP * 2
+.IP \(bu 3
A command can be made to follow
any symbolic links named on the command line,
regardless of the type of file they reference, by specifying the
@@ -444,7 +444,7 @@ .SS Commands traversing a file tree
dereferenced for the purposes of both the action to be performed
and the tree walk, and it is as if the user had specified the
name of the file to which the symbolic link pointed.
-.IP *
+.IP \(bu
A command can be made to
follow any symbolic links named on the command line,
as well as any symbolic links encountered during the traversal,
@@ -473,7 +473,7 @@ .SS Commands traversing a file tree
.B chown
traverses, they will be treated in the same fashion as
.IR slink .
-.IP *
+.IP \(bu
A command can be made to
provide the default behavior by specifying the
.I \-P
@@ -504,7 +504,7 @@ .SS Commands traversing a file tree
and
.BR rm (1)
commands have exceptions to these rules:
-.IP * 2
+.IP \(bu 3
The
.BR rm (1)
command operates on the symbolic link, and not the file it references,
@@ -517,7 +517,7 @@ .SS Commands traversing a file tree
or
.I \-P
options.
-.IP *
+.IP \(bu
To maintain compatibility with historic systems,
the
.BR ls (1)
diff --git a/man7/time_namespaces.7 b/man7/time_namespaces.7
index 7271b17af..a3032aac3 100644
--- a/man7/time_namespaces.7
+++ b/man7/time_namespaces.7
@@ -8,7 +8,7 @@ .SH NAME
time_namespaces \- overview of Linux time namespaces
.SH DESCRIPTION
Time namespaces virtualize the values of two system clocks:
-.IP \(bu 2
+.IP \(bu 3
.B CLOCK_MONOTONIC
(and likewise
.B CLOCK_MONOTONIC_COARSE
@@ -147,7 +147,7 @@ .SS /proc/PID/timens_offsets
value is out of range.
In particular;
.RS
-.IP \(bu 2
+.IP \(bu 3
.I offset-secs
can't be set to a value which would make the current
time on the corresponding clock inside the namespace a negative value; and
diff --git a/man7/unicode.7 b/man7/unicode.7
index 86be576fb..825b47042 100644
--- a/man7/unicode.7
+++ b/man7/unicode.7
@@ -195,7 +195,7 @@ .SS Private Use Areas (PUA)
and plane 16 (Supplementary Private Use Area-B, range
0x100000 to 0x10fffd).
.SS Literature
-.IP * 3
+.IP \(bu 3
Information technology \(em Universal Multiple-Octet Coded Character
Set (UCS) \(em Part 1: Architecture and Basic Multilingual Plane.
International Standard ISO/IEC 10646-1, International Organization
@@ -205,11 +205,11 @@ .SS Literature
Available from
.UR http://www.iso.ch/
.UE .
-.IP *
+.IP \(bu
The Unicode Standard, Version 3.0.
The Unicode Consortium, Addison-Wesley,
Reading, MA, 2000, ISBN 0-201-61633-5.
-.IP *
+.IP \(bu
S.\& Harbison, G.\& Steele. C: A Reference Manual. Fourth edition,
Prentice Hall, Englewood Cliffs, 1995, ISBN 0-13-326224-3.
.IP
@@ -219,19 +219,19 @@ .SS Literature
adds a large number of new C library functions for handling wide and
multibyte character encodings, but it does not yet cover ISO C99,
which improved wide and multibyte character support even further.
-.IP *
+.IP \(bu
Unicode Technical Reports.
.RS
.UR http://www.unicode.org\:/reports/
.UE
.RE
-.IP *
+.IP \(bu
Markus Kuhn: UTF-8 and Unicode FAQ for UNIX/Linux.
.RS
.UR http://www.cl.cam.ac.uk\:/\(timgk25\:/unicode.html
.UE
.RE
-.IP *
+.IP \(bu
Bruno Haible: Unicode HOWTO.
.RS
.UR http://www.tldp.org\:/HOWTO\:/Unicode\-HOWTO.html
diff --git a/man7/unix.7 b/man7/unix.7
index 113fef949..f11a70ebc 100644
--- a/man7/unix.7
+++ b/man7/unix.7
@@ -166,15 +166,15 @@ .SS Address format
.SS Pathname sockets
When binding a socket to a pathname, a few rules should be observed
for maximum portability and ease of coding:
-.IP * 3
+.IP \(bu 3
The pathname in
.I sun_path
should be null-terminated.
-.IP *
+.IP \(bu
The length of the pathname, including the terminating null byte,
should not exceed the size of
.IR sun_path .
-.IP *
+.IP \(bu
The
.I addrlen
argument that describes the enclosing
@@ -598,13 +598,13 @@ .SS Ancillary messages
.PP
.RS
.PD 0
-.IP 1. 3
+.IP (1) 5
.BR sendmsg (2)
of four bytes, with no ancillary data.
-.IP 2.
+.IP (2)
.BR sendmsg (2)
of one byte, with ancillary data.
-.IP 3.
+.IP (3)
.BR sendmsg (2)
of four bytes, with no ancillary data.
.PD
diff --git a/man7/uri.7 b/man7/uri.7
index dd9be43cd..22d4227a7 100644
--- a/man7/uri.7
+++ b/man7/uri.7
@@ -522,11 +522,11 @@ .SS Character encoding
the HTML 4.01 specification (section B.2) and
IETF RFC\~3986 (last paragraph of section 2.5)
recommend the following approach:
-.IP 1. 4
+.IP (1) 5
translate the character sequences into UTF-8 (IETF RFC\~3629)\(emsee
.BR utf\-8 (7)\(emand
then
-.IP 2.
+.IP (2)
use the URI escaping mechanism, that is,
use the %HH encoding for unsafe octets.
.SS Writing a URI
diff --git a/man7/user_namespaces.7 b/man7/user_namespaces.7
index d5dba8fca..02d3ee01c 100644
--- a/man7/user_namespaces.7
+++ b/man7/user_namespaces.7
@@ -157,7 +157,7 @@ .SS Capabilities
.PP
The rules for determining whether or not a process has a capability
in a particular user namespace are as follows:
-.IP 1. 3
+.IP \(bu 3
A process has a capability inside a user namespace
if it is a member of that namespace and
it has the capability in its effective capability set.
@@ -173,11 +173,11 @@ .SS Capabilities
.BR setns (2),
as already described.
.\" In the 3.8 sources, see security/commoncap.c::cap_capable():
-.IP 2.
+.IP \(bu
If a process has a capability in a user namespace,
then it has that capability in all child (and further removed descendant)
namespaces as well.
-.IP 3.
+.IP \(bu
.\" * The owner of the user namespace in the parent of the
.\" * user namespace has all caps.
When a user namespace is created, the kernel records the effective
@@ -234,29 +234,29 @@ .SS Effect of capabilities within a user namespace
.PP
.RS 4
.PD 0
-.IP * 2
+.IP \(bu 3
.I /proc
(since Linux 3.8)
-.IP *
+.IP \(bu
.I /sys
(since Linux 3.8)
-.IP *
+.IP \(bu
.I devpts
(since Linux 3.9)
-.IP *
+.IP \(bu
.BR tmpfs (5)
(since Linux 3.9)
-.IP *
+.IP \(bu
.I ramfs
(since Linux 3.9)
-.IP *
+.IP \(bu
.I mqueue
(since Linux 3.9)
-.IP *
+.IP \(bu
.I bpf
.\" commit b2197755b2633e164a439682fb05a9b5ea48f706
(since Linux 4.4)
-.IP *
+.IP \(bu
.I overlayfs
.\" commit 92dbc9dedccb9759c7f9f2f0ae6242396376988f
.\" commit 4cb2c00c43b3fe88b32f29df4f76da1b92c33224
@@ -397,7 +397,7 @@ .SS User and group ID mappings: uid_map and gid_map
each of the two user namespaces.
The third number specifies the length of the mapped range.
In detail, the fields are interpreted as follows:
-.IP (1) 4
+.IP (1) 5
The start of the range of user IDs in
the user namespace of the process
.IR pid .
@@ -410,12 +410,12 @@ .SS User and group ID mappings: uid_map and gid_map
.I pid
are in the same user namespace, as follows:
.RS
-.IP a) 3
+.IP (a) 5
If the two processes are in different user namespaces:
field two is the start of a range of
user IDs in the user namespace of the process that opened
.IR uid_map .
-.IP b)
+.IP (b)
If the two processes are in the same user namespace:
field two is the start of the range of
user IDs in the parent user namespace of the process
@@ -499,12 +499,12 @@ .SS Defining user and group ID mappings: writing to
uid_map and gid_map
.I uid_map
.RI ( gid_map )
must conform to the following validity rules:
-.IP * 3
+.IP \(bu 3
The three fields must be valid numbers,
and the last field must be greater than 0.
-.IP *
+.IP \(bu
Lines are terminated by newline characters.
-.IP *
+.IP \(bu
There is a limit on the number of lines in the file.
In Linux 4.14 and earlier, this limit was (arbitrarily)
.\" 5*12-byte records could fit in a 64B cache line
@@ -519,7 +519,7 @@ .SS Defining user and group ID mappings: writing to uid_map
and gid_map
and
.BR pwrite (2)
can't be used to write to nonzero offsets in the file).
-.IP *
+.IP \(bu
The range of user IDs (group IDs)
specified in each line cannot overlap with the ranges
in any other lines.
@@ -532,7 +532,7 @@ .SS Defining user and group ID mappings: writing to uid_map
and gid_map
Linux 3.9 and later
.\" commit 0bd14b4fd72afd5df41e9fd59f356740f22fceba
fix this limitation, allowing any valid set of nonoverlapping maps.
-.IP *
+.IP \(bu
At least one line must be written to the file.
.PP
Writes that violate the above rules fail with the error
@@ -542,32 +542,32 @@ .SS Defining user and group ID mappings: writing to
uid_map and gid_map
.IR /proc/ pid /uid_map
.RI ( /proc/ pid /gid_map )
file, all of the following permission requirements must be met:
-.IP 1. 3
+.IP \(bu 3
The writing process must have the
.B CAP_SETUID
.RB ( CAP_SETGID )
capability in the user namespace of the process
.IR pid .
-.IP 2.
+.IP \(bu
The writing process must either be in the user namespace of the process
.I pid
or be in the parent user namespace of the process
.IR pid .
-.IP 3.
+.IP \(bu
The mapped user IDs (group IDs) must in turn have a mapping
in the parent user namespace.
-.IP 4.
+.IP \(bu
If updating
.IR /proc/ pid /uid_map
to create a mapping that maps UID 0 in the parent namespace,
then one of the following must be true:
.RS
-.IP * 3
+.IP (a) 5
if writing process is in the parent user namespace,
then it must have the
.B CAP_SETFCAP
capability in that user namespace; or
-.IP *
+.IP (b)
if the writing process is in the child user namespace,
then the process that created the user namespace must have had the
.B CAP_SETFCAP
@@ -587,21 +587,21 @@ .SS Defining user and group ID mappings: writing to
uid_map and gid_map
could nevertheless create such a binary,
by the following steps:
.RS
-.IP * 3
+.IP (1) 5
Create a new user namespace with the identity mapping
(i.e., UID 0 in the new user namespace maps to UID 0 in the parent namespace),
so that UID 0 in both namespaces is equivalent to the same root user ID.
-.IP *
+.IP (2)
Since the child process has the
.B CAP_SETFCAP
capability, it could create a binary with namespaced file capabilities
that would then be effective in the parent user namespace
(because the root user IDs are the same in the two namespaces).
.RE
-.IP 5.
+.IP \(bu
One of the following two cases applies:
.RS
-.IP * 3
+.IP (a) 5
.I Either
the writing process has the
.B CAP_SETUID
@@ -610,16 +610,16 @@ .SS Defining user and group ID mappings: writing to
uid_map and gid_map
.I parent
user namespace.
.RS
-.IP + 3
+.IP \(bu 3
No further restrictions apply:
the process can make mappings to arbitrary user IDs (group IDs)
in the parent user namespace.
.RE
-.IP * 3
+.IP (b)
.I Or
otherwise all of the following restrictions apply:
.RS
-.IP + 3
+.IP \(bu 3
The data written to
.I uid_map
.RI ( gid_map )
@@ -627,10 +627,10 @@ .SS Defining user and group ID mappings: writing to
uid_map and gid_map
the writing process's effective user ID
(group ID) in the parent user namespace to a user ID (group ID)
in the user namespace.
-.IP +
+.IP \(bu
The writing process must have the same effective user ID as the process
that created the user namespace.
-.IP +
+.IP \(bu
In the case of
.IR gid_map ,
use of the
@@ -675,12 +675,12 @@ .SS Project ID mappings: projid_map
The permission rules for writing to the
.IR /proc/ pid /projid_map
file are as follows:
-.IP 1. 3
+.IP \(bu 3
The writing process must either be in the user namespace of the process
.I pid
or be in the parent user namespace of the process
.IR pid .
-.IP 2.
+.IP \(bu
The mapped project IDs must in turn have a mapping
in the parent user namespace.
.PP
@@ -965,9 +965,9 @@ .SS Operation of file-related capabilities
these capabilities allow a process to bypass the rules
if the process has the relevant capability over the file,
meaning that:
-.IP * 3
+.IP \(bu 3
the process has the relevant effective capability in its user namespace; and
-.IP *
+.IP \(bu
the file's user ID and group ID both have valid mappings
in the user namespace.
.PP
diff --git a/man8/ld.so.8 b/man8/ld.so.8
index bcdb2f0ab..5f790323d 100644
--- a/man8/ld.so.8
+++ b/man8/ld.so.8
@@ -57,17 +57,17 @@ .SH DESCRIPTION
.PP
If a shared object dependency does not contain a slash,
then it is searched for in the following order:
-.IP o 3
+.IP (1) 5
Using the directories specified in the
DT_RPATH dynamic section attribute
of the binary if present and DT_RUNPATH attribute does not exist.
Use of DT_RPATH is deprecated.
-.IP o
+.IP (2)
Using the environment variable
.BR LD_LIBRARY_PATH ,
unless the executable is being run in secure-execution mode (see below),
in which case this variable is ignored.
-.IP o
+.IP (3)
Using the directories specified in the
DT_RUNPATH dynamic section attribute
of the binary if present.
@@ -77,7 +77,7 @@ .SH DESCRIPTION
which must themselves have their own DT_RUNPATH entries.
This is unlike DT_RPATH, which is applied
to searches for all children in the dependency tree.
-.IP o
+.IP (4)
From the cache file
.IR /etc/ld.so.cache ,
which contains a compiled list of candidate shared objects previously found
@@ -87,7 +87,7 @@ .SH DESCRIPTION
linker option, shared objects in the default paths are skipped.
Shared objects installed in hardware capability directories (see below)
are preferred to other shared objects.
-.IP o
+.IP (5)
In the default path
.IR /lib ,
and then
@@ -102,13 +102,13 @@ .SH DESCRIPTION
.\"
.SS Dynamic string tokens
In several places, the dynamic linker expands dynamic string tokens:
-.IP o 3
+.IP \(bu 3
In the environment variables
.BR LD_LIBRARY_PATH ,
.BR LD_PRELOAD ,
and
.BR LD_AUDIT ,
-.IP o 3
+.IP \(bu
inside the values of the dynamic section tags
.BR DT_NEEDED ,
.BR DT_RPATH ,
@@ -117,7 +117,7 @@ .SS Dynamic string tokens
and
.B DT_DEPAUDIT
of ELF binaries,
-.IP o 3
+.IP \(bu
in the arguments to the
.B ld.so
command line options
@@ -126,7 +126,7 @@ .SS Dynamic string tokens
and
.B \-\-preload
(see below), and
-.IP o 3
+.IP \(bu
in the filename arguments to the
.BR dlopen (3)
and
@@ -296,15 +296,15 @@ .SS Secure-execution mode
.BR getauxval (3))
has a nonzero value.
This entry may have a nonzero value for various reasons, including:
-.IP * 3
+.IP \(bu 3
The process's real and effective user IDs differ,
or the real and effective group IDs differ.
This typically occurs as a result of executing
a set-user-ID or set-group-ID program.
-.IP *
+.IP \(bu
A process with a non-root user ID executed a binary that
conferred capabilities to the process.
-.IP *
+.IP \(bu
A nonzero value may have been set by a Linux Security Module.
.\"
.SS Environment variables
@@ -438,7 +438,7 @@ .SS Environment variables
There are various methods of specifying libraries to be preloaded,
and these are handled in the following order:
.RS
-.IP (1) 4
+.IP (1) 5
The
.B LD_PRELOAD
environment variable.
--
2.37.2
- [RFC] Various pages: Use consistent style for lists (.IP),
Alejandro Colomar <=