From: Greg KH <greg@kroah.com>
To: "Robert T. Johnson" <rtjohnso@eecs.berkeley.edu>
Cc: linux-kernel@vger.kernel.org, Jean Delvare <khali@linux-fr.org>,
Marcelo Tosatti <marcelo@conectiva.com.br>,
sensors@Stimpy.netroedge.com, vsu@altlinux.ru
Subject: Re: [PATCH 2.4] i2c-dev user/kernel bug and mem leak
Date: Fri, 15 Aug 2003 14:13:30 -0700 [thread overview]
Message-ID: <20030815211329.GB4920@kroah.com> (raw)
In-Reply-To: <1060912895.1006.7160.camel@dooby.cs.berkeley.edu>
On Thu, Aug 14, 2003 at 07:01:34PM -0700, Robert T. Johnson wrote:
> On Thu, 2003-08-14 at 12:09, Greg KH wrote:
> > Hm, much like Linus's sparse does already? :)
>
> Yes, but cqual needs fewer annotations (see below).
>
> > His checker missed the 2.6 version of this, for some reason, I haven't
> > taken the time to figure out why.
>
> Currently, sparse silently ignores missing annotations. Since i2c-dev.c
> is not extensively annotated, it missed this bug.
i2c-dev.c is annotated in 2.6. Did I miss anything that needs to be
marked as such?
> Also, cqual is more flexible than sparse. For example, i2c-dev.c wants
> to use some i2c_msg structures to hold user bufs, and some to hold
> kernel bufs. cqual handles this automatically, but sparse cannot at
> all. To get i2c-dev.c to work with sparse, you'd need to declare two
> new types, "struct kernel_i2c_msg" and "struct user_i2c_msg", and change
> every instance of i2c_msg to be one or the other.
That's something that will be necessary anyway, if we want to get this
to ever work on a 64 bit processor running with a 32 bit userspace
(amd64, ppc64, sparc64, etc.)
> > How is cqual going to handle all of the tty drivers which can have a
> > pointer be either a userspace pointer, or a kernel pointer depending on
> > the value of another paramater in a function?
>
> I think all these functions should be changed to take two pointers, only
> one of which is allowed to be non-NULL. Then the flag can go away. I
> hope to submit a patch to this effect in the future. I think sparse
> can't check these either, unless you insert casts between user/kernel.
> But inserting casts loses the benefits of the automatic verification,
> since the casts could be wrong.
Hm, how about just fixing the tty core to always pass in kernel buffers?
That would fix the "problem" in one place :)
Anyway, that's a 2.7 change that has been on my list of things to do for
a while...
> Ok. Here's a patch against 2.6.0-test3. I didn't add the md
> substructure to i2c_msg, since it would require changing lots of files
> throughout the kernel. If you think that's an important change, I'll do
> it. Otherwise, the patch is the same idea as before.
>
> Oh, yeah. This patch also fixes the mem leak, and includes the
> single-copy_from_user optimization you guys talked about earlier, since
> those haven't been merged into mainline linux yet.
Hm, I had already applied your patch, so this one doesn't apply. Care
to re-do it against 2.6.0-test4 whenever that comes out?
thanks,
greg k-h
next prev parent reply other threads:[~2003-08-15 21:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-03 17:23 PATCH: 2.4.22-pre7 drivers/i2c/i2c-dev.c user/kernel bug and mem leak Jean Delvare
2003-08-04 15:32 ` Sergey Vlasov
2003-08-05 8:32 ` Jean Delvare
2003-08-05 14:10 ` Sergey Vlasov
2003-08-05 21:07 ` Greg KH
2003-08-06 8:07 ` [PATCH 2.4] i2c-dev " Jean Delvare
[not found] ` <1060886657.1006.7121.camel@dooby.cs.berkeley.edu>
[not found] ` <20030814190954.GA2492@kroah.com>
2003-08-15 2:01 ` Robert T. Johnson
2003-08-15 21:13 ` Greg KH [this message]
2003-08-15 22:17 ` Robert T. Johnson
2003-08-15 23:51 ` Greg KH
2003-08-18 0:54 ` Robert T. Johnson
2003-08-18 21:05 ` Greg KH
2003-09-10 23:02 ` CQual 0.99 Released: user/kernel pointer bug finding tool Robert T. Johnson
2003-08-28 1:17 ` [PATCH 2.4] i2c-dev user/kernel bug and mem leak Robert T. Johnson
2003-08-29 16:21 ` Jean Delvare
2003-08-29 17:30 ` Robert T. Johnson
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=20030815211329.GB4920@kroah.com \
--to=greg@kroah.com \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
--cc=rtjohnso@eecs.berkeley.edu \
--cc=sensors@Stimpy.netroedge.com \
--cc=vsu@altlinux.ru \
/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