linux-kernel - Re: [PATCH v7 07/22] Replace the XIP page fault handler with the DAX page fault handler

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140811085147.GB29526@quack.suse.cz>
Date:	Mon, 11 Aug 2014 10:51:47 +0200
From:	Jan Kara <jack@...e.cz>
To:	Matthew Wilcox <willy@...ux.intel.com>
Cc:	Jan Kara <jack@...e.cz>,
	Matthew Wilcox <matthew.r.wilcox@...el.com>,
	linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 07/22] Replace the XIP page fault handler with the DAX
 page fault handler

On Sat 09-08-14 07:00:00, Matthew Wilcox wrote:
> On Wed, Jul 30, 2014 at 11:52:29AM +0200, Jan Kara wrote:
> >   I see the problem now. How about an attached patch? Do you see other
> > lockdep warnings with it?
> 
> Hit another one :-(  Same inversion between i_mmap_mutex and jbd2_handle:
> 
>  -> #1 (&mapping->i_mmap_mutex){+.+...}:
>         [<ffffffff810cfa12>] lock_acquire+0xb2/0x1f0
>         [<ffffffff815cb5e5>] mutex_lock_nested+0x75/0x420
>         [<ffffffff811bc0ff>] rmap_walk+0x6f/0x390
>         [<ffffffff811bc5a9>] page_mkclean+0x69/0x90
>         [<ffffffff81189c10>] clear_page_dirty_for_io+0x60/0x120
>         [<ffffffffa01d1017>] mpage_submit_page+0x47/0x80 [ext4]
>         [<ffffffffa01d1160>] mpage_process_page_bufs+0x110/0x120 [ext4]
>         [<ffffffffa01d16f0>] mpage_prepare_extent_to_map+0x1f0/0x2f0 [ext4]
>         [<ffffffffa01d6e57>] ext4_writepages+0x427/0x1060 [ext4]
>         [<ffffffff8118c211>] do_writepages+0x21/0x40
>         [<ffffffff8117e909>] __filemap_fdatawrite_range+0x59/0x60
>         [<ffffffff8117ea0d>] filemap_write_and_wait_range+0x2d/0x70
>         [<ffffffffa01cd7d8>] ext4_sync_file+0x118/0x490 [ext4]
>         [<ffffffff8122dd2b>] vfs_fsync_range+0x1b/0x30
>         [<ffffffff811b99ad>] SyS_msync+0x1ed/0x250
> 
> (ext4_writepages starts a transaction before calling
> mpage_prepare_extent_to_map)
  Hum, yes, this is difficult. Getting rid of
clear_page_dirty_for_io() when the transaction is started isn't easily
possible :(. So I'm afraid we'll have to find some other way to synchronize
page faults and truncate / punch hole in DAX.

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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/