On Wed 10-07-19 20:35:55, Matthew Wilcox wrote:
On Wed, Jul 10, 2019 at 09:02:04PM +0200, Jan Kara wrote:
So how about the attached patch? That keeps the interface sane and passes a smoketest for me (full fstest run running). Obviously it also needs a proper changelog...
Changelog and slightly massaged version along the lines of my two comments attached.
From 57b63fdd38e7bea7eb8d6332f0163fb028570def Mon Sep 17 00:00:00 2001 From: "Matthew Wilcox (Oracle)" willy@infradead.org Date: Wed, 3 Jul 2019 23:21:25 -0400 Subject: [PATCH] dax: Fix missed wakeup with PMD faults
RocksDB can hang indefinitely when using a DAX file. This is due to a bug in the XArray conversion when handling a PMD fault and finding a PTE entry. We use the wrong index in the hash and end up waiting on the wrong waitqueue.
There's actually no need to wait; if we find a PTE entry while looking for a PMD entry, we can return immediately as we know we should fall back to a PTE fault (which may not conflict with the lock held).
Cc: stable@vger.kernel.org Fixes: b15cd800682f ("dax: Convert page fault handlers to XArray") Signed-off-by: Matthew Wilcox (Oracle) willy@infradead.org
Just one nit below. Otherwise feel free to add:
Reviewed-by: Jan Kara jack@suse.cz
diff --git a/include/linux/xarray.h b/include/linux/xarray.h index 052e06ff4c36..fb25452bcfa4 100644 --- a/include/linux/xarray.h +++ b/include/linux/xarray.h @@ -169,7 +169,9 @@ static inline bool xa_is_internal(const void *entry) return ((unsigned long)entry & 3) == 2; } +#define XA_RETRY_ENTRY xa_mk_internal(256) #define XA_ZERO_ENTRY xa_mk_internal(257) +#define XA_DAX_CONFLICT_ENTRY xa_mk_internal(258) /**
- xa_is_zero() - Is the entry a zero entry?
As I wrote in my previous email, won't it be nicer if we just defined DAX_CONFLICT_ENTRY (or however we name it) inside dax code say to XA_ZERO_ENTRY? Generic xarray code just doesn't care about that value and I can imagine in future there'll be other xarray user's who'd like to have some special value(s) for use similarly to DAX and we don't want to clutter xarray definitions with those as well. If you don't like XA_ZERO_ENTRY, I could also imagine having XA_USER_RESERVED value that's guaranteed to be unused by xarray and we'd define DAX_CONFLICT_ENTRY to it. Overall I don't care too much so I can live even with what you have now but it would seem cleaner that way to me.
Honza