From: "George Spelvin" <linux@horizon.com>
To: gregkh@linuxfoundation.org, linux@horizon.com
Cc: giometti@linux.it, linux-kernel@vger.kernel.org,
linux-serial@vger.kernel.org, peter@hurleysoftware.com
Subject: Re: [PATCH 0/7] 3.8-rc regression with pps-ldisc due to 70ece7a731
Date: 9 Feb 2013 02:05:58 -0500 [thread overview]
Message-ID: <20130209070558.4322.qmail@science.horizon.com> (raw)
In-Reply-To: <20130208233656.GA7700@kroah.com>
As a followup, testing my fixes has revealed an old bug in the
PPS driver that I'm trying to figure out how to solve.
Basically, pps_unregister_cdev does
device_destroy(pps_class, pps->dev->devt);
cdev_del(&pps->cdev);
And device_destroy ends up calling pps->dev->release,
which is pps_device_destruct, which does
mutex_lock(&pps_idr_lock);
idr_remove(&pps_idr, pps->id);
mutex_unlock(&pps_idr_lock);
kfree(dev);
kfree(pps);
Now the problem is that the kfree(pps) happens *before* the
cdev_del(&pps->cdev) call, which is Not Good.
I'm trying to figure out The Right Thing to do in this case and include a
fix for that, too. It's not a regression, but it is a fairly serious bug.
Advice gratefully received, but I'll figure it out on my own, if not.
The most obvious kludge is to wrap the pps_unregister_cdev operations
in device_get/device_put, to force the release callback to be delayed
until later.
I'm hoping for something prettier, though. The other option I'm thinking
about is to move one or both deallocations to the (currently stub)
pps_cdev_release function.
prev parent reply other threads:[~2013-02-09 7:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1360307140.git.linux@horizon.com>
2013-02-08 23:36 ` Greg KH
2013-02-09 0:22 ` George Spelvin
2013-02-09 7:05 ` George Spelvin [this message]
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=20130209070558.4322.qmail@science.horizon.com \
--to=linux@horizon.com \
--cc=giometti@linux.it \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=peter@hurleysoftware.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®