<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/arch, branch v2.6.20.7</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/arch?h=v2.6.20.7</id>
<link rel='self' href='https://git.amat.us/linux/atom/arch?h=v2.6.20.7'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2007-04-13T20:47:01Z</updated>
<entry>
<title>i386: fix file_read_actor() and pipe_read() for original i386 systems</title>
<updated>2007-04-13T20:47:01Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2007-04-02T12:25:31Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a63b596ec4b04fdf46bdc2d9c7410924ed4d9724'/>
<id>urn:sha1:a63b596ec4b04fdf46bdc2d9c7410924ed4d9724</id>
<content type='text'>
The __copy_to_user_inatomic() calls in file_read_actor() and pipe_read()
are broken on original i386 machines, where WP-works-ok == false, as
__copy_to_user_inatomic() on such systems calls functions which might
sleep and/or contain cond_resched() calls inside of a kmap_atomic()
region.

The original check for WP-works-ok was in access_ok(), but got moved
during the 2.5 series to fix a race vs. swap.

Return the number of bytes to copy in the case where we are in an atomic
region, so the non atomic code pathes in file_read_actor() and
pipe_read() are taken.

This could be optimized to avoid the kmap_atomic by moving the check for
WP-works-ok into fault_in_pages_writeable(), but this is more intrusive
and can be done later.

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Acked-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>uml: fix unreasonably long udelay</title>
<updated>2007-04-06T10:43:12Z</updated>
<author>
<name>Paolo 'Blaisorblade' Giarrusso</name>
<email>blaisorblade@yahoo.it</email>
</author>
<published>2007-03-28T23:26:11Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=16ad6a9070a33c1a624ace8880dd92803228a73d'/>
<id>urn:sha1:16ad6a9070a33c1a624ace8880dd92803228a73d</id>
<content type='text'>
Currently we have a confused udelay implementation.

* __const_udelay does not accept usecs but xloops in i386 and x86_64
* our implementation requires usecs as arg
* it gets a xloops count when called by asm/arch/delay.h

Bugs related to this (extremely long shutdown times) where reported by some
x86_64 users, especially using Device Mapper.

To hit this bug, a compile-time constant time parameter must be passed - that's
why UML seems to work most times.
Fix this with a simple udelay implementation.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso &lt;blaisorblade@yahoo.it&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>UML - use correct register file size everywhere</title>
<updated>2007-04-06T10:43:12Z</updated>
<author>
<name>Jeff Dike</name>
<email>jdike@addtoit.com</email>
</author>
<published>2007-03-25T17:01:44Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=93420eaf5b7ef59dc1de112419f854741d06bc66'/>
<id>urn:sha1:93420eaf5b7ef59dc1de112419f854741d06bc66</id>
<content type='text'>
This patch uses MAX_REG_NR consistently to refer to the register file
size.  FRAME_SIZE isn't sufficient because on x86_64, it is smaller
than the ptrace register file size.  MAX_REG_NR was introduced as a
consistent way to get the number of registers, but wasn't used
everywhere it should be.

When this causes a problem, it makes PTRACE_SETREGS fail on x86_64
because of a corrupted segment register value in the known-good
register file. The patch also adds a register dump at that point in
case there are any future problems here.

Signed-off-by: Jeff Dike &lt;jdike@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>UML - host VDSO fix</title>
<updated>2007-04-06T10:43:11Z</updated>
<author>
<name>Jeff Dike</name>
<email>jdike@addtoit.com</email>
</author>
<published>2007-03-23T19:37:30Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=6f6017090339ddb751b3c71840c214282214f6bc'/>
<id>urn:sha1:6f6017090339ddb751b3c71840c214282214f6bc</id>
<content type='text'>
This fixes a problem seen by a number of people running UML on newer host
kernels.  init would hang with an infinite segfault loop.

It turns out that the host kernel was providing a AT_SYSINFO_EHDR of
0xffffe000, which faked UML into believing that the host VDSO page could be
reused.  However, AT_SYSINFO pointed into the middle of the address space, and
was unmapped as a result.  Because UML was providing AT_SYSINFO_EHDR and
AT_SYSINFO to its own processes, these would branch to nowhere when trying to
use the VDSO.

The fix is to also check the location of AT_SYSINFO when deciding whether to
use the host's VDSO.

Signed-off-by: Jeff Dike &lt;jdike@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>Fix niagara memory corruption</title>
<updated>2007-03-23T19:49:27Z</updated>
<author>
<name>David Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2007-03-19T21:50:04Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=9c06278212e2d8f050fbd6ca9cb277836b3c523d'/>
<id>urn:sha1:9c06278212e2d8f050fbd6ca9cb277836b3c523d</id>
<content type='text'>
[SPARC64]: store-init needs trailing membar.

