[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPcyv4h5mxgYOE655Nb4a8tofN_-mkNPKLFtz6ES5oTbnFqucg@mail.gmail.com>
Date: Tue, 11 Apr 2017 09:17:05 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Pushkar Jambhlekar <pushkar.iit@...il.com>
Cc: Dave Jiang <dave.jiang@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Johannes Thumshirn <jthumshirn@...e.de>,
Ross Zwisler <ross.zwisler@...ux.intel.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] drivers/dax: Avoiding potential deadlock
On Mon, Apr 10, 2017 at 10:26 PM, Pushkar Jambhlekar
<pushkar.iit@...il.com> wrote:
> dax_dev_huge_fault returning without releasing lock. Making code change to avoid this situation
>
> Signed-off-by: Pushkar Jambhlekar <pushkar.iit@...il.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.
Powered by blists - more mailing lists