Re: [f2fs-dev] [PATCH v14 00/74] Convert page cache to XArray
On Wed, Jul 25, 2018 at 02:03:23PM -0700, Matthew Wilcox wrote: > On Wed, Jun 27, 2018 at 01:44:38PM -0600, Ross Zwisler wrote: > > On Wed, Jun 27, 2018 at 04:05:29AM -0700, Matthew Wilcox wrote: > > > On Tue, Jun 19, 2018 at 10:16:38AM -0700, Matthew Wilcox wrote: > > > > I think I see a bug. No idea if it's the one you're hitting ;-) > > > > > > > > I had been intending to not use the 'entry' to decide whether we were > > > > waiting on a 2MB or 4kB page, but rather the xas. I shelved that idea, > > > > but not before dropping the DAX_PMD flag being passed from the PMD > > > > pagefault caller. So if I put that back ... > > > > > > Did you get a chance to test this? > > > > With this patch it doesn't deadlock, but the test dies with a SIGBUS and we > > hit a WARN_ON in the DAX code: > > > > WARNING: CPU: 5 PID: 1678 at fs/dax.c:226 get_unlocked_entry+0xf7/0x120 > > > > I don't have a lot of time this week to debug further. The quickest path to > > victory is probably for you to get this reproducing in your test setup. > > Does > > XFS + DAX + generic/340 pass for you? > > I now have generic/340 passing. I've pushed a new version to > git://git.infradead.org/users/willy/linux-dax.git xarray Okay, the next failure I'm hitting is with DAX + XFS + generic/344. It doesn't happen every time, but I can usually recreate it within 10 iterations of the test. Here's the failure: generic/344 21s ...[ 1852.564559] run fstests generic/344 at 2018-07-27 11:19:05 [ 1853.033177] XFS (pmem0p2): Unmounting Filesystem [ 1853.134497] XFS (pmem0p2): DAX enabled. Warning: EXPERIMENTAL, use at your own risk [ 1853.135335] XFS (pmem0p2): Mounting V5 Filesystem [ 1853.138119] XFS (pmem0p2): Ending clean mount [ 1862.251185] WARNING: CPU: 10 PID: 15695 at mm/memory.c:1801 insert_pfn+0x229/0x240 [ 1862.252023] Modules linked in: dax_pmem device_dax nd_pmem nd_btt nfit libnvdimm [ 1862.252853] CPU: 10 PID: 15695 Comm: holetest Tainted: GW 4.18.0-rc6-00077-gc79b37ebab6d-dirty #1 [ 1862.253979] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 04/01/2014 [ 1862.255232] RIP: 0010:insert_pfn+0x229/0x240 [ 1862.255734] Code: 21 fa 4c 89 4d b0 48 89 45 c0 c6 05 3c 47 74 01 01 e8 db c2 e2 ff 0f 0b 44 8b 45 ac 4c 8b 4d b0 4c 8b 55 b8 48 8b 45 c0 eb 92 <0f> 0b e9 45 fe ff ff 41 bf f4 ff ff ff e9 43 fe ff ff e8 50 c5 e2 [ 1862.257526] RSP: :c9000e197af8 EFLAGS: 00010216 [ 1862.257994] RAX: 2df7 RBX: 8800368ffe00 RCX: 0002 [ 1862.258673] RDX: 000f RSI: 000a RDI: 82df7225 [ 1862.259319] RBP: c9000e197b50 R08: 0001 R09: 8800b8fecd48 [ 1862.260097] R10: c9000e197a30 R11: 88010d649a80 R12: 8800bb616e80 [ 1862.260843] R13: 7fc2137c R14: 004521d4 R15: fff0 [ 1862.261563] FS: 7fc2157ff700() GS:88011580() knlGS: [ 1862.262420] CS: 0010 DS: ES: CR0: 80050033 [ 1862.263003] CR2: 7fc2137c0c00 CR3: b866e000 CR4: 06e0 [ 1862.263631] Call Trace: [ 1862.263862] ? trace_hardirqs_on_caller+0xf4/0x190 [ 1862.264300] __vm_insert_mixed+0x83/0xd0 [ 1862.264657] vmf_insert_mixed_mkwrite+0x13/0x40 [ 1862.265066] dax_iomap_pte_fault+0x760/0x1140 [ 1862.265478] dax_iomap_fault+0x37/0x40 [ 1862.265816] __xfs_filemap_fault+0x2de/0x310 [ 1862.266207] xfs_filemap_page_mkwrite+0x15/0x20 [ 1862.266610] xfs_filemap_pfn_mkwrite+0xe/0x10 [ 1862.267044] do_wp_page+0x1bb/0x660 [ 1862.267435] __handle_mm_fault+0xc78/0x1320 [ 1862.267912] handle_mm_fault+0x1ba/0x3c0 [ 1862.268359] __do_page_fault+0x2b4/0x590 [ 1862.268799] do_page_fault+0x38/0x2c0 [ 1862.269218] do_async_page_fault+0x2c/0xb0 [ 1862.269674] ? async_page_fault+0x8/0x30 [ 1862.270081] async_page_fault+0x1e/0x30 [ 1862.270431] RIP: 0033:0x401442 [ 1862.270709] Code: 1d 20 00 85 f6 0f 85 7d 00 00 00 48 85 db 7e 20 4b 8d 04 34 31 d2 66 90 48 8b 0d 21 1d 20 00 48 0f af ca 48 83 c2 01 48 39 d3 <48> 89 2c 08 75 e8 8b 0d de 1c 20 00 31 c0 85 c9 74 0a 8b 15 d6 1c [ 1862.272811] RSP: 002b:7fc2157feec0 EFLAGS: 00010216 [ 1862.273392] RAX: 7fc213600c00 RBX: 1000 RCX: 001c [ 1862.274182] RDX: 01c1 RSI: RDI: 0001 [ 1862.274961] RBP: 7fc2157ff700 R08: 7fc2157ff700 R09: 7fc2157ff700 [ 1862.275740] R10: 7fc2157ff9d0 R11: 0202 R12: 7fc21360 [ 1862.276519] R13: 7ffe07faa240 R14: 0c00 R15: 7ffe07faa170 [ 1862.277296] irq event stamp: 13256 [ 1862.277666] hardirqs last enabled at (13255): [] _raw_spin_unlock_irq+0x2c/0x60 [ 1862.278630] hard
Re: [f2fs-dev] [PATCH v14 00/74] Convert page cache to XArray
On Wed, Jul 25, 2018 at 02:03:23PM -0700, Matthew Wilcox wrote: > On Wed, Jun 27, 2018 at 01:44:38PM -0600, Ross Zwisler wrote: > > On Wed, Jun 27, 2018 at 04:05:29AM -0700, Matthew Wilcox wrote: > > > On Tue, Jun 19, 2018 at 10:16:38AM -0700, Matthew Wilcox wrote: > > > > I think I see a bug. No idea if it's the one you're hitting ;-) > > > > > > > > I had been intending to not use the 'entry' to decide whether we were > > > > waiting on a 2MB or 4kB page, but rather the xas. I shelved that idea, > > > > but not before dropping the DAX_PMD flag being passed from the PMD > > > > pagefault caller. So if I put that back ... > > > > > > Did you get a chance to test this? > > > > With this patch it doesn't deadlock, but the test dies with a SIGBUS and we > > hit a WARN_ON in the DAX code: > > > > WARNING: CPU: 5 PID: 1678 at fs/dax.c:226 get_unlocked_entry+0xf7/0x120 > > > > I don't have a lot of time this week to debug further. The quickest path to > > victory is probably for you to get this reproducing in your test setup. > > Does > > XFS + DAX + generic/340 pass for you? > > I now have generic/340 passing. I've pushed a new version to > git://git.infradead.org/users/willy/linux-dax.git xarray Thanks, I'll throw it in my test setup. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v14 68/74] dax: Convert dax_lock_page to XArray
On Sat, Jun 16, 2018 at 07:00:46PM -0700, Matthew Wilcox wrote:
> Signed-off-by: Matthew Wilcox
> ---
<>
> +static void *dax_make_page_entry(struct page *page, void *entry)
> +{
> + pfn_t pfn = page_to_pfn_t(page);
> + return dax_make_entry(pfn, dax_is_pmd_entry(entry));
> +}
This function is defined and never used, so we get:
fs/dax.c:106:14: warning: ‘dax_make_page_entry’ defined but not used
[-Wunused-function]
static void *dax_make_page_entry(struct page *page, void *entry)
^~~
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v14 00/74] Convert page cache to XArray
On Thu, Jun 28, 2018 at 01:39:09AM -0700, Matthew Wilcox wrote: > On Wed, Jun 27, 2018 at 01:44:38PM -0600, Ross Zwisler wrote: > > On Wed, Jun 27, 2018 at 04:05:29AM -0700, Matthew Wilcox wrote: > > > On Tue, Jun 19, 2018 at 10:16:38AM -0700, Matthew Wilcox wrote: > > > > I think I see a bug. No idea if it's the one you're hitting ;-) > > > > > > > > I had been intending to not use the 'entry' to decide whether we were > > > > waiting on a 2MB or 4kB page, but rather the xas. I shelved that idea, > > > > but not before dropping the DAX_PMD flag being passed from the PMD > > > > pagefault caller. So if I put that back ... > > > > > > Did you get a chance to test this? > > > > With this patch it doesn't deadlock, but the test dies with a SIGBUS and we > > hit a WARN_ON in the DAX code: > > > > WARNING: CPU: 5 PID: 1678 at fs/dax.c:226 get_unlocked_entry+0xf7/0x120 > > > > I don't have a lot of time this week to debug further. The quickest path to > > victory is probably for you to get this reproducing in your test setup. > > Does > > XFS + DAX + generic/340 pass for you? > > I won't be back in front of my test box until Tuesday, but that test > does work for me because I couldn't get your instructions to give me a > 2MB aligned DAX setup. I had to settle for 4k, so none of the 2MB stuff > has been tested properly. Ah. I've documented both my qemu setup and my filesystem setup here: https://nvdimm.wiki.kernel.org/pmem_in_qemu https://nvdimm.wiki.kernel.org/2mib_fs_dax This should be enough to get you up and running in QEMU and able to reliably get filesystem DAX PMD faults. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v14 00/74] Convert page cache to XArray
On Wed, Jun 27, 2018 at 04:05:29AM -0700, Matthew Wilcox wrote: > On Tue, Jun 19, 2018 at 10:16:38AM -0700, Matthew Wilcox wrote: > > I think I see a bug. No idea if it's the one you're hitting ;-) > > > > I had been intending to not use the 'entry' to decide whether we were > > waiting on a 2MB or 4kB page, but rather the xas. I shelved that idea, > > but not before dropping the DAX_PMD flag being passed from the PMD > > pagefault caller. So if I put that back ... > > Did you get a chance to test this? With this patch it doesn't deadlock, but the test dies with a SIGBUS and we hit a WARN_ON in the DAX code: WARNING: CPU: 5 PID: 1678 at fs/dax.c:226 get_unlocked_entry+0xf7/0x120 I don't have a lot of time this week to debug further. The quickest path to victory is probably for you to get this reproducing in your test setup. Does XFS + DAX + generic/340 pass for you? -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v14 00/74] Convert page cache to XArray
On Tue, Jun 19, 2018 at 02:22:30AM -0700, Matthew Wilcox wrote: > On Mon, Jun 18, 2018 at 09:12:57PM -0600, Ross Zwisler wrote: > > Hit another deadlock. This one reproduces 100% of the time in my setup with > > XFS + DAX + generic/340. It doesn't reproduce for me at all with > > next-20180615. Here's the output from "echo w > /proc/sysrq-trigger": > > *sigh*. I wonder what the differences are between our setups ... > > > [ 92.849119] sysrq: SysRq : Show Blocked State > > [ 92.850506] taskPC stack pid father > > [ 92.852299] holetestD0 1651 1466 0x > > [ 92.853912] Call Trace: > > [ 92.854610] __schedule+0x2c5/0xad0 > > [ 92.855612] schedule+0x36/0x90 > > [ 92.856602] get_unlocked_entry+0xce/0x120 > > [ 92.857756] ? dax_insert_entry+0x2b0/0x2b0 > > [ 92.858931] grab_mapping_entry+0x19e/0x250 > > [ 92.860119] dax_iomap_pte_fault+0x115/0x1140 > > [ 92.860836] dax_iomap_fault+0x37/0x40 > ... > > This looks very similar to the one I reported last week with generic/269. > > Yeah, another missing wakeup, no doubt. Can you bisect this? That was > how I found the last one; bisected it to a single patch and stared very > hard at the patch until I saw it. I'm not going to be in a position to > tinker with my DAX setup until the first week of July. It bisected to this commit: b4b4daa7e8fb0ad0fee35d3e28d00e97c849a6cb is the first bad commit commit b4b4daa7e8fb0ad0fee35d3e28d00e97c849a6cb Author: Matthew Wilcox Date: Thu Mar 29 22:58:27 2018 -0400 dax: Convert page fault handlers to XArray This is the last part of DAX to be converted to the XArray so remove all the old helper functions. Signed-off-by: Matthew Wilcox -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v14 00/74] Convert page cache to XArray
On Sat, Jun 16, 2018 at 06:59:38PM -0700, Matthew Wilcox wrote: > The XArray is a replacement for the radix tree. For the moment it uses > the same data structures, enabling a gradual replacement. This patch > set implements the XArray and converts the page cache to use it. > > A version of these patches has been running under xfstests for over > 48 hours, so I have some confidence in them. The DAX changes have now > also had a reasonable test outing. This is based on next-20180615 and > is available as a git tree at > git://git.infradead.org/users/willy/linux-dax.git xarray-20180615 > > I shall create a git branch from -rc1 and ask for that to be included in > -next. I'm a little concerned I still have no reviews on some of the > later patches. > > Changes since v13: > - Actually fixed bug in workingset conversion that led to exceptional >entries not being deleted from the XArray. Not sure how I dropped >that patch for v13. Thanks to David Sterba for noticing. > - Fixed bug in DAX writeback conversion that failed to wake up waiters. >Thanks to Ross for testing, and to Dan & Jeff for helping me get a >setup working to reproduce the problem. > - Converted the new dax_lock_page / dax_unlock_page functions. > - Moved XArray test suite entirely into the test_xarray kernel module >to match other test suites. It can still be built in userspace as >part of the radix tree test suite. > - Changed email address. > - Moved a few functions into different patches to make the test-suite >additions more logical. > - Fixed a bug in XA_BUG_ON (oh the irony) where it evaluated the >condition twice. > - Constified xa_head() / xa_parent() / xa_entry() and their _locked >variants. > - Moved xa_parent() to xarray.h so it can be used from the workingset code. > - Call the xarray testsuite from the radix tree test suite to ensure >that I remember to run both test suites ;-) > - Added some more tests to the test suite. Hit another deadlock. This one reproduces 100% of the time in my setup with XFS + DAX + generic/340. It doesn't reproduce for me at all with next-20180615. Here's the output from "echo w > /proc/sysrq-trigger": [ 92.849119] sysrq: SysRq : Show Blocked State [ 92.850506] taskPC stack pid father [ 92.852299] holetestD0 1651 1466 0x [ 92.853912] Call Trace: [ 92.854610] __schedule+0x2c5/0xad0 [ 92.855612] schedule+0x36/0x90 [ 92.856602] get_unlocked_entry+0xce/0x120 [ 92.857756] ? dax_insert_entry+0x2b0/0x2b0 [ 92.858931] grab_mapping_entry+0x19e/0x250 [ 92.860119] dax_iomap_pte_fault+0x115/0x1140 [ 92.860836] dax_iomap_fault+0x37/0x40 [ 92.861235] __xfs_filemap_fault+0x2de/0x310 [ 92.861681] xfs_filemap_fault+0x2c/0x30 [ 92.862113] __do_fault+0x26/0x160 [ 92.862531] __handle_mm_fault+0xc96/0x1320 [ 92.863059] handle_mm_fault+0x1ba/0x3c0 [ 92.863534] __do_page_fault+0x2b4/0x590 [ 92.864029] do_page_fault+0x38/0x2c0 [ 92.864472] do_async_page_fault+0x2c/0xb0 [ 92.864985] ? async_page_fault+0x8/0x30 [ 92.865459] async_page_fault+0x1e/0x30 [ 92.865941] RIP: 0033:0x401442 [ 92.866322] Code: Bad RIP value. [ 92.866739] RSP: 002b:7fa29c9feec0 EFLAGS: 00010212 [ 92.867366] RAX: 7fa29ca00400 RBX: 1000 RCX: 8000 [ 92.868219] RDX: 0009 RSI: RDI: [ 92.869082] RBP: 7fa29c9ff700 R08: 7fa29c9ff700 R09: 7fa29c9ff700 [ 92.869939] R10: 0070 R11: 7fa29e571ba0 R12: 7fa29ca0 [ 92.870804] R13: 7fffd5f24160 R14: 0400 R15: 7fffd5f240b0 This looks very similar to the one I reported last week with generic/269. - Ross -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v13 00/72] Convert page cache to XArray
On Tue, Jun 12, 2018 at 12:46:19PM -0700, Matthew Wilcox wrote: > On Tue, Jun 12, 2018 at 01:37:41PM -0600, Ross Zwisler wrote: > > On Tue, Jun 12, 2018 at 04:31:22AM -0700, Matthew Wilcox wrote: > > > On Tue, Jun 12, 2018 at 12:40:41PM +0200, David Sterba wrote: > > > > [ 9875.174796] kernel BUG at fs/inode.c:513! > > > > > > What the ... > > > > > > Somehow the fix for that got dropped. I spent most of last week chasing > > > that problem! This is the correct code: > > > > > > http://git.infradead.org/users/willy/linux-dax.git/commitdiff/01177bb06761539af8a6c872416109e2c8b64559 > > > > > > I'll check over the patchset and see if anything else got dropped! > > > > Can you please repost when you have this sorted? > > > > I think the commit you've pointed to is in your xarray-20180601 branch, but > > I > > see two more recent xarray branches in your tree (xarray-20180608 and > > xarray-20180612). > > > > Basically, I don't know what is stable and what's not, and what I should be > > reviewing/testing. > > Yup, I shall. The xarray-20180612 is the most recent thing I've > published, but I'm still going over the 0601 patchset looking for other > little pieces I may have dropped. I've found a couple, and I'm updating > the 0612 branch each time I find another one. > > If you want to start looking at the DAX patches on the 0612 branch, > that wouldn't be a waste of your time. Neither would testing; I don't > think I dropped anything from the DAX patches. I tested xarray-20180612 vs next-20180612, and your patches cause a new deadlock with XFS + DAX + generic/269. Here's the output from "echo w > /proc/sysrq-trigger": [ 302.520590] sysrq: SysRq : Show Blocked State [ 302.521431] taskPC stack pid father [ 302.522419] fsstressD0 1703 1660 0x0004 [ 302.523238] Call Trace: [ 302.523634] __schedule+0x2c5/0xad0 [ 302.524116] schedule+0x36/0x90 [ 302.524572] get_unlocked_entry+0xce/0x120 [ 302.525160] ? dax_insert_entry+0x2a0/0x2a0 [ 302.525859] grab_mapping_entry+0x1c4/0x240 [ 302.526515] dax_iomap_pte_fault+0x115/0x1140 [ 302.527181] dax_iomap_fault+0x37/0x40 [ 302.527697] __xfs_filemap_fault+0x2de/0x310 [ 302.528241] xfs_filemap_fault+0x2c/0x30 [ 302.528828] __do_fault+0x26/0x160 [ 302.529280] __handle_mm_fault+0xc96/0x1320 [ 302.529933] handle_mm_fault+0x1ba/0x3c0 [ 302.530560] __do_page_fault+0x2b4/0x590 [ 302.531105] do_page_fault+0x38/0x2c0 [ 302.531693] do_async_page_fault+0x2c/0xb0 [ 302.532274] ? async_page_fault+0x8/0x30 [ 302.532875] async_page_fault+0x1e/0x30 [ 302.533479] RIP: 0033:0x7f0224141c96 [ 302.533966] Code: Bad RIP value. [ 302.534482] RSP: 002b:7ffdcc5a5398 EFLAGS: 00010202 [ 302.535217] RAX: 7f0224c9b000 RBX: 000bf000 RCX: 7f0224c9b040 [ 302.536335] RDX: 2f94 RSI: 0096 RDI: 7f0224c9b000 [ 302.537339] RBP: 1dcd6500 R08: 0003 R09: 000bf000 [ 302.538524] R10: 0008 R11: 0246 R12: 51eb851f [ 302.539708] R13: 0040ab80 R14: 2f94 R15: [ 302.540875] fsstressD0 1764 1660 0x0004 [ 302.541680] Call Trace: [ 302.542061] __schedule+0x2c5/0xad0 [ 302.542619] schedule+0x36/0x90 [ 302.543091] get_unlocked_entry+0xce/0x120 [ 302.543763] ? dax_insert_entry+0x2a0/0x2a0 [ 302.544420] __dax_invalidate_entry+0x65/0x120 [ 302.545095] dax_delete_mapping_entry+0x13/0x20 [ 302.545654] truncate_exceptional_pvec_entries.part.15+0x215/0x220 [ 302.546520] truncate_inode_pages_range+0x2b4/0x9d0 [ 302.547277] ? up_write+0x1f/0x90 [ 302.547816] ? unmap_mapping_pages+0x62/0x130 [ 302.548535] truncate_pagecache+0x48/0x70 [ 302.549156] truncate_setsize+0x32/0x40 [ 302.549775] xfs_setattr_size+0x167/0x530 [ 302.550398] xfs_vn_setattr_size+0x57/0x170 [ 302.551013] xfs_ioc_space+0x2c6/0x3a0 [ 302.551621] ? __might_fault+0x85/0x90 [ 302.552195] xfs_file_ioctl+0xcac/0xdf0 [ 302.552856] ? __might_sleep+0x4a/0x80 [ 302.553464] ? selinux_file_ioctl+0x131/0x1f0 [ 302.554168] do_vfs_ioctl+0xa9/0x6d0 [ 302.554815] ksys_ioctl+0x75/0x80 [ 302.555365] __x64_sys_ioctl+0x1a/0x20 [ 302.555962] do_syscall_64+0x65/0x220 [ 302.556603] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 302.557341] RIP: 0033:0x7f022418e0f7 [ 302.557916] Code: Bad RIP value. [ 302.558487] RSP: 002b:7ffdcc5a5468 EFLAGS: 0246 ORIG_RAX: 0010 [ 302.559734] RAX: ffda RBX: 0541 RCX: 7f022418e0f7 [ 302.560825] RDX: 7ffdcc5a5490 RSI: 40305824 RDI: 0003 [ 302.561882] RBP: 0003 R08: 0074 R09: 7
Re: [f2fs-dev] [PATCH v13 00/72] Convert page cache to XArray
On Tue, Jun 12, 2018 at 04:31:22AM -0700, Matthew Wilcox wrote: > On Tue, Jun 12, 2018 at 12:40:41PM +0200, David Sterba wrote: > > [ 9875.174796] kernel BUG at fs/inode.c:513! > > What the ... > > Somehow the fix for that got dropped. I spent most of last week chasing > that problem! This is the correct code: > > http://git.infradead.org/users/willy/linux-dax.git/commitdiff/01177bb06761539af8a6c872416109e2c8b64559 > > I'll check over the patchset and see if anything else got dropped! Can you please repost when you have this sorted? I think the commit you've pointed to is in your xarray-20180601 branch, but I see two more recent xarray branches in your tree (xarray-20180608 and xarray-20180612). Basically, I don't know what is stable and what's not, and what I should be reviewing/testing. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v11 00/63] Convert page cache to XArray
On Thu, May 31, 2018 at 02:46:12PM -0700, Matthew Wilcox wrote: > On Thu, May 31, 2018 at 03:37:42PM -0600, Ross Zwisler wrote: > > Never mind, just saw your mail from a few weeks ago. :-/ I'll retest on my > > end. > > Don't strain too hard; I found (and fixed) some bugs in the DAX > conversion. I keep finding new bugs though -- the latest was that > xas_store(xas, NULL); doesn't work properly if xas is multiindex and some > of the covered entries are not NULL. And in fixing that, I noticed that > xas_store(xas, not-null) doesn't handle tagged entries correctly. > > I'd offer to push out the current version for testing but I've pulled > everything apart and nothing works right now ;-) I always think "it'll > be ready tomorrow", but I don't want to make a promise I can't keep. > > Here's my current changelog (may have forgotten a few things; need to > compare a diff once I've put together a decent patch series) > > - Reordered two DAX bugfixes to the head of the queue to allow them to >be merged independently. > - Converted apparmor secid to IDR > - Fixed bug in page cache lookup conversion which could lead to returning >pages which had been released from the page cache. > - Fixed several bugs in DAX conversion > - Re-added conversion of dax_layout_busy_page > - At Ross's request, renamed dax_mk_foo() to dax_make_foo(). > - Split out the radix tree test suite addition of ubsan. > - Split out radix tree code deletion. > - Removed __radix_tree_create from the public API > - Fixed up a couple of comments in DAX > - Renamed shmem_xa_replace() to shmem_replace_entry() > * Undid change of xas_load() behaviour with multislot xa_state > - Added xas_store_for_each() and use it in DAX > - Corrected some typos in the XArray kerneldoc. > - Fixed multi-index xas_store(xas, NULL) > - Fixed tag handling in multi-index xas_store(xas, not-null) Ah, okay. I'll retest & resume review once things settle down and you send out a new version. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v11 00/63] Convert page cache to XArray
On Thu, May 31, 2018 at 03:36:43PM -0600, Ross Zwisler wrote: > On Mon, Apr 16, 2018 at 10:01:33AM -0600, Ross Zwisler wrote: > > On Sat, Apr 14, 2018 at 07:12:13AM -0700, Matthew Wilcox wrote: > > > From: Matthew Wilcox > > > > > > This conversion keeps the radix tree and XArray data structures in sync > > > at all times. That allows us to convert the page cache one function at > > > a time and should allow for easier bisection. Other than renaming some > > > elements of the structures, the data structures are fundamentally > > > unchanged; a radix tree walk and an XArray walk will touch the same > > > number of cachelines. I have changes planned to the XArray data > > > structure, but those will happen in future patches. > > > > I've hit a few failures when throwing this into my test setup. The first > > two > > seem like similar bugs hit in two different ways, the third seems unique. > > I've verified that these don't seem to happen with the next-20180413 > > baseline. > > Hey Matthew, did you ever figure out these failures? Never mind, just saw your mail from a few weeks ago. :-/ I'll retest on my end. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v11 00/63] Convert page cache to XArray
On Mon, Apr 16, 2018 at 10:01:33AM -0600, Ross Zwisler wrote: > On Sat, Apr 14, 2018 at 07:12:13AM -0700, Matthew Wilcox wrote: > > From: Matthew Wilcox > > > > This conversion keeps the radix tree and XArray data structures in sync > > at all times. That allows us to convert the page cache one function at > > a time and should allow for easier bisection. Other than renaming some > > elements of the structures, the data structures are fundamentally > > unchanged; a radix tree walk and an XArray walk will touch the same > > number of cachelines. I have changes planned to the XArray data > > structure, but those will happen in future patches. > > I've hit a few failures when throwing this into my test setup. The first two > seem like similar bugs hit in two different ways, the third seems unique. > I've verified that these don't seem to happen with the next-20180413 baseline. Hey Matthew, did you ever figure out these failures? -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v11 53/63] dax: Rename some functions
On Mon, May 21, 2018 at 03:11:39AM -0700, Matthew Wilcox wrote: > On Sun, May 20, 2018 at 10:42:36PM -0600, Ross Zwisler wrote: > > > @@ -1519,15 +1517,14 @@ int dax_iomap_fault(struct vm_fault *vmf, enum > > > page_entry_size pe_size, > > > } > > > EXPORT_SYMBOL_GPL(dax_iomap_fault); > > > > > > -/** > > > +/* > > > > Let's leave the double ** so that the function is picked up properly by > > the documentation system, and so it's consistent with the rest of the > > functions. > > This function is static. I think it's worth keeping the documentation, > but making it part of the exported kernel API documentation is confusing. Ah, fair enough. > By the way, nothing at all in fs/dax.c is picked up by the documentation > system today. We should probably fix that ... did you want to look at it > or shall I propose a patch to anchor it somewhere? If you have time for it that would be awesome. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v11 54/63] dax: Hash on XArray instead of mapping
On Mon, May 21, 2018 at 03:25:24AM -0700, Matthew Wilcox wrote:
> On Sun, May 20, 2018 at 10:47:56PM -0600, Ross Zwisler wrote:
> > On Sat, Apr 14, 2018 at 07:13:07AM -0700, Matthew Wilcox wrote:
> > > From: Matthew Wilcox
> > >
> > > Since the XArray is embedded in the struct address_space, this contains
> > > exactly as much entropy as the address of the mapping.
> >
> > I agree that they both have the same amount of entropy, but what's the
> > benefit? It doesn't seem like this changes any behavior, fixes any bugs or
> > makes things any simpler?
>
> This is a preparatory patch for some of the changes later in the series.
> It has no benefit in and of itself; the benefit comes later when we
> switch from dax_wake_mapping_entry() to dax_wake_entry():
>
> static void dax_wake_entry(struct xa_state *xas, bool wake_all)
>
> This switch could be left until the end; I can introduce dax_wake_entry()
> without this change:
>
> +static void dax_wake_entry(struct xa_state *xas, bool wake_all)
> +{
> + struct address_space *mapping = container_of(xas->xa,
> + struct address_space, i_pages);
> + return dax_wake_mapping_entry_waiter(mapping, xas->xa_index, NULL,
> + wake_all);
> +}
>
> and then cut everybody over in the final step.
>
> Or I can just explain in the changelog that it's a preparatory step.
Sure, just a note in the changelog saying that it's a preparatory step would
be good enough for me.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v11 54/63] dax: Hash on XArray instead of mapping
On Sat, Apr 14, 2018 at 07:13:07AM -0700, Matthew Wilcox wrote: > From: Matthew Wilcox > > Since the XArray is embedded in the struct address_space, this contains > exactly as much entropy as the address of the mapping. I agree that they both have the same amount of entropy, but what's the benefit? It doesn't seem like this changes any behavior, fixes any bugs or makes things any simpler? -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v11 53/63] dax: Rename some functions
On Sat, Apr 14, 2018 at 07:13:06AM -0700, Matthew Wilcox wrote:
> From: Matthew Wilcox
>
> Remove mentions of 'radix' and 'radix tree'. Simplify some names by
> dropping the word 'mapping'.
>
> Signed-off-by: Matthew Wilcox
> @@ -74,18 +74,18 @@ fs_initcall(init_dax_wait_table);
> #define DAX_ZERO_PAGE(1UL << 2)
> #define DAX_EMPTY(1UL << 3)
>
> -static unsigned long dax_radix_pfn(void *entry)
> +static unsigned long dax_to_pfn(void *entry)
> {
> return xa_to_value(entry) >> DAX_SHIFT;
> }
>
> -static void *dax_radix_locked_entry(unsigned long pfn, unsigned long flags)
> +static void *dax_mk_locked(unsigned long pfn, unsigned long flags)
Let's continue to use whole words in function names instead of abbreviations
for readability. Can you please s/dax_mk_locked/dax_make_locked/ ?
I do realize that the xarray function is xa_mk_value() (which I also think is
perhaps too brief for readability), but in the rest of DAX we use full words
everywhere.
> @@ -1519,15 +1517,14 @@ int dax_iomap_fault(struct vm_fault *vmf, enum
> page_entry_size pe_size,
> }
> EXPORT_SYMBOL_GPL(dax_iomap_fault);
>
> -/**
> +/*
Let's leave the double ** so that the function is picked up properly by
the documentation system, and so it's consistent with the rest of the
functions.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v11 52/63] dax: dax_insert_mapping_entry always succeeds
On Sat, Apr 14, 2018 at 07:13:05AM -0700, Matthew Wilcox wrote: > From: Matthew Wilcox > > It does not return an error, so we don't need to check the return value > for IS_ERR(). > > Signed-off-by: Matthew Wilcox Yep, this looks correct to me. You can add: Reviewed-by: Ross Zwisler -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v11 51/63] dax: Fix use of zero page
On Sat, Apr 14, 2018 at 07:13:04AM -0700, Matthew Wilcox wrote: > From: Matthew Wilcox > > Use my_zero_pfn instead of ZERO_PAGE, and pass the vaddr to it so it > works on MIPS and s390. > > Signed-off-by: Matthew Wilcox Feel free to add my: Reviewed-by: Ross Zwisler To this version as well if you keep this patch in the larger series. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v11 00/63] Convert page cache to XArray
On Sat, Apr 14, 2018 at 07:12:13AM -0700, Matthew Wilcox wrote: > From: Matthew Wilcox > > This conversion keeps the radix tree and XArray data structures in sync > at all times. That allows us to convert the page cache one function at > a time and should allow for easier bisection. Other than renaming some > elements of the structures, the data structures are fundamentally > unchanged; a radix tree walk and an XArray walk will touch the same > number of cachelines. I have changes planned to the XArray data > structure, but those will happen in future patches. I've hit a few failures when throwing this into my test setup. The first two seem like similar bugs hit in two different ways, the third seems unique. I've verified that these don't seem to happen with the next-20180413 baseline. 1) Just run some parted commands in a loop: # while true; do > parted -s /dev/pmem0 mktable msdos > parted -s -a optimal /dev/pmem0 mkpart Primary 2MiB 12GiB > parted -s -a optimal /dev/pmem0 mkpart Primary 12GiB 16382MiB > done Within a few seconds I hit: page:ea0004293040 count:0 mapcount:0 mapping: index:0x0 flags: 0x2fffc1(locked) raw: 002fffc1 raw: dead0100 dead0200 page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) <= 0) [ cut here ] kernel BUG at ./include/linux/mm.h:853! invalid opcode: [#1] PREEMPT SMP PTI Modules linked in: dax_pmem device_dax nd_pmem nd_btt nfit libnvdimm CPU: 10 PID: 1539 Comm: systemd-udevd Not tainted 4.16.0-next-20180413-00063-gbbcfa4572878 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014 RIP: 0010:__add_to_page_cache_locked+0x34b/0x400 RSP: 0018:c90003427a58 EFLAGS: 00010246 RAX: 003e RBX: ea0004293040 RCX: 0001 RDX: RSI: RDI: RBP: c90003427ac8 R08: 001ff3fd4371 R09: R10: 0001 R11: R12: 88010cd82210 R13: R14: R15: c90003427ad8 FS: 7ff6e400c1c0() GS:88011580() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 55af28d0e390 CR3: 00010a64e000 CR4: 06e0 Call Trace: ? memcg_drain_all_list_lrus+0x260/0x260 add_to_page_cache_lru+0x4f/0xe0 mpage_readpages+0xde/0x1d0 ? check_disk_change+0x70/0x70 ? xa_load+0xbe/0x150 blkdev_readpages+0x1d/0x20 __do_page_cache_readahead+0x203/0x2f0 force_page_cache_readahead+0xb8/0x110 ? force_page_cache_readahead+0xb8/0x110 page_cache_sync_readahead+0x43/0x50 generic_file_read_iter+0x842/0xb70 blkdev_read_iter+0x35/0x40 __vfs_read+0xfe/0x170 vfs_read+0xa3/0x150 ksys_read+0x58/0xc0 __x64_sys_read+0x1a/0x20 do_syscall_64+0x65/0x220 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7ff6e3bf2d31 RSP: 002b:7ffc54c38a78 EFLAGS: 0246 ORIG_RAX: RAX: ffda RBX: 55af28cdb7c0 RCX: 7ff6e3bf2d31 RDX: 0004 RSI: 55af28de66d8 RDI: 000f RBP: R08: 55af28de66b0 R09: 7ff6e3bdd090 R10: R11: 0246 R12: 0004 R13: 55af28de66b0 R14: 55af28cdb810 R15: 55af28de66c8 Code: 88 fb 55 82 48 89 df e8 64 42 04 00 0f 0b 48 c7 c6 a8 fc 55 82 48 89 df e8 53 42 04 00 0f 0b 48 c7 c6 18 b5 52 82 e8 45 42 04 00 <0f> 0b 48 c1 f8 02 85 c0 0f 84 59 fe ff ff 45 85 ed 48 c7 43 08 RIP: __add_to_page_cache_locked+0x34b/0x400 RSP: c90003427a58 ---[ end trace 0a2ff3a36c6cabde ]--- 2) xfs + DAX + generic/095 A spew of this new message: Page cache invalidation failure on direct I/O. Possible data corruption due to collision with buffered I/O! Then a bug similar to the one hit with parted: BUG: Bad page state in process fio pfn:11e38c page:ea000478e300 count:0 mapcount:0 mapping: index:0x60 page:ea000478e300 count:0 mapcount:0 mapping: index:0x60 flags: 0x3fffc10068(uptodate|lru|active|mappedtodisk) raw: 003fffc10068 0060 raw: ea0004ed6220 88011a04d830 page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0) [ cut here ] kernel BUG at ./include/linux/mm.h:492! invalid opcode: [#1] PREEMPT SMP PTI Modules linked in: nd_pmem nd_btt dax_pmem device_dax nfit libnvdimm CPU: 5 PID: 599 Comm: systemd-journal Tainted: GW 4.16.0-next-20180413-00063-gbbcfa4572878 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014 RIP: 0010:release_pages+0x30e/0x3f0 RSP: 0018:c90001223a68 EFLAGS: 00010046 RAX: 003e RBX: ea000478e300 RCX: 0003 RDX: RSI: RDI: RBP: c90001223ae8 R08: R
Re: [f2fs-dev] [PATCH v4 00/73] XArray version 4
On Tue, Dec 05, 2017 at 04:40:46PM -0800, Matthew Wilcox wrote: > From: Matthew Wilcox > > I looked through some notes and decided this was version 4 of the XArray. > Last posted two weeks ago, this version includes a *lot* of changes. > I'd like to thank Dave Chinner for his feedback, encouragement and > distracting ideas for improvement, which I'll get to once this is merged. > > Highlights: > - Over 2000 words of documentation in patch 8! And lots more kernel-doc. > - The page cache is now fully converted to the XArray. > - Many more tests in the test-suite. > > This patch set is not for applying. 0day is still reporting problems, > and I'd feel bad for eating someone's data. These patches apply on top > of a set of prepatory patches which just aren't interesting. If you > want to see the patches applied to a tree, I suggest pulling my git tree: > http://git.infradead.org/users/willy/linux-dax.git/shortlog/refs/heads/xarray-2017-12-04 > I also left out the idr_preload removals. They're still in the git tree, > but I'm not looking for feedback on them. Hey Matthew, Maybe I missed this from a previous version, but can you explain the motivation for replacing the radix tree with an xarray? (I think this should probably still be part of the cover letter?) Do we have a performance problem we need to solve? A code complexity issue we need to solve? Something else? - Ross -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v3 06/20] dax: set errors in mapping when writeback fails
On Mon, Apr 24, 2017 at 09:22:45AM -0400, Jeff Layton wrote:
> In order to get proper error codes from fsync, we must set an error in
> the mapping range when writeback fails.
>
> Signed-off-by: Jeff Layton
Works fine in some error injection testing.
Tested-by: Ross Zwisler
> ---
> fs/dax.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index 85abd741253d..9b6b04030c3f 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -901,8 +901,10 @@ int dax_writeback_mapping_range(struct address_space
> *mapping,
>
> ret = dax_writeback_one(bdev, mapping, indices[i],
> pvec.pages[i]);
> - if (ret < 0)
> + if (ret < 0) {
> + mapping_set_error(mapping, ret);
> return ret;
> + }
> }
> }
> return 0;
> --
> 2.9.3
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 37/45] drivers: use req op accessor
On Sun, Jun 5, 2016 at 1:32 PM, wrote: > From: Mike Christie > > The req operation REQ_OP is separated from the rq_flag_bits > definition. This converts the block layer drivers to > use req_op to get the op from the request struct. > > Signed-off-by: Mike Christie > --- > drivers/block/loop.c | 6 +++--- > drivers/block/mtip32xx/mtip32xx.c | 2 +- > drivers/block/nbd.c | 2 +- > drivers/block/rbd.c | 4 ++-- > drivers/block/xen-blkfront.c | 8 +--- > drivers/ide/ide-floppy.c | 2 +- > drivers/md/dm.c | 2 +- > drivers/mmc/card/block.c | 7 +++ > drivers/mmc/card/queue.c | 6 ++ Dave Chinner reported a deadlock with XFS + DAX, which I reproduced and bisected to this commit: commit c2df40dfb8c015211ec55f4b1dd0587f875c7b34 Author: Mike Christie Date: Sun Jun 5 14:32:17 2016 -0500 drivers: use req op accessor Here are the steps to reproduce the deadlock with a BRD ramdisk: mkfs.xfs -f /dev/ram0 mount -o dax /dev/ram0 /mnt/scratch xfs_io -f -c "truncate 1g" /mnt/scratch/test.img losetup -f --show /mnt/scratch/test.img mkfs.xfs -f /dev/loop0 At this point the mkfs.xfs deadlocks. Here is the stack trace gathered via "echo w > /proc/sysrq-trigger" and passed through kasan_symbolize.py: brd: module loaded XFS (ram0): DAX enabled. Warning: EXPERIMENTAL, use at your own risk XFS (ram0): Mounting V5 Filesystem XFS (ram0): Ending clean mount sysrq: SysRq : Show Blocked State taskPC stack pid father mkfs.xfsD 88060ae47b38 0 1482 1287 0x 88060ae47b38 79e8 880610fd8d98 880036011a40 8800aa6dcec0 88060ae48000 880610fd8d80 7fff 8800aa6dcec0 024000c0 88060ae47b50 81aca775 Call Trace: [] schedule+0x35/0x80 kernel/sched/core.c:3360 [] schedule_timeout+0x271/0x460 kernel/time/timer.c:1493 [] io_schedule_timeout+0xa4/0x110 kernel/sched/core.c:4969 [< inline >] do_wait_for_common kernel/sched/completion.c:75 [< inline >] __wait_for_common kernel/sched/completion.c:93 [< inline >] wait_for_common_io kernel/sched/completion.c:107 [] wait_for_completion_io+0xdf/0x120 kernel/sched/completion.c:155 [] submit_bio_wait+0x66/0x90 block/bio.c:870 [] blkdev_issue_discard+0x86/0xc0 block/blk-lib.c:115 [] blk_ioctl_discard+0xa3/0xd0 block/ioctl.c:221 [] blkdev_ioctl+0x60a/0x9e0 block/ioctl.c:510 [] block_ioctl+0x43/0x50 fs/block_dev.c:1714 [< inline >] vfs_ioctl fs/ioctl.c:43 [] do_vfs_ioctl+0xa2/0x6a0 fs/ioctl.c:674 [< inline >] SYSC_ioctl fs/ioctl.c:689 [] SyS_ioctl+0x79/0x90 fs/ioctl.c:680 [] entry_SYSCALL_64_fastpath+0x1f/0xbd arch/x86/entry/entry_64.S:207 The line numbers are for the commit above, not for linux/master. This occurs 100% as of this commit, and 0% with the previous commit. This doesn't occur if you don't use DAX, but based on the content of the commit I'm guessing that difference is due to variations in the way the two paths use discard. - Ross -- ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 42/45] block, fs, drivers: remove REQ_OP compat defs and related code
On Sun, Jun 5, 2016 at 1:32 PM, wrote: > From: Mike Christie > > This patch drops the compat definition of req_op where it matches > the rq_flag_bits definitions, and drops the related old and compat > code that allowed users to set either the op or flags for the operation. > > We also then store the operation in the bi_rw/cmd_flags field similar > to how we used to store the bio ioprio where it sat in the upper bits > of the field. > > Signed-off-by: Mike Christie I was doing some xfstests testing yesterday using linux/master, and hit a kernel BUG that bisected to this change. The failing test is generic/008 + ext2, without DAX. This BUG reproduces with this test 100% as of this change, and 0% with the previous commit. Here's the kernel commit that I bisected to: commit 4e1b2d52a80d79296a5d899d73249748dea71a53 Author: Mike Christie Date: Sun Jun 5 14:32:22 2016 -0500 block, fs, drivers: remove REQ_OP compat defs and related code Here are the steps to reproduce the BUG using a pair of 1 GiB BRD ramdisks: SCRATCH_DEV=/dev/ram0 TEST_DEV=/dev/ram1 mkfs.ext2 -F $SCRATCH_DEV mkfs.ext2 -F $TEST_DEV cd ~/xfstests ./check generic/008 Here is the BUG output for that commit, passed through kasan_symbolize.py. The line numbers are for the commit listed above, not for linux/master: run fstests generic/008 at 2016-08-03 09:54:56 page:ea0017af04c0 count:3 mapcount:0 mapping:8805eb059200 index:0x0 flags: 0x3fff802828(uptodate|lru|private|writeback) page dumped because: VM_BUG_ON_PAGE(!PageLocked(page)) page->mem_cgroup:8806098e0800 [ cut here ] kernel BUG at mm/filemap.c:833! invalid opcode: [#1] SMP Modules linked in: brd dax_pmem nd_pmem dax nd_btt nd_e820 libnvdimm CPU: 0 PID: 2522 Comm: xfs_io Not tainted 4.7.0-rc2-00042-g4e1b2d52 #18 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014 task: 8805ebae4ec0 ti: 8805eba3c000 task.ti: 8805eba3c000 RIP: 0010:[] [] unlock_page+0xa5/0xb0 RSP: 0018:8805eba3fa60 EFLAGS: 00010282 RAX: 0021 RBX: RCX: 0006 RDX: RSI: 0001 RDI: 8806109ce200 RBP: 8805eba3fa60 R08: 0001 R09: 0001 R10: 8805ebae4ec0 R11: 0001 R12: ea0017af04c0 R13: 00028000 R14: a00202c0 R15: 88060eff1200 FS: 7f87a31cf700() GS:88061080() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f87a31e6000 CR3: 00060da31000 CR4: 001406f0 Stack: 8805eba3fa98 812bd782 8805eba3fdb0 1000 ea0017af04c0 0088 8805eba3fbe0 812c3ff1 8805eba3fd00 00028000 000c Call Trace: [] bdev_write_page+0xb2/0xe0 fs/block_dev.c:462 [] __mpage_writepage+0x5c1/0x750 fs/mpage.c:604 [] write_cache_pages+0x20d/0x5f0 mm/page-writeback.c:2261 [] mpage_writepages+0x75/0xe0 fs/mpage.c:703 [] ext2_writepages+0x3b/0x40 fs/ext2/inode.c:887 [] do_writepages+0x21/0x30 mm/page-writeback.c:2361 [] __filemap_fdatawrite_range+0xc6/0x100 mm/filemap.c:300 [] filemap_write_and_wait_range+0x44/0x90 mm/filemap.c:490 [] __generic_file_fsync+0x27/0x90 fs/libfs.c:937 [] generic_file_fsync+0x19/0x40 fs/libfs.c:974 [] ext2_fsync+0x2e/0x70 fs/ext2/file.c:149 [] vfs_fsync_range+0x4b/0xb0 fs/sync.c:195 [< inline >] vfs_fsync fs/sync.c:209 [] do_fsync+0x3d/0x70 fs/sync.c:219 [< inline >] SYSC_fsync fs/sync.c:227 [] SyS_fsync+0x10/0x20 fs/sync.c:225 [] entry_SYSCALL_64_fastpath+0x1f/0xbd arch/x86/entry/entry_64.S:207 Code: 00 00 48 d3 ea 89 d2 48 8d 0c 92 48 8d 14 4a 48 8d 3c d0 31 d2 e8 bc fc f1 ff 5d c3 48 c7 c6 20 1d ec 81 4c 89 c7 e8 bb 8d 03 00 <0f> 0b 66 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 b9 08 00 00 RIP [] unlock_page+0xa5/0xb0 mm/filemap.c:833 RSP ---[ end trace d419bf59bba263fb ]--- I'm happy to provide any additional info you need, or to test fixes. Thanks, - Ross -- ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
