From: Ritesh Harjani <riteshh@linux.ibm.com>
To: Matthew Bobrowski <mbobrowski@mbobrowski.org>
Cc: jack@suse.cz, tytso@mit.edu, linux-ext4@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [RFCv3 2/4] ext4: Add ext4_ilock & ext4_iunlock API
Date: Wed, 20 Nov 2019 17:48:30 +0530 [thread overview]
Message-ID: <20191120121831.9639B42047@d06av24.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <20191120112339.GB30486@bobrowski>
Hello Matthew,
Thanks for the review.
On 11/20/19 4:53 PM, Matthew Bobrowski wrote:
> On Wed, Nov 20, 2019 at 10:30:22AM +0530, Ritesh Harjani wrote:
>> This adds ext4_ilock/iunlock types of APIs.
>> This is the preparation APIs to make shared
>> locking/unlocking & restarting with exclusive
>> locking/unlocking easier in next patch.
>
> *scratches head*
>
> A nit, but what's with the changelog wrapping at like ~40 characters?
Yup will fix that next time. Thanks.
>
>> +#define EXT4_IOLOCK_EXCL (1 << 0)
>> +#define EXT4_IOLOCK_SHARED (1 << 1)
>>
>> +static inline void ext4_ilock(struct inode *inode, unsigned int iolock)
>> +{
>> + if (iolock == EXT4_IOLOCK_EXCL)
>> + inode_lock(inode);
>> + else
>> + inode_lock_shared(inode);
>> +}
>> +
>> +static inline void ext4_iunlock(struct inode *inode, unsigned int iolock)
>> +{
>> + if (iolock == EXT4_IOLOCK_EXCL)
>> + inode_unlock(inode);
>> + else
>> + inode_unlock_shared(inode);
>> +}
>> +
>> +static inline int ext4_ilock_nowait(struct inode *inode, unsigned int iolock)
>> +{
>> + if (iolock == EXT4_IOLOCK_EXCL)
>> + return inode_trylock(inode);
>> + else
>> + return inode_trylock_shared(inode);
>> +}
>
> Is it really necessary for all these helpers to actually have the
> 'else' statement? Could we not just return/set whatever takes the
> 'else' branch directly from the end of these functions? I think it
> would be cleaner that way.
Sure np.
>
> /me doesn't really like the naming of these functions either.
:) difference of opinion.
>
> What's people's opinion on changing these for example:
> - ext4_inode_lock()
> - ext4_inode_unlock()
>
ext4_ilock/iunlock sounds better to me as it is short too.
But if others have also have a strong opinion towards
ext4_inode_lock/unlock() - I am ok with that.
> Or, better yet, is there any reason why we've never actually
> considered naming such functions to have the verb precede the actual
> object that we're performing the operation on? In my opinion, it
> totally makes way more sense from a code readability standpoint and
> overall intent of the function. For example:
> - ext4_lock_inode()
> - ext4_unlock_inode()
Not against your suggestion here.
But in kernel I do see a preference towards object followed by a verb.
At least in vfs I see functions like inode_lock()/unlock().
Plus I would not deny that this naming is also inspired from
xfs_ilock()/iunlock API names.
>
>> +static inline void ext4_ilock_demote(struct inode *inode, unsigned int iolock)
>> +{
>> + BUG_ON(iolock != EXT4_IOLOCK_EXCL);
>> + downgrade_write(&inode->i_rwsem);
>> +}
>> +
>
> Same principle would also apply here.
>
> On an ending note, I'm not really sure that I like the name of these
> macros. Like, for example, expand the macro 'EXT4_IOLOCK_EXCL' into
> plain english words as if you were reading it. This would translate to
> something like 'EXT4 INPUT/OUPUT LOCK EXCLUSIVE' or 'EXT4 IO LOCK
> EXCLUSIVE'. Just flipping the words around make a significant
> improvement for overall readability i.e. 'EXT4_EXCL_IOLOCK', which
> would expand out to 'EXT4 EXCLUSIVE IO LOCK'. Speaking of, is there
Ditto. Unless you and others have a strong objection, I would rather
keep this as is :)
> any reason why we don't mention 'INODE' here seeing as though that's
> the object we're actually protecting by taking one of these locking
> mechanisms?
hmm, it was increasing the name of the macro if I do it that way.
But that's ok. Is below macro name better?
#define EXT4_INODE_IOLOCK_EXCL (1 << 0)
#define EXT4_INODE_IOLOCK_SHARED (1 << 1)
Thanks for the review!!
-ritesh
next prev parent reply other threads:[~2019-11-20 12:18 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-20 5:00 [RFCv3 0/4] ext4: Introducing ilock wrapper APIs & fixing i_rwsem scalablity prob. in DIO mixed-rw Ritesh Harjani
2019-11-20 5:00 ` [RFCv3 1/4] ext4: fix ext4_dax_read/write inode locking sequence for IOCB_NOWAIT Ritesh Harjani
2019-11-20 12:51 ` Jan Kara
2019-11-22 5:53 ` Matthew Bobrowski
2019-11-20 5:00 ` [RFCv3 2/4] ext4: Add ext4_ilock & ext4_iunlock API Ritesh Harjani
2019-11-20 11:23 ` Matthew Bobrowski
2019-11-20 12:18 ` Ritesh Harjani [this message]
2019-11-20 16:35 ` Matthew Wilcox
2019-11-23 11:51 ` Ritesh Harjani
2019-11-20 13:11 ` Jan Kara
2019-11-20 16:06 ` Darrick J. Wong
2019-11-20 5:00 ` [RFCv3 3/4] ext4: start with shared iolock in case of DIO instead of excl. iolock Ritesh Harjani
2019-11-20 13:55 ` Jan Kara
2019-11-23 13:17 ` Ritesh Harjani
2019-11-20 5:00 ` [RFCv3 4/4] ext4: Move to shared iolock even without dioread_nolock mount opt Ritesh Harjani
2019-11-20 14:32 ` Jan Kara
2019-11-26 10:51 ` Ritesh Harjani
2019-11-26 12:45 ` Ritesh Harjani
2019-11-29 17:23 ` Jan Kara
2019-11-29 17:18 ` Jan Kara
2019-12-03 11:54 ` Ritesh Harjani
2019-12-03 12:39 ` Jan Kara
2019-12-03 13:10 ` Ritesh Harjani
2019-12-03 13:48 ` Jan Kara
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=20191120121831.9639B42047@d06av24.portsmouth.uk.ibm.com \
--to=riteshh@linux.ibm.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mbobrowski@mbobrowski.org \
--cc=tytso@mit.edu \
/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).