<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/i386/kernel/process.c, branch linux-2.6.13.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.13.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.13.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2005-07-27T23:26:08Z</updated>
<entry>
<title>[PATCH] sys_get_thread_area does not clear the returned argument</title>
<updated>2005-07-27T23:26:08Z</updated>
<author>
<name>Blaisorblade</name>
</author>
<published>2005-07-27T18:45:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=71ae18ec690953e9ba7107c7cc44589c2cc0d9f1'/>
<id>urn:sha1:71ae18ec690953e9ba7107c7cc44589c2cc0d9f1</id>
<content type='text'>
sys_get_thread_area does not memset to 0 its struct user_desc info before
copying it to user space...  since sizeof(struct user_desc) is 16 while the
actual datas which are filled are only 12 bytes + 9 bits (across the
bitfields), there is a (small) information leak.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso &lt;blaisorblade@yahoo.it&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
<entry>
<title>Fix up incorrect "unlikely()" on %gs reload in x86 __switch_to</title>
<updated>2005-07-22T19:23:47Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2005-07-22T19:23:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b339a18b81a1f6ca1455559594f5df872b9e59f4'/>
<id>urn:sha1:b339a18b81a1f6ca1455559594f5df872b9e59f4</id>
<content type='text'>
These days %gs is normally the TLS segment, so it's no longer zero.  As
a result, we shouldn't just assume that %fs/%gs tend to be zero
together, but test them independently instead.

Also, fix setting of debug registers to use the "next" pointer instead
of "current".  It so happens that the scheduler will have set the new
current pointer before calling __switch_to(), but that's just an
implementation detail.
</content>
</entry>
<entry>
<title>[PATCH] seccomp: tsc disable</title>
<updated>2005-06-27T22:11:44Z</updated>
<author>
<name>Andrea Arcangeli</name>
</author>
<published>2005-06-27T21:36:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ffaa8bd6c904d1ab79b677905067349a5ff51d84'/>
<id>urn:sha1:ffaa8bd6c904d1ab79b677905067349a5ff51d84</id>
<content type='text'>
I believe at least for seccomp it's worth to turn off the tsc, not just for
HT but for the L2 cache too.  So it's up to you, either you turn it off
completely (which isn't very nice IMHO) or I recommend to apply this below
patch.

This has been tested successfully on x86-64 against current cogito
repository (i686 compiles so I didn't bother testing ;).  People selling
the cpu through cpushare may appreciate this bit for a peace of mind.

There's no way to get any timing info anymore with this applied
(gettimeofday is forbidden of course).  The seccomp environment is
completely deterministic so it can't be allowed to get timing info, it has
to be deterministic so in the future I can enable a computing mode that
does a parallel computing for each task with server side transparent
checkpointing and verification that the output is the same from all the 2/3
seller computers for each task, without the buyer even noticing (for now
the verification is left to the buyer client side and there's no
checkpointing, since that would require more kernel changes to track the
dirty bits but it'll be easy to extend once the basic mode is finished).

Eliminating a cold-cache read of the cr4 global variable will save one
cacheline during the tlb flush while making the code per-cpu-safe at the
same time.  Thanks to Mikael Pettersson for noticing the tlb flush wasn't
per-cpu-safe.

The global tlb flush can run from irq (IPI calling do_flush_tlb_all) but
it'll be transparent to the switch_to code since the IPI won't make any
change to the cr4 contents from the point of view of the interrupted code
and since it's now all per-cpu stuff, it will not race.  So no need to
disable irqs in switch_to slow path.

Signed-off-by: Andrea Arcangeli &lt;andrea@cpushare.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] cpu state clean after hot remove</title>
<updated>2005-06-25T23:24:30Z</updated>
<author>
<name>Li Shaohua</name>
</author>
<published>2005-06-25T21:54:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e1367daf3eed5cd619ee88c9907e1e6ddaa58406'/>
<id>urn:sha1:e1367daf3eed5cd619ee88c9907e1e6ddaa58406</id>
<content type='text'>
Clean CPU states in order to reuse smp boot code for CPU hotplug.

Signed-off-by: Li Shaohua&lt;shaohua.li@intel.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] init call cleanup</title>
<updated>2005-06-25T23:24:30Z</updated>
<author>
<name>Li Shaohua</name>
</author>
<published>2005-06-25T21:54:55Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0bb3184df537002a742bafddf3f4fb482b7fe610'/>
<id>urn:sha1:0bb3184df537002a742bafddf3f4fb482b7fe610</id>
<content type='text'>
Trival patch for CPU hotplug.  In CPU identify part, only did cleaup for intel
CPUs.  Need do for other CPUs if they support S3 SMP.

Signed-off-by: Li Shaohua&lt;shaohua.li@intel.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] i386 CPU hotplug</title>
<updated>2005-06-25T23:24:29Z</updated>
<author>
<name>Zwane Mwaikambo</name>
</author>
<published>2005-06-25T21:54:50Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f370513640492641b4046bfd9a6e4714f6ae530d'/>
<id>urn:sha1:f370513640492641b4046bfd9a6e4714f6ae530d</id>
<content type='text'>
(The i386 CPU hotplug patch provides infrastructure for some work which Pavel
is doing as well as for ACPI S3 (suspend-to-RAM) work which Li Shaohua
&lt;shaohua.li@intel.com&gt; is doing)

The following provides i386 architecture support for safely unregistering and
registering processors during runtime, updated for the current -mm tree.  In
order to avoid dumping cpu hotplug code into kernel/irq/* i dropped the
cpu_online check in do_IRQ() by modifying fixup_irqs().  The difference being
that on cpu offline, fixup_irqs() is called before we clear the cpu from
cpu_online_map and a long delay in order to ensure that we never have any
queued external interrupts on the APICs.  There are additional changes to s390
and ppc64 to account for this change.

1) Add CONFIG_HOTPLUG_CPU
2) disable local APIC timer on dead cpus.
3) Disable preempt around irq balancing to prevent CPUs going down.
4) Print irq stats for all possible cpus.
5) Debugging check for interrupts on offline cpus.
6) Hacky fixup_irqs() to redirect irqs when cpus go off/online.
7) play_dead() for offline cpus to spin inside.
8) Handle offline cpus set in flush_tlb_others().
9) Grab lock earlier in smp_call_function() to prevent CPUs going down.
10) Implement __cpu_disable() and __cpu_die().
11) Enable local interrupts in cpu_enable() after fixup_irqs()
12) Don't fiddle with NMI on dead cpu, but leave intact on other cpus.
13) Program IRQ affinity whilst cpu is still in cpu_online_map on offline.

Signed-off-by: Zwane Mwaikambo &lt;zwane@linuxpower.ca&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] kprobes: function-return probes</title>
<updated>2005-06-23T16:45:21Z</updated>
<author>
<name>Hien Nguyen</name>
</author>
<published>2005-06-23T07:09:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b94cce926b2b902b79380ccba370d6f9f2980de0'/>
<id>urn:sha1:b94cce926b2b902b79380ccba370d6f9f2980de0</id>
<content type='text'>
This patch adds function-return probes to kprobes for the i386
architecture.  This enables you to establish a handler to be run when a
function returns.

1. API

Two new functions are added to kprobes:

	int register_kretprobe(struct kretprobe *rp);
	void unregister_kretprobe(struct kretprobe *rp);

2. Registration and unregistration

2.1 Register

  To register a function-return probe, the user populates the following
  fields in a kretprobe object and calls register_kretprobe() with the
  kretprobe address as an argument:

  kp.addr - the function's address

  handler - this function is run after the ret instruction executes, but
  before control returns to the return address in the caller.

  maxactive - The maximum number of instances of the probed function that
  can be active concurrently.  For example, if the function is non-
  recursive and is called with a spinlock or mutex held, maxactive = 1
  should be enough.  If the function is non-recursive and can never
  relinquish the CPU (e.g., via a semaphore or preemption), NR_CPUS should
  be enough.  maxactive is used to determine how many kretprobe_instance
  objects to allocate for this particular probed function.  If maxactive &lt;=
  0, it is set to a default value (if CONFIG_PREEMPT maxactive=max(10, 2 *
  NR_CPUS) else maxactive=NR_CPUS)

  For example:

    struct kretprobe rp;
    rp.kp.addr = /* entrypoint address */
    rp.handler = /*return probe handler */
    rp.maxactive = /* e.g., 1 or NR_CPUS or 0, see the above explanation */
    register_kretprobe(&amp;rp);

  The following field may also be of interest:

  nmissed - Initialized to zero when the function-return probe is
  registered, and incremented every time the probed function is entered but
  there is no kretprobe_instance object available for establishing the
  function-return probe (i.e., because maxactive was set too low).

