2020-11-05 06:48:40

by Stephen Rothwell

[permalink] [raw]
Subject: linux-next: build warning after merge of the akpm-current tree

Hi all,

After merging the akpm-current tree, today's linux-next build (htmldocs)
produced this warning:

Documentation/filesystems/proc.rst:296: WARNING: Malformed table.
Text in column margin in table line 61.

========================== ===================================================
Field Content
========================== ===================================================
Name filename of the executable
Umask file mode creation mask
State state (R is running, S is sleeping, D is sleeping
in an uninterruptible wait, Z is zombie,
T is traced or stopped)
Tgid thread group ID
Ngid NUMA group ID (0 if none)
Pid process id
PPid process id of the parent process
TracerPid PID of process tracing this process (0 if not)
Uid Real, effective, saved set, and file system UIDs
Gid Real, effective, saved set, and file system GIDs
FDSize number of file descriptor slots currently allocated
Groups supplementary group list
NStgid descendant namespace thread group ID hierarchy
NSpid descendant namespace process ID hierarchy
NSpgid descendant namespace process group ID hierarchy
NSsid descendant namespace session ID hierarchy
VmPeak peak virtual memory size
VmSize total program size
VmLck locked memory size
VmPin pinned memory size
VmHWM peak resident set size ("high water mark")
VmRSS size of memory portions. It contains the three
following parts
(VmRSS = RssAnon + RssFile + RssShmem)
RssAnon size of resident anonymous memory
RssFile size of resident file mappings
RssShmem size of resident shmem memory (includes SysV shm,
mapping of tmpfs and shared anonymous mappings)
VmData size of private data segments
VmStk size of stack segments
VmExe size of text segment
VmLib size of shared library code
VmPTE size of page table entries
VmSwap amount of swap used by anonymous private data
(shmem swap usage is not included)
HugetlbPages size of hugetlb memory portions
CoreDumping process's memory is currently being dumped
(killing the process may lead to a corrupted core)
THP_enabled process is allowed to use THP (returns 0 when
PR_SET_THP_DISABLE is set on the process
Threads number of threads
SigQ number of signals queued/max. number for queue
SigPnd bitmap of pending signals for the thread
ShdPnd bitmap of shared pending signals for the process
SigBlk bitmap of blocked signals
SigIgn bitmap of ignored signals
SigCgt bitmap of caught signals
CapInh bitmap of inheritable capabilities
CapPrm bitmap of permitted capabilities
CapEff bitmap of effective capabilities
CapBnd bitmap of capabilities bounding set
CapAmb bitmap of ambient capabilities
NoNewPrivs no_new_privs, like prctl(PR_GET_NO_NEW_PRIV, ...)
Seccomp seccomp mode, like prctl(PR_GET_SECCOMP, ...)
Speculation_Store_Bypass speculative store bypass mitigation status
Speculation_Indirect_Branch indirect branch speculation mode
Cpus_allowed mask of CPUs on which this process may run
Cpus_allowed_list Same as previous, but in "list format"
Mems_allowed mask of memory nodes allowed to this process
Mems_allowed_list Same as previous, but in "list format"
voluntary_ctxt_switches number of voluntary context switches
nonvoluntary_ctxt_switches number of non voluntary context switches
========================== ===================================================
Documentation/filesystems/proc.rst:234: WARNING: Error parsing content block for the "table" directive: exactly one table expected.

.. table:: Table 1-2: Contents of the status files (as of 4.19)

========================== ===================================================
Field Content
========================== ===================================================
Name filename of the executable
Umask file mode creation mask
State state (R is running, S is sleeping, D is sleeping
in an uninterruptible wait, Z is zombie,
T is traced or stopped)
Tgid thread group ID
Ngid NUMA group ID (0 if none)
Pid process id
PPid process id of the parent process
TracerPid PID of process tracing this process (0 if not)
Uid Real, effective, saved set, and file system UIDs
Gid Real, effective, saved set, and file system GIDs
FDSize number of file descriptor slots currently allocated
Groups supplementary group list
NStgid descendant namespace thread group ID hierarchy
NSpid descendant namespace process ID hierarchy
NSpgid descendant namespace process group ID hierarchy
NSsid descendant namespace session ID hierarchy
VmPeak peak virtual memory size
VmSize total program size
VmLck locked memory size
VmPin pinned memory size
VmHWM peak resident set size ("high water mark")
VmRSS size of memory portions. It contains the three
following parts
(VmRSS = RssAnon + RssFile + RssShmem)
RssAnon size of resident anonymous memory
RssFile size of resident file mappings
RssShmem size of resident shmem memory (includes SysV shm,
mapping of tmpfs and shared anonymous mappings)
VmData size of private data segments
VmStk size of stack segments
VmExe size of text segment
VmLib size of shared library code
VmPTE size of page table entries
VmSwap amount of swap used by anonymous private data
(shmem swap usage is not included)
HugetlbPages size of hugetlb memory portions
CoreDumping process's memory is currently being dumped
(killing the process may lead to a corrupted core)
THP_enabled process is allowed to use THP (returns 0 when
PR_SET_THP_DISABLE is set on the process
Threads number of threads
SigQ number of signals queued/max. number for queue
SigPnd bitmap of pending signals for the thread
ShdPnd bitmap of shared pending signals for the process
SigBlk bitmap of blocked signals
SigIgn bitmap of ignored signals
SigCgt bitmap of caught signals
CapInh bitmap of inheritable capabilities
CapPrm bitmap of permitted capabilities
CapEff bitmap of effective capabilities
CapBnd bitmap of capabilities bounding set
CapAmb bitmap of ambient capabilities
NoNewPrivs no_new_privs, like prctl(PR_GET_NO_NEW_PRIV, ...)
Seccomp seccomp mode, like prctl(PR_GET_SECCOMP, ...)
Speculation_Store_Bypass speculative store bypass mitigation status
Speculation_Indirect_Branch indirect branch speculation mode
Cpus_allowed mask of CPUs on which this process may run
Cpus_allowed_list Same as previous, but in "list format"
Mems_allowed mask of memory nodes allowed to this process
Mems_allowed_list Same as previous, but in "list format"
voluntary_ctxt_switches number of voluntary context switches
nonvoluntary_ctxt_switches number of non voluntary context switches
========================== ===================================================

Introduced by commit

60b492d745d5 ("proc: provide details on indirect branch speculation")

--
Cheers,
Stephen Rothwell


Attachments:
(No filename) (499.00 B)
OpenPGP digital signature

2020-11-05 07:08:25

by Mike Rapoport

[permalink] [raw]
Subject: Re: linux-next: build warning after merge of the akpm-current tree

On Thu, Nov 05, 2020 at 05:45:49PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (htmldocs)
> produced this warning:
>
> Documentation/filesystems/proc.rst:296: WARNING: Malformed table.
> Text in column margin in table line 61.
>
> ========================== ===================================================
> Field Content
> ========================== ===================================================
...
> Speculation_Store_Bypass speculative store bypass mitigation status
> Speculation_Indirect_Branch indirect branch speculation mode
...
> ========================== ===================================================
> Documentation/filesystems/proc.rst:234: WARNING: Error parsing content block for the "table" directive: exactly one table expected.

Looks like left column became too wide, so rather than shift the right
column to the right, I'd suggest to drop underscores in Speculation*.

>
> .. table:: Table 1-2: Contents of the status files (as of 4.19)
>
> ========================== ===================================================
> Field Content
> ========================== ===================================================
...
> Speculation_Store_Bypass speculative store bypass mitigation status
> Speculation_Indirect_Branch indirect branch speculation mode
> Cpus_allowed mask of CPUs on which this process may run
> Cpus_allowed_list Same as previous, but in "list format"
> Mems_allowed mask of memory nodes allowed to this process
> Mems_allowed_list Same as previous, but in "list format"
> voluntary_ctxt_switches number of voluntary context switches
> nonvoluntary_ctxt_switches number of non voluntary context switches
> ========================== ===================================================

Same here.

> Introduced by commit
>
> 60b492d745d5 ("proc: provide details on indirect branch speculation")
>
> --
> Cheers,
> Stephen Rothwell



--
Sincerely yours,
Mike.

2020-11-05 07:44:38

by Anand K. Mistry

[permalink] [raw]
Subject: Re: linux-next: build warning after merge of the akpm-current tree

On Thu, 5 Nov 2020 at 18:03, Mike Rapoport <[email protected]> wrote:
>
> On Thu, Nov 05, 2020 at 05:45:49PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the akpm-current tree, today's linux-next build (htmldocs)
> > produced this warning:
> >
> > Documentation/filesystems/proc.rst:296: WARNING: Malformed table.
> > Text in column margin in table line 61.
> >
> > ========================== ===================================================
> > Field Content
> > ========================== ===================================================
> ...
> > Speculation_Store_Bypass speculative store bypass mitigation status
> > Speculation_Indirect_Branch indirect branch speculation mode
> ...
> > ========================== ===================================================
> > Documentation/filesystems/proc.rst:234: WARNING: Error parsing content block for the "table" directive: exactly one table expected.
>
> Looks like left column became too wide, so rather than shift the right
> column to the right, I'd suggest to drop underscores in Speculation*.

Hm. That makes it inconsistent with Speculation_Store_Bypass. I guess
it's the lesser of two evils.

How would I go about fixing this? Send a new (v2), fixed patch to the
mailing list? I'm not that familiar with how patches get merged
through the branches.

>
> >
> > .. table:: Table 1-2: Contents of the status files (as of 4.19)
> >
> > ========================== ===================================================
> > Field Content
> > ========================== ===================================================
> ...
> > Speculation_Store_Bypass speculative store bypass mitigation status
> > Speculation_Indirect_Branch indirect branch speculation mode
> > Cpus_allowed mask of CPUs on which this process may run
> > Cpus_allowed_list Same as previous, but in "list format"
> > Mems_allowed mask of memory nodes allowed to this process
> > Mems_allowed_list Same as previous, but in "list format"
> > voluntary_ctxt_switches number of voluntary context switches
> > nonvoluntary_ctxt_switches number of non voluntary context switches
> > ========================== ===================================================
>
> Same here.
>
> > Introduced by commit
> >
> > 60b492d745d5 ("proc: provide details on indirect branch speculation")
> >
> > --
> > Cheers,
> > Stephen Rothwell
>
>
>
> --
> Sincerely yours,
> Mike.



--
Anand K. Mistry
Software Engineer
Google Australia

2020-11-05 07:49:05

by Anand K. Mistry

[permalink] [raw]
Subject: Re: linux-next: build warning after merge of the akpm-current tree

SNIPPED

> >
> > Looks like left column became too wide, so rather than shift the right
> > column to the right, I'd suggest to drop underscores in Speculation*.
>
> Hm. That makes it inconsistent with Speculation_Store_Bypass. I guess
> it's the lesser of two evils.

Oh, do you mean renaming the existing Speculation_Store_Bypass? I
thought that was a big no-no for the kernel?

2020-11-05 08:01:57

by Stephen Rothwell

[permalink] [raw]
Subject: Re: linux-next: build warning after merge of the akpm-current tree

Hi Anand,

On Thu, 5 Nov 2020 18:42:23 +1100 "Anand K. Mistry" <[email protected]> wrote:
>
> How would I go about fixing this? Send a new (v2), fixed patch to the
> mailing list? I'm not that familiar with how patches get merged
> through the branches.

Since this is in Andrew's quilt series, either a v2, or an incremental
patch (to wherever the original went - including cc'ing Andrew). If
you send a v2, he will probably turn it into an incremental patch and
then squash it back before sending it to Linus.

--
Cheers,
Stephen Rothwell


Attachments:
(No filename) (499.00 B)
OpenPGP digital signature

2020-11-05 08:06:01

by Stephen Rothwell

[permalink] [raw]
Subject: Re: linux-next: build warning after merge of the akpm-current tree

Hi Anand,

On Thu, 5 Nov 2020 19:00:11 +1100 Stephen Rothwell <[email protected]> wrote:
>
> On Thu, 5 Nov 2020 18:42:23 +1100 "Anand K. Mistry" <[email protected]> wrote:
> >
> > How would I go about fixing this? Send a new (v2), fixed patch to the
> > mailing list? I'm not that familiar with how patches get merged
> > through the branches.
>
> Since this is in Andrew's quilt series, either a v2, or an incremental
> patch (to wherever the original went - including cc'ing Andrew). If
> you send a v2, he will probably turn it into an incremental patch and
> then squash it back before sending it to Linus.

And if you cc me as well, I will add it to the copy of Andrew's series
that I have in linux-next (so I won't have to worry about the warning
until Andrew gets around to sending out a new version of his quilt
series).
--
Cheers,
Stephen Rothwell


Attachments:
(No filename) (499.00 B)
OpenPGP digital signature

2020-11-05 09:19:21

by Mike Rapoport

[permalink] [raw]
Subject: Re: linux-next: build warning after merge of the akpm-current tree

On Thu, Nov 05, 2020 at 06:45:04PM +1100, Anand K. Mistry wrote:
> SNIPPED
>
> > >
> > > Looks like left column became too wide, so rather than shift the right
> > > column to the right, I'd suggest to drop underscores in Speculation*.
> >
> > Hm. That makes it inconsistent with Speculation_Store_Bypass. I guess
> > it's the lesser of two evils.
>
> Oh, do you mean renaming the existing Speculation_Store_Bypass? I
> thought that was a big no-no for the kernel?

Right, renaming is not an option :)

I thought Speculation_Store_Bypass was also introduced by the same
patch, sorry about the confusion.

--
Sincerely yours,
Mike.