linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: dai.ngo@oracle.com
To: Chuck Lever III <chuck.lever@oracle.com>,
	Jeff Layton <jlayton@redhat.com>
Cc: Bruce Fields <bfields@fieldses.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH RFC v15 01/11] fs/lock: add helper locks_any_blockers to check for blockers
Date: Wed, 9 Mar 2022 19:11:25 -0800	[thread overview]
Message-ID: <cf55f250-a1ba-243c-f826-3cbd91088d6b@oracle.com> (raw)
In-Reply-To: <AB3847D1-CAD5-4D6F-8D49-C380F2E7AB64@oracle.com>

On 3/9/22 12:56 PM, Chuck Lever III wrote:
>
>> On Mar 4, 2022, at 7:37 PM, Dai Ngo <dai.ngo@oracle.com> wrote:
>>
>> Add helper locks_any_blockers to check if there is any blockers
>> for a file_lock.
>>
>> Signed-off-by: Dai Ngo <dai.ngo@oracle.com>
>> ---
>> include/linux/fs.h | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/include/linux/fs.h b/include/linux/fs.h
>> index 831b20430d6e..7f5756bfcc13 100644
>> --- a/include/linux/fs.h
>> +++ b/include/linux/fs.h
>> @@ -1200,6 +1200,11 @@ extern void lease_unregister_notifier(struct notifier_block *);
>> struct files_struct;
>> extern void show_fd_locks(struct seq_file *f,
>> 			 struct file *filp, struct files_struct *files);
>> +
>> +static inline bool locks_has_blockers_locked(struct file_lock *lck)
>> +{
>> +	return !list_empty(&lck->fl_blocked_requests);
>> +}
>> #else /* !CONFIG_FILE_LOCKING */
>> static inline int fcntl_getlk(struct file *file, unsigned int cmd,
>> 			      struct flock __user *user)
>> @@ -1335,6 +1340,11 @@ static inline int lease_modify(struct file_lock *fl, int arg,
>> struct files_struct;
>> static inline void show_fd_locks(struct seq_file *f,
>> 			struct file *filp, struct files_struct *files) {}
>> +
>> +static inline bool locks_has_blockers_locked(struct file_lock *lck)
>> +{
>> +	return false;
>> +}
>> #endif /* !CONFIG_FILE_LOCKING */
>>
>> static inline struct inode *file_inode(const struct file *f)
> Hm. This is not exactly what I had in mind.
>
> In order to be more kABI friendly, fl_blocked_requests should be
> dereferenced only in fs/locks.c. IMO you want to take the inner
> loop in nfs4_lockowner_has_blockers() and make that a function
> that lives in fs/locks.c. Something akin to:
>
> fs/locks.c:
>
> /**
>   * locks_owner_has_blockers - Check for blocking lock requests
>   * @flctx: file lock context
>   * @owner: lock owner
>   *
>   * Return values:
>   *   %true: @ctx has at least one blocker
>   *   %false: @ctx has no blockers
>   */
> bool locks_owner_has_blockers(struct file_lock_context *flctx,
> 			      fl_owner_t owner)
> {
> 	struct file_lock *fl;
>
> 	spin_lock(&flctx->flc_lock);
> 	list_for_each_entry(fl, &flctx->flc_posix, fl_list) {
> 		if (fl->fl_owner != owner)
> 			continue;
> 		if (!list_empty(&fl->fl_blocked_requests)) {
> 			spin_unlock(&flctx->flc_lock);
> 			return true;
> 		}
> 	}
> 	spin_unlock(&flctx->flc_lock);
> 	return false;
> }
> EXPORT_SYMBOL(locks_owner_has_blockers);
>
> As a subsequent clean up (which anyone can do at a later point),
> a similar change could be done to check_for_locks(). This bit of
> code seems to appear in several other filesystems, for example:

I used check_for_locks as reference for locks_owner_has_blockers
so both should be updated to be more kABI friendly as you suggested.
Can I update both in a subsequent cleanup patch? I plan to have
a number of small cleanup up patches for these and also some nits.

Thanks,
-Dai


>
> 7643         inode = locks_inode(nf->nf_file);
> 7644         flctx = inode->i_flctx;
> 7645
> 7646         if (flctx && !list_empty_careful(&flctx->flc_posix)) {
> 7647                 spin_lock(&flctx->flc_lock);
> 7648                 list_for_each_entry(fl, &flctx->flc_posix, fl_list) {
> 7649                         if (fl->fl_owner == (fl_owner_t)lowner) {
> 7650                                 status = true;
> 7651                                 break;
> 7652                         }
> 7653                 }
> 7654                 spin_unlock(&flctx->flc_lock);
> 7655         }
>
>
> --
> Chuck Lever
>
>
>

  reply	other threads:[~2022-03-10  3:11 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-05  0:37 [PATCH RFC v15 0/11] NFSD: Initial implementation of NFSv4 Courteous Server Dai Ngo
2022-03-05  0:37 ` [PATCH RFC v15 01/11] fs/lock: add helper locks_any_blockers to check for blockers Dai Ngo
2022-03-09 20:56   ` Chuck Lever III
2022-03-10  3:11     ` dai.ngo [this message]
2022-03-10  4:08       ` Chuck Lever III
2022-03-10  4:45         ` dai.ngo
2022-03-05  0:37 ` [PATCH RFC v15 02/11] NFSD: Add client flags, macro and spinlock to support courteous server Dai Ngo
2022-03-05  0:37 ` [PATCH RFC v15 03/11] NFSD: Add lm_lock_expired call out Dai Ngo
2022-03-05  0:37 ` [PATCH RFC v15 04/11] NFSD: Update nfsd_breaker_owns_lease() to handle courtesy clients Dai Ngo
2022-03-09 21:46   ` Chuck Lever III
2022-03-10  5:09     ` dai.ngo
2022-03-10 14:02       ` Chuck Lever III
2022-03-05  0:37 ` [PATCH RFC v15 05/11] NFSD: Update nfs4_get_vfs_file() " Dai Ngo
2022-03-05  0:37 ` [PATCH RFC v15 06/11] NFSD: Update find_clp_in_name_tree() " Dai Ngo
2022-03-09 22:08   ` Chuck Lever III
2022-03-10  3:11     ` dai.ngo
2022-03-05  0:37 ` [PATCH RFC v15 07/11] NFSD: Update find_in_sessionid_hashtbl() " Dai Ngo
2022-03-09 22:42   ` Chuck Lever III
2022-03-10  3:12     ` dai.ngo
2022-03-10  3:33       ` Chuck Lever III
2022-03-10  4:43         ` dai.ngo
2022-03-05  0:37 ` [PATCH RFC v15 08/11] NFSD: Update find_client_in_id_table() " Dai Ngo
2022-03-05  0:37 ` [PATCH RFC v15 09/11] NFSD: Refactor nfsd4_laundromat() Dai Ngo
2022-03-05  0:37 ` [PATCH RFC v15 10/11] NFSD: Update laundromat to handle courtesy clients Dai Ngo
2022-03-05  0:37 ` [PATCH RFC v15 11/11] NFSD: Show state of courtesy clients in client info Dai Ngo
2022-03-09 20:14   ` Chuck Lever III
2022-03-09 20:51     ` dai.ngo
2022-03-10  3:09       ` dai.ngo
2022-03-10  3:27         ` Chuck Lever III
2022-03-10 15:00           ` Bruce Fields
2022-03-10 17:59             ` dai.ngo
2022-03-10 14:43         ` Chuck Lever III

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=cf55f250-a1ba-243c-f826-3cbd91088d6b@oracle.com \
    --to=dai.ngo@oracle.com \
    --cc=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=jlayton@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@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 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).