commit f453538a1f5b66168caf9c446c56375246b4ac29 Author: Ben Hutchings Date: Wed Apr 30 16:23:28 2014 +0100 Linux 3.2.58 commit 2e59f013993a74bf31366a59bcf36be830d0f058 Author: Ben Hutchings Date: Wed Apr 30 13:22:22 2014 +0100 Revert "isci: fix reset timeout handling" This reverts commit 584ec12265192bf49dfa270d517380f6723a6956, which was commit ddfadd7736b677de2d4ca2cd5b4b655368c85a7a upstream. It causes boot failure on 3.2 although no such problem occurs upstream. Reported-by: Ondrej Zary Signed-off-by: Ben Hutchings Acked-by: Dan Williams commit 53119558f7a2f8e6432e00d395748a431a0cb14e Author: Ben Hutchings Date: Mon Apr 28 02:04:30 2014 +0100 Revert "alpha: fix broken network checksum" This reverts commit b93b90ff7c50288d602108ae1a09673df3f799a8, which was commit 0ef38d70d4118b2ce1a538d14357be5ff9dc2bbd upstream. It was intended to fix a regression which never occurred in 3.2. commit 3d793c474f42b0443b7d13c851d8960de4485184 Author: Mikulas Patocka Date: Wed Dec 11 19:39:19 2013 -0500 powernow-k6: reorder frequencies commit 22c73795b101597051924556dce019385a1e2fa0 upstream. This patch reorders reported frequencies from the highest to the lowest, just like in other frequency drivers. Signed-off-by: Mikulas Patocka Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki [bwh: Backported to 3.2: cpu_frequency_table::driver_data is called index] Signed-off-by: Ben Hutchings commit 133eadd570837d44b8e9828f0189cb75dde9b7ac Author: Mikulas Patocka Date: Wed Dec 11 19:38:53 2013 -0500 powernow-k6: correctly initialize default parameters commit d82b922a4acc1781d368aceac2f9da43b038cab2 upstream. The powernow-k6 driver used to read the initial multiplier from the powernow register. However, there is a problem with this: * If there was a frequency transition before, the multiplier read from the register corresponds to the current multiplier. * If there was no frequency transition since reset, the field in the register always reads as zero, regardless of the current multiplier that is set using switches on the mainboard and that the CPU is running at. The zero value corresponds to multiplier 4.5, so as a consequence, the powernow-k6 driver always assumes multiplier 4.5. For example, if we have 550MHz CPU with bus frequency 100MHz and multiplier 5.5, the powernow-k6 driver thinks that the multiplier is 4.5 and bus frequency is 122MHz. The powernow-k6 driver then sets the multiplier to 4.5, underclocking the CPU to 450MHz, but reports the current frequency as 550MHz. There is no reliable way how to read the initial multiplier. I modified the driver so that it contains a table of known frequencies (based on parameters of existing CPUs and some common overclocking schemes) and sets the multiplier according to the frequency. If the frequency is unknown (because of unusual overclocking or underclocking), the user must supply the bus speed and maximum multiplier as module parameters. This patch should be backported to all stable kernels. If it doesn't apply cleanly, change it, or ask me to change it. Signed-off-by: Mikulas Patocka Signed-off-by: Rafael J. Wysocki [bwh: Backported to 3.2: - Adjust context - s/driver_data/index/] Signed-off-by: Ben Hutchings commit f5fe5bb9f7091f23f16c8cbcf2e8283fa42a5245 Author: Mikulas Patocka Date: Wed Dec 11 19:38:32 2013 -0500 powernow-k6: disable cache when changing frequency commit e20e1d0ac02308e2211306fc67abcd0b2668fb8b upstream. I found out that a system with k6-3+ processor is unstable during network server load. The system locks up or the network card stops receiving. The reason for the instability is the CPU frequency scaling. During frequency transition the processor is in "EPM Stop Grant" state. The documentation says that the processor doesn't respond to inquiry requests in this state. Consequently, coherency of processor caches and bus master devices is not maintained, causing the system instability. This patch flushes the cache during frequency transition. It fixes the instability. Other minor changes: * u64 invalue changed to unsigned long because the variable is 32-bit * move the logic to set the multiplier to a separate function powernow_k6_set_cpu_multiplier * preserve lower 5 bits of the powernow port instead of 4 (the voltage field has 5 bits) * mask interrupts when reading the multiplier, so that the port is not open during other activity (running other kernel code with the port open shouldn't cause any misbehavior, but we should better be safe and keep the port closed) This patch should be backported to all stable kernels. If it doesn't apply cleanly, change it, or ask me to change it. Signed-off-by: Mikulas Patocka Signed-off-by: Rafael J. Wysocki [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit a07089d78e0fa3ec170e7e9302484e11f246d713 Author: Paul Moore Date: Wed Mar 19 16:46:18 2014 -0400 selinux: correctly label /proc inodes in use before the policy is loaded commit f64410ec665479d7b4b77b7519e814253ed0f686 upstream. This patch is based on an earlier patch by Eric Paris, he describes the problem below: "If an inode is accessed before policy load it will get placed on a list of inodes to be initialized after policy load. After policy load we call inode_doinit() which calls inode_doinit_with_dentry() on all inodes accessed before policy load. In the case of inodes in procfs that means we'll end up at the bottom where it does: /* Default to the fs superblock SID. */ isec->sid = sbsec->sid; if ((sbsec->flags & SE_SBPROC) && !S_ISLNK(inode->i_mode)) { if (opt_dentry) { isec->sclass = inode_mode_to_security_class(...) rc = selinux_proc_get_sid(opt_dentry, isec->sclass, &sid); if (rc) goto out_unlock; isec->sid = sid; } } Since opt_dentry is null, we'll never call selinux_proc_get_sid() and will leave the inode labeled with the label on the superblock. I believe a fix would be to mimic the behavior of xattrs. Look for an alias of the inode. If it can't be found, just leave the inode uninitialized (and pick it up later) if it can be found, we should be able to call selinux_proc_get_sid() ..." On a system exhibiting this problem, you will notice a lot of files in /proc with the generic "proc_t" type (at least the ones that were accessed early in the boot), for example: # ls -Z /proc/sys/kernel/shmmax | awk '{ print $4 " " $5 }' system_u:object_r:proc_t:s0 /proc/sys/kernel/shmmax However, with this patch in place we see the expected result: # ls -Z /proc/sys/kernel/shmmax | awk '{ print $4 " " $5 }' system_u:object_r:sysctl_kernel_t:s0 /proc/sys/kernel/shmmax Cc: Eric Paris Signed-off-by: Paul Moore Acked-by: Eric Paris Signed-off-by: Ben Hutchings commit 24b528cb0652ac135a86ca1c54ecf7300c3a1c5b Author: Jiri Slaby Date: Mon Apr 14 09:46:50 2014 -0500 Char: ipmi_bt_sm, fix infinite loop commit a94cdd1f4d30f12904ab528152731fb13a812a16 upstream. In read_all_bytes, we do unsigned char i; ... bt->read_data[0] = BMC2HOST; bt->read_count = bt->read_data[0]; ... for (i = 1; i <= bt->read_count; i++) bt->read_data[i] = BMC2HOST; If bt->read_data[0] == bt->read_count == 255, we loop infinitely in the 'for' loop. Make 'i' an 'int' instead of 'char' to get rid of the overflow and finish the loop after 255 iterations every time. Signed-off-by: Jiri Slaby Reported-and-debugged-by: Rui Hui Dian Cc: Tomas Cech Cc: Corey Minyard Cc: Signed-off-by: Corey Minyard Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 683bce8d2ecebf16147103a49ad891191d390bd5 Author: Qiang Huang Date: Fri Apr 18 17:29:24 2014 +0800 drivers: hv: additional switch to use mb() instead of smp_mb() commit e4af376d04b0(drivers: hv: switch to use mb() instead of smp_mb()), the adjustment mistakenly dropped the change in hv_ringbuffer_read, so add it. Signed-off-by: Qiang Huang Signed-off-by: Ben Hutchings commit 6ff2fec9fc73d071d62460acea6c064105fd67e5 Author: Andy Grover Date: Fri Apr 4 16:44:37 2014 -0700 target/tcm_fc: Fix use-after-free of ft_tpg commit 2c42be2dd4f6586728dba5c4e197afd5cfaded78 upstream. ft_del_tpg checks tpg->tport is set before unlinking the tpg from the tport when the tpg is being removed. Set this pointer in ft_tport_create, or the unlinking won't happen in ft_del_tpg and tport->tpg will reference a deleted object. This patch sets tpg->tport in ft_tport_create, because that's what ft_del_tpg checks, and is the only way to get back to the tport to clear tport->tpg. The bug was occuring when: - lport created, tport (our per-lport, per-provider context) is allocated. tport->tpg = NULL - tpg created - a PRLI is received. ft_tport_create is called, tpg is found and tport->tpg is set - tpg removed. ft_tpg is freed in ft_del_tpg. Since tpg->tport was not set, tport->tpg is not cleared and points at freed memory - Future calls to ft_tport_create return tport via first conditional, instead of searching for new tpg by calling ft_lport_find_tpg. tport->tpg is still invalid, and will access freed memory. see https://bugzilla.redhat.com/show_bug.cgi?id=1071340 Signed-off-by: Andy Grover Signed-off-by: Nicholas Bellinger Signed-off-by: Ben Hutchings commit a862b5c4076b1ba4dd6c87aebac478853dc6db47 Author: H. Peter Anvin Date: Sun Mar 16 15:31:54 2014 -0700 x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels commit b3b42ac2cbae1f3cecbb6229964a4d48af31d382 upstream. The IRET instruction, when returning to a 16-bit segment, only restores the bottom 16 bits of the user space stack pointer. We have a software workaround for that ("espfix") for the 32-bit kernel, but it relies on a nonzero stack segment base which is not available in 32-bit mode. Since 16-bit support is somewhat crippled anyway on a 64-bit kernel (no V86 mode), and most (if not quite all) 64-bit processors support virtualization for the users who really need it, simply reject attempts at creating a 16-bit segment when running on top of a 64-bit kernel. Cc: Linus Torvalds Signed-off-by: H. Peter Anvin Link: http://lkml.kernel.org/n/tip-kicdm89kzw9lldryb1br9od0@git.kernel.org Signed-off-by: Ben Hutchings commit 68289dd32489599ba7f351a3e9ee6bbb36757bc8 Author: Rafał Miłecki Date: Sat Apr 5 18:08:25 2014 +0200 b43: Fix machine check error due to improper access of B43_MMIO_PSM_PHY_HDR commit 12cd43c6ed6da7bf7c5afbd74da6959cda6d056b upstream. Register B43_MMIO_PSM_PHY_HDR is 16 bit one, so accessing it with 32b functions isn't safe. On my machine it causes delayed (!) CPU exception: Disabling lock debugging due to kernel taint mce: [Hardware Error]: CPU 0: Machine Check Exception: 4 Bank 4: b200000000070f0f mce: [Hardware Error]: TSC 164083803dc mce: [Hardware Error]: PROCESSOR 2:20fc2 TIME 1396650505 SOCKET 0 APIC 0 microcode 0 mce: [Hardware Error]: Run the above through 'mcelog --ascii' mce: [Hardware Error]: Machine check: Processor context corrupt Kernel panic - not syncing: Fatal machine check on current CPU Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff) Signed-off-by: Rafał Miłecki Acked-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit 1f9df43033d35e170e869ccb442b3d37b291fe4e Author: Jens Axboe Date: Tue Apr 8 16:04:12 2014 -0700 lib/percpu_counter.c: fix bad percpu counter state during suspend commit e39435ce68bb4685288f78b1a7e24311f7ef939f upstream. I got a bug report yesterday from Laszlo Ersek in which he states that his kvm instance fails to suspend. Laszlo bisected it down to this commit 1cf7e9c68fe8 ("virtio_blk: blk-mq support") where virtio-blk is converted to use the blk-mq infrastructure. After digging a bit, it became clear that the issue was with the queue drain. blk-mq tracks queue usage in a percpu counter, which is incremented on request alloc and decremented when the request is freed. The initial hunt was for an inconsistency in blk-mq, but everything seemed fine. In fact, the counter only returned crazy values when suspend was in progress. When a CPU is unplugged, the percpu counters merges that CPU state with the general state. blk-mq takes care to register a hotcpu notifier with the appropriate priority, so we know it runs after the percpu counter notifier. However, the percpu counter notifier only merges the state when the CPU is fully gone. This leaves a state transition where the CPU going away is no longer in the online mask, yet it still holds private values. This means that in this state, percpu_counter_sum() returns invalid results, and the suspend then hangs waiting for abs(dead-cpu-value) requests to complete which of course will never happen. Fix this by clearing the state earlier, so we never have a case where the CPU isn't in online mask but still holds private state. This bug has been there since forever, I guess we don't have a lot of users where percpu counters needs to be reliable during the suspend cycle. Signed-off-by: Jens Axboe Reported-by: Laszlo Ersek Tested-by: Laszlo Ersek Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 2a803e14679269f4df4698aa5da94b3243d87af0 Author: Takashi Iwai Date: Tue Apr 8 16:58:34 2014 +0200 ALSA: ice1712: Fix boundary checks in PCM pointer ops commit 4f8e940095536bc002a81666a4107a581c84e9b9 upstream. PCM pointer callbacks in ice1712 driver check the buffer size boundary wrongly between bytes and frames. This leads to PCM core warnings like: snd_pcm_update_hw_ptr0: 105 callbacks suppressed ALSA pcm_lib.c:352 BUG: pcmC3D0c:0, pos = 5461, buffer size = 5461, period size = 2730 This patch fixes these checks to be placed after the proper unit conversions. Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit a817fbacc3dca3da46a486cbee77d384ac9f04af Author: Oleg Nesterov Date: Mon Apr 7 15:38:41 2014 -0700 wait: fix reparent_leader() vs EXIT_DEAD->EXIT_ZOMBIE race commit dfccbb5e49a621c1b21a62527d61fc4305617aca upstream. wait_task_zombie() first does EXIT_ZOMBIE->EXIT_DEAD transition and drops tasklist_lock. If this task is not the natural child and it is traced, we change its state back to EXIT_ZOMBIE for ->real_parent. The last transition is racy, this is even documented in 50b8d257486a "ptrace: partially fix the do_wait(WEXITED) vs EXIT_DEAD->EXIT_ZOMBIE race". wait_consider_task() tries to detect this transition and clear ->notask_error but we can't rely on ptrace_reparented(), debugger can exit and do ptrace_unlink() before its sub-thread sets EXIT_ZOMBIE. And there is another problem which were missed before: this transition can also race with reparent_leader() which doesn't reset >exit_signal if EXIT_DEAD, assuming that this task must be reaped by someone else. So the tracee can be re-parented with ->exit_signal != SIGCHLD, and if /sbin/init doesn't use __WALL it becomes unreapable. Change reparent_leader() to update ->exit_signal even if EXIT_DEAD. Note: this is the simple temporary hack for -stable, it doesn't try to solve all problems, it will be reverted by the next changes. Signed-off-by: Oleg Nesterov Reported-by: Jan Kratochvil Reported-by: Michal Schmidt Tested-by: Michal Schmidt Cc: Al Viro Cc: Lennart Poettering Cc: Roland McGrath Cc: Tejun Heo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 057d8772041e0e04c7297c56be1ca38e78044af8 Author: Mizuma, Masayoshi Date: Mon Apr 7 15:37:54 2014 -0700 mm: hugetlb: fix softlockup when a large number of hugepages are freed. commit 55f67141a8927b2be3e51840da37b8a2320143ed upstream. When I decrease the value of nr_hugepage in procfs a lot, softlockup happens. It is because there is no chance of context switch during this process. On the other hand, when I allocate a large number of hugepages, there is some chance of context switch. Hence softlockup doesn't happen during this process. So it's necessary to add the context switch in the freeing process as same as allocating process to avoid softlockup. When I freed 12 TB hugapages with kernel-2.6.32-358.el6, the freeing process occupied a CPU over 150 seconds and following softlockup message appeared twice or more. $ echo 6000000 > /proc/sys/vm/nr_hugepages $ cat /proc/sys/vm/nr_hugepages 6000000 $ grep ^Huge /proc/meminfo HugePages_Total: 6000000 HugePages_Free: 6000000 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB $ echo 0 > /proc/sys/vm/nr_hugepages BUG: soft lockup - CPU#16 stuck for 67s! [sh:12883] ... Pid: 12883, comm: sh Not tainted 2.6.32-358.el6.x86_64 #1 Call Trace: free_pool_huge_page+0xb8/0xd0 set_max_huge_pages+0x128/0x190 hugetlb_sysctl_handler_common+0x113/0x140 hugetlb_sysctl_handler+0x1e/0x20 proc_sys_call_handler+0x97/0xd0 proc_sys_write+0x14/0x20 vfs_write+0xb8/0x1a0 sys_write+0x51/0x90 __audit_syscall_exit+0x265/0x290 system_call_fastpath+0x16/0x1b I have not confirmed this problem with upstream kernels because I am not able to prepare the machine equipped with 12TB memory now. However I confirmed that the amount of decreasing hugepages was directly proportional to the amount of required time. I measured required times on a smaller machine. It showed 130-145 hugepages decreased in a millisecond. Amount of decreasing Required time Decreasing rate hugepages (msec) (pages/msec) ------------------------------------------------------------ 10,000 pages == 20GB 70 - 74 135-142 30,000 pages == 60GB 208 - 229 131-144 It means decrement of 6TB hugepages will trigger softlockup with the default threshold 20sec, in this decreasing rate. Signed-off-by: Masayoshi Mizuma Cc: Joonsoo Kim Cc: Michal Hocko Cc: Wanpeng Li Cc: Aneesh Kumar Cc: KOSAKI Motohiro Cc: Naoya Horiguchi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 8e8836abf74a0b227c651cf76466b8d711470a76 Author: Vlastimil Babka Date: Mon Apr 7 15:37:50 2014 -0700 mm: try_to_unmap_cluster() should lock_page() before mlocking commit 57e68e9cd65b4b8eb4045a1e0d0746458502554c upstream. A BUG_ON(!PageLocked) was triggered in mlock_vma_page() by Sasha Levin fuzzing with trinity. The call site try_to_unmap_cluster() does not lock the pages other than its check_page parameter (which is already locked). The BUG_ON in mlock_vma_page() is not documented and its purpose is somewhat unclear, but apparently it serializes against page migration, which could otherwise fail to transfer the PG_mlocked flag. This would not be fatal, as the page would be eventually encountered again, but NR_MLOCK accounting would become distorted nevertheless. This patch adds a comment to the BUG_ON in mlock_vma_page() and munlock_vma_page() to that effect. The call site try_to_unmap_cluster() is fixed so that for page != check_page, trylock_page() is attempted (to avoid possible deadlocks as we already have check_page locked) and mlock_vma_page() is performed only upon success. If the page lock cannot be obtained, the page is left without PG_mlocked, which is again not a problem in the whole unevictable memory design. Signed-off-by: Vlastimil Babka Signed-off-by: Bob Liu Reported-by: Sasha Levin Cc: Wanpeng Li Cc: Michel Lespinasse Cc: KOSAKI Motohiro Acked-by: Rik van Riel Cc: David Rientjes Cc: Mel Gorman Cc: Hugh Dickins Cc: Joonsoo Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 9acd41220b5addaf9d59b1e8825375d34803a375 Author: Nicholas Bellinger Date: Wed Feb 19 23:32:14 2014 +0000 iscsi-target: Fix ERL=2 ASYNC_EVENT connection pointer bug commit d444edc679e7713412f243b792b1f964e5cff1e1 upstream. This patch fixes a long-standing bug in iscsit_build_conn_drop_async_message() where during ERL=2 connection recovery, a bogus conn_p pointer could end up being used to send the ISCSI_OP_ASYNC_EVENT + DROPPING_CONNECTION notifying the initiator that cmd->logout_cid has failed. The bug was manifesting itself as an OOPs in iscsit_allocate_cmd() with a bogus conn_p pointer in iscsit_build_conn_drop_async_message(). Reported-by: Arshad Hussain Reported-by: santosh kulkarni Signed-off-by: Nicholas Bellinger Signed-off-by: Ben Hutchings commit 4c5dd0ae37e1409250ab628b86facb574588716c Author: alex chen Date: Thu Apr 3 14:47:05 2014 -0700 ocfs2: do not put bh when buffer_uptodate failed commit f7cf4f5bfe073ad792ab49c04f247626b3e38db6 upstream. Do not put bh when buffer_uptodate failed in ocfs2_write_block and ocfs2_write_super_or_backup, because it will put bh in b_end_io. Otherwise it will hit a warning "VFS: brelse: Trying to free free buffer". Signed-off-by: Alex Chen Reviewed-by: Joseph Qi Reviewed-by: Srinivas Eeda Cc: Mark Fasheh Acked-by: Joel Becker Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit f5c4690c8baf89d07433af83ab029d3b554955ea Author: Junxiao Bi Date: Thu Apr 3 14:46:51 2014 -0700 ocfs2: dlm: fix recovery hung commit ded2cf71419b9353060e633b59e446c42a6a2a09 upstream. There is a race window in dlm_do_recovery() between dlm_remaster_locks() and dlm_reset_recovery() when the recovery master nearly finish the recovery process for a dead node. After the master sends FINALIZE_RECO message in dlm_remaster_locks(), another node may become the recovery master for another dead node, and then send the BEGIN_RECO message to all the nodes included the old master, in the handler of this message dlm_begin_reco_handler() of old master, dlm->reco.dead_node and dlm->reco.new_master will be set to the second dead node and the new master, then in dlm_reset_recovery(), these two variables will be reset to default value. This will cause new recovery master can not finish the recovery process and hung, at last the whole cluster will hung for recovery. old recovery master: new recovery master: dlm_remaster_locks() become recovery master for another dead node. dlm_send_begin_reco_message() dlm_begin_reco_handler() { if (dlm->reco.state & DLM_RECO_STATE_FINALIZE) { return -EAGAIN; } dlm_set_reco_master(dlm, br->node_idx); dlm_set_reco_dead_node(dlm, br->dead_node); } dlm_reset_recovery() { dlm_set_reco_dead_node(dlm, O2NM_INVALID_NODE_NUM); dlm_set_reco_master(dlm, O2NM_INVALID_NODE_NUM); } will hang in dlm_remaster_locks() for request dlm locks info Before send FINALIZE_RECO message, recovery master should set DLM_RECO_STATE_FINALIZE for itself and clear it after the recovery done, this can break the race windows as the BEGIN_RECO messages will not be handled before DLM_RECO_STATE_FINALIZE flag is cleared. A similar race may happen between new recovery master and normal node which is in dlm_finalize_reco_handler(), also fix it. Signed-off-by: Junxiao Bi Reviewed-by: Srinivas Eeda Reviewed-by: Wengang Wang Cc: Joel Becker Cc: Mark Fasheh Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit ca2ba53d4db54ef84aad522cef202f89443a52ca Author: Junxiao Bi Date: Thu Apr 3 14:46:49 2014 -0700 ocfs2: dlm: fix lock migration crash commit 34aa8dac482f1358d59110d5e3a12f4351f6acaa upstream. This issue was introduced by commit 800deef3f6f8 ("ocfs2: use list_for_each_entry where benefical") in 2007 where it replaced list_for_each with list_for_each_entry. The variable "lock" will point to invalid data if "tmpq" list is empty and a panic will be triggered due to this. Sunil advised reverting it back, but the old version was also not right. At the end of the outer for loop, that list_for_each_entry will also set "lock" to an invalid data, then in the next loop, if the "tmpq" list is empty, "lock" will be an stale invalid data and cause the panic. So reverting the list_for_each back and reset "lock" to NULL to fix this issue. Another concern is that this seemes can not happen because the "tmpq" list should not be empty. Let me describe how. old lock resource owner(node 1): migratation target(node 2): image there's lockres with a EX lock from node 2 in granted list, a NR lock from node x with convert_type EX in converting list. dlm_empty_lockres() { dlm_pick_migration_target() { pick node 2 as target as its lock is the first one in granted list. } dlm_migrate_lockres() { dlm_mark_lockres_migrating() { res->state |= DLM_LOCK_RES_BLOCK_DIRTY; wait_event(dlm->ast_wq, !dlm_lockres_is_dirty(dlm, res)); //after the above code, we can not dirty lockres any more, // so dlm_thread shuffle list will not run downconvert lock from EX to NR upconvert lock from NR to EX <<< migration may schedule out here, then <<< node 2 send down convert request to convert type from EX to <<< NR, then send up convert request to convert type from NR to <<< EX, at this time, lockres granted list is empty, and two locks <<< in the converting list, node x up convert lock followed by <<< node 2 up convert lock. // will set lockres RES_MIGRATING flag, the following // lock/unlock can not run dlm_lockres_release_ast(dlm, res); } dlm_send_one_lockres() dlm_process_recovery_data() for (i=0; inum_locks; i++) if (ml->node == dlm->node_num) for (j = DLM_GRANTED_LIST; j <= DLM_BLOCKED_LIST; j++) { list_for_each_entry(lock, tmpq, list) if (lock) break; <<< lock is invalid as grant list is empty. } if (lock->ml.node != ml->node) BUG() >>> crash here } I see the above locks status from a vmcore of our internal bug. Signed-off-by: Junxiao Bi Reviewed-by: Wengang Wang Cc: Sunil Mushran Reviewed-by: Srinivas Eeda Cc: Joel Becker Cc: Mark Fasheh Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 75c623aeed530e1da2a97dfbfaef86b55121e00f Author: Matt Fleming Date: Thu Apr 3 14:46:20 2014 -0700 sh: fix format string bug in stack tracer commit a0c32761e73c9999cbf592b702f284221fea8040 upstream. Kees reported the following error: arch/sh/kernel/dumpstack.c: In function 'print_trace_address': arch/sh/kernel/dumpstack.c:118:2: error: format not a string literal and no format arguments [-Werror=format-security] Use the "%s" format so that it's impossible to interpret 'data' as a format string. Signed-off-by: Matt Fleming Reported-by: Kees Cook Acked-by: Kees Cook Cc: Paul Mundt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit f81305b3826f8e69b2c57e8ef4bc7a72b029461c Author: Alex Deucher Date: Mon Mar 31 11:19:46 2014 -0400 drm/radeon: call drm_edid_to_eld when we update the edid commit 16086279353cbfecbb3ead474072dced17b97ddc upstream. This needs to be done to update some of the fields in the connector structure used by the audio code. Noticed by several users on irc. Signed-off-by: Alex Deucher Signed-off-by: Christian König Signed-off-by: Ben Hutchings commit 8dd0cd27909f04ddb5ffb7da306643da45f42b60 Author: Christopher Friedt Date: Sat Feb 1 10:01:15 2014 -0500 drm/vmwgfx: correct fb_fix_screeninfo.line_length commit aa6de142c901cd2d90ef08db30ae87da214bedcc upstream. Previously, the vmwgfx_fb driver would allow users to call FBIOSET_VINFO, but it would not adjust the FINFO properly, resulting in distorted screen rendering. The patch corrects that behaviour. See https://bugs.gentoo.org/show_bug.cgi?id=494794 for examples. Signed-off-by: Christopher Friedt Reviewed-by: Thomas Hellstrom Signed-off-by: Ben Hutchings commit 078a6830af35e480d2882ad08cede954bb84ad64 Author: Jeff Mahoney Date: Wed Apr 2 14:40:26 2014 -0400 reiserfs: fix race in readdir commit 01d8885785a60ae8f4c37b0ed75bdc96d0fc6a44 upstream. jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-2) The -ENOENT is due to readdir calling dir_emit on the same entry twice. If the dir_emit callback sleeps and the tree is changed underneath us, we won't be able to trust deh_offset(deh) anymore. We need to save next_pos before we might sleep so we can find the next entry. Signed-off-by: Jeff Mahoney Signed-off-by: Jan Kara Signed-off-by: Ben Hutchings commit 47b1cf907952463052def12fca6a07f7df0c34c4 Author: Yann Droneaud Date: Mon Mar 10 23:06:25 2014 +0100 IB/ehca: Returns an error on ib_copy_to_udata() failure commit 5bdb0f02add5994b0bc17494f4726925ca5d6ba1 upstream. In case of error when writing to userspace, function ehca_create_cq() does not set an error code before following its error path. This patch sets the error code to -EFAULT when ib_copy_to_udata() fails. This was caught when using spatch (aka. coccinelle) to rewrite call to ib_copy_{from,to}_udata(). Link: https://www.gitorious.org/opteya/coccib/source/75ebf2c1033c64c1d81df13e4ae44ee99c989eba:ib_copy_udata.cocci Link: http://marc.info/?i=cover.1394485254.git.ydroneaud@opteya.com Signed-off-by: Yann Droneaud Signed-off-by: Roland Dreier Signed-off-by: Ben Hutchings commit 44a524016c91bf52c52abc2dc7ab4c2262e98dac Author: Yann Droneaud Date: Mon Mar 10 23:06:26 2014 +0100 IB/mthca: Return an error on ib_copy_to_udata() failure commit 08e74c4b00c30c232d535ff368554959403d0432 upstream. In case of error when writing to userspace, the function mthca_create_cq() does not set an error code before following its error path. This patch sets the error code to -EFAULT when ib_copy_to_udata() fails. This was caught when using spatch (aka. coccinelle) to rewrite call to ib_copy_{from,to}_udata(). Link: https://www.gitorious.org/opteya/coccib/source/75ebf2c1033c64c1d81df13e4ae44ee99c989eba:ib_copy_udata.cocci Link: http://marc.info/?i=cover.1394485254.git.ydroneaud@opteya.com Signed-off-by: Yann Droneaud Signed-off-by: Roland Dreier Signed-off-by: Ben Hutchings commit 38c4a0153b2bad3280768787bf2a3cf349e59bc8 Author: W. Trevor King Date: Sat Mar 29 17:47:24 2014 -0700 ALSA: hda - Enable beep for ASUS 1015E commit a4b7f21d7b42b33609df3f86992a8deff80abfaf upstream. The `lspci -nnvv` output contains (wrapped for line length): 00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller [8086:1e20] (rev 04) Subsystem: ASUSTeK Computer Inc. Device [1043:115d] Signed-off-by: W. Trevor King Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 258f96215696a32844bb6ed9da446cb550bd8396 Author: Huacai Chen Date: Sat Mar 22 17:21:44 2014 +0800 MIPS: Hibernate: Flush TLB entries in swsusp_arch_resume() commit c14af233fbe279d0e561ecf84f1208b1bae087ef upstream. The original MIPS hibernate code flushes cache and TLB entries in swsusp_arch_resume(). But they are removed in Commit 44eeab67416711 (MIPS: Hibernation: Remove SMP TLB and cacheflushing code.). A cross- CPU flush is surely unnecessary because all but the local CPU have already been disabled. But a local flush (at least the TLB flush) is needed. When we do hibernation on Loongson-3 with an E1000E NIC, it is very easy to produce a kernel panic (kernel page fault, or unaligned access). The root cause is E1000E driver use vzalloc_node() to allocate pages, the stale TLB entries of the booting kernel will be misused by the resumed target kernel. Signed-off-by: Huacai Chen Cc: John Crispin Cc: Steven J. Hill Cc: Aurelien Jarno Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang Cc: Zhangjin Wu Patchwork: https://patchwork.linux-mips.org/patch/6643/ Signed-off-by: Ralf Baechle Signed-off-by: Ben Hutchings commit 2791a9e4eb2e0086dba46782876cf6d567182259 Author: J. Bruce Fields Date: Mon Mar 10 14:17:55 2014 -0400 nfsd4: fix setclientid encode size commit 480efaee085235bb848f1063f959bf144103c342 upstream. Signed-off-by: J. Bruce Fields Signed-off-by: Ben Hutchings commit 28ba5aaec4a0b118214d2f075456f288f0b67648 Author: Mike Snitzer Date: Fri Mar 28 02:15:02 2014 -0400 dm thin: fix dangling bio in process_deferred_bios error path commit fe76cd88e654124d1431bb662a0fc6e99ca811a5 upstream. If unable to ensure_next_mapping() we must add the current bio, which was removed from the @bios list via bio_list_pop, back to the deferred_bios list before all the remaining @bios. Signed-off-by: Mike Snitzer Acked-by: Joe Thornber Signed-off-by: Ben Hutchings commit e6f13570cf414aa151d350e2c2583375a1229b45 Author: Jani Nikula Date: Fri Mar 28 08:54:04 2014 +0200 drm/i915/tv: fix gen4 composite s-video tv-out commit e1f23f3dd817f53f622e486913ac662add46eeed upstream. This is *not* bisected, but the likely regression is commit c35614380d5c956bfda20eab2755b2f5a7d6f1e7 Author: Zhao Yakui Date: Tue Nov 24 09:48:48 2009 +0800 drm/i915: Don't set up the TV port if it isn't in the BIOS table. The commit does not check for all TV device types that might be present in the VBT, disabling TV out for the missing ones. Add composite S-video. Reported-and-tested-by: Matthew Khouzam Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73362 Signed-off-by: Jani Nikula Signed-off-by: Daniel Vetter [bwh: Backported to 3.2: s/old\.device_type/device_type/] Signed-off-by: Ben Hutchings commit 8389a2e977d9ffe5c695a9735158c9d135100080 Author: J. Bruce Fields Date: Mon Feb 24 14:59:47 2014 -0500 nfsd: notify_change needs elevated write count commit 9f67f189939eccaa54f3d2c9cf10788abaf2d584 upstream. Looks like this bug has been here since these write counts were introduced, not sure why it was just noticed now. Thanks also to Jan Kara for pointing out the problem. Reported-by: Matthew Rahtz Signed-off-by: J. Bruce Fields Signed-off-by: Ben Hutchings commit 3863e89caec3c83dbeae9c3077389db6206dc8e7 Author: Ben Hutchings Date: Sun Apr 27 01:20:19 2014 +0100 nfsd: Add fh_{want,drop}_write() Part of commit bad0dcffc21d17a07dbb83a2bf764f35a57feba5 ('new helpers: fh_{want,drop}_write()') upstream. Signed-off-by: Ben Hutchings commit 4b739882ad223508c474f0f9f15c9f9c032277c1 Author: J. Bruce Fields Date: Tue Jan 28 16:01:04 2014 -0500 nfsd4: session needs room for following op to error out commit 4c69d5855a16f7378648c5733632628fa10431db upstream. Signed-off-by: J. Bruce Fields Signed-off-by: Ben Hutchings commit c674ae0967fa888e35c173a5026001dfdc0493c8 Author: J. Bruce Fields Date: Tue Jan 28 16:05:15 2014 -0500 nfsd4: buffer-length check for SUPPATTR_EXCLCREAT commit de3997a7eeb9ea286b15879fdf8a95aae065b4f7 upstream. This was an omission from 8c18f2052e756e7d5dea712fc6e7ed70c00e8a39 "nfsd41: SUPPATTR_EXCLCREAT attribute". Cc: Benny Halevy Signed-off-by: J. Bruce Fields Signed-off-by: Ben Hutchings commit 5bb8af45843a01663197cfc41afa9c30c350cc07 Author: Jason Wang Date: Fri Feb 28 11:30:29 2014 +0800 x86, hyperv: Bypass the timer_irq_works() check commit ca3ba2a2f4a49a308e7d78c784d51b2332064f15 upstream. This patch bypass the timer_irq_works() check for hyperv guest since: - It was guaranteed to work. - timer_irq_works() may fail sometime due to the lpj calibration were inaccurate in a hyperv guest or a buggy host. In the future, we should get the tsc frequency from hypervisor and use preset lpj instead. [ hpa: I would prefer to not defer things to "the future" in the future... ] Cc: K. Y. Srinivasan Cc: Haiyang Zhang Acked-by: K. Y. Srinivasan Signed-off-by: Jason Wang Link: http://lkml.kernel.org/r/1393558229-14755-1-git-send-email-jasowang@redhat.com Signed-off-by: H. Peter Anvin [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 4f86b545ffcdea19ea644920e84d644cf2e6b1e8 Author: Marek Vasut Date: Mon Mar 24 03:38:10 2014 +0100 gpio: mxs: Allow for recursive enable_irq_wake() call commit a585f87c863e4e1d496459d382b802bf5ebe3717 upstream. The scenario here is that someone calls enable_irq_wake() from somewhere in the code. This will result in the lockdep producing a backtrace as can be seen below. In my case, this problem is triggered when using the wl1271 (TI WlCore) driver found in drivers/net/wireless/ti/ . The problem cause is rather obvious from the backtrace, but let's outline the dependency. enable_irq_wake() grabs the IRQ buslock in irq_set_irq_wake(), which in turns calls mxs_gpio_set_wake_irq() . But mxs_gpio_set_wake_irq() calls enable_irq_wake() again on the one-level-higher IRQ , thus it tries to grab the IRQ buslock again in irq_set_irq_wake() . Because the spinlock in irq_set_irq_wake()->irq_get_desc_buslock()->__irq_get_desc_lock() is not marked as recursive, lockdep will spew the stuff below. We know we can safely re-enter the lock, so use IRQ_GC_INIT_NESTED_LOCK to fix the spew. ============================================= [ INFO: possible recursive locking detected ] 3.10.33-00012-gf06b763-dirty #61 Not tainted --------------------------------------------- kworker/0:1/18 is trying to acquire lock: (&irq_desc_lock_class){-.-...}, at: [] __irq_get_desc_lock+0x48/0x88 but task is already holding lock: (&irq_desc_lock_class){-.-...}, at: [] __irq_get_desc_lock+0x48/0x88 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&irq_desc_lock_class); lock(&irq_desc_lock_class); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by kworker/0:1/18: #0: (events){.+.+.+}, at: [] process_one_work+0x134/0x4a4 #1: ((&fw_work->work)){+.+.+.}, at: [] process_one_work+0x134/0x4a4 #2: (&irq_desc_lock_class){-.-...}, at: [] __irq_get_desc_lock+0x48/0x88 stack backtrace: CPU: 0 PID: 18 Comm: kworker/0:1 Not tainted 3.10.33-00012-gf06b763-dirty #61 Workqueue: events request_firmware_work_func [] (unwind_backtrace+0x0/0xf0) from [] (show_stack+0x10/0x14) [] (show_stack+0x10/0x14) from [] (__lock_acquire+0x140c/0x1a64) [] (__lock_acquire+0x140c/0x1a64) from [] (lock_acquire+0x9c/0x104) [] (lock_acquire+0x9c/0x104) from [] (_raw_spin_lock_irqsave+0x44/0x58) [] (_raw_spin_lock_irqsave+0x44/0x58) from [] (__irq_get_desc_lock+0x48/0x88) [] (__irq_get_desc_lock+0x48/0x88) from [] (irq_set_irq_wake+0x20/0xf4) [] (irq_set_irq_wake+0x20/0xf4) from [] (mxs_gpio_set_wake_irq+0x1c/0x24) [] (mxs_gpio_set_wake_irq+0x1c/0x24) from [] (set_irq_wake_real+0x30/0x44) [] (set_irq_wake_real+0x30/0x44) from [] (irq_set_irq_wake+0x8c/0xf4) [] (irq_set_irq_wake+0x8c/0xf4) from [] (wlcore_nvs_cb+0x10c/0x97c) [] (wlcore_nvs_cb+0x10c/0x97c) from [] (request_firmware_work_func+0x38/0x58) [] (request_firmware_work_func+0x38/0x58) from [] (process_one_work+0x1c0/0x4a4) [] (process_one_work+0x1c0/0x4a4) from [] (worker_thread+0x138/0x394) [] (worker_thread+0x138/0x394) from [] (kthread+0xa4/0xb0) [] (kthread+0xa4/0xb0) from [] (ret_from_fork+0x14/0x34) wlcore: loaded Signed-off-by: Marek Vasut Acked-by: Shawn Guo Signed-off-by: Linus Walleij Signed-off-by: Ben Hutchings commit d57813e995c66cb298e745f3ba7e4ceb7a47c248 Author: Josef Bacik Date: Thu Mar 6 19:01:07 2014 -0500 Btrfs: fix deadlock with nested trans handles commit 3bbb24b20a8800158c33eca8564f432dd14d0bf3 upstream. Zach found this deadlock that would happen like this btrfs_end_transaction <- reduce trans->use_count to 0 btrfs_run_delayed_refs btrfs_cow_block find_free_extent btrfs_start_transaction <- increase trans->use_count to 1 allocate chunk btrfs_end_transaction <- decrease trans->use_count to 0 btrfs_run_delayed_refs lock tree block we are cowing above ^^ We need to only decrease trans->use_count if it is above 1, otherwise leave it alone. This will make nested trans be the only ones who decrease their added ref, and will let us get rid of the trans->use_count++ hack if we have to commit the transaction. Thanks, Reported-by: Zach Brown Signed-off-by: Josef Bacik Tested-by: Zach Brown Signed-off-by: Chris Mason [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 135db4db00fec7f7680f3d104c887aad6b4e465f Author: Richard Guy Briggs Date: Tue Dec 10 22:10:41 2013 -0500 audit: convert PPIDs to the inital PID namespace. commit c92cdeb45eea38515e82187f48c2e4f435fb4e25 upstream. sys_getppid() returns the parent pid of the current process in its own pid namespace. Since audit filters are based in the init pid namespace, a process could avoid a filter or trigger an unintended one by being in an alternate pid namespace or log meaningless information. Switch to task_ppid_nr() for PPIDs to anchor all audit filters in the init_pid_ns. (informed by ebiederman's 6c621b7e) Cc: Eric W. Biederman Signed-off-by: Richard Guy Briggs [bwh: Backported to 3.2: sys_getppid() is used by audit_exit() but not audit_log_task_info()] Signed-off-by: Ben Hutchings commit 0ce844aea64b8bff202676fd87f2932b3eb35b83 Author: Richard Guy Briggs Date: Thu Aug 15 18:05:12 2013 -0400 pid: get pid_t ppid of task in init_pid_ns commit ad36d28293936b03d6b7996e9d6aadfd73c0eb08 upstream. Added the functions task_ppid_nr_ns() and task_ppid_nr() to abstract the lookup of the PPID (real_parent's pid_t) of a process, including rcu locking, in the arbitrary and init_pid_ns. This provides an alternative to sys_getppid(), which is relative to the child process' pid namespace. (informed by ebiederman's 6c621b7e) Cc: Eric W. Biederman Signed-off-by: Richard Guy Briggs Signed-off-by: Ben Hutchings commit 209e1b813d01a0a6fe12cecc9e15dbf40cdf12ad Author: Krzysztof Kozlowski Date: Tue Feb 11 11:03:29 2014 +0100 mfd: 88pm860x: Fix possible NULL pointer dereference on i2c_new_dummy error commit 159ce52a6b777fc82fa0b51c7440e25f9e4c6feb upstream. During probe the driver allocates dummy I2C device for companion chip with i2c_new_dummy() but it does not check the return value of this call. In case of error (i2c_new_device(): memory allocation failure or I2C address cannot be used) this function returns NULL which is later used by regmap_init_i2c(). If i2c_new_dummy() fails for companion device, fail also the probe for main MFD driver. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Lee Jones [bwh: Backported to 3.2: - Adjust filename, context - Add kfree() before return, as driver is not using managed allocations] Signed-off-by: Ben Hutchings commit 758e64a56d3220edc5097d97cba1104530661fd2 Author: Krzysztof Kozlowski Date: Tue Feb 11 11:03:33 2014 +0100 mfd: max8925: Fix possible NULL pointer dereference on i2c_new_dummy error commit 96cf3dedc491d2f1f66cc26217f2b06b0c7b6797 upstream. During probe the driver allocates dummy I2C devices for RTC and ADC with i2c_new_dummy() but it does not check the return value of this calls. In case of error (i2c_new_device(): memory allocation failure or I2C address cannot be used) this function returns NULL which is later used by i2c_unregister_device(). If i2c_new_dummy() fails for RTC or ADC devices, fail also the probe for main MFD driver. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Lee Jones Signed-off-by: Ben Hutchings commit c330c022ae163cc84eff086720e28562570c2eaa Author: Krzysztof Kozlowski Date: Tue Feb 11 11:03:35 2014 +0100 mfd: max8998: Fix possible NULL pointer dereference on i2c_new_dummy error commit ed26f87b9f71693a1d1ee85f5e6209601505080f upstream. During probe the driver allocates dummy I2C device for RTC with i2c_new_dummy() but it does not check the return value of this call. In case of error (i2c_new_device(): memory allocation failure or I2C address cannot be used) this function returns NULL which is later used by i2c_unregister_device(). If i2c_new_dummy() fails for RTC device, fail also the probe for main MFD driver. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Lee Jones Signed-off-by: Ben Hutchings commit 792aa59f009d781878bd509ecc8fa65a94dfb4ab Author: Krzysztof Kozlowski Date: Tue Feb 11 11:03:34 2014 +0100 mfd: max8997: Fix possible NULL pointer dereference on i2c_new_dummy error commit 97dc4ed3fa377ec91bb60ba98b70d645c2099384 upstream. During probe the driver allocates dummy I2C devices for RTC, haptic and MUIC with i2c_new_dummy() but it does not check the return value of this calls. In case of error (i2c_new_device(): memory allocation failure or I2C address cannot be used) this function returns NULL which is later used by i2c_unregister_device(). If i2c_new_dummy() fails for RTC, haptic or MUIC devices, fail also the probe for main MFD driver. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Lee Jones Signed-off-by: Ben Hutchings commit fb2da9df043b1151d37be156f4b78eee4d1bde87 Author: Linus Walleij Date: Wed Jan 29 11:09:53 2014 +0100 mfd: Include all drivers in subsystem menu commit a6e6e660baa5c583022e3e48c85316bace027825 upstream. It is currently not possible to select the SA1100 or Vexpress drivers in the MFD subsystem, because the menu for the entire subsystem ends before these options are presented. Move the main menu closing and the endif for HAS_IOMEM to the end of the file so these are selectable again. Signed-off-by: Linus Walleij Signed-off-by: Lee Jones [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit a3ffdf42b198ba6a2e3427cd456f892aa89a36b4 Author: Yann Droneaud Date: Mon Mar 10 23:06:27 2014 +0100 IB/nes: Return an error on ib_copy_from_udata() failure instead of NULL commit 9d194d1025f463392feafa26ff8c2d8247f71be1 upstream. In case of error while accessing to userspace memory, function nes_create_qp() returns NULL instead of an error code wrapped through ERR_PTR(). But NULL is not expected by ib_uverbs_create_qp(), as it check for error with IS_ERR(). As page 0 is likely not mapped, it is going to trigger an Oops when the kernel will try to dereference NULL pointer to access to struct ib_qp's fields. In some rare cases, page 0 could be mapped by userspace, which could turn this bug to a vulnerability that could be exploited: the function pointers in struct ib_device will be under userspace total control. This was caught when using spatch (aka. coccinelle) to rewrite calls to ib_copy_{from,to}_udata(). Link: https://www.gitorious.org/opteya/ib-hw-nes-create-qp-null Link: https://www.gitorious.org/opteya/coccib/source/75ebf2c1033c64c1d81df13e4ae44ee99c989eba:ib_copy_udata.cocci Link: http://marc.info/?i=cover.1394485254.git.ydroneaud@opteya.com Signed-off-by: Yann Droneaud Signed-off-by: Roland Dreier Signed-off-by: Ben Hutchings commit a9782df2240b10ebc8df587e5a7f574ef9f44f71 Author: Dennis Dalessandro Date: Thu Feb 20 11:02:53 2014 -0500 IB/ipath: Fix potential buffer overrun in sending diag packet routine commit a2cb0eb8a64adb29a99fd864013de957028f36ae upstream. Guard against a potential buffer overrun. The size to read from the user is passed in, and due to the padding that needs to be taken into account, as well as the place holder for the ICRC it is possible to overflow the 32bit value which would cause more data to be copied from user space than is allocated in the buffer. Reported-by: Nico Golde Reported-by: Fabian Yamaguchi Reviewed-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Roland Dreier Signed-off-by: Ben Hutchings commit a7bbda740718580d49fb5a7ccd950316d58970f7 Author: Felix Fietkau Date: Sun Mar 9 11:02:54 2014 +0100 ath9k: fix ready time of the multicast buffer queue commit 3b3e0efb5c72c4fc940af50b33626b8a78a907dc upstream. qi->tqi_readyTime is written directly to registers that expect microseconds as unit instead of TU. When setting the CABQ ready time, cur_conf->beacon_interval is in TU, so convert it to microseconds before passing it to ath9k_hw. This should hopefully fix some Tx DMA issues with buffered multicast frames in AP mode. Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit e0a00412630cd700a1ea6d9162afdae261d03a31 Author: Eric Whitney Date: Thu Mar 13 23:34:16 2014 -0400 ext4: fix partial cluster handling for bigalloc file systems commit c06344939422bbd032ac967223a7863de57496b5 upstream. Commit 9cb00419fa, which enables hole punching for bigalloc file systems, exposed a bug introduced by commit 6ae06ff51e in an earlier release. When run on a bigalloc file system, xfstests generic/013, 068, 075, 083, 091, 100, 112, 127, 263, 269, and 270 fail with e2fsck errors or cause kernel error messages indicating that previously freed blocks are being freed again. The latter commit optimizes the selection of the starting extent in ext4_ext_rm_leaf() when hole punching by beginning with the extent supplied in the path argument rather than with the last extent in the leaf node (as is still done when truncating). However, the code in rm_leaf that initially sets partial_cluster to track cluster sharing on extent boundaries is only guaranteed to run if rm_leaf starts with the last node in the leaf. Consequently, partial_cluster is not correctly initialized when hole punching, and a cluster on the boundary of a punched region that should be retained may instead be deallocated. Signed-off-by: Eric Whitney Signed-off-by: "Theodore Ts'o" Signed-off-by: Ben Hutchings commit d7a04a3b663789ecfd80c4eeea742c73d3ccb540 Author: Rusty Russell Date: Thu Mar 13 11:23:38 2014 +1030 virtio_balloon: don't softlockup on huge balloon changes. commit 1f74ef0f2d7d692fcd615621e0e734c3e7771413 upstream. When adding or removing 100G from a balloon: BUG: soft lockup - CPU#0 stuck for 22s! [vballoon:367] We have a wait_event_interruptible(), but the condition is always true (more ballooning to do) so we don't ever sleep. We also have a wait_event() for the host to ack, but that is also always true as QEMU is synchronous for balloon operations. Reported-by: Gopesh Kumar Chaudhary Signed-off-by: Rusty Russell Signed-off-by: Ben Hutchings commit 769ddc4b6571f1b9766f2fa3d9e2c78cfc1afdeb Author: Emmanuel Grumbach Date: Mon Mar 10 15:22:03 2014 +0200 iwlwifi: dvm: take mutex when sending SYNC BT config command commit 82e5a649453a3cf23516277abb84273768a1592b upstream. There is a flow in which we send the host command in SYNC mode, but we don't take priv->mutex. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1046495 Reviewed-by: Johannes Berg Signed-off-by: Emmanuel Grumbach [bwh: Backported to 3.2: - Adjust filename, context - mutex is priv->shrd->mutex] Signed-off-by: Ben Hutchings commit 65417cd845c9e6217bcbdd7c9b91b01d57a09a9d Author: Ajesh Kunhipurayil Vijayan Date: Mon Jan 6 19:06:55 2014 +0530 jffs2: Fix crash due to truncation of csize commit 41bf1a24c1001f4d0d41a78e1ac575d2f14789d7 upstream. mounting JFFS2 partition sometimes crashes with this call trace: [ 1322.240000] Kernel bug detected[#1]: [ 1322.244000] Cpu 2 [ 1322.244000] $ 0 : 0000000000000000 0000000000000018 000000003ff00070 0000000000000001 [ 1322.252000] $ 4 : 0000000000000000 c0000000f3980150 0000000000000000 0000000000010000 [ 1322.260000] $ 8 : ffffffffc09cd5f8 0000000000000001 0000000000000088 c0000000ed300de8 [ 1322.268000] $12 : e5e19d9c5f613a45 ffffffffc046d464 0000000000000000 66227ba5ea67b74e [ 1322.276000] $16 : c0000000f1769c00 c0000000ed1e0200 c0000000f3980150 0000000000000000 [ 1322.284000] $20 : c0000000f3a80000 00000000fffffffc c0000000ed2cfbd8 c0000000f39818f0 [ 1322.292000] $24 : 0000000000000004 0000000000000000 [ 1322.300000] $28 : c0000000ed2c0000 c0000000ed2cfab8 0000000000010000 ffffffffc039c0b0 [ 1322.308000] Hi : 000000000000023c [ 1322.312000] Lo : 000000000003f802 [ 1322.316000] epc : ffffffffc039a9f8 check_tn_node+0x88/0x3b0 [ 1322.320000] Not tainted [ 1322.324000] ra : ffffffffc039c0b0 jffs2_do_read_inode_internal+0x1250/0x1e48 [ 1322.332000] Status: 5400f8e3 KX SX UX KERNEL EXL IE [ 1322.336000] Cause : 00800034 [ 1322.340000] PrId : 000c1004 (Netlogic XLP) [ 1322.344000] Modules linked in: [ 1322.348000] Process jffs2_gcd_mtd7 (pid: 264, threadinfo=c0000000ed2c0000, task=c0000000f0e68dd8, tls=0000000000000000) [ 1322.356000] Stack : c0000000f1769e30 c0000000ed010780 c0000000ed010780 c0000000ed300000 c0000000f1769c00 c0000000f3980150 c0000000f3a80000 00000000fffffffc c0000000ed2cfbd8 ffffffffc039c0b0 ffffffffc09c6340 0000000000001000 0000000000000dec ffffffffc016c9d8 c0000000f39805a0 c0000000f3980180 0000008600000000 0000000000000000 0000000000000000 0000000000000000 0001000000000dec c0000000f1769d98 c0000000ed2cfb18 0000000000010000 0000000000010000 0000000000000044 c0000000f3a80000 c0000000f1769c00 c0000000f3d207a8 c0000000f1769d98 c0000000f1769de0 ffffffffc076f9c0 0000000000000009 0000000000000000 0000000000000000 ffffffffc039cf90 0000000000000017 ffffffffc013fbdc 0000000000000001 000000010003e61c ... [ 1322.424000] Call Trace: [ 1322.428000] [] check_tn_node+0x88/0x3b0 [ 1322.432000] [] jffs2_do_read_inode_internal+0x1250/0x1e48 [ 1322.440000] [] jffs2_do_crccheck_inode+0x70/0xd0 [ 1322.448000] [] jffs2_garbage_collect_pass+0x160/0x870 [ 1322.452000] [] jffs2_garbage_collect_thread+0xdc/0x1f0 [ 1322.460000] [] kthread+0xb8/0xc0 [ 1322.464000] [] kernel_thread_helper+0x10/0x18 [ 1322.472000] [ 1322.472000] Code: 67bd0050 94a4002c 2c830001 <00038036> de050218 2403fffc 0080a82d 00431824 24630044 [ 1322.480000] ---[ end trace b052bb90e97dfbf5 ]--- The variable csize in structure jffs2_tmp_dnode_info is of type uint16_t, but it is used to hold the compressed data length(csize) which is declared as uint32_t. So, when the value of csize exceeds 16bits, it gets truncated when assigned to tn->csize. This is causing a kernel BUG. Changing the definition of csize in jffs2_tmp_dnode_info to uint32_t fixes the issue. Signed-off-by: Ajesh Kunhipurayil Vijayan Signed-off-by: Kamlakant Patel Signed-off-by: Brian Norris Signed-off-by: Ben Hutchings commit 9634d073d823def05f7b4f2b89b35c4c55be10ac Author: Kamlakant Patel Date: Mon Jan 6 19:06:54 2014 +0530 jffs2: Fix segmentation fault found in stress test commit 3367da5610c50e6b83f86d366d72b41b350b06a2 upstream. Creating a large file on a JFFS2 partition sometimes crashes with this call trace: [ 306.476000] CPU 13 Unable to handle kernel paging request at virtual address c0000000dfff8002, epc == ffffffffc03a80a8, ra == ffffffffc03a8044 [ 306.488000] Oops[#1]: [ 306.488000] Cpu 13 [ 306.492000] $ 0 : 0000000000000000 0000000000000000 0000000000008008 0000000000008007 [ 306.500000] $ 4 : c0000000dfff8002 000000000000009f c0000000e0007cde c0000000ee95fa58 [ 306.508000] $ 8 : 0000000000000001 0000000000008008 0000000000010000 ffffffffffff8002 [ 306.516000] $12 : 0000000000007fa9 000000000000ff0e 000000000000ff0f 80e55930aebb92bb [ 306.524000] $16 : c0000000e0000000 c0000000ee95fa5c c0000000efc80000 ffffffffc09edd70 [ 306.532000] $20 : ffffffffc2b60000 c0000000ee95fa58 0000000000000000 c0000000efc80000 [ 306.540000] $24 : 0000000000000000 0000000000000004 [ 306.548000] $28 : c0000000ee950000 c0000000ee95f738 0000000000000000 ffffffffc03a8044 [ 306.556000] Hi : 00000000000574a5 [ 306.560000] Lo : 6193b7a7e903d8c9 [ 306.564000] epc : ffffffffc03a80a8 jffs2_rtime_compress+0x98/0x198 [ 306.568000] Tainted: G W [ 306.572000] ra : ffffffffc03a8044 jffs2_rtime_compress+0x34/0x198 [ 306.580000] Status: 5000f8e3 KX SX UX KERNEL EXL IE [ 306.584000] Cause : 00800008 [ 306.588000] BadVA : c0000000dfff8002 [ 306.592000] PrId : 000c1100 (Netlogic XLP) [ 306.596000] Modules linked in: [ 306.596000] Process dd (pid: 170, threadinfo=c0000000ee950000, task=c0000000ee6e0858, tls=0000000000c47490) [ 306.608000] Stack : 7c547f377ddc7ee4 7ffc7f967f5d7fae 7f617f507fc37ff4 7e7d7f817f487f5f 7d8e7fec7ee87eb3 7e977ff27eec7f9e 7d677ec67f917f67 7f3d7e457f017ed7 7fd37f517f867eb2 7fed7fd17ca57e1d 7e5f7fe87f257f77 7fd77f0d7ede7fdb 7fba7fef7e197f99 7fde7fe07ee37eb5 7f5c7f8c7fc67f65 7f457fb87f847e93 7f737f3e7d137cd9 7f8e7e9c7fc47d25 7dbb7fac7fb67e52 7ff17f627da97f64 7f6b7df77ffa7ec5 80057ef17f357fb3 7f767fa27dfc7fd5 7fe37e8e7fd07e53 7e227fcf7efb7fa1 7f547e787fa87fcc 7fcb7fc57f5a7ffb 7fc07f6c7ea97e80 7e2d7ed17e587ee0 7fb17f9d7feb7f31 7f607e797e887faa 7f757fdd7c607ff3 7e877e657ef37fbd 7ec17fd67fe67ff7 7ff67f797ff87dc4 7eef7f3a7c337fa6 7fe57fc97ed87f4b 7ebe7f097f0b8003 7fe97e2a7d997cba 7f587f987f3c7fa9 ... [ 306.676000] Call Trace: [ 306.680000] [] jffs2_rtime_compress+0x98/0x198 [ 306.684000] [] jffs2_selected_compress+0x110/0x230 [ 306.692000] [] jffs2_compress+0x5c/0x388 [ 306.696000] [] jffs2_write_inode_range+0xd8/0x388 [ 306.704000] [] jffs2_write_end+0x16c/0x2d0 [ 306.708000] [] generic_file_buffered_write+0xf8/0x2b8 [ 306.716000] [] __generic_file_aio_write+0x1ac/0x350 [ 306.720000] [] generic_file_aio_write+0x80/0x168 [ 306.728000] [] do_sync_write+0x94/0xf8 [ 306.732000] [] vfs_write+0xa4/0x1a0 [ 306.736000] [] SyS_write+0x50/0x90 [ 306.744000] [] handle_sys+0x180/0x1a0 [ 306.748000] [ 306.748000] Code: 020b202d 0205282d 90a50000 <90840000> 14a40038 00000000 0060602d 0000282d 016c5823 [ 306.760000] ---[ end trace 79dd088435be02d0 ]--- Segmentation fault This crash is caused because the 'positions' is declared as an array of signed short. The value of position is in the range 0..65535, and will be converted to a negative number when the position is greater than 32767 and causes a corruption and crash. Changing the definition to 'unsigned short' fixes this issue Signed-off-by: Jayachandran C Signed-off-by: Kamlakant Patel Signed-off-by: Brian Norris Signed-off-by: Ben Hutchings commit 62a9eee371b54d6c56f9867b193f4a2410c50c05 Author: Li Zefan Date: Wed Feb 12 12:44:56 2014 -0800 jffs2: avoid soft-lockup in jffs2_reserve_space_gc() commit 13b546d96207c131eeae15dc7b26c6e7d0f1cad7 upstream. We triggered soft-lockup under stress test on 2.6.34 kernel. BUG: soft lockup - CPU#1 stuck for 60009ms! [lockf2.test:14488] ... [] (jffs2_do_reserve_space+0x420/0x440 [jffs2]) [] (jffs2_reserve_space_gc+0x34/0x78 [jffs2]) [] (jffs2_garbage_collect_dnode.isra.3+0x264/0x478 [jffs2]) [] (jffs2_garbage_collect_pass+0x9c0/0xe4c [jffs2]) [] (jffs2_reserve_space+0x104/0x2a8 [jffs2]) [] (jffs2_write_inode_range+0x5c/0x4d4 [jffs2]) [] (jffs2_write_end+0x198/0x2c0 [jffs2]) [] (generic_file_buffered_write+0x158/0x200) [] (__generic_file_aio_write+0x3a4/0x414) [] (generic_file_aio_write+0x5c/0xbc) [] (do_sync_write+0x98/0xd4) [] (vfs_write+0xa8/0x150) [] (sys_write+0x3c/0xc0)] Fix this by adding a cond_resched() in the while loop. [akpm@linux-foundation.org: don't initialize `ret'] Signed-off-by: Li Zefan Cc: David Woodhouse Cc: Artem Bityutskiy Signed-off-by: Andrew Morton Signed-off-by: Brian Norris [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 22af2c501a2c1980e848ce138031ed1cab278f55 Author: Li Zefan Date: Wed Feb 12 12:44:57 2014 -0800 jffs2: remove from wait queue after schedule() commit 3ead9578443b66ddb3d50ed4f53af8a0c0298ec5 upstream. @wait is a local variable, so if we don't remove it from the wait queue list, later wake_up() may end up accessing invalid memory. This was spotted by eyes. Signed-off-by: Li Zefan Cc: David Woodhouse Cc: Artem Bityutskiy Signed-off-by: Andrew Morton Signed-off-by: Brian Norris Signed-off-by: Ben Hutchings commit b58d5a52ea4a3fec497594d642ed7cec25950900 Author: Hidetoshi Seto Date: Wed Feb 5 16:34:38 2014 +0900 Btrfs: skip submitting barrier for missing device commit f88ba6a2a44ee98e8d59654463dc157bb6d13c43 upstream. I got an error on v3.13: BTRFS error (device sdf1) in write_all_supers:3378: errno=-5 IO failure (errors while submitting device barriers.) how to reproduce: > mkfs.btrfs -f -d raid1 /dev/sdf1 /dev/sdf2 > wipefs -a /dev/sdf2 > mount -o degraded /dev/sdf1 /mnt > btrfs balance start -f -sconvert=single -mconvert=single -dconvert=single /mnt The reason of the error is that barrier_all_devices() failed to submit barrier to the missing device. However it is clear that we cannot do anything on missing device, and also it is not necessary to care chunks on the missing device. This patch stops sending/waiting barrier if device is missing. Signed-off-by: Hidetoshi Seto Signed-off-by: Josef Bacik Signed-off-by: Ben Hutchings commit de12340b331f5da8b78edba6d3cde42de259ee60 Author: Himangi Saraogi Date: Wed Mar 5 04:59:57 2014 +0530 staging:serqt_usb2: Fix sparse warning restricted __le16 degrades to integer commit abe5d64d1a74195a44cd14624f8178b9f48b7cc7 upstream. This patch fixes the following sparse warning : drivers/staging/serqt_usb2/serqt_usb2.c:727:40: warning: restricted __le16 degrades to integer Signed-off-by: Himangi Saraogi Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 721c5416f8e56db70ccc99662be57998599d06b6 Author: Larry Finger Date: Tue Mar 4 16:53:51 2014 -0600 rtlwifi: rtl8192se: Fix too long disable of IRQs commit 2610decdd0b3808ba20471a999835cfee5275f98 upstream. In commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 entitled "rtlwifi: rtl8192ce: Fix too long disable of IRQs", Olivier Langlois fixed a problem caused by an extra long disabling of interrupts. This patch makes the same fix for rtl8192se. Signed-off-by: Larry Finger Signed-off-by: John W. Linville [bwh: Backported to 3.2: - Adjust context - Drop change to an error path that we don't have] Signed-off-by: Ben Hutchings commit 5b85afa68e4f56c27f1d5c6f49e5257bce6448e6 Author: Roman Pen Date: Tue Mar 4 23:13:10 2014 +0900 blktrace: fix accounting of partially completed requests commit af5040da01ef980670b3741b3e10733ee3e33566 upstream. trace_block_rq_complete does not take into account that request can be partially completed, so we can get the following incorrect output of blkparser: C R 232 + 240 [0] C R 240 + 232 [0] C R 248 + 224 [0] C R 256 + 216 [0] but should be: C R 232 + 8 [0] C R 240 + 8 [0] C R 248 + 8 [0] C R 256 + 8 [0] Also, the whole output summary statistics of completed requests and final throughput will be incorrect. This patch takes into account real completion size of the request and fixes wrong completion accounting. Signed-off-by: Roman Pen CC: Steven Rostedt CC: Frederic Weisbecker CC: Ingo Molnar CC: linux-kernel@vger.kernel.org Signed-off-by: Jens Axboe [bwh: Backported to 3.2: drop change in blk-mq.c] Signed-off-by: Ben Hutchings commit 631f96b5e27fdf9dc7b7e78201c01d05321f1494 Author: Gregory CLEMENT Date: Mon Mar 3 17:48:34 2014 +0100 usb: gadget: atmel_usba: fix crashed during stopping when DEBUG is enabled commit d8eb6c653ef6b323d630de3c5685478469e248bc upstream. commit 511f3c5 (usb: gadget: udc-core: fix a regression during gadget driver unbinding) introduced a crash when DEBUG is enabled. The debug trace in the atmel_usba_stop function made the assumption that the driver pointer passed in parameter was not NULL, but since the commit above, such assumption was no longer always true. This commit now uses the driver pointer stored in udc which fixes this issue. [ balbi@ti.com : improved commit log a bit ] Acked-by: Alexandre Belloni Signed-off-by: Gregory CLEMENT Signed-off-by: Felipe Balbi [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 165f9a52923ddaf70ada17d3d957d832b89f15c4 Author: Oleksij Rempel Date: Sun Feb 16 06:59:32 2014 -0300 uvcvideo: Do not use usb_set_interface on bulk EP commit b1e43f232698274871e1358c276d7b0242a7d607 upstream. The UVC specification uses alternate setting selection to notify devices of stream start/stop. This breaks when using bulk-based devices, as the video streaming interface has a single alternate setting in that case, making video stream start and video stream stop events to appear identical to the device. Bulk-based devices are thus not well supported by UVC. The webcam built in the Asus Zenbook UX302LA ignores the set interface request and will keep the video stream enabled when the driver tries to stop it. If USB autosuspend is enabled the device will then be suspended and will crash, requiring a cold reboot. USB trace capture showed that Windows sends a CLEAR_FEATURE(HALT) request to the bulk endpoint when stopping the stream instead of selecting alternate setting 0. The camera then behaves correctly, and thus seems to require that behaviour. Replace selection of alternate setting 0 with clearing of the endpoint halt feature at video stream stop for bulk-based devices. Let's refrain from blaming Microsoft this time, as it's not clear whether this Windows-specific but USB-compliant behaviour was specifically developed to handle bulkd-based UVC devices, or if the camera just took advantage of it. Signed-off-by: Oleksij Rempel Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings commit 66f328f3931d53a33c10c1003133bba1a2f5cb00 Author: Hannes Reinecke Date: Thu Feb 27 12:30:51 2014 +0100 tty: Set correct tty name in 'active' sysfs attribute commit 723abd87f6e536f1353c8f64f621520bc29523a3 upstream. The 'active' sysfs attribute should refer to the currently active tty devices the console is running on, not the currently active console. The console structure doesn't refer to any device in sysfs, only the tty the console is running on has. So we need to print out the tty names in 'active', not the console names. There is one special-case, which is tty0. If the console is directed to it, we want 'tty0' to show up in the file, so user-space knows that the messages get forwarded to the active VT. The ->device() callback would resolve tty0, though. Hence, treat it special and don't call into the VT layer to resolve it (plymouth is known to depend on it). Cc: Lennart Poettering Cc: Kay Sievers Cc: Greg Kroah-Hartman Cc: Jiri Slaby Signed-off-by: Werner Fink Signed-off-by: Hannes Reinecke Signed-off-by: David Herrmann Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: no TTY_DRIVER_UNNUMBERED_NODE case in tty_line_name()] Signed-off-by: Ben Hutchings commit 4a4033cbb11d3fbf963a657ad621cd12f751bbc7 Author: Wolfram Sang Date: Sat Feb 1 15:26:00 2014 -0300 media: gspca: sn9c20x: add ID for Genius Look 1320 V2 commit 61f0319193c44adbbada920162d880b1fdb3aeb3 upstream. Signed-off-by: Wolfram Sang Signed-off-by: Hans de Goede Signed-off-by: Mauro Carvalho Chehab [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings commit 8359dbebb14ceeac2ad73b47869c68a0a0603c9a Author: Huang Rui Date: Tue Jan 7 17:45:50 2014 +0800 usb: dwc3: fix wrong bit mask in dwc3_event_devt commit 06f9b6e59661cee510b04513b13ea7927727d758 upstream. Around DWC USB3 2.30a release another bit has been added to the Device-Specific Event (DEVT) Event Information (EvtInfo) bitfield. Because of that, what used to be 8 bits long, has become 9 bits long. Per dwc3 2.30a+ spec in the Device-Specific Event (DEVT), the field of Event Information Bits(EvtInfo) uses [24:16] bits, and it has 9 bits not 8 bits. And the following reserved field uses [31:25] bits not [31:24] bits, and it has 7 bits. So in dwc3_event_devt, the bit mask should be: event_info [24:16] 9 bits reserved31_25 [31:25] 7 bits This patch makes sure that newer core releases will work fine with Linux and that we will decode the event information properly on new core releases. [ balbi@ti.com : improve commit log a bit ] Signed-off-by: Huang Rui Signed-off-by: Felipe Balbi Signed-off-by: Ben Hutchings commit d666ac7d1b5a09b7d148850289c8abaf3c3aa215 Author: Paul Gortmaker Date: Tue Jan 14 16:03:37 2014 -0500 hvc: ensure hvc_init is only ever called once in hvc_console.c commit f76a1cbed18c86e2d192455f0daebb48458965f3 upstream. Commit 3e6c6f630a5282df8f3393a59f10eb9c56536d23 ("Delay creation of khcvd thread") moved the call of hvc_init from being a device_initcall into hvc_alloc, and used a non-null hvc_driver as indication of whether hvc_init had already been called. The problem with this is that hvc_driver is only assigned a value at the bottom of hvc_init, and so there is a window where multiple hvc_alloc calls can be in progress at the same time and hence try and call hvc_init multiple times. Previously the use of device_init guaranteed that hvc_init was only called once. This manifests itself as sporadic instances of two hvc_init calls racing each other, and with the loser of the race getting -EBUSY from tty_register_driver() and hence that virtual console fails: Couldn't register hvc console driver virtio-ports vport0p1: error -16 allocating hvc for port Here we add an atomic_t to guarantee we'll never run hvc_init twice. Cc: Rusty Russell Cc: Greg Kroah-Hartman Fixes: 3e6c6f630a52 ("Delay creation of khcvd thread") Reported-by: Jim Somerville Tested-by: Jim Somerville Signed-off-by: Paul Gortmaker Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 1c579197257b4e93a39e1d75b67d41bce6ac0b5c Author: Mikulas Patocka Date: Thu Jan 23 14:43:10 2014 -0500 tgafb: fix data copying commit 6b0df6827bb6fcacb158dff29ad0a62d6418b534 upstream. The functions for data copying copyarea_foreward_8bpp and copyarea_backward_8bpp are buggy, they produce screen corruption. This patch fixes the functions and moves the logic to one function "copyarea_8bpp". For simplicity, the function only handles copying that is aligned on 8 pixes. If we copy an unaligned area, generic function cfb_copyarea is used. Signed-off-by: Mikulas Patocka Signed-off-by: Tomi Valkeinen Signed-off-by: Ben Hutchings commit 9542ff416a8a3af15bdf465e63583c94e7d1055f Author: Mikulas Patocka Date: Thu Jan 23 14:41:59 2014 -0500 mach64: fix cursor when character width is not a multiple of 8 pixels commit 43751a1b8ee2e70ce392bf31ef3133da324e68b3 upstream. This patch fixes the hardware cursor on mach64 when font width is not a multiple of 8 pixels. If you load such a font, the cursor is expanded to the next 8-byte boundary and a part of the next character after the cursor is not visible. For example, when you load a font with 12-pixel width, the cursor width is 16 pixels and when the cursor is displayed, 4 pixels of the next character are not visible. The reason is this: atyfb_cursor is called with proper parameters to load an image that is 12-pixel wide. However, the number is aligned on the next 8-pixel boundary on the line "unsigned int width = (cursor->image.width + 7) >> 3;" and the whole function acts as it is was loading a 16-pixel image. This patch fixes it so that the value written to the framebuffer is padded with 0xaaaa (the transparent pattern) when the image size it not a multiple of 8 pixels. The transparent pattern causes that the cursor will not interfere with the next character. Signed-off-by: Mikulas Patocka Signed-off-by: Tomi Valkeinen Signed-off-by: Ben Hutchings commit 1a2417a20f3733dac45d91b1b0d7cd58260ff587 Author: Mikulas Patocka Date: Thu Jan 23 14:41:09 2014 -0500 mach64: use unaligned access commit c29dd8696dc5dbd50b3ac441b8a26751277ba520 upstream. This patch fixes mach64 to use unaligned access to the font bitmap. This fixes unaligned access warning on sparc64 when 14x8 font is loaded. On x86(64), unaligned access is handled in hardware, so both functions le32_to_cpup and get_unaligned_le32 perform the same operation. On RISC machines, unaligned access is not handled in hardware, so we better use get_unaligned_le32 to avoid the unaligned trap and warning. Signed-off-by: Mikulas Patocka Signed-off-by: Tomi Valkeinen Signed-off-by: Ben Hutchings commit eda5fd3e2bf03fd7351a9573696d5ce63e07fde2 Author: Mikulas Patocka Date: Thu Jan 23 14:39:29 2014 -0500 framebuffer: fix cfb_copyarea commit 00a9d699bc85052d2d3ed56251cd928024ce06a3 upstream. The function cfb_copyarea is buggy when the copy operation is not aligned on long boundary (4 bytes on 32-bit machines, 8 bytes on 64-bit machines). How to reproduce: - use x86-64 machine - use a framebuffer driver without acceleration (for example uvesafb) - set the framebuffer to 8-bit depth (for example fbset -a 1024x768-60 -depth 8) - load a font with character width that is not a multiple of 8 pixels note: the console-tools package cannot load a font that has width different from 8 pixels. You need to install the packages "kbd" and "console-terminus" and use the program "setfont" to set font width (for example: setfont Uni2-Terminus20x10) - move some text left and right on the bash command line and you get a screen corruption To expose more bugs, put this line to the end of uvesafb_init_info: info->flags |= FBINFO_HWACCEL_COPYAREA | FBINFO_READS_FAST; - Now framebuffer console will use cfb_copyarea for console scrolling. You get a screen corruption when console is scrolled. This patch is a rewrite of cfb_copyarea. It fixes the bugs, with this patch, console scrolling in 8-bit depth with a font width that is not a multiple of 8 pixels works fine. The cfb_copyarea code was very buggy and it looks like it was written and never tried with non-8-pixel font. Signed-off-by: Mikulas Patocka Signed-off-by: Tomi Valkeinen Signed-off-by: Ben Hutchings commit ac572a610a0d862efb46aa8c51088624e1f3cad6 Author: Mikulas Patocka Date: Thu Jan 23 14:39:04 2014 -0500 matroxfb: restore the registers M_ACCESS and M_PITCH commit a772d4736641ec1b421ad965e13457c17379fc86 upstream. When X11 is running and the user switches back to console, the card modifies the content of registers M_MACCESS and M_PITCH in periodic intervals. This patch fixes it by restoring the content of these registers before issuing any accelerator command. Signed-off-by: Mikulas Patocka Signed-off-by: Tomi Valkeinen Signed-off-by: Ben Hutchings commit 2324f8a281c84b19aef7251cde4df51876328d42 Author: Will Deacon Date: Fri Feb 7 19:12:27 2014 +0100 ARM: 7954/1: mm: remove remaining domain support from ARMv6 commit b6ccb9803e90c16b212cf4ed62913a7591e79a39 upstream. CPU_32v6 currently selects CPU_USE_DOMAINS if CPU_V6 and MMU. This is because ARM 1136 r0pX CPUs lack the v6k extensions, and therefore do not have hardware thread registers. The lack of these registers requires the kernel to update the vectors page at each context switch in order to write a new TLS pointer. This write must be done via the userspace mapping, since aliasing caches can lead to expensive flushing when using kmap. Finally, this requires the vectors page to be mapped r/w for kernel and r/o for user, which has implications for things like put_user which must trigger CoW appropriately when targetting user pages. The upshot of all this is that a v6/v7 kernel makes use of domains to segregate kernel and user memory accesses. This has the nasty side-effect of making device mappings executable, which has been observed to cause subtle bugs on recent cores (e.g. Cortex-A15 performing a speculative instruction fetch from the GIC and acking an interrupt in the process). This patch solves this problem by removing the remaining domain support from ARMv6. A new memory type is added specifically for the vectors page which allows that page (and only that page) to be mapped as user r/o, kernel r/w. All other user r/o pages are mapped also as kernel r/o. Patch co-developed with Russell King. Signed-off-by: Will Deacon Signed-off-by: Russell King [bwh: Backported to 3.2: - Adjust filename, context - Drop condition on CONFIG_ARM_LPAE] Signed-off-by: Ben Hutchings commit 960bd8ae3e6402a0409b11ed18a7ba9aaf69c3c5 Author: Will Deacon Date: Sat Sep 1 05:22:12 2012 +0100 ARM: mm: introduce present, faulting entries for PAGE_NONE commit 26ffd0d43b186b0d5186354da8714a1c2d360df0 upstream. PROT_NONE mappings apply the page protection attributes defined by _P000 which translate to PAGE_NONE for ARM. These attributes specify an XN, RDONLY pte that is inaccessible to userspace. However, on kernels configured without support for domains, such a pte *is* accessible to the kernel and can be read via get_user, allowing tasks to read PROT_NONE pages via syscalls such as read/write over a pipe. This patch introduces a new software pte flag, L_PTE_NONE, that is set to identify faulting, present entries. Signed-off-by: Will Deacon [bwh: Backported to 3.2 as dependency of commit b6ccb9803e90 ('ARM: 7954/1: mm: remove remaining domain support from ARMv6'): - Drop 3-level changes - Adjust filename, context] Signed-off-by: Ben Hutchings commit 25f60b0397e698cce0473c7c9ff321b7765434d3 Author: David Fries Date: Wed Jan 15 22:29:12 2014 -0600 w1: fix w1_send_slave dropping a slave id commit 6b355b33a64fd6d8ead2b838ec16fb9b551f71e8 upstream. Previous logic, if (avail > 8) { store slave; return; } send data; clear; The logic error is, if there isn't space send the buffer and clear, but the slave wasn't added to the now empty buffer loosing that slave id. It also should have been "if (avail >= 8)" because when it is 8, there is space. Instead, if there isn't space send and clear the buffer, then there is always space for the slave id. Signed-off-by: David Fries Acked-by: Evgeniy Polyakov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit fd87fcdbd0d83ad29951002e8e320f9688a2dbd0 Author: Jani Nikula Date: Mon Jan 13 17:30:34 2014 +0200 drm/i915: quirk invert brightness for Acer Aspire 5336 commit 0f540c3a7cfb91c9d7a19eb0c95c24c5de1197d5 upstream. Since commit ee1452d7458451a7508e0663553ce88d63958157 Author: Jani Nikula Date: Fri Sep 20 15:05:30 2013 +0300 drm/i915: assume all GM45 Acer laptops use inverted backlight PWM failed and was later reverted in commit be505f643925e257087247b996cd8ece787c12af Author: Alexander van Heukelum Date: Sat Dec 28 21:00:39 2013 +0100 Revert "drm/i915: assume all GM45 Acer laptops use inverted backlight PWM" fix the individual broken machine instead. Note to backporters: http://patchwork.freedesktop.org/patch/17837/ is the patch you want for 3.13 and older. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54171 Reference: http://mid.gmane.org/DUB115-W7628C7C710EA51AA110CD4A5000@phx.gbl Signed-off-by: Jani Nikula Reviewed-by: Ville Syrjälä [danvet: Patch mangling for 3.14 plus adding the link to the original for 3.13.] Signed-off-by: Daniel Vetter Signed-off-by: Ben Hutchings commit dfd8ed909c79a24732c6cec4820c3e63e6c9c4c6 Author: Daniel Vetter Date: Fri Feb 15 18:35:30 2013 +0100 drm/i915: inverted brightness quirk for Acer Aspire 4736Z commit ac4199e0f047546aa40172785e26c82b54bbe811 upstream. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=53881 Cc: Jani Nikula Tested-by: Jani Monoses Signed-off-by: Daniel Vetter [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 5aa3bcddc8ddc4a8c09541d4b608bfa765631a6d Author: Sabrina Dubroca Date: Thu Mar 6 17:51:57 2014 +0100 ipv6: don't set DST_NOCOUNT for remotely added routes commit c88507fbad8055297c1d1e21e599f46960cbee39 upstream. DST_NOCOUNT should only be used if an authorized user adds routes locally. In case of routes which are added on behalf of router advertisments this flag must not get used as it allows an unlimited number of routes getting added remotely. Signed-off-by: Sabrina Dubroca Acked-by: Hannes Frederic Sowa Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Acked-by: David S. Miller Signed-off-by: Ben Hutchings commit b2d56d0f73e93d78a9983d1c4dc512a68f63ab98 Author: Dave Kleikamp Date: Fri Mar 14 10:42:01 2014 -0500 sparc64: don't treat 64-bit syscall return codes as 32-bit [ Upstream commit 1535bd8adbdedd60a0ee62e28fd5225d66434371 ] When checking a system call return code for an error, linux_sparc_syscall was sign-extending the lower 32-bit value and comparing it to -ERESTART_RESTARTBLOCK. lseek can return valid return codes whose lower 32-bits alone would indicate a failure (such as 4G-1). Use the whole 64-bit value to check for errors. Only the 32-bit path should sign extend the lower 32-bit value. Signed-off-by: Dave Kleikamp Acked-by: Bob Picco Acked-by: Allen Pais Cc: David S. Miller Cc: sparclinux@vger.kernel.org Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 8a937060cba9bbea7a2679dbe09679dc9bdaacfe Author: Paul Gortmaker Date: Thu Feb 13 13:57:44 2014 -0500 sparc32: fix build failure for arch_jump_label_transform [ Upstream commit 4f6500fff5f7644a03c46728fd7ef0f62fa6940b ] In arch/sparc/Kernel/Makefile, we see: obj-$(CONFIG_SPARC64) += jump_label.o However, the Kconfig selects HAVE_ARCH_JUMP_LABEL unconditionally for all SPARC. This in turn leads to the following failure when doing allmodconfig coverage builds: kernel/built-in.o: In function `__jump_label_update': jump_label.c:(.text+0x8560c): undefined reference to `arch_jump_label_transform' kernel/built-in.o: In function `arch_jump_label_transform_static': (.text+0x85cf4): undefined reference to `arch_jump_label_transform' make: *** [vmlinux] Error 1 Change HAVE_ARCH_JUMP_LABEL to be conditional on SPARC64 so that it matches the Makefile. Signed-off-by: Paul Gortmaker Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit ab29430a573553a8026704d4f5a30307a62d19de Author: Dave Kleikamp Date: Mon Dec 16 15:01:00 2013 -0600 Revert "sparc64: Fix __copy_{to,from}_user_inatomic defines." [ Upstream commit 16932237f2978a2265662f8de4af743b1f55a209 ] This reverts commit 145e1c0023585e0e8f6df22316308ec61c5066b2. This commit broke the behavior of __copy_from_user_inatomic when it is only partially successful. Instead of returning the number of bytes not copied, it now returns 1. This translates to the wrong value being returned by iov_iter_copy_from_user_atomic. xfstests generic/246 and LTP writev01 both fail on btrfs and nfs because of this. Signed-off-by: Dave Kleikamp Cc: Hugh Dickins Cc: David S. Miller Cc: sparclinux@vger.kernel.org Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 0fc0d40baf275f99cb635fb65af19a977e7ecd2a Author: oftedal Date: Fri Oct 18 22:28:29 2013 +0200 sparc: PCI: Fix incorrect address calculation of PCI Bridge windows on Simba-bridges [ Upstream commit 557fc5873ef178c4b3e1e36a42db547ecdc43f9b ] The SIMBA APB Bridges lacks the 'ranges' of-property describing the PCI I/O and memory areas located beneath the bridge. Faking this information has been performed by reading range registers in the APB bridge, and calculating the corresponding areas. In commit 01f94c4a6ced476ce69b895426fc29bfc48c69bd ("Fix sabre pci controllers with new probing scheme.") a bug was introduced into this calculation, causing the PCI memory areas to be calculated incorrectly: The shift size was set to be identical for I/O and MEM ranges, which is incorrect. This patch set the shift size of the MEM range back to the value used before 01f94c4a6ced476ce69b895426fc29bfc48c69bd. Signed-off-by: Kjetil Oftedal Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 710da494970f1d73c7df3fc0997e565cf4396e9d Author: Sasha Levin Date: Sat Mar 29 20:39:35 2014 -0400 rds: prevent dereference of a NULL device in rds_iw_laddr_check [ Upstream commit bf39b4247b8799935ea91d90db250ab608a58e50 ] Binding might result in a NULL device which is later dereferenced without checking. Signed-off-by: Sasha Levin Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit a0035ead18a914e0407b946876ac5be0ab09af61 Author: Dan Carpenter Date: Tue Apr 8 12:23:09 2014 +0300 isdnloop: several buffer overflows [ Upstream commit 7563487cbf865284dcd35e9ef5a95380da046737 ] There are three buffer overflows addressed in this patch. 1) In isdnloop_fake_err() we add an 'E' to a 60 character string and then copy it into a 60 character buffer. I have made the destination buffer 64 characters and I'm changed the sprintf() to a snprintf(). 2) In isdnloop_parse_cmd(), p points to a 6 characters into a 60 character buffer so we have 54 characters. The ->eazlist[] is 11 characters long. I have modified the code to return if the source buffer is too long. 3) In isdnloop_command() the cbuf[] array was 60 characters long but the max length of the string then can be up to 79 characters. I made the cbuf array 80 characters long and changed the sprintf() to snprintf(). I also removed the temporary "dial" buffer and changed it to use "p" directly. Unfortunately, we pass the "cbuf" string from isdnloop_command() to isdnloop_writecmd() which truncates anything over 60 characters to make it fit in card->omsg[]. (It can accept values up to 255 characters so long as there is a '\n' character every 60 characters). For now I have just fixed the memory corruption bug and left the other problems in this driver alone. Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit b6de0f964e567b8494c0172be16f2893452892df Author: YOSHIFUJI Hideaki / 吉藤英明 Date: Wed Apr 2 12:48:42 2014 +0900 isdnloop: Validate NUL-terminated strings from user. [ Upstream commit 77bc6bed7121936bb2e019a8c336075f4c8eef62 ] Return -EINVAL unless all of user-given strings are correctly NUL-terminated. Signed-off-by: YOSHIFUJI Hideaki Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit e78fe1b486df8633ee3e86573242eff51aa50007 Author: Pablo Neira Date: Tue Apr 1 19:38:44 2014 +0200 netlink: don't compare the nul-termination in nla_strcmp [ Upstream commit 8b7b932434f5eee495b91a2804f5b64ebb2bc835 ] nla_strcmp compares the string length plus one, so it's implicitly including the nul-termination in the comparison. int nla_strcmp(const struct nlattr *nla, const char *str) { int len = strlen(str) + 1; ... d = memcmp(nla_data(nla), str, len); However, if NLA_STRING is used, userspace can send us a string without the nul-termination. This is a problem since the string comparison will not match as the last byte may be not the nul-termination. Fix this by skipping the comparison of the nul-termination if the attribute data is nul-terminated. Suggested by Thomas Graf. Cc: Florian Westphal Cc: Thomas Graf Signed-off-by: Pablo Neira Ayuso Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 4af949fdc4252fd05fe318536e1bf03d1f533e0d Author: Hannes Frederic Sowa Date: Mon Mar 31 20:14:10 2014 +0200 ipv6: some ipv6 statistic counters failed to disable bh [ Upstream commit 43a43b6040165f7b40b5b489fe61a4cb7f8c4980 ] After commit c15b1ccadb323ea ("ipv6: move DAD and addrconf_verify processing to workqueue") some counters are now updated in process context and thus need to disable bh before doing so, otherwise deadlocks can happen on 32-bit archs. Fabio Estevam noticed this while while mounting a NFS volume on an ARM board. As a compensation for missing this I looked after the other *_STATS_BH and found three other calls which need updating: 1) icmp6_send: ip6_fragment -> icmpv6_send -> icmp6_send (error handling) 2) ip6_push_pending_frames: rawv6_sendmsg -> rawv6_push_pending_frames -> ... (only in case of icmp protocol with raw sockets in error handling) 3) ping6_v6_sendmsg (error handling) Fixes: c15b1ccadb323ea ("ipv6: move DAD and addrconf_verify processing to workqueue") Reported-by: Fabio Estevam Tested-by: Fabio Estevam Cc: Eric Dumazet Signed-off-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 4399eeb660a1fc58c4dddaece8ce779841f83ecb Author: Paul Durrant Date: Fri Mar 28 11:39:05 2014 +0000 xen-netback: remove pointless clause from if statement [ Upstream commit 0576eddf24df716d8570ef8ca11452a9f98eaab2 ] This patch removes a test in start_new_rx_buffer() that checks whether a copy operation is less than MAX_BUFFER_OFFSET in length, since MAX_BUFFER_OFFSET is defined to be PAGE_SIZE and the only caller of start_new_rx_buffer() already limits copy operations to PAGE_SIZE or less. Signed-off-by: Paul Durrant Cc: Ian Campbell Cc: Wei Liu Cc: Sander Eikelenboom Reported-By: Sander Eikelenboom Tested-By: Sander Eikelenboom Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 4334fca3512d179726666ad18459965916a1f189 Author: Michael S. Tsirkin Date: Thu Mar 27 12:53:37 2014 +0200 vhost: validate vhost_get_vq_desc return value [ Upstream commit a39ee449f96a2cd44ce056d8a0a112211a9b1a1f ] vhost fails to validate negative error code from vhost_get_vq_desc causing a crash: we are using -EFAULT which is 0xfffffff2 as vector size, which exceeds the allocated size. The code in question was introduced in commit 8dd014adfea6f173c1ef6378f7e5e7924866c923 vhost-net: mergeable buffers support CVE-2014-0055 Signed-off-by: Michael S. Tsirkin Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit cb505037a28ad1d8c378b40366e17fbbc44d10e6 Author: Michael S. Tsirkin Date: Thu Mar 27 12:00:26 2014 +0200 vhost: fix total length when packets are too short [ Upstream commit d8316f3991d207fe32881a9ac20241be8fa2bad0 ] When mergeable buffers are disabled, and the incoming packet is too large for the rx buffer, get_rx_bufs returns success. This was intentional in order for make recvmsg truncate the packet and then handle_rx would detect err != sock_len and drop it. Unfortunately we pass the original sock_len to recvmsg - which means we use parts of iov not fully validated. Fix this up by detecting this overrun and doing packet drop immediately. CVE-2014-0077 Signed-off-by: Michael S. Tsirkin Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit ea1e320ea1ab61681ab8e093bc4f48cf79a04543 Author: lucien Date: Mon Mar 17 12:51:01 2014 +0800 ipv6: ip6_append_data_mtu do not handle the mtu of the second fragment properly [ Upstream commit e367c2d03dba4c9bcafad24688fadb79dd95b218 ] In ip6_append_data_mtu(), when the xfrm mode is not tunnel(such as transport),the ipsec header need to be added in the first fragment, so the mtu will decrease to reserve space for it, then the second fragment come, the mtu should be turn back, as the commit 0c1833797a5a6ec23ea9261d979aa18078720b74 said. however, in the commit a493e60ac4bbe2e977e7129d6d8cbb0dd236be, it use *mtu = min(*mtu, ...) to change the mtu, which lead to the new mtu is alway equal with the first fragment's. and cannot turn back. when I test through ping6 -c1 -s5000 $ip (mtu=1280): ...frag (0|1232) ESP(spi=0x00002000,seq=0xb), length 1232 ...frag (1232|1216) ...frag (2448|1216) ...frag (3664|1216) ...frag (4880|164) which should be: ...frag (0|1232) ESP(spi=0x00001000,seq=0x1), length 1232 ...frag (1232|1232) ...frag (2464|1232) ...frag (3696|1232) ...frag (4928|116) so delete the min() when change back the mtu. Signed-off-by: Xin Long Fixes: 75a493e60ac4bb ("ipv6: ip6_append_data_mtu did not care about pmtudisc and frag_size") Acked-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 49ff127930d7c4a3e4b3f163af77e8ad0cda63b0 Author: Heiner Kallweit Date: Wed Mar 12 22:13:19 2014 +0100 ipv6: Avoid unnecessary temporary addresses being generated [ Upstream commit ecab67015ef6e3f3635551dcc9971cf363cc1cd5 ] tmp_prefered_lft is an offset to ifp->tstamp, not now. Therefore age needs to be added to the condition. Age calculation in ipv6_create_tempaddr is different from the one in addrconf_verify and doesn't consider ADDRCONF_TIMER_FUZZ_MINUS. This can cause age in ipv6_create_tempaddr to be less than the one in addrconf_verify and therefore unnecessary temporary address to be generated. Use age calculation as in addrconf_modify to avoid this. Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit d46880faad42eea3c68a525fec579bcf104d2f55 Author: Matthew Leach Date: Tue Mar 11 11:58:27 2014 +0000 net: socket: error on a negative msg_namelen [ Upstream commit dbb490b96584d4e958533fb637f08b557f505657 ] When copying in a struct msghdr from the user, if the user has set the msg_namelen parameter to a negative value it gets clamped to a valid size due to a comparison between signed and unsigned values. Ensure the syscall errors when the user passes in a negative value. Signed-off-by: Matthew Leach Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit c99f58d722f7566041f88cea72c78785e717ce72 Author: Peter Boström Date: Mon Mar 10 16:17:15 2014 +0100 vlan: Set correct source MAC address with TX VLAN offload enabled [ Upstream commit dd38743b4cc2f86be250eaf156cf113ba3dd531a ] With TX VLAN offload enabled the source MAC address for frames sent using the VLAN interface is currently set to the address of the real interface. This is wrong since the VLAN interface may be configured with a different address. The bug was introduced in commit 2205369a314e12fcec4781cc73ac9c08fc2b47de ("vlan: Fix header ops passthru when doing TX VLAN offload."). This patch sets the source address before calling the create function of the real interface. Signed-off-by: Peter Boström Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit e7177969baa17560848666cb547b6c05ca86297a Author: Eric Dumazet Date: Tue Mar 25 18:42:27 2014 -0700 net: unix: non blocking recvmsg() should not return -EINTR [ Upstream commit de1443916791d75fdd26becb116898277bb0273f ] Some applications didn't expect recvmsg() on a non blocking socket could return -EINTR. This possibility was added as a side effect of commit b3ca9b02b00704 ("net: fix multithreaded signal handling in unix recv routines"). To hit this bug, you need to be a bit unlucky, as the u->readlock mutex is usually held for very small periods. Fixes: b3ca9b02b00704 ("net: fix multithreaded signal handling in unix recv routines") Signed-off-by: Eric Dumazet Cc: Rainer Weikusat Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 36672f6303a461e8dee4e1eab5a80bdfb31795f7 Author: Linus Lüssing Date: Tue Mar 4 03:57:35 2014 +0100 bridge: multicast: add sanity check for query source addresses [ Upstream commit 6565b9eeef194afbb3beec80d6dd2447f4091f8c ] MLD queries are supposed to have an IPv6 link-local source address according to RFC2710, section 4 and RFC3810, section 5.1.14. This patch adds a sanity check to ignore such broken MLD queries. Without this check, such malformed MLD queries can result in a denial of service: The queries are ignored by any MLD listener therefore they will not respond with an MLD report. However, without this patch these malformed MLD queries would enable the snooping part in the bridge code, potentially shutting down the according ports towards these hosts for multicast traffic as the bridge did not learn about these listeners. Reported-by: Jan Stancek Signed-off-by: Linus Lüssing Reviewed-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 46e9c408e8537254f89a5b6b930fdda85eaba143 Author: Daniel Borkmann Date: Tue Mar 4 16:35:51 2014 +0100 net: sctp: fix skb leakage in COOKIE ECHO path of chunk->auth_chunk [ Upstream commit c485658bae87faccd7aed540fd2ca3ab37992310 ] While working on ec0223ec48a9 ("net: sctp: fix sctp_sf_do_5_1D_ce to verify if we/peer is AUTH capable"), we noticed that there's a skb memory leakage in the error path. Running the same reproducer as in ec0223ec48a9 and by unconditionally jumping to the error label (to simulate an error condition) in sctp_sf_do_5_1D_ce() receive path lets kmemleak detector bark about the unfreed chunk->auth_chunk skb clone: Unreferenced object 0xffff8800b8f3a000 (size 256): comm "softirq", pid 0, jiffies 4294769856 (age 110.757s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 89 ab 75 5e d4 01 58 13 00 00 00 00 00 00 00 00 ..u^..X......... backtrace: [] kmemleak_alloc+0x4e/0xb0 [] kmem_cache_alloc+0xc8/0x210 [] skb_clone+0x49/0xb0 [] sctp_endpoint_bh_rcv+0x1d9/0x230 [sctp] [] sctp_inq_push+0x4c/0x70 [sctp] [] sctp_rcv+0x82e/0x9a0 [sctp] [] ip_local_deliver_finish+0xa8/0x210 [] nf_reinject+0xbf/0x180 [] nfqnl_recv_verdict+0x1d2/0x2b0 [nfnetlink_queue] [] nfnetlink_rcv_msg+0x14b/0x250 [nfnetlink] [] netlink_rcv_skb+0xa9/0xc0 [] nfnetlink_rcv+0x23f/0x408 [nfnetlink] [] netlink_unicast+0x168/0x250 [] netlink_sendmsg+0x2e1/0x3f0 [] sock_sendmsg+0x8b/0xc0 [] ___sys_sendmsg+0x369/0x380 What happens is that commit bbd0d59809f9 clones the skb containing the AUTH chunk in sctp_endpoint_bh_rcv() when having the edge case that an endpoint requires COOKIE-ECHO chunks to be authenticated: ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ----------> <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] --------- ------------------ AUTH; COOKIE-ECHO ----------------> <-------------------- COOKIE-ACK --------------------- When we enter sctp_sf_do_5_1D_ce() and before we actually get to the point where we process (and subsequently free) a non-NULL chunk->auth_chunk, we could hit the "goto nomem_init" path from an error condition and thus leave the cloned skb around w/o freeing it. The fix is to centrally free such clones in sctp_chunk_destroy() handler that is invoked from sctp_chunk_free() after all refs have dropped; and also move both kfree_skb(chunk->auth_chunk) there, so that chunk->auth_chunk is either NULL (since sctp_chunkify() allocs new chunks through kmem_cache_zalloc()) or non-NULL with a valid skb pointer. chunk->skb and chunk->auth_chunk are the only skbs in the sctp_chunk structure that need to be handeled. While at it, we should use consume_skb() for both. It is the same as dev_kfree_skb() but more appropriately named as we are not a device but a protocol. Also, this effectively replaces the kfree_skb() from both invocations into consume_skb(). Functions are the same only that kfree_skb() assumes that the frame was being dropped after a failure (e.g. for tools like drop monitor), usage of consume_skb() seems more appropriate in function sctp_chunk_destroy() though. Fixes: bbd0d59809f9 ("[SCTP]: Implement the receive and verification of AUTH chunk") Signed-off-by: Daniel Borkmann Cc: Vlad Yasevich Cc: Neil Horman Acked-by: Vlad Yasevich Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings