- 06 Jan, 2016 40 commits
-
-
Hannes Frederic Sowa authored
[ Upstream commit 79462ad0 ] 郭永刚 reported that one could simply crash the kernel as root by using a simple program: int socket_fd; struct sockaddr_in addr; addr.sin_port = 0; addr.sin_addr.s_addr = INADDR_ANY; addr.sin_family = 10; socket_fd = socket(10,3,0x40000000); connect(socket_fd , &addr,16); AF_INET, AF_INET6 sockets actually only support 8-bit protocol identifiers. inet_sock's skc_protocol field thus is sized accordingly, thus larger protocol identifiers simply cut off the higher bits and store a zero in the protocol fields. This could lead to e.g. NULL function pointer because as a result of the cut off inet_num is zero and we call down to inet_autobind, which is NULL for raw sockets. kernel: Call Trace: kernel: [<ffffffff816db90e>] ? inet_autobind+0x2e/0x70 kernel: [<ffffffff816db9a4>] inet_dgram_connect+0x54/0x80 kernel: [<ffffffff81645069>] SYSC_connect+0xd9/0x110 kernel: [<ffffffff810ac51b>] ? ptrace_notify+0x5b/0x80 kernel: [<ffffffff810236d8>] ? syscall_trace_enter_phase2+0x108/0x200 kernel: [<ffffffff81645e0e>] SyS_connect+0xe/0x10 kernel: [<ffffffff81779515>] tracesys_phase2+0x84/0x89 I found no particular commit which introduced this problem. CVE: CVE-2015-8543 Cc: Cong Wang <cwang@twopensource.com> Reported-by:
郭永刚 <guoyonggang@360.cn> Signed-off-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Andrew Lunn authored
[ Upstream commit 651df218 ] commit 8b63ec18 ("phylib: Make PHYs children of their MDIO bus, not the bus' parent.") changed the parenting of PHY devices, making them a child of the MDIO bus, instead of the MAC device. This broken the Micrel PHY driver which has a deprecated feature of allowing PHY properties to be placed into the MAC node. In order to find the MAC node, we need to walk up the tree of devices until we find one with an OF node attached. Reported-by:
Dinh Nguyen <dinguyen@opensource.altera.com> Suggested-by:
David Daney <david.daney@cavium.com> Acked-by:
Andrew Lunn <andrew@lunn.ch> Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 9470e24f ] SCTP is lacking proper np->opt cloning at accept() time. TCP and DCCP use ipv6_dup_options() helper, do the same in SCTP. We might later factorize this code in a common helper to avoid future mistakes. Reported-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Acked-by:
Vlad Yasevich <vyasevich@gmail.com> Signed-off-by:
-
Peter Wu authored
[ Upstream commit 90186af4 ] When an interface is brought up which was previously suspended (via runtime PM), it would hang. This happens because napi_disable is called before napi_enable. Solve this by avoiding napi_enable in the resume during open function (netif_running is true when open is called, IFF_UP is set after a successful open; netif_running is false when close is called, but IFF_UP is then still set). While at it, remove WORK_ENABLE check from rtl8152_open (introduced with the original change) because it cannot happen: - After this patch, runtime resume will not set it during rtl8152_open. - When link is up, rtl8152_open is not called. - When link is down during system/auto suspend/resume, it is not set. Fixes: 41cec84c ("r8152: don't enable napi before rx ready") Link: https://lkml.kernel.org/r/20151205105912.GA1766@alSigned-off-by:
Peter Wu <peter@lekensteyn.nl> Acked-by:
Hayes Wang <hayeswang@realtek.com> Signed-off-by:
-
Stefan Wahren authored
[ Upstream commit ed7d42e2 ] In case of a tx queue timeout every transmit is blocked until the QCA7000 resets himself and triggers a sync which makes the driver flushs the tx ring. So avoid this blocking situation by triggering the sync immediately after the timeout. Waking the queue doesn't make sense in this situation. Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Fixes: 291ab06e ("net: qualcomm: new Ethernet over SPI driver for QCA7000") Signed-off-by:
-
Bjørn Mork authored
[ Upstream commit f8c0cfa5 ] The Huawei E3372 (12d1:157d) needs this quirk in MBIM mode as well. Allow this by forcing the NTB to contain only a single NDP, and add a device specific entry for this ID. Due to the way Huawei use device IDs, this might be applied to other modems as well. It is assumed that those modems will be based on the same firmware and will need this quirk too. If not, it will still not harm normal usage, although multiplexing performance could be impacted. Cc: Enrico Mioso <mrkiko.rs@gmail.com> Reported-by:
Sami Farin <hvtaifwkbgefbaei@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Acked-By:
Enrico Mioso <mrkiko.rs@gmail.com> Signed-off-by:
-
Marcelo Ricardo Leitner authored
[ Upstream commit 50a5ffb1 ] As we are keeping timestamps on when copying the socket, we also have to copy sk_tsflags. This is needed since b9f40e21 ("net-timestamp: move timestamp flags out of sk_flags"). Signed-off-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Acked-by:
-
Marcelo Ricardo Leitner authored
[ Upstream commit 01ce63c9 ] Dmitry Vyukov reported that SCTP was triggering a WARN on socket destroy related to disabling sock timestamp. When SCTP accepts an association or peel one off, it copies sock flags but forgot to call net_enable_timestamp() if a packet timestamping flag was copied, leading to extra calls to net_disable_timestamp() whenever such clones were closed. The fix is to call net_enable_timestamp() whenever we copy a sock with that flag on, like tcp does. Reported-by:
-
Marcelo Ricardo Leitner authored
[ Upstream commit cb5e173e ] SCTP echoes a cookie o INIT ACK chunks that contains a timestamp, for detecting stale cookies. This cookie is echoed back to the server by the client and then that timestamp is checked. Thing is, if the listening socket is using packet timestamping, the cookie is encoded with ktime_get() value and checked against ktime_get_real(), as done by __net_timestamp(). The fix is to sctp also use ktime_get_real(), so we can compare bananas with bananas later no matter if packet timestamping was enabled or not. Fixes: 52db882f ("net: sctp: migrate cookie life from timeval to ktime") Signed-off-by:
-
Jiri Benc authored
[ Upstream commit c5fb8caa ] Commit 3511494c ("vxlan: Group Policy extension") changed definition of VXLAN_HF_RCO from 0x00200000 to BIT(24). This is obviously incorrect. It's also in violation with the RFC draft. Fixes: 3511494c ("vxlan: Group Policy extension") Cc: Thomas Graf <tgraf@suug.ch> Cc: Tom Herbert <therbert@google.com> Signed-off-by:
Jiri Benc <jbenc@redhat.com> Acked-by:
Tom Herbert <tom@herbertland.com> Signed-off-by:
-
Bjørn Mork authored
[ Upstream commit 9a1ec461 ] Commit 64236f3f ("ipv6: introduce IFA_F_STABLE_PRIVACY flag") failed to update the setting of the IFA_F_OPTIMISTIC flag, causing the IFA_F_STABLE_PRIVACY flag to be lost if IFA_F_OPTIMISTIC is set. Cc: Erik Kline <ek@google.com> Cc: Fernando Gont <fgont@si6networks.com> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: YOSHIFUJI Hideaki/吉藤英明 <hideaki.yoshifuji@miraclelinux.com> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Fixes: 64236f3f ("ipv6: introduce IFA_F_STABLE_PRIVACY flag") Signed-off-by:
-
Pavel Machek authored
[ Upstream commit f2a3771a ] atl1c driver is doing order-4 allocation with GFP_ATOMIC priority. That often breaks networking after resume. Switch to GFP_KERNEL. Still not ideal, but should be significantly better. atl1c_setup_ring_resources() is called from .open() function, and already uses GFP_KERNEL, so this change is safe. Signed-off-by:
Pavel Machek <pavel@ucw.cz> Acked-by:
Michal Hocko <mhocko@suse.com> Signed-off-by:
-
Nicolas Dichtel authored
[ Upstream commit 6a61d4db ] Parameters were updated only if the kernel was unable to find the tunnel with the new parameters, ie only if core pamareters were updated (keys, addr, link, type). Now it's possible to update ttl, hoplimit, flowinfo and flags. Fixes: c12b395a ("gre: Support GRE over IPv6") Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by:
-
Guillaume Nault authored
[ Upstream commit fe53985a ] pppoe_connect() mustn't touch the padt_work field of pppoe sockets because that work could be already pending. [ 21.473147] BUG: unable to handle kernel NULL pointer dereference at 00000004 [ 21.474523] IP: [<c1043177>] process_one_work+0x29/0x31c [ 21.475164] *pde = 00000000 [ 21.475513] Oops: 0000 [#1] SMP [ 21.475910] Modules linked in: pppoe pppox ppp_generic slhc crc32c_intel aesni_intel virtio_net xts aes_i586 lrw gf128mul ablk_helper cryptd evdev acpi_cpufreq processor serio_raw button ext4 crc16 mbcache jbd2 virtio_blk virtio_pci virtio_ring virtio [ 21.476168] CPU: 2 PID: 164 Comm: kworker/2:2 Not tainted 4.4.0-rc1 #1 [ 21.476168] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014 [ 21.476168] task: f5f83c00 ti: f5e28000 task.ti: f5e28000 [ 21.476168] EIP: 0060:[<c1043177>] EFLAGS: 00010046 CPU: 2 [ 21.476168] EIP is at process_one_work+0x29/0x31c [ 21.484082] EAX: 00000000 EBX: f678b2a0 ECX: 00000004 EDX: 00000000 [ 21.484082] ESI: f6c69940 EDI: f5e29ef0 EBP: f5e29f0c ESP: f5e29edc [ 21.484082] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 [ 21.484082] CR0: 80050033 CR2: 000000a4 CR3: 317ad000 CR4: 00040690 [ 21.484082] Stack: [ 21.484082] 00000000 f6c69950 00000000 f6c69940 c0042338 f5e29f0c c1327945 00000000 [ 21.484082] 00000008 f678b2a0 f6c69940 f678b2b8 f5e29f30 c1043984 f5f83c00 f6c69970 [ 21.484082] f678b2a0 c10437d3 f6775e80 f678b2a0 c10437d3 f5e29fac c1047059 f5e29f74 [ 21.484082] Call Trace: [ 21.484082] [<c1327945>] ? _raw_spin_lock_irq+0x28/0x30 [ 21.484082] [<c1043984>] worker_thread+0x1b1/0x244 [ 21.484082] [<c10437d3>] ? rescuer_thread+0x229/0x229 [ 21.484082] [<c10437d3>] ? rescuer_thread+0x229/0x229 [ 21.484082] [<c1047059>] kthread+0x8f/0x94 [ 21.484082] [<c1327a32>] ? _raw_spin_unlock_irq+0x22/0x26 [ 21.484082] [<c1327ee9>] ret_from_kernel_thread+0x21/0x38 [ 21.484082] [<c1046fca>] ? kthread_parkme+0x19/0x19 [ 21.496082] Code: 5d c3 55 89 e5 57 56 53 89 c3 83 ec 24 89 d0 89 55 e0 8d 7d e4 e8 6c d8 ff ff b9 04 00 00 00 89 45 d8 8b 43 24 89 45 dc 8b 45 d8 <8b> 40 04 8b 80 e0 00 00 00 c1 e8 05 24 01 88 45 d7 8b 45 e0 8d [ 21.496082] EIP: [<c1043177>] process_one_work+0x29/0x31c SS:ESP 0068:f5e29edc [ 21.496082] CR2: 0000000000000004 [ 21.496082] ---[ end trace e362cc9cf10dae89 ]--- Reported-by:
Andrew <nitr0@seti.kr.ua> Fixes: 287f3a94 ("pppoe: Use workqueue to die properly when a PADT is received") Signed-off-by:
Guillaume Nault <g.nault@alphalink.fr> Signed-off-by:
-
Vineet Gupta authored
commit 30b9dbee upstream. Signed-off-by:
-
Sumit Saxena authored
commit aed335ee upstream. The DELL PERC5 controller firmware does not list tape drives in response to MR_DCMD_PD_LIST_QUERY. This causes tape drives not be exposed to the OS when connected to a PERC5 controller. This patch permits detection of tape drives connected to a PERC5 controller by exposing non-TYPE_DISK devices unconditionally. Signed-off-by:
Kashyap Desai <kashyap.desai@avagotech.com> Signed-off-by:
Sumit Saxena <sumit.saxena@avagotech.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Christophe JAILLET authored
commit eb8ed1eb upstream. Reference to the 'np' node is dropped before dereferencing the 'sizep' and 'basep' pointers, which could by then point to junk if the node has been freed. Refactor code to call 'of_node_put' later. Fixes: c5df3926 ("drivers/char/tpm: Add securityfs support for event log") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by:
Peter Huewe <PeterHuewe@gmx.de> Signed-off-by:
-
Arnd Bergmann authored
commit 4bed5395 upstream. The fixed_phy infrastructure is done in a way that is optional, by providing 'static inline' helper functions doing nothing in include/linux/phy_fixed.h for all its APIs. However, three out of the four users (DSA, BCMGENET, and SYSTEMPORT) always 'select FIXED_PHY', presumably because they need that. MVNETA is the fourth one, and if that is built-in but FIXED_PHY is configured as a loadable module, we get a link error: drivers/built-in.o: In function `mvneta_fixed_link_update': fpga-mgr.c:(.text+0x33ed80): undefined reference to `fixed_phy_update_state' Presumably this driver has the same dependency as the others, so this patch also uses 'select' to ensure that the fixed-phy support is built-in. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Fixes: 898b2970 ("mvneta: implement SGMII-based in-band link state signaling") Signed-off-by:
-
Jarkko Sakkinen authored
commit b1a4144a upstream. Mimi reported that afb5abc2 reverts the fix in 398a1e71. This patch reverts it back. Fixes: afb5abc2 ("tpm: two-phase chip management functions") Reported-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by:
-
Martin Wilck authored
commit 2aef9da6 upstream. Release IRQs used for probing only. Otherwise the TPM will end up with all IRQs 3-15 assigned. Fixes: afb5abc2 ("tpm: two-phase chip management functions") Signed-off-by:
Martin Wilck <Martin.Wilck@ts.fujitsu.com> Reviewed-by:
-
Arnd Bergmann authored
commit fdcb4b2e upstream. resource_size_t may be 32-bit wide on some architectures, which causes this warning when building the NTB code: drivers/ntb/ntb_transport.c: In function 'ntb_transport_link_work': drivers/ntb/ntb_transport.c:828:46: warning: right shift count >= width of type [-Wshift-count-overflow] The warning is harmless but can be avoided by using the upper_32_bits() macro. Signed-off-by:
Jon Mason <jdmason@kudzu.us> Signed-off-by:
-
Tero Kristo authored
commit 62c8c20a upstream. mcp794xx alarm registers must be written in BCD format. However, the alarm programming logic neglected this by adding one to the value after bin2bcd conversion has been already done, writing bad values to month register in case the alarm being set is in October. In this case, the alarm month value becomes 0x0a instead of the expected 0x10. Fix by moving the +1 addition within the bin2bcd call also. Fixes: 1d1945d2 ("drivers/rtc/rtc-ds1307.c: add alarm support for mcp7941x chips") Signed-off-by:
Tero Kristo <t-kristo@ti.com> Acked-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
-
Peter Feiner authored
commit 956959f6 upstream. The -i flag was incorrectly listed as a short flag for --no-inherit. It should have only been listed as a short flag for --input. This documentation error has existed since the --input flag was introduced in 6810fc91 (perf trace: Add option to analyze events in a file versus live). Signed-off-by:
Peter Feiner <pfeiner@google.com> Cc: David Ahern <dsahern@gmail.com> Link: http://lkml.kernel.org/r/1446657706-14518-1-git-send-email-pfeiner@google.com Fixes: 6810fc91 ("perf trace: Add option to analyze events in a file versus live") Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
WANG Cong authored
commit 87e9f031 upstream. Sasha reported the following lockdep warning: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sk_lock-AF_INET); lock(rtnl_mutex); lock(sk_lock-AF_INET); lock(rtnl_mutex); This is due to that for IP_MSFILTER and MCAST_MSFILTER, we take rtnl lock before the socket lock in setsockopt() path, but take the socket lock before rtnl lock in getsockopt() path. All the rest optnames are setsockopt()-only. Fix this by aligning the getsockopt() path with the setsockopt() path, so that all mcast socket path would be locked in the same order. Note, IPv6 part is different where rtnl lock is not held. Fixes: 54ff9ef3 ("ipv4, ipv6: kill ip_mc_{join, leave}_group and ipv6_sock_mc_{join, drop}") Reported-by:
Sasha Levin <sasha.levin@oracle.com> Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Reviewed-by:
-
Krzysztof Kozlowski authored
commit 9e4249b4 upstream. Thermal core could not read the temperature after registering the thermal sensor with thermal_zone_of_sensor_register() because the driver was not yet initialized. The call trace looked like: exynos_tmu_probe() thermal_zone_of_sensor_register() of_thermal_set_mode() thermal_zone_device_update() exynos_get_temp() if (!data->tmu_read) return -EINVAL; exynos_map_dt_data() data->tmu_read = ... This produced an error in dmesg: thermal thermal_zone0: failed to read out thermal zone (-22) Register the thermal_zone_device later, after parsing Device Tree and enabling necessary clocks, but before calling exynos_tmu_initialize() which uses the registered thermal_zone_device. Reviewed-by:
Alim Akhtar <alim.akhtar@samsung.com> Tested-by:
Lukasz Majewski <l.majewski@samsung.com> Tested-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Fixes: 3b6a1a80 ("thermal: samsung: core: Exynos TMU rework to use device tree for configuration") Signed-off-by:
Eduardo Valentin <edubezval@gmail.com> Signed-off-by:
-
Ben Hutchings authored
commit 3b4d3819 upstream. Fixes: 87b2d440 ("selftests: add memfd/sealing page-pinning tests") Fixes: 2bf9e0ab ("locking/static_keys: Provide a selftest") Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by:
-
Ben Hutchings authored
commit c28628b8 upstream. do_fork() is no longer defined on x86, so probe _do_fork() instead. Fixes: 3033f14a ("clone: support passing tls argument via C ...") Signed-off-by:
-
James Morse authored
commit 1b4bb2ea upstream. vfio_platform_{read,write}_mmio() call ioremap_nocache() to map a region of io memory, which they store in struct vfio_platform_region to be eventually re-used, or unmapped by vfio_platform_regions_cleanup(). These functions receive a copy of their struct vfio_platform_region argument on the stack - so these mapped areas are always allocated, and always leaked. Pass this argument as a pointer instead. Fixes: 6e3f2645 "vfio/platform: read and write support for the device fd" Signed-off-by:
James Morse <james.morse@arm.com> Acked-by:
Baptiste Reynal <b.reynal@virtualopensystems.com> Tested-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Michal Kubeček authored
commit ebac62fe upstream. Both tunnel6_protocol and tunnel46_protocol share the same error handler, tunnel6_err(), which traverses through tunnel6_handlers list. For ipip6 tunnels, we need to traverse tunnel46_handlers as we do e.g. in tunnel46_rcv(). Current code can generate an ICMPv6 error message with an IPv4 packet embedded in it. Fixes: 73d605d1 ("[IPSEC]: changing API of xfrm6_tunnel_register") Signed-off-by:
Michal Kubecek <mkubecek@suse.cz> Signed-off-by:
-
Eric Dumazet authored
commit 1d6119ba upstream. This patch fixes following problems : 1) percpu_counter_init() can return an error, therefore init_frag_mem_limit() must propagate this error so that inet_frags_init_net() can do the same up to its callers. 2) If ip[46]_frags_ns_ctl_register() fail, we must unwind properly and free the percpu_counter. Without this fix, we leave freed object in percpu_counters global list (if CONFIG_HOTPLUG_CPU) leading to crashes. This bug was detected by KASAN and syzkaller tool (http://github.com/google/syzkaller) Fixes: 6d7b857d ("net: use lib/percpu_counter API for fragmentation mem accounting") Signed-off-by:
-
Mathieu Desnoyers authored
commit a15920be upstream. The documentation on top of __DECLARE_TRACE() does not match its implementation since the condition check has been added to the RCU lockdep checks. Update the documentation to match its implementation. Link: http://lkml.kernel.org/r/1446504164-21563-1-git-send-email-mathieu.desnoyers@efficios.com CC: Dave Hansen <dave@sr71.net> Fixes: a05d59a5 "tracing: Add condition check to RCU lockdep checks" Signed-off-by:
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Bjørn Mork authored
commit 70910791 upstream. The lt4112 is a HP branded Huawei me906e modem. Like other Huawei modems, it does not have a fixed interface to function mapping. Instead it uses a Huawei specific scheme: functions are mapped by subclass and protocol. However, the HP vendor ID is used for modems from many different manufacturers using different schemes, so we cannot apply a generic vendor rule like we do for the Huawei vendor ID. Replace the previous lt4112 entry pointing to an arbitrary interface number with a device specific subclass + protocol match. Reported-and-tested-by:
Muri Nicanor <muri+libqmi@immerda.ch> Tested-by:
Martin Hauke <mardnh@gmx.de> Fixes: bb2bdeb8 ("qmi_wwan: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem") Signed-off-by:
-
Chuck Lever authored
commit 4220a072 upstream. Commit 8301a2c0 ("xprtrdma: Limit work done by completion handler") was supposed to prevent xprtrdma's upcall handlers from starving other softIRQ work by letting them return to the provider before all CQEs have been polled. The logic assumes the provider will call the upcall handler again immediately if the CQ is re-armed while there are still queued CQEs. This assumption is invalid. The IBTA spec says that after a CQ is armed, the hardware must interrupt only when a new CQE is inserted. xprtrdma can't rely on the provider calling again, even though some providers do. Therefore, leaving CQEs on queue makes sense only when there is another mechanism that ensures all remaining CQEs are consumed in a timely fashion. xprtrdma does not have such a mechanism. If a CQE remains queued, the transport can wait forever to send the next RPC. Finally, move the wcs array back onto the stack to ensure that the poll array is always local to the CPU where the completion upcall is running. Fixes: 8301a2c0 ("xprtrdma: Limit work done by completion ...") Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Reviewed-by:
Sagi Grimberg <sagig@mellanox.com> Reviewed-by:
Devesh Sharma <devesh.sharma@avagotech.com> Tested-By:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
-
Chuck Lever authored
commit 7b3d770c upstream. ib_req_notify_cq(IB_CQ_REPORT_MISSED_EVENTS) returns a positive value if WCs were added to a CQ after the last completion upcall but before the CQ has been re-armed. Commit 7f23f6f6 ("xprtrmda: Reduce lock contention in completion handlers") assumed that when ib_req_notify_cq() returned a positive RC, the CQ had also been successfully re-armed, making it safe to return control to the provider without losing any completion signals. That is an invalid assumption. Change both completion handlers to continue polling while ib_req_notify_cq() returns a positive value. Fixes: 7f23f6f6 ("xprtrmda: Reduce lock contention in ...") Signed-off-by:
-
Jon Medhurst \(Tixy\) authored
commit 14f1ba3a upstream. The check for correct frequency being set in bL_cpufreq_set_rate is broken when the big.LITTLE switcher is active, for two reasons. 1. The 'new_rate' variable gets overwritten before the test by the code calculating the frequency of the old cluster. 2. The frequency returned by bL_cpufreq_get_rate will be the virtual frequency, not the actual one the intended version of new_rate contains. This means the function always returns an error causing an endless stream of: "cpufreq: __target_index: Failed to change cpu frequency: -5" As the intent is to check for errors that clk_set_rate doesn't report lets move the check to immediately after that and directly use clk_get_rate, rather than the arm_big_little helpers which only confuse matters. Also, update the comment to be hopefully clearer about the purpose of the code. Fixes: 0a95e630 (cpufreq: arm_big_little: check if the frequency is set correctly) Signed-off-by:
Jon Medhurst <tixy@linaro.org> Acked-by:
Sudeep Holla <sudeep.holla@arm.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by:
Michael Turquette <mturquette@baylibre.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Hannes Frederic Sowa authored
commit 682b1a9d upstream. We cannot reliable calculate packet size on MSG_MORE corked sockets and thus cannot decide if they are going to be fragmented later on, so better not use CHECKSUM_PARTIAL in the first place. The IPv6 code also intended to protect and not use CHECKSUM_PARTIAL in the existence of IPv6 extension headers, but the condition was wrong. Fix it up, too. Also the condition to check whether the packet fits into one fragment was wrong and has been corrected. Fixes: commit 32dce968 ("ipv6: Allow for partial checksums on non-ufo packets") See-also: commit 72e843bb ("ipv6: ip6_fragment() should check CHECKSUM_PARTIAL") Cc: Eric Dumazet <edumazet@google.com> Cc: Vlad Yasevich <vyasevich@gmail.com> Cc: Benjamin Coddington <bcodding@redhat.com> Cc: Tom Herbert <tom@herbertland.com> Signed-off-by:
-
Bart Van Assche authored
commit db7489e0 upstream. Move the __attribute_const__ declarations such that sparse understands that these apply to the function itself and not to the return type. This avoids that sparse reports error messages like the following: drivers/infiniband/core/verbs.c:73:12: error: symbol 'ib_event_msg' redeclared with different type (originally declared at include/rdma/ib_verbs.h:470) - different modifiers Fixes: 2b1b5b60 ("IB/core, cma: Nice log-friendly string helpers") Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Cc: Sagi Grimberg <sagig@mellanox.com> Reviewed-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Yinghai Lu authored
commit af86fa40 upstream. David reported that a T5-8 sparc system failed to boot with: pci_sun4v f02dbcfc: PCI host bridge to bus 0000:00 pci_bus 0000:00: root bus resource [io 0x804000000000-0x80400fffffff] (bus address [0x0000-0xfffffff]) pci_bus 0000:00: root bus resource [mem 0x800000000000-0x80007effffff] (bus address [0x00000000-0x7effffff]) pci 0000:00:01.0: can't claim BAR 15 [mem 0x100000000-0x4afffffff pref]: no compatible bridge window Note that we don't know about a host bridge aperture that contains BAR 15. OF does report a MEM64 aperture, but before this patch, pci_determine_mem_io_space() ignored it. Add support for host bridge apertures with 64-bit PCI addresses. Also set IORESOURCE_MEM_64 for PCI device and bridge resources in PCI 64-bit memory space. Sparc doesn't actually print the device and bridge resources, but after this patch, we should have the equivalent of this: pci_sun4v f02dbcfc: PCI host bridge to bus 0000:00 pci_bus 0000:00: root bus resource [io 0x804000000000-0x80400fffffff] (bus address [0x0000-0xfffffff]) pci_bus 0000:00: root bus resource [mem 0x800000000000-0x80007effffff] (bus address [0x00000000-0x7effffff]) pci_bus 0000:00: root bus resource [mem 0x800100000000-0x8007ffffffff] (bus address [0x100000000-0x7ffffffff]) pci 0000:00:01.0: bridge window [mem 0x800100000000-0x8004afffffff 64bit pref] [bhelgaas: changelog, URL to David's report] Fixes: d63e2e1f ("sparc/PCI: Clip bridge windows to fit in upstream windows") Link: http://lkml.kernel.org/r/5514391F.2030300@oracle.comReported-by:
David Ahern <david.ahern@oracle.com> Tested-by:
Khalid Aziz <khalid.aziz@oracle.com> Signed-off-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Alexander Duyck authored
commit ea9a8854 upstream. The enumeration path should leave NumVFs set to zero. But after 4449f079 ("PCI: Calculate maximum number of buses required for VFs"), we call virtfn_max_buses() in the enumeration path, which changes NumVFs. This NumVFs change is visible via lspci and sysfs until a driver enables SR-IOV. Iterate from TotalVFs down to zero so NumVFs is zero when we're finished computing the maximum number of buses. Validate offset and stride in the loop, so we can test it at every possible NumVFs setting. Rename virtfn_max_buses() to compute_max_vf_buses() to hint that it does have a side effect of updating iov->max_VF_buses. [bhelgaas: changelog, rename, allow numVF==1 && stride==0, rework loop, reverse sense of error path] Fixes: 4449f079 ("PCI: Calculate maximum number of buses required for VFs") Based-on-patch-by:
Ethan Zhao <ethan.zhao@oracle.com> Signed-off-by:
Alexander Duyck <aduyck@mirantis.com> Signed-off-by:
-
Florian Westphal authored
commit dbc3617f upstream. nfnetlink_bind request_module()s all the time as nfnetlink_get_subsys() shifts the argument by 8 to obtain the subsys id. So using type instead of type << 8 always returns NULL. Fixes: 03292745 ("netlink: add nlk->netlink_bind hook for module auto-loading") Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
