From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Jan Kara <jack@suse.cz>, Arnd Bergmann <arnd@arndb.de>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
Sajjan Vikas C <vikas.cha.sajjan@hpe.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH] device-dax: don't set kobj parent during cdev init
Date: Sat, 11 Feb 2017 08:16:19 +0100 [thread overview]
Message-ID: <20170211071619.GA1345@kroah.com> (raw)
In-Reply-To: <CAPcyv4gz0C+rhR=Xzk-G58yM=qpEBEuYbkushn5dByFD38KQbg@mail.gmail.com>
On Fri, Feb 10, 2017 at 02:25:35PM -0800, Dan Williams wrote:
> On Fri, Feb 10, 2017 at 12:17 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > 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@deltatee.com> 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 <logang@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:
> >> 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?
> >
> > 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.
> >
>
> 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.
"pin it" where? Why do you need this? That feels really "odd" to me...
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Logan Gunthorpe <logang@deltatee.com>,
Johannes Thumshirn <jthumshirn@suse.de>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Sajjan Vikas C <vikas.cha.sajjan@hpe.com>,
Arnd Bergmann <arnd@arndb.de>, Jan Kara <jack@suse.cz>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>
Subject: Re: [PATCH] device-dax: don't set kobj parent during cdev init
Date: Sat, 11 Feb 2017 08:16:19 +0100 [thread overview]
Message-ID: <20170211071619.GA1345@kroah.com> (raw)
In-Reply-To: <CAPcyv4gz0C+rhR=Xzk-G58yM=qpEBEuYbkushn5dByFD38KQbg@mail.gmail.com>
On Fri, Feb 10, 2017 at 02:25:35PM -0800, Dan Williams wrote:
> On Fri, Feb 10, 2017 at 12:17 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > 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@deltatee.com> 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 <logang@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:
> >> 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?
> >
> > 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.
> >
>
> 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.
"pin it" where? Why do you need this? That feels really "odd" to me...
next prev parent reply other threads:[~2017-02-11 7:16 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-10 19:19 [PATCH] device-dax: don't set kobj parent during cdev init Logan Gunthorpe
2017-02-10 19:19 ` Logan Gunthorpe
2017-02-10 19:22 ` Logan Gunthorpe
2017-02-10 19:22 ` Logan Gunthorpe
2017-02-10 19:41 ` Dan Williams
2017-02-10 19:41 ` Dan Williams
2017-02-10 20:17 ` Greg Kroah-Hartman
2017-02-10 20:17 ` Greg Kroah-Hartman
2017-02-10 22:25 ` Dan Williams
2017-02-10 22:25 ` Dan Williams
2017-02-11 7:16 ` Greg Kroah-Hartman [this message]
2017-02-11 7:16 ` Greg Kroah-Hartman
2017-02-11 8:56 ` Dan Williams
2017-02-11 8:56 ` Dan Williams
2017-02-11 17:59 ` Logan Gunthorpe
2017-02-11 17:59 ` Logan Gunthorpe
2017-02-11 18:27 ` Dan Williams
2017-02-11 18:27 ` Dan Williams
2017-02-11 18:43 ` Logan Gunthorpe
2017-02-11 18:43 ` Logan Gunthorpe
2017-02-11 18:55 ` Dan Williams
2017-02-11 18:55 ` Dan Williams
2017-02-11 18:58 ` Dan Williams
2017-02-11 18:58 ` Dan Williams
2017-02-12 5:42 ` Logan Gunthorpe
2017-02-12 5:42 ` Logan Gunthorpe
2017-02-13 20:47 ` Dan Williams
2017-02-13 20:47 ` Dan Williams
2017-02-13 22:38 ` Logan Gunthorpe
2017-02-13 22:38 ` Logan Gunthorpe
2017-02-10 19:46 ` Greg Kroah-Hartman
2017-02-10 19:46 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170211071619.GA1345@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=arnd@arndb.de \
--cc=dan.j.williams@intel.com \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=vikas.cha.sajjan@hpe.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.