- 07 Jul, 2015 5 commits
-
-
Chris Lesiak authored
commit adba6575 upstream. When configured via device tree, the associated iio device needs to be measuring voltage for the conversion to resistance to be correct. Return -EINVAL if that is not the case. Signed-off-by:
Chris Lesiak <chris.lesiak@licor.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Borislav Petkov authored
commit 17fea54b upstream. Derek noticed that a critical MCE gets reported with the wrong error type description: [Hardware Error]: CPU 34: Machine Check Exception: 5 Bank 9: f200003f000100b0 [Hardware Error]: RIP !INEXACT! 10:<ffffffff812e14c1> {intel_idle+0xb1/0x170} [Hardware Error]: TSC 49587b8e321cb [Hardware Error]: PROCESSOR 0:306e4 TIME 1431561296 SOCKET 1 APIC 29 [Hardware Error]: Some CPUs didn't answer in synchronization [Hardware Error]: Machine check: Invalid ^^^^^^^ The last line with 'Invalid' should have printed the high level MCE error type description we get from mce_severity, i.e. something like: [Hardware Error]: Machine check: Action required: data load error in a user process this happens due to the fact that mce_no_way_out() iterates over all MCA banks and possibly overwrites the @msg argument which is used in the panic printing later. Change behavior to take the message of only and the (last) critical MCE it detects. Reported-by:
Derek <denc716@gmail.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Link: http://lkml.kernel.org/r/1431936437-25286-3-git-send-email-bp@alien8.deSigned-off-by:
Ingo Molnar <mingo@kernel.org> [ kamal: backport to 3.13-stable: context ] Signed-off-by:
-
Mark Rutland authored
commit 965278dc upstream. At boot time we round the memblock limit down to section size in an attempt to ensure that we will have mapped this RAM with section mappings prior to allocating from it. When mapping RAM we iterate over PMD-sized chunks, creating these section mappings. Section mappings are only created when the end of a chunk is aligned to section size. Unfortunately, with classic page tables (where PMD_SIZE is 2 * SECTION_SIZE) this means that if a chunk is between 1M and 2M in size the first 1M will not be mapped despite having been accounted for in the memblock limit. This has been observed to result in page tables being allocated from unmapped memory, causing boot-time hangs. This patch modifies the memblock limit rounding to always round down to PMD_SIZE instead of SECTION_SIZE. For classic MMU this means that we will round the memblock limit down to a 2M boundary, matching the limits on section mappings, and preventing allocations from unmapped memory. For LPAE there should be no change as PMD_SIZE == SECTION_SIZE. Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Reported-by:
Stefan Agner <stefan@agner.ch> Tested-by:
Laura Abbott <labbott@redhat.com> Tested-by:
Hans de Goede <hdegoede@redhat.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Steve Capper <steve.capper@linaro.org> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> [ kamal: backport to 3.13-stable: block_start, block_end rename ] Signed-off-by:
-
Philippe Reynes authored
commit a29ef819 upstream. According to the imx27 documentation, fec has a 4 Kbyte memory space map. Moreover, the actual 16 Kbyte mapping overlaps the SCC (Security Controller) memory register space. So, we reduce the memory register space to 4 Kbyte. Signed-off-by:
Philippe Reynes <tremyfr@gmail.com> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Fixes: 9f0749e3 ("ARM i.MX27: Add devicetree support") Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
-
Michael Brunner authored
commit f230e8ff upstream. This patch fixes an inverted return value of the gpio get_direction function. The wrong value causes the direction sysfs entry and GPIO debugfs file to indicate incorrect GPIO direction settings. In some cases it also prevents setting GPIO output values. The problem is also present in all other stable kernel versions since linux-3.12. Reported-by:
Jochen Henneberg <jh@henneberg-systemdesign.com> Signed-off-by:
Michael Brunner <michael.brunner@kontron.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
- 06 Jul, 2015 1 commit
-
-
Kamal Mostafa authored
[3.13-stable only] Revert "ARM: net: delegate filter to kernel interpreter when imm_offset() return value can't fit into 12bits." This reverts commit a39d787c. Not suitable for 3.13 (no bpf_jit_binary_free). Cc: Brad Figg <brad.figg@canonical.com> Signed-off-by:
-
- 30 Jun, 2015 6 commits
-
-
Paolo Bonzini authored
commit ce40cd3f upstream. Malicious (or egregiously buggy) userspace can trigger it, but it should never happen in normal operation. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Reference: CVE-2015-4692 Signed-off-by:
-
Ben Hutchings authored
pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec, the first time atomically and the second time not. The second attempt needs to continue from the iovec position, pipe buffer offset and remaining length where the first attempt failed, but currently the pipe buffer offset and remaining length are reset. This will corrupt the piped data (possibly also leading to an information leak between processes) and may also corrupt kernel memory. This was fixed upstream by commits f0d1bec9 ("new helper: copy_page_from_iter()") and 637b58c2 ("switch pipe_read() to copy_page_to_iter()"), but those aren't suitable for stable. This fix for older kernel versions was made by Seth Jennings for RHEL and I have extracted it from their update. CVE-2015-1805 References: https://bugzilla.redhat.com/show_bug.cgi?id=1202855Signed-off-by:Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
James Smart authored
commit 27f344eb upstream. Add a memory barrier to ensure the valid bit is read before any of the cqe payload is read. This fixes an issue seen on Power where the cqe payload was getting loaded before the valid bit. When this occurred, we saw an iotag out of range error when a command completed, but since the iotag looked invalid the command didn't get completed to scsi core. Later we hit the command timeout, attempted to abort the command, then waited for the aborted command to get returned. Since the adapter already returned the command, we timeout waiting, and end up escalating EEH all the way to host reset. This patch fixes this issue. Signed-off-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
James Smart <james.smart@emulex.com> --- lpfc_sli.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) Signed-off-by:
Christoph Hellwig <hch@lst.de> Cc: Chris J Arges <chris.j.arges@canonical.com> Signed-off-by:
-
Sasha Levin authored
commit 161f873b upstream. We used to read file_handle twice. Once to get the amount of extra bytes, and once to fetch the entire structure. This may be problematic since we do size verifications only after the first read, so if the number of extra bytes changes in userspace between the first and second calls, we'll have an incoherent view of file_handle. Instead, read the constant size once, and copy that over to the final structure without having to re-read it again. Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Reference: CVE-2015-1420 Cc: Moritz Muehlenhoff <jmm@debian.org> Signed-off-by:
-
Kamal Mostafa authored
This reverts commit bb551e64. New feature; not qualified for -stable kernels. Signed-off-by:
-
Kamal Mostafa authored
[3.13-stable only] Revert "Drivers: hv: vmbus: Correcting truncation error for constant HV_CRASH_CTL_CRASH_NOTIFY" This reverts commit a40cec45. New feature; not qualified for -stable kernels. Signed-off-by:
-
- 22 Jun, 2015 1 commit
-
-
Kamal Mostafa authored
Signed-off-by:
-
- 18 Jun, 2015 1 commit
-
-
Christian König authored
commit 7c0411d2 upstream. We have that bug for years and some users report side effects when fixing it on older hardware. So revert it for VM_CONTEXT0_PAGE_TABLE_END_ADDR, but keep it for VM 1-15. Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
- 17 Jun, 2015 26 commits
-
-
Shawn Bohrer authored
[ Upstream commit 6e540309 ] 421b3885 "udp: ipv4: Add udp early demux" introduced a regression that allowed sockets bound to INADDR_ANY to receive packets from multicast groups that the socket had not joined. For example a socket that had joined 224.168.2.9 could also receive packets from 225.168.2.9 despite not having joined that group if ip_early_demux is enabled. Fix this by calling ip_check_mc_rcu() in udp_v4_early_demux() to verify that the multicast packet is indeed ours. Signed-off-by:
Shawn Bohrer <sbohrer@rgmadvisors.com> Reported-by:
Yurij M. Plotnikov <Yurij.Plotnikov@oktetlabs.ru> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Ian Campbell authored
[ Upstream commit 31a41898 ] When we come to tear things down in netback_remove() and generate the uevent it is possible that the xenstore directory has already been removed (details below). In such cases netback_uevent() won't be able to read the hotplug script and will write a xenstore error node. A recent change to the hypervisor exposed this race such that we now sometimes lose it (where apparently we didn't ever before). Instead read the hotplug script configuration during setup and use it for the lifetime of the backend device. The apparently more obvious fix of moving the transition to state=Closed in netback_remove() to after the uevent does not work because it is possible that we are already in state=Closed (in reaction to the guest having disconnected as it shutdown). Being already in Closed means the toolstack is at liberty to start tearing down the xenstore directories. In principal it might be possible to arrange to unregister the device sooner (e.g on transition to Closing) such that xenstore would still be there but this state machine is fragile and prone to anger... A modern Xen system only relies on the hotplug uevent for driver domains, when the backend is in the same domain as the toolstack it will run the necessary setup/teardown directly in the correct sequence wrt xenstore changes. Signed-off-by:
Ian Campbell <ian.campbell@citrix.com> Acked-by:
Wei Liu <wei.liu2@citrix.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit beb39db5 ] We have two problems in UDP stack related to bogus checksums : 1) We return -EAGAIN to application even if receive queue is not empty. This breaks applications using edge trigger epoll() 2) Under UDP flood, we can loop forever without yielding to other processes, potentially hanging the host, especially on non SMP. This patch is an attempt to make things better. We might in the future add extra support for rt applications wanting to better control time spent doing a recv() in a hostile environment. For example we could validate checksums before queuing packets in socket receive queue. Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Willem de Bruijn <willemb@google.com> Signed-off-by:
-
WANG Cong authored
[ Upstream commit 86e363dc ] For mq qdisc, we add per tx queue qdisc to root qdisc for display purpose, however, that happens too early, before the new dev->qdisc is finally set, this causes q->list points to an old root qdisc which is going to be freed right before assigning with a new one. Fix this by moving ->attach() after setting dev->qdisc. For the record, this fixes the following crash: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 975 at lib/list_debug.c:59 __list_del_entry+0x5a/0x98() list_del corruption. prev->next should be ffff8800d1998ae8, but was 6b6b6b6b6b6b6b6b CPU: 1 PID: 975 Comm: tc Not tainted 4.1.0-rc4+ #1019 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 0000000000000009 ffff8800d73fb928 ffffffff81a44e7f 0000000047574756 ffff8800d73fb978 ffff8800d73fb968 ffffffff810790da ffff8800cfc4cd20 ffffffff814e725b ffff8800d1998ae8 ffffffff82381250 0000000000000000 Call Trace: [<ffffffff81a44e7f>] dump_stack+0x4c/0x65 [<ffffffff810790da>] warn_slowpath_common+0x9c/0xb6 [<ffffffff814e725b>] ? __list_del_entry+0x5a/0x98 [<ffffffff81079162>] warn_slowpath_fmt+0x46/0x48 [<ffffffff81820eb0>] ? dev_graft_qdisc+0x5e/0x6a [<ffffffff814e725b>] __list_del_entry+0x5a/0x98 [<ffffffff814e72a7>] list_del+0xe/0x2d [<ffffffff81822f05>] qdisc_list_del+0x1e/0x20 [<ffffffff81820cd1>] qdisc_destroy+0x30/0xd6 [<ffffffff81822676>] qdisc_graft+0x11d/0x243 [<ffffffff818233c1>] tc_get_qdisc+0x1a6/0x1d4 [<ffffffff810b5eaf>] ? mark_lock+0x2e/0x226 [<ffffffff817ff8f5>] rtnetlink_rcv_msg+0x181/0x194 [<ffffffff817ff72e>] ? rtnl_lock+0x17/0x19 [<ffffffff817ff72e>] ? rtnl_lock+0x17/0x19 [<ffffffff817ff774>] ? __rtnl_unlock+0x17/0x17 [<ffffffff81855dc6>] netlink_rcv_skb+0x4d/0x93 [<ffffffff817ff756>] rtnetlink_rcv+0x26/0x2d [<ffffffff818544b2>] netlink_unicast+0xcb/0x150 [<ffffffff81161db9>] ? might_fault+0x59/0xa9 [<ffffffff81854f78>] netlink_sendmsg+0x4fa/0x51c [<ffffffff817d6e09>] sock_sendmsg_nosec+0x12/0x1d [<ffffffff817d8967>] sock_sendmsg+0x29/0x2e [<ffffffff817d8cf3>] ___sys_sendmsg+0x1b4/0x23a [<ffffffff8100a1b8>] ? native_sched_clock+0x35/0x37 [<ffffffff810a1d83>] ? sched_clock_local+0x12/0x72 [<ffffffff810a1fd4>] ? sched_clock_cpu+0x9e/0xb7 [<ffffffff810def2a>] ? current_kernel_time+0xe/0x32 [<ffffffff810b4bc5>] ? lock_release_holdtime.part.29+0x71/0x7f [<ffffffff810ddebf>] ? read_seqcount_begin.constprop.27+0x5f/0x76 [<ffffffff810b6292>] ? trace_hardirqs_on_caller+0x17d/0x199 [<ffffffff811b14d5>] ? __fget_light+0x50/0x78 [<ffffffff817d9808>] __sys_sendmsg+0x42/0x60 [<ffffffff817d9838>] SyS_sendmsg+0x12/0x1c [<ffffffff81a50e97>] system_call_fastpath+0x12/0x6f ---[ end trace ef29d3fb28e97ae7 ]--- For long term, we probably need to clean up the qdisc_graft() code in case it hides other bugs like this. Fixes: 95dc1929 ("pkt_sched: give visibility to mq slave qdiscs") Cc: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Acked-by:
-
Mark Salyzyn authored
[ Upstream commit b48732e4 ] got a rare NULL pointer dereference in clear_bit Signed-off-by:
Mark Salyzyn <salyzyn@android.com> Acked-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> ---- v2: switch to sock_flag(sk, SOCK_DEAD) and added net/caif/caif_socket.c v3: return -ECONNRESET in upstream caller of wait function for SOCK_DEAD Signed-off-by:
-
Richard Cochran authored
[ Upstream commit 397a253a ] Currently, the calibration function that corrects the initial offsets among multiple devices only works the first time. If the function is called more than once, the calibration fails and bogus offsets will be programmed into the devices. In a well hidden spot, the device documentation tells that trigger indexes 0 and 1 are special in allowing the TRIG_IF_LATE flag to actually work. This patch fixes the issue by using one of the special triggers during the recalibration method. Signed-off-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
-
Alexei Starovoitov authored
[ Upstream commit 3f7352bf ] x86 has variable length encoding. x86 JIT compiler is trying to pick the shortest encoding for given bpf instruction. While doing so the jump targets are changing, so JIT is doing multiple passes over the program. Typical program needs 3 passes. Some very short programs converge with 2 passes. Large programs may need 4 or 5. But specially crafted bpf programs may hit the pass limit and if the program converges on the last iteration the JIT compiler will be producing an image full of 'int 3' insns. Fix this corner case by doing final iteration over bpf program. Fixes: 0a14842f ("net: filter: Just In Time compiler for x86-64") Reported-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
Alexei Starovoitov <ast@plumgrid.com> Tested-by:
-
Vlad Yasevich authored
[ Upstream commit d66bf7dd ] The code in __netdev_upper_dev_link() has an over-stringent loop detection logic that actually prevents valid configurations from working correctly. In particular, the logic returns an error if an upper device is already in the list of all upper devices for a given dev. This particular check seems to be a overzealous as it disallows perfectly valid configurations. For example: # ip l a link eth0 name eth0.10 type vlan id 10 # ip l a dev br0 typ bridge # ip l s eth0.10 master br0 # ip l s eth0 master br0 <--- Will fail If you switch the last two commands (add eth0 first), then both will succeed. If after that, you remove eth0 and try to re-add it, it will fail! It appears to be enough to simply check adj_list to keeps things safe. I've tried stacking multiple devices multiple times in all different combinations, and either rx_handler registration prevented the stacking of the device linking cought the error. Signed-off-by:
Vladislav Yasevich <vyasevic@redhat.com> Acked-by:
Jiri Pirko <jiri@resnulli.us> Acked-by:
Veaceslav Falico <vfalico@gmail.com> Signed-off-by:
-
Michal Kubeček authored
commit 27596472 upstream. When replacing an IPv6 multipath route with "ip route replace", i.e. NLM_F_CREATE | NLM_F_REPLACE, fib6_add_rt2node() replaces only first matching route without fixing its siblings, resulting in corrupted siblings linked list; removing one of the siblings can then end in an infinite loop. IPv6 ECMP implementation is a bit different from IPv4 so that route replacement cannot work in exactly the same way. This should be a reasonable approximation: 1. If the new route is ECMP-able and there is a matching ECMP-able one already, replace it and all its siblings (if any). 2. If the new route is ECMP-able and no matching ECMP-able route exists, replace first matching non-ECMP-able (if any) or just add the new one. 3. If the new route is not ECMP-able, replace first matching non-ECMP-able route (if any) or add the new route. We also need to remove the NLM_F_REPLACE flag after replacing old route(s) by first nexthop of an ECMP route so that each subsequent nexthop does not replace previous one. Fixes: 51ebd318 ("ipv6: add support of equal cost multipath (ECMP)") Signed-off-by:
Michal Kubecek <mkubecek@suse.cz> Acked-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by:
-
Michal Kubeček authored
commit 35f1b4e9 upstream. If adding a nexthop of an IPv6 multipath route fails, comment in ip6_route_multipath() says we are going to delete all nexthops already added. However, current implementation deletes even the routes it hasn't even tried to add yet. For example, running ip route add 1234:5678::/64 \ nexthop via fe80::aa dev dummy1 \ nexthop via fe80::bb dev dummy1 \ nexthop via fe80::cc dev dummy1 twice results in removing all routes first command added. Limit the second (delete) run to nexthops that succeeded in the first (add) run. Fixes: 51ebd318 ("ipv6: add support of equal cost multipath (ECMP)") Signed-off-by:
-
Eric W. Biederman authored
commit 381c759d upstream. ip_error does not check if in_dev is NULL before dereferencing it. IThe following sequence of calls is possible: CPU A CPU B ip_rcv_finish ip_route_input_noref() ip_route_input_slow() inetdev_destroy() dst_input() With the result that a network device can be destroyed while processing an input packet. A crash was triggered with only unicast packets in flight, and forwarding enabled on the only network device. The error condition was created by the removal of the network device. As such it is likely the that error code was -EHOSTUNREACH, and the action taken by ip_error (if in_dev had been accessible) would have been to not increment any counters and to have tried and likely failed to send an icmp error as the network device is going away. Therefore handle this weird case by just dropping the packet if !in_dev. It will result in dropping the packet sooner, and will not result in an actual change of behavior. Fixes: 251da413 ("ipv4: Cache ip_error() routes even when not forwarding.") Reported-by:
Vittorio Gambaletta <linuxbugs@vittgam.net> Tested-by:
"Eric W. Biederman" <ebiederm@xmission.com> Acked-by:
-
Thadeu Lima de Souza Cascardo authored
commit 47cc84ce upstream. When more than a multicast address is present in a MLDv2 report, all but the first address is ignored, because the code breaks out of the loop if there has not been an error adding that address. This has caused failures when two guests connected through the bridge tried to communicate using IPv6. Neighbor discoveries would not be transmitted to the other guest when both used a link-local address and a static address. This only happens when there is a MLDv2 querier in the network. The fix will only break out of the loop when there is a failure adding a multicast address. The mdb before the patch: dev ovirtmgmt port vnet0 grp ff02::1:ff7d:6603 temp dev ovirtmgmt port vnet1 grp ff02::1:ff7d:6604 temp dev ovirtmgmt port bond0.86 grp ff02::2 temp After the patch: dev ovirtmgmt port vnet0 grp ff02::1:ff7d:6603 temp dev ovirtmgmt port vnet1 grp ff02::1:ff7d:6604 temp dev ovirtmgmt port bond0.86 grp ff02::fb temp dev ovirtmgmt port bond0.86 grp ff02::2 temp dev ovirtmgmt port bond0.86 grp ff02::d temp dev ovirtmgmt port vnet0 grp ff02::1:ff00:76 temp dev ovirtmgmt port bond0.86 grp ff02::16 temp dev ovirtmgmt port vnet1 grp ff02::1:ff00:77 temp dev ovirtmgmt port bond0.86 grp ff02::1:ff00:def temp dev ovirtmgmt port bond0.86 grp ff02::1:ffa1:40bf temp Fixes: 08b202b6 ("bridge br_multicast: IPv6 MLD support.") Reported-by:
Rik Theys <Rik.Theys@esat.kuleuven.be> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@redhat.com> Tested-by:
-
Florian Fainelli authored
commit 7e140696 upstream. RGMII interfaces come in multiple flavors: RGMII with transmit or receive internal delay, no delays at all, or delays in both direction. This change extends the initial check for PHY_INTERFACE_MODE_RGMII to cover all of these variants since EEE should be allowed for any of these modes, since it is a property of the RGMII, hence Gigabit PHY capability more than the RGMII electrical interface and its delays. Fixes: a59a4d19 ("phy: add the EEE support and the way to access to the MMD registers") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Tommi Rantala authored
commit f30bf2a5 upstream. Fix memory leak introduced in commit a0840e2e ("IPVS: netns, ip_vs_ctl local vars moved to ipvs struct."): unreferenced object 0xffff88005785b800 (size 2048): comm "(-localed)", pid 1434, jiffies 4294755650 (age 1421.089s) hex dump (first 32 bytes): bb 89 0b 83 ff ff ff ff b0 78 f0 4e 00 88 ff ff .........x.N.... 04 00 00 00 a4 01 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff8262ea8e>] kmemleak_alloc+0x4e/0xb0 [<ffffffff811fba74>] __kmalloc_track_caller+0x244/0x430 [<ffffffff811b88a0>] kmemdup+0x20/0x50 [<ffffffff823276b7>] ip_vs_control_net_init+0x1f7/0x510 [<ffffffff8231d630>] __ip_vs_init+0x100/0x250 [<ffffffff822363a1>] ops_init+0x41/0x190 [<ffffffff82236583>] setup_net+0x93/0x150 [<ffffffff82236cc2>] copy_net_ns+0x82/0x140 [<ffffffff810ab13d>] create_new_namespaces+0xfd/0x190 [<ffffffff810ab49a>] unshare_nsproxy_namespaces+0x5a/0xc0 [<ffffffff810833e3>] SyS_unshare+0x173/0x310 [<ffffffff8265cbd7>] system_call_fastpath+0x12/0x6f [<ffffffffffffffff>] 0xffffffffffffffff Fixes: a0840e2e ("IPVS: netns, ip_vs_ctl local vars moved to ipvs struct.") Signed-off-by:
Tommi Rantala <tt.rantala@gmail.com> Acked-by:
Julian Anastasov <ja@ssi.bg> Signed-off-by:
Simon Horman <horms@verge.net.au> Signed-off-by:
-
Harald Freudenberger authored
commit a1cae34e upstream. Multitheaded tests showed that the icv buffer in the current ghash implementation is not handled correctly. A move of this working ghash buffer value to the descriptor context fixed this. Code is tested and verified with an multithreaded application via af_alg interface. Signed-off-by:
Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by:
Gerald Schaefer <geraldsc@linux.vnet.ibm.com> Reported-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Ilya Dryomov authored
commit b0494532 upstream. This commit does two things. First, if there are any homeless lingering requests, we now request a new osdmap even if the osdmap that is being processed brought no changes, i.e. if a given lingering request turned homeless in one of the previous epochs and remained homeless in the current epoch. Not doing so leaves us with a stale osdmap and as a result we may miss our window for reestablishing the watch and lose notifies. MON=1 OSD=1: # cat linger-needmap.sh #!/bin/bash rbd create --size 1 test DEV=$(rbd map test) ceph osd out 0 rbd map dne/dne # obtain a new osdmap as a side effect (!) sleep 1 ceph osd in 0 rbd resize --size 2 test # rbd info test | grep size -> 2M # blockdev --getsize $DEV -> 1M N.B.: Not obtaining a new osdmap in between "osd out" and "osd in" above is enough to make it miss that resize notify, but that is a bug^Wlimitation of ceph watch/notify v1. Second, homeless lingering requests are now kicked just like those lingering requests whose mapping has changed. This is mainly to recognize that a homeless lingering request makes no sense and to preserve the invariant that a registered lingering request is not sitting on any of r_req_lru_item lists. This spares us a WARN_ON, which commit ba9d114e ("libceph: clear r_req_lru_item in __unregister_linger_request()") tried to fix the _wrong_ way. Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Reviewed-by:
Sage Weil <sage@redhat.com> Signed-off-by:
-
Mark Hounschell authored
commit 74856fbf upstream. 256 bytes per sector support has been broken since 2.6.X, and no-one stepped up to fix this. So disable support for it. Signed-off-by:
Mark Hounschell <dmarkh@cfl.rr.com> Signed-off-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
James Bottomley <JBottomley@Odin.com> Signed-off-by:
-
Ludovic Desroches authored
commit 60c8f783 upstream. clkdiv is declared as an u32 but it can be set to a negative value causing a huge divisor value. Change its type to int to avoid this case. Signed-off-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
David Henningsson authored
commit 6ffc0898 upstream. This patch adds support for Conexant HD Audio codecs CX20721, CX20722, CX20723 and CX20724. BugLink: https://bugs.launchpad.net/bugs/1454656Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Anton Blanchard authored
commit 5e95235c upstream. Recent toolchains force the TOC to be 256 byte aligned. We need to enforce this alignment in our linker script, otherwise pointers to our TOC variables (__toc_start, __prom_init_toc_start) could be incorrect. If they are bad, we die a few hundred instructions into boot. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Benjamin Tissoires authored
commit 3c0213d1 upstream. When the v3 hardware sees more than one finger, it uses the semi-mt protocol to report the touches. However, it currently works when num_fingers is 0, 1 or 2, but when it is 3 and above, it sends only 1 finger as if num_fingers was 1. This confuses userspace which knows how to deal with extra fingers when all the slots are used, but not when some are missing. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=90101Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Zidan Wang authored
commit 17fc2e0a upstream. According to the RM of wm8958, BCLK DIV 348 doesn't exist, correct it to 384. Signed-off-by:
Zidan Wang <zidan.wang@freescale.com> Acked-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Zidan Wang authored
commit 85e36a1f upstream. It should be "RINPUT3" instead of "LINPUT3" route to "Right Input Mixer". Signed-off-by:
-
K. Y. Srinivasan authored
commit dc45708c upstream. Set the SRB flags correctly when there is no data transfer. Without this change some IHV drivers will fail valid commands such as TEST_UNIT_READY. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Reviewed-by:
Long Li <longli@microsoft.com> Signed-off-by:
-
Xiao Guangrong authored
commit 0be0226f upstream. KVM may turn a user page to a kernel page when kernel writes a readonly user page if CR0.WP = 1. This shadow page entry will be reused after SMAP is enabled so that kernel is allowed to access this user page Fix it by setting SMAP && !CR0.WP into shadow page's role and reset mmu once CR4.SMAP is updated Signed-off-by:
Xiao Guangrong <guangrong.xiao@linux.intel.com> Signed-off-by:
-
Paolo Bonzini authored
commit 89876115 upstream. smep_andnot_wp is initialized in kvm_init_shadow_mmu and shadow pages should not be reused for different values of it. Thus, it has to be added to the mask in kvm_mmu_pte_write. Reviewed-by:
-
