]> git.kernelconcepts.de Git - karo-tx-linux.git/log
karo-tx-linux.git
17 years agoLinux 2.6.19.3 v2.6.19.3
Chris Wright [Mon, 5 Feb 2007 16:31:59 +0000 (08:31 -0800)]
Linux 2.6.19.3

17 years ago[PATCH] sched: fix cond_resched_softirq() offset
Ingo Molnar [Sat, 30 Dec 2006 00:48:13 +0000 (16:48 -0800)]
[PATCH] sched: fix cond_resched_softirq() offset

Remove the __resched_legal() check: it is conceptually broken.  The biggest
problem it had is that it can mask buggy cond_resched() calls.  A
cond_resched() call is only legal if we are not in an atomic context, with
two narrow exceptions:

 - if the system is booting
 - a reacquire_kernel_lock() down() done while PREEMPT_ACTIVE is set

But __resched_legal() hid this and just silently returned whenever
these primitives were called from invalid contexts. (Same goes for
cond_resched_locked() and cond_resched_softirq()).

Furthermore, the __legal_resched(0) call was buggy in that it caused
unnecessarily long softirq latencies via cond_resched_softirq().  (which is
only called from softirq-off sections, hence the code did nothing.)

The fix is to resurrect the efficiency of the might_sleep checks and to
only allow the narrow exceptions.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[chrisw: backport to 2.6.19.2]
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] move_task_off_dead_cpu() should be called with disabled ints
Kirill Korotaev [Sun, 10 Dec 2006 10:20:11 +0000 (02:20 -0800)]
[PATCH] move_task_off_dead_cpu() should be called with disabled ints

move_task_off_dead_cpu() requires interrupts to be disabled, while
migrate_dead() calls it with enabled interrupts.  Added appropriate
comments to functions and added BUG_ON(!irqs_disabled()) into
double_rq_lock() and double_lock_balance() which are the origin sources of
such bugs.

Signed-off-by: Kirill Korotaev <dev@openvz.org>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] SUNRPC: Give cloned RPC clients their own rpc_pipefs directory
Trond Myklebust [Thu, 25 Jan 2007 04:13:46 +0000 (20:13 -0800)]
[PATCH] SUNRPC: Give cloned RPC clients their own rpc_pipefs directory

This patch fixes a regression in 2.6.19 in which the use of multiple
krb5 mounts against the same NFS server may result in an Oops on
unmount. The Oops is due to the fact that multiple NFS krb5 clients may
end up inadvertently sharing the same rpc_pipefs upcall pipe. The first
client to 'umount' will unlink that shared pipe, causing an Oops.

The solution is to give each client their own upcall pipe. This fix has
been in mainline since 2.6.20-rc1.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
[chrisw: backport to 2.6.19.2]
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] NETFILTER: xt_connbytes: fix division by zero
Patrick McHardy [Wed, 31 Jan 2007 00:27:29 +0000 (01:27 +0100)]
[PATCH] NETFILTER: xt_connbytes: fix division by zero

When the packet counter of a connection is zero a division by zero
occurs in div64_64(). Fix that by using zero as average value, which
is correct as long as the packet counter didn't overflow, at which
point we have lost anyway.

Additionally we're probably going to go back to 64 bit counters
in 2.6.21.

Based on patch from Jonas Berlin <xkr47@outerspace.dyndns.org>,
with suggestions from KOVACS Krisztian <hidden@balabit.hu>.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] TCP: skb is unexpectedly freed.
Masayuki Nakagawa [Fri, 2 Feb 2007 21:17:13 +0000 (13:17 -0800)]
[PATCH] TCP: skb is unexpectedly freed.

I encountered a kernel panic with my test program, which is a very
simple IPv6 client-server program.

The server side sets IPV6_RECVPKTINFO on a listening socket, and the
client side just sends a message to the server.  Then the kernel panic
occurs on the server.  (If you need the test program, please let me
know. I can provide it.)

This problem happens because a skb is forcibly freed in
tcp_rcv_state_process().

When a socket in listening state(TCP_LISTEN) receives a syn packet,
then tcp_v6_conn_request() will be called from
tcp_rcv_state_process().  If the tcp_v6_conn_request() successfully
returns, the skb would be discarded by __kfree_skb().

However, in case of a listening socket which was already set
IPV6_RECVPKTINFO, an address of the skb will be stored in
treq->pktopts and a ref count of the skb will be incremented in
tcp_v6_conn_request().  But, even if the skb is still in use, the skb
will be freed.  Then someone still using the freed skb will cause the
kernel panic.

I suggest to use kfree_skb() instead of __kfree_skb().

Signed-off-by: Masayuki Nakagawa <nakagawa.msy@ncos.nec.co.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] TCP: Fix sorting of SACK blocks.
Baruch Even [Fri, 2 Feb 2007 21:16:09 +0000 (13:16 -0800)]
[PATCH] TCP: Fix sorting of SACK blocks.

The sorting of SACK blocks actually munges them rather than sort,
causing the TCP stack to ignore some SACK information and breaking the
assumption of ordered SACK blocks after sorting.

The sort takes the data from a second buffer which isn't moved causing
subsequent data moves to occur from the wrong location. The fix is to
use a temporary buffer as a normal sort does.

Signed-off-By: Baruch Even <baruch@ev-en.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] TCP: rare bad TCP checksum with 2.6.19
Jarek Poplawski [Fri, 2 Feb 2007 21:15:00 +0000 (13:15 -0800)]
[PATCH] TCP: rare bad TCP checksum with 2.6.19

The patch "Replace CHECKSUM_HW by CHECKSUM_PARTIAL/CHECKSUM_COMPLETE"
changed to unconditional copying of ip_summed field from collapsed
skb. This patch reverts this change.

The majority of substantial work including heavy testing
and diagnosing by: Michael Tokarev <mjt@tls.msk.ru>
Possible reasons pointed by: Herbert Xu and Patrick McHardy.

Signed-off-by: Jarek Poplawski <jarkao2@o2.pl>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] AF_PACKET: Check device down state before hard header callbacks.
David S. Miller [Fri, 2 Feb 2007 21:01:28 +0000 (13:01 -0800)]
[PATCH] AF_PACKET: Check device down state before hard header callbacks.

If the device is down, invoking the device hard header callbacks
is not legal, so check it early.

Based upon a shaper OOPS report from Frederik Deweerdt.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] AF_PACKET: Fix BPF handling.
David S. Miller [Fri, 2 Feb 2007 21:06:03 +0000 (13:06 -0800)]
[PATCH] AF_PACKET: Fix BPF handling.

This fixes a bug introduced by:

commit fda9ef5d679b07c9d9097aaf6ef7f069d794a8f9
Author: Dmitry Mishin <dim@openvz.org>
Date:   Thu Aug 31 15:28:39 2006 -0700

    [NET]: Fix sk->sk_filter field access

sk_run_filter() returns either 0 or an unsigned 32-bit
length which says how much of the packet to retain.
If that 32-bit unsigned integer is larger than the packet,
this is fine we just leave the packet unchanged.

The above commit caused all filter return values which
were negative when interpreted as a signed integer to
indicate a packet drop, which is wrong.

Based upon a report and initial patch by Raivis Bucis.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] IPV4: Fix single-entry /proc/net/fib_trie output.
Robert Olsson [Fri, 2 Feb 2007 20:58:58 +0000 (12:58 -0800)]
[PATCH] IPV4: Fix single-entry /proc/net/fib_trie output.

When main table is just a single leaf this gets printed as belonging to the
local table in /proc/net/fib_trie. A fix is below.

Signed-off-by: Robert Olsson <robert.olsson@its.uu.se>
Acked-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] IPV4: Fix the fib trie iterator to work with a single entry routing tables
Eric W. Biederman [Fri, 2 Feb 2007 20:57:16 +0000 (12:57 -0800)]
[PATCH] IPV4: Fix the fib trie iterator to work with a single entry routing tables

In a kernel with trie routing enabled I had a simple routing setup
with only a single route to the outside world and no default
route. "ip route table list main" showed my the route just fine but
/proc/net/route was an empty file.  What was going on?

Thinking it was a bug in something I did and I looked deeper.  Eventually
I setup a second route and everything looked correct, huh?  Finally I
realized that the it was just the iterator pair in fib_trie_get_first,
fib_trie_get_next just could not handle a routing table with a single entry.

So to save myself and others further confusion, here is a simple fix for
the fib proc iterator so it works even when there is only a single route
in a routing table.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Robert Olsson <robert.olsson@its.uu.se>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] SPARC32: Fix over-optimization by GCC near ip_fast_csum.
Bob Breuer [Fri, 2 Feb 2007 20:52:15 +0000 (12:52 -0800)]
[PATCH] SPARC32: Fix over-optimization by GCC near ip_fast_csum.

In some cases such as:
iph->check = 0;
iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl);
GCC may optimize out the previous store.

Observed as a failure of NFS over udp (bad checksums on ip fragments)
when compiled with GCC 3.4.2.

Signed-off-by: Bob Breuer <breuerr@mc.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] DECNET: Handle a failure in neigh_parms_alloc (take 2)
Eric W. Biederman [Fri, 2 Feb 2007 20:50:23 +0000 (12:50 -0800)]
[PATCH] DECNET: Handle a failure in neigh_parms_alloc (take 2)

