Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1620916 > unrolled thread

[PATCH 1/2] drivers/dax: Avoiding potential deadlock

Started byPushkar Jambhlekar <pushkar.iit@gmail.com>
First post2017-04-11 07:30 +0200
Last post2017-04-12 06:20 +0200
Articles 6 — 3 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH 1/2] drivers/dax: Avoiding potential deadlock Pushkar Jambhlekar <pushkar.iit@gmail.com> - 2017-04-11 07:30 +0200
    [PATCH 2/2] drivers/dax: Changing RC value Pushkar Jambhlekar <pushkar.iit@gmail.com> - 2017-04-11 07:30 +0200
      Re: [PATCH 2/2] drivers/dax: Changing RC value Andrew Morton <akpm@linux-foundation.org> - 2017-04-11 23:00 +0200
        Re: [PATCH 2/2] drivers/dax: Changing RC value Dan Williams <dan.j.williams@intel.com> - 2017-04-12 18:30 +0200
    Re: [PATCH 1/2] drivers/dax: Avoiding potential deadlock Dan Williams <dan.j.williams@intel.com> - 2017-04-11 18:20 +0200
      Re: [PATCH 1/2] drivers/dax: Avoiding potential deadlock Pushkar Jambhlekar <pushkar.iit@gmail.com> - 2017-04-12 06:20 +0200

#1620916 — [PATCH 1/2] drivers/dax: Avoiding potential deadlock

FromPushkar Jambhlekar <pushkar.iit@gmail.com>
Date2017-04-11 07:30 +0200
Subject[PATCH 1/2] drivers/dax: Avoiding potential deadlock
Message-ID<tuWxj-2Jg-3@gated-at.bofh.it>
dax_dev_huge_fault returning without releasing lock. Making code change to avoid this situation

Signed-off-by: Pushkar Jambhlekar <pushkar.iit@gmail.com>
---
 drivers/dax/dax.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index 0d1ca24..fd9c4db 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -590,7 +590,7 @@ static int dax_dev_huge_fault(struct vm_fault *vmf,
 		rc = __dax_dev_pud_fault(dax_dev, vmf);
 		break;
 	default:
-		return VM_FAULT_FALLBACK;
+		rc = VM_FAULT_FALLBACK;
 	}
 	rcu_read_unlock();
 
-- 
2.7.4

[toc] | [next] | [standalone]

#1620926 — [PATCH 2/2] drivers/dax: Changing RC value

FromPushkar Jambhlekar <pushkar.iit@gmail.com>
Date2017-04-11 07:30 +0200
Subject[PATCH 2/2] drivers/dax: Changing RC value
Message-ID<tuWxk-2Jg-27@gated-at.bofh.it>
In reply to#1620916
Changing rc value from VM_FAULT_FALLBACK to VM_FAULT_SIGBUS for an unknown / unsupported fault size.

Signed-off-by: Pushkar Jambhlekar <pushkar.iit@gmail.com>
---
 drivers/dax/dax.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index fd9c4db..6156fdc 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -590,7 +590,7 @@ static int dax_dev_huge_fault(struct vm_fault *vmf,
 		rc = __dax_dev_pud_fault(dax_dev, vmf);
 		break;
 	default:
-		rc = VM_FAULT_FALLBACK;
+		rc = VM_FAULT_SIGBUS;
 	}
 	rcu_read_unlock();
 
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1621612 — Re: [PATCH 2/2] drivers/dax: Changing RC value

FromAndrew Morton <akpm@linux-foundation.org>
Date2017-04-11 23:00 +0200
SubjectRe: [PATCH 2/2] drivers/dax: Changing RC value
Message-ID<tvb3k-3yo-19@gated-at.bofh.it>
In reply to#1620926
On Tue, 11 Apr 2017 10:56:45 +0530 Pushkar Jambhlekar <pushkar.iit@gmail.com> wrote:

> Changing rc value from VM_FAULT_FALLBACK to VM_FAULT_SIGBUS for an unknown / unsupported fault size.
> 
> ...
>
> --- a/drivers/dax/dax.c
> +++ b/drivers/dax/dax.c
> @@ -590,7 +590,7 @@ static int dax_dev_huge_fault(struct vm_fault *vmf,
>  		rc = __dax_dev_pud_fault(dax_dev, vmf);
>  		break;
>  	default:
> -		rc =  VM_FAULT_FALLBACK;
> +		rc = VM_FAULT_SIGBUS;
>  	}
>  	rcu_read_unlock();

The change seems to make sense but more info would be helpful.  What
is wrong with the current code?  ie, what goes wrong if we return
VM_FAULT_FALLBACK here?

[toc] | [prev] | [next] | [standalone]

#1622306 — Re: [PATCH 2/2] drivers/dax: Changing RC value

FromDan Williams <dan.j.williams@intel.com>
Date2017-04-12 18:30 +0200
SubjectRe: [PATCH 2/2] drivers/dax: Changing RC value
Message-ID<tvtjB-6IX-43@gated-at.bofh.it>
In reply to#1621612
On Tue, Apr 11, 2017 at 1:58 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Tue, 11 Apr 2017 10:56:45 +0530 Pushkar Jambhlekar <pushkar.iit@gmail.com> wrote:
>
>> Changing rc value from VM_FAULT_FALLBACK to VM_FAULT_SIGBUS for an unknown / unsupported fault size.
>>
>> ...
>>
>> --- a/drivers/dax/dax.c
>> +++ b/drivers/dax/dax.c
>> @@ -590,7 +590,7 @@ static int dax_dev_huge_fault(struct vm_fault *vmf,
>>               rc = __dax_dev_pud_fault(dax_dev, vmf);
>>               break;
>>       default:
>> -             rc =  VM_FAULT_FALLBACK;
>> +             rc = VM_FAULT_SIGBUS;
>>       }
>>       rcu_read_unlock();
>
> The change seems to make sense but more info would be helpful.  What
> is wrong with the current code?  ie, what goes wrong if we return
> VM_FAULT_FALLBACK here?

Hi Andrew, I took these two patches into my for-4.12/dax branch with
the following fixed up changelog:

commit 17756a4c681c320712798b783eb40006de9b4cc3
Author: Pushkar Jambhlekar <pushkar.iit@gmail.com>
Date:   Tue Apr 11 09:12:25 2017 -0700

    device-dax: fix dax_dev_huge_fault() unknown fault size handling

    The default case for dax_dev_huge_fault() fault size handling mistakenly
    returns when it should unlock. This is not a problem in practice since
    the only three possible fault sizes are handled. Going forward, if the
    core mm adds a new fault size beyond pte, pmd, or pud device-dax should
    abort VM_FAULT_SIGBUS requests not VM_FAULT_FALLBACK since device-dax
    guarantees a configured fault granularity for all faults.

    Signed-off-by: Pushkar Jambhlekar <pushkar.iit@gmail.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index 19795eb35579..94036d92ed16 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -591,7 +591,7 @@ static int dax_dev_huge_fault(struct vm_fault *vmf,
                rc = __dax_dev_pud_fault(dax_dev, vmf);
                break;
        default:
-               return VM_FAULT_FALLBACK;
+               rc = VM_FAULT_SIGBUS;
        }
        srcu_read_unlock(&dax_srcu, id);

[toc] | [prev] | [next] | [standalone]

#1621442

FromDan Williams <dan.j.williams@intel.com>
Date2017-04-11 18:20 +0200
Message-ID<tv6Gl-QX-1@gated-at.bofh.it>
In reply to#1620916
On Mon, Apr 10, 2017 at 10:26 PM, Pushkar Jambhlekar
<pushkar.iit@gmail.com> wrote:
> dax_dev_huge_fault returning without releasing lock. Making code change to avoid this situation
>
> Signed-off-by: Pushkar Jambhlekar <pushkar.iit@gmail.com>
> ---
>  drivers/dax/dax.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
> index 0d1ca24..fd9c4db 100644
> --- a/drivers/dax/dax.c
> +++ b/drivers/dax/dax.c
> @@ -590,7 +590,7 @@ static int dax_dev_huge_fault(struct vm_fault *vmf,
>                 rc = __dax_dev_pud_fault(dax_dev, vmf);
>                 break;
>         default:
> -               return VM_FAULT_FALLBACK;
> +               rc = VM_FAULT_FALLBACK;
>         }
>         rcu_read_unlock();

Thanks Pushkar, I'll apply this and combine with patch 2 as well.

[toc] | [prev] | [next] | [standalone]

#1621772

FromPushkar Jambhlekar <pushkar.iit@gmail.com>
Date2017-04-12 06:20 +0200
Message-ID<tvhV7-8fa-3@gated-at.bofh.it>
In reply to#1621442
Thanks Dan!

On Tue, Apr 11, 2017 at 9:47 PM, Dan Williams <dan.j.williams@intel.com> wrote:
> On Mon, Apr 10, 2017 at 10:26 PM, Pushkar Jambhlekar
> <pushkar.iit@gmail.com> wrote:
>> dax_dev_huge_fault returning without releasing lock. Making code change to avoid this situation
>>
>> Signed-off-by: Pushkar Jambhlekar <pushkar.iit@gmail.com>
>> ---
>>  drivers/dax/dax.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
>> index 0d1ca24..fd9c4db 100644
>> --- a/drivers/dax/dax.c
>> +++ b/drivers/dax/dax.c
>> @@ -590,7 +590,7 @@ static int dax_dev_huge_fault(struct vm_fault *vmf,
>>                 rc = __dax_dev_pud_fault(dax_dev, vmf);
>>                 break;
>>         default:
>> -               return VM_FAULT_FALLBACK;
>> +               rc = VM_FAULT_FALLBACK;
>>         }
>>         rcu_read_unlock();
>
> Thanks Pushkar, I'll apply this and combine with patch 2 as well.



-- 
Jambhlekar Pushkar Arun

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web