This is the start of the longterm review cycle for the 2.6.32.42 release.
There are 91 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let us know. If anyone is a maintainer of the proper subsystem, and
wants to add a Signed-off-by: line to the patch, please respond with it.
Responses should be made by Sat, Jun 18, 2011, 00:00:00 UTC.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v2.6/longterm-review/patch-2.6.32.-rc1.gz
and the diffstat can be found below.
The full set of patches will be sent, as normal, however they will be
delayed by a few hours out of respect for those still awake and trying
to get work done.
thanks,
greg k-h
Makefile | 2 +-
arch/powerpc/kernel/misc_64.S | 13 ++++--
arch/powerpc/oprofile/op_model_power4.c | 24 +++++++++++-
arch/x86/include/asm/uaccess.h | 2 +-
arch/x86/kernel/amd_iommu_init.c | 8 ++--
arch/x86/kernel/cpu/amd.c | 16 +++++--
arch/x86/kernel/process_32.c | 1 -
arch/x86/kernel/process_64.c | 1 -
arch/x86/lib/copy_user_64.S | 4 +-
arch/x86/xen/mmu.c | 2 +-
arch/x86/xen/multicalls.c | 12 +++---
block/blk-core.c | 2 +
block/blk.h | 3 +-
drivers/acpi/scan.c | 12 +++---
drivers/ata/pata_cmd64x.c | 66 ++++++++++++++++++++----------
drivers/ata/pata_hpt366.c | 8 +---
drivers/ata/pata_hpt37x.c | 21 ++++------
drivers/ata/pata_hpt3x2n.c | 15 ++-----
drivers/ata/pata_sil680.c | 6 +--
drivers/block/brd.c | 11 +++--
drivers/block/loop.c | 11 +++--
drivers/block/nbd.c | 6 +++
drivers/char/i8k.c | 4 +-
drivers/cpufreq/cpufreq.c | 20 ++++++++-
drivers/cpufreq/cpufreq_stats.c | 22 +++++++++-
drivers/cpuidle/governors/menu.c | 4 +-
drivers/gpu/drm/i915/intel_lvds.c | 8 ++++
drivers/gpu/drm/radeon/radeon_device.c | 1 +
drivers/md/dm-table.c | 17 ++++++++
drivers/md/md.c | 2 +-
drivers/md/raid5.c | 8 ++--
drivers/mtd/mtdconcat.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 2 +-
drivers/net/wireless/p54/p54usb.c | 1 +
drivers/pci/hotplug/pcihp_slot.c | 45 +++++++++++++++++++++
drivers/pci/pci.c | 8 +++-
drivers/pci/quirks.c | 10 +++++
drivers/scsi/scsi_scan.c | 11 +++--
drivers/scsi/scsi_sysfs.c | 19 ++++-----
drivers/scsi/ultrastor.c | 2 +-
drivers/staging/usbip/usbip_common.c | 2 +-
drivers/usb/class/cdc-acm.c | 2 +
drivers/usb/core/hub.c | 6 ++-
drivers/usb/gadget/at91_udc.c | 2 +-
drivers/usb/gadget/f_rndis.c | 3 +-
drivers/usb/host/ohci-pci.c | 12 +++++-
drivers/usb/host/xhci-mem.c | 18 +++++++--
drivers/usb/serial/cp210x.c | 4 ++
drivers/usb/serial/ftdi_sio.c | 2 +
drivers/usb/serial/ftdi_sio_ids.h | 6 +++
drivers/usb/serial/garmin_gps.c | 20 ++++++---
drivers/usb/serial/moto_modem.c | 1 +
drivers/xen/events.c | 9 +----
fs/block_dev.c | 27 ++++++++----
fs/dcookies.c | 3 +
fs/ecryptfs/keystore.c | 46 ++++++++++------------
fs/exec.c | 5 +--
fs/ext3/namei.c | 13 +++++-
fs/ext4/mballoc.c | 2 +
fs/fat/file.c | 2 +-
fs/jbd/commit.c | 9 +++-
fs/jbd/journal.c | 16 ++++++-
fs/partitions/ldm.c | 5 ++
fs/ubifs/journal.c | 1 +
fs/ubifs/sb.c | 3 +-
fs/ubifs/shrinker.c | 6 ++-
fs/ubifs/super.c | 1 +
fs/xfs/linux-2.6/xfs_sync.c | 16 ++++++--
fs/xfs/linux-2.6/xfs_sync.h | 1 +
fs/xfs/xfs_iget.c | 1 +
include/linux/interrupt.h | 3 +-
include/linux/pci_ids.h | 2 +
include/linux/seqlock.h | 4 +-
kernel/irq/manage.c | 11 +++++-
kernel/irq/pm.c | 3 -
kernel/lockdep.c | 2 +-
kernel/time/timekeeping.c | 9 +++-
kernel/trace/ftrace.c | 12 +++--
lib/locking-selftest.c | 2 +-
mm/hugetlb.c | 4 +-
mm/kmemleak.c | 7 ++-
mm/page_alloc.c | 2 +-
net/atm/atm_sysfs.c | 10 +++++
net/ipv6/netfilter/ip6t_REJECT.c | 4 +-
net/ipv6/netfilter/nf_conntrack_reasm.c | 8 +---
net/netfilter/xt_DSCP.c | 2 +-
net/sunrpc/xprtsock.c | 16 ++++++-
net/wireless/nl80211.c | 2 +-
sound/pci/hda/patch_realtek.c | 1 +
sound/pci/hda/patch_sigmatel.c | 2 +-
sound/soc/codecs/wm_hubs.c | 24 +++++++-----
91 files changed, 552 insertions(+), 256 deletions(-)
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Steven Rostedt <[email protected]>
commit 058e297d34a404caaa5ed277de15698d8dc43000 upstream.
If function tracing is enabled, a read of the filter files will
cause the call to stop_machine to update the function trace sites.
It should only call stop_machine on write.
Signed-off-by: Steven Rostedt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/trace/ftrace.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -2360,14 +2360,16 @@ ftrace_regex_release(struct inode *inode
ftrace_match_records(parser->buffer, parser->idx, enable);
}
- mutex_lock(&ftrace_lock);
- if (ftrace_start_up && ftrace_enabled)
- ftrace_run_update_code(FTRACE_ENABLE_CALLS);
- mutex_unlock(&ftrace_lock);
-
trace_parser_put(parser);
kfree(iter);
+ if (file->f_mode & FMODE_WRITE) {
+ mutex_lock(&ftrace_lock);
+ if (ftrace_start_up && ftrace_enabled)
+ ftrace_run_update_code(FTRACE_ENABLE_CALLS);
+ mutex_unlock(&ftrace_lock);
+ }
+
mutex_unlock(&ftrace_regex_lock);
return 0;
}
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Catalin Marinas <[email protected]>
commit 52c3ce4ec5601ee383a14f1485f6bac7b278896e upstream.
The kmemleak_seq_next() function tries to get an object (and increment
its use count) before returning it. If it could not get the last object
during list traversal (because it may have been freed), the function
should return NULL rather than a pointer to such object that it did not
get.
Signed-off-by: Catalin Marinas <[email protected]>
Reported-by: Phil Carmody <[email protected]>
Acked-by: Phil Carmody <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/kmemleak.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -1354,9 +1354,12 @@ static void *kmemleak_seq_next(struct se
++(*pos);
list_for_each_continue_rcu(n, &object_list) {
- next_obj = list_entry(n, struct kmemleak_object, object_list);
- if (get_object(next_obj))
+ struct kmemleak_object *obj =
+ list_entry(n, struct kmemleak_object, object_list);
+ if (get_object(obj)) {
+ next_obj = obj;
break;
+ }
}
put_object(prev_obj);
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Jacob Shin <[email protected]>
commit 27ecddc2a9f99ce4ac9a59a0acd77f7100b6d034 upstream.
When we discover CPUs that are affected by each other's
frequency/voltage transitions, the first CPU gets a sysfs directory
created, and rest of the siblings get symlinks. Currently, when we
hotplug off only the first CPU, all of the symlinks and the sysfs
directory gets removed. Even though rest of the siblings are still
online and functional, they are orphaned, and no longer governed by
cpufreq.
This patch, given the above scenario, creates a sysfs directory for
the first sibling and symlinks for the rest of the siblings.
Please note the recursive call, it was rather too ugly to roll it
out. And the removal of redundant NULL setting (it is already taken
care of near the top of the function).
Signed-off-by: Jacob Shin <[email protected]>
Acked-by: Mark Langsdorf <[email protected]>
Reviewed-by: Thomas Renninger <[email protected]>
Signed-off-by: Dave Jones <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/cpufreq/cpufreq.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1183,12 +1183,28 @@ static int __cpufreq_remove_dev(struct s
unlock_policy_rwsem_write(cpu);
+ cpufreq_debug_enable_ratelimit();
+
+#ifdef CONFIG_HOTPLUG_CPU
+ /* when the CPU which is the parent of the kobj is hotplugged
+ * offline, check for siblings, and create cpufreq sysfs interface
+ * and symlinks
+ */
+ if (unlikely(cpumask_weight(data->cpus) > 1)) {
+ /* first sibling now owns the new sysfs dir */
+ cpumask_clear_cpu(cpu, data->cpus);
+ cpufreq_add_dev(get_cpu_sysdev(cpumask_first(data->cpus)));
+
+ /* finally remove our own symlink */
+ lock_policy_rwsem_write(cpu);
+ __cpufreq_remove_dev(sys_dev);
+ }
+#endif
+
free_cpumask_var(data->related_cpus);
free_cpumask_var(data->cpus);
kfree(data);
- per_cpu(cpufreq_cpu_data, cpu) = NULL;
- cpufreq_debug_enable_ratelimit();
return 0;
}
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: steven finney <[email protected]>
commit 98586ed8b8878e10691203687e89a42fa3355300 upstream.
When a CPU is taken offline in an SMP system, cpufreq_remove_dev()
nulls out the per-cpu policy before cpufreq_stats_free_table() can
make use of it. cpufreq_stats_free_table() then skips the
call to sysfs_remove_group(), leaving about 100 bytes of sysfs-related
memory unclaimed each time a CPU-removal occurs. Break up
cpu_stats_free_table into sysfs and table portions, and
call the sysfs portion early.
Signed-off-by: Steven Finney <[email protected]>
Signed-off-by: Dave Jones <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/cpufreq/cpufreq_stats.c | 21 ++++++++++++++++++---
1 file changed, 18 insertions(+), 3 deletions(-)
--- a/drivers/cpufreq/cpufreq_stats.c
+++ b/drivers/cpufreq/cpufreq_stats.c
@@ -164,17 +164,27 @@ static int freq_table_get_index(struct c
return -1;
}
+/* should be called late in the CPU removal sequence so that the stats
+ * memory is still available in case someone tries to use it.
+ */
static void cpufreq_stats_free_table(unsigned int cpu)
{
struct cpufreq_stats *stat = per_cpu(cpufreq_stats_table, cpu);
- struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
- if (policy && policy->cpu == cpu)
- sysfs_remove_group(&policy->kobj, &stats_attr_group);
if (stat) {
kfree(stat->time_in_state);
kfree(stat);
}
per_cpu(cpufreq_stats_table, cpu) = NULL;
+}
+
+/* must be called early in the CPU removal sequence (before
+ * cpufreq_remove_dev) so that policy is still valid.
+ */
+static void cpufreq_stats_free_sysfs(unsigned int cpu)
+{
+ struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
+ if (policy && policy->cpu == cpu)
+ sysfs_remove_group(&policy->kobj, &stats_attr_group);
if (policy)
cpufreq_cpu_put(policy);
}
@@ -315,6 +325,9 @@ static int __cpuinit cpufreq_stat_cpu_ca
case CPU_ONLINE_FROZEN:
cpufreq_update_policy(cpu);
break;
+ case CPU_DOWN_PREPARE:
+ cpufreq_stats_free_sysfs(cpu);
+ break;
case CPU_DEAD:
case CPU_DEAD_FROZEN:
cpufreq_stats_free_table(cpu);
@@ -323,9 +336,11 @@ static int __cpuinit cpufreq_stat_cpu_ca
return NOTIFY_OK;
}
+/* priority=1 so this will get called before cpufreq_remove_dev */
static struct notifier_block cpufreq_stat_cpu_notifier __refdata =
{
.notifier_call = cpufreq_stat_cpu_callback,
+ .priority = 1,
};
static struct notifier_block notifier_policy_block = {
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Milton Miller <[email protected]>
commit 3d2cea732d68aa270c360f55d8669820ebce188a upstream.
Commit 1fc711f7ffb01089efc58042cfdbac8573d1b59a (powerpc/kexec: Fix race
in kexec shutdown) moved the write to signal the cpu had exited the kernel
from before the transition to real mode in kexec_smp_wait to kexec_wait.
Unfornately it missed that kexec_wait is used both by cpus leaving the
kernel and by secondary slave cpus that were not allocated a paca for
what ever reason -- they could be beyond nr_cpus or not described in
the current device tree for whatever reason (for example, kexec-load
was not refreshed after a cpu hotplug operation). Cpus coming through
that path they will write to paca[NR_CPUS] which is beyond the space
allocated for the paca data and overwrite memory not allocated to pacas
but very likely still real mode accessable).
Move the write back to kexec_smp_wait, which is used only by cpus that
found their paca, but after the transition to real mode.
Signed-off-by: Milton Miller <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/powerpc/kernel/misc_64.S | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -463,7 +463,8 @@ _GLOBAL(disable_kernel_fp)
* wait for the flag to change, indicating this kernel is going away but
* the slave code for the next one is at addresses 0 to 100.
*
- * This is used by all slaves.
+ * This is used by all slaves, even those that did not find a matching
+ * paca in the secondary startup code.
*
* Physical (hardware) cpu id should be in r3.
*/
@@ -472,10 +473,6 @@ _GLOBAL(kexec_wait)
1: mflr r5
addi r5,r5,kexec_flag-1b
- li r4,KEXEC_STATE_REAL_MODE
- stb r4,PACAKEXECSTATE(r13)
- SYNC
-
99: HMT_LOW
#ifdef CONFIG_KEXEC /* use no memory without kexec */
lwz r4,0(r5)
@@ -500,11 +497,17 @@ kexec_flag:
*
* get phys id from paca
* switch to real mode
+ * mark the paca as no longer used
* join other cpus in kexec_wait(phys_id)
*/
_GLOBAL(kexec_smp_wait)
lhz r3,PACAHWCPUID(r13)
bl real_mode
+
+ li r4,KEXEC_STATE_REAL_MODE
+ stb r4,PACAKEXECSTATE(r13)
+ SYNC
+
b .kexec_wait
/*
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Eric B Munson <[email protected]>
commit ad5d5292f16c6c1d7d3e257c4c7407594286b97e upstream.
Commit 0837e3242c73566fc1c0196b4ec61779c25ffc93 fixes a situation on POWER7
where events can roll back if a specualtive event doesn't actually complete.
This can raise a performance monitor exception. We need to catch this to ensure
that we reset the PMC. In all cases the PMC will be less than 256 cycles from
overflow.
This patch lifts Anton's fix for the problem in perf and applies it to oprofile
as well.
Signed-off-by: Eric B Munson <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/powerpc/oprofile/op_model_power4.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
--- a/arch/powerpc/oprofile/op_model_power4.c
+++ b/arch/powerpc/oprofile/op_model_power4.c
@@ -261,6 +261,28 @@ static int get_kernel(unsigned long pc,
return is_kernel;
}
+static bool pmc_overflow(unsigned long val)
+{
+ if ((int)val < 0)
+ return true;
+
+ /*
+ * Events on POWER7 can roll back if a speculative event doesn't
+ * eventually complete. Unfortunately in some rare cases they will
+ * raise a performance monitor exception. We need to catch this to
+ * ensure we reset the PMC. In all cases the PMC will be 256 or less
+ * cycles from overflow.
+ *
+ * We only do this if the first pass fails to find any overflowing
+ * PMCs because a user might set a period of less than 256 and we
+ * don't want to mistakenly reset them.
+ */
+ if (__is_processor(PV_POWER7) && ((0x80000000 - val) <= 256))
+ return true;
+
+ return false;
+}
+
static void power4_handle_interrupt(struct pt_regs *regs,
struct op_counter_config *ctr)
{
@@ -281,7 +303,7 @@ static void power4_handle_interrupt(stru
for (i = 0; i < cur_cpu_spec->num_pmcs; ++i) {
val = classic_ctr_read(i);
- if (val < 0) {
+ if (pmc_overflow(val)) {
if (oprofile_running && ctr[i].enabled) {
oprofile_add_ext_sample(pc, regs, i, is_kernel);
classic_ctr_write(i, reset_value[i]);
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
too
From: Tejun Heo <[email protected]>
commit 02e352287a40bd456eb78df705bf888bc3161d3f upstream.
__blkdev_get() doesn't rescan partitions if disk->fops->open() fails,
which leads to ghost partition devices lingering after medimum removal
is known to both the kernel and userland. The behavior also creates a
subtle inconsistency where O_NONBLOCK open, which doesn't fail even if
there's no medium, clears the ghots partitions, which is exploited to
work around the problem from userland.
Fix it by updating __blkdev_get() to issue partition rescan after
-ENOMEDIA too.
This was reported in the following bz.
https://bugzilla.kernel.org/show_bug.cgi?id=13029
Stable: 2.6.38
Signed-off-by: Tejun Heo <[email protected]>
Reported-by: David Zeuthen <[email protected]>
Reported-by: Martin Pitt <[email protected]>
Reported-by: Kay Sievers <[email protected]>
Tested-by: Kay Sievers <[email protected]>
Cc: Alan Cox <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/block_dev.c | 27 ++++++++++++++++++---------
1 file changed, 18 insertions(+), 9 deletions(-)
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1203,6 +1203,7 @@ static int __blkdev_get(struct block_dev
if (!bdev->bd_part)
goto out_clear;
+ ret = 0;
if (disk->fops->open) {
ret = disk->fops->open(bdev, mode);
if (ret == -ERESTARTSYS) {
@@ -1218,9 +1219,18 @@ static int __blkdev_get(struct block_dev
mutex_unlock(&bdev->bd_mutex);
goto restart;
}
- if (ret)
- goto out_clear;
}
+ /*
+ * If the device is invalidated, rescan partition
+ * if open succeeded or failed with -ENOMEDIUM.
+ * The latter is necessary to prevent ghost
+ * partitions on a removed medium.
+ */
+ if (bdev->bd_invalidated && (!ret || ret == -ENOMEDIUM))
+ rescan_partitions(disk, bdev);
+ if (ret)
+ goto out_clear;
+
if (!bdev->bd_openers) {
bd_set_size(bdev,(loff_t)get_capacity(disk)<<9);
bdi = blk_get_backing_dev_info(bdev);
@@ -1228,8 +1238,6 @@ static int __blkdev_get(struct block_dev
bdi = &default_backing_dev_info;
bdev->bd_inode->i_data.backing_dev_info = bdi;
}
- if (bdev->bd_invalidated)
- rescan_partitions(disk, bdev);
} else {
struct block_device *whole;
whole = bdget_disk(disk, 0);
@@ -1256,13 +1264,14 @@ static int __blkdev_get(struct block_dev
put_disk(disk);
disk = NULL;
if (bdev->bd_contains == bdev) {
- if (bdev->bd_disk->fops->open) {
+ ret = 0;
+ if (bdev->bd_disk->fops->open)
ret = bdev->bd_disk->fops->open(bdev, mode);
- if (ret)
- goto out_unlock_bdev;
- }
- if (bdev->bd_invalidated)
+ /* the same as first opener case, read comment there */
+ if (bdev->bd_invalidated && (!ret || ret == -ENOMEDIUM))
rescan_partitions(bdev->bd_disk, bdev);
+ if (ret)
+ goto out_unlock_bdev;
}
}
bdev->bd_openers++;
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: James Bottomley <[email protected]>
commit 0a58e077eb600d1efd7e54ad9926a75a39d7f8ae upstream.
blk_cleanup_queue() calls elevator_exit() and after this, we can't
touch the elevator without oopsing. __elv_next_request() must check
for this state because in the refcounted queue model, we can still
call it after blk_cleanup_queue() has been called.
This was reported as causing an oops attributable to scsi.
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
block/blk.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/block/blk.h
+++ b/block/blk.h
@@ -62,7 +62,8 @@ static inline struct request *__elv_next
return rq;
}
- if (!q->elevator->ops->elevator_dispatch_fn(q, 0))
+ if (test_bit(QUEUE_FLAG_DEAD, &q->queue_flags) ||
+ !q->elevator->ops->elevator_dispatch_fn(q, 0))
return NULL;
}
}
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Felix Radensky <[email protected]>
commit 431e1ecabddcd7cbba237182ddf431771f98bb4c upstream.
Currently mtdconcat is broken for NAND. An attemtpt to create
JFFS2 filesystem on concatenation of several NAND devices fails
with OOB write errors. This patch fixes that problem.
Signed-off-by: Felix Radensky <[email protected]>
Signed-off-by: Artem Bityutskiy <[email protected]>
Signed-off-by: David Woodhouse <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/mtd/mtdconcat.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/mtd/mtdconcat.c
+++ b/drivers/mtd/mtdconcat.c
@@ -306,7 +306,7 @@ concat_write_oob(struct mtd_info *mtd, l
if (!(mtd->flags & MTD_WRITEABLE))
return -EROFS;
- ops->retlen = 0;
+ ops->retlen = ops->oobretlen = 0;
for (i = 0; i < concat->num_subdev; i++) {
struct mtd_info *subdev = concat->subdev[i];
@@ -321,7 +321,7 @@ concat_write_oob(struct mtd_info *mtd, l
devops.len = subdev->size - to;
err = subdev->write_oob(subdev, to, &devops);
- ops->retlen += devops.retlen;
+ ops->retlen += devops.oobretlen;
if (err)
return err;
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
userspace address limit
From: Jiri Olsa <[email protected]>
commit 26afb7c661080ae3f1f13ddf7f0c58c4f931c22b upstream.
As reported in BZ #30352:
https://bugzilla.kernel.org/show_bug.cgi?id=30352
there's a kernel bug related to reading the last allowed page on x86_64.
The _copy_to_user() and _copy_from_user() functions use the following
check for address limit:
if (buf + size >= limit)
fail();
while it should be more permissive:
if (buf + size > limit)
fail();
That's because the size represents the number of bytes being
read/write from/to buf address AND including the buf address.
So the copy function will actually never touch the limit
address even if "buf + size == limit".
Following program fails to use the last page as buffer
due to the wrong limit check:
#include <sys/mman.h>
#include <sys/socket.h>
#include <assert.h>
#define PAGE_SIZE (4096)
#define LAST_PAGE ((void*)(0x7fffffffe000))
int main()
{
int fds[2], err;
void * ptr = mmap(LAST_PAGE, PAGE_SIZE, PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE | MAP_FIXED, -1, 0);
assert(ptr == LAST_PAGE);
err = socketpair(AF_LOCAL, SOCK_STREAM, 0, fds);
assert(err == 0);
err = send(fds[0], ptr, PAGE_SIZE, 0);
perror("send");
assert(err == PAGE_SIZE);
err = recv(fds[1], ptr, PAGE_SIZE, MSG_WAITALL);
perror("recv");
assert(err == PAGE_SIZE);
return 0;
}
The other place checking the addr limit is the access_ok() function,
which is working properly. There's just a misleading comment
for the __range_not_ok() macro - which this patch fixes as well.
The last page of the user-space address range is a guard page and
Brian Gerst observed that the guard page itself due to an erratum on K8 cpus
(#121 Sequential Execution Across Non-Canonical Boundary Causes Processor
Hang).
However, the test code is using the last valid page before the guard page.
The bug is that the last byte before the guard page can't be read
because of the off-by-one error. The guard page is left in place.
This bug would normally not show up because the last page is
part of the process stack and never accessed via syscalls.
Signed-off-by: Jiri Olsa <[email protected]>
Acked-by: Brian Gerst <[email protected]>
Acked-by: Linus Torvalds <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/include/asm/uaccess.h | 2 +-
arch/x86/lib/copy_user_64.S | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -42,7 +42,7 @@
* Returns 0 if the range is valid, nonzero otherwise.
*
* This is equivalent to the following test:
- * (u33)addr + (u33)size >= (u33)current->addr_limit.seg (u65 for x86_64)
+ * (u33)addr + (u33)size > (u33)current->addr_limit.seg (u65 for x86_64)
*
* This needs 33-bit (65-bit for x86_64) arithmetic. We have a carry...
*/
--- a/arch/x86/lib/copy_user_64.S
+++ b/arch/x86/lib/copy_user_64.S
@@ -72,7 +72,7 @@ ENTRY(copy_to_user)
addq %rdx,%rcx
jc bad_to_user
cmpq TI_addr_limit(%rax),%rcx
- jae bad_to_user
+ ja bad_to_user
ALTERNATIVE_JUMP X86_FEATURE_REP_GOOD,copy_user_generic_unrolled,copy_user_generic_string
CFI_ENDPROC
ENDPROC(copy_to_user)
@@ -85,7 +85,7 @@ ENTRY(copy_from_user)
addq %rdx,%rcx
jc bad_from_user
cmpq TI_addr_limit(%rax),%rcx
- jae bad_from_user
+ ja bad_from_user
ALTERNATIVE_JUMP X86_FEATURE_REP_GOOD,copy_user_generic_unrolled,copy_user_generic_string
CFI_ENDPROC
ENDPROC(copy_from_user)
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Jan Kara <[email protected]>
commit 86c4f6d85595cd7da635dc6985d27bfa43b1ae10 upstream.
When make_indexed_dir() fails (e.g. because of ENOSPC) after it has allocated
block for index tree root, we did not properly mark all changed buffers dirty.
This lead to only some of these buffers being written out and thus effectively
corrupting the directory.
Fix the issue by marking all changed data dirty even in the error failure case.
Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ext3/namei.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
--- a/fs/ext3/namei.c
+++ b/fs/ext3/namei.c
@@ -1425,10 +1425,19 @@ static int make_indexed_dir(handle_t *ha
frame->at = entries;
frame->bh = bh;
bh = bh2;
+ /*
+ * Mark buffers dirty here so that if do_split() fails we write a
+ * consistent set of buffers to disk.
+ */
+ ext3_journal_dirty_metadata(handle, frame->bh);
+ ext3_journal_dirty_metadata(handle, bh);
de = do_split(handle,dir, &bh, frame, &hinfo, &retval);
- dx_release (frames);
- if (!(de))
+ if (!de) {
+ ext3_mark_inode_dirty(handle, dir);
+ dx_release(frames);
return retval;
+ }
+ dx_release(frames);
return add_dirent_to_buf(handle, dentry, inode, de, bh);
}
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Jan Kara <[email protected]>
commit 2842bb20eed2e25cde5114298edc62c8883a1d9a upstream.
In do_get_write_access() we wait on BH_Unshadow bit for buffer to get
from shadow state. The waking code in journal_commit_transaction() has
a bug because it does not issue a memory barrier after the buffer is moved
from the shadow state and before wake_up_bit() is called. Thus a waitqueue
check can happen before the buffer is actually moved from the shadow state
and waiting process may never be woken. Fix the problem by issuing proper
barrier.
Reported-by: Tao Ma <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/jbd/commit.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/fs/jbd/commit.c
+++ b/fs/jbd/commit.c
@@ -746,8 +746,13 @@ wait_for_iobuf:
required. */
JBUFFER_TRACE(jh, "file as BJ_Forget");
journal_file_buffer(jh, commit_transaction, BJ_Forget);
- /* Wake up any transactions which were waiting for this
- IO to complete */
+ /*
+ * Wake up any transactions which were waiting for this
+ * IO to complete. The barrier must be here so that changes
+ * by journal_file_buffer() take effect before wake_up_bit()
+ * does the waitqueue check.
+ */
+ smp_mb();
wake_up_bit(&bh->b_state, BH_Unshadow);
JBUFFER_TRACE(jh, "brelse shadowed buffer");
__brelse(bh);
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Ted Ts'o <[email protected]>
commit d9b01934d56a96d9f4ae2d6204d4ea78a36f5f36 upstream.
If an application program does not make any changes to the indirect
blocks or extent tree, i_datasync_tid will not get updated. If there
are enough commits (i.e., 2**31) such that tid_geq()'s calculations
wrap, and there isn't a currently active transaction at the time of
the fdatasync() call, this can end up triggering a BUG_ON in
fs/jbd/commit.c:
J_ASSERT(journal->j_running_transaction != NULL);
It's pretty rare that this can happen, since it requires the use of
fdatasync() plus *very* frequent and excessive use of fsync(). But
with the right workload, it can.
We fix this by replacing the use of tid_geq() with an equality test,
since there's only one valid transaction id that is valid for us to
start: namely, the currently running transaction (if it exists).
Reported-by: [email protected]
Signed-off-by: "Theodore Ts'o" <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/jbd/journal.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
--- a/fs/jbd/journal.c
+++ b/fs/jbd/journal.c
@@ -435,9 +435,12 @@ int __log_space_left(journal_t *journal)
int __log_start_commit(journal_t *journal, tid_t target)
{
/*
- * Are we already doing a recent enough commit?
+ * The only transaction we can possibly wait upon is the
+ * currently running transaction (if it exists). Otherwise,
+ * the target tid must be an old one.
*/
- if (!tid_geq(journal->j_commit_request, target)) {
+ if (journal->j_running_transaction &&
+ journal->j_running_transaction->t_tid == target) {
/*
* We want a new commit: OK, mark the request and wakup the
* commit thread. We do _not_ do the commit ourselves.
@@ -449,7 +452,14 @@ int __log_start_commit(journal_t *journa
journal->j_commit_sequence);
wake_up(&journal->j_wait_commit);
return 1;
- }
+ } else if (!tid_geq(journal->j_commit_request, target))
+ /* This should never happen, but if it does, preserve
+ the evidence before kjournald goes into a loop and
+ increments j_commit_sequence beyond all recognition. */
+ WARN_ONCE(1, "jbd: bad log_start_commit: %u %u %u %u\n",
+ journal->j_commit_request, journal->j_commit_sequence,
+ target, journal->j_running_transaction ?
+ journal->j_running_transaction->t_tid : 0);
return 0;
}
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Yang Ruirui <[email protected]>
commit 26626f1172fb4f3f323239a6a5cf4e082643fa46 upstream.
Add missing page_cache_release in the error path of ext4_mb_load_buddy
Signed-off-by: Yang Ruirui <[email protected]>
Signed-off-by: "Theodore Ts'o" <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ext4/mballoc.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -1173,6 +1173,8 @@ repeat_load_buddy:
return 0;
err:
+ if (page)
+ page_cache_release(page);
if (e4b->bd_bitmap_page)
page_cache_release(e4b->bd_bitmap_page);
if (e4b->bd_buddy_page)
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Samuel Thibault <[email protected]>
commit fad4dab5e44e10acf6b0235e469cb8e773b58e31 upstream.
Commit 1292500b replaced
"=m" (*field) : "1" (*field)
with
"=m" (*field) :
with comment "The following patch fixes it by using the '+' operator on
the (*field) operand, marking it as read-write to gcc."
'+' was actually forgotten. This really puts it.
Signed-off-by: Samuel Thibault <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/scsi/ultrastor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/ultrastor.c
+++ b/drivers/scsi/ultrastor.c
@@ -306,7 +306,7 @@ static inline int find_and_clear_bit_16(
"0: bsfw %1,%w0\n\t"
"btr %0,%1\n\t"
"jnc 0b"
- : "=&r" (rv), "=m" (*field) :);
+ : "=&r" (rv), "+m" (*field) :);
return rv;
}
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
family 0x12
From: Boris Ostrovsky <[email protected]>
commit e9cdd343a5e42c43bcda01e609fa23089e026470 upstream.
Commit b87cf80af3ba4b4c008b4face3c68d604e1715c6 added support for
ARAT (Always Running APIC timer) on AMD processors that are not
affected by erratum 400. This erratum is present on certain processor
families and prevents APIC timer from waking up the CPU when it
is in a deep C state, including C1E state.
Determining whether a processor is affected by this erratum may
have some corner cases and handling these cases is somewhat
complicated. In the interest of simplicity we won't claim ARAT
support on processor families below 0x12 and will go back to
broadcasting timer when going idle.
Signed-off-by: Boris Ostrovsky <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Tested-by: Boris Petkov <[email protected]>
Cc: Hans Rosenfeld <[email protected]>
Cc: Andreas Herrmann <[email protected]>
Cc: Chuck Ebbert <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/cpu/amd.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -567,8 +567,11 @@ static void __cpuinit init_amd(struct cp
}
#endif
- /* As a rule processors have APIC timer running in deep C states */
- if (c->x86 > 0xf && !cpu_has_amd_erratum(amd_erratum_400))
+ /*
+ * Family 0x12 and above processors have APIC timer
+ * running in deep C states.
+ */
+ if (c->x86 > 0x11)
set_cpu_cap(c, X86_FEATURE_ARAT);
/*
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: "Roedel, Joerg" <[email protected]>
commit d47cc0db8fd6011de2248df505fc34990b7451bf upstream.
The workaround for Bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=33012
introduced a read and a write to the MC4 mask msr.
Unfortunatly this MSR is not emulated by the KVM hypervisor
so that the kernel will get a #GP and crashes when applying
this workaround when running inside KVM.
This issue was reported as:
https://bugzilla.kernel.org/show_bug.cgi?id=35132
and is fixed with this patch. The change just let the kernel
ignore any #GP it gets while accessing this MSR by using the
_safe msr access methods.
Reported-by: Török Edwin <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>
Cc: Maciej Rutecki <[email protected]>
Cc: Avi Kivity <[email protected]>
Cc: Andrew Morton <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/cpu/amd.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -587,10 +587,13 @@ static void __cpuinit init_amd(struct cp
* Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=33012
*/
u64 mask;
+ int err;
- rdmsrl(MSR_AMD64_MCx_MASK(4), mask);
- mask |= (1 << 10);
- wrmsrl(MSR_AMD64_MCx_MASK(4), mask);
+ err = rdmsrl_safe(MSR_AMD64_MCx_MASK(4), &mask);
+ if (err == 0) {
+ mask |= (1 << 10);
+ checking_wrmsrl(MSR_AMD64_MCx_MASK(4), mask);
+ }
}
}
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Frederic Weisbecker <[email protected]>
commit ba9f207c9f82115aba4ce04b22e0081af0ae300f upstream.
HARDIRQ_ENTER() maps to irq_enter() which calls rcu_irq_enter().
But HARDIRQ_EXIT() maps to __irq_exit() which doesn't call
rcu_irq_exit().
So for every locking selftest that simulates hardirq disabled,
we create an imbalance in the rcu extended quiescent state
internal state.
As a result, after the first missing rcu_irq_exit(), subsequent
irqs won't exit dyntick-idle mode after leaving the interrupt
handler. This means that RCU won't see the affected CPU as being
in an extended quiescent state, resulting in long grace-period
delays (as in grace periods extending for hours).
To fix this, just use __irq_enter() to simulate the hardirq
context. This is sufficient for the locking selftests as we
don't need to exit any extended quiescent state or perform
any check that irqs normally do when they wake up from idle.
As a side effect, this patch makes it possible to restore
"rcu: Decrease memory-barrier usage based on semi-formal proof",
which eventually helped finding this bug.
Reported-and-tested-by: Yinghai Lu <[email protected]>
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Paul E. McKenney <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Signed-off-by: Paul E. McKenney <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
lib/locking-selftest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/lib/locking-selftest.c
+++ b/lib/locking-selftest.c
@@ -144,7 +144,7 @@ static void init_shared_classes(void)
#define HARDIRQ_ENTER() \
local_irq_disable(); \
- irq_enter(); \
+ __irq_enter(); \
WARN_ON(!in_irq());
#define HARDIRQ_EXIT() \
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: David Chang <[email protected]>
commit cacd18a8476ce145ca5dcd46dc5b75585fd1289c upstream.
Fix number_of_packets wrong endian conversion in function
correct_endian_ret_submit()
Signed-off-by: David Chang <[email protected]>
Acked-by: Arjan Mels <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/usbip/usbip_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/usbip/usbip_common.c
+++ b/drivers/staging/usbip/usbip_common.c
@@ -770,7 +770,7 @@ static void correct_endian_ret_submit(st
be32_to_cpus(&pdu->status);
be32_to_cpus(&pdu->actual_length);
be32_to_cpus(&pdu->start_frame);
- cpu_to_be32s(&pdu->number_of_packets);
+ be32_to_cpus(&pdu->number_of_packets);
be32_to_cpus(&pdu->error_count);
}
}
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Timo Warns <[email protected]>
commit cae13fe4cc3f24820ffb990c09110626837e85d4 upstream.
As Ben Hutchings discovered [1], the patch for CVE-2011-1017 (buffer
overflow in ldm_frag_add) is not sufficient. The original patch in
commit c340b1d64000 ("fs/partitions/ldm.c: fix oops caused by corrupted
partition table") does not consider that, for subsequent fragments,
previously allocated memory is used.
[1] http://lkml.org/lkml/2011/5/6/407
Reported-by: Ben Hutchings <[email protected]>
Signed-off-by: Timo Warns <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/partitions/ldm.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/fs/partitions/ldm.c
+++ b/fs/partitions/ldm.c
@@ -1335,6 +1335,11 @@ static bool ldm_frag_add (const u8 *data
list_add_tail (&f->list, frags);
found:
+ if (rec >= f->num) {
+ ldm_error("REC value (%d) exceeds NUM value (%d)", rec, f->num);
+ return false;
+ }
+
if (f->map & (1 << rec)) {
ldm_error ("Duplicate VBLK, part %d.", rec);
f->map &= 0x7F; /* Mark the group as broken */
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Milton Miller <[email protected]>
commit 5db1256a5131d3b133946fa02ac9770a784e6eb2 upstream.
Move the smp_rmb after cpu_relax loop in read_seqlock and add
ACCESS_ONCE to make sure the test and return are consistent.
A multi-threaded core in the lab didn't like the update
from 2.6.35 to 2.6.36, to the point it would hang during
boot when multiple threads were active. Bisection showed
af5ab277ded04bd9bc6b048c5a2f0e7d70ef0867 (clockevents:
Remove the per cpu tick skew) as the culprit and it is
supported with stack traces showing xtime_lock waits including
tick_do_update_jiffies64 and/or update_vsyscall.
Experimentation showed the combination of cpu_relax and smp_rmb
was significantly slowing the progress of other threads sharing
the core, and this patch is effective in avoiding the hang.
A theory is the rmb is affecting the whole core while the
cpu_relax is causing a resource rebalance flush, together they
cause an interfernce cadance that is unbroken when the seqlock
reader has interrupts disabled.
At first I was confused why the refactor in
3c22cd5709e8143444a6d08682a87f4c57902df3 (kernel: optimise
seqlock) didn't affect this patch application, but after some
study that affected seqcount not seqlock. The new seqcount was
not factored back into the seqlock. I defer that the future.
While the removal of the timer interrupt offset created
contention for the xtime lock while a cpu does the
additonal work to update the system clock, the seqlock
implementation with the tight rmb spin loop goes back much
further, and is just waiting for the right trigger.
Signed-off-by: Milton Miller <[email protected]>
Cc: <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Nick Piggin <[email protected]>
Cc: Benjamin Herrenschmidt <[email protected]>
Cc: Anton Blanchard <[email protected]>
Cc: Paul McKenney <[email protected]>
Acked-by: Eric Dumazet <[email protected]>
Link: http://lkml.kernel.org/r/%3Cseqlock-rmb%40mdm.bga.com%3E
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/seqlock.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -88,12 +88,12 @@ static __always_inline unsigned read_seq
unsigned ret;
repeat:
- ret = sl->sequence;
- smp_rmb();
+ ret = ACCESS_ONCE(sl->sequence);
if (unlikely(ret & 1)) {
cpu_relax();
goto repeat;
}
+ smp_rmb();
return ret;
}
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: David Henningsson <[email protected]>
commit e033ebfb399227e01686260ac271029011bc6b47 upstream.
There are no signs of a dmic at node 0x0b, so the user is left with
an additional internal mic which does not exist. This commit removes
that non-existing mic.
BugLink: http://bugs.launchpad.net/bugs/731706
Reported-by: James Page <[email protected]>
Signed-off-by: David Henningsson <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/pci/hda/patch_sigmatel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/pci/hda/patch_sigmatel.c
+++ b/sound/pci/hda/patch_sigmatel.c
@@ -1600,7 +1600,7 @@ static struct snd_pci_quirk stac92hd73xx
SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x02fe,
"Dell Studio XPS 1645", STAC_DELL_M6_BOTH),
SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x0413,
- "Dell Studio 1558", STAC_DELL_M6_BOTH),
+ "Dell Studio 1558", STAC_DELL_M6_DMIC),
{} /* terminator */
};
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
wm_hubs
From: Mark Brown <[email protected]>
commit d0b48af6c2b887354d0893e598d92911ce52620e upstream.
Also fix a left/right typo while we're at it.
Signed-off-by: Mark Brown <[email protected]>
Acked-by: Liam Girdwood <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/soc/codecs/wm_hubs.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
--- a/sound/soc/codecs/wm_hubs.c
+++ b/sound/soc/codecs/wm_hubs.c
@@ -639,17 +639,17 @@ static const struct snd_soc_dapm_route a
static const struct snd_soc_dapm_route lineout1_diff_routes[] = {
{ "LINEOUT1 Mixer", "IN1L Switch", "IN1L PGA" },
{ "LINEOUT1 Mixer", "IN1R Switch", "IN1R PGA" },
- { "LINEOUT1 Mixer", "Output Switch", "Left Output Mixer" },
+ { "LINEOUT1 Mixer", "Output Switch", "Left Output PGA" },
{ "LINEOUT1N Driver", NULL, "LINEOUT1 Mixer" },
{ "LINEOUT1P Driver", NULL, "LINEOUT1 Mixer" },
};
static const struct snd_soc_dapm_route lineout1_se_routes[] = {
- { "LINEOUT1N Mixer", "Left Output Switch", "Left Output Mixer" },
- { "LINEOUT1N Mixer", "Right Output Switch", "Left Output Mixer" },
+ { "LINEOUT1N Mixer", "Left Output Switch", "Left Output PGA" },
+ { "LINEOUT1N Mixer", "Right Output Switch", "Right Output PGA" },
- { "LINEOUT1P Mixer", "Left Output Switch", "Left Output Mixer" },
+ { "LINEOUT1P Mixer", "Left Output Switch", "Left Output PGA" },
{ "LINEOUT1N Driver", NULL, "LINEOUT1N Mixer" },
{ "LINEOUT1P Driver", NULL, "LINEOUT1P Mixer" },
@@ -658,17 +658,17 @@ static const struct snd_soc_dapm_route l
static const struct snd_soc_dapm_route lineout2_diff_routes[] = {
{ "LINEOUT2 Mixer", "IN2L Switch", "IN2L PGA" },
{ "LINEOUT2 Mixer", "IN2R Switch", "IN2R PGA" },
- { "LINEOUT2 Mixer", "Output Switch", "Right Output Mixer" },
+ { "LINEOUT2 Mixer", "Output Switch", "Right Output PGA" },
{ "LINEOUT2N Driver", NULL, "LINEOUT2 Mixer" },
{ "LINEOUT2P Driver", NULL, "LINEOUT2 Mixer" },
};
static const struct snd_soc_dapm_route lineout2_se_routes[] = {
- { "LINEOUT2N Mixer", "Left Output Switch", "Left Output Mixer" },
- { "LINEOUT2N Mixer", "Right Output Switch", "Left Output Mixer" },
+ { "LINEOUT2N Mixer", "Left Output Switch", "Left Output PGA" },
+ { "LINEOUT2N Mixer", "Right Output Switch", "Right Output PGA" },
- { "LINEOUT2P Mixer", "Right Output Switch", "Right Output Mixer" },
+ { "LINEOUT2P Mixer", "Right Output Switch", "Right Output PGA" },
{ "LINEOUT2N Driver", NULL, "LINEOUT2N Mixer" },
{ "LINEOUT2P Driver", NULL, "LINEOUT2P Mixer" },
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
devices
From: Mark Brown <[email protected]>
commit fb5af53d421d80725172427e9076f6e889603df6 upstream.
Signed-off-by: Mark Brown <[email protected]>
Acked-by: Liam Girdwood <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/soc/codecs/wm_hubs.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/sound/soc/codecs/wm_hubs.c
+++ b/sound/soc/codecs/wm_hubs.c
@@ -686,17 +686,21 @@ int wm_hubs_add_analogue_controls(struct
snd_soc_update_bits(codec, WM8993_RIGHT_LINE_INPUT_3_4_VOLUME,
WM8993_IN2_VU, WM8993_IN2_VU);
+ snd_soc_update_bits(codec, WM8993_SPEAKER_VOLUME_LEFT,
+ WM8993_SPKOUT_VU, WM8993_SPKOUT_VU);
snd_soc_update_bits(codec, WM8993_SPEAKER_VOLUME_RIGHT,
WM8993_SPKOUT_VU, WM8993_SPKOUT_VU);
snd_soc_update_bits(codec, WM8993_LEFT_OUTPUT_VOLUME,
- WM8993_HPOUT1L_ZC, WM8993_HPOUT1L_ZC);
+ WM8993_HPOUT1_VU | WM8993_HPOUT1L_ZC,
+ WM8993_HPOUT1_VU | WM8993_HPOUT1L_ZC);
snd_soc_update_bits(codec, WM8993_RIGHT_OUTPUT_VOLUME,
WM8993_HPOUT1_VU | WM8993_HPOUT1R_ZC,
WM8993_HPOUT1_VU | WM8993_HPOUT1R_ZC);
snd_soc_update_bits(codec, WM8993_LEFT_OPGA_VOLUME,
- WM8993_MIXOUTL_ZC, WM8993_MIXOUTL_ZC);
+ WM8993_MIXOUTL_ZC | WM8993_MIXOUT_VU,
+ WM8993_MIXOUTL_ZC | WM8993_MIXOUT_VU);
snd_soc_update_bits(codec, WM8993_RIGHT_OPGA_VOLUME,
WM8993_MIXOUTR_ZC | WM8993_MIXOUT_VU,
WM8993_MIXOUTR_ZC | WM8993_MIXOUT_VU);
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
__alloc_pages_slowpath()
From: Andrew Barry <[email protected]>
commit cfa54a0fcfc1017c6f122b6f21aaba36daa07f71 upstream.
I believe I found a problem in __alloc_pages_slowpath, which allows a
process to get stuck endlessly looping, even when lots of memory is
available.
Running an I/O and memory intensive stress-test I see a 0-order page
allocation with __GFP_IO and __GFP_WAIT, running on a system with very
little free memory. Right about the same time that the stress-test gets
killed by the OOM-killer, the utility trying to allocate memory gets stuck
in __alloc_pages_slowpath even though most of the systems memory was freed
by the oom-kill of the stress-test.
The utility ends up looping from the rebalance label down through the
wait_iff_congested continiously. Because order=0,
__alloc_pages_direct_compact skips the call to get_page_from_freelist.
Because all of the reclaimable memory on the system has already been
reclaimed, __alloc_pages_direct_reclaim skips the call to
get_page_from_freelist. Since there is no __GFP_FS flag, the block with
__alloc_pages_may_oom is skipped. The loop hits the wait_iff_congested,
then jumps back to rebalance without ever trying to
get_page_from_freelist. This loop repeats infinitely.
The test case is pretty pathological. Running a mix of I/O stress-tests
that do a lot of fork() and consume all of the system memory, I can pretty
reliably hit this on 600 nodes, in about 12 hours. 32GB/node.
Signed-off-by: Andrew Barry <[email protected]>
Signed-off-by: Minchan Kim <[email protected]>
Reviewed-by: Rik van Riel<[email protected]>
Acked-by: Mel Gorman <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/page_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1841,6 +1841,7 @@ restart:
*/
alloc_flags = gfp_to_alloc_flags(gfp_mask);
+rebalance:
/* This is the last chance, in general, before the goto nopage. */
page = get_page_from_freelist(gfp_mask, nodemask, order, zonelist,
high_zoneidx, alloc_flags & ~ALLOC_NO_WATERMARKS,
@@ -1848,7 +1849,6 @@ restart:
if (page)
goto got_pg;
-rebalance:
/* Allocate without watermarks if the context allows */
if (alloc_flags & ALLOC_NO_WATERMARKS) {
page = __alloc_pages_high_priority(gfp_mask, order,
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
non-prefetchable windows
From: Linus Torvalds <[email protected]>
commit 8c8def26bfaa704db67d515da3eb92cf26067548 upstream.
I'm not entirely sure it needs to go into 32, but it's probably the right
thing to do. Another way of explaining the patch is:
- we currently pick the _first_ exactly matching bus resource entry, but
the _last_ inexactly matching one. Normally first/last shouldn't
matter, but bus resource entries aren't actually all created equal: in
a transparent bus, the last resources will be the parent resources,
which we should generally try to avoid unless we have no choice. So
"first matching" is the thing we should always aim for.
- the patch is a bit bigger than it needs to be, because I simplified the
logic at the same time. It used to be a fairly incomprehensible
if ((res->flags & IORESOURCE_PREFETCH) && !(r->flags & IORESOURCE_PREFETCH))
best = r; /* Approximating prefetchable by non-prefetchable */
and technically, all the patch did was to make that complex choice be
even more complex (it basically added a "&& !best" to say that if we
already gound a non-prefetchable window for the prefetchable resource,
then we won't override an earlier one with that later one: remember
"first matching").
- So instead of that complex one with three separate conditionals in one,
I split it up a bit, and am taking advantage of the fact that we
already handled the exact case, so if 'res->flags' has the PREFETCH
bit, then we already know that 'r->flags' will _not_ have it. So the
simplified code drops the redundant test, and does the new '!best' test
separately. It also uses 'continue' as a way to ignore the bus
resource we know doesn't work (ie a prefetchable bus resource is _not_
acceptable for anything but an exact match), so it turns into:
/* We can't insert a non-prefetch resource inside a prefetchable parent .. */
if (r->flags & IORESOURCE_PREFETCH)
continue;
/* .. but we can put a prefetchable resource inside a non-prefetchable one */
if (!best)
best = r;
instead. With the comments, it's now six lines instead of two, but it's
conceptually simpler, and I _could_ have written it as two lines:
if ((res->flags & IORESOURCE_PREFETCH) && !best)
best = r; /* Approximating prefetchable by non-prefetchable */
but I thought that was too damn subtle.
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Jesse Barnes <[email protected]>
Cc: Seth Forshee <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/pci/pci.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -373,8 +373,12 @@ pci_find_parent_resource(const struct pc
continue; /* Wrong type */
if (!((res->flags ^ r->flags) & IORESOURCE_PREFETCH))
return r; /* Exact match */
- if ((res->flags & IORESOURCE_PREFETCH) && !(r->flags & IORESOURCE_PREFETCH))
- best = r; /* Approximating prefetchable by non-prefetchable */
+ /* We can't insert a non-prefetch resource inside a prefetchable parent .. */
+ if (r->flags & IORESOURCE_PREFETCH)
+ continue;
+ /* .. but we can put a prefetchable resource inside a non-prefetchable one */
+ if (!best)
+ best = r;
}
return best;
}
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Namhyung Kim <[email protected]>
commit 78f4bb367fd147a0e7e3998ba6e47109999d8814 upstream.
The 'max_part' parameter controls the number of maximum partition
a loop block device can have. However if a user specifies very
large value it would exceed the limitation of device minor number
and can cause a kernel panic (or, at least, produce invalid
device nodes in some cases).
On my desktop system, following command kills the kernel. On qemu,
it triggers similar oops but the kernel was alive:
$ sudo modprobe loop max_part0000
------------[ cut here ]------------
kernel BUG at /media/Linux_Data/project/linux/fs/sysfs/group.c:65!
invalid opcode: 0000 [#1] SMP
last sysfs file:
CPU 0
Modules linked in: loop(+)
Pid: 43, comm: insmod Tainted: G W 2.6.39-qemu+ #155 Bochs Bochs
RIP: 0010:[<ffffffff8113ce61>] [<ffffffff8113ce61>] internal_create_group=
+0x2a/0x170
RSP: 0018:ffff880007b3fde8 EFLAGS: 00000246
RAX: 00000000ffffffef RBX: ffff880007b3d878 RCX: 00000000000007b4
RDX: ffffffff8152da50 RSI: 0000000000000000 RDI: ffff880007b3d878
RBP: ffff880007b3fe38 R08: ffff880007b3fde8 R09: 0000000000000000
R10: ffff88000783b4a8 R11: ffff880007b3d878 R12: ffffffff8152da50
R13: ffff880007b3d868 R14: 0000000000000000 R15: ffff880007b3d800
FS: 0000000002137880(0063) GS:ffff880007c00000(0000) knlGS:00000000000000=
00
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000422680 CR3: 0000000007b50000 CR4: 00000000000006b0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000
Process insmod (pid: 43, threadinfo ffff880007b3e000, task ffff880007afb9c=
0)
Stack:
ffff880007b3fe58 ffffffff811e66dd ffff880007b3fe58 ffffffff811e570b
0000000000000010 ffff880007b3d800 ffff880007a7b390 ffff880007b3d868
0000000000400920 ffff880007b3d800 ffff880007b3fe48 ffffffff8113cfc8
Call Trace:
[<ffffffff811e66dd>] ? device_add+0x4bc/0x5af
[<ffffffff811e570b>] ? dev_set_name+0x3c/0x3e
[<ffffffff8113cfc8>] sysfs_create_group+0xe/0x12
[<ffffffff810b420e>] blk_trace_init_sysfs+0x14/0x16
[<ffffffff8116a090>] blk_register_queue+0x47/0xf7
[<ffffffff8116f527>] add_disk+0xdf/0x290
[<ffffffffa00060eb>] loop_init+0xeb/0x1b8 [loop]
[<ffffffffa0006000>] ? 0xffffffffa0005fff
[<ffffffff8100020a>] do_one_initcall+0x7a/0x12e
[<ffffffff81096804>] sys_init_module+0x9c/0x1e0
[<ffffffff813329bb>] system_call_fastpath+0x16/0x1b
Code: c3 55 48 89 e5 41 57 41 56 41 89 f6 41 55 41 54 49 89 d4 53 48 89 fb=
48 83 ec 28 48 85 ff 74 0b 85 f6 75 0b 48 83 7f 30 00 75 14 <0f> 0b eb fe =
48 83 7f 30 00 b9 ea ff ff ff 0f 84 18 01 00 00 49
RIP [<ffffffff8113ce61>] internal_create_group+0x2a/0x170
RSP <ffff880007b3fde8>
---[ end trace a123eb592043acad ]---
Signed-off-by: Namhyung Kim <[email protected]>
Cc: Laurent Vivier <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/block/loop.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1605,6 +1605,9 @@ static int __init loop_init(void)
if (max_part > 0)
part_shift = fls(max_part);
+ if ((1UL << part_shift) > DISK_MAX_PARTS)
+ return -EINVAL;
+
if (max_loop > 1UL << (MINORBITS - part_shift))
return -EINVAL;
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Namhyung Kim <[email protected]>
commit a1c15c59feee36267c43142a41152fbf7402afb6 upstream.
When finding or allocating a loop device, loop_probe() did not take
partition numbers into account so that it can result to a different
device. Consider following example:
$ sudo modprobe loop max_part=15
$ ls -l /dev/loop*
brw-rw---- 1 root disk 7, 0 2011-05-24 22:16 /dev/loop0
brw-rw---- 1 root disk 7, 16 2011-05-24 22:16 /dev/loop1
brw-rw---- 1 root disk 7, 32 2011-05-24 22:16 /dev/loop2
brw-rw---- 1 root disk 7, 48 2011-05-24 22:16 /dev/loop3
brw-rw---- 1 root disk 7, 64 2011-05-24 22:16 /dev/loop4
brw-rw---- 1 root disk 7, 80 2011-05-24 22:16 /dev/loop5
brw-rw---- 1 root disk 7, 96 2011-05-24 22:16 /dev/loop6
brw-rw---- 1 root disk 7, 112 2011-05-24 22:16 /dev/loop7
$ sudo mknod /dev/loop8 b 7 128
$ sudo losetup /dev/loop8 ~/temp/disk-with-3-parts.img
$ sudo losetup -a
/dev/loop128: [0805]:278201 (/home/namhyung/temp/disk-with-3-parts.img)
$ ls -l /dev/loop*
brw-rw---- 1 root disk 7, 0 2011-05-24 22:16 /dev/loop0
brw-rw---- 1 root disk 7, 16 2011-05-24 22:16 /dev/loop1
brw-rw---- 1 root disk 7, 2048 2011-05-24 22:18 /dev/loop128
brw-rw---- 1 root disk 7, 2049 2011-05-24 22:18 /dev/loop128p1
brw-rw---- 1 root disk 7, 2050 2011-05-24 22:18 /dev/loop128p2
brw-rw---- 1 root disk 7, 2051 2011-05-24 22:18 /dev/loop128p3
brw-rw---- 1 root disk 7, 32 2011-05-24 22:16 /dev/loop2
brw-rw---- 1 root disk 7, 48 2011-05-24 22:16 /dev/loop3
brw-rw---- 1 root disk 7, 64 2011-05-24 22:16 /dev/loop4
brw-rw---- 1 root disk 7, 80 2011-05-24 22:16 /dev/loop5
brw-rw---- 1 root disk 7, 96 2011-05-24 22:16 /dev/loop6
brw-rw---- 1 root disk 7, 112 2011-05-24 22:16 /dev/loop7
brw-r--r-- 1 root root 7, 128 2011-05-24 22:17 /dev/loop8
After this patch, /dev/loop8 - instead of /dev/loop128 - was
accessed correctly.
In addition, 'range' passed to blk_register_region() should
include all range of dev_t that LOOP_MAJOR can address. It does
not need to be limited by partition numbers unless 'max_loop'
param was specified.
Signed-off-by: Namhyung Kim <[email protected]>
Cc: Laurent Vivier <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/block/loop.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1572,7 +1572,7 @@ static struct kobject *loop_probe(dev_t
struct kobject *kobj;
mutex_lock(&loop_devices_mutex);
- lo = loop_init_one(dev & MINORMASK);
+ lo = loop_init_one(MINOR(dev) >> part_shift);
kobj = lo ? get_disk(lo->lo_disk) : ERR_PTR(-ENOMEM);
mutex_unlock(&loop_devices_mutex);
@@ -1613,10 +1613,10 @@ static int __init loop_init(void)
if (max_loop) {
nr = max_loop;
- range = max_loop;
+ range = max_loop << part_shift;
} else {
nr = 8;
- range = 1UL << (MINORBITS - part_shift);
+ range = 1UL << MINORBITS;
}
if (register_blkdev(LOOP_MAJOR, "loop"))
@@ -1655,7 +1655,7 @@ static void __exit loop_exit(void)
unsigned long range;
struct loop_device *lo, *next;
- range = max_loop ? max_loop : 1UL << (MINORBITS - part_shift);
+ range = max_loop ? max_loop << part_shift : 1UL << MINORBITS;
list_for_each_entry_safe(lo, next, &loop_devices, lo_list)
loop_del_one(lo);
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Craig Shelley <[email protected]>
commit 4eff0b40a7174896b860312910e0db51f2dcc567 upstream.
This patch adds 4 device IDs for CP2102 based devices manufactured by
AC-Services. See http://www.ac-services.eu for further info.
Signed-off-by: Craig Shelley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/serial/cp210x.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -114,6 +114,10 @@ static struct usb_device_id id_table []
{ USB_DEVICE(0x10C4, 0x8418) }, /* IRZ Automation Teleport SG-10 GSM/GPRS Modem */
{ USB_DEVICE(0x10C4, 0x846E) }, /* BEI USB Sensor Interface (VCP) */
{ USB_DEVICE(0x10C4, 0x8477) }, /* Balluff RFID */
+ { USB_DEVICE(0x10C4, 0x85EA) }, /* AC-Services IBUS-IF */
+ { USB_DEVICE(0x10C4, 0x85EB) }, /* AC-Services CIS-IBUS */
+ { USB_DEVICE(0x10C4, 0x8664) }, /* AC-Services CAN-IF */
+ { USB_DEVICE(0x10C4, 0x8665) }, /* AC-Services OBD-IF */
{ USB_DEVICE(0x10C4, 0xEA60) }, /* Silicon Labs factory default */
{ USB_DEVICE(0x10C4, 0xEA61) }, /* Silicon Labs factory default */
{ USB_DEVICE(0x10C4, 0xEA71) }, /* Infinity GPS-MIC-1 Radio Monophone */
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Elizabeth Jennifer Myers <[email protected]>
commit 3938a0b32dc12229e76735679b37095bc2bc1578 upstream.
Tested on my phone, the ttyUSB device is created and is fully
functional.
Signed-off-by: Elizabeth Jennifer Myers <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/serial/moto_modem.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/serial/moto_modem.c
+++ b/drivers/usb/serial/moto_modem.c
@@ -25,6 +25,7 @@ static struct usb_device_id id_table []
{ USB_DEVICE(0x05c6, 0x3197) }, /* unknown Motorola phone */
{ USB_DEVICE(0x0c44, 0x0022) }, /* unknown Mororola phone */
{ USB_DEVICE(0x22b8, 0x2a64) }, /* Motorola KRZR K1m */
+ { USB_DEVICE(0x22b8, 0x2c84) }, /* Motorola VE240 phone */
{ USB_DEVICE(0x22b8, 0x2c64) }, /* Motorola V950 phone */
{ },
};
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: =?UTF-8?q?Benedek=20L=C3=A1szl=C3=B3?= <[email protected]>
commit 37909fe588c9e09ab57cd267e98678a17ceda64a upstream.
Adding support for the TavIR STK500 (id 0403:FA33)
Atmel AVR programmer device based on FTDI FT232RL.
Signed-off-by: Benedek László <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 5 +++++
2 files changed, 6 insertions(+)
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -570,6 +570,7 @@ static struct usb_device_id id_table_com
{ USB_DEVICE(FTDI_VID, FTDI_IBS_APP70_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_IBS_PEDO_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_IBS_PROD_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_TAVIR_STK500_PID) },
/*
* ELV devices:
*/
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -491,6 +491,11 @@
/* http://www.canusb.com Lawicel CANUSB device (FTDI_VID) */
#define FTDI_CANUSB_PID 0xFFA8 /* Product Id */
+/*
+ * TavIR AVR product ids (FTDI_VID)
+ */
+#define FTDI_TAVIR_STK500_PID 0xFA33 /* STK500 AVR programmer */
+
/********************************/
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
mode
From: Hermann Kneissel <[email protected]>
commit b4026c4584cd70858d4d3450abfb1cd0714d4f32 upstream.
This patch fixes a problem where data received from the gps is sometimes
transferred incompletely to the serial port. If used in native mode now
all data received via the bulk queue will be forwarded to the serial
port.
Signed-off-by: Hermann Kneissel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/serial/garmin_gps.c | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
--- a/drivers/usb/serial/garmin_gps.c
+++ b/drivers/usb/serial/garmin_gps.c
@@ -1,7 +1,7 @@
/*
* Garmin GPS driver
*
- * Copyright (C) 2006-2009 Hermann Kneissel [email protected]
+ * Copyright (C) 2006-2011 Hermann Kneissel [email protected]
*
* The latest version of the driver can be found at
* http://sourceforge.net/projects/garmin-gps/
@@ -51,7 +51,7 @@ static int debug;
*/
#define VERSION_MAJOR 0
-#define VERSION_MINOR 33
+#define VERSION_MINOR 36
#define _STR(s) #s
#define _DRIVER_VERSION(a, b) "v" _STR(a) "." _STR(b)
@@ -411,6 +411,7 @@ static int gsp_send_ack(struct garmin_da
*/
static int gsp_rec_packet(struct garmin_data *garmin_data_p, int count)
{
+ unsigned long flags;
const __u8 *recpkt = garmin_data_p->inbuffer+GSP_INITIAL_OFFSET;
__le32 *usbdata = (__le32 *) garmin_data_p->inbuffer;
@@ -459,7 +460,9 @@ static int gsp_rec_packet(struct garmin_
/* if this was an abort-transfer command, flush all
queued data. */
if (isAbortTrfCmnd(garmin_data_p->inbuffer)) {
+ spin_lock_irqsave(&garmin_data_p->lock, flags);
garmin_data_p->flags |= FLAGS_DROP_DATA;
+ spin_unlock_irqrestore(&garmin_data_p->lock, flags);
pkt_clear(garmin_data_p);
}
@@ -944,7 +947,7 @@ static int garmin_open(struct tty_struct
spin_lock_irqsave(&garmin_data_p->lock, flags);
garmin_data_p->mode = initial_mode;
garmin_data_p->count = 0;
- garmin_data_p->flags = 0;
+ garmin_data_p->flags &= FLAGS_SESSION_REPLY1_SEEN;
spin_unlock_irqrestore(&garmin_data_p->lock, flags);
/* shutdown any bulk reads that might be going on */
@@ -1179,7 +1182,8 @@ static int garmin_write_room(struct tty_
static void garmin_read_process(struct garmin_data *garmin_data_p,
- unsigned char *data, unsigned data_length)
+ unsigned char *data, unsigned data_length,
+ int bulk_data)
{
unsigned long flags;
@@ -1194,7 +1198,8 @@ static void garmin_read_process(struct g
send it directly to the tty port */
if (garmin_data_p->flags & FLAGS_QUEUING) {
pkt_add(garmin_data_p, data, data_length);
- } else if (getLayerId(data) == GARMIN_LAYERID_APPL) {
+ } else if (bulk_data ||
+ getLayerId(data) == GARMIN_LAYERID_APPL) {
spin_lock_irqsave(&garmin_data_p->lock, flags);
garmin_data_p->flags |= APP_RESP_SEEN;
@@ -1238,7 +1243,7 @@ static void garmin_read_bulk_callback(st
usb_serial_debug_data(debug, &port->dev,
__func__, urb->actual_length, data);
- garmin_read_process(garmin_data_p, data, urb->actual_length);
+ garmin_read_process(garmin_data_p, data, urb->actual_length, 1);
if (urb->actual_length == 0 &&
0 != (garmin_data_p->flags & FLAGS_BULK_IN_RESTART)) {
@@ -1348,7 +1353,7 @@ static void garmin_read_int_callback(str
__func__, garmin_data_p->serial_num);
}
- garmin_read_process(garmin_data_p, data, urb->actual_length);
+ garmin_read_process(garmin_data_p, data, urb->actual_length, 0);
port->interrupt_in_urb->dev = port->serial->dev;
retval = usb_submit_urb(urb, GFP_ATOMIC);
@@ -1463,6 +1468,7 @@ static int garmin_attach(struct usb_seri
garmin_data_p->timer.function = timeout_handler;
garmin_data_p->port = port;
garmin_data_p->state = 0;
+ garmin_data_p->flags = 0;
garmin_data_p->count = 0;
usb_set_serial_port_data(port, garmin_data_p);
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Jean-Christophe PLAGNIOL-VILLARD <[email protected]>
commit bf1f0a05d472e33dda8e5e69525be1584cdbd03a upstream.
on 9g20 they are the same as the 9260
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <[email protected]>
Acked-by: Nicolas Ferre <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/gadget/at91_udc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/gadget/at91_udc.c
+++ b/drivers/usb/gadget/at91_udc.c
@@ -1687,7 +1687,7 @@ static int __init at91udc_probe(struct p
}
/* newer chips have more FIFO memory than rm9200 */
- if (cpu_is_at91sam9260()) {
+ if (cpu_is_at91sam9260() || cpu_is_at91sam9g20()) {
udc->ep[0].maxpacket = 64;
udc->ep[3].maxpacket = 64;
udc->ep[4].maxpacket = 512;
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Felipe Balbi <[email protected]>
commit 472b91274a6c6857877b5caddb875dcb5ecdfcb8 upstream.
composite.c always sets req->length to zero
and expects function driver's setup handlers
to return the amount of bytes to be used
on req->length. If we test against req->length
w_length will always be greater than req->length
thus making us always stall that particular
SEND_ENCAPSULATED_COMMAND request.
Tested against a Windows XP SP3.
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/gadget/f_rndis.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/usb/gadget/f_rndis.c
+++ b/drivers/usb/gadget/f_rndis.c
@@ -400,8 +400,7 @@ rndis_setup(struct usb_function *f, cons
*/
case ((USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE) << 8)
| USB_CDC_SEND_ENCAPSULATED_COMMAND:
- if (w_length > req->length || w_value
- || w_index != rndis->ctrl_id)
+ if (w_value || w_index != rndis->ctrl_id)
goto invalid;
/* read the request; process it later */
value = w_length;
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Sarah Sharp <[email protected]>
commit b513d44751bfb609a3c20463f764c8ce822d63e9 upstream.
Dmitry's patch
dfa49c4ad120a784ef1ff0717168aa79f55a483a USB: xhci - fix math in xhci_get_endpoint_interval()
introduced a bug. The USB 2.0 spec says that full speed isochronous endpoints'
bInterval must be decoded as an exponent to a power of two (e.g. interval =
2^(bInterval - 1)). Full speed interrupt endpoints, on the other hand, don't
use exponents, and the interval in frames is encoded straight into bInterval.
Dmitry's patch was supposed to fix up the full speed isochronous to parse
bInterval as an exponent, but instead it changed the *interrupt* endpoint
bInterval decoding. The isochronous endpoint encoding was the same.
This caused full speed devices with interrupt endpoints (including mice, hubs,
and USB to ethernet devices) to fail under NEC 0.96 xHCI host controllers:
[ 100.909818] xhci_hcd 0000:06:00.0: add ep 0x83, slot id 1, new drop flags = 0x0, new add flags = 0x99, new slot info = 0x38100000
[ 100.909821] xhci_hcd 0000:06:00.0: xhci_check_bandwidth called for udev ffff88011f0ea000
...
[ 100.910187] xhci_hcd 0000:06:00.0: ERROR: unexpected command completion code 0x11.
[ 100.910190] xhci_hcd 0000:06:00.0: xhci_reset_bandwidth called for udev ffff88011f0ea000
When the interrupt endpoint was added and a Configure Endpoint command was
issued to the host, the host controller would return a very odd error message
(0x11 means "Slot Not Enabled", which isn't true because the slot was enabled).
Probably the host controller was getting very confused with the bad encoding.
Signed-off-by: Sarah Sharp <[email protected]>
Cc: Dmitry Torokhov <[email protected]>
Reported-by: Thomas Lindroth <[email protected]>
Tested-by: Thomas Lindroth <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/host/xhci-mem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -511,12 +511,12 @@ static inline unsigned int xhci_get_endp
break;
case USB_SPEED_FULL:
- if (usb_endpoint_xfer_int(&ep->desc)) {
+ if (usb_endpoint_xfer_isoc(&ep->desc)) {
interval = xhci_parse_exponent_interval(udev, ep);
break;
}
/*
- * Fall through for isochronous endpoint interval decoding
+ * Fall through for interrupt endpoint interval decoding
* since it uses the same rules as low speed interrupt
* endpoints.
*/
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Alan Stern <[email protected]>
commit 2b7aaf503d56216b847c8265421d2a7d9b42df3e upstream.
This patch (as1463) fixes a regression caused by commit
3df7169e73fc1d71a39cffeacc969f6840cdf52b (OHCI: work around for nVidia
shutdown problem).
The original problem encountered by people using NVIDIA chipsets was
that USB devices were not turning off when the system shut down. For
example, the LED on an optical mouse would remain on, draining a
laptop's battery. The problem was caused by a bug in the chipset; an
OHCI controller in the Reset state would continue to drive a bus reset
signal even after system shutdown. The workaround was to put the
controllers into the Suspend state instead.
It turns out that later NVIDIA chipsets do not suffer from this bug.
Instead some have the opposite bug: If a system is shut down while an
OHCI controller is in the Suspend state, USB devices remain powered!
On other systems, shutting down with a Suspended controller causes the
system to reboot immediately. Thus, working around the original bug
on some machines exposes other bugs on other machines.
The best solution seems to be to limit the workaround to OHCI
controllers with a low-numbered PCI product ID. I don't know exactly
at what point NVIDIA changed their chipsets; the value used here is a
guess. So far it was worked out okay for all the people who have
tested it.
This fixes Bugzilla #35032.
Signed-off-by: Alan Stern <[email protected]>
Tested-by: Andre "Osku" Schmidt <[email protected]>
Tested-by: Yury Siamashka <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/host/ohci-pci.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
--- a/drivers/usb/host/ohci-pci.c
+++ b/drivers/usb/host/ohci-pci.c
@@ -207,10 +207,18 @@ static int ohci_quirk_amd700(struct usb_
*/
static int ohci_quirk_nvidia_shutdown(struct usb_hcd *hcd)
{
+ struct pci_dev *pdev = to_pci_dev(hcd->self.controller);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
- ohci->flags |= OHCI_QUIRK_SHUTDOWN;
- ohci_dbg(ohci, "enabled nVidia shutdown quirk\n");
+ /* Evidently nVidia fixed their later hardware; this is a guess at
+ * the changeover point.
+ */
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP51_USB 0x026d
+
+ if (pdev->device < PCI_DEVICE_ID_NVIDIA_NFORCE_MCP51_USB) {
+ ohci->flags |= OHCI_QUIRK_SHUTDOWN;
+ ohci_dbg(ohci, "enabled nVidia shutdown quirk\n");
+ }
return 0;
}
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Christian Lamparter <[email protected]>
commit 9368a9a2378ab721f82f59430a135b4ce4ff5109 upstream.
Reported-by: Mark Davis <[email protected]>
Signed-off-by: Christian Lamparter <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/p54/p54usb.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/wireless/p54/p54usb.c
+++ b/drivers/net/wireless/p54/p54usb.c
@@ -80,6 +80,7 @@ static struct usb_device_id p54u_table[]
{USB_DEVICE(0x06b9, 0x0121)}, /* Thomson SpeedTouch 121g */
{USB_DEVICE(0x0707, 0xee13)}, /* SMC 2862W-G version 2 */
{USB_DEVICE(0x083a, 0x4521)}, /* Siemens Gigaset USB Adapter 54 version 2 */
+ {USB_DEVICE(0x083a, 0xc501)}, /* Zoom Wireless-G 4410 */
{USB_DEVICE(0x083a, 0xf503)}, /* Accton FD7050E ver 1010ec */
{USB_DEVICE(0x0846, 0x4240)}, /* Netgear WG111 (v2) */
{USB_DEVICE(0x0915, 0x2000)}, /* Cohiba Proto board */
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
filenames
From: Tyler Hicks <[email protected]>
commit 8d08dab786ad5cc2aca2bf870de370144b78c85a upstream.
The buffers allocated while encrypting and decrypting long filenames can
sometimes straddle two pages. In this situation, virt_to_scatterlist()
will return -ENOMEM, causing the operation to fail and the user will get
scary error messages in their logs:
kernel: ecryptfs_write_tag_70_packet: Internal error whilst attempting
to convert filename memory to scatterlist; expected rc = 1; got rc =
[-12]. block_aligned_filename_size = [272]
kernel: ecryptfs_encrypt_filename: Error attempting to generate tag 70
packet; rc = [-12]
kernel: ecryptfs_encrypt_and_encode_filename: Error attempting to
encrypt filename; rc = [-12]
kernel: ecryptfs_lookup: Error attempting to encrypt and encode
filename; rc = [-12]
The solution is to allow up to 2 scatterlist entries to be used.
Signed-off-by: Tyler Hicks <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ecryptfs/keystore.c | 46 +++++++++++++++++++++-------------------------
1 file changed, 21 insertions(+), 25 deletions(-)
--- a/fs/ecryptfs/keystore.c
+++ b/fs/ecryptfs/keystore.c
@@ -481,8 +481,8 @@ struct ecryptfs_write_tag_70_packet_sill
struct mutex *tfm_mutex;
char *block_aligned_filename;
struct ecryptfs_auth_tok *auth_tok;
- struct scatterlist src_sg;
- struct scatterlist dst_sg;
+ struct scatterlist src_sg[2];
+ struct scatterlist dst_sg[2];
struct blkcipher_desc desc;
char iv[ECRYPTFS_MAX_IV_BYTES];
char hash[ECRYPTFS_TAG_70_DIGEST_SIZE];
@@ -695,23 +695,21 @@ ecryptfs_write_tag_70_packet(char *dest,
memcpy(&s->block_aligned_filename[s->num_rand_bytes], filename,
filename_size);
rc = virt_to_scatterlist(s->block_aligned_filename,
- s->block_aligned_filename_size, &s->src_sg, 1);
- if (rc != 1) {
+ s->block_aligned_filename_size, s->src_sg, 2);
+ if (rc < 1) {
printk(KERN_ERR "%s: Internal error whilst attempting to "
- "convert filename memory to scatterlist; "
- "expected rc = 1; got rc = [%d]. "
+ "convert filename memory to scatterlist; rc = [%d]. "
"block_aligned_filename_size = [%zd]\n", __func__, rc,
s->block_aligned_filename_size);
goto out_release_free_unlock;
}
rc = virt_to_scatterlist(&dest[s->i], s->block_aligned_filename_size,
- &s->dst_sg, 1);
- if (rc != 1) {
+ s->dst_sg, 2);
+ if (rc < 1) {
printk(KERN_ERR "%s: Internal error whilst attempting to "
"convert encrypted filename memory to scatterlist; "
- "expected rc = 1; got rc = [%d]. "
- "block_aligned_filename_size = [%zd]\n", __func__, rc,
- s->block_aligned_filename_size);
+ "rc = [%d]. block_aligned_filename_size = [%zd]\n",
+ __func__, rc, s->block_aligned_filename_size);
goto out_release_free_unlock;
}
/* The characters in the first block effectively do the job
@@ -734,7 +732,7 @@ ecryptfs_write_tag_70_packet(char *dest,
mount_crypt_stat->global_default_fn_cipher_key_bytes);
goto out_release_free_unlock;
}
- rc = crypto_blkcipher_encrypt_iv(&s->desc, &s->dst_sg, &s->src_sg,
+ rc = crypto_blkcipher_encrypt_iv(&s->desc, s->dst_sg, s->src_sg,
s->block_aligned_filename_size);
if (rc) {
printk(KERN_ERR "%s: Error attempting to encrypt filename; "
@@ -766,8 +764,8 @@ struct ecryptfs_parse_tag_70_packet_sill
struct mutex *tfm_mutex;
char *decrypted_filename;
struct ecryptfs_auth_tok *auth_tok;
- struct scatterlist src_sg;
- struct scatterlist dst_sg;
+ struct scatterlist src_sg[2];
+ struct scatterlist dst_sg[2];
struct blkcipher_desc desc;
char fnek_sig_hex[ECRYPTFS_SIG_SIZE_HEX + 1];
char iv[ECRYPTFS_MAX_IV_BYTES];
@@ -872,13 +870,12 @@ ecryptfs_parse_tag_70_packet(char **file
}
mutex_lock(s->tfm_mutex);
rc = virt_to_scatterlist(&data[(*packet_size)],
- s->block_aligned_filename_size, &s->src_sg, 1);
- if (rc != 1) {
+ s->block_aligned_filename_size, s->src_sg, 2);
+ if (rc < 1) {
printk(KERN_ERR "%s: Internal error whilst attempting to "
"convert encrypted filename memory to scatterlist; "
- "expected rc = 1; got rc = [%d]. "
- "block_aligned_filename_size = [%zd]\n", __func__, rc,
- s->block_aligned_filename_size);
+ "rc = [%d]. block_aligned_filename_size = [%zd]\n",
+ __func__, rc, s->block_aligned_filename_size);
goto out_unlock;
}
(*packet_size) += s->block_aligned_filename_size;
@@ -892,13 +889,12 @@ ecryptfs_parse_tag_70_packet(char **file
goto out_unlock;
}
rc = virt_to_scatterlist(s->decrypted_filename,
- s->block_aligned_filename_size, &s->dst_sg, 1);
- if (rc != 1) {
+ s->block_aligned_filename_size, s->dst_sg, 2);
+ if (rc < 1) {
printk(KERN_ERR "%s: Internal error whilst attempting to "
"convert decrypted filename memory to scatterlist; "
- "expected rc = 1; got rc = [%d]. "
- "block_aligned_filename_size = [%zd]\n", __func__, rc,
- s->block_aligned_filename_size);
+ "rc = [%d]. block_aligned_filename_size = [%zd]\n",
+ __func__, rc, s->block_aligned_filename_size);
goto out_free_unlock;
}
/* The characters in the first block effectively do the job of
@@ -937,7 +933,7 @@ ecryptfs_parse_tag_70_packet(char **file
mount_crypt_stat->global_default_fn_cipher_key_bytes);
goto out_free_unlock;
}
- rc = crypto_blkcipher_decrypt_iv(&s->desc, &s->dst_sg, &s->src_sg,
+ rc = crypto_blkcipher_decrypt_iv(&s->desc, s->dst_sg, s->src_sg,
s->block_aligned_filename_size);
if (rc) {
printk(KERN_ERR "%s: Error attempting to decrypt filename; "
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Artem Bityutskiy <[email protected]>
commit eaeee242c531cd4b0a4a46e8b5dd7ef504380c42 upstream.
When re-mounting from R/O mode to R/W mode and the LEB count in the superblock
is not up-to date, because for the underlying UBI volume became larger, we
re-write the superblock. We allocate RAM for these purposes, but never free it.
So this is a memory leak, although very rare one.
Signed-off-by: Artem Bityutskiy <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ubifs/sb.c | 3 ++-
fs/ubifs/super.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
--- a/fs/ubifs/sb.c
+++ b/fs/ubifs/sb.c
@@ -474,7 +474,8 @@ failed:
* @c: UBIFS file-system description object
*
* This function returns a pointer to the superblock node or a negative error
- * code.
+ * code. Note, the user of this function is responsible of kfree()'ing the
+ * returned superblock buffer.
*/
struct ubifs_sb_node *ubifs_read_sb_node(struct ubifs_info *c)
{
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -1550,6 +1550,7 @@ static int ubifs_remount_rw(struct ubifs
}
sup->leb_cnt = cpu_to_le32(c->leb_cnt);
err = ubifs_write_sb_node(c, sup);
+ kfree(sup);
if (err)
goto out;
}
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Luca Tettamanti <[email protected]>
commit bc1f419c76a2d6450413ce4349f4e4a07be011d5 upstream.
i8k uses lahf to read the flag register in 64-bit code; early x86-64
CPUs, however, lack this instruction and we get an invalid opcode
exception at runtime.
Use pushf to load the flag register into the stack instead.
Signed-off-by: Luca Tettamanti <[email protected]>
Reported-by: Jeff Rickman <[email protected]>
Tested-by: Jeff Rickman <[email protected]>
Tested-by: Harry G McGavran Jr <[email protected]>
Cc: Massimo Dal Zotto <[email protected]>
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/char/i8k.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/char/i8k.c
+++ b/drivers/char/i8k.c
@@ -138,8 +138,8 @@ static int i8k_smm(struct smm_regs *regs
"movl %%edi,20(%%rax)\n\t"
"popq %%rdx\n\t"
"movl %%edx,0(%%rax)\n\t"
- "lahf\n\t"
- "shrl $8,%%eax\n\t"
+ "pushfq\n\t"
+ "popq %%rax\n\t"
"andl $1,%%eax\n"
:"=a"(rc)
: "a"(regs)
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Artem Bityutskiy <[email protected]>
commit cf610bf4199770420629d3bc273494bd27ad6c1d upstream.
Sometimes VM asks the shrinker to return amount of objects it can shrink,
and we return the ubifs_clean_zn_cnt in that case. However, it is possible
that this counter is negative for a short period of time, due to the way
UBIFS TNC code updates it. And I can observe the following warnings sometimes:
shrink_slab: ubifs_shrinker+0x0/0x2b7 [ubifs] negative objects to delete nr=-8541616642706119788
This patch makes sure UBIFS never returns negative count of objects.
Signed-off-by: Artem Bityutskiy <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ubifs/shrinker.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/fs/ubifs/shrinker.c
+++ b/fs/ubifs/shrinker.c
@@ -283,7 +283,11 @@ int ubifs_shrinker(int nr, gfp_t gfp_mas
long clean_zn_cnt = atomic_long_read(&ubifs_clean_zn_cnt);
if (nr == 0)
- return clean_zn_cnt;
+ /*
+ * Due to the way UBIFS updates the clean znode counter it may
+ * temporarily be negative.
+ */
+ return clean_zn_cnt >= 0 ? clean_zn_cnt : 1;
if (!clean_zn_cnt) {
/*
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Artem Bityutskiy <[email protected]>
commit 812eb258311f89bcd664a34a620f249d54a2cd83 upstream.
UBIFS leaks memory on error path in 'ubifs_jnl_update()' in case of write
failure because it forgets to free the 'struct ubifs_dent_node *dent' object.
Although the object is small, the alignment can make it large - e.g., 2KiB
if the min. I/O unit is 2KiB.
Signed-off-by: Artem Bityutskiy <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ubifs/journal.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/ubifs/journal.c
+++ b/fs/ubifs/journal.c
@@ -665,6 +665,7 @@ out_free:
out_release:
release_head(c, BASEHD);
+ kfree(dent);
out_ro:
ubifs_ro_mode(c, err);
if (last_reference)
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Namhyung Kim <[email protected]>
commit 3b2710824e00d238554c13b5add347e6c701ab1a upstream.
The 'max_part' parameter controls the number of maximum partition
a nbd device can have. However if a user specifies very large
value it would exceed the limitation of device minor number and
can cause a kernel oops (or, at least, produce invalid device
nodes in some cases).
In addition, specifying large 'nbds_max' value causes same
problem for the same reason.
On my desktop, following command results to the kernel bug:
$ sudo modprobe nbd max_part=100000
kernel BUG at /media/Linux_Data/project/linux/fs/sysfs/group.c:65!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/virtual/block/nbd4/range
CPU 1
Modules linked in: nbd(+) bridge stp llc kvm_intel kvm asus_atk0110 sg sr_mod cdrom
Pid: 2522, comm: modprobe Tainted: G W 2.6.39-leonard+ #159 System manufacturer System Product Name/P5G41TD-M PRO
RIP: 0010:[<ffffffff8115aa08>] [<ffffffff8115aa08>] internal_create_group+0x2f/0x166
RSP: 0018:ffff8801009f1de8 EFLAGS: 00010246
RAX: 00000000ffffffef RBX: ffff880103920478 RCX: 00000000000a7bd3
RDX: ffffffff81a2dbe0 RSI: 0000000000000000 RDI: ffff880103920478
RBP: ffff8801009f1e38 R08: ffff880103920468 R09: ffff880103920478
R10: ffff8801009f1de8 R11: ffff88011eccbb68 R12: ffffffff81a2dbe0
R13: ffff880103920468 R14: 0000000000000000 R15: ffff880103920400
FS: 00007f3c49de9700(0000) GS:ffff88011f800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007f3b7fe7c000 CR3: 00000000cd58d000 CR4: 00000000000406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process modprobe (pid: 2522, threadinfo ffff8801009f0000, task ffff8801009a93a0)
Stack:
ffff8801009f1e58 ffffffff812e8f6e ffff8801009f1e58 ffffffff812e7a80
ffff880000000010 ffff880103920400 ffff8801002fd0c0 ffff880103920468
0000000000000011 ffff880103920400 ffff8801009f1e48 ffffffff8115ab6a
Call Trace:
[<ffffffff812e8f6e>] ? device_add+0x4f1/0x5e4
[<ffffffff812e7a80>] ? dev_set_name+0x41/0x43
[<ffffffff8115ab6a>] sysfs_create_group+0x13/0x15
[<ffffffff810b857e>] blk_trace_init_sysfs+0x14/0x16
[<ffffffff811ee58b>] blk_register_queue+0x4c/0xfd
[<ffffffff811f3bdf>] add_disk+0xe4/0x29c
[<ffffffffa007e2ab>] nbd_init+0x2ab/0x30d [nbd]
[<ffffffffa007e000>] ? 0xffffffffa007dfff
[<ffffffff8100020f>] do_one_initcall+0x7f/0x13e
[<ffffffff8107ab0a>] sys_init_module+0xa1/0x1e3
[<ffffffff814f3542>] system_call_fastpath+0x16/0x1b
Code: 41 57 41 56 41 55 41 54 53 48 83 ec 28 0f 1f 44 00 00 48 89 fb 41 89 f6 49 89 d4 48 85 ff 74 0b 85 f6 75 0b 48 83
7f 30 00 75 14 <0f> 0b eb fe b9 ea ff ff ff 48 83 7f 30 00 0f 84 09 01 00 00 49
RIP [<ffffffff8115aa08>] internal_create_group+0x2f/0x166
RSP <ffff8801009f1de8>
---[ end trace 753285ffbf72c57c ]---
Signed-off-by: Namhyung Kim <[email protected]>
Cc: Laurent Vivier <[email protected]>
Cc: Paul Clements <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/block/nbd.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -754,6 +754,12 @@ static int __init nbd_init(void)
if (max_part > 0)
part_shift = fls(max_part);
+ if ((1UL << part_shift) > DISK_MAX_PARTS)
+ return -EINVAL;
+
+ if (nbds_max > 1UL << (MINORBITS - part_shift))
+ return -EINVAL;
+
for (i = 0; i < nbds_max; i++) {
struct gendisk *disk = alloc_disk(1 << part_shift);
if (!disk)
Hi Greg,
seems like only first 55 mails made it to the list, also the link seems to be wrong...
maybe some bug in the script?
n.
On Wed, Jun 15, 2011 at 05:19:00PM -0700, Greg KH wrote:
> This is the start of the longterm review cycle for the 2.6.32.42 release.
> There are 91 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let us know. If anyone is a maintainer of the proper subsystem, and
> wants to add a Signed-off-by: line to the patch, please respond with it.
>
> Responses should be made by Sat, Jun 18, 2011, 00:00:00 UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v2.6/longterm-review/patch-2.6.32.-rc1.gz
> and the diffstat can be found below.
>
> The full set of patches will be sent, as normal, however they will be
> delayed by a few hours out of respect for those still awake and trying
> to get work done.
>
> thanks,
>
> greg k-h
>
> Makefile | 2 +-
> arch/powerpc/kernel/misc_64.S | 13 ++++--
> arch/powerpc/oprofile/op_model_power4.c | 24 +++++++++++-
> arch/x86/include/asm/uaccess.h | 2 +-
> arch/x86/kernel/amd_iommu_init.c | 8 ++--
> arch/x86/kernel/cpu/amd.c | 16 +++++--
> arch/x86/kernel/process_32.c | 1 -
> arch/x86/kernel/process_64.c | 1 -
> arch/x86/lib/copy_user_64.S | 4 +-
> arch/x86/xen/mmu.c | 2 +-
> arch/x86/xen/multicalls.c | 12 +++---
> block/blk-core.c | 2 +
> block/blk.h | 3 +-
> drivers/acpi/scan.c | 12 +++---
> drivers/ata/pata_cmd64x.c | 66 ++++++++++++++++++++----------
> drivers/ata/pata_hpt366.c | 8 +---
> drivers/ata/pata_hpt37x.c | 21 ++++------
> drivers/ata/pata_hpt3x2n.c | 15 ++-----
> drivers/ata/pata_sil680.c | 6 +--
> drivers/block/brd.c | 11 +++--
> drivers/block/loop.c | 11 +++--
> drivers/block/nbd.c | 6 +++
> drivers/char/i8k.c | 4 +-
> drivers/cpufreq/cpufreq.c | 20 ++++++++-
> drivers/cpufreq/cpufreq_stats.c | 22 +++++++++-
> drivers/cpuidle/governors/menu.c | 4 +-
> drivers/gpu/drm/i915/intel_lvds.c | 8 ++++
> drivers/gpu/drm/radeon/radeon_device.c | 1 +
> drivers/md/dm-table.c | 17 ++++++++
> drivers/md/md.c | 2 +-
> drivers/md/raid5.c | 8 ++--
> drivers/mtd/mtdconcat.c | 4 +-
> drivers/net/wireless/iwlwifi/iwl-5000.c | 2 +-
> drivers/net/wireless/p54/p54usb.c | 1 +
> drivers/pci/hotplug/pcihp_slot.c | 45 +++++++++++++++++++++
> drivers/pci/pci.c | 8 +++-
> drivers/pci/quirks.c | 10 +++++
> drivers/scsi/scsi_scan.c | 11 +++--
> drivers/scsi/scsi_sysfs.c | 19 ++++-----
> drivers/scsi/ultrastor.c | 2 +-
> drivers/staging/usbip/usbip_common.c | 2 +-
> drivers/usb/class/cdc-acm.c | 2 +
> drivers/usb/core/hub.c | 6 ++-
> drivers/usb/gadget/at91_udc.c | 2 +-
> drivers/usb/gadget/f_rndis.c | 3 +-
> drivers/usb/host/ohci-pci.c | 12 +++++-
> drivers/usb/host/xhci-mem.c | 18 +++++++--
> drivers/usb/serial/cp210x.c | 4 ++
> drivers/usb/serial/ftdi_sio.c | 2 +
> drivers/usb/serial/ftdi_sio_ids.h | 6 +++
> drivers/usb/serial/garmin_gps.c | 20 ++++++---
> drivers/usb/serial/moto_modem.c | 1 +
> drivers/xen/events.c | 9 +----
> fs/block_dev.c | 27 ++++++++----
> fs/dcookies.c | 3 +
> fs/ecryptfs/keystore.c | 46 ++++++++++------------
> fs/exec.c | 5 +--
> fs/ext3/namei.c | 13 +++++-
> fs/ext4/mballoc.c | 2 +
> fs/fat/file.c | 2 +-
> fs/jbd/commit.c | 9 +++-
> fs/jbd/journal.c | 16 ++++++-
> fs/partitions/ldm.c | 5 ++
> fs/ubifs/journal.c | 1 +
> fs/ubifs/sb.c | 3 +-
> fs/ubifs/shrinker.c | 6 ++-
> fs/ubifs/super.c | 1 +
> fs/xfs/linux-2.6/xfs_sync.c | 16 ++++++--
> fs/xfs/linux-2.6/xfs_sync.h | 1 +
> fs/xfs/xfs_iget.c | 1 +
> include/linux/interrupt.h | 3 +-
> include/linux/pci_ids.h | 2 +
> include/linux/seqlock.h | 4 +-
> kernel/irq/manage.c | 11 +++++-
> kernel/irq/pm.c | 3 -
> kernel/lockdep.c | 2 +-
> kernel/time/timekeeping.c | 9 +++-
> kernel/trace/ftrace.c | 12 +++--
> lib/locking-selftest.c | 2 +-
> mm/hugetlb.c | 4 +-
> mm/kmemleak.c | 7 ++-
> mm/page_alloc.c | 2 +-
> net/atm/atm_sysfs.c | 10 +++++
> net/ipv6/netfilter/ip6t_REJECT.c | 4 +-
> net/ipv6/netfilter/nf_conntrack_reasm.c | 8 +---
> net/netfilter/xt_DSCP.c | 2 +-
> net/sunrpc/xprtsock.c | 16 ++++++-
> net/wireless/nl80211.c | 2 +-
> sound/pci/hda/patch_realtek.c | 1 +
> sound/pci/hda/patch_sigmatel.c | 2 +-
> sound/soc/codecs/wm_hubs.c | 24 +++++++-----
> 91 files changed, 552 insertions(+), 256 deletions(-)
>
> _______________________________________________
> Stable-review mailing list
> [email protected]
> http://linux.kernel.org/mailman/listinfo/stable-review
>
--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
http://www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: [email protected]
-------------------------------------
On Fri, Jun 17, 2011 at 10:36:49PM +0200, Nikola Ciprich wrote:
> Hi Greg,
> seems like only first 55 mails made it to the list, also the link seems to be wrong...
I forgot to put the correct link in the email, it should be obvious as
to what it should be.
> maybe some bug in the script?
Probably, some people pointed out a problem that I had with the Subject:
on some patches, which was caused by a git update and my scripts not
properly handling multi-line Subject: lines in emails.
I'll fix that up for next time.
thanks,
greg k-h