On Wed, Jul 26, 2017 at 7:23 AM, Ross Zwisler
On Wed, Jul 26, 2017 at 06:23:08PM +0900, OGAWA Hirofumi wrote:
> "Kani, Toshimitsu" <toshi.kani(a)hpe.com> 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.