Makefile | 2
arch/x86/kernel/acpi/sleep.c | 3 +
arch/x86/kernel/amd_iommu_init.c | 2
drivers/acpi/hardware/hwsleep.c | 37 ++++-----------
drivers/acpi/sleep/main.c | 10 ++++
drivers/char/hvc_console.c | 10 ++--
drivers/edac/cell_edac.c | 2
drivers/gpio/gpiolib.c | 2
drivers/md/dm-kcopyd.c | 13 +++++
drivers/md/dm-snap.c | 10 +---
drivers/media/video/pvrusb2/pvrusb2-hdw.c | 6 --
drivers/pci/hotplug/cpqphp_core.c | 2
drivers/scsi/device_handler/scsi_dh_rdac.c | 2
drivers/usb/atm/speedtch.c | 12 +++++
drivers/usb/class/cdc-acm.c | 3 -
drivers/usb/class/cdc-wdm.c | 2
drivers/usb/core/driver.c | 3 -
drivers/usb/core/hub.c | 2
fs/cifs/readdir.c | 3 -
fs/ext2/dir.c | 60 ++++++++++++++-----------
fs/ext3/dir.c | 10 ++--
fs/ext4/dir.c | 11 +++-
fs/proc/task_mmu.c | 34 +++++++++-----
kernel/sched_stats.h | 2
mm/rmap.c | 42 +++++++++++++----
net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 2
net/ipv4/netfilter/nf_nat_snmp_basic.c | 1
net/netfilter/xt_iprange.c | 8 +--
28 files changed, 184 insertions(+), 112 deletions(-)
New commits:
commit 056c71459d3acf9fefcb2dc67abeef10e649d508
Author: Greg Kroah-Hartman <[EMAIL PROTECTED]>
Date: Sat Oct 25 15:05:07 2008 -0700
Linux 2.6.27.4
commit 1b146f86965053c2496f9ce22c9e26a770930c66
Author: Mike Isely <[EMAIL PROTECTED]>
Date: Sun Oct 19 16:26:05 2008 -0300
V4L/DVB (9300): pvrusb2: Fix deadlock problem
commit c82732a42896364296599b0f73f01c5e3fd781ae upstream
Fix deadlock problem in 2.6.27 caused by new USB core behavior in
response to a USB device reset request. With older kernels, the USB
device reset was "in line"; the reset simply took place and the driver
retained its association with the hardware. However now this reset
triggers a disconnect, and worse still the disconnect callback happens
in the context of the caller who asked for the device reset. This
results in an attempt by the pvrusb2 driver to recursively take a
mutex it already has, which deadlocks the driver's worker thread.
(Even if the disconnect callback were to happen on a different thread
we'd still have problems however - because while the driver should
survive and correctly disconnect / reconnect, it will then trigger
another device reset during the repeated initialization, which will
then cause another disconect, etc, forever.) The fix here is simply
to not attempt the device reset (it was of marginal value anyway).
Signed-off-by: Mike Isely <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Signed-off-by: Mike Krufky <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit daa0b0ad2666acdb331e6611ca790fd0dfe6a1b0
Author: Kenji Kaneshige <[EMAIL PROTECTED]>
Date: Fri Oct 24 02:50:03 2008 +0000
PCI hotplug: cpqphp: fix kernel NULL pointer dereference
commit d2174c3c07adad88dd9ba37a731e0b00b746822a upstream
The following patch fixes the regression in 2.6.27 that causes kernel
NULL pointer dereference at cpqphp driver probe time. This patch should
be backported to the .27 stable series.
Seems to have been introduced by
f46753c5e354b857b20ab8e0fe7b2579831dc369.
The root cause of this problem seems that cpqphp driver calls
pci_hp_register() wrongly. In current implementation, cpqphp driver
passes 'ctrl->pci_dev->subordinate' as a second parameter for
pci_hp_register(). But because hotplug slots and it's hotplug controller
(exists as a pci funcion) are on the same bus, it should be
'ctrl->pci_dev->bus' instead.
Tested-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Kenji Kaneshige <[EMAIL PROTECTED]>
Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 3ee82b553d04d90948a41eef761302afcf3f1805
Author: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Thu Oct 2 12:18:33 2008 -0500
SCSI: scsi_dh: add Dell product information into rdac device handler
commit 650849d71ca05d55a1553fe42fb21af9dce5612b upstream.
Add Dell Powervault storage arrays into device list of rdac device
handler.
Signed-off-by: Yanqing Liu <[EMAIL PROTECTED]>
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
Cc: shyam iyer <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit a75aefa2c83b7eea2cced4d7ff70eb1d50e926df
Author: Joe Korty <[EMAIL PROTECTED]>
Date: Thu Oct 23 18:14:25 2008 -0400
proc: fix vma display mismatch between /proc/pid/{maps,smaps}
[ backport of 7c88db0cb589df980acfb2f73c3595a0653004ec to 2.7.27.3 by Joe
Korty <[EMAIL PROTECTED] ]
proc: fix vma display mismatch between /proc/pid/{maps,smaps}
Commit 4752c369789250eafcd7813e11c8fb689235b0d2 aka
"maps4: simplify interdependence of maps and smaps" broke /proc/pid/smaps,
causing it to display some vmas twice and other vmas not at all. For
example:
grep .- /proc/1/smaps >/tmp/smaps; diff /proc/1/maps /tmp/smaps
1 25d24
2 < 7fd7e23aa000-7fd7e23ac000 rw-p 7fd7e23aa000 00:00 0
3 28a28
4 > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
The bug has something to do with setting m->version before all the
seq_printf's have been performed. show_map was doing this correctly,
but show_smap was doing this in the middle of its seq_printf sequence.
This patch arranges things so that the setting of m->version in show_smap
is also done at the end of its seq_printf sequence.
Testing: in addition to the above grep test, for each process I summed
up the 'Rss' fields of /proc/pid/smaps and compared that to the 'VmRSS'
field of /proc/pid/status. All matched except for Xorg (which has a
/dev/mem mapping which Rss accounts for but VmRSS does not). This result
gives us some confidence that neither /proc/pid/maps nor /proc/pid/smaps
are any longer skipping or double-counting vmas.
Signed-off-by: Joe Korty <[EMAIL PROTECTED]>
Cc: Matt Mackall <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
commit 3b987ac961486373f91191b14291b331fa546072
Author: Rafael J. Wysocki <[EMAIL PROTECTED]>
Date: Sat Sep 6 13:13:01 2008 +0200
ACPI suspend: Always use the 32-bit waking vector
commit a6629105dd03d370fcb31e97bddf223fa4bb651e upstream.
According to the ACPI specification 2.0c and later, the 64-bit waking vector
should be cleared and the 32-bit waking vector should be used, unless we
want
the wake-up code to be called by the BIOS in Protected Mode. Moreover, some
systems (for example HP dv5-1004nr) are known to fail to resume if the
64-bit
waking vector is used. Therefore, modify the code to clear the 64-bit
waking
vector, for FACS version 1 or greater, and set the 32-bit one before
suspend.
http://bugzilla.kernel.org/show_bug.cgi?id=11368
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit a25e0acfb0217c3910151af3ae6b020fd0bad094
Author: Rafael J. Wysocki <[EMAIL PROTECTED]>
Date: Tue Oct 14 22:54:06 2008 +0200
ACPI suspend: Blacklist HP xw4600 Workstation for old code ordering
commit 4fb507b6b764195bb7821cf2baa988f6eb677d30 upstream
HP xw4600 Workstation is known to require the "old" (ie. compatible
with ACPI 1.0) suspend code ordering, so blacklist it for this
purpose.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Tested-by: John Brown <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 66036f5862883fcc9f7ff8550685a5a3de1a57e4
Author: Rafael J. Wysocki <[EMAIL PROTECTED]>
Date: Sat Oct 4 00:05:05 2008 +0200
ACPI Suspend: Enable ACPI during resume if SCI_EN is not set
commit d0c71fe7ebc180f1b7bc7da1d39a07fc19eec768 upstream.
On some machines, like for example MSI Wind U100, the BIOS doesn't
enable ACPI before returning control to the OS, which sometimes
causes resume to fail. This is against the ACPI specification,
which clearly states that "When the platform is waking from an S1, S2
or S3 state, OSPM assumes the hardware is already in the ACPI mode
and will not issue an ACPI_ENABLE", but it won't hurt to check the
SCI_EN bit and enable ACPI during resume from S3 if this bit is not
set.
Fortunately, we already have acpi_enable() for that, so use it in the
resume code path, before executing _BFS, in analogy with the
resume-from-hibernation code path.
NOTE: We aren't supposed to set SCI_EN directly, because it's owned
by the hardware.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 220d13c9015f53509245807f4e4d86e8d062a26d
Author: Christian Borntraeger <[EMAIL PROTECTED]>
Date: Thu Oct 23 12:18:31 2008 +1100
hvc_console: Fix free_irq in spinlocked section
commit eef2622a9fcfa964073333ea72c7c9cd20ad45e6 upstream
hvc_console: Fix free_irq in spinlocked section
commit 611e097d7707741a336a0677d9d69bec40f29f3d
Author: Christian Borntraeger <[EMAIL PROTECTED]>
hvc_console: rework setup to replace irq functions with callbacks
introduced a spinlock recursion problem. The notifier_del is
called with a lock held, and in turns calls free_irq which then
complains when manipulating procfs. This fixes it by moving the
call to the notifier to outside of the locked section.
Signed-off-by: Christian Borntraeger<[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 07a96d7019701ce9e6be9bd975e4f9d021649a8f
Author: Linus Torvalds <[EMAIL PROTECTED]>
Date: Sun Oct 19 10:32:20 2008 -0700
anon_vma_prepare: properly lock even newly allocated entries
commit d9d332e0874f46b91d8ac4604b68ee42b8a7a2c6 upstream
The anon_vma code is very subtle, and we end up doing optimistic lookups
of anon_vmas under RCU in page_lock_anon_vma() with no locking. Other
CPU's can also see the newly allocated entry immediately after we've
exposed it by setting "vma->anon_vma" to the new value.
We protect against the anon_vma being destroyed by having the SLAB
marked as SLAB_DESTROY_BY_RCU, so the RCU lookup can depend on the
allocation not being destroyed - but it might still be free'd and
re-allocated here to a new vma.
As a result, we should not do the anon_vma list ops on a newly allocated
vma without proper locking.
Acked-by: Nick Piggin <[EMAIL PROTECTED]>
Acked-by: Hugh Dickins <[EMAIL PROTECTED]>
Acked-by: Peter Zijlstra <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 373775331502999bcf0e37e8cb06488f65482939
Author: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed Oct 22 19:41:31 2008 +0200
netfilter: restore lost ifdef guarding defrag exception
netfilter: restore lost #ifdef guarding defrag exception
Upstream commit 38f7ac3eb:
Nir Tzachar <[EMAIL PROTECTED]> reported a warning when sending
fragments over loopback with NAT:
[ 6658.338121] WARNING: at net/ipv4/netfilter/nf_nat_standalone.c:89
nf_nat_fn+0x33/0x155()
The reason is that defragmentation is skipped for already tracked
connections.
This is wrong in combination with NAT and ip_conntrack actually had some
ifdefs
to avoid this behaviour when NAT is compiled in.
The entire "optimization" may seem a bit silly, for now simply restoring the
lost #ifdef is the easiest solution until we can come up with something
better.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 2abb966556649d871174343386ad71b78e12a47a
Author: Ilpo Järvinen <[EMAIL PROTECTED]>
Date: Wed Oct 22 19:41:29 2008 +0200
netfilter: snmp nat leaks memory in case of failure
netfilter: snmp nat leaks memory in case of failure
Upstream commit 311670f3e:
Signed-off-by: Ilpo Jarvinen <[EMAIL PROTECTED]>
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
commit c903fcb8747d4b8c2af95e058877e106da23e82a
Author: Alexey Dobriyan <[EMAIL PROTECTED]>
Date: Wed Oct 22 19:41:28 2008 +0200
netfilter: xt_iprange: fix range inversion match
netfilter: xt_iprange: fix range inversion match
Upstream commit 6def1eb48:
Inverted IPv4 v1 and IPv6 v0 matches don't match anything since 2.6.25-rc1!
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
Acked-by: Jan Engelhardt <[EMAIL PROTECTED]>
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 382931f3e09030e7e4d7fcaee2ad3cdc1d396a14
Author: Eric Sandeen <[EMAIL PROTECTED]>
Date: Wed Oct 22 10:11:52 2008 -0500
ext[234]: Avoid printk floods in the face of directory corruption
(CVE-2008-3528)
This is a trivial backport of the following upstream commits:
- bd39597cbd42a784105a04010100e27267481c67 (ext2)
- cdbf6dba28e8e6268c8420857696309470009fd9 (ext3)
- 9d9f177572d9e4eba0f2e18523b44f90dd51fe74 (ext4)
This addresses CVE-2008-3528
ext[234]: Avoid printk floods in the face of directory corruption
Note: some people thinks this represents a security bug, since it
might make the system go away while it is printing a large number of
console messages, especially if a serial console is involved. Hence,
it has been assigned CVE-2008-3528, but it requires that the attacker
either has physical access to your machine to insert a USB disk with a
corrupted filesystem image (at which point why not just hit the power
button), or is otherwise able to convince the system administrator to
mount an arbitrary filesystem image (at which point why not just
include a setuid shell or world-writable hard disk device file or some
such). Me, I think they're just being silly. --tytso
Signed-off-by: Eric Sandeen <[EMAIL PROTECTED]>
Signed-off-by: "Theodore Ts'o" <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: Eugene Teo <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 0f3da51e7046e2eb28992ba65c22d058f571356c
Author: Jeff Layton <[EMAIL PROTECTED]>
Date: Thu Oct 23 18:05:02 2008 +0000
CIFS: fix saving of resume key before CIFSFindNext
commit a364bc0b37f14ffd66c1f982af42990a9d77fa43 upstream
We recently fixed the cifs readdir code so that it saves the resume key
before calling CIFSFindNext. Unfortunately, this assumes that we have
just done a CIFSFindFirst (or FindNext) and have resume info to save.
This isn't necessarily the case. Fix the code to save resume info if we
had to reinitiate the search, and after a FindNext.
This fixes connectathon basic test6 against NetApp filers.
Signed-off-by: Jeff Layton <[EMAIL PROTECTED]>
Signed-off-by: Steve French <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 5880100d91db1337c6604bf704c08c3c3dd4bf13
Author: Andreas Herrmann <[EMAIL PROTECTED]>
Date: Thu Oct 23 17:35:28 2008 +0000
amd_iommu: fix nasty bug that caused ILLEGAL_DEVICE_TABLE_ENTRY errors
commit f609891f428e1c20e270e7c350daf8c93cc459d7 upstream
We are on 64-bit so better use u64 instead of u32 to deal with
addresses:
static void __init iommu_set_device_table(struct amd_iommu *iommu)
{
u64 entry;
...
entry = virt_to_phys(amd_iommu_dev_table);
...
(I am wondering why gcc 4.2.x did not warn about the assignment
between u32 and unsigned long.)
Cc: [EMAIL PROTECTED]
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 1ea93b4aadc022277ddf92cf2aaa9ab00ca9a9b1
Author: Mikulas Patocka <[EMAIL PROTECTED]>
Date: Thu Oct 23 17:35:22 2008 +0000
dm snapshot: fix primary_pe race
commit 7c5f78b9d7f21937e46c26db82976df4b459c95c upstream
Fix a race condition with primary_pe ref_count handling.
put_pending_exception runs under dm_snapshot->lock, it does
atomic_dec_and_test
on primary_pe->ref_count, and later does atomic_read primary_pe->ref_count.
__origin_write does atomic_dec_and_test on primary_pe->ref_count without
holding
dm_snapshot->lock.
This opens the following race condition:
Assume two CPUs, CPU1 is executing put_pending_exception (and holding
dm_snapshot->lock). CPU2 is executing __origin_write in parallel.
primary_pe->ref_count == 2.
CPU1:
if (primary_pe && atomic_dec_and_test(&primary_pe->ref_count))
origin_bios = bio_list_get(&primary_pe->origin_bios);
.. decrements primary_pe->ref_count to 1. Doesn't load origin_bios
CPU2:
if (first && atomic_dec_and_test(&primary_pe->ref_count)) {
flush_bios(bio_list_get(&primary_pe->origin_bios));
free_pending_exception(primary_pe);
/* If we got here, pe_queue is necessarily empty. */
return r;
}
.. decrements primary_pe->ref_count to 0, submits pending bios, frees
primary_pe.
CPU1:
if (!primary_pe || primary_pe != pe)
free_pending_exception(pe);
.. this has no effect.
if (primary_pe && !atomic_read(&primary_pe->ref_count))
free_pending_exception(primary_pe);
.. sees ref_count == 0 (written by CPU 2), does double free !!
This bug can happen only if someone is simultaneously writing to both the
origin and the snapshot.
If someone is writing only to the origin, __origin_write will submit kcopyd
request after it decrements primary_pe->ref_count (so it can't happen that
the
finished copy races with primary_pe->ref_count decrementation).
If someone is writing only to the snapshot, __origin_write isn't invoked at
all
and the race can't happen.
The race happens when someone writes to the snapshot --- this creates
pending_exception with primary_pe == NULL and starts copying. Then, someone
writes to the same chunk in the snapshot, and __origin_write races with
termination of already submitted request in pending_complete (that calls
put_pending_exception).
This race may be reason for bugs:
http://bugzilla.kernel.org/show_bug.cgi?id=11636
https://bugzilla.redhat.com/show_bug.cgi?id=465825
The patch fixes the code to make sure that:
1. If atomic_dec_and_test(&primary_pe->ref_count) returns false, the process
must no longer dereference primary_pe (because someone else may free it
under
us).
2. If atomic_dec_and_test(&primary_pe->ref_count) returns true, the process
is responsible for freeing primary_pe.
Signed-off-by: Mikulas Patocka <[EMAIL PROTECTED]>
Signed-off-by: Alasdair G Kergon <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit c17e59af0d10fe9c5616109fab5ac879cad1cd61
Author: Kazuo Ito <[EMAIL PROTECTED]>
Date: Thu Oct 23 17:35:24 2008 +0000
dm kcopyd: avoid queue shuffle
commit b673c3a8192e28f13e2050a4b82c1986be92cc15 upstream
Write throughput to LVM snapshot origin volume is an order
of magnitude slower than those to LV without snapshots or
snapshot target volumes, especially in the case of sequential
writes with O_SYNC on.
The following patch originally written by Kevin Jamieson and
Jan Blunck and slightly modified for the current RCs by myself
tries to improve the performance by modifying the behaviour
of kcopyd, so that it pushes back an I/O job to the head of
the job queue instead of the tail as process_jobs() currently
does when it has to wait for free pages. This way, write
requests aren't shuffled to cause extra seeks.
I tested the patch against 2.6.27-rc5 and got the following results.
The test is a dd command writing to snapshot origin followed by fsync
to the file just created/updated. A couple of filesystem benchmarks
gave me similar results in case of sequential writes, while random
writes didn't suffer much.
dd if=/dev/zero of=<somewhere on snapshot origin> bs=4096 count=...
[conv=notrunc when updating]
1) linux 2.6.27-rc5 without the patch, write to snapshot origin,
average throughput (MB/s)
10M 100M 1000M
create,dd 511.46 610.72 11.81
create,dd+fsync 7.10 6.77 8.13
update,dd 431.63 917.41 12.75
update,dd+fsync 7.79 7.43 8.12
compared with write throughput to LV without any snapshots,
all dd+fsync and 1000 MiB writes perform very poorly.
10M 100M 1000M
create,dd 555.03 608.98 123.29
create,dd+fsync 114.27 72.78 76.65
update,dd 152.34 1267.27 124.04
update,dd+fsync 130.56 77.81 77.84
2) linux 2.6.27-rc5 with the patch, write to snapshot origin,
average throughput (MB/s)
10M 100M 1000M
create,dd 537.06 589.44 46.21
create,dd+fsync 31.63 29.19 29.23
update,dd 487.59 897.65 37.76
update,dd+fsync 34.12 30.07 26.85
Although still not on par with plain LV performance -
cannot be avoided because it's copy on write anyway -
this simple patch successfully improves throughtput
of dd+fsync while not affecting the rest.
Signed-off-by: Jan Blunck <[EMAIL PROTECTED]>
Signed-off-by: Kazuo Ito <[EMAIL PROTECTED]>
Signed-off-by: Alasdair G Kergon <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 08177861a152254ba025b751559e592757e31475
Author: Alan Stern <[EMAIL PROTECTED]>
Date: Thu Oct 23 17:35:13 2008 +0000
USB: Speedtouch: add pre_reset and post_reset routines
commit 8fc7aeab3851ed8c3ecf28901ca2c6f0400955c7 upstream
This patch (as1150) fixes a problem in the speedtch driver. When it
resets the modem during probe it will be unbound from the other
interfaces it has claimed, because it doesn't define a pre_reset and a
post_reset method.
The patch defines "do-nothing" methods. This fixes Bugzilla #11767.
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 837de9e1d92bb73408088f7b5849715d90925fee
Author: Oliver Neukum <[EMAIL PROTECTED]>
Date: Thu Oct 23 17:35:09 2008 +0000
USB: fix memory leak in cdc-acm
commit a496c64f1363ec4d67ebdc1e1f619ad6372a574c upstream
This fixes a memory leak on disconnect in cdc-acm
Thanks to æ½éå for finding it.
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 1769c339cde4c1da819ee97513e9340413cef3c5
Author: Alan Stern <[EMAIL PROTECTED]>
Date: Thu Oct 23 17:35:07 2008 +0000
USB: don't rebind drivers after failed resume or reset
commit 6c6409459a18a825ce12ecb003d5686af61f7a2f upstream
This patch (as1152) may help prevent some problems associated with the
new policy of unbinding drivers that don't support suspend/resume or
pre_reset/post_reset. If for any reason the resume or reset fails, and
the device is logically disconnected, there's no point in trying to
rebind the driver. So the patch checks for success before carrying
out the unbind/rebind.
There was a report from one user that this fixed a problem he was
experiencing, but the details never became fully clear. In any case,
adding these tests can't hurt.
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 8cece7795b1c359787261a150ac502b250c6699f
Author: Oliver Neukum <[EMAIL PROTECTED]>
Date: Thu Oct 23 17:35:11 2008 +0000
USB: cdc-wdm: make module autoload work
commit aa5380b904e7f896db0931320160bdea93e41f6a upstream
this fixes an omission that led to no alias being computed for the
cdc-wdm module.
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 919e14cd03504d00e4ba13933ac229f7eca21444
Author: Miao Xie <[EMAIL PROTECTED]>
Date: Thu Oct 23 16:50:03 2008 +0000
sched: fix the wrong mask_len
commit c851c8676bd7ae456e9b3af8e6bb2c434eddcc75 upstream
If NR_CPUS isn't a multiple of 32, we get a truncated string of sched
domains by catting /proc/schedstat. This is caused by the wrong mask_len.
This patch fixes it.
Signed-off-by: Miao Xie <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit bc79810633524ea09b77e3de3ba3f4a97f2152b7
Author: Rafael J. Wysocki <[EMAIL PROTECTED]>
Date: Mon Oct 20 21:30:19 2008 +0000
x86 ACPI: fix breakage of resume on 64-bit UP systems with SMP kernel
commit 3038edabf48f01421c621cb77a712b446d3a5d67 upstream
x86 ACPI: Fix breakage of resume on 64-bit UP systems with SMP kernel
We are now using per CPU GDT tables in head_64.S and the original
early_gdt_descr.address is invalidated after boot by
setup_per_cpu_areas(). This breaks resume from suspend to RAM on
x86_64 UP systems using SMP kernels, because this part of head_64.S
is also executed during the resume and the invalid GDT address
causes the system to crash. It doesn't break on 'true' SMP systems,
because early_gdt_descr.address is modified every time
native_cpu_up() runs. However, during resume it should point to the
GDT of the boot CPU rather than to another CPU's GDT.
For this reason, during suspend to RAM always make
early_gdt_descr.address point to the boot CPU's GDT.
This fixes http://bugzilla.kernel.org/show_bug.cgi?id=11568, which
is a regression from 2.6.26.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Reported-and-tested-by: Andy Wettstein <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 204d439e5c39809d05f15b93cfabac1cbb99e1a7
Author: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Mon Oct 20 16:50:07 2008 +0000
edac cell: fix incorrect edac_mode
commit 3b274f44d2ca05f719fe39947b6a5293a2dbd8fd upstream
The cell_edac driver is setting the edac_mode field of the csrow's to an
incorrect value, causing the sysfs show routine for that field to go out
of an array bound and Oopsing the kernel when used.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: Doug Thompson <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit a2d18f62f58e8b5128c4ac7173ac15a8fa559b9c
Author: David Brownell <[EMAIL PROTECTED]>
Date: Mon Oct 20 16:50:10 2008 +0000
gpiolib: fix oops in gpio_get_value_cansleep()
commit 978ccaa8ea5d8c7bf6b676209f2fc126eae6355b upstream
We can get the following oops from gpio_get_value_cansleep() when a GPIO
controller doesn't provide a get() callback:
Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0x00000000
Oops: Kernel access of bad area, sig: 11 [#1]
[...]
NIP [00000000] 0x0
LR [c0182fb0] gpio_get_value_cansleep+0x40/0x50
Call Trace:
[c7b79e80] [c0183f28] gpio_value_show+0x5c/0x94
[c7b79ea0] [c01a584c] dev_attr_show+0x30/0x7c
[c7b79eb0] [c00d6b48] fill_read_buffer+0x68/0xe0
[c7b79ed0] [c00d6c54] sysfs_read_file+0x94/0xbc
[c7b79ef0] [c008f24c] vfs_read+0xb4/0x16c
[c7b79f10] [c008f580] sys_read+0x4c/0x90
[c7b79f40] [c0013a14] ret_from_syscall+0x0/0x38
It's OK to request the value of *any* GPIO; most GPIOs are bidirectional,
so configuring them as outputs just enables an output driver and doesn't
disable the input logic.
So the problem is that gpio_get_value_cansleep() isn't making the same
sanity check that gpio_get_value() does: making sure this GPIO isn't one
of the atypical "no input logic" cases.
Reported-by: Anton Vorontsov <[EMAIL PROTECTED]>
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=056c71459d3acf9fefcb2dc67abeef10e649d508
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=1b146f86965053c2496f9ce22c9e26a770930c66
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=daa0b0ad2666acdb331e6611ca790fd0dfe6a1b0
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=3ee82b553d04d90948a41eef761302afcf3f1805
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=a75aefa2c83b7eea2cced4d7ff70eb1d50e926df
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=3b987ac961486373f91191b14291b331fa546072
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=a25e0acfb0217c3910151af3ae6b020fd0bad094
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=66036f5862883fcc9f7ff8550685a5a3de1a57e4
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=220d13c9015f53509245807f4e4d86e8d062a26d
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=07a96d7019701ce9e6be9bd975e4f9d021649a8f
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=373775331502999bcf0e37e8cb06488f65482939
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=2abb966556649d871174343386ad71b78e12a47a
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=c903fcb8747d4b8c2af95e058877e106da23e82a
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=382931f3e09030e7e4d7fcaee2ad3cdc1d396a14
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=0f3da51e7046e2eb28992ba65c22d058f571356c
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=5880100d91db1337c6604bf704c08c3c3dd4bf13
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=1ea93b4aadc022277ddf92cf2aaa9ab00ca9a9b1
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=c17e59af0d10fe9c5616109fab5ac879cad1cd61
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=08177861a152254ba025b751559e592757e31475
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=837de9e1d92bb73408088f7b5849715d90925fee
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=1769c339cde4c1da819ee97513e9340413cef3c5
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=8cece7795b1c359787261a150ac502b250c6699f
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=919e14cd03504d00e4ba13933ac229f7eca21444
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=bc79810633524ea09b77e3de3ba3f4a97f2152b7
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=204d439e5c39809d05f15b93cfabac1cbb99e1a7
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=a2d18f62f58e8b5128c4ac7173ac15a8fa559b9c
_______________________________________________
svn mailing list
[email protected]
http://mailman.vyatta.com/mailman/listinfo/svn