2.2 Unregister

  To unregiter a function-return probe, the user calls
  unregister_kretprobe() with the same kretprobe object as registered
  previously.  If a probed function is running when the return probe is
  unregistered, the function will return as expected, but the handler won't
  be run.

3. Limitations

3.1 This patch supports only the i386 architecture, but patches for
    x86_64 and ppc64 are anticipated soon.

3.2 Return probes operates by replacing the return address in the stack
    (or in a known register, such as the lr register for ppc).  This may
    cause __builtin_return_address(0), when invoked from the return-probed
    function, to return the address of the return-probes trampoline.

3.3 This implementation uses the "Multiprobes at an address" feature in
    2.6.12-rc3-mm3.

3.4 Due to a limitation in multi-probes, you cannot currently establish
    a return probe and a jprobe on the same function.  A patch to remove
    this limitation is being tested.

This feature is required by SystemTap (http://sourceware.org/systemtap),
and reflects ideas contributed by several SystemTap developers, including
Will Cohen and Ananth Mavinakayanahalli.

Signed-off-by: Hien Nguyen &lt;hien@us.ibm.com&gt;
Signed-off-by: Prasanna S Panchamukhi &lt;prasanna@in.ibm.com&gt;
Signed-off-by: Frederik Deweerdt &lt;frederik.deweerdt@laposte.net&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] xen: x86: Use more usermode macro</title>
<updated>2005-06-23T16:45:14Z</updated>
<author>
<name>Vincent Hanquez</name>
</author>
<published>2005-06-23T07:08:45Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=717b594a415bfaf2dbd5e8266636488f2564c689'/>
<id>urn:sha1:717b594a415bfaf2dbd5e8266636488f2564c689</id>
<content type='text'>
Use the user_mode macro where it's possible.

Signed-off-by: Vincent Hanquez &lt;vincent.hanquez@cl.cam.ac.uk&gt;
Cc: Ian Pratt &lt;m+Ian.Pratt@cl.cam.ac.uk&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] xen: x86: Use new macro for debugreg</title>
<updated>2005-06-23T16:45:13Z</updated>
<author>
<name>Vincent Hanquez</name>
</author>
<published>2005-06-23T07:08:43Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1cc6f12e03ebc064b74161c684f987284ce9d0cc'/>
<id>urn:sha1:1cc6f12e03ebc064b74161c684f987284ce9d0cc</id>
<content type='text'>
Make use of the 2 new macro set_debugreg and get_debugreg.

Signed-off-by: Vincent Hanquez &lt;vincent.hanquez@cl.cam.ac.uk&gt;
Cc: Ian Pratt &lt;m+Ian.Pratt@cl.cam.ac.uk&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] Remove i386_ksyms.c, almost.</title>
<updated>2005-06-23T16:45:11Z</updated>
<author>
<name>Alexey Dobriyan</name>
</author>
<published>2005-06-23T07:08:33Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=129f69465b411592247c408f93d7106939223be1'/>
<id>urn:sha1:129f69465b411592247c408f93d7106939223be1</id>
<content type='text'>
* EXPORT_SYMBOL's moved to other files
* #include &lt;linux/config.h&gt;, &lt;linux/module.h&gt; where needed
* #include's in i386_ksyms.c cleaned up
* After copy-paste, redundant due to Makefiles rules preprocessor directives
  removed:

	#ifdef CONFIG_FOO
	EXPORT_SYMBOL(foo);
	#endif

	obj-$(CONFIG_FOO) += foo.o

* Tiny reformat to fit in 80 columns

Signed-off-by: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
</feed>
