[PATCHSET] thread_info annotations and fixes

[PATCHSET] thread_info annotations and fixes

[Al Viro]

Message-ID: <20060103210515.5135@ftp.linux.org.uk>

	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...

Patchset contents:
      missing helper - task_stack_page()
      alpha: task_thread_info()
      alpha: task_stack_page()
      alpha: task_pt_regs()
      amd64: task_thread_info()
      amd64: task_pt_regs()
      amd64: task_stack_page()
      i386: task_thread_info()
      i386: fix task_pt_regs()
      i386: task_stack_page()
      sparc64: task_thread_info()
      sparc64: task_stack_page()
      sparc64: task_pt_regs()
      sh: task_pt_regs()
      sh: task_thread_info()
      sh: task_stack_page()
      sparc: task_thread_info()
      sparc: task_stack_page()
      uml: task_thread_info()
      uml: task_stack_page()
      s390: task_pt_regs()
      s390: task_stack_page()
      xtensa: task_pt_regs(), task_stack_page()
      v850: task_stack_page(), task_pt_regs()
      m32r: task_pt_regs(), task_stack_page(), task_thread_info()
      frv: task_thread_info(), task_stack_page()
      m68k: task_stack_page()
      m68knommu: task_stack_page()
      parisc: task_stack_page(), task_thread_info()
      h8300: task_stack_page()
      arm: task_thread_info()
      arm: task_pt_regs()
      arm: end_of_stack()
      arm: task_stack_page()
      arm26: task_thread_info()
      arm26: task_pt_regs()
      arm26: task_stack_page()
      sh64: task_stack_page()
      powerpc: task_thread_info()
      powerpc: task_stack_page()
      cris: task_pt_regs()
      cris: fix KSTK_EIP
      cris: task_thread_info()
      ia64: task_thread_info()
      ia64: task_pt_regs()
      mips: namespace pollution: dump_regs() -> elf_dump_regs()
      mips: task_pt_regs()
      mips: task_thread_info()
      mips: task_stack_page()
      death of get_thread_info/put_thread_info

The only ordering requirements are that the first patch (introducing a
trivial #define for task_stack_page()) goes before the rest and that
patches for given architecture go in order.

Re: [PATCHSET] thread_info annotations and fixes

[Al Viro]

On Tue, Jan 03, 2006 at 09:07:38PM +0000, Al Viro wrote:
> Message-ID: <20060103210515.5135@ftp.linux.org.uk>

Gaaaack...  <applies a self-LART for broken patchbomb script>
My apologies, folks.

Linus, I'll send entire series in one mbox in a few (I doubt that 196Kb
is below the list limit and resending 50-member series... ouch)

Re: [PATCHSET] thread_info annotations and fixes

[James Bottomley]

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

Re: [PATCHSET] thread_info annotations and fixes

[Al Viro]

On Tue, Jan 03, 2006 at 05:41:45PM -0500, James Bottomley wrote:
> 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).

You and a _lot_ of other architectures.  That's fine - nobody suggests
centrally forced changes of data structure layouts, etc.  These decisions
belong to architecture and assembler code is obviously supposed to be
aware of WTF it is doing; such annotations belong on C side of things.