While enhancing the neighbour code to handle multiple network
namespaces I noticed that decnet is assuming neigh_parms_alloc
will allways succeed, which is clearly wrong.  So handle the
failure.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Acked-by: Steven Whitehouse <steve@chygwyn.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] jmicron: 40/80pin primary detection
ethanhsiao@jmicron.com [Tue, 30 Jan 2007 22:36:13 +0000 (14:36 -0800)]
[PATCH] jmicron: 40/80pin primary detection

jmicron module detects all JMB36x as JMB361 and PATA0 has wrong pin status
of XICBLID.

Cc: Jeff Garzik <jeff@garzik.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
cebbert@redhat.com: I folded in the warning fix (a51545ab25) because
otherwise it makes the tester think the patch caused the warning
that was already there.

Cc: Dave Jones <davej@redhat.com>
Signed-off-by: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] bonding: ARP monitoring broken on x86_64
Andy Gospodarek [Mon, 29 Jan 2007 20:08:38 +0000 (12:08 -0800)]
[PATCH] bonding: ARP monitoring broken on x86_64

While working with the latest bonding code I noticed a nasty problem that
will prevent arp monitoring from always functioning correctly on x86_64
systems.  Comparing ints to longs and expecting reliable results on x86_64
is a bad idea.  With this patch, arp monitoring works correctly again.

Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Stephen Hemminger <shemminger@osdl.org>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] uml: fix signal frame alignment
Jeff Dike [Tue, 30 Jan 2007 22:36:17 +0000 (14:36 -0800)]
[PATCH] uml: fix signal frame alignment

Use the same signal frame alignment calculations as the underlying
architecture.  x86_64 appeared to do this, but the "- 8" was really
subtracting 8 * sizeof(struct rt_sigframe) rather than 8 bytes.

UML/i386 might have been OK, but I changed the calculation to match
i386 just to be sure.

Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: <stable@kernel.org>
Cc: Adrian Bunk <bunk@stusta.de>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Acked-by: Antoine Martin <antoine@nagafix.co.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] Don't allow the stack to grow into hugetlb reserved regions
Adam Litke [Tue, 30 Jan 2007 22:35:39 +0000 (14:35 -0800)]
[PATCH] Don't allow the stack to grow into hugetlb reserved regions

When expanding the stack, we don't currently check if the VMA will cross
into an area of the address space that is reserved for hugetlb pages.
Subsequent faults on the expanded portion of such a VMA will confuse the
low-level MMU code, resulting in an OOPS.  Check for this.

Signed-off-by: Adam Litke <agl@us.ibm.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: William Lee Irwin III <wli@holomorphy.com>
Cc: Hugh Dickins <hugh@veritas.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] libata: use kmap_atomic(KM_IRQ0) in SCSI simulator
Jeff Garzik [Mon, 11 Dec 2006 16:05:53 +0000 (11:05 -0500)]
[PATCH] libata: use kmap_atomic(KM_IRQ0) in SCSI simulator

We are inside spin_lock_irqsave().  quoth akpm's debug facility:

 [  231.948000] SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB)
 [  232.232000] ata1.00: configured for UDMA/33
 [  232.404000] WARNING (1) at arch/i386/mm/highmem.c:47 kmap_atomic()
 [  232.404000]  [<c01162e6>] kmap_atomic+0xa9/0x1ab
 [  232.404000]  [<c0242c81>] ata_scsi_rbuf_get+0x1c/0x30
 [  232.404000]  [<c0242caf>] ata_scsi_rbuf_fill+0x1a/0x87
 [  232.404000]  [<c0243ab2>] ata_scsiop_mode_sense+0x0/0x309
 [  232.404000]  [<c01729d5>] end_bio_bh_io_sync+0x0/0x37
 [  232.404000]  [<c02311c6>] scsi_done+0x0/0x16
 [  232.404000]  [<c02311c6>] scsi_done+0x0/0x16
 [  232.404000]  [<c0242dcc>] ata_scsi_simulate+0xb0/0x13f
[...]

Signed-off-by: Jeff Garzik <jeff@garzik.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] md: fix potential memalloc deadlock in md
NeilBrown [Thu, 25 Jan 2007 04:35:34 +0000 (15:35 +1100)]
[PATCH] md: fix potential memalloc deadlock in md

If a GFP_KERNEL allocation is attempted in md while the mddev_lock is
held, it is possible for a deadlock to eventuate.
This happens if the array was marked 'clean', and the memalloc triggers
a write-out to the md device.
For the writeout to succeed, the array must be marked 'dirty', and that
requires getting the mddev_lock.

So, before attempting a GFP_KERNEL alloction while holding the lock,
make sure the array is marked 'dirty' (unless it is currently read-only).

Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] md: fix a few problems with the interface (sysfs and ioctl) to md.
NeilBrown [Thu, 25 Jan 2007 04:35:29 +0000 (15:35 +1100)]
[PATCH] md: fix a few problems with the interface (sysfs and ioctl) to md.

While developing more functionality in mdadm I found some bugs in md...

- When we remove a device from an inactive array (write 'remove' to
  the 'state' sysfs file - see 'state_store') would should not
  update the superblock information - as we may not have
  read and processed it all properly yet.

- initialise all raid_disk entries to '-1' else the 'slot sysfs file
  will claim '0' for all devices in an array before the array is
  started.

- all '\n' not to be present at the end of words written to
  sysfs files
- when we use SET_ARRAY_INFO to set the md metadata version,
  set the flag to say that there is persistant metadata.
- allow GET_BITMAP_FILE to be called on an array that hasn't
  been started yet.

Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] md: make 'repair' actually work for raid1.
NeilBrown [Thu, 25 Jan 2007 04:35:25 +0000 (15:35 +1100)]
[PATCH] md: make 'repair' actually work for raid1.

When 'repair' finds a block that is different one the various
parts of the mirror. it is meant to write a chosen good version
to the others.  However it currently writes out the original data
to each. The memcpy to make all the data the same is missing.

Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] md: assorted md and raid1 one-liners
NeilBrown [Thu, 25 Jan 2007 04:35:21 +0000 (15:35 +1100)]
[PATCH] md: assorted md and raid1 one-liners

Fix few bugs that meant that:
  - superblocks weren't alway written at exactly the right time (this
    could show up if the array was not written to - writting to the array
    causes lots of superblock updates and so hides these errors).

  - restarting device recovery after a clean shutdown (version-1 metadata
    only) didn't work as intended (or at all).

1/ Ensure superblock is updated when a new device is added.
2/ Remove an inappropriate test on MD_RECOVERY_SYNC in md_do_sync.
   The body of this if takes one of two branches depending on whether
   MD_RECOVERY_SYNC is set, so testing it in the clause of the if
   is wrong.
3/ Flag superblock for updating after a resync/recovery finishes.
4/ If we find the neeed to restart a recovery in the middle (version-1
   metadata only) make sure a full recovery (not just as guided by
   bitmaps) does get done.

Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] knfsd: fix up some bit-rot in exp_export
NeilBrown [Thu, 25 Jan 2007 04:35:17 +0000 (15:35 +1100)]
[PATCH] knfsd: fix up some bit-rot in exp_export

The nfsservctl systemcall isn't used but recent nfs-utils releases for
exporting filesystems, and consequently the code that is uses -
exp_export - has suffered some bitrot.

Particular:
  - some newly added fields in 'struct svc_export' are being initialised
    properly.
  - the return value is now always -ENOMEM ...

This patch fixes both these problems.

Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] knfsd: fix type mismatch with filldir_t used by nfsd.
NeilBrown [Thu, 25 Jan 2007 04:35:12 +0000 (15:35 +1100)]
[PATCH] knfsd: fix type mismatch with filldir_t used by nfsd.

nfsd defines a type 'encode_dent_fn' which is much like 'filldir_t'
except that the first pointer is 'struct readdir_cd *' rather than
'void *'.  It then casts encode_dent_fn points to 'filldir_t' as
needed.  This hides any other type mismatches between the two such as
the fact that the 'ino' arg recently changed from ino_t to u64.

So: get rid of 'encode_dent_fn', get rid of the cast of the function
type, change the first arg of various functions from 'struct readdir_cd *'
to 'void *', and live with the fact that we have a little less type
checking on the calling of these functions now.
Less internal (to nfsd) checking offset by more external checking, which
is more important.

Thanks to Gabriel Paubert <paubert@iram.es> for discovering this and
providing an initial patch.

Signed-off-by: Gabriel Paubert <paubert@iram.es>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] knfsd: fix an NFSD bug with full sized, non-page-aligned reads.
NeilBrown [Thu, 25 Jan 2007 04:35:08 +0000 (15:35 +1100)]
[PATCH] knfsd: fix an NFSD bug with full sized, non-page-aligned reads.

NFSd assumes that largest number of pages that will be needed
for a request+response is 2+N where N pages is the size of the largest
permitted read/write request.  The '2' are 1 for the non-data part of
the request, and 1 for the non-data part of the reply.

However, when a read request is not page-aligned, and we choose to use
->sendfile to send it directly from the page cache, we may need N+1
pages to hold the whole reply.  This can overflow and array and cause
an Oops.

This patch increases size of the array for holding pages by one and
makes sure that entry is NULL when it is not in use.

Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] knfsd: fix setting of ACL server versions.
NeilBrown [Thu, 25 Jan 2007 04:35:01 +0000 (15:35 +1100)]
[PATCH] knfsd: fix setting of ACL server versions.

Due to silly typos, if the nfs versions are explicitly set,
no NFSACL versions get enabled.

Also improve an error message that would have made this bug
a little easier to find.

Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] sis190: failure to set the MAC address from EEPROM
Francois Romieu [Thu, 18 Jan 2007 22:22:23 +0000 (23:22 +0100)]
[PATCH] sis190: failure to set the MAC address from EEPROM

Fix from http://bugzilla.kernel.org/show_bug.cgi?id=7747

Signed-off-by: Andrew Morton <akpm@osdl.org>
Cc: <sleepy@mike-neko.net>
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] SPARC64: Set g4/g5 properly in sun4v dtlb-prot handling.
David S. Miller [Sat, 27 Jan 2007 03:17:10 +0000 (19:17 -0800)]
[PATCH] SPARC64: Set g4/g5 properly in sun4v dtlb-prot handling.

Mirror the logic in the sun4u handler, we have to update
both registers even when we branch out to window fault
fixup handling.

The way it works is that if we are in etrap processing a
fault already, g4/g5 holds the original fault information.
If we take a window spill fault while doing etrap, then
we put the window spill fault info into g4/g5 and this is
what the top-level fault handler ends up processing first.

Then we retry the originally faulting instruction, and
process the original fault at that time.

This is all necessary because of how constrained the trap
registers are in these code paths.  These cases trigger
very rarely, so even if there is some performance implication
it's doesn't happen very often.  In fact the rarity is why
it took so long to trigger and find this particular bug.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] remove __devinit markings from rtc_sysfs_add_device()
Mike Frysinger [Fri, 26 Jan 2007 08:57:08 +0000 (00:57 -0800)]
[PATCH] remove __devinit markings from rtc_sysfs_add_device()

rtc_sysfs_add_device is needed even after dev initialization, so drop __devinit.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Acked-by: Alessandro Zummo <a.zummo@towertech.it>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] Revert "[PATCH] Fix up mmap_kmem"
Linus Torvalds [Mon, 22 Jan 2007 16:53:24 +0000 (08:53 -0800)]
[PATCH] Revert "[PATCH] Fix up mmap_kmem"

This reverts commit 99a10a60ba9bedcf5d70ef81414d3e03816afa3f.

As per Hugh Dickins:

  "Nadia Derbey has reported that mmap of /dev/kmem no longer works with
   the kernel virtual address as offset, and Franck has confirmed that
   his patch came from a misunderstanding of what an offset means to
   /dev/kmem - whereas his patch description seems to say that he was
   correcting the offset on a few plaforms, there was no such problem to
   correct, and his patch was in fact changing its API on all platforms."

Suggested-by: Hugh Dickins <hugh@veritas.com>
Cc: Franck Bui-Huu <fbuihuu@gmail.com>
Cc: Nadia Derbey <Nadia.Derbey@bull.net>
Cc: Andi Kleen <ak@suse.de>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] elevator: move clearing of unplug flag earlier
Linas Vepstas [Tue, 23 Jan 2007 18:40:54 +0000 (19:40 +0100)]
[PATCH] elevator: move clearing of unplug flag earlier

A flag was recently added to the elevator code to avoid
performing an unplug when reuests are being re-queued.
The goal of this flag was to avoid a deep recursion that
can occur when re-queueing requests after a SCSI device/host
reset.  See http://lkml.org/lkml/2006/5/17/254

However, that fix added the flag near the bottom of a case
statement, where an earlier break (in an if statement) could
transport one out of the case, without setting the flag.
This patch sets the flag earlier in the case statement.

I re-discovered the deep recursion recently during testing;
I was told that it was a known problem, and the fix to it was
in the kernel I was testing. Indeed it was ... but it didn't
fix the bug. With the patch below, I no longer see the bug.

Signed-off by: Linas Vepstas <linas@austin.ibm.com>
Signed-off-by: Jens Axboe <axboe@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] NETFILTER: Fix iptables ABI breakage on (at least) CRIS
Patrick McHardy [Wed, 24 Jan 2007 16:46:39 +0000 (17:46 +0100)]
[PATCH] NETFILTER: Fix iptables ABI breakage on (at least) CRIS

With the introduction of x_tables we accidentally broke compatibility
by defining IPT_TABLE_MAXNAMELEN to XT_FUNCTION_MAXNAMELEN instead of
XT_TABLE_MAXNAMELEN, which is two bytes larger.

On most architectures it doesn't really matter since we don't have
any tables with names that long in the kernel and the structure
layout didn't change because of alignment requirements of following
members. On CRIS however (and other architectures that don't align
data) this changed the structure layout and thus broke compatibility
with old iptables binaries.

Changing it back will break compatibility with binaries compiled
against recent kernels again, but since the breakage has only been
there for three releases this seems like the better choice.

Spotted by Jonas Berlin <xkr47@outerspace.dyndns.org>.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] x86: Work around gcc 4.2 over aggressive optimizer
Andi Kleen [Tue, 23 Jan 2007 17:17:09 +0000 (04:17 +1100)]
[PATCH] x86: Work around gcc 4.2 over aggressive optimizer

The new PDA code uses a dummy _proxy_pda variable to describe
memory references to the PDA. It is never referenced
in inline assembly, but exists as input/output arguments.
gcc 4.2 in some cases can CSE references to this which causes
unresolved symbols.  Define it to zero to avoid this.

Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] ACPI: fix cpufreq regression
Ingo Molnar [Tue, 23 Jan 2007 16:16:26 +0000 (17:16 +0100)]
[PATCH] ACPI: fix cpufreq regression

recently cpufreq support on my laptop (Lenovo T60) broke completely:
when it's plugged into AC it would never go higher than 1 GHz - neither
1.3 GHz nor 1.83 GHz is possible - no matter which governor (userspace,
speed or ondemand) is used.

after some cpufreq debugging i tracked the regression back to the
following (totally correct) bug-fix commit:

   commit 0916bd3ebb7cefdd0f432e8491abe24f4b5a101e
   Author: Dave Jones <davej@redhat.com>
   Date:   Wed Nov 22 20:42:01 2006 -0500

    [PATCH] Correct bound checking from the value returned from _PPC method.

this bugfix, which makes other laptops work, made a previously hidden
(BIOS) bug visible on my laptop.

The bug is the following: if the _PPC (Performance Present Capabilities)
optional ACPI object is queried /after/ bootup then the BIOS reports an
incorrect value of '2'.

My laptop (Lenovo T60) has the following performance states supported:

   0: 1833000
   1: 1333000
   2: 1000000

Per ACPI specification, a _PPC value of '0' means that all 3 performance
states are usable. A _PPC value of '1' means states 1 .. 2 are usable, a
value of '2' means only state '2' (slowest) is usable.

now, the _PPC object is optional, and it also comes with notification.
Furthermore, when a CPU object is initialized, the _PPC object is
initialized as well. So the following evaluation of the _PPC object is
superfluous:

 [<c028ba5f>] acpi_processor_get_platform_limit+0xa1/0xaf
 [<c028c040>] acpi_processor_register_performance+0x3b9/0x3ef
 [<c0111a85>] acpi_cpufreq_cpu_init+0xb7/0x596
 [<c03dab74>] cpufreq_add_dev+0x160/0x4a8
 [<c02bed90>] sysdev_driver_register+0x5a/0xa0
 [<c03d9c4c>] cpufreq_register_driver+0xb4/0x176
 [<c068ac08>] acpi_cpufreq_init+0xe5/0xeb
 [<c010056e>] init+0x14f/0x3dd

and this is the point where my laptop's BIOS returns the incorrect value
of '2'. Note that it has not sent any notification event, so the value
is probably not really intentional (possibly spurious), and Windows
likely doesnt query it after bootup either. Maybe the value is kept at
'2' normally, and is only set to the real value when a true asynchronous
event (such as AC plug event, battery switch, etc.) occurs.

So i /think/ this is a grey area of the ACPI spec: per the letter of the
spec the _PPC value only changes when notified, so there's no reason to
query it after the system has booted up. So in my opinion the best (and
most compatible) strategy would be to do the change below, and to not
evaluate the _PPC object in the acpi_processor_get_performance_info()
call, but only evaluate it if _PPC is present during CPU object init, or
if it's notified during an asynchronous event. This change is more
permissive than the previous logic, so it definitely shouldnt break any
existing system.

This also happens to fix my laptop, which is merrily chugging along at
1.83 GHz now. Yay!

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Dave Jones <davej@redhat.com>
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] Fix UML on non-standard VM split hosts
Jeff Dike [Mon, 22 Jan 2007 20:38:27 +0000 (15:38 -0500)]
[PATCH] Fix UML on non-standard VM split hosts

This fixes UML on hosts with non-standard VM splits.  We had changed
the config variable that controls UML behavior on such hosts, but not
propogated the change everywhere.  In particular, the values of
STUB_CODE and STUB_DATA relied on the old variable.

I also reformatted the HOST_VMSPLIT_3G help to make it more standard.

Spotted by uml@flonatel.org.

Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
--
 arch/um/Kconfig.i386 |   38 +++++++++++++++++++-------------------
 1 file changed, 19 insertions(+), 19 deletions(-)

17 years ago[PATCH] IB/iser: return error code when PDUs may not be sent
Erez Zilber [Mon, 22 Jan 2007 13:03:53 +0000 (15:03 +0200)]
[PATCH] IB/iser: return error code when PDUs may not be sent

iSER limits the number of outstanding PDUs to send. When this threshold is
reached, it should return an error code (-ENOBUFS) instead of setting the
suspend_tx bit (which should be used only by libiscsi). Without this fix,
during logout, open-iscsi over iSER tries to logout forever.

Signed-off-by: Erez Zilber <erezz@voltaire.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] SELinux: fix an oops with NetLabel and non-MLS SELinux policy
Paul Moore [Fri, 19 Jan 2007 19:25:50 +0000 (14:25 -0500)]
[PATCH] SELinux: fix an oops with NetLabel and non-MLS SELinux policy

In the case where a user has configured NetLabel in the kernel but is not
using a SELinux policy with the MLS/MCS feature enabled there is a bug in
mls_export_cat() where a NULL pointer is used.  The initial problem report and
discussion can be found here (this patch has been ACK'd by Stephen Smalley and
 James Morris in the discussion thread below):

 * http://marc2.theaimsgroup.com/?t=116920302500004&r=1&w=2

This patch is specific to the 2.6.19.y kernel series as the mls_export_cat()
function has been replaced in the 2.6.20 kernel.

Signed-off-by: Paul Moore <paul.moore@hp.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] ALSA hda-codec - Fix NULL dereference in generic hda code
Takashi Iwai [Thu, 18 Jan 2007 14:25:31 +0000 (15:25 +0100)]
[PATCH] ALSA hda-codec - Fix NULL dereference in generic hda code

Fix NULL dereference in hda_generic.c.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jaroslav Kysela <perex@suse.cz>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] IPSEC: Policy list disorder
Herbert Xu [Wed, 17 Jan 2007 02:35:01 +0000 (13:35 +1100)]
[PATCH] IPSEC: Policy list disorder

The recent hashing introduced an off-by-one bug in policy list insertion.
Instead of adding after the last entry with a lesser or equal priority,
we're adding after the successor of that entry.

This patch fixes this and also adds a warning if we detect a duplicate
entry in the policy list.  This should never happen due to this if clause.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] NETFILTER: ctnetlink: fix leak in ctnetlink_create_conntrack error path
Patrick McHardy [Mon, 15 Jan 2007 09:28:28 +0000 (10:28 +0100)]
[PATCH] NETFILTER: ctnetlink: fix leak in ctnetlink_create_conntrack error path

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] NETFILTER: ctnetlink: check for status attribute existence on conntrack creation
Pablo Neira Ayuso [Mon, 15 Jan 2007 09:28:27 +0000 (10:28 +0100)]
[PATCH] NETFILTER: ctnetlink: check for status attribute existence on conntrack creation

Check that status flags are available in the netlink message received
to create a new conntrack.

Fixes a crash in ctnetlink_create_conntrack when the CTA_STATUS attribute
is not present.

Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] IPV6 MCAST: Fix joining all-node multicast group on device initialization.
YOSHIFUJI Hideaki [Sun, 14 Jan 2007 18:56:01 +0000 (03:56 +0900)]
[PATCH] IPV6 MCAST: Fix joining all-node multicast group on device initialization.

Join all-node multicast group after assignment of dev->ip6_ptr
because it must be assigned when ipv6_dev_mc_inc() is called.
This fixes Bug#7817, reported by <gernoth@informatik.uni-erlangen.de>.

Closes: 7817
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] PCI: prevent down_read when pci_devices is empty
Ard van Breemen [Thu, 11 Jan 2007 15:22:57 +0000 (10:22 -0500)]
[PATCH] PCI: prevent down_read when pci_devices is empty

The pci_find_subsys gets called very early by obsolete ide setup parameters.
This is a bogus call since pci is not initialized yet, so the list is empty.
But in the mean time, interrupts get enabled by down_read.  This can result in
a kernel panic when the irq controller gets initialized.

This patch checks if the device list is empty before taking the semaphore, and
hence will not enable irq's.  Furthermore it will inform that it is called
while pci_devices is empty as a reminder that the ide code needs to be fixed.

The pci_get_subsys can get called in the same manner, and as such is patched
in the same manner.

[akpm@osdl.org: cleanups]
Signed-off-by: Ard van Breemen <ard@telegraafnet.nl>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[chrisw: fold in 6a4c24ec5212 to avoid printk spamming]
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] start_kernel: test if irq's got enabled early, barf, and disable them again
Ard van Breemen [Thu, 11 Jan 2007 15:21:52 +0000 (10:21 -0500)]
[PATCH] start_kernel: test if irq's got enabled early, barf, and disable them again

The calls made by parse_parms to other initialization code might enable
interrupts again way too early.

Having interrupts on this early can make systems PANIC when they initialize
the IRQ controllers (which happens later in the code).  This patch detects
that irq's are enabled again, barfs about it and disables them again as a
safety net.

[akpm@osdl.org: cleanups]
Signed-off-by: Ard van Breemen <ard@telegraafnet.nl>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] Fix up CIFS for "test_clear_page_dirty()" removal
Linus Torvalds [Thu, 11 Jan 2007 15:20:10 +0000 (10:20 -0500)]
[PATCH] Fix up CIFS for "test_clear_page_dirty()" removal

Fix up CIFS for "test_clear_page_dirty()" removal

This also adds he required page "writeback" flag handling, that cifs
hasn't been doing and that the page dirty flag changes made obvious.

Acked-by: Steve French <smfltc@us.ibm.com>
Acked-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] sched: tasks cannot run on cpus onlined after boot
Nathan Lynch [Thu, 11 Jan 2007 07:15:28 +0000 (23:15 -0800)]
[PATCH] sched: tasks cannot run on cpus onlined after boot

Commit 5c1e176781f43bc902a51e5832f789756bff911b ("sched: force /sbin/init
off isolated cpus") sets init's cpus_allowed to a subset of cpu_online_map
at boot time, which means that tasks won't be scheduled on cpus that are
added to the system later.

Make init's cpus_allowed a subset of cpu_possible_map instead.  This should
still preserve the behavior that Nick's change intended.

Thanks to Giuliano Pochini for reporting this and testing the fix:

http://ozlabs.org/pipermail/linuxppc-dev/2006-December/029397.html

Signed-off-by: Nathan Lynch <ntl@pobox.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] ieee1394: sbp2: fix probing of some DVD-ROM/RWs
Stefan Richter [Thu, 11 Jan 2007 07:50:27 +0000 (08:50 +0100)]
[PATCH] ieee1394: sbp2: fix probing of some DVD-ROM/RWs

Since commit 98e238cd42be6c0852da519303cf0182690f8d9f in Linux 2.6.19,
"ieee1394: sbp2: don't prefer MODE SENSE 10", some FireWire DVD-ROMs and
DVD-RWs were mistaken as CD-ROM because sr_mod now sent MODE SENSE 6.
The MMC command set includes only MODE SENSE 10.
http://bugzilla.kernel.org/show_bug.cgi?id=7800

This fix lets sbp2 switch scsi_device.use_10_for_rw on for MMC LUs.
This should rather be done in the command set driver sr_mod, not in the
sbp2 transport driver, and an according patch will follow for a next
Linux release.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] Fix reparenting to the same thread group. (take 2)
Eric W. Biederman [Fri, 22 Dec 2006 04:28:40 +0000 (21:28 -0700)]
[PATCH] Fix reparenting to the same thread group. (take 2)

This patch fixes the case when we reparent to a different thread in the
same thread group.  This modifies the code so that we do not send
signals and do not change the signal to send to SIGCHLD unless we have
change the thread group of our parents.  It also suppresses sending
pdeath_sig in this cas as well since the result of geppid doesn't
change.

Thanks to Oleg for spotting my bug of only fixing this for non-ptraced
tasks.

This fixes the issues identified by Albert Cahalan in thread
http://lkml.org/lkml/2006/12/21/22.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Acked-by: Mike Galbraith <efault@gmx.de>
Cc: Albert Cahalan <acahalan@gmail.com>
Cc: Andrew Morton <akpm@osdl.org>
Cc: Roland McGrath <roland@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Coywolf Qi Hunt <qiyong@fc-cn.com>
Acked-by: Oleg Nesterov <oleg@tv-sign.ru>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[chrisw: fold in 241ceee0b442, Oleg's fix to restore user visible behaviour]
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] IB/mthca: Fix off-by-one in FMR handling on memfree
Michael S. Tsirkin [Wed, 10 Jan 2007 21:36:54 +0000 (13:36 -0800)]
[PATCH] IB/mthca: Fix off-by-one in FMR handling on memfree

mthca_table_find() will return the wrong address when the table entry
being searched for is exactly at the beginning of a sglist entry
(other than the first), because it uses >= when it should use >.

Example: assume we have 2 entries in scatterlist, 4K each, offset is
4K.  The current code will return first entry + 4K when we really want
the second entry.

In particular this means mapping an FMR on a memfree HCA may end up
writing the page table into the wrong place, leading to memory
corruption and also causing the HCA to use an incorrect address
translation table.

Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] Repair snd-usb-usx2y over OHCI
Karsten Wiese [Wed, 10 Jan 2007 12:33:27 +0000 (13:33 +0100)]
[PATCH] Repair snd-usb-usx2y over OHCI

The previous patch "Repair snd-usb-usx2y for usb 2.6.18" assumed
urb->start_frame roll over beyond MAX_INT for both UHCI & OHCI.
This isn't true until now (kernel 2.6.20).
Fix this by only looking at the common between OHCI & UHCI Frame number
range.
This is for mainline and stable kernels >= 2.6.18.

Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] NETFILTER: arp_tables: fix userspace compilation
Patrick McHardy [Wed, 10 Jan 2007 07:04:50 +0000 (08:04 +0100)]
[PATCH] NETFILTER: arp_tables: fix userspace compilation

The included patch translates arpt_counters to xt_counters, making
userspace arptables compile against recent kernels.

Signed-off-by: Bart De Schuymer <bdschuym@pandora.be>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] NETFILTER: tcp conntrack: fix IP_CT_TCP_FLAG_CLOSE_INIT value
Patrick McHardy [Wed, 10 Jan 2007 07:04:49 +0000 (08:04 +0100)]
[PATCH] NETFILTER: tcp conntrack: fix IP_CT_TCP_FLAG_CLOSE_INIT value

IP_CT_TCP_FLAG_CLOSE_INIT is a flag and should have a value of 0x4 instead
of 0x3, which is IP_CT_TCP_FLAG_WINDOW_SCALE | IP_CT_TCP_FLAG_SACK_PERM.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] NETFILTER: nf_conntrack_ipv6: fix crash when handling fragments
Patrick McHardy [Wed, 10 Jan 2007 07:04:47 +0000 (08:04 +0100)]
[PATCH] NETFILTER: nf_conntrack_ipv6: fix crash when handling fragments

When IPv6 connection tracking splits up a defragmented packet into
its original fragments, the packets are taken from a list and are
passed to the network stack with skb->next still set. This causes
dev_hard_start_xmit to treat them as GSO fragments, resulting in
a use after free when connection tracking handles the next fragment.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] NETFILTER: Fix routing of REJECT target generated packets in output chain
Patrick McHardy [Wed, 10 Jan 2007 07:04:46 +0000 (08:04 +0100)]
[PATCH] NETFILTER: Fix routing of REJECT target generated packets in output chain

Packets generated by the REJECT target in the output chain have a local
destination address and a foreign source address. Make sure not to use
the foreign source address for the output route lookup.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] md: pass down BIO_RW_SYNC in raid{1,10}
Lars Ellenberg [Mon, 8 Jan 2007 23:02:42 +0000 (15:02 -0800)]
[PATCH] md: pass down BIO_RW_SYNC in raid{1,10}

md raidX make_request functions strip off the BIO_RW_SYNC flag, thus
introducing additional latency.

Fixing this in raid1 and raid10 seems to be straightforward enough.

For our particular usage case in DRBD, passing this flag improved some
initialization time from ~5 minutes to ~5 seconds.

Acked-by: NeilBrown <neilb@suse.de>
Signed-off-by: Lars Ellenberg <lars@linbit.com>
Acked-by: Jens Axboe <jens.axboe@oracle.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] Fix HWRNG built-in initcalls priority
Michael Buesch [Mon, 8 Jan 2007 15:34:54 +0000 (16:34 +0100)]
[PATCH] Fix HWRNG built-in initcalls priority

This changes all HWRNG driver initcalls to module_init().
We must probe the RNGs after the major kernel subsystems
are already up and running (like PCI).
This fixes Bug 7730.
http://bugzilla.kernel.org/show_bug.cgi?id=7730

Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] Check for populated zone in __drain_pages
Christoph Lameter [Sat, 6 Jan 2007 00:37:02 +0000 (16:37 -0800)]
[PATCH] Check for populated zone in __drain_pages

Both process_zones() and drain_node_pages() check for populated zones
before touching pagesets.  However, __drain_pages does not do so,

This may result in a NULL pointer dereference for pagesets in unpopulated
zones if a NUMA setup is combined with cpu hotplug.

Initially the unpopulated zone has the pcp pointers pointing to the boot
pagesets.  Since the zone is not populated the boot pageset pointers will
not be changed during page allocator and slab bootstrap.

If a cpu is later brought down (first call to __drain_pages()) then the pcp
pointers for cpus in unpopulated zones are set to NULL since __drain_pages
does not first check for an unpopulated zone.

If the cpu is then brought up again then we call process_zones() which will
ignore the unpopulated zone.  So the pageset pointers will still be NULL.

If the cpu is then again brought down then __drain_pages will attempt to
drain pages by following the NULL pageset pointer for unpopulated zones.

Signed-off-by: Christoph Lameter <clameter@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] i2c/m41t00: Do not forget to write year
Philippe De Muyter [Sun, 7 Jan 2007 11:09:21 +0000 (12:09 +0100)]
[PATCH] i2c/m41t00: Do not forget to write year

m41t00.c forgets to set the year field in set_rtc_time; fix that.

Signed-off-by: Philippe De Muyter <phdm@macqel.be>
Acked-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] i2c-mv64xxx: Fix random oops at boot
Maxime Bizon [Sun, 7 Jan 2007 10:49:48 +0000 (11:49 +0100)]
[PATCH] i2c-mv64xxx: Fix random oops at boot

I have a Marvell board which has the same i2c hw block than mv64xxx, so
I'm trying to use i2c-mv64xxx driver.

But I get the following random oops at boot:

Unable to handle kernel NULL pointer dereference at virtual address 00000002
Backtrace:
[<c0397e4c>] (mv64xxx_i2c_intr+0x0/0x2b8) from [<c02879c4>] (__do_irq+0x4c/0x8c)
[<c0287978>] (__do_irq+0x0/0x8c) from [<c0287c0c>] (do_level_IRQ+0x68/0xc0)
 r8 = C0501E08  r7 = 00000005  r6 = C0501E08  r5 = 00000005
 r4 = C048BB78
[<c0287ba4>] (do_level_IRQ+0x0/0xc0) from [<c02885f8>] (asm_do_IRQ+0x50/0x134)
 r6 = C0449C78  r5 = F1020000  r4 = FFFFFFFF
[<c02885a8>] (asm_do_IRQ+0x0/0x134) from [<c02869c4>] (__irq_svc+0x24/0x100)
 r8 = C1CAC400  r7 = 00000005  r6 = 00000002  r5 = F1020000
 r4 = FFFFFFFF
[<c0287efc>] (setup_irq+0x0/0x124) from [<c02880d0>] (request_irq+0xb0/0xd0)
 r7 = C041B2AC  r6 = C0397E4C  r5 = 00000000  r4 = 00000005
[<c0288020>] (request_irq+0x0/0xd0) from [<c03985f4>] (mv64xxx_i2c_probe+0x148/0x244)
[<c03984ac>] (mv64xxx_i2c_probe+0x0/0x244) from [<c038bedc>] (platform_drv_probe+0x20/0x24)

The oops is caused by a spurious interrupt that occurs when request_irq
is called. mv64xxx_i2c_fsm() tries to read drv_data->msg, which is NULL.

I noticed that hardware init is done after requesting irq. Thus any
pending irq from previous hardware usage may cause this.

The following patch fixes it:

Signed-off-by: Maxime Bizon <mbizon@freebox.fr>
Acked-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years agoLinux 2.6.19.2 v2.6.19.2
Chris Wright [Wed, 10 Jan 2007 19:10:37 +0000 (11:10 -0800)]
Linux 2.6.19.2

17 years ago[PATCH] Fix up page_mkclean_one(): virtual caches, s390
Peter Zijlstra [Fri, 22 Dec 2006 13:25:52 +0000 (14:25 +0100)]
[PATCH] Fix up page_mkclean_one(): virtual caches, s390

 - add flush_cache_page() for all those virtual indexed cache
   architectures.

 - handle s390.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[chrisw: fold in d6e88e671ac1]
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] Fix incorrect user space access locking in mincore() (CVE-2006-4814)
Linus Torvalds [Sat, 16 Dec 2006 17:44:32 +0000 (09:44 -0800)]
[PATCH] Fix incorrect user space access locking in mincore() (CVE-2006-4814)

Doug Chapman noticed that mincore() will doa "copy_to_user()" of the
result while holding the mmap semaphore for reading, which is a big
no-no.  While a recursive read-lock on a semaphore in the case of a page
fault happens to work, we don't actually allow them due to deadlock
schenarios with writers due to fairness issues.

Doug and Marcel sent in a patch to fix it, but I decided to just rewrite
the mess instead - not just fixing the locking problem, but making the
code smaller and (imho) much easier to understand.

Cc: Doug Chapman <dchapman@redhat.com>
Cc: Marcel Holtmann <holtmann@redhat.com>
Cc: Hugh Dickins <hugh@veritas.com>
Cc: Andrew Morton <akpm@osdl.org>
[chrisw: fold in subsequent fix: 4fb23e439ce0]
Acked-by: Hugh Dickins <hugh@veritas.com>
[chrisw: fold in subsequent fix: 825020c3866e]
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] fix OOM killing of swapoff
Hugh Dickins [Sat, 6 Jan 2007 00:37:03 +0000 (16:37 -0800)]
[PATCH] fix OOM killing of swapoff

These days, if you swapoff when there isn't enough memory, OOM killer gives
"BUG: scheduling while atomic" and the machine hangs: badness() needs to do
its PF_SWAPOFF return after the task_unlock (tasklist_lock is also held
here, so p isn't going to be freed: PF_SWAPOFF might get turned off at any
moment, but that doesn't really matter).

Signed-off-by: Hugh Dickins <hugh@veritas.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] connector: some fixes for ia64 unaligned access errors
Erik Jacobson [Sat, 6 Jan 2007 00:37:05 +0000 (16:37 -0800)]
[PATCH] connector: some fixes for ia64 unaligned access errors

On ia64, the various functions that make up cn_proc.c cause kernel
unaligned access errors.

If you are using these, for example, to get notification about all tasks
forking and exiting, you get multiple unaligned access errors per process.

Use put_unaligned() in the appropriate palces to fix this.

Signed-off-by: Erik Jacobson <erikj@sgi.com>
Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Cc: Tony Luck <tony.luck@intel.com>
Cc: <stable@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] NetLabel: correctly fill in unused CIPSOv4 level and category mappings
Paul Moore [Mon, 18 Dec 2006 18:07:29 +0000 (13:07 -0500)]
[PATCH] NetLabel: correctly fill in unused CIPSOv4 level and category mappings

Back when the original NetLabel patches were being changed to use Netlink
attributes correctly some code was accidentially dropped which set all of the
undefined CIPSOv4 level and category mappings to a sentinel value.  The result
is the mappings data in the kernel contains bogus mappings which always map to
zero.  Having level and category mappings that map to zero could result in the
kernel assigning incorrect security attributes to packets.

This patch restores the old/correct behavior by initializing the mapping
data to the correct sentinel value.

Signed-off-by: Paul Moore <paul.moore@hp.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] asix: Fix typo for AX88772 PHY Selection
David Hollis [Fri, 5 Jan 2007 17:34:05 +0000 (12:34 -0500)]
[PATCH] asix: Fix typo for AX88772 PHY Selection

The attached patch fixes a PHY selection problem that prevents AX88772
based devices (Linksys USB200Mv2, etc) devices from working.  The
interface comes up and everything seems fine except the device doesn't
send/receive any packets.  The one-liner attached fixes this issue and
makes the devices usable again.

Signed-off-by: David Hollis <dhollis@davehollis.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] IPV4/IPV6: Fix inet{,6} device initialization order.
David L Stevens [Fri, 5 Jan 2007 01:07:34 +0000 (17:07 -0800)]
[PATCH] IPV4/IPV6: Fix inet{,6} device initialization order.

It is important that we only assign dev->ip{,6}_ptr
only after all portions of the inet{,6} are setup.

Otherwise we can receive packets before the multicast
spinlocks et al. are initialized.

Signed-off-by: David L Stevens <dlstevens@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] SOUND: Sparc CS4231: Use 64 for period_bytes_min
David Miller [Fri, 5 Jan 2007 01:04:31 +0000 (17:04 -0800)]
[PATCH] SOUND: Sparc CS4231: Use 64 for period_bytes_min

This matches what the ISA cs4231 driver uses.

Tested by Georg Chini.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] SOUND: Sparc CS4231: Fix IRQ return value and initialization.
Georg Chini [Fri, 5 Jan 2007 01:03:38 +0000 (17:03 -0800)]
[PATCH] SOUND: Sparc CS4231: Fix IRQ return value and initialization.

SBUS: Change IRQ-handler return value from 0 to IRQ_HANDLED and
fix some initialisation problems.

Change period_bytes_min from 4096 to 256 to allow driver to work with
low latency (VOIP) applications. Hope this does not break EBUS.

Signed-off-by: Georg Chini <georg.chini@triaton-webhosting.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] ebtables: don't compute gap before checking struct type
Chuck Ebbert [Thu, 4 Jan 2007 07:59:56 +0000 (02:59 -0500)]
[PATCH] ebtables: don't compute gap before checking struct type

We cannot compute the gap until we know we have a 'struct ebt_entry'
and not 'struct ebt_entries'.  Failure to check can cause crash.

Tested-by: Santiago Garcia Mantinan <manty@manty.net>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] V4L: cx88: Fix leadtek_eeprom tagging
Jean Delvare [Thu, 4 Jan 2007 04:21:03 +0000 (23:21 -0500)]
[PATCH] V4L: cx88: Fix leadtek_eeprom tagging

reference to .init.text: from .text between 'cx88_card_setup'
(at offset 0x68c) and 'cx88_risc_field'
Caused by leadtek_eeprom() being declared __devinit and called from
a non-devinit context.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] dvb-core: fix bug in CRC-32 checking on 64-bit systems
Ang Way Chuang [Thu, 4 Jan 2007 04:20:48 +0000 (23:20 -0500)]
[PATCH] dvb-core: fix bug in CRC-32 checking on 64-bit systems

CRC-32 checking during ULE decapsulation always failed on x86_64 systems due
to the size of a variable used to store CRC. This bug was discovered on
Fedora Core 6 with kernel-2.6.18-1.2849. The i386 counterpart has no such
problem. This patch has been tested on 64-bit system as well as 32-bit system.

Signed-off-by: Ang Way Chuang <wcang@nrg.cs.usm.my>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] V4L: cx2341x: audio_properties is an u16, not u8
Hans Verkuil [Thu, 4 Jan 2007 04:20:55 +0000 (23:20 -0500)]
[PATCH] V4L: cx2341x: audio_properties is an u16, not u8

This bug broke the MPEG audio mode controls.

Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] VM: Fix nasty and subtle race in shared mmap'ed page writeback
Linus Torvalds [Fri, 29 Dec 2006 18:00:58 +0000 (10:00 -0800)]
[PATCH] VM: Fix nasty and subtle race in shared mmap'ed page writeback

The VM layer (on the face of it, fairly reasonably) expected that when
it does a ->writepage() call to the filesystem, it would write out the
full page at that point in time.  Especially since it had earlier marked
the whole page dirty with "set_page_dirty()".

But that isn't actually the case: ->writepage() does not actually write
a page, it writes the parts of the page that have been explicitly marked
dirty before, *and* that had not got written out for other reasons since
the last time we told it they were dirty.

That last caveat is the important one.

Which _most_ of the time ends up being the whole page (since we had
called "set_page_dirty()" on the page earlier), but if the filesystem
had done any dirty flushing of its own (for example, to honor some
internal write ordering guarantees), it might end up doing only a
partial page IO (or none at all) when ->writepage() is actually called.

That is the correct thing in general (since we actually often _want_
only the known-dirty parts of the page to be written out), but the
shared dirty page handling had implicitly forgotten about these details,
and had a number of cases where it was doing just the "->writepage()"
part, without telling the low-level filesystem that the whole page might
have been re-dirtied as part of being mapped writably into user space.

Since most of the time the FS did actually write out the full page, we
didn't notice this for a loong time, and this needed some really odd
patterns to trigger.  But it caused occasional corruption with rtorrent
and with the Debian "apt" database, because both use shared mmaps to
update the end result.

This fixes it. Finally. After way too much hair-pulling.

Acked-by: Nick Piggin <nickpiggin@yahoo.com.au>
Acked-by: Martin J. Bligh <mbligh@google.com>
Acked-by: Martin Michlmayr <tbm@cyrius.com>
Acked-by: Martin Johansson <martin@fatbob.nu>
Acked-by: Ingo Molnar <mingo@elte.hu>
Acked-by: Andrei Popa <andrei.popa@i-neo.ro>
Cc: High Dickins <hugh@veritas.com>
Cc: Andrew Morton <akpm@osdl.org>,
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Segher Boessenkool <segher@kernel.crashing.org>
Cc: David Miller <davem@davemloft.net>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Gordon Farquharson <gordonfarquharson@gmail.com>
Cc: Guillaume Chazarain <guichaz@yahoo.fr>
Cc: Theodore Tso <tytso@mit.edu>
Cc: Kenneth Cheng <kenneth.w.chen@intel.com>
Cc: Tobias Diedrich <ranma@tdiedrich.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[chrisw: backport to 2.6.19.1]
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] sparc32: add offset in pci_map_sg()
Jan Andersson [Tue, 2 Jan 2007 08:09:25 +0000 (00:09 -0800)]
[PATCH] sparc32: add offset in pci_map_sg()

Add sg->offset to sg->dvma_address in pci_map_sg() on sparc32.  Without the
offset, transfers to buffers that do not begin on a page boundary will not
work as expected.

Signed-off-by: Jan Andersson <jan.andersson@ieee.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: William Lee Irwin III <wli@holomorphy.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] NET: Don't export linux/random.h outside __KERNEL__
David Woodhouse [Tue, 2 Jan 2007 08:07:50 +0000 (00:07 -0800)]
[PATCH] NET: Don't export linux/random.h outside __KERNEL__

Don't add it there please; add it lower down inside the existing #ifdef
__KERNEL__. You just made the _userspace_ net.h include random.h, which
then fails to compile unless <asm/types.h> was already included.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] SPARC64: Handle ISA devices with no 'regs' property.
David Miller [Tue, 2 Jan 2007 08:06:00 +0000 (00:06 -0800)]
[PATCH] SPARC64: Handle ISA devices with no 'regs' property.

And this points out that the return value from
isa_dev_get_resource() and the 'pregs' arg to
isa_dev_get_irq() are totally unused.

Based upon a patch from Richard Mortimer <richm@oldelvet.org.uk>

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] SPARC64: Fix "mem=xxx" handling.
David Miller [Tue, 2 Jan 2007 08:03:37 +0000 (00:03 -0800)]
[PATCH] SPARC64: Fix "mem=xxx" handling.

We were not being careful enough.  When we trim the physical
memory areas, we have to make sure we don't remove the kernel
image or initial ramdisk image ranges.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] PKTGEN: Fix module load/unload races.
Robert Olsson [Tue, 2 Jan 2007 05:04:19 +0000 (21:04 -0800)]
[PATCH] PKTGEN: Fix module load/unload races.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] ext2: skip pages past number of blocks in ext2_find_entry (CVE-2006-6054)
Eric Sandeen [Sat, 30 Dec 2006 23:30:32 +0000 (18:30 -0500)]
[PATCH] ext2: skip pages past number of blocks in ext2_find_entry (CVE-2006-6054)

This one was pointed out on the MOKB site:
http://kernelfun.blogspot.com/2006/11/mokb-09-11-2006-linux-26x-ext2checkpage.html

If a directory's i_size is corrupted, ext2_find_entry() will keep processing
pages until the i_size is reached, even if there are no more blocks associated
with the directory inode.  This patch puts in some minimal sanity-checking
so that we don't keep checking pages (and issuing errors) if we know there
can be no more data to read, based on the block count of the directory inode.

This is somewhat similar in approach to the ext3 patch I sent earlier this
year.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] corrupted cramfs filesystems cause kernel oops (CVE-2006-5823)
Phillip Lougher [Sat, 30 Dec 2006 23:28:06 +0000 (18:28 -0500)]
[PATCH] corrupted cramfs filesystems cause kernel oops (CVE-2006-5823)

Steve Grubb's fzfuzzer tool (http://people.redhat.com/sgrubb/files/
fsfuzzer-0.6.tar.gz) generates corrupt Cramfs filesystems which cause
Cramfs to kernel oops in cramfs_uncompress_block().  The cause of the oops
is an unchecked corrupted block length field read by cramfs_readpage().

This patch adds a sanity check to cramfs_readpage() which checks that the
block length field is sensible.  The (PAGE_CACHE_SIZE << 1) size check is
intentional, even though the uncompressed data is not going to be larger
than PAGE_CACHE_SIZE, gzip sometimes generates compressed data larger than
the original source data.  Mkcramfs checks that the compressed size is
always less than or equal to PAGE_CACHE_SIZE << 1.  Of course Cramfs could
use the original uncompressed data in this case, but it doesn't.

Signed-off-by: Phillip Lougher <phillip@lougher.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] handle ext3 directory corruption better (CVE-2006-6053)
Eric Sandeen [Sat, 30 Dec 2006 23:22:07 +0000 (18:22 -0500)]
[PATCH] handle ext3 directory corruption better (CVE-2006-6053)

I've been using Steve Grubb's purely evil "fsfuzzer" tool, at
http://people.redhat.com/sgrubb/files/fsfuzzer-0.4.tar.gz

Basically it makes a filesystem, splats some random bits over it, then
tries to mount it and do some simple filesystem actions.

At best, the filesystem catches the corruption gracefully.  At worst,
things spin out of control.

As you might guess, we found a couple places in ext3 where things spin out
of control :)

First, we had a corrupted directory that was never checked for
consistency...  it was corrupt, and pointed to another bad "entry" of
length 0.  The for() loop looped forever, since the length of
ext3_next_entry(de) was 0, and we kept looking at the same pointer over and
over and over and over...  I modeled this check and subsequent action on
what is done for other directory types in ext3_readdir...

(adding this check adds some computational expense; I am testing a followup
patch to reduce the number of times we check and re-check these directory
entries, in all cases.  Thanks for the idea, Andreas).

Next we had a root directory inode which had a corrupted size, claimed to
be > 200M on a 4M filesystem.  There was only really 1 block in the
directory, but because the size was so large, readdir kept coming back for
more, spewing thousands of printk's along the way.

Per Andreas' suggestion, if we're in this read error condition and we're
trying to read an offset which is greater than i_blocks worth of bytes,
stop trying, and break out of the loop.

With these two changes fsfuzz test survives quite well on ext3.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Cc: <linux-ext4@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] zd1211rw: Call ieee80211_rx in tasklet
Ulrich Kunitz [Sat, 30 Dec 2006 21:35:17 +0000 (16:35 -0500)]
[PATCH] zd1211rw: Call ieee80211_rx in tasklet

The driver called ieee80211_rx in hardware interrupt context.  This has
been against the intention of the ieee80211_rx function.  It caused a bug
in the crypto routines used by WPA.  This patch calls ieee80211_rx in a
tasklet.

Signed-off-by: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] softmac: Fixed handling of deassociation from AP
Ulrich Kunitz [Sat, 30 Dec 2006 21:18:14 +0000 (16:18 -0500)]
[PATCH] softmac: Fixed handling of deassociation from AP

In 2.6.19 a deauthentication from the AP doesn't start a
reassociation by the softmac code. It appears that
mac->associnfo.associating must be set and the
ieee80211softmac_assoc_work function must be scheduled. This patch
fixes that.

Signed-off-by: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] Buglet in vmscan.c
Shantanu Goel [Sat, 30 Dec 2006 00:48:59 +0000 (16:48 -0800)]
[PATCH] Buglet in vmscan.c

Fix a rather obvious buglet.  Noticed while instrumenting the VM using
/proc/vmstat.

Cc: Christoph Lameter <clameter@engr.sgi.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] ramfs breaks without CONFIG_BLOCK
Dimitri Gorokhovik [Sat, 30 Dec 2006 00:48:24 +0000 (16:48 -0800)]
[PATCH] ramfs breaks without CONFIG_BLOCK

ramfs doesn't provide the .set_dirty_page a_op, and when the BLOCK layer is
not configured in, 'set_page_dirty' makes a call via a NULL pointer.

Signed-off-by: Dimitri Gorokhovik <dimitri.gorokhovik@free.fr>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] i386: CPU hotplug broken with 2GB VMSPLIT
Shaohua Li [Sun, 24 Dec 2006 02:39:08 +0000 (21:39 -0500)]
[PATCH] i386: CPU hotplug broken with 2GB VMSPLIT

In VMSPLIT mode, kernel PGD might have more entries than user space

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] cciss: fix XFER_READ/XFER_WRITE in do_cciss_request
Mike Miller [Sat, 23 Dec 2006 20:11:58 +0000 (15:11 -0500)]
[PATCH] cciss: fix XFER_READ/XFER_WRITE in do_cciss_request

This patch fixes a stupid bug. Sometime during the 2tb enhancement I ended up
replacing the macros XFER_READ and XFER_WRITE with h->cciss_read and
h->cciss_write respectively. It seemed to work somehow at least on x86_64 and
ia64. I don't know how. But people started complaining about command timeouts
on older controllers like the 64xx series and only on ia32. This resolves the
issue reproduced in our lab. Please consider this for inclusion.

Signed-off-by: Mike Miller <mike.miller@hp.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] UDP: Fix reversed logic in udp_get_port()
David Miller [Fri, 22 Dec 2006 19:56:21 +0000 (11:56 -0800)]
[PATCH] UDP: Fix reversed logic in udp_get_port()

When this code was converted to use sk_for_each() the
logic for the "best hash chain length" code was reversed,
breaking everything.

The original code was of the form:

size = 0;
do {
if (++size >= best_size_so_far)
goto next;
} while ((sk = sk->next) != NULL);
best_size_so_far = size;
best = result;
next:;

and this got converted into:

sk_for_each(sk2, node, head)
if (++size < best_size_so_far) {
best_size_so_far = size;
best = result;
}

Which does something very very different from the original.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] fix aoe without scatter-gather [Bug 7662]
Ed L Cashin [Fri, 22 Dec 2006 09:09:21 +0000 (01:09 -0800)]
[PATCH] fix aoe without scatter-gather [Bug 7662]

Fix a bug that only appears when AoE goes over a network card that does not
support scatter-gather.  The headers in the linear part of the skb appeared
to be larger than they really were, resulting in data that was offset by 24
bytes.

This patch eliminates the offset data on cards that don't support
scatter-gather or have had scatter-gather turned off.  There remains an
unrelated issue that I'll address in a separate email.

Fixes bugzilla #7662

Signed-off-by: "Ed L. Cashin" <ecashin@coraid.com>
Cc: <stable@kernel.org>
Cc: Greg KH <greg@kroah.com>
Cc: <boddingt@optusnet.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] smc911x: fix netpoll compilation faliure
Vitaly Wool [Fri, 22 Dec 2006 09:08:24 +0000 (01:08 -0800)]
[PATCH] smc911x: fix netpoll compilation faliure

Fix the compilation failure for smc911x.c when NET_POLL_CONTROLLER is set.

Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] Fix for shmem_truncate_range() BUG_ON()
Badari Pulavarty [Fri, 22 Dec 2006 09:06:23 +0000 (01:06 -0800)]
[PATCH] Fix for shmem_truncate_range() BUG_ON()

