On Wed, Jul 26, 2017 at 7:23 AM, Ross Zwisler <ross.zwisler@xxxxxxxxxxxxxxx> wrote: > On Wed, Jul 26, 2017 at 06:23:08PM +0900, OGAWA Hirofumi wrote: >> "Kani, Toshimitsu" <toshi.kani@xxxxxxx> writes: >> >> > kernel BUG at fs/buffer.c:3305! >> > invalid opcode: 0000 [#1] SMP >> > : >> > Workqueue: writeback wb_workfn (flush-259:0) >> > task: ffff8d02595b8000 task.stack: ffffa22242400000 >> > RIP: 0010:try_to_free_buffers+0xd2/0xe0 >> > RSP: 0018:ffffa22242403830 EFLAGS: 00010246 >> > RAX: 00afffc000001028 RBX: 0000000000000008 RCX: ffff8d012dcf19c0 >> > RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffc468e3b52b80 >> > RBP: ffffa22242403858 R08: 0000000000000000 R09: 000000000002067c >> > R10: ffff8d027ffe6000 R11: 0000000000000000 R12: 0000000000000000 >> > R13: ffff8d022fccdbe0 R14: ffffc468e3b52b80 R15: ffffa22242403ad0 >> > FS: 0000000000000000(0000) GS:ffff8d027fd40000(0000) >> >> The locking of this path seems to be broken. The guy familiar to >> bdev_write_page() path will made real fix though, The following patch >> should be explaining enough what is wrong. > > Is there someone in particular who is familiar with bdev_write_page() that is > working on this fix, or does someone need to pick this up? Another question, does ->rw_page() really buy us that much with the pmem driver? If applications want to enjoy the lowest latency access they can just use DAX. There's now only 4 drivers that use rw_page since nvme dropped its usage and I'd be inclined to just rip it out.
