From: liyu <liyu@ccoss.com.cn>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [Question] one question about 'current' in scheduler_tick()
Date: Mon, 17 Oct 2005 17:02:10 +0800 [thread overview]
Message-ID: <43536892.9070607@ccoss.com.cn> (raw)
In-Reply-To: <Pine.LNX.4.58.0510170416090.5859@localhost.localdomain>
Steven Rostedt wrote:
>Hi Liyu (once again :-)
>
>On Mon, 17 Oct 2005, liyu wrote:
>
>
>
>>Hi, All.
>>
>> I found scheduler_tick() use current macro to get task_struct of
>>current task.
>>
>> I seen scheduler_tick() is called every timer interrupt at most
>>time. In this
>>case, I think scheduler_tick() is in interrupt context (enter kernel by
>>interrupt),
>>
>>
>
>Yes, scheduler_tick is called from interrupt context.
>
>
>
>>So I have a hunch that there have not thread_info which it need in
>>kernel stack. But
>>It seem it can work perfectly.
>>
>>
>
>Although it is said that you can't access user memory from an interrupt
>context, the reasons are simple. One, most user memory access can
>schedule, and an interrupt service routine must not schedule. Also, an
>interrupt service routine can happen on any thread, so you can't be sure
>what thread is there.
>
>But, when an interrupt goes off, whatever thread is running is still
>there. The thread's context _is_ still there. The changing to the
>interrupt stack takes special care to make sure that current still works.
>So a copy of the thread_info is also done. Look in the do_IRQ in
>arch/i386/kernel/irq.c and search for 4KSTACKS. You will see there the
>copying of thread_info.
>
>
>
>> I can not understand this. Would any expert like explain clearly for
>>it ?
>>
>>
>>
>
>Hope this helps,
>
>-- Steve
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>
Hi Steve, Thanks once again :)
I searched arch/i386/kernel/irq.c, and got this line of code:
irqctx->tinfo.task = curctx->tinfo.task;
I think it just is answer that I want to get. It seem interrupt
stack is
created at top of the original kernel stack. Are my words right?
In passing, How 'current' work in this case when we disable 4KSTACK?
I just found these code only be compiled when we define CONFIG_4KSTACK,
but cann't found #else branch relevantly.
-liyu
next prev parent reply other threads:[~2005-10-17 9:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-17 8:05 [Question] one question about 'current' in scheduler_tick() liyu
2005-10-17 8:24 ` Steven Rostedt
2005-10-17 9:02 ` liyu [this message]
2005-10-17 9:32 ` Steven Rostedt
2005-10-18 1:58 ` liyu
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=43536892.9070607@ccoss.com.cn \
--to=liyu@ccoss.com.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.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