lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 3 Oct 2015 23:24:33 -0600 From: Ross Zwisler <ross.zwisler@...ux.intel.com> To: Ross Zwisler <ross.zwisler@...ux.intel.com> Cc: linux-kernel@...r.kernel.org, Alexander Viro <viro@...iv.linux.org.uk>, Matthew Wilcox <willy@...ux.intel.com>, linux-fsdevel@...r.kernel.org, linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>, Dan Williams <dan.j.williams@...el.com>, Dave Chinner <david@...morbit.com>, Jan Kara <jack@...e.com>, "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, linux-nvdimm@...ts.01.org Subject: Re: [PATCH v2 0/2] Revert locking changes in DAX for v4.3 On Fri, Oct 02, 2015 at 06:01:32PM -0600, Ross Zwisler wrote: > This series reverts some recent changes to the locking scheme in DAX introduced > by these two commits: > > commit 843172978bb9 ("dax: fix race between simultaneous faults") > commit 46c043ede471 ("mm: take i_mmap_lock in unmap_mapping_range() for DAX") > > Changes from v1: > - Squashed patches 1 and 2 from the first series into a single patch to avoid > adding another spot in the git history where we could end up referencing an > uninitialized pointer. > > Ross Zwisler (2): > Revert "mm: take i_mmap_lock in unmap_mapping_range() for DAX" > Revert "dax: fix race between simultaneous faults" > > fs/dax.c | 83 +++++++++++++++++++++++++------------------------------------ > mm/memory.c | 2 ++ > 2 files changed, 36 insertions(+), 49 deletions(-) > > -- > 2.1.0 *sigh* - even after these reverts we can deadlock on in the DAX PMD code with its original locking scheme. I can hit them 100% of the time with either generic/074 or generic/198 using either XFS or ext4. I'll debug exactly what's going on on Monday. The quick and easy workaround for this is to do a "return VM_FAULT_FALLBACK;" at the beginning of __dax_pmd_fault() to just turn off PMD faults while we rework the locking for v4.4. This saves us reverting and re-adding all the PMD code, and will let us ship v4.3 without known deadlocks. Other better ideas? - Ross -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists