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
>
>
>
next prev parent 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).