From: Prasanna S Panchamukhi <prasanna@in.ibm.com>
To: Stas Sergeev <stsp@aknet.ru>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: [patch] kprobes: dont steal interrupts from vm86
Date: Mon, 6 Dec 2004 20:58:03 +0530 [thread overview]
Message-ID: <20041206152803.GC28861@in.ibm.com> (raw)
In-Reply-To: <41AF6CE0.4090500@aknet.ru>
Hi,
On Thu, Dec 02, 2004 at 10:28:32PM +0300, Stas Sergeev wrote:
> Hello.
>
> Prasanna S Panchamukhi wrote:
> >Yes, there is a small bug in kprobes. Kprobes int3 handler
> >was returning wrong value. Please check out if the patch
> >attached with this mail fixes your problem.
> >Please let me know if you have any issues.
> Yes. After several days of debugging,
> I am pointing to this problem again.
> Unfortunately your patch appeared not
> to work. It only masks the problem.
> I was surprised that you check VM_MASK
> after you already used "addr" a couple
> of times - this "addr" is completely
> bogus and should not be used. Now this
> turned out more important. The problem
> is that the "addr" calculated only from
> the value of EIP, is bogus not only when
> VM flag is set. It is also bogus if the
> program uses segmentation and the
> CS_base!=0. I have many of the like
> programs here and they all are broken
> because kprobes still steal the int3 from
> them. They do not use V86, but they use
> segments instead of the flat layout, so
> the address cannot be calculated by the
> EIP value.
Well, a test program is always better. I
would appreciate if you can sent me the
test program.
> I would suggest something like the attached
> patch. I know nothing about kprobes (sorry)
> so I don't know what CS you need. If you
> need not only __KERNEL_CS, you probably
> want the (regs->xcs & 4) check to see if
> the CS is not from LDT at least. Does this
> make sense?
> Anyway, would be nice to get this fixed.
> This can cause Oopses because you deref
> the completely bogus pointer later in the
> code.
> Writing a test-case for this problem is
> not a several-minutes work, but if you
> really need one, I may try to hack it out.
>
> Thanks.
>
Thanks
Prasanna
--
Prasanna S Panchamukhi
Linux Technology Center
India Software Labs, IBM Bangalore
Ph: 91-80-25044636
<prasanna@in.ibm.com>
next prev parent reply other threads:[~2004-12-06 15:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20041109130407.6d7faf10.akpm@osdl.org>
2004-11-10 10:49 ` [patch] kprobes: dont steal interrupts from vm86 Prasanna S Panchamukhi
2004-11-10 18:53 ` Stas Sergeev
2004-11-17 13:15 ` Prasanna S Panchamukhi
2004-11-18 14:55 ` Stas Sergeev
2004-12-02 19:28 ` Stas Sergeev
2004-12-06 15:28 ` Prasanna S Panchamukhi [this message]
2004-12-04 18:09 ` Stas Sergeev
2004-12-07 5:53 ` Prasanna S Panchamukhi
2004-12-07 18:44 ` Stas Sergeev
2004-12-09 12:47 ` Prasanna S Panchamukhi
2004-12-09 19:28 ` Stas Sergeev
2005-01-07 11:37 ` Prasanna S Panchamukhi
2005-01-07 12:59 ` Andi Kleen
2005-01-13 8:10 ` Prasanna S Panchamukhi
2005-01-07 22:44 ` Stas Sergeev
2004-11-09 19:01 Stas Sergeev
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=20041206152803.GC28861@in.ibm.com \
--to=prasanna@in.ibm.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stsp@aknet.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 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.