aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2012-01-26ipv6: Fix ip_gre lockless xmits.Willem de Bruijn1-0/+4
Tunnel devices set NETIF_F_LLTX to bypass HARD_TX_LOCK. Sit and ipip set this unconditionally in ops->setup, but gre enables it conditionally after parameter passing in ops->newlink. This is not called during tunnel setup as below, however, so GRE tunnels are still taking the lock. modprobe ip_gre ip tunnel add test0 mode gre remote 10.5.1.1 dev lo ip link set test0 up ip addr add 10.6.0.1 dev test0 # cat /sys/class/net/test0/features # $DIR/test_tunnel_xmit 10 10.5.2.1 ip route add 10.5.2.0/24 dev test0 ip tunnel del test0 The newlink callback is only called in rtnl_netlink, and only if the device is new, as it calls register_netdevice internally. Gre tunnels are created at 'ip tunnel add' with ioctl SIOCADDTUNNEL, which calls ipgre_tunnel_locate, which calls register_netdev. rtnl_newlink is called at 'ip link set', but skips ops->newlink and the device is up with locking still enabled. The equivalent ipip tunnel works fine, btw (just substitute 'method gre' for 'method ipip'). On kernels before /sys/class/net/*/features was removed [1], the first commented out line returns 0x6000 with method gre, which indicates that NETIF_F_LLTX (0x1000) is not set. With ipip, it reports 0x7000. This test cannot be used on recent kernels where the sysfs file is removed (and ETHTOOL_GFEATURES does not currently work for tunnel devices, because they lack dev->ethtool_ops). The second commented out line calls a simple transmission test [2] that sends on 24 cores at maximum rate. Results of a single run: ipip: 19,372,306 gre before patch: 4,839,753 gre after patch: 19,133,873 This patch replicates the condition check in ipgre_newlink to ipgre_tunnel_locate. It works for me, both with oseq on and off. This is the first time I looked at rtnetlink and iproute2 code, though, so someone more knowledgeable should probably check the patch. Thanks. The tail of both functions is now identical, by the way. To avoid code duplication, I'll be happy to rework this and merge the two. [1] http://patchwork.ozlabs.org/patch/104610/ [2] http://kernel.googlecode.com/files/xmit_udp_parallel.c Signed-off-by: Willem de Bruijn <[email protected]> Acked-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-01-26Merge branch 'sa11x0-mcp-fixes' into fixesRussell King37-509/+596
2012-01-26Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds7-6/+30
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/microcode_amd: Add support for CPU family specific container files x86/amd: Add missing feature flag for fam15h models 10h-1fh processors x86/boot-image: Don't leak phdrs in arch/x86/boot/compressed/misc.c::Parse_elf() x86/numachip: Drop unnecessary conflict with EDAC x86/uv: Fix uninitialized spinlocks x86/uv: Fix uv_gpa_to_soc_phys_ram() shift
2012-01-26Merge branch 'perf-urgent-for-linus' of ↵Linus Torvalds2-3/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf: Call perf_cgroup_event_time() directly perf: Don't call release_callchain_buffers() if allocation fails
2012-01-26Merge branch 'core-urgent-for-linus' of ↵Linus Torvalds3-7/+10
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip * 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: rcu: Add missing __cpuinit annotation in rcutorture code sched: Add "const" to is_idle_task() parameter rcu: Make rcutorture bool parameters really bool (core code) memblock: Fix alloc failure due to dumb underflow protection in memblock_find_in_range_node()
2012-01-26Merge branch 'for-linus' of ↵Linus Torvalds9-82/+56
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k: m68k: Fix assembler constraint to prevent overeager gcc optimisation mac_esp: rename irq mac_scsi: dont enable mac_scsi irq before requesting it macfb: fix black and white modes m68k/irq: Remove obsolete IRQ_FLG_* definitions Fix up trivial conflict in arch/m68k/kernel/process_mm.c as per Geert.
2012-01-26bugs, x86: Fix printk levels for panic, softlockups and stack dumpsPrarit Bhargava5-8/+9
rsyslog will display KERN_EMERG messages on a connected terminal. However, these messages are useless/undecipherable for a general user. For example, after a softlockup we get: Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ... kernel:Stack: Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ... kernel:Call Trace: Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ... kernel:Code: ff ff a8 08 75 25 31 d2 48 8d 86 38 e0 ff ff 48 89 d1 0f 01 c8 0f ae f0 48 8b 86 38 e0 ff ff a8 08 75 08 b1 01 4c 89 e0 0f 01 c9 <e8> ea 69 dd ff 4c 29 e8 48 89 c7 e8 0f bc da ff 49 89 c4 49 89 This happens because the printk levels for these messages are incorrect. Only an informational message should be displayed on a terminal. I modified the printk levels for various messages in the kernel and tested the output by using the drivers/misc/lkdtm.c kernel modules (ie, softlockups, panics, hard lockups, etc.) and confirmed that the console output was still the same and that the output to the terminals was correct. For example, in the case of a softlockup we now see the much more informative: Message from syslogd@intel-s3e37-04 at Jan 25 10:18:06 ... BUG: soft lockup - CPU4 stuck for 60s! instead of the above confusing messages. AFAICT, the messages no longer have to be KERN_EMERG. In the most important case of a panic we set console_verbose(). As for the other less severe cases the correct data is output to the console and /var/log/messages. Successfully tested by me using the drivers/misc/lkdtm.c module. Signed-off-by: Prarit Bhargava <[email protected]> Cc: [email protected] Cc: Linus Torvalds <[email protected]> Cc: Andrew Morton <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2012-01-26x86-64: Handle byte-wise tail copying in memcpy() without a loopJan Beulich1-9/+10
While hard to measure, reducing the number of possibly/likely mis-predicted branches can generally be expected to be slightly better. Other than apparent at the first glance, this also doesn't grow the function size (the alignment gap to the next function just gets smaller). Signed-off-by: Jan Beulich <[email protected]> Cc: Linus Torvalds <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2012-01-26x86-64: Fix memcpy() to support sizes of 4Gb and aboveJan Beulich1-15/+10
While currently there doesn't appear to be any reachable in-tree case where such large memory blocks may be passed to memcpy(), we already had hit the problem in our Xen kernels. Just like done recently for mmeset(), rather than working around it, prevent others from falling into the same trap by fixing this long standing limitation. Signed-off-by: Jan Beulich <[email protected]> Cc: Linus Torvalds <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2012-01-26x86: Properly parenthesize cmpxchg() macro argumentsJan Beulich1-3/+3
Quite oddly, all of the arguments passed through from the top level macros to the second level which didn't need parentheses had them, while the only expression (involving a parameter) needing them didn't. Very recently I got bitten by the lack thereof when using something like "array + index" for the first operand, with "array" being an array more narrow than int. Signed-off-by: Jan Beulich <[email protected]> Cc: Linus Torvalds <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2012-01-26Btrfs: advance window_start if we're using a bitmapJosef Bacik1-0/+1
If we span a long area in a bitmap we could end up taking a lot of time searching to the next free area if we're searching from the original window_start, so advance window_start in order to make sure we don't do any superficial searching. Thanks, Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2012-01-26btrfs: mask out gfp flags in releasepageDavid Sterba1-0/+7
btree_releasepage is a callback and can be passed unknown gfp flags and then they may end up in kmem_cache_alloc called from alloc_extent_state, slab allocator will BUG_ON when there is HIGHMEM or DMA32 flag set. This may happen when btrfs is mounted from a loop device, which masks out __GFP_IO flag. The check in try_release_extent_state 3399 if ((mask & GFP_NOFS) == GFP_NOFS) 3400 mask = GFP_NOFS; will not work and passes unfiltered flags further resulting in crash at mm/slab.c:2963 [<000000000024ae4c>] cache_alloc_refill+0x3b4/0x5c8 [<000000000024c810>] kmem_cache_alloc+0x204/0x294 [<00000000001fd3c2>] mempool_alloc+0x52/0x170 [<000003c000ced0b0>] alloc_extent_state+0x40/0xd4 [btrfs] [<000003c000cee5ae>] __clear_extent_bit+0x38a/0x4cc [btrfs] [<000003c000cee78c>] try_release_extent_state+0x9c/0xd4 [btrfs] [<000003c000cc4c66>] btree_releasepage+0x7e/0xd0 [btrfs] [<0000000000210d84>] shrink_page_list+0x6a0/0x724 [<0000000000211394>] shrink_inactive_list+0x230/0x578 [<0000000000211bb8>] shrink_list+0x6c/0x120 [<0000000000211e4e>] shrink_zone+0x1e2/0x228 [<0000000000211f24>] shrink_zones+0x90/0x254 [<0000000000213410>] do_try_to_free_pages+0xac/0x420 [<0000000000213ae0>] try_to_free_pages+0x13c/0x1b0 [<0000000000204e6c>] __alloc_pages_nodemask+0x5b4/0x9a8 [<00000000001fb04a>] grab_cache_page_write_begin+0x7e/0xe8 Signed-off-by: David Sterba <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2012-01-26Btrfs: fix enospc error caused by wrong checks of the chunkMiao Xie1-22/+27
When we did sysbench test for inline files, enospc error happened easily though there was lots of free disk space which could be allocated for new chunks. Reproduce steps: # mkfs.btrfs -b $((2 * 1024 * 1024 * 1024)) <test partition> # mount <test partition> /mnt # ulimit -n 102400 # cd /mnt # sysbench --num-threads=1 --test=fileio --file-num=81920 \ > --file-total-size=80M --file-block-size=1K --file-io-mode=sync \ > --file-test-mode=seqwr prepare # sysbench --num-threads=1 --test=fileio --file-num=81920 \ > --file-total-size=80M --file-block-size=1K --file-io-mode=sync \ > --file-test-mode=seqwr run <soon later, BUG_ON() was triggered by enospc error> The reason of this bug is: Now, we can reserve space which is larger than the free space in the chunks if we have enough free disk space which can be used for new chunks. By this way, the space allocator should allocate a new chunk by force if there is no free space in the free space cache. But there are two wrong checks which break this operation. One is if (ret == -ENOSPC && num_bytes > min_alloc_size) in btrfs_reserve_extent(), it is wrong, we should try to allocate a new chunk even we fail to allocate free space by minimum allocable size. The other is if (space_info->force_alloc) force = space_info->force_alloc; in do_chunk_alloc(). It makes the allocator ignore CHUNK_ALLOC_FORCE If someone sets ->force_alloc to CHUNK_ALLOC_LIMITED, and makes the enospc error happen. Fix these two wrong checks. Especially the second one, we fix it by changing the value of CHUNK_ALLOC_LIMITED and CHUNK_ALLOC_FORCE, and make CHUNK_ALLOC_FORCE greater than CHUNK_ALLOC_LIMITED since CHUNK_ALLOC_FORCE has higher priority. And if the value which is passed in by the caller is greater than ->force_alloc, use the passed value. Signed-off-by: Miao Xie <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2012-01-26Btrfs: do not defrag a file partiallyLiu Bo1-1/+1
xfstests 218 complains that btrfs defrags a file partially: After: 1 Write backwards sync, but contiguous - should defrag to 1 extent Before: 10 -After: 1 +After: 2 To fix this, we need to set max_to_defrag count properly. Signed-off-by: Liu Bo <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2012-01-26Btrfs: fix warning for 32-bit build of fs/btrfs/check-integrity.cStefan Behrens1-5/+6
There have been 4 warnings on 32-bit build, they are herewith fixed. Signed-off-by: Stefan Behrens <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2012-01-26Btrfs: use cluster->window_start when allocating from a cluster bitmapJosef Bacik1-1/+1
We specifically set window_start in the cluster struct to indicate where the cluster starts in a bitmap, but we've been using min_start to indicate where we're searching from. This is usually the start of the blockgroup, so essentially means we're constantly searching from the start of any bitmap we find, which completely negates all the trouble we go to in order to setup a cluster. So start using window_start to make sure we actually use the area we found. Thanks, Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2012-01-26Btrfs: Check for NULL page in extent_range_uptodateMitch Harder1-0/+2
A user has encountered a NULL pointer kernel oops in btrfs when encountering media errors. The problem has been identified as an unhandled NULL pointer returned from find_get_page(). This modification simply checks for a NULL page, and returns with an error if found (the extent_range_uptodate() function returns 1 on errors). After testing this patch, the user reported that the error with the NULL pointer oops was solved. However, there is still a remaining problem with a thread becoming stuck in wait_on_page_locked(page) in the read_extent_buffer_pages(...) function in extent_io.c for (i = start_i; i < num_pages; i++) { page = extent_buffer_page(eb, i); wait_on_page_locked(page); if (!PageUptodate(page)) ret = -EIO; } This patch leaves the issue with the locked page yet to be resolved. Signed-off-by: Mitch Harder <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2012-01-26btrfs: Fix busyloops in transaction waiting codeJan Kara1-2/+4
wait_log_commit() and wait_for_writer() were using slightly different conditions for deciding whether they should call schedule() and whether they should continue in the wait loop. Thus it could happen that we busylooped when the first condition was not true while the second one was. That is burning CPU cycles needlessly and is deadly on UP machines... Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2012-01-26Btrfs: make sure a bitmap has enough bytesJosef Bacik1-1/+1
We have only been checking for min_bytes available in bitmap entries, but we won't successfully setup a bitmap cluster unless it has at least bytes in the bitmap, so in the common case min_bytes is 4k and we want something like 2MB, so if there are a bunch of bitmap entries with less than 2mb's in them, we'll search all them anyway, which is suboptimal. Fix this check. Thanks, Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2012-01-26Btrfs: fix uninit warning in backref.cJan Schmidt1-2/+2
Added initialization with the declaration of ret. It isn't set later on the switch-default branch (which should never be taken). Signed-off-by: Jan Schmidt <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2012-01-26uwb & wusb: fix kconfig errorRandy Dunlap1-1/+1
Fix UWB/WUSB kconfig error by changing 'select' to 'depends on'. drivers/usb/wusbcore/Kconfig:4:error: recursive dependency detected! drivers/usb/wusbcore/Kconfig:4: symbol USB_WUSB is selected by USB_HWA_HCD drivers/usb/host/Kconfig:559: symbol USB_HWA_HCD depends on UWB drivers/uwb/Kconfig:5: symbol UWB is selected by USB_WUSB Signed-off-by: Randy Dunlap <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-01-26USB: Realtek cr: fix autopm scheduling while atomicStanislaw Gruszka1-1/+1
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=784345 Reported-by: Francis Moreau <[email protected]> Reported-and-tested-by: Christian D <[email protected]> Reported-and-tested-by: Jimmy Dorff <[email protected]> Reported-and-tested-by: [email protected] Cc: [email protected] # 3.2+ Signed-off-by: Stanislaw Gruszka <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-01-26USB: ftdi_sio: Add more identifiersAlan Cox2-0/+7
0x04d8, 0x000a: Hornby Elite Signed-off-by: Alan Cox <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-01-26serial: Kill off Moorestown codeAlan Cox3-354/+0
All production devices operate in the Oaktrail configuration with legacy PC elements present and an ACPI BIOS. Continue stripping out the Moorestown elements from the tree leaving Medfield. Signed-off-by: Alan Cox <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-01-26Revert "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA mode"Greg Kroah-Hartman1-31/+4
This reverts commit 0a697b22252c9d7208b5fb3e9fbd124dd229f1d2 as Paul wants to rework it. Cc: Paul Walmsley <[email protected]> Cc: Tomi Valkeinen <[email protected]> Cc: Govindraj Raja <[email protected]> Cc: Kevin Hilman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-01-26Revert "tty: serial: OMAP: transmit FIFO threshold interrupts don't wake the ↵Greg Kroah-Hartman2-51/+1
chip" This reverts commit 43cf7c0bebf50d0b68aa42ae6d24cf08e3f24823 as Paul wants to redo it. Cc: Paul Walmsley <[email protected]> Cc: Tomi Valkeinen <[email protected]> Cc: Govindraj Raja <[email protected]> Cc: Kevin Hilman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-01-26[media] imon: don't wedge hardware after early callbacksJarod Wilson1-4/+22
This patch is just a minor update to one titled "imon: Input from ffdc device type ignored" from Corinna Vinschen. An earlier patch to prevent an oops when we got early callbacks also has the nasty side-effect of wedging imon hardware, as we don't acknowledge the urb. Rework the check slightly here to bypass processing the packet, as the driver isn't yet fully initialized, but still acknowlege the urb and submit a new rx_urb. Do this for both interfaces -- irrelevant for ffdc hardware, but relevant for newer hardware, though newer hardware doesn't spew the constant stream of data as soon as the hardware is initialized like the older ffdc devices, so they'd be less likely to trigger this anyway... Tested with both an ffdc device and an 0042 device. Reported-by: Corinna Vinschen <[email protected]> Signed-off-by: Jarod Wilson <[email protected]> CC: [email protected] Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2012-01-26ASoC: wm_hubs: Enable line out VMID buffer for single ended line outputsMark Brown1-0/+6
For optimal performance the single ended line outputs require that the line output VMID buffer be enabled. Signed-off-by: Mark Brown <[email protected]> Cc: [email protected]
2012-01-26xen-netfront: correct MAX_TX_TARGET calculation.Wei Liu1-1/+1
Signed-off-by: Wei Liu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-01-26sched/nohz: Fix nohz cpu idle load balancing state with cpu hotplugSuresh Siddha1-5/+29
With the recent nohz scheduler changes, rq's nohz flag 'NOHZ_TICK_STOPPED' and its associated state doesn't get cleared immediately after the cpu exits idle. This gets cleared as part of the next tick seen on that cpu. For the cpu offline support, we need to clear this state manually. Fix it by registering a cpu notifier, which clears the nohz idle load balance state for this rq explicitly during the CPU_DYING notification. There won't be any nohz updates for that cpu, after the CPU_DYING notification. But lets be extra paranoid and skip updating the nohz state in the select_nohz_load_balancer() if the cpu is not in active state anymore. Reported-by: Srivatsa S. Bhat <[email protected]> Reviewed-and-tested-by: Srivatsa S. Bhat <[email protected]> Tested-by: Sergey Senozhatsky <[email protected]> Signed-off-by: Suresh Siddha <[email protected]> Signed-off-by: Peter Zijlstra <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2012-01-26sched/s390: Fix compile error in sched/core.cChristian Borntraeger1-0/+1
Commit 029632fbb7b7c9d85063cc9eb470de6c54873df3 ("sched: Make separate sched*.c translation units") removed the include of asm/mutex.h from sched.c. This breaks the combination of: CONFIG_MUTEX_SPIN_ON_OWNER=yes CONFIG_HAVE_ARCH_MUTEX_CPU_RELAX=yes like s390 without mutex debugging: CC kernel/sched/core.o kernel/sched/core.c: In function ‘mutex_spin_on_owner’: kernel/sched/core.c:3287: error: implicit declaration of function ‘arch_mutex_cpu_relax’ Lets re-add the include to kernel/sched/core.c Signed-off-by: Christian Borntraeger <[email protected]> Signed-off-by: Peter Zijlstra <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2012-01-26sched: Fix rq->nr_uninterruptible update racePeter Zijlstra1-12/+6
KOSAKI Motohiro noticed the following race: > CPU0 CPU1 > -------------------------------------------------------- > deactivate_task() > task->state = TASK_UNINTERRUPTIBLE; > activate_task() > rq->nr_uninterruptible--; > > schedule() > deactivate_task() > rq->nr_uninterruptible++; > Kosaki-San's scenario is possible when CPU0 runs __sched_setscheduler() against CPU1's current @task. __sched_setscheduler() does a dequeue/enqueue in order to move the task to its new queue (position) to reflect the newly provided scheduling parameters. However it should be completely invariant to nr_uninterruptible accounting, sched_setscheduler() doesn't affect readyness to run, merely policy on when to run. So convert the inappropriate activate/deactivate_task usage to enqueue/dequeue_task, which avoids the nr_uninterruptible accounting. Also convert the two other sites: __migrate_task() and normalize_task() that still use activate/deactivate_task. These sites aren't really a problem since __migrate_task() will only be called on non-running task (and therefore are immume to the described problem) and normalize_task() isn't ever used on regular systems. Also remove the comments from activate/deactivate_task since they're misleading at best. Reported-by: KOSAKI Motohiro <[email protected]> Signed-off-by: Peter Zijlstra <[email protected]> Link: http://lkml.kernel.org/r/1327486224.2614.45.camel@laptop Signed-off-by: Ingo Molnar <[email protected]>
2012-01-26agp: fix scratch page cleanupMichal Kubecek1-6/+6
In error cleanup of agp_backend_initialize() and in agp_backend_cleanup(), agp_destroy_page() is passed virtual address of the scratch page. This leads to a kernel warning if the initialization fails (or upon regular cleanup) as pointer to struct page should be passed instead. Signed-off-by: Michal Kubecek <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2012-01-26netns: fix net_alloc_generic()Eric Dumazet1-15/+16
When a new net namespace is created, we should attach to it a "struct net_generic" with enough slots (even empty), or we can hit the following BUG_ON() : [ 200.752016] kernel BUG at include/net/netns/generic.h:40! ... [ 200.752016] [<ffffffff825c3cea>] ? get_cfcnfg+0x3a/0x180 [ 200.752016] [<ffffffff821cf0b0>] ? lockdep_rtnl_is_held+0x10/0x20 [ 200.752016] [<ffffffff825c41be>] caif_device_notify+0x2e/0x530 [ 200.752016] [<ffffffff810d61b7>] notifier_call_chain+0x67/0x110 [ 200.752016] [<ffffffff810d67c1>] raw_notifier_call_chain+0x11/0x20 [ 200.752016] [<ffffffff821bae82>] call_netdevice_notifiers+0x32/0x60 [ 200.752016] [<ffffffff821c2b26>] register_netdevice+0x196/0x300 [ 200.752016] [<ffffffff821c2ca9>] register_netdev+0x19/0x30 [ 200.752016] [<ffffffff81c1c67a>] loopback_net_init+0x4a/0xa0 [ 200.752016] [<ffffffff821b5e62>] ops_init+0x42/0x180 [ 200.752016] [<ffffffff821b600b>] setup_net+0x6b/0x100 [ 200.752016] [<ffffffff821b6466>] copy_net_ns+0x86/0x110 [ 200.752016] [<ffffffff810d5789>] create_new_namespaces+0xd9/0x190 net_alloc_generic() should take into account the maximum index into the ptr array, as a subsystem might use net_generic() anytime. This also reduces number of reallocations in net_assign_generic() Reported-by: Sasha Levin <[email protected]> Tested-by: Sasha Levin <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Cc: Sjur Brændeland <[email protected]> Cc: Eric W. Biederman <[email protected]> Cc: Pavel Emelyanov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-01-26Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~keithp/linux ↵Dave Airlie14-199/+167
into drm-fixes * 'drm-intel-fixes' of git://people.freedesktop.org/~keithp/linux: (24 commits) drm/i915: fixup forcewake spinlock fallout in drpc debugfs function drm/i915: debugfs: show semaphore registers also on gen7 drm/i915: allow userspace forcewake references also on gen7 drm/i915: Re-enable gen7 RC6 and GPU turbo after resume. drm/i915: Correct debugfs printout for RC1e. Revert "drm/i915: Work around gen7 BLT ring synchronization issues." drm/i915: rip out the HWSTAM missed irq workaround drm/i915: paper over missed irq issues with force wake voodoo drm/i915: Hold gt_lock across forcewake register reads drm/i915: Hold gt_lock during reset drm/i915: Move reset forcewake processing to gen6_do_reset drm/i915: protect force_wake_(get|put) with the gt_lock drm/i915: convert force_wake_get to func pointer in the gpu reset code drm/i915: sprite init failure on pre-SNB is not a failure drm/i915: VBT Parser cleanup for eDP block drm/i915: mask transcoder select bits before setting them on LVDS drm/i915: Add Clientron E830 to the ignore LVDS list CHROMIUM: i915: Add DMI override to skip CRT initialization on ZGB drm/i915: handle 3rd pipe drm/i915: simplify pipe checking ...
2012-01-26ALSA: hda - Fix silent output on Haier W18 laptopTakashi Iwai1-0/+1
The very same problem is seen on Haier W18 laptop with ALC861 as seen on ASUS A6Rp, which was fixed by the commit 3b25eb69. Now we just need to add a new SSID entry pointing to the same fixup. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42656 Cc: <[email protected]> [v3.2+] Signed-off-by: Takashi Iwai <[email protected]>
2012-01-26pinctrl: add checks for empty function namesTony Lindgren5-24/+41
This is needed as otherwise we can get the following when dealing with buggy data in a pinmux driver for pinmux_search_function: Unable to handle kernel NULL pointer dereference at virtual address 00000000 ... PC is at strcmp+0xc/0x34 LR is at pinmux_get+0x350/0x8f4 ... As we need pctldev initialized to call ops->list_functions, let's initialize it before check_ops calls and pass the pctldev to the check_ops functions. Do this for both pinmux and pinconf check_ops functions. Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2012-01-26pinctrl: fix pinmux_hog_maps when ctrl_dev_name is not setTony Lindgren1-3/+6
The ctrl_dev_name is optional for struct pinmux_map assuming that ctrl_dev is set. Without this patch we can get: Unable to handle kernel NULL pointer dereference at virtual address 00000000 ... (pinmux_hog_maps+0xa4/0x20c) (pinctrl_register+0x2a4/0x378) ... Fix this by adding adding a test for map->ctrl_dev. Additionally move the test for map->ctrl_dev earlier to optimize out the loop a bit. Signed-off-by: Tony Lindgren <[email protected]> Acked-by: Stephen Warren <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2012-01-26pinctrl: fix some pinmux typosTony Lindgren2-8/+3
Fix some pinmux typos so implementing pinmux drivers is a bit easier. Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2012-01-26arch/arm/mach-imx/mach-mx53_ard.c: add missing iounmapJulia Lawall1-1/+3
Add missing iounmap in error handling code, in a case where the function already preforms iounmap on some other execution path. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression e; statement S,S1; int ret; @@ e = \(ioremap\|ioremap_nocache\)(...) ... when != iounmap(e) if (<+...e...+>) S ... when any when != iounmap(e) *if (...) { ... when != iounmap(e) return ...; } ... when any iounmap(e); // </smpl> Signed-off-by: Julia Lawall <[email protected]> Signed-off-by: Sascha Hauer <[email protected]>
2012-01-26ARM: imx: iomux-v1.h: Fix build error due to __init annotationFabio Estevam1-1/+1
Fix the following build error found when building imx_v4_v5_defconfig: CC arch/arm/mach-imx/mach-imx27ipcam.o In file included from arch/arm/plat-mxc/include/mach/iomux-mx27.h:23, from arch/arm/mach-imx/mach-imx27ipcam.c:22: arch/arm/plat-mxc/include/mach/iomux-v1.h:99: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'imx_iomuxv1_init' Signed-off-by: Fabio Estevam <[email protected]> Signed-off-by: Sascha Hauer <[email protected]>
2012-01-26OMAPDSS: HDMI: PHY burnout fixTomi Valkeinen6-4/+86
A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board if the HDMI PHY is kept powered on when the cable is not connected. This patch solves the problem by adding hot-plug-detection into the HDMI IP driver. This is not a real HPD support in the sense that nobody else than the IP driver gets to know about the HPD events, but is only meant to fix the HW bug. The strategy is simple: If the display device is turned off by the user, the PHY power is set to OFF. When the display device is turned on by the user, the PHY power is set either to LDOON or TXON, depending on whether the HDMI cable is connected. The reason to avoid PHY OFF when the display device is on, but the cable is disconnected, is that when the PHY is turned OFF, the HDMI IP is not "ticking" and thus the DISPC does not receive pixel clock from the HDMI IP. This would, for example, prevent any VSYNCs from happening, and would thus affect the users of omapdss. By using LDOON when the cable is disconnected we'll avoid the HW bug, but keep the HDMI working as usual from the user's point of view. Signed-off-by: Tomi Valkeinen <[email protected]>
2012-01-26OMAP: 4430SDP/Panda: add HDMI HPD gpioTomi Valkeinen2-0/+6
Both Panda and 4430SDP use GPIO 63 as HDMI hot-plug-detect. Configure this GPIO in the board files. Signed-off-by: Tomi Valkeinen <[email protected]> Acked-by: Tony Lindgren <[email protected]>
2012-01-26OMAP: 4430SDP/Panda: setup HDMI GPIO muxesTomi Valkeinen2-0/+6
The HDMI GPIO pins LS_OE and CT_CP_HPD are not currently configured. This patch configures them as output pins. Signed-off-by: Tomi Valkeinen <[email protected]> Acked-by: Tony Lindgren <[email protected]>
2012-01-26OMAPDSS: remove wrong HDMI HPD muxingTomi Valkeinen1-4/+0
"hdmi_hpd" pin is muxed to INPUT and PULLUP, but the pin is not currently used, and in the future when it is used, the pin is used as a GPIO and is board specific, not an OMAP4 wide thing. So remove the muxing for now. Signed-off-by: Tomi Valkeinen <[email protected]> Acked-by: Tony Lindgren <[email protected]>
2012-01-26OMAP: 4430SDP/Panda: rename HPD GPIO to CT_CP_HPDTomi Valkeinen2-4/+4
The GPIO 60 on 4430sdp and Panda is not HPD GPIO, as currently marked in the board files, but CT_CP_HPD, which is used to enable/disable HPD functionality. This patch renames the GPIO. Signed-off-by: Tomi Valkeinen <[email protected]> Acked-by: Tony Lindgren <[email protected]>
2012-01-26OMAP: 4430SDP/Panda: use gpio_free_array to free HDMI gpiosTomi Valkeinen2-4/+2
Instead of freeing the GPIOs individually, use gpio_free_array(). Signed-off-by: Tomi Valkeinen <[email protected]> Acked-by: Tony Lindgren <[email protected]>
2012-01-26OMAPDSS: use sync versions of pm_runtime_putTomi Valkeinen6-6/+6
omapdss doesn't work properly on system suspend. The problem seems to be the fact that omapdss uses pm_runtime_put() functions when turning off the hardware, and when system suspend is in process only sync versions are allowed. Using non-sync versions normally and sync versions when suspending would need rather ugly hacks to convey the information of suspending/not-suspending to different functions. Optimally the driver wouldn't even need to care about this, and the PM layer would handle syncing when suspend is in process. This patch changes all omapdss's pm_runtime_put calls to pm_runtime_put_sync. This fixes the suspend problem, and probably the performance penalty of always using sync versions is negligible. Signed-off-by: Tomi Valkeinen <[email protected]> Acked-by: Kevin Hilman <[email protected]>
2012-01-26x86/microcode_amd: Add support for CPU family specific container filesAndreas Herrmann1-2/+22
We've decided to provide CPU family specific container files (starting with CPU family 15h). E.g. for family 15h we have to load microcode_amd_fam15h.bin instead of microcode_amd.bin Rationale is that starting with family 15h patch size is larger than 2KB which was hard coded as maximum patch size in various microcode loaders (not just Linux). Container files which include patches larger than 2KB cause different kinds of trouble with such old patch loaders. Thus we have to ensure that the default container file provides only patches with size less than 2KB. Signed-off-by: Andreas Herrmann <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: <[email protected]> Link: http://lkml.kernel.org/r/[email protected] [ documented the naming convention and tidied the code a bit. ] Signed-off-by: Ingo Molnar <[email protected]>
2012-01-26x86/amd: Add missing feature flag for fam15h models 10h-1fh processorsAndreas Herrmann1-0/+1
That is the last one missing for those CPUs. Others were recently added with commits fb215366b3c7320ac25dca766a0152df16534932 (KVM: expose latest Intel cpu new features (BMI1/BMI2/FMA/AVX2) to guest) and commit 969df4b82904a30fef19a67398a0c854d223ea67 (x86: Report cpb and eff_freq_ro flags correctly) Signed-off-by: Andreas Herrmann <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.