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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox