On Fri, Feb 10, 2017 at 11:19 AM, Logan Gunthorpe <[email protected]> wrote: > I copied this code and per feedback from Greg Kroah-Hartman [1] the > cdev's kobject's parent should not be set to the related device. > This should have minor consequences but isn't doing what anyone > expects it to. > > This patch then fixes device-dax so it doesn't make the same mistake. > > [1] https://lkml.org/lkml/2017/2/10/370 > > Signed-off-by: Logan Gunthorpe <[email protected]>
Thanks for following up with this fix, but this causes a use-after-free regression: general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC [..] Call Trace: vsnprintf+0x2d7/0x500 snprintf+0x49/0x60 dev_vprintk_emit+0x68/0x230 ? debug_lockdep_rcu_enabled+0x1d/0x20 ? trace_hardirqs_off+0xd/0x10 ? cmpxchg_double_slab.isra.70+0x15a/0x1c0 ? __slab_free+0x134/0x290 dev_printk_emit+0x4e/0x70 __dynamic_dev_dbg+0xc8/0x110 ? __lock_acquire+0x33d/0x1290 dax_dev_huge_fault+0xee/0x570 [dax] __handle_mm_fault+0x5aa/0x10a0 handle_mm_fault+0x154/0x350 ? handle_mm_fault+0x3c/0x350 __do_page_fault+0x26b/0x4c0 trace_do_page_fault+0x58/0x270 do_async_page_fault+0x1a/0xa0 async_page_fault+0x28/0x30 I added this reference explicitly so the parent struct device has the correct lifetime after this feedback from Al. https://lists.01.org/pipermail/linux-nvdimm/2016-August/006563.html ...so I'm wondering what the actual problem is with setting cdev->parent?
