All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Jonathan Corbet <corbet@lwn.net>, Will Deacon <will@kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Daniel Kiss <daniel.kiss@arm.com>,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Subject: Re: linux-next: manual merge of the jc_docs tree with the arm64 tree
Date: Wed, 18 Mar 2020 08:49:15 +0000	[thread overview]
Message-ID: <20200318084915.GO3005@mbp> (raw)
In-Reply-To: <20200318124033.6c523374@canb.auug.org.au>

On Wed, Mar 18, 2020 at 12:40:33PM +1100, Stephen Rothwell wrote:
> diff --cc Documentation/filesystems/proc.rst
> index ed5465d0f435,38b606991065..000000000000
> --- a/Documentation/filesystems/proc.rst
> +++ b/Documentation/filesystems/proc.rst
> @@@ -489,37 -511,39 +511,40 @@@ does not take into account swapped out 
>   "THPeligible" indicates whether the mapping is eligible for allocating THP
>   pages - 1 if true, 0 otherwise. It just shows the current status.
>   
> - "VmFlags" field deserves a separate description. This member represents the kernel
> - flags associated with the particular virtual memory area in two letter encoded
> - manner. The codes are the following:
> -     rd  - readable
> -     wr  - writeable
> -     ex  - executable
> -     sh  - shared
> -     mr  - may read
> -     mw  - may write
> -     me  - may execute
> -     ms  - may share
> -     gd  - stack segment growns down
> -     pf  - pure PFN range
> -     dw  - disabled write to the mapped file
> -     lo  - pages are locked in memory
> -     io  - memory mapped I/O area
> -     sr  - sequential read advise provided
> -     rr  - random read advise provided
> -     dc  - do not copy area on fork
> -     de  - do not expand area on remapping
> -     ac  - area is accountable
> -     nr  - swap space is not reserved for the area
> -     ht  - area uses huge tlb pages
> -     ar  - architecture specific flag
> -     dd  - do not include area into core dump
> -     sd  - soft-dirty flag
> -     mm  - mixed map area
> -     hg  - huge page advise flag
> -     nh  - no-huge page advise flag
> -     mg  - mergable advise flag
> + "VmFlags" field deserves a separate description. This member represents the
> + kernel flags associated with the particular virtual memory area in two letter
> + encoded manner. The codes are the following:
> + 
> +     ==    =======================================
> +     rd    readable
> +     wr    writeable
> +     ex    executable
> +     sh    shared
> +     mr    may read
> +     mw    may write
> +     me    may execute
> +     ms    may share
> +     gd    stack segment growns down
> +     pf    pure PFN range
> +     dw    disabled write to the mapped file
> +     lo    pages are locked in memory
> +     io    memory mapped I/O area
> +     sr    sequential read advise provided
> +     rr    random read advise provided
> +     dc    do not copy area on fork
> +     de    do not expand area on remapping
> +     ac    area is accountable
> +     nr    swap space is not reserved for the area
> +     ht    area uses huge tlb pages
> +     ar    architecture specific flag
> +     dd    do not include area into core dump
> +     sd    soft dirty flag
> +     mm    mixed map area
> +     hg    huge page advise flag
> +     nh    no huge page advise flag
> +     mg    mergable advise flag
> ++    bt    arm64 BTI guarded page
> +     ==    =======================================

Looks fine. Thanks Stephen.

-- 
Catalin

  reply	other threads:[~2020-03-18  8:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-18  1:40 linux-next: manual merge of the jc_docs tree with the arm64 tree Stephen Rothwell
2020-03-18  8:49 ` Catalin Marinas [this message]
  -- strict thread matches above, loose matches on Subject: below --
2020-04-29  1:09 Stephen Rothwell
2020-07-06  0:34 Stephen Rothwell
2023-06-22  1:07 Stephen Rothwell

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=20200318084915.GO3005@mbp \
    --to=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=daniel.kiss@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=mchehab+huawei@kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

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

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