18 Feb, 2011
40 commits
-
commit c093b8b46c5f0dd12d799f0d6a3b579863df72f6 upstream.
We use the physical address instead of the base gfn for the four
PAE page directories we use in unpaged mode. When the guest accesses
an address above 1GB that is backed by a large host page, a BUG_ON()
in kvm_mmu_set_gfn() triggers.Resolves: https://bugzilla.kernel.org/show_bug.cgi?id=21962
Reported-and-tested-by: Nicolas Prochazka
Signed-off-by: Avi Kivity
Cc: Marcelo Tosatti
Signed-off-by: Greg Kroah-Hartman -
commit a0272630bb594b4eac03a79e77957df7dad8eade upstream.
isr_ack is never initialized. So, until the first PIC reset, interrupts
may fail to be injected. This can cause Windows XP to fail to boot, as
reported in the fallout from the fix to
https://bugzilla.kernel.org/show_bug.cgi?id=21962.Reported-and-tested-by: Nicolas Prochazka
Signed-off-by: Avi Kivity
Signed-off-by: Greg Kroah-Hartman -
commit e91ece5590b3c728624ab57043fc7a05069c604a upstream.
md_make_request was calling bio_sectors() for part_stat_add
after it was calling the make_request function. This is
bad because the make_request function can free the bio and
because the bi_size field can change around.The fix here was suggested by Jens Axboe. It saves the
sector count before the make_request call. I hit this
with CONFIG_DEBUG_PAGEALLOC turned on while trying to break
his pretty fusionio card.Signed-off-by: Chris Mason
Signed-off-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman -
commit 77c5fd19075d299fe820bb59bb21b0b113676e20 upstream.
pata_mpc52xx supports BMDMA but inherits ata_sff_port_ops which
triggers BUG_ON() when a DMA command is issued. Fix it.Signed-off-by: Tejun Heo
Reported-by: Roman Fietze
Cc: Sergei Shtylyov
Signed-off-by: Jeff Garzik
Signed-off-by: Greg Kroah-Hartman -
commit bf2cb0dab8c97f00a71875d9b13dbac17a2f47ca upstream.
When a RAID6 is converted to a RAID5, the extra drive should
be discarded. However it isn't due to a typo in a comparison.This bug was introduced in commit e93f68a1fc6 in 2.6.35-rc4
and is suitable for any -stable since than.As the extra drive is not removed, the 'degraded' counter is wrong and
so the RAID5 will not respond correctly to a subsequent failure.Signed-off-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman -
commit 0ca69886a8273ac1350143d562280bfcbe4760dc upstream.
When an md device is in the process of coming on line it is possible
for an IO request (typically a partition table probe) to get through
before the array is fully initialised, which can cause unexpected
behaviour (e.g. a crash).So explicitly record when the array is ready for IO and don't allow IO
through until then.There is no possibility for a similar problem when the array is going
off-line as there must only be one 'open' at that time, and it is busy
off-lining the array and so cannot send IO requests. So no memory
barrier is needed in md_stop()This has been a bug since commit 409c57f3801 in 2.6.30 which
introduced md_make_request. Before then, each personality would
register its own make_request_fn when it was ready.
This is suitable for any stable kernel from 2.6.30.y onwards.Signed-off-by: NeilBrown
Reported-by: "Hawrylewicz Czarnowski, Przemyslaw"
Signed-off-by: Greg Kroah-Hartman -
commit 6c9879101442b08581e8a0e3ae6b7f643a78fd63 upstream.
commit 589a594be1fb (2.6.37-rc4) fixed a problem were md_thread would
sometimes call the ->run function at a bad time.If an error is detected during array start up after the md_thread has
been started, the md_thread is killed. This resulted in the ->run
function being called once. However the array may not be in a state
that it is safe to call ->run.However the fix imposed meant that ->run was not called on a timeout.
This means that when an array goes idle, bitmap bits do not get
cleared promptly. While the array is busy the bits will still be
cleared when appropriate so this is not very serious. There is no
risk to data.Change the test so that we only avoid calling ->run when the thread
is being stopped. This more explicitly addresses the problem situation.This is suitable for 2.6.37-stable and any -stable kernel to which
589a594be1fb was applied.Signed-off-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman -
commit bf572541ab44240163eaa2d486b06f306a31d45a upstream.
Commit 1a855a0606 (2.6.37-rc4) fixed a problem where devices were
re-added when they shouldn't be but caused a regression in a less
common case that means sometimes devices cannot be re-added when they
should be.In particular, when re-adding a device to an array without metadata
we should always access the device, but after the above commit we
didn't.This patch sets the In_sync flag in that case so that the re-add
succeeds.This patch is suitable for any -stable kernel to which 1a855a0606 was
applied.Signed-off-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman -
commit 6dc19899958e420a931274b94019e267e2396d3e upstream.
I noticed a failure where we hit the following WARN_ON in
generic_smp_call_function_interrupt:if (!cpumask_test_and_clear_cpu(cpu, data->cpumask))
continue;data->csd.func(data->csd.info);
refs = atomic_dec_return(&data->refs);
WARN_ON(refs < 0); cpumask sees and
clears bit in cpumask
might be using old or new fn!
decrements refs below 0set data->refs (too late!)
The important thing to note is since the interrupt handler walks a
potentially stale call_function.queue without any locking, then another
cpu can view the percpu *data structure at any time, even when the owner
is in the process of initialising it.The following test case hits the WARN_ON 100% of the time on my PowerPC
box (having 128 threads does help :)#include
#include#define ITERATIONS 100
static void do_nothing_ipi(void *dummy)
{
}static void do_ipis(struct work_struct *dummy)
{
int i;for (i = 0; i < ITERATIONS; i++)
smp_call_function(do_nothing_ipi, NULL, 1);printk(KERN_DEBUG "cpu %d finished\n", smp_processor_id());
}static struct work_struct work[NR_CPUS];
static int __init testcase_init(void)
{
int cpu;for_each_online_cpu(cpu) {
INIT_WORK(&work[cpu], do_ipis);
schedule_work_on(cpu, &work[cpu]);
}return 0;
}static void __exit testcase_exit(void)
{
}module_init(testcase_init)
module_exit(testcase_exit)
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Anton Blanchard");I tried to fix it by ordering the read and the write of ->cpumask and
->refs. In doing so I missed a critical case but Paul McKenney was able
to spot my bug thankfully :) To ensure we arent viewing previous
iterations the interrupt handler needs to read ->refs then ->cpumask then
->refs _again_.Thanks to Milton Miller and Paul McKenney for helping to debug this issue.
[miltonm@bga.com: add WARN_ON and BUG_ON, remove extra read of refs before initial read of mask that doesn't help (also noted by Peter Zijlstra), adjust comments, hopefully clarify scenario ]
[miltonm@bga.com: remove excess tests]
Signed-off-by: Anton Blanchard
Signed-off-by: Milton Miller
Cc: Ingo Molnar
Cc: "Paul E. McKenney"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 20d9600cb407b0b55fef6ee814b60345c6f58264 upstream.
When using devices that support max_segments > BIO_MAX_PAGES (256), direct
IO tries to allocate a bio with more pages than allowed, which leads to an
oops in dio_bio_alloc(). Clamp the request to the supported maximum, and
change dio_bio_alloc() to reflect that bio_alloc() will always return a
bio when called with __GFP_WAIT and a valid number of vectors.[akpm@linux-foundation.org: remove redundant BUG_ON()]
Signed-off-by: David Dillow
Reviewed-by: Jeff Moyer
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 2550326ac7a062fdfc204f9a3b98bdb9179638fc upstream.
Fix collision with kernel-supplied #define:
drivers/video/backlight/88pm860x_bl.c:24:1: warning: "CURRENT_MASK" redefined
arch/x86/include/asm/page_64_types.h:6:1: warning: this is the location of the previous definitionSigned-off-by: Randy Dunlap
Cc: Haojian Zhuang
Cc: Richard Purdie
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit dd3cb633078fb12e06ce6cebbdfbf55a7562e929 upstream.
This fixes parsing of the device invariants (MAC address)
for PCMCIA SSB devices.ssb_pcmcia_do_get_invariants expects an iv pointer as data
argument.Tested-by: dylan cristiani
Signed-off-by: Michael Buesch
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit d2478521afc20227658a10a8c5c2bf1a2aa615b3 upstream.
This patch fixes an OOPS triggered when calling modprobe ipmi_si a
second time after the first modprobe returned without finding any ipmi
devices. This can happen if you reload the module after having the
first module load fail. The driver was not deregistering from PNP in
that case.Peter Huewe originally reported this patch and supplied a fix, I have a
different patch based on Linus' suggestion that cleans things up a bit
more.Cc: openipmi-developer@lists.sourceforge.net
Reviewed-by: Peter Huewe
Cc: Randy Dunlap
Signed-off-by: Corey Minyard
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 9ffdc6c37df131f89d52001e0ef03091b158826f upstream.
Signed-off-by: Marcin Slusarz
[ add {}'s to fix a warning ]
Signed-off-by: Don Zickus
Cc: Peter Zijlstra
Cc: Frederic Weisbecker
LKML-Reference:
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 397357666de6b5b6adb5fa99f9758ec8cf30ac34 upstream.
If it was not possible to enable watchdog for any cpu, switch
watchdog_enabled back to 0, because it's visible via
kernel.watchdog sysctl.Signed-off-by: Marcin Slusarz
Signed-off-by: Don Zickus
Cc: Peter Zijlstra
Cc: Frederic Weisbecker
LKML-Reference:
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit fbea668498e93bb38ac9226c7af9120a25957375 upstream.
Remove the broken line wrapping handling in pdc_iodc_print().
It is broken in 3 ways :
- It doesn't keep track of the current screen position, it just
assumes that the new buffer will be printed at the begining of the
screen.
- It doesn't take in account that non printable characters won't
increase the current position on the screen.
- And last but not least, it triggers a kernel panic if a backspace
is the first char in the provided buffer :Backtrace:
[] pdc_console_write+0x44/0x78
[] pdc_console_tty_write+0x20/0x38
[] n_tty_write+0x2a4/0x550
[] tty_write+0x1e0/0x2d8
[] vfs_write+0xb8/0x188
[] sys_write+0x68/0xb8
[] syscall_exit+0x0/0x14Most terminals handle the line wrapping just fine. I've confirmed that
it works correctly on a C8000 with both vga and serial output.Signed-off-by: Guy Martin
Signed-off-by: James Bottomley
Signed-off-by: Greg Kroah-Hartman -
commit 6044565af458e7fa6e748bff437ecc49dea88d79 upstream.
Regression since commit 10389536742c, "firewire: core: check for 1394a
compliant IRM, fix inaccessibility of Sony camcorder":The camcorder Canon MV5i generates lots of bus resets when asynchronous
requests are sent to it (e.g. Config ROM read requests or FCP Command
write requests) if the camcorder is not root node. This causes drop-
outs in videos or makes the camcorder entirely inaccessible.
https://bugzilla.redhat.com/show_bug.cgi?id=633260Fix this by allowing any Canon device, even if it is a pre-1394a IRM
like MV5i are, to remain root node (if it is at least Cycle Master
capable). With the FireWire controller cards that I tested, MV5i always
becomes root node when plugged in and left to its own devices.Reported-by: Ralf Lange
Signed-off-by: Stefan Richter
Signed-off-by: Greg Kroah-Hartman -
commit 1f1936ff3febf38d582177ea319eaa278f32c91f upstream.
Some of those functions try to adjust the CPU features, for example
to remove NAP support on some revisions. However, they seem to use
r5 as an index into the CPU table entry, which might have been right
a long time ago but no longer is. r4 is the right register to use.This probably caused some off behaviours on some PowerMac variants
using 750cx or 7455 processor revisions.Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit 429f4d8d20b91e4a6c239f951c06a56a6ac22957 upstream.
When converting to the new cpumask code I screwed up:
- if (cpu_isset(cpu, numa_cpumask_lookup_table[node])) {
- cpu_clear(cpu, numa_cpumask_lookup_table[node]);
+ if (cpumask_test_cpu(cpu, node_to_cpumask_map[node])) {
+ cpumask_set_cpu(cpu, node_to_cpumask_map[node]);This was introduced in commit 25863de07af9 (powerpc/cpumask: Convert NUMA code
to new cpumask API)Fix it.
Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit 57cdfdf829a850a317425ed93c6a576c9ee6329c upstream.
Spinlocks on shared processor partitions use H_YIELD to notify the
hypervisor we are waiting on another virtual CPU. Unfortunately this means
the hcall tracepoints can recurse.The patch below adds a percpu depth and checks it on both the entry and
exit hcall tracepoints.Signed-off-by: Anton Blanchard
Acked-by: Steven Rostedt
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit b2e0861e51f2961954330dcafe6d148ee3ab5cff upstream.
In order to prevent the fsl_dma driver from claiming the DMA channels that the
P1022DS audio driver needs, the compatible properties for those nodes must say
"fsl,ssi-dma-channel" instead of "fsl,eloplus-dma-channel".Signed-off-by: Timur Tabi
Signed-off-by: Kumar Gala
Signed-off-by: Greg Kroah-Hartman -
commit 02a8f01b5a9f396d0327977af4c232d0f94c45fd upstream.
Commit 7667aa0630407bc07dc38dcc79d29cc0a65553c1 added logic to wait for
the last queue of the group to become busy (have at least one request),
so that the group does not lose out for not being continuously
backlogged. The commit did not check for the condition that the last
queue already has some requests. As a result, if the queue already has
requests, wait_busy is set. Later on, cfq_select_queue() checks the
flag, and decides that since the queue has a request now and wait_busy
is set, the queue is expired. This results in early expiration of the
queue.This patch fixes the problem by adding a check to see if queue already
has requests. If it does, wait_busy is not set. As a result, time slices
do not expire early.The queues with more than one request are usually buffered writers.
Testing shows improvement in isolation between buffered writers.Signed-off-by: Justin TerAvest
Reviewed-by: Gui Jianfeng
Acked-by: Vivek Goyal
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit 795abaf1e4e188c4171e3cd3dbb11a9fcacaf505 upstream.
Commit c0e69a5bbc6f ("klist.c: bit 0 in pointer can't be used as flag")
intended to make sure that all klist objects were at least pointer size
aligned, but used the constant "4" which only works on 32-bit.Use "sizeof(void *)" which is correct in all cases.
Signed-off-by: David S. Miller
Acked-by: Jesper Nilsson
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 88f5acf88ae6a9778f6d25d0d5d7ec2d57764a97 upstream.
Commit aa45484 ("calculate a better estimate of NR_FREE_PAGES when memory
is low") noted that watermarks were based on the vmstat NR_FREE_PAGES. To
avoid synchronization overhead, these counters are maintained on a per-cpu
basis and drained both periodically and when a threshold is above a
threshold. On large CPU systems, the difference between the estimate and
real value of NR_FREE_PAGES can be very high. The system can get into a
case where pages are allocated far below the min watermark potentially
causing livelock issues. The commit solved the problem by taking a better
reading of NR_FREE_PAGES when memory was low.Unfortately, as reported by Shaohua Li this accurate reading can consume a
large amount of CPU time on systems with many sockets due to cache line
bouncing. This patch takes a different approach. For large machines
where counter drift might be unsafe and while kswapd is awake, the per-cpu
thresholds for the target pgdat are reduced to limit the level of drift to
what should be a safe level. This incurs a performance penalty in heavy
memory pressure by a factor that depends on the workload and the machine
but the machine should function correctly without accidentally exhausting
all memory on a node. There is an additional cost when kswapd wakes and
sleeps but the event is not expected to be frequent - in Shaohua's test
case, there was one recorded sleep and wake event at least.To ensure that kswapd wakes up, a safe version of zone_watermark_ok() is
introduced that takes a more accurate reading of NR_FREE_PAGES when called
from wakeup_kswapd, when deciding whether it is really safe to go back to
sleep in sleeping_prematurely() and when deciding if a zone is really
balanced or not in balance_pgdat(). We are still using an expensive
function but limiting how often it is called.When the test case is reproduced, the time spent in the watermark
functions is reduced. The following report is on the percentage of time
spent cumulatively spent in the functions zone_nr_free_pages(),
zone_watermark_ok(), __zone_watermark_ok(), zone_watermark_ok_safe(),
zone_page_state_snapshot(), zone_page_state().vanilla 11.6615%
disable-threshold 0.2584%David said:
: We had to pull aa454840 "mm: page allocator: calculate a better estimate
: of NR_FREE_PAGES when memory is low and kswapd is awake" from 2.6.36
: internally because tests showed that it would cause the machine to stall
: as the result of heavy kswapd activity. I merged it back with this fix as
: it is pending in the -mm tree and it solves the issue we were seeing, so I
: definitely think this should be pushed to -stable (and I would seriously
: consider it for 2.6.37 inclusion even at this late date).Signed-off-by: Mel Gorman
Reported-by: Shaohua Li
Reviewed-by: Christoph Lameter
Tested-by: Nicolas Bareil
Cc: David Rientjes
Cc: Kyle McMartin
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit a34650f0f1ca589cda09c48cb62baf15e680a247 upstream.
The bfin_sdh driver allocates the wrong size for the private data
in the mmc_host. The first parameter of mmc_alloc_host should be
the size of the local driver struct rather than the common mmc_host.Signed-off-by: Sonic Zhang
Signed-off-by: Mike Frysinger
Signed-off-by: Chris Ball
Signed-off-by: Greg Kroah-Hartman -
commit 01c88e2d6b7330c0cc5867fe2297e7d826e1337d upstream.
Commit 4b53433468 ("memcg: clean up try_charge main loop") removes a
cancel of charge at case: memory charge-> success. mem+swap charge->
failure.This leaks usage of memory. Fix it.
Signed-off-by: KAMEZAWA Hiroyuki
Reviewed-by: Johannes Weiner
Acked-by: Daisuke Nishimura
Cc: Balbir Singh
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit b0a2679d27408d97ce31e5f800b44227d3388b84 upstream.
Disable the initrd if the passed address already overlaps the reserved
region. This avoids oopses on Netwinders when NeTTrom tells the kernel
that an initrd is located at mem+4MB, but this overlaps the BSS,
resulting in the kernels in-use BSS being freed.This should be applied to v2.6.37-stable.
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman -
commit aa5bd67dcfdf9af34c7fa36ebc87d4e1f7e91873 upstream.
Since check_prlimit_permission always fails in the case of SUID/GUID
processes, such processes are not able to read or set their own limits.
This commit changes this by assuming that process can always read/change
its own limits.Signed-off-by: Kacper Kornet
Acked-by: Jiri Slaby
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit a124339ad28389093ed15eca990d39c51c5736cc upstream.
We have found a hardware erratum on 82599 hardware that can lead to
unpredictable behavior when Header Splitting mode is enabled. So
we are no longer enabling this feature on affected hardware.Please see the 82599 Specification Update for more information.
Signed-off-by: Don Skidmore
Tested-by: Stephen Ko
Signed-off-by: Jeff Kirsher
Signed-off-by: Greg Kroah-Hartman -
commit 70a062286b9dfcbd24d2e11601aecfead5cf709a upstream.
Fixes a hang when booting as dom0 under Xen, when jiffies can be
quite large by the time the kernel init gets this far.Signed-off-by: Tim Deegan
[jbeulich@novell.com: !time_after() -> time_before_eq() as suggested by Jiri Slaby]
Signed-off-by: Jan Beulich
Cc: Jiri Slaby
Cc: Jeremy Fitzhardinge
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit f7448548a9f32db38f243ccd4271617758ddfe2c upstream.
Markus Kohn ran into a hard hang regression on an acer aspire
1310, when acpi is enabled. git bisect showed the following
commit as the bad one that introduced the boot regression.commit d0af9eed5aa91b6b7b5049cae69e5ea956fd85c3
Author: Suresh Siddha
Date: Wed Aug 19 18:05:36 2009 -0700x86, pat/mtrr: Rendezvous all the cpus for MTRR/PAT init
Because of the UP configuration of that platform,
native_smp_prepare_cpus() bailed out (in smp_sanity_check())
before doing the set_mtrr_aps_delayed_init()Further down the boot path, native_smp_cpus_done() will call the
delayed MTRR initialization for the AP's (mtrr_aps_init()) with
mtrr_aps_delayed_init not set. This resulted in the boot
processor reprogramming its MTRR's to the values seen during the
start of the OS boot. While this is not needed ideally, this
shouldn't have caused any side-effects. This is because the
reprogramming of MTRR's (set_mtrr_state() that gets called via
set_mtrr()) will check if the live register contents are
different from what is being asked to write and will do the actual
write only if they are different.BP's mtrr state is read during the start of the OS boot and
typically nothing would have changed when we ask to reprogram it
on BP again because of the above scenario on an UP platform. So
on a normal UP platform no reprogramming of BP MTRR MSR's
happens and all is well.However, on this platform, bios seems to be modifying the fixed
mtrr range registers between the start of OS boot and when we
double check the live registers for reprogramming BP MTRR
registers. And as the live registers are modified, we end up
reprogramming the MTRR's to the state seen during the start of
the OS boot.During ACPI initialization, something in the bios (probably smi
handler?) don't like this fact and results in a hard lockup.We didn't see this boot hang issue on this platform before the
commit d0af9eed5aa91b6b7b5049cae69e5ea956fd85c3, because only
the AP's (if any) will program its MTRR's to the value that BP
had at the start of the OS boot.Fix this issue by checking mtrr_aps_delayed_init before
continuing further in the mtrr_aps_init(). Now, only AP's (if
any) will program its MTRR's to the BP values during boot.Addresses https://bugzilla.novell.com/show_bug.cgi?id=623393
[ By the way, this behavior of the bios modifying MTRR's after the start
of the OS boot is not common and the kernel is not prepared to
handle this situation well. Irrespective of this issue, during
suspend/resume, linux kernel will try to reprogram the BP's MTRR values
to the values seen during the start of the OS boot. So suspend/resume might
be already broken on this platform for all linux kernel versions. ]Reported-and-bisected-by: Markus Kohn
Tested-by: Markus Kohn
Signed-off-by: Suresh Siddha
Cc: Thomas Renninger
Cc: Rafael Wysocki
Cc: Venkatesh Pallipadi
LKML-Reference:
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 13ad17745c2cbd437d9e24b2d97393e0be11c439 upstream.
Ed Swierk writes:
> On 2.6.35.7
> ip link add link eth0 netns 9999 type macvlan
> where 9999 is a nonexistent PID triggers an oops and causes all network functions to hang:
> [10663.821898] BUG: unable to handle kernel NULL pointer dereference at 000000000000006d
> [10663.821917] IP: [] __dev_alloc_name+0x9a/0x170
> [10663.821933] PGD 1d3927067 PUD 22f5c5067 PMD 0
> [10663.821944] Oops: 0000 [#1] SMP
> [10663.821953] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
> [10663.821959] CPU 3
> [10663.821963] Modules linked in: macvlan ip6table_filter ip6_tables rfcomm ipt_MASQUERADE binfmt_misc iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack sco ipt_REJECT bnep l2cap xt_tcpudp iptable_filter ip_tables x_tables bridge stp vboxnetadp vboxnetflt vboxdrv kvm_intel kvm parport_pc ppdev snd_hda_codec_intelhdmi snd_hda_codec_conexant arc4 iwlagn iwlcore mac80211 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi i915 snd_seq_midi_event snd_seq thinkpad_acpi drm_kms_helper btusb tpm_tis nvram uvcvideo snd_timer snd_seq_device bluetooth videodev v4l1_compat v4l2_compat_ioctl32 tpm drm tpm_bios snd cfg80211 psmouse serio_raw intel_ips soundcore snd_page_alloc intel_agp i2c_algo_bit video output netconsole configfs lp parport usbhid hid e1000e sdhci_pci ahci libahci sdhci led_class
> [10663.822155]
> [10663.822161] Pid: 6000, comm: ip Not tainted 2.6.35-23-generic #41-Ubuntu 2901CTO/2901CTO
> [10663.822167] RIP: 0010:[] [] __dev_alloc_name+0x9a/0x170
> [10663.822177] RSP: 0018:ffff88014aebf7b8 EFLAGS: 00010286
> [10663.822182] RAX: 00000000fffffff4 RBX: ffff8801ad900800 RCX: 0000000000000000
> [10663.822187] RDX: ffff880000000000 RSI: 0000000000000000 RDI: ffff88014ad63000
> [10663.822191] RBP: ffff88014aebf808 R08: 0000000000000041 R09: 0000000000000041
> [10663.822196] R10: 0000000000000000 R11: dead000000200200 R12: ffff88014aebf818
> [10663.822201] R13: fffffffffffffffd R14: ffff88014aebf918 R15: ffff88014ad62000
> [10663.822207] FS: 00007f00c487f700(0000) GS:ffff880001f80000(0000) knlGS:0000000000000000
> [10663.822212] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [10663.822216] CR2: 000000000000006d CR3: 0000000231f19000 CR4: 00000000000026e0
> [10663.822221] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [10663.822226] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [10663.822231] Process ip (pid: 6000, threadinfo ffff88014aebe000, task ffff88014afb16e0)
> [10663.822236] Stack:
> [10663.822240] ffff88014aebf808 ffffffff814a2bb5 ffff88014aebf7e8 00000000a00ee8d6
> [10663.822251] 0000000000000000 ffffffffa00ef940 ffff8801ad900800 ffff88014aebf818
> [10663.822265] ffff88014aebf918 ffff8801ad900800 ffff88014aebf858 ffffffff8149c413
> [10663.822281] Call Trace:
> [10663.822290] [] ? dev_addr_init+0x75/0xb0
> [10663.822298] [] dev_alloc_name+0x43/0x90
> [10663.822307] [] rtnl_create_link+0xbe/0x1b0
> [10663.822314] [] rtnl_newlink+0x48a/0x570
> [10663.822321] [] ? rtnl_newlink+0x1ac/0x570
> [10663.822332] [] ? native_x2apic_icr_read+0x4/0x20
> [10663.822339] [] rtnetlink_rcv_msg+0x177/0x290
> [10663.822346] [] ? rtnetlink_rcv_msg+0x0/0x290
> [10663.822354] [] netlink_rcv_skb+0xa9/0xd0
> [10663.822360] [] rtnetlink_rcv+0x25/0x40
> [10663.822367] [] netlink_unicast+0x2de/0x2f0
> [10663.822374] [] netlink_sendmsg+0x1fe/0x2e0
> [10663.822383] [] sock_sendmsg+0xf3/0x120
> [10663.822391] [] ? _raw_spin_lock+0xe/0x20
> [10663.822400] [] ? __d_lookup+0x136/0x150
> [10663.822406] [] ? _raw_spin_lock+0xe/0x20
> [10663.822414] [] ? _atomic_dec_and_lock+0x4d/0x80
> [10663.822422] [] ? mntput_no_expire+0x30/0x110
> [10663.822429] [] ? move_addr_to_kernel+0x65/0x70
> [10663.822435] [] ? verify_iovec+0x88/0xe0
> [10663.822442] [] sys_sendmsg+0x240/0x3a0
> [10663.822450] [] ? __do_fault+0x479/0x560
> [10663.822457] [] ? _raw_spin_lock+0xe/0x20
> [10663.822465] [] ? alloc_fd+0x10a/0x150
> [10663.822473] [] ? do_page_fault+0x15e/0x350
> [10663.822482] [] system_call_fastpath+0x16/0x1b
> [10663.822487] Code: 90 48 8d 78 02 be 25 00 00 00 e8 92 1d e2 ff 48 85 c0 75 cf bf 20 00 00 00 e8 c3 b1 c6 ff 49 89 c7 b8 f4 ff ff ff 4d 85 ff 74 bd 8b 75 70 49 8d 45 70 48 89 45 b8 49 83 ee 58 eb 28 48 8d 55
> [10663.822618] RIP [] __dev_alloc_name+0x9a/0x170
> [10663.822627] RSP
> [10663.822631] CR2: 000000000000006d
> [10663.822636] ---[ end trace 3dfd6c3ad5327ca7 ]---This bug was introduced in:
commit 81adee47dfb608df3ad0b91d230fb3cef75f0060
Author: Eric W. Biederman
Date: Sun Nov 8 00:53:51 2009 -0800net: Support specifying the network namespace upon device creation.
There is no good reason to not support userspace specifying the
network namespace during device creation, and it makes it easier
to create a network device and pass it to a child network namespace
with a well known name.We have to be careful to ensure that the target network namespace
for the new device exists through the life of the call. To keep
that logic clear I have factored out the network namespace grabbing
logic into rtnl_link_get_net.In addtion we need to continue to pass the source network namespace
to the rtnl_link_ops.newlink method so that we can find the base
device source network namespace.Signed-off-by: Eric W. Biederman
Acked-by: Eric DumazetWhere apparently I forgot to add error handling to the path where we create
a new network device in a new network namespace, and pass in an invalid pid.Reported-by: Ed Swierk
Signed-off-by: "Eric W. Biederman"
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 01e05e9a90b8f4c3997ae0537e87720eb475e532 upstream.
The wake_up_process() call in ptrace_detach() is spurious and not
interlocked with the tracee state. IOW, the tracee could be running or
sleeping in any place in the kernel by the time wake_up_process() is
called. This can lead to the tracee waking up unexpectedly which can be
dangerous.The wake_up is spurious and should be removed but for now reduce its
toxicity by only waking up if the tracee is in TRACED or STOPPED state.This bug can possibly be used as an attack vector. I don't think it
will take too much effort to come up with an attack which triggers oops
somewhere. Most sleeps are wrapped in condition test loops and should
be safe but we have quite a number of places where sleep and wakeup
conditions are expected to be interlocked. Although the window of
opportunity is tiny, ptrace can be used by non-privileged users and with
some loading the window can definitely be extended and exploited.Signed-off-by: Tejun Heo
Acked-by: Roland McGrath
Acked-by: Oleg Nesterov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit d0694e2aeb815042aa0f3e5036728b3db4446f1d upstream.
Unbreak Billionton CF bluetooth card. This actually fixes a regression
on zaurus.Signed-off-by: Pavel Machek
Signed-off-by: Greg Kroah-Hartman -
commit 96a3e79edff6f41b0f115a82f1a39d66218077a7 upstream.
Added 0x0307 device id to support Motorola cables to the pl2303 usb
serial driver. This cable has a modified chip that is a pl2303, but
declares itself as 0307. Fixed by adding the right device id to the
supported devices list, assigning it the code labeled
PL2303_PRODUCT_ID_MOTOROLA.Signed-off-by: Dario Lombardo
Signed-off-by: Greg Kroah-Hartman -
commit 2770c5ea501be69989a7acf54ec4cb3554c47191 upstream.
The outvq needs to be woken up on host notifications so that buffers
consumed by the host can be reclaimed, outvq freed, and application
writes may proceed again.The need for this is now finally noticed when I have qemu patches ready
to use nonblocking IO and flow control.CC: Hans de Goede
Signed-off-by: Amit Shah
Signed-off-by: Rusty Russell
Acked-by: Hans de Goede
Signed-off-by: Greg Kroah-Hartman -
commit 3e9d08ec0a68f6faf718d5a7e050fe5ca0ba004f upstream.
Under harsh testing conditions, including low memory, the guest would
stop receiving packets. With this patch applied we no longer see any
problems in the driver while performing these tests for extended periods
of time.Make sure napi is scheduled subsequent to each napi_enable.
Signed-off-by: Bruce Rogers
Signed-off-by: Olaf Kirch
Signed-off-by: Rusty Russell
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 7f94de483f4e37e14d646ad6e85a3c82f66fb487 upstream.
Due to the different routing for AIF1 and AIF2 we weren't using a
single widget to represent the ADCDAT signal. For consistency add
one.Signed-off-by: Mark Brown
Acked-by: Liam Girdwood
Signed-off-by: Greg Kroah-Hartman -
commit 78b3fb46753872fc79bffecc8d50355a8622b39b upstream.
fix wrong value in wm8994_set_tristate func. when updating reg bits,
it should use "value", not "reg".Signed-off-by: Qiao Zhou
Acked-by: Liam Girdwood
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 20a4e7fc7e213365ea3771d7bf1e10a6bab853be upstream.
The DC servo codes are actually signed numbers so need to be treated as
such.Signed-off-by: Mark Brown
Acked-by: Liam Girdwood
Signed-off-by: Greg Kroah-Hartman
