<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/x86/include/asm/system.h, branch linux-2.6.30.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.30.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.30.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2009-09-24T15:27:21Z</updated>
<entry>
<title>x86/i386: Make sure stack-protector segment base is cache aligned</title>
<updated>2009-09-24T15:27:21Z</updated>
<author>
<name>Jeremy Fitzhardinge</name>
</author>
<published>2009-09-03T19:27:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0863b5e00d32b9adaf93226c893918af297b74f3'/>
<id>urn:sha1:0863b5e00d32b9adaf93226c893918af297b74f3</id>
<content type='text'>
commit 1ea0d14e480c245683927eecc03a70faf06e80c8 upstream.

The Intel Optimization Reference Guide says:

	In Intel Atom microarchitecture, the address generation unit
	assumes that the segment base will be 0 by default. Non-zero
	segment base will cause load and store operations to experience
	a delay.
		- If the segment base isn't aligned to a cache line
		  boundary, the max throughput of memory operations is
		  reduced to one [e]very 9 cycles.
	[...]
	Assembly/Compiler Coding Rule 15. (H impact, ML generality)
	For Intel Atom processors, use segments with base set to 0
	whenever possible; avoid non-zero segment base address that is
	not aligned to cache line boundary at all cost.

We can't avoid having a non-zero base for the stack-protector
segment, but we can make it cache-aligned.

Signed-off-by: Jeremy Fitzhardinge &lt;jeremy.fitzhardinge@citrix.com&gt;
LKML-Reference: &lt;4AA01893.6000507@goop.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>x86: add forward decl for tss_struct</title>
<updated>2009-03-02T11:07:49Z</updated>
<author>
<name>Jeremy Fitzhardinge</name>
</author>
<published>2009-02-27T21:25:33Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2fb6b2a048ed8fa3f049c7d42f7a2dd3f0c8d7a6'/>
<id>urn:sha1:2fb6b2a048ed8fa3f049c7d42f7a2dd3f0c8d7a6</id>
<content type='text'>
Its the correct thing to do before using the struct in a prototype.

Signed-off-by: Jeremy Fitzhardinge &lt;jeremy.fitzhardinge@citrix.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
<entry>
<title>x86: unify chunks of kernel/process*.c</title>
<updated>2009-03-02T11:07:48Z</updated>
<author>
<name>Jeremy Fitzhardinge</name>
</author>
<published>2009-02-27T21:25:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=389d1fb11e5f2a16b5e34c547756f0c4dec641f7'/>
<id>urn:sha1:389d1fb11e5f2a16b5e34c547756f0c4dec641f7</id>
<content type='text'>
With x86-32 and -64 using the same mechanism for managing the
tss io permissions bitmap, large chunks of process*.c are
trivially unifyable, including:

 - exit_thread
 - flush_thread
 - __switch_to_xtra (along with tsc enable/disable)

and as bonus pickups:

 - sys_fork
 - sys_vfork

(Note: asmlinkage expands to empty on x86-64)

Signed-off-by: Jeremy Fitzhardinge &lt;jeremy.fitzhardinge@citrix.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
<entry>
<title>Merge branch 'core/percpu' into x86/core</title>
<updated>2009-02-13T08:45:09Z</updated>
<author>
<name>Ingo Molnar</name>
</author>
<published>2009-02-13T08:45:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ab639f3593f0b5e4439d549831442c18c3baf989'/>
<id>urn:sha1:ab639f3593f0b5e4439d549831442c18c3baf989</id>
<content type='text'>
</content>
</entry>
<entry>
<title>x86: fix x86_32 stack protector bugs</title>
<updated>2009-02-11T10:33:49Z</updated>
<author>
<name>Tejun Heo</name>
</author>
<published>2009-02-11T07:31:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5c79d2a517a9905599d192db8ce77ab5f1a2faca'/>
<id>urn:sha1:5c79d2a517a9905599d192db8ce77ab5f1a2faca</id>
<content type='text'>
Impact: fix x86_32 stack protector

Brian Gerst found out that %gs was being initialized to stack_canary
instead of stack_canary - 20, which basically gave the same canary
value for all threads.  Fixing this also exposed the following bugs.

* cpu_idle() didn't call boot_init_stack_canary()

* stack canary switching in switch_to() was being done too late making
  the initial run of a new thread use the old stack canary value.

Fix all of them and while at it update comment in cpu_idle() about
calling boot_init_stack_canary().

Reported-by: Brian Gerst &lt;brgerst@gmail.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
<entry>
<title>x86: implement x86_32 stack protector</title>
<updated>2009-02-09T23:42:01Z</updated>
<author>
<name>Tejun Heo</name>
</author>
<published>2009-02-09T13:17:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=60a5317ff0f42dd313094b88f809f63041568b08'/>
<id>urn:sha1:60a5317ff0f42dd313094b88f809f63041568b08</id>
<content type='text'>
Impact: stack protector for x86_32

Implement stack protector for x86_32.  GDT entry 28 is used for it.
It's set to point to stack_canary-20 and have the length of 24 bytes.
CONFIG_CC_STACKPROTECTOR turns off CONFIG_X86_32_LAZY_GS and sets %gs
to the stack canary segment on entry.  As %gs is otherwise unused by
the kernel, the canary can be anywhere.  It's defined as a percpu
variable.

x86_32 exception handlers take register frame on stack directly as
struct pt_regs.  With -fstack-protector turned on, gcc copies the
whole structure after the stack canary and (of course) doesn't copy
back on return thus losing all changed.  For now, -fno-stack-protector
is added to all files which contain those functions.  We definitely
need something better.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
<entry>
<title>x86: make lazy %gs optional on x86_32</title>
<updated>2009-02-09T23:42:00Z</updated>
<author>
<name>Tejun Heo</name>
</author>
<published>2009-02-09T13:17:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ccbeed3a05908d201b47b6c3dd1a373138bba566'/>
<id>urn:sha1:ccbeed3a05908d201b47b6c3dd1a373138bba566</id>
<content type='text'>
Impact: pt_regs changed, lazy gs handling made optional, add slight
        overhead to SAVE_ALL, simplifies error_code path a bit

On x86_32, %gs hasn't been used by kernel and handled lazily.  pt_regs
doesn't have place for it and gs is saved/loaded only when necessary.
In preparation for stack protector support, this patch makes lazy %gs
handling optional by doing the followings.

* Add CONFIG_X86_32_LAZY_GS and place for gs in pt_regs.

* Save and restore %gs along with other registers in entry_32.S unless
  LAZY_GS.  Note that this unfortunately adds "pushl $0" on SAVE_ALL
  even when LAZY_GS.  However, it adds no overhead to common exit path
  and simplifies entry path with error code.

* Define different user_gs accessors depending on LAZY_GS and add
  lazy_save_gs() and lazy_load_gs() which are noop if !LAZY_GS.  The
  lazy_*_gs() ops are used to save, load and clear %gs lazily.

* Define ELF_CORE_COPY_KERNEL_REGS() which always read %gs directly.

xen and lguest changes need to be verified.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Cc: Jeremy Fitzhardinge &lt;jeremy@xensource.com&gt;
Cc: Rusty Russell &lt;rusty@rustcorp.com.au&gt;

Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
<entry>
<title>x86: add %gs accessors for x86_32</title>
<updated>2009-02-09T23:41:58Z</updated>
<author>
<name>Tejun Heo</name>
</author>
<published>2009-02-09T13:17:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d9a89a26e02ef9ed03f74a755a8b4d8f3a066622'/>
<id>urn:sha1:d9a89a26e02ef9ed03f74a755a8b4d8f3a066622</id>
<content type='text'>
Impact: cleanup

On x86_32, %gs is handled lazily.  It's not saved and restored on
kernel entry/exit but only when necessary which usually is during task
switch but there are few other places.  Currently, it's done by
calling savesegment() and loadsegment() explicitly.  Define
get_user_gs(), set_user_gs() and task_user_gs() and use them instead.

While at it, clean up register access macros in signal.c.

This cleans up code a bit and will help future changes.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
<entry>
<title>Merge branches 'x86/asm', 'x86/cleanups', 'x86/cpudetect', 'x86/debug', 'x86/doc', 'x86/header-fixes', 'x86/mm', 'x86/paravirt', 'x86/pat', 'x86/setup-v2', 'x86/subarch', 'x86/uaccess' and 'x86/urgent' into x86/core</title>
<updated>2009-01-28T22:13:53Z</updated>
<author>
<name>Ingo Molnar</name>
</author>
<published>2009-01-28T22:13:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=74b6eb6b937df07d0757e8642b7538b07da4290f'/>
<id>urn:sha1:74b6eb6b937df07d0757e8642b7538b07da4290f</id>
<content type='text'>
</content>
</entry>
<entry>
<title>x86: update canary handling during switch</title>
<updated>2009-01-21T08:26:05Z</updated>
<author>
<name>Tejun Heo</name>
</author>
<published>2009-01-21T08:26:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=67e68bde02fe783efc2ce2ca31bdb992f5235f8d'/>
<id>urn:sha1:67e68bde02fe783efc2ce2ca31bdb992f5235f8d</id>
<content type='text'>
Impact: cleanup

In switch_to(), instead of taking offset to irq_stack_union.stack,
make it a proper percpu access using __percpu_arg() and per_cpu_var().

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
</content>
</entry>
</feed>
