From: hyl <heyongli@gmail.com>
To: "John Blackwood" <john.blackwood@ccur.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch][RFC] an early patch for x86_64 preempt-rt kernel cause more __might_sleep warnings
Date: Tue, 1 Jul 2008 10:33:16 +0800 [thread overview]
Message-ID: <505766fa0806301933w65924ce0x3195f9e2dd82e7bb@mail.gmail.com> (raw)
In-Reply-To: <4868D792.6020205@ccur.com>
2008/6/30 John Blackwood <john.blackwood@ccur.com>:
>> Subject: Re: [patch][RFC] an early patch for x86_64 preempt-rt kernel
>> cause more __might_sleep warnings
>> From: hyl <heyongli@gmail.com>
>> Date: Wed, 25 Jun 2008 22:38:50 -0400
>> To: "Blackwood, John" <john.blackwood@ccur.com>
>>
>> > > ------------------------------ ------------------------------
>> > >
>> > > Subject: Re: your x86_64 IST stack preempt rt patch
>> > > From: Andi Kleen <andi@firstfloor.org>
>> > > Date: Wed, 25 Jun 2008 03:36:33 -0400
>> > > To: "Blackwood, John" <john.blackwood@ccur.com>
>> > >
>> > >
>> > > This patch changes these traps instead to always switch
>> > > to the process stack when the trap originated from user mode.
>> > > For kernel traps it keeps running non preemptive on the IST stack
>> > > because that is much safer (e.g. to still get nmi watchdog events
>> > > out even when the process stack is corrupted)
>> > >
>> > > Strictly the change would have been only needed for debug
>> > > and int3, but since they share this code as macros it was
>> > > cleanest to just change all.
>> > >
>> > > Additional (small) benefit is less preemption latency in these
>> > > exception cases. This will also likely help preempt-RT kernels a bit
>> > > because those are more likely to take sleeping locks even in these
>> > > cases.
>> > >
>>
>> But with this fix, we still run do_debug/.. on IST when the 'interrupt'
>> occur from kernel space, so the warning message will come out again,
>> right?
>
> that seems correct to me.
>
>> but i don't have a scenario to proof this.
>
> i think that using something like kgdb or kdb kernel debuggers
> would end up causing this situation.
>
> or using ptrace from user space to set up a debug register to point
> to some kernel address as a breakpoint or watchpoint (this wouldn't be
> something that people would usually want to do though).
yeah, but there is no patch try to fix it, do you found one ?
>
>
>
>
>
next parent reply other threads:[~2008-07-01 2:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4868D792.6020205@ccur.com>
2008-07-01 2:33 ` hyl [this message]
2008-06-24 7:01 hyl
2008-06-25 5:31 ` hyl
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=505766fa0806301933w65924ce0x3195f9e2dd82e7bb@mail.gmail.com \
--to=heyongli@gmail.com \
--cc=john.blackwood@ccur.com \
--cc=linux-kernel@vger.kernel.org \
/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®