On Thu, Jan 18, 2018 at 02:38:39PM +0100, Jan H. Schönherr wrote:
> The function follow_pte_pmd() can theoretically return after having
> acquired a PMD lock, even when DAX was not compiled with
> CONFIG_FS_DAX_PMD.
>
> Release the PMD lock unconditionally.
>
> Fixes: f729c8c9b24f ("dax: wrprotect pmd_t in dax_mapping_entry_mkclean")
> Signed-off-by: Jan H. Schönherr <jschoenh@xxxxxxxxx>
> ---
> fs/dax.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index 9598159..c2ebf10 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -636,8 +636,8 @@ static void dax_mapping_entry_mkclean(struct address_space *mapping,
> pmd = pmd_mkclean(pmd);
> set_pmd_at(vma->vm_mm, address, pmdp, pmd);
> unlock_pmd:
> - spin_unlock(ptl);
> #endif
> + spin_unlock(ptl);
> } else {
> if (pfn != pte_pfn(*ptep))
> goto unlock_pte;
Sure, this seems fine to me. This seems simple and correct - you're right
that we aren't taking the PTL on the PMD conditionally based on whether
CONFIG_DAX_PMD is defined, so it doesn't make sense to release it
conditionally. I think if we ever hit this lock imbalance we're totally
insane anyway, but it the fix is correct and doesn't mess with our code flow.
You can add:
Reviewed-by: Ross Zwisler <ross.zwisler@xxxxxxxxxxxxxxx>
