Re: [PATCH] device-dax: don't set kobj parent during cdev init
From: Greg Kroah-Hartman
Date: Fri Feb 10 2017 - 15:18:50 EST
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@xxxxxxxxxxxx> wrote:
> > 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@xxxxxxxxxxxx>
> 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 cdev->parent?
It shouldn't do anything at all. The kobject in a cdev isn't a "normal"
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.