Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1242807 > unrolled thread
| Started by | Ross Zwisler <ross.zwisler@linux.intel.com> |
|---|---|
| First post | 2015-10-09 00:00 +0200 |
| Last post | 2015-10-09 01:10 +0200 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
[PATCH] xfs: clarify lock ordering comment Ross Zwisler <ross.zwisler@linux.intel.com> - 2015-10-09 00:00 +0200
Re: [PATCH] xfs: clarify lock ordering comment Dave Chinner <david@fromorbit.com> - 2015-10-09 00:30 +0200
Re: [PATCH] xfs: clarify lock ordering comment Ross Zwisler <ross.zwisler@linux.intel.com> - 2015-10-09 01:10 +0200
| From | Ross Zwisler <ross.zwisler@linux.intel.com> |
|---|---|
| Date | 2015-10-09 00:00 +0200 |
| Subject | [PATCH] xfs: clarify lock ordering comment |
| Message-ID | <qhrog-7CK-49@gated-at.bofh.it> |
Replace "i_mmap_lock" with "mmap_lock" in the lock ordering comment above xfs_filemap_page_mkwrite(). The lock in question is actually the XFS_MMAPLOCK_SHARED rw_semaphore (no leading "i"), and this comment is easily confused with the "i_mmap_lock_[read|write]" functions that operate on struct address_space->i_mmap_rwsem. This clarification is especially important because address_space->i_mmap_rwsem is taken down in the DAX code as part of this fault path. Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com> --- fs/xfs/xfs_file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c index f429662..b190033 100644 --- a/fs/xfs/xfs_file.c +++ b/fs/xfs/xfs_file.c @@ -1477,7 +1477,7 @@ xfs_file_llseek( * * mmap_sem (MM) * sb_start_pagefault(vfs, freeze) - * i_mmap_lock (XFS - truncate serialisation) + * mmap_lock (XFS - truncate serialisation) * page_lock (MM) * i_lock (XFS - extent map serialisation) */ -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Dave Chinner <david@fromorbit.com> |
|---|---|
| Date | 2015-10-09 00:30 +0200 |
| Message-ID | <qhrRf-8pC-5@gated-at.bofh.it> |
| In reply to | #1242807 |
On Thu, Oct 08, 2015 at 03:58:01PM -0600, Ross Zwisler wrote:
> Replace "i_mmap_lock" with "mmap_lock" in the lock ordering comment above
> xfs_filemap_page_mkwrite(). The lock in question is actually the
> XFS_MMAPLOCK_SHARED rw_semaphore (no leading "i"), and this comment is
struct xfs_inode {
....
mrlock_t i_mmaplock; /* inode mmap IO lock */
....
> easily confused with the "i_mmap_lock_[read|write]" functions that operate
> on struct address_space->i_mmap_rwsem. This clarification is especially
> important because address_space->i_mmap_rwsem is taken down in the DAX
> code as part of this fault path.
>
> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> ---
> fs/xfs/xfs_file.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
> index f429662..b190033 100644
> --- a/fs/xfs/xfs_file.c
> +++ b/fs/xfs/xfs_file.c
> @@ -1477,7 +1477,7 @@ xfs_file_llseek(
> *
> * mmap_sem (MM)
> * sb_start_pagefault(vfs, freeze)
> - * i_mmap_lock (XFS - truncate serialisation)
> + * mmap_lock (XFS - truncate serialisation)
As per above, the XFS lock is "i_mmaplock"...
The lock names are annotated with the subsystem the lock belongs to
to avoid this confusion. Along with the lock ordering (inside
sb_start_pagefault) this should indicate that it's not the
"i_mmap_lock (MM - vma serialisation)" lock... ;)
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Ross Zwisler <ross.zwisler@linux.intel.com> |
|---|---|
| Date | 2015-10-09 01:10 +0200 |
| Message-ID | <qhstY-WT-19@gated-at.bofh.it> |
| In reply to | #1242822 |
On Fri, Oct 09, 2015 at 09:24:50AM +1100, Dave Chinner wrote:
> On Thu, Oct 08, 2015 at 03:58:01PM -0600, Ross Zwisler wrote:
> > Replace "i_mmap_lock" with "mmap_lock" in the lock ordering comment above
> > xfs_filemap_page_mkwrite(). The lock in question is actually the
> > XFS_MMAPLOCK_SHARED rw_semaphore (no leading "i"), and this comment is
>
> struct xfs_inode {
> ....
> mrlock_t i_mmaplock; /* inode mmap IO lock */
> ....
>
> > easily confused with the "i_mmap_lock_[read|write]" functions that operate
> > on struct address_space->i_mmap_rwsem. This clarification is especially
> > important because address_space->i_mmap_rwsem is taken down in the DAX
> > code as part of this fault path.
> >
> > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> > ---
> > fs/xfs/xfs_file.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
> > index f429662..b190033 100644
> > --- a/fs/xfs/xfs_file.c
> > +++ b/fs/xfs/xfs_file.c
> > @@ -1477,7 +1477,7 @@ xfs_file_llseek(
> > *
> > * mmap_sem (MM)
> > * sb_start_pagefault(vfs, freeze)
> > - * i_mmap_lock (XFS - truncate serialisation)
> > + * mmap_lock (XFS - truncate serialisation)
>
> As per above, the XFS lock is "i_mmaplock"...
>
> The lock names are annotated with the subsystem the lock belongs to
> to avoid this confusion. Along with the lock ordering (inside
> sb_start_pagefault) this should indicate that it's not the
> "i_mmap_lock (MM - vma serialisation)" lock... ;)
Ah, that makes sense, thanks. :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web