Re: [PATCH v2 2/2] overlayfs.rst: fix ReST formatting

[Bagas Sanjaya <bagasdotme@gmail.com>]

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

On Wed, Dec 13, 2023 at 02:34:22PM +0200, Amir Goldstein wrote:
> Fix some indentation issues and fix missing newlines in quoted text
> by converting quoted text to code blocks.
> 
> Unindent a) b) enumerated list to workaround github displaying it
> as numbered list.
> 
> Reported-by: Christian Brauner <brauner@kernel.org>
> Suggested-by: Bagas Sanjaya <bagasdotme@gmail.com>
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> ---
>  Documentation/filesystems/overlayfs.rst | 63 +++++++++++++------------
>  1 file changed, 32 insertions(+), 31 deletions(-)
> 
> diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst
> index 926396fdc5eb..a36f3a2a2d4b 100644
> --- a/Documentation/filesystems/overlayfs.rst
> +++ b/Documentation/filesystems/overlayfs.rst
> @@ -118,7 +118,7 @@ Where both upper and lower objects are directories, a merged directory
>  is formed.
>  
>  At mount time, the two directories given as mount options "lowerdir" and
> -"upperdir" are combined into a merged directory:
> +"upperdir" are combined into a merged directory::
>  
>    mount -t overlay overlay -olowerdir=/lower,upperdir=/upper,\
>    workdir=/work /merged
> @@ -174,10 +174,10 @@ programs.
>  seek offsets are assigned sequentially when the directories are read.
>  Thus if
>  
> -  - read part of a directory
> -  - remember an offset, and close the directory
> -  - re-open the directory some time later
> -  - seek to the remembered offset
> +- read part of a directory
> +- remember an offset, and close the directory
> +- re-open the directory some time later
> +- seek to the remembered offset
>  
>  there may be little correlation between the old and new locations in
>  the list of filenames, particularly if anything has changed in the
> @@ -285,21 +285,21 @@ Permission model
>  
>  Permission checking in the overlay filesystem follows these principles:
>  
> - 1) permission check SHOULD return the same result before and after copy up
> +1) permission check SHOULD return the same result before and after copy up
>  
> - 2) task creating the overlay mount MUST NOT gain additional privileges
> +2) task creating the overlay mount MUST NOT gain additional privileges
>  
> - 3) non-mounting task MAY gain additional privileges through the overlay,
> - compared to direct access on underlying lower or upper filesystems
> +3) non-mounting task MAY gain additional privileges through the overlay,
> +   compared to direct access on underlying lower or upper filesystems
>  
> -This is achieved by performing two permission checks on each access
> +This is achieved by performing two permission checks on each access:
>  
> - a) check if current task is allowed access based on local DAC (owner,
> -    group, mode and posix acl), as well as MAC checks
> +a) check if current task is allowed access based on local DAC (owner,
> +group, mode and posix acl), as well as MAC checks
>  
> - b) check if mounting task would be allowed real operation on lower or
> -    upper layer based on underlying filesystem permissions, again including
> -    MAC checks
> +b) check if mounting task would be allowed real operation on lower or
> +upper layer based on underlying filesystem permissions, again including
> +MAC checks
>  
>  Check (a) ensures consistency (1) since owner, group, mode and posix acls
>  are copied up.  On the other hand it can result in server enforced
> @@ -311,11 +311,11 @@ to create setups where the consistency rule (1) does not hold; normally,
>  however, the mounting task will have sufficient privileges to perform all
>  operations.
>  
> -Another way to demonstrate this model is drawing parallels between
> +Another way to demonstrate this model is drawing parallels between::
>  
>    mount -t overlay overlay -olowerdir=/lower,upperdir=/upper,... /merged
>  
> -and
> +and::
>  
>    cp -a /lower /upper
>    mount --bind /upper /merged
> @@ -328,7 +328,7 @@ Multiple lower layers
>  ---------------------
>  
>  Multiple lower layers can now be given using the colon (":") as a
> -separator character between the directory names.  For example:
> +separator character between the directory names.  For example::
>  
>    mount -t overlay overlay -olowerdir=/lower1:/lower2:/lower3 /merged
>  
> @@ -340,13 +340,13 @@ rightmost one and going left.  In the above example lower1 will be the
>  top, lower2 the middle and lower3 the bottom layer.
>  
>  Note: directory names containing colons can be provided as lower layer by
> -escaping the colons with a single backslash.  For example:
> +escaping the colons with a single backslash.  For example::
>  
>    mount -t overlay overlay -olowerdir=/a\:lower\:\:dir /merged
>  
>  Since kernel version v6.8, directory names containing colons can also
>  be configured as lower layer using the "lowerdir+" mount options and the
> -fsconfig syscall from new mount api.  For example:
> +fsconfig syscall from new mount api.  For example::
>  
>    fsconfig(fs_fd, FSCONFIG_SET_STRING, "lowerdir+", "/a:lower::dir", 0);
>  
> @@ -390,11 +390,11 @@ Data-only lower layers
>  With "metacopy" feature enabled, an overlayfs regular file may be a composition
>  of information from up to three different layers:
>  
> - 1) metadata from a file in the upper layer
> +1) metadata from a file in the upper layer
>  
> - 2) st_ino and st_dev object identifier from a file in a lower layer
> +2) st_ino and st_dev object identifier from a file in a lower layer
>  
> - 3) data from a file in another lower layer (further below)
> +3) data from a file in another lower layer (further below)
>  
>  The "lower data" file can be on any lower layer, except from the top most
>  lower layer.
> @@ -405,7 +405,7 @@ A normal lower layer is not allowed to be below a data-only layer, so single
>  colon separators are not allowed to the right of double colon ("::") separators.
>  
>  
> -For example:
> +For example::
>  
>    mount -t overlay overlay -olowerdir=/l1:/l2:/l3::/do1::/do2 /merged
>  
> @@ -419,7 +419,7 @@ to the absolute path of the "lower data" file in the "data-only" lower layer.
>  
>  Since kernel version v6.8, "data-only" lower layers can also be added using
>  the "datadir+" mount options and the fsconfig syscall from new mount api.
> -For example:
> +For example::
>  
>    fsconfig(fs_fd, FSCONFIG_SET_STRING, "lowerdir+", "/l1", 0);
>    fsconfig(fs_fd, FSCONFIG_SET_STRING, "lowerdir+", "/l2", 0);
> @@ -429,7 +429,7 @@ For example:
>  
>  
>  fs-verity support
> -----------------------
> +-----------------
>  
>  During metadata copy up of a lower file, if the source file has
>  fs-verity enabled and overlay verity support is enabled, then the
> @@ -653,9 +653,10 @@ following rules apply:
>     encode an upper file handle from upper inode
>  
>  The encoded overlay file handle includes:
> - - Header including path type information (e.g. lower/upper)
> - - UUID of the underlying filesystem
> - - Underlying filesystem encoding of underlying inode
> +
> +- Header including path type information (e.g. lower/upper)
> +- UUID of the underlying filesystem
> +- Underlying filesystem encoding of underlying inode
>  
>  This encoding format is identical to the encoding format file handles that
>  are stored in extended attribute "trusted.overlay.origin".
> @@ -773,9 +774,9 @@ Testsuite
>  There's a testsuite originally developed by David Howells and currently
>  maintained by Amir Goldstein at:
>  
> -  https://github.com/amir73il/unionmount-testsuite.git
> +https://github.com/amir73il/unionmount-testsuite.git
>  
> -Run as root:
> +Run as root::
>  
>    # cd unionmount-testsuite
>    # ./run --ov --verify

LGTM, thanks!

Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>

-- 
An old man doll... just what I always wanted! - Clara

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