All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Schermerhorn <lee.schermerhorn@hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: Question about interrupt enabling/disabling in kernel exit path
Date: Tue, 15 Nov 2005 20:21:15 +0000	[thread overview]
Message-ID: <1132086075.5230.23.camel@localhost.localdomain> (raw)
In-Reply-To: <1131559925.5214.100.camel@localhost.localdomain>

On Mon, 2005-11-14 at 13:52 -0800, David Mosberger-Tang wrote:
> > Then I notice that after we return from do_notify_resume_user() we don't
> > recheck TIF_NEED_RESCHED, etc. in the thread_info flags.
> 
> Why do you say this?  It's not true.  After processing pending work,
> we go back to .work_processed_{syscall,kernel), which will again
> invoke .work_pending, if necessary.

OK.  I guess I'm misinterpreting the comments on the line labeled
'.ret10:'.
Say's it's setting p6 to zero, so no recheck.  I'm not fluent [writing
nor reading] ia64 assembler, but it appeared to me that with p6 set to
zero on return from notify_resume(), the checks for more work back
at .work_processed_* would be disabled.

Are the comments at the ia64_leave_kernel entry point stale?

> 
> AFAIR, it's OK to reenable interrupts in notify_resume_user() because
> we know we're at the top of the kernel stack (i.e., there is no risk
> of nesting the kernel stack too deeply due to pending interrupts),
> provided the interrupts are off again when resuming execution at
> .work_processed_kernel.

OK.  Ken said he thought it was OK to disable.  And Stephane mentioned
that he's seen interrupts enabled when entering do_notify_resume_user()
as well.

Thanks,
Lee


  parent reply	other threads:[~2005-11-15 20:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-09 18:12 Question about interrupt enabling/disabling in kernel exit path Lee Schermerhorn
2005-11-09 22:31 ` Stephane Eranian
2005-11-14 21:52 ` David Mosberger-Tang
2005-11-15 20:21 ` Lee Schermerhorn [this message]
2005-11-15 21:04 ` Chen, Kenneth W
2005-11-15 21:16 ` David Mosberger-Tang

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=1132086075.5230.23.camel@localhost.localdomain \
    --to=lee.schermerhorn@hp.com \
    --cc=linux-ia64@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 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.