kernel_samsung_smdk4412/include/asm-x86_64/thread_info.h, branch replicant-6.0

i386/x86_64: move headers to include/asm-x86

2007-10-11T09:20:03+00:00

Move the headers to include/asm-x86 and fixup the
header install make rules

Signed-off-by: Thomas Gleixner 
Signed-off-by: Ingo Molnar

remove unused TIF_NOTIFY_RESUME flag

2007-07-31T22:39:38+00:00

Remove unused TIF_NOTIFY_RESUME flag for all processor architectures.  The
flag was not used excecpt on IA-64 where the patch replaces it with
TIF_PERFMON_WORK.

Signed-off-by: stephane eranian 
Cc: 
Cc: "Luck, Tony" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

x86_64: support poll() on /dev/mcelog

2007-07-22T01:37:10+00:00

Background:
 /dev/mcelog is typically polled manually.  This is less than optimal for
 situations where accurate accounting of MCEs is important.  Calling
 poll() on /dev/mcelog does not work.

Description:
 This patch adds support for poll() to /dev/mcelog.  This results in
 immediate wakeup of user apps whenever the poller finds MCEs.  Because
 the exception handler can not take any locks, it can not call the wakeup
 itself.  Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
 caught at the next return from interrupt or exit from idle, calling the
 mce_user_notify() routine.  This patch also disables the "fake panic"
 path of the mce_panic(), because it results in printk()s in the exception
 handler and crashy systems.

 This patch also does some small cleanup for essentially unused variables,
 and moves the user notification into the body of the poller, so it is
 only called once per poll, rather than once per CPU.

Result:
 Applications can now poll() on /dev/mcelog.  When an error is logged
 (whether through the poller or through an exception) the applications are
 woken up promptly.  This should not affect any previous behaviors.  If no
 MCEs are being logged, there is no overhead.

Alternatives:
 I considered simply supporting poll() through the poller and not using
 TIF_MCE_NOTIFY at all.  However, the time between an uncorrectable error
 happening and the user application being notified is *the*most* critical
 window for us.  Many uncorrectable errors can be logged to the network if
 given a chance.

 I also considered doing the MCE poll directly from the idle notifier, but
 decided that was overkill.

Testing:
 I used an error-injecting DIMM to create lots of correctable DRAM errors
 and verified that my user app is woken up in sync with the polling interval.
 I also used the northbridge to inject uncorrectable ECC errors, and
 verified (printk() to the rescue) that the notify routine is called and the
 user app does wake up.  I built with PREEMPT on and off, and verified
 that my machine survives MCEs.

[wli@holomorphy.com: build fix]
Signed-off-by: Tim Hockin 
Signed-off-by: William Irwin 
Signed-off-by: Andrew Morton 
Signed-off-by: Andi Kleen 
Signed-off-by: Linus Torvalds

wrap access to thread_info

2007-05-09T19:30:56+00:00

Recently a few direct accesses to the thread_info in the task structure snuck
back, so this wraps them with the appropriate wrapper.

Signed-off-by: Roman Zippel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] PM: Fix SMP races in the freezer

2006-12-13T17:05:49+00:00

Currently, to tell a task that it should go to the refrigerator, we set the
PF_FREEZE flag for it and send a fake signal to it.  Unfortunately there
are two SMP-related problems with this approach.  First, a task running on
another CPU may be updating its flags while the freezer attempts to set
PF_FREEZE for it and this may leave the task's flags in an inconsistent
state.  Second, there is a potential race between freeze_process() and
refrigerator() in which freeze_process() running on one CPU is reading a
task's PF_FREEZE flag while refrigerator() running on another CPU has just
set PF_FROZEN for the same task and attempts to reset PF_FREEZE for it.  If
the refrigerator wins the race, freeze_process() will state that PF_FREEZE
hasn't been set for the task and will set it unnecessarily, so the task
will go to the refrigerator once again after it's been thawed.

To solve first of these problems we need to stop using PF_FREEZE to tell
tasks that they should go to the refrigerator.  Instead, we can introduce a
special TIF_*** flag and use it for this purpose, since it is allowed to
change the other tasks' TIF_*** flags and there are special calls for it.

To avoid the freeze_process()-refrigerator() race we can make
freeze_process() to always check the task's PF_FROZEN flag after it's read
its "freeze" flag.  We should also make sure that refrigerator() will
always reset the task's "freeze" flag after it's set PF_FROZEN for it.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Pavel Machek 
Cc: Russell King 
Cc: David Howells 
Cc: Andi Kleen 
Cc: "Luck, Tony" 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Paul Mundt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] x86-64 TIF flags for debug regs and io bitmap in ctxsw

2006-09-26T08:52:28+00:00

Hello,

Following my discussion with Andi. Here is a patch that introduces
two new TIF flags to simplify the context switch code in __switch_to().
The idea is to minimize the number of cache lines accessed in the common
case, i.e., when neither the debug registers nor the I/O bitmap are used.

This patch covers the x86-64 modifications. A patch for i386 follows.

Changelog:
	- add TIF_DEBUG to track when debug registers are active
	- add TIF_IO_BITMAP to track when I/O bitmap is used
	- modify __switch_to() to use the new TIF flags

: eranian@hpl.hp.com

Signed-off-by: Andi Kleen

[PATCH] Add TIF_RESTORE_SIGMASK

2006-09-26T08:52:26+00:00

We need TIF_RESTORE_SIGMASK in order to support ppoll() and pselect()
system calls. This patch originally came from Andi, and was based
heavily on David Howells' implementation of same on i386. I fixed a typo
which was causing do_signal() to use the wrong signal mask.

Signed-off-by: David Woodhouse 
Signed-off-by: Andi Kleen

[PATCH] x86_64: x86_64 stack usage debugging

2006-06-26T17:48:22+00:00

Applies to git & 2.6.17-rc6 after CONFIG_DEBUG_STACKOVERFLOW patch

uses same stack-zeroing mechanism as on i386 to discover maximum stack
excursions.

Signed-off-by: Eric Sandeen 
Signed-off-by: Andi Kleen 
Signed-off-by: Linus Torvalds

[PATCH] i386/x86-64/ia64: Move polling flag into thread_info_status

2006-06-26T17:48:21+00:00

During some profiling I noticed that default_idle causes a lot of
memory traffic. I think that is caused by the atomic operations
to clear/set the polling flag in thread_info. There is actually
no reason to make this atomic - only the idle thread does it
to itself, other CPUs only read it. So I moved it into ti->status.

Converted i386/x86-64/ia64 for now because that was the easiest
way to fix ACPI which also manipulates these flags in its idle
function.

Cc: Nick Piggin 
Cc: Tony Luck 
Cc: Len Brown 
Signed-off-by: Andi Kleen 
Signed-off-by: Linus Torvalds

[PATCH] death of get_thread_info/put_thread_info

2006-01-12T17:08:59+00:00

{get,put}_thread_info() were introduced in 2.5.4 and never
had been called by anything in the tree.

Signed-off-by: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds