All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@steeleye.com>
To: Al Viro <viro@ftp.linux.org.uk>
Cc: torvalds@osdl.org, linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org
Subject: Re: [PATCHSET] thread_info annotations and fixes
Date: Tue, 03 Jan 2006 17:41:45 -0500	[thread overview]
Message-ID: <1136328105.3658.2.camel@mulgrave> (raw)
In-Reply-To: <E1EttNa-0008PA-2x@ZenIV.linux.org.uk>

On Tue, 2006-01-03 at 21:07 +0000, Al Viro wrote:
> 	Patchset annotates arch/* uses of ->thread_info.  Ones that really
> are about access of thread_info of given process are simply switched to
> task_thread_info(task); ones that deal with access to objects on stack
> are switched to new helper - task_stack_page().  A _lot_ of the latter are
> actually open-coded instances of "find where pt_regs are"; those are
> consolidated into task_pt_regs(task) (many architectures actually have
> such helper already).
> 
> 	Note that these annotations are not mandatory - any code not
> converted to these helpers still works.  However, they clean up a lot
> of places and have actually caught a number of bugs, so converting out
> of tree ports would be a good idea...
> 
> 	As an example of breakage caught by that stuff, see i386
> pt_regs mess - we used to have it open-coded in a bunch of places
> and when back in April Stas had fixed a bug in copy_thread(), the
> rest had been left out of sync.  That required two followup patches
> (the latest - just before 2.6.15) _and_ still had left /proc/*/stat
> eip field broken.  Try ps -eo eip on i386 and watch the junk...

As long as this is just wrappering the existing pointers, then that's
fine, but just in case it matters, I should point out that, at least for
parisc, the wrappering is incomplete: we have references to the
thread_info pointer in the task struct via our assembly glue as well (in
just two places: the smp secondary CPU start and the _switch_to
implementation).

James



  parent reply	other threads:[~2006-01-03 22:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-03 21:07 [PATCHSET] thread_info annotations and fixes Al Viro
2006-01-03 21:15 ` Al Viro
2006-01-03 22:41 ` James Bottomley [this message]
2006-01-03 22:53   ` Al Viro

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=1136328105.3658.2.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    --cc=viro@ftp.linux.org.uk \
    /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.