All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Imran Khan <imran.f.khan@oracle.com>
Cc: viro@zeniv.linux.org.uk, gregkh@linuxfoundation.org,
	ebiederm@xmission.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8 05/10] kernfs: Replace global kernfs_open_file_mutex with hashed mutexes.
Date: Fri, 22 Apr 2022 07:00:29 -1000	[thread overview]
Message-ID: <YmLfLX5Ce8+VF2G4@slm.duckdns.org> (raw)
In-Reply-To: <20220410023719.1752460-6-imran.f.khan@oracle.com>

On Sun, Apr 10, 2022 at 12:37:14PM +1000, Imran Khan wrote:
> diff --git a/fs/kernfs/file.c b/fs/kernfs/file.c
> index 214b48d59148..0946ab341ce4 100644
> --- a/fs/kernfs/file.c
> +++ b/fs/kernfs/file.c
> @@ -19,18 +19,14 @@
>  #include "kernfs-internal.h"
>  
>  /*
> - * There's one kernfs_open_file for each open file and one kernfs_open_node
> - * for each kernfs_node with one or more open files.
> - *
> + * kernfs locks
> + */
> +extern struct kernfs_global_locks *kernfs_locks;

This should be in a header file, right?

> @@ -545,7 +543,7 @@ static int kernfs_get_open_node(struct kernfs_node *kn,
>  	 * need rcu_read_lock to ensure its existence.
>  	 */
>  	on = rcu_dereference_protected(kn->attr.open,
> -				   lockdep_is_held(&kernfs_open_file_mutex));
> +				   lockdep_is_held(mutex));
>  	if (on) {
>  		list_add_tail(&of->list, &on->files);
>  		mutex_unlock(mutex);
> @@ -593,10 +591,10 @@ static void kernfs_put_open_node(struct kernfs_node *kn,
>  	mutex = kernfs_open_file_mutex_lock(kn);
>  
>  	on = rcu_dereference_protected(kn->attr.open,
> -				       lockdep_is_held(&kernfs_open_file_mutex));
> +				       lockdep_is_held(mutex));
>  
>  	if (!on) {
> -		mutex_unlock(&kernfs_open_file_mutex);
> +		mutex_unlock(mutex);
>  		return;
>  	}

Don't above chunks belong to the previous patch?

> @@ -769,6 +767,10 @@ static int kernfs_fop_release(struct inode *inode, struct file *filp)
>  	struct mutex *mutex = NULL;
>  
>  	if (kn->flags & KERNFS_HAS_RELEASE) {
> +		/**
> +		 * Callers of kernfs_fop_release, don't need global
> +		 * exclusion so using hashed mutex here is safe.
> +		 */

I don't think we use /** for in-line comments. Just do balanced wings.

 /*
  * ....
  */

besides, I'm not sure the comment is helping that much. It'd be better to
have a comment describing the locking rules comprehensively around the lock
definition and/or helpers.

>  		mutex = kernfs_open_file_mutex_lock(kn);
>  		kernfs_release_file(kn, of);
>  		mutex_unlock(mutex);
> @@ -796,9 +798,9 @@ void kernfs_drain_open_files(struct kernfs_node *kn)
>  
>  	mutex = kernfs_open_file_mutex_lock(kn);
>  	on = rcu_dereference_check(kn->attr.open,
> -				   lockdep_is_held(&kernfs_open_file_mutex));
> +				   lockdep_is_held(mutex));
>  	if (!on) {
> -		mutex_unlock(&kernfs_open_file_mutex);
> +		mutex_unlock(mutex);

Again, should be in the previous patch.

> +void __init kernfs_lock_init(void)
> +{
> +	int count;
> +
> +	kernfs_locks = kmalloc(sizeof(struct kernfs_global_locks), GFP_KERNEL);
> +	WARN_ON(!kernfs_locks);
> +
> +	for (count = 0; count < NR_KERNFS_LOCKS; count++)
> +		mutex_init(&kernfs_locks->open_file_mutex[count].lock);
> +}

Does this need to be a separate function?

>  void __init kernfs_init(void)
>  {
>  	kernfs_node_cache = kmem_cache_create("kernfs_node_cache",
> @@ -397,4 +409,6 @@ void __init kernfs_init(void)
>  	kernfs_iattrs_cache  = kmem_cache_create("kernfs_iattrs_cache",
>  					      sizeof(struct kernfs_iattrs),
>  					      0, SLAB_PANIC, NULL);
> +
> +	kernfs_lock_init();
>  }
> diff --git a/include/linux/kernfs.h b/include/linux/kernfs.h
> index 2dd9c8df0f4f..cc514bda0ae7 100644
> --- a/include/linux/kernfs.h
> +++ b/include/linux/kernfs.h
...
> + * filp->private_data points to seq_file whose ->private points to
> + * kernfs_open_file.
> + * kernfs_open_files are chained at kernfs_open_node->files, which is
> + * protected by kernfs_open_file_mutex.lock.

Can you either flow the sentences together or have a blank line inbetween if
they're supposed to be in separate paragraphs?

> + */
> +struct kernfs_open_file_mutex {
> +	struct mutex lock;
> +} ____cacheline_aligned_in_smp;

Is there a reason to define the outer struct?

> +/*
> + * To reduce possible contention in sysfs access, arising due to single
> + * locks, use an array of locks and use kernfs_node object address as
> + * hash keys to get the index of these locks.
> + */
> +struct kernfs_global_locks {
> +	struct kernfs_open_file_mutex open_file_mutex[NR_KERNFS_LOCKS];
> +};

Ditto, why not just define the array directly?

> +void kernfs_lock_init(void);

Does this function need to be exposed?

Thanks.

-- 
tejun

  reply	other threads:[~2022-04-22 17:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-10  2:37 [PATCH v8 00/10] kernfs: Remove reference counting for kernfs_open_node Imran Khan
2022-04-10  2:37 ` [PATCH v8 01/10] " Imran Khan
2022-04-22 16:03   ` Tejun Heo
2022-04-26  1:43     ` Imran Khan
2022-04-26 18:29       ` Tejun Heo
2022-04-26 20:13         ` Al Viro
2022-04-26 20:16           ` Tejun Heo
2022-04-10  2:37 ` [PATCH v8 02/10] kernfs: make ->attr.open RCU protected Imran Khan
2022-04-22 16:19   ` Tejun Heo
2022-04-26  1:54     ` Imran Khan
2022-04-26 18:37       ` Tejun Heo
2022-04-10  2:37 ` [PATCH v8 03/10] kernfs: Change kernfs_notify_list to llist Imran Khan
2022-04-22 16:41   ` Tejun Heo
2022-04-10  2:37 ` [PATCH v8 04/10] kernfs: Introduce interface to access global kernfs_open_file_mutex Imran Khan
2022-04-10  2:37 ` [PATCH v8 05/10] kernfs: Replace global kernfs_open_file_mutex with hashed mutexes Imran Khan
2022-04-22 17:00   ` Tejun Heo [this message]
2022-04-10  2:37 ` [PATCH v8 06/10] kernfs: Use a per-fs rwsem to protect per-fs list of kernfs_super_info Imran Khan
2022-04-10  2:37 ` [PATCH v8 07/10] kernfs: Change kernfs_rename_lock into a read-write lock Imran Khan
2022-04-10  2:37 ` [PATCH v8 08/10] kernfs: Introduce interface to access per-fs rwsem Imran Khan
2022-04-10  2:37 ` [PATCH v8 09/10] kernfs: Replace per-fs rwsem with hashed rwsems Imran Khan
2022-04-10  2:37 ` [PATCH v8 10/10] kernfs: Add a document to describe hashed locks used in kernfs Imran Khan
2022-04-22 17:03 ` [PATCH v8 00/10] kernfs: Remove reference counting for kernfs_open_node Tejun Heo
2022-04-23  8:49   ` Imran Khan
2022-04-25 17:21     ` Tejun Heo
2022-04-28 17:28       ` Imran Khan

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=YmLfLX5Ce8+VF2G4@slm.duckdns.org \
    --to=tj@kernel.org \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=imran.f.khan@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.