From: Gustavo Padovan <gustavo@padovan.org>
To: Adam Lee <adam.lee@canonical.com>
Cc: Marcel Holtmann <marcel@holtmann.org>,
linux-bluetooth@vger.kernel.org,
Wen-chien Jesse Sung <jesse.sung@canonical.com>,
AceLan Kao <acelan.kao@canonical.com>,
Tedd Ho-Jeong An <tedd.an@intel.com>,
Anthony Wong <anthony.wong@canonical.com>,
Johan Hedberg <johan.hedberg@gmail.com>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] btusb: fix overflow return values
Date: Tue, 9 Jul 2013 16:32:13 +0100 [thread overview]
Message-ID: <20130709153213.GC1772@joana> (raw)
In-Reply-To: <20130709025501.GA6369@adam-laptop>
Hi Adam,
* Adam Lee <adam.lee@canonical.com> [2013-07-09 10:55:01 +0800]:
> On Mon, Jul 08, 2013 at 11:50:54AM -0700, Marcel Holtmann wrote:
> > Hi Adam,
> >
> > > PTR_ERR() returns a long type value, but btusb_setup_intel() and
> > > btusb_setup_intel_patching() should return an int type value.
> > >
> > > This bug makes the judgement "if (ret < 0)" not working on x86_64
> > > architecture systems, leading to failure as below, even panic.
> > > ...
> > > For not affecting other modules, I choose to modify the return values
> > > but not extend btusb_setup_intel() and btusb_setup_intel_patching()'s
> > > return types. This is harmless, because the return values were only
> > > used to comparing number 0.
> >
> > there are tons of examples in various subsystems and drivers where we
> > return PTR_ERR from a function calls returning int.
> >
> > So I wonder what is actually going wrong here. If this is x86_64
> > specific problem with PTR_ERR vs int, then we should have this problem
> > everywhere in the kernel.
>
> Hi, Marcel
>
> I see you point, the difference between here and other subsystems are:
>
> 1, it returns -PTR_ERR() here but all other places return PTR_ERR(), I
> checked.
Please sending a patch fixing this. We got this right in other parts of the
bluetooth subsystems but somehow we failed to check this when this code came
in. And then another updating the checks if needed.
Gustavo
next prev parent reply other threads:[~2013-07-09 15:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-04 12:43 [PATCH] btusb: fix overflow return values Adam Lee
2013-07-05 2:37 ` Yang Bai
2013-07-05 2:53 ` Yang Bai
2013-07-05 2:59 ` Adam Lee
2013-07-05 4:41 ` Adam Lee
2013-07-08 18:50 ` Marcel Holtmann
2013-07-09 2:55 ` Adam Lee
2013-07-09 7:40 ` Adam Lee
2013-07-09 8:48 ` [PATCH v2] btusb: fix wrong use of PTR_ERR() Adam Lee
2013-07-09 15:32 ` Gustavo Padovan [this message]
2013-07-10 2:02 ` [PATCH v3] " Adam Lee
2013-07-10 10:28 ` Gustavo Padovan
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=20130709153213.GC1772@joana \
--to=gustavo@padovan.org \
--cc=acelan.kao@canonical.com \
--cc=adam.lee@canonical.com \
--cc=anthony.wong@canonical.com \
--cc=jesse.sung@canonical.com \
--cc=johan.hedberg@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcel@holtmann.org \
--cc=tedd.an@intel.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;
as well as URLs for NNTP newsgroup(s).