LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Kari Argillander <kari.argillander@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH] docs: fs: Refactor directory-locking.rst for better reading
Date: Tue, 7 Sep 2021 10:43:42 +0300	[thread overview]
Message-ID: <20210907074342.ycsuuafn4pjsxbei@kari-VirtualBox> (raw)
In-Reply-To: <20210816222639.73838-1-kari.argillander@gmail.com>

On Tue, Aug 17, 2021 at 01:26:39AM +0300, Kari Argillander wrote:
> Reorganize classes so that it is easier to read. Before number 4 was
> written in one lenghty paragraph. It is as long as number 6 and it is
> basically same kind of class (rename()). Also old number 5 was list and
> it is as short as 1, 2, 3 so it can be converted non list.
> 
> This makes file now much readible.

Gently ping for this one.

> 
> Signed-off-by: Kari Argillander <kari.argillander@gmail.com>
> ---
>  .../filesystems/directory-locking.rst         | 31 +++++++++----------
>  1 file changed, 15 insertions(+), 16 deletions(-)
> 
> diff --git a/Documentation/filesystems/directory-locking.rst b/Documentation/filesystems/directory-locking.rst
> index 504ba940c36c..33921dff7af4 100644
> --- a/Documentation/filesystems/directory-locking.rst
> +++ b/Documentation/filesystems/directory-locking.rst
> @@ -11,7 +11,7 @@ When taking the i_rwsem on multiple non-directory objects, we
>  always acquire the locks in order by increasing address.  We'll call
>  that "inode pointer" order in the following.
>  
> -For our purposes all operations fall in 5 classes:
> +For our purposes all operations fall in 6 classes:
>  
>  1) read access.  Locking rules: caller locks directory we are accessing.
>  The lock is taken shared.
> @@ -22,26 +22,25 @@ exclusive.
>  3) object removal.  Locking rules: caller locks parent, finds victim,
>  locks victim and calls the method.  Locks are exclusive.
>  
> -4) rename() that is _not_ cross-directory.  Locking rules: caller locks
> -the parent and finds source and target.  In case of exchange (with
> -RENAME_EXCHANGE in flags argument) lock both.  In any case,
> -if the target already exists, lock it.  If the source is a non-directory,
> -lock it.  If we need to lock both, lock them in inode pointer order.
> -Then call the method.  All locks are exclusive.
> -NB: we might get away with locking the source (and target in exchange
> -case) shared.
> +4) link creation.  Locking rules: lock parent, check that source is not
> +a directory, lock source and call the method.  Locks are exclusive.
>  
> -5) link creation.  Locking rules:
> +5) rename() that is _not_ cross-directory.
> +Locking rules:
>  
> -	* lock parent
> -	* check that source is not a directory
> -	* lock source
> -	* call the method.
> +	* Caller locks the parent and finds source and target.
> +	* In case of exchange (with RENAME_EXCHANGE in flags argument)
> +	  lock both the source and the target.
> +	* If the target exists, lock it,  If the source is a non-directory,
> +	  lock it. If we need to lock both, do so in inode pointer order.
> +	* Call the method.
>  
>  All locks are exclusive.
> +NB: we might get away with locking the source (and target in exchange
> +case) shared.
>  
> -6) cross-directory rename.  The trickiest in the whole bunch.  Locking
> -rules:
> +6) rename() that _is_ cross-directory.  The trickiest in the whole bunch.
> +Locking rules:
>  
>  	* lock the filesystem
>  	* lock parents in "ancestors first" order.
> -- 
> 2.30.2
> 

      reply	other threads:[~2021-09-07  7:43 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-16 22:26 Kari Argillander
2021-09-07  7:43 ` Kari Argillander [this message]

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=20210907074342.ycsuuafn4pjsxbei@kari-VirtualBox \
    --to=kari.argillander@gmail.com \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --subject='Re: [PATCH] docs: fs: Refactor directory-locking.rst for better reading' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).