Ran into BUG() while doing madvise(REMOVE) testing.  If we are punching a
hole into shared memory segment using madvise(REMOVE) and the entire hole
is below the indirect blocks, we hit following assert.

        BUG_ON(limit <= SHMEM_NR_DIRECT);

Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com>
Cc: Hugh Dickins <hugh@veritas.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] sched: fix bad missed wakeups in the i386, x86_64, ia64, ACPI and APM idle...
Ingo Molnar [Thu, 21 Dec 2006 12:20:30 +0000 (13:20 +0100)]
[PATCH] sched: fix bad missed wakeups in the i386, x86_64, ia64, ACPI and APM idle code

Fernando Lopez-Lezcano reported frequent scheduling latencies and audio
xruns starting at the 2.6.18-rt kernel, and those problems persisted all
until current -rt kernels. The latencies were serious and unjustified by
system load, often in the milliseconds range.

After a patient and heroic multi-month effort of Fernando, where he
tested dozens of kernels, tried various configs, boot options,
test-patches of mine and provided latency traces of those incidents, the
following 'smoking gun' trace was captured by him:

                 _------=> CPU#
                / _-----=> irqs-off
               | / _----=> need-resched
               || / _---=> hardirq/softirq
               ||| / _--=> preempt-depth
               |||| /
               |||||     delay
   cmd     pid ||||| time  |   caller
      \   /    |||||   \   |   /
  IRQ_19-1479  1D..1    0us : __trace_start_sched_wakeup (try_to_wake_up)
  IRQ_19-1479  1D..1    0us : __trace_start_sched_wakeup <<...>-5856> (37 0)
  IRQ_19-1479  1D..1    0us : __trace_start_sched_wakeup (c01262ba 0 0)
  IRQ_19-1479  1D..1    0us : resched_task (try_to_wake_up)
  IRQ_19-1479  1D..1    0us : __spin_unlock_irqrestore (try_to_wake_up)
  ...
  <idle>-0     1...1   11us!: default_idle (cpu_idle)
  ...
  <idle>-0     0Dn.1  602us : smp_apic_timer_interrupt (c0103baf 1 0)
  ...
   <...>-5856  0D..2  618us : __switch_to (__schedule)
   <...>-5856  0D..2  618us : __schedule <<idle>-0> (20 162)
   <...>-5856  0D..2  619us : __spin_unlock_irq (__schedule)
   <...>-5856  0...1  619us : trace_stop_sched_switched (__schedule)
   <...>-5856  0D..1  619us : trace_stop_sched_switched <<...>-5856> (37 0)

what is visible in this trace is that CPU#1 ran try_to_wake_up() for
PID:5856, it placed PID:5856 on CPU#0's runqueue and ran resched_task()
for CPU#0. But it decided to not send an IPI that no CPU - due to
TS_POLLING. But CPU#0 never woke up after its NEED_RESCHED bit was set,
and only rescheduled to PID:5856 upon the next lapic timer IRQ. The
result was a 600+ usecs latency and a missed wakeup!

the bug turned out to be an idle-wakeup bug introduced into the mainline
kernel this summer via an optimization in the x86_64 tree:

    commit 495ab9c045e1b0e5c82951b762257fe1c9d81564
    Author: Andi Kleen <ak@suse.de>
    Date:   Mon Jun 26 13:59:11 2006 +0200

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

    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.

the problem is this type of change:

        if (!hlt_counter && boot_cpu_data.hlt_works_ok) {
-               clear_thread_flag(TIF_POLLING_NRFLAG);
+               current_thread_info()->status &= ~TS_POLLING;
                smp_mb__after_clear_bit();
                while (!need_resched()) {
                        local_irq_disable();

this changes clear_thread_flag() to an explicit clearing of TS_POLLING.
clear_thread_flag() is defined as:

        clear_bit(flag, &ti->flags);

and clear_bit() is a LOCK-ed atomic instruction on all x86 platforms:

  static inline void clear_bit(int nr, volatile unsigned long * addr)
  {
          __asm__ __volatile__( LOCK_PREFIX
                  "btrl %1,%0"

hence smp_mb__after_clear_bit() is defined as a simple compile barrier:

  #define smp_mb__after_clear_bit()       barrier()

but the explicit TS_POLLING clearing introduced by the patch:

+               current_thread_info()->status &= ~TS_POLLING;

is not an atomic op! So the clearing of the TS_POLLING bit is freely
reorderable with the reading of the NEED_RESCHED bit - and both now
reside in different memory addresses.

CPU idle wakeup very much depends on ordered memory ops, the clearing of
the TS_POLLING flag must always be done before we test need_resched()
and hit the idle instruction(s). [Symmetrically, the wakeup code needs
to set NEED_RESCHED before it tests the TS_POLLING flag, so memory
ordering is paramount.]

Fernando's dual-core Athlon64 system has a sufficiently advanced memory
ordering model so that it triggered this scenario very often.

( And it also turned out that the reason why these latencies never
  triggered on my testsystems is that i routinely use idle=poll, which
  was the only idle variant not affected by this bug. )

The fix is to change the smp_mb__after_clear_bit() to an smp_mb(), to
act as an absolute barrier between the TS_POLLING write and the
NEED_RESCHED read. This affects almost all idling methods (default,
ACPI, APM), on all 3 x86 architectures: i386, x86_64, ia64.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Tested-by: Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU>
[chrisw: backport to 2.6.19.1]
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] i2c: fix broken ds1337 initialization
Dirk Eibach [Wed, 20 Dec 2006 07:34:43 +0000 (08:34 +0100)]
[PATCH] i2c: fix broken ds1337 initialization

On a custom board with ds1337 RTC I found that upgrade from 2.6.15 to
2.6.18 broke RTC support.

The main problem are changes to ds1337_init_client().
When a ds1337 recognizes a problem (e.g. power or clock failure) bit 7
in status register is set. This has to be reset by writing 0 to status
register. But since there are only 16 byte written to the chip and the
first byte is interpreted as an address, the status register (which is
the 16th) is never written.
The other problem is, that initializing all registers to zero is not
valid for day, date and month register. Funny enough this is checked by
ds1337_detect(), which depends on this values not being zero. So then
treated by ds1337_init_client() the ds1337 is not detected anymore,
whereas the failure bit in the status register is still set.

Broken by commit f9e8957937ebf60d22732a5ca9130f48a7603f60 (2.6.16-rc1,
2006-01-06). This fix is in Linus' tree since 2.6.20-rc1 (commit
763d9c046a2e511ec090a8986d3f85edf7448e7e).

Signed-off-by: Dirk Stieler <stieler@gdsys.de>
Signed-off-by: Dirk Eibach <eibach@gdsys.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] Bluetooth: Add packet size checks for CAPI messages (CVE-2006-6106)
Marcel Holtmann [Mon, 11 Dec 2006 14:18:24 +0000 (15:18 +0100)]
[PATCH] Bluetooth: Add packet size checks for CAPI messages (CVE-2006-6106)

With malformed packets it might be possible to overwrite internal
CMTP and CAPI data structures. This patch adds additional length
checks to prevent these kinds of remote attacks.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] SCSI: add missing cdb clearing in scsi_execute()
Tejun Heo [Sat, 16 Dec 2006 11:02:32 +0000 (20:02 +0900)]
[PATCH] SCSI: add missing cdb clearing in scsi_execute()

Clear-garbage-after-CDB patch missed scsi_execute() and it causes some
ODDs (HL-DT-ST DVD-RAM GSA-H30N) choke during SCSI scan.  Note that
this patch is only for -stable.  There is another more reliable fix
for this problem proposed for devel tree.

http://thread.gmane.org/gmane.linux.ide/14605/focus=14605

Signed-off-by: Tejun Heo <htejun@gmail.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Douglas Gilbert <dougg@torque.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] IB/srp: Fix FMR mapping for 32-bit kernels and addresses above 4G
Roland Dreier [Sat, 16 Dec 2006 04:58:14 +0000 (20:58 -0800)]
[PATCH] IB/srp: Fix FMR mapping for 32-bit kernels and addresses above 4G

struct srp_device.fmr_page_mask was unsigned long, which means that
the top part of addresses above 4G was being chopped off on 32-bit
architectures.  Of course nothing good happens when data from SRP
targets is DMAed to the wrong place.

Fix this by changing fmr_page_mask to u64, to match the addresses
actually used by IB devices.

Thanks to Brian Cain <Brian.Cain@ge.com> and David McMillen
<davem@systemfabricworks.com> for help diagnosing the bug and testing
the fix.

Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] sched: remove __cpuinitdata anotation to cpu_isolated_map
Tim Chen [Wed, 13 Dec 2006 22:17:58 +0000 (14:17 -0800)]
[PATCH] sched: remove __cpuinitdata anotation to cpu_isolated_map

The structure cpu_isolated_map is used not only during initialization.
Multi-core scheduler configuration changes and exclusive cpusets
use this during run time.  During setting of sched_mc_power_savings
 policy, this structure is accessed to update sched_domains.

Signed-off-by: Tim Chen <tim.c.chen@intel.com>
Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
17 years ago[PATCH] ARM: Add sys_*at syscalls
Russell King [Wed, 13 Dec 2006 14:12:15 +0000 (14:12 +0000)]
[PATCH] ARM: Add sys_*at syscalls

Later glibc requires the *at syscalls.  Add them.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>