On Fri, Feb 10, 2017 at 12:17 PM, Greg Kroah-Hartman
> On Fri, Feb 10, 2017 at 11:41:20AM -0800, Dan Williams wrote:
>> On Fri, Feb 10, 2017 at 11:19 AM, Logan Gunthorpe <logang(a)deltatee.com>
>> > I copied this code and per feedback from Greg Kroah-Hartman  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.
>> >  https://lkml.org/lkml/2017/2/10/370
>> > Signed-off-by: Logan Gunthorpe <logang(a)deltatee.com>
>> 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:
>> ? debug_lockdep_rcu_enabled+0x1d/0x20
>> ? trace_hardirqs_off+0xd/0x10
>> ? cmpxchg_double_slab.isra.70+0x15a/0x1c0
>> ? __slab_free+0x134/0x290
>> ? __lock_acquire+0x33d/0x1290
>> dax_dev_huge_fault+0xee/0x570 [dax]
>> ? handle_mm_fault+0x3c/0x350
>> I added this reference explicitly so the parent struct device has the
>> correct lifetime after this feedback from Al.
>> ...so I'm wondering what the actual problem is with setting
> It shouldn't do anything at all. The kobject in a cdev isn't a
> kobject, it doesn't show up in sysfs, or anywhere else. It's used for
> an internal representation to the cdev code (a kmap) to look up the
> object to call when userspace opens the device node in a quick manner.
> Now changing from initialize/add to just register, does do different
> things, perhaps that is the issue here. Just try removing the
> cdev->kobject parent stuff and see if that causes a problem or not.
That doesn't help. I rely on the "kobject_get(p->kobj.parent);" in
cdev_add() to pin my device and cdev_default_release() to free it.