The manual says that it is required and we actually have crash reports
where loads see stale data due to not having membars here.

In one case the networking does:

	memset(skb, 0, offsetof(struct sk_buff, truesize));

and then some code later checks skb-&gt;nohdr for zero, but it's still
the value that was there before the memset().

Note that arch/sparc64/lib/xor.S already got this right.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>UML - arch_prctl should set thread fs</title>
<updated>2007-03-23T19:49:27Z</updated>
<author>
<name>Jeff Dike</name>
<email>jdike@addtoit.com</email>
</author>
<published>2007-03-19T20:12:50Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a0518e0445325892f9a92fbd19cbfdb0eecfdb3e'/>
<id>urn:sha1:a0518e0445325892f9a92fbd19cbfdb0eecfdb3e</id>
<content type='text'>
x86_64 needs some TLS fixes.  What was missing was remembering the child
thread id during clone and stuffing it into the child during each context
switch.

The %fs value is stored separately in the thread structure since the host
controls what effect it has on the actual register file.  The host also needs
to store it in its own thread struct, so we need the value kept outside the
register file.

arch_prctl_skas was fixed to call PTRACE_ARCH_PRCTL appropriately.  There is
some saving and restoring of registers in the ARCH_SET_* cases so that the
correct set of registers are changed on the host and restored to the process
when it runs again.

Signed-off-by: Jeff Dike &lt;jdike@addtoit.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>Fix page allocation debugging on sparc64</title>
<updated>2007-03-23T19:49:26Z</updated>
<author>
<name>David Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2007-03-17T01:51:00Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=e7afe7add33b3c467999376ac22d819fa7bcade8'/>
<id>urn:sha1:e7afe7add33b3c467999376ac22d819fa7bcade8</id>
<content type='text'>
[SPARC64]: Get DEBUG_PAGEALLOC working again.

We have to make sure to use base-pagesize TLB entries even during the
early transition period where we need TLB miss handling but don't have
the kernel page tables setup yet for the linear region.

Also, it is necessary therefore to not use the 4MB TSB for these
translations, and instead use the normal kernel TSB.  This allows us
to also get rid of the 4MB tsb for debug builds which shrinks the
kernel a little bit.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>Fix sparc64 hugepage bugs</title>
<updated>2007-03-23T19:49:26Z</updated>
<author>
<name>David Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2007-03-17T01:49:06Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b5c5ded3e7922dbbb45a2f7183d500514185eab8'/>
<id>urn:sha1:b5c5ded3e7922dbbb45a2f7183d500514185eab8</id>
<content type='text'>
[SPARC64]: Add missing HPAGE_MASK masks on address parameters.

These pte loops all assume the passed in address is HPAGE
aligned, make sure that is actually true.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>IA64: fix NULL pointer in ia64/irq_chip-mask/unmask function</title>
<updated>2007-03-23T19:49:22Z</updated>
<author>
<name>KAMEZAWA Hiroyuki</name>
<email>kamezawa.hiroyu@jp.fujitsu.com</email>
</author>
<published>2007-03-13T18:00:39Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1891665fed2eeb8c0170f9ccca8a045292ec3089'/>
<id>urn:sha1:1891665fed2eeb8c0170f9ccca8a045292ec3089</id>
<content type='text'>
[IA64] fix NULL pointer in ia64/irq_chip-mask/unmask function

This patch fixes boot failure because irq_desc-&gt;mask() is NULL.

- Added mask/unmask functions to ia64's irq desc function table.
- rename hw_interrupt_type to irq_chip. hw_interrupt_type is old name.
- Tony: Added same change to arch/ia64/sn/kernel/irq.c as pointed out
  by Eric Biederman ... mask/unmask functions there can be no-op.

Signed-off-by: KAMEZAWA Hiroyuki &lt;kamezawa.hiroyu@jp.fujitsu.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
Cc: Chuck Ebbert &lt;cebbert@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>Fix sparc64 device register probing</title>
<updated>2007-03-13T18:26:47Z</updated>
<author>
<name>David Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2007-03-08T02:47:54Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=46bda9eca2e14448ec85272259fb7d4aa5ac32b8'/>
<id>urn:sha1:46bda9eca2e14448ec85272259fb7d4aa5ac32b8</id>
<content type='text'>
[SPARC]: Fix bus handling in build_device_resources().

We mistakedly modify 'bus' in the innermost loop.  What
should happen is that at each register index iteration,
we start with the same 'bus'.

So preserve it's value at the top level, and use a loop
local variable 'dbus' for iteration.

This bug causes registers other than the first to be
decoded improperly.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
</feed>
