- 23 Jun, 2015 40 commits
-
-
Axel Lin authored
commit 3e59ae4a upstream. Make the modalias match driver name, this is required to make module auto-loading work. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Acked-by:
Zhangfei Gao <zhangfei.gao@linaro.org> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ludovic Desroches authored
commit 4c374fc7 upstream. Using _bh variant for spin locks causes this kind of warning: Starting logging: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 3 at /ssd_drive/linux/kernel/softirq.c:151 __local_bh_enable_ip+0xe8/0xf4() Modules linked in: CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 4.1.0-rc2+ #94 Hardware name: Atmel SAMA5 [<c0013c04>] (unwind_backtrace) from [<c00118a4>] (show_stack+0x10/0x14) [<c00118a4>] (show_stack) from [<c001bbcc>] (warn_slowpath_common+0x80/0xac) [<c001bbcc>] (warn_slowpath_common) from [<c001bc14>] (warn_slowpath_null+0x1c/0x24) [<c001bc14>] (warn_slowpath_null) from [<c001e28c>] (__local_bh_enable_ip+0xe8/0xf4) [<c001e28c>] (__local_bh_enable_ip) from [<c01fdbd0>] (at_xdmac_device_terminate_all+0xf4/0x100) [<c01fdbd0>] (at_xdmac_device_terminate_all) from [<c02221a4>] (atmel_complete_tx_dma+0x34/0xf4) [<c02221a4>] (atmel_complete_tx_dma) from [<c01fe4ac>] (at_xdmac_tasklet+0x14c/0x1ac) [<c01fe4ac>] (at_xdmac_tasklet) from [<c001de58>] (tasklet_action+0x68/0xb4) [<c001de58>] (tasklet_action) from [<c001dfdc>] (__do_softirq+0xfc/0x238) [<c001dfdc>] (__do_softirq) from [<c001e140>] (run_ksoftirqd+0x28/0x34) [<c001e140>] (run_ksoftirqd) from [<c0033a3c>] (smpboot_thread_fn+0x138/0x18c) [<c0033a3c>] (smpboot_thread_fn) from [<c0030e7c>] (kthread+0xdc/0xf0) [<c0030e7c>] (kthread) from [<c000f480>] (ret_from_fork+0x14/0x34) ---[ end trace b57b14a99c1d8812 ]--- It comes from the fact that devices can called some code from the DMA controller with irq disabled. _bh variant is not intended to be used in this case since it can enable irqs. Switch to irqsave/irqrestore variant to avoid this situation. Signed-off-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Ludovic Desroches authored
commit 765c37d8 upstream. Rework slave configuration part in order to more report wrong errors about the configuration. Only maxburst and addr width values are checked when doing the slave configuration. The validity of the channel configuration is done at prepare time. Signed-off-by:
-
Krzysztof Kozlowski authored
commit 88d04643 upstream. Some drivers implement only pause operation (no resuming). Example is pl330 where pause is needed for getting residuum. pl330 does not support resume operation, transfer must be stopped after pause. However for slaves this is exposed always as "pause and resume" which introduces subtle errors on Odroid U3 board (Exynos4412 with pl330). After adding pause function to pl330 driver the audio playback (utilizing DMA) gets choppy after some time (approximately 24 hours). Fix this by exposing "cmd_pause" if and only if pause and resume are implemented. Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Reported-by: gabriel@unseen.is Reported-by:
Marek Szyprowski <m.szyprowski@samsung.com> Fixes: 88987d2c ("dmaengine: pl330: add DMA_PAUSE feature") Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Krzysztof Kozlowski authored
commit 81cc6edc upstream. The pl330 device could hang infinitely on certain boards when DMA channels are terminated. It was caused by lack of runtime resume when executing pl330_terminate_all() which calls the _stop() function. _stop() accesses device register and can loop infinitely while checking for device state. The hang was confirmed by Dinh Nguyen on Altera SOCFPGA Cyclone V board during boot. It can be also triggered with: $ echo 1 > /sys/module/dmatest/parameters/iterations $ echo dma1chan0 > /sys/module/dmatest/parameters/channel $ echo 1 > /sys/module/dmatest/parameters/run $ sleep 1 $ cat /sys/module/dmatest/parameters/run Reported-by:
Dinh Nguyen <dinguyen@opensource.altera.com> Signed-off-by:
-
Jurgen Kramer authored
commit 3b7e5c7e upstream. This patch adds native DSD support for the XMOS based JLsounds I2SoverUSB board Signed-off-by:
Jurgen Kramer <gtmkramer@xs4all.nl> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Clemens Ladisch authored
commit ea114fc2 upstream. The driver worked around an error in the MAYA44 USB(+)'s mixer unit descriptor by aborting before parsing the missing field. However, aborting parsing too early prevented parsing of the other units connected to this unit, so the capture mixer controls would be missing. Fix this by moving the check for this descriptor error after the parsing of the unit's input pins. Reported-by:
nightmixes <nightmixes@gmail.com> Tested-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Clemens Ladisch authored
commit 044bddb9 upstream. Add mixer control names for the ESI Maya44 USB+ (which appears to be identical width the AudioTrak Maya44 USB). Reported-by:
-
Eric Wong authored
commit 2f80b295 upstream. This quirk allows us to avoid the noisy: current rate 0 is different from the runtime rate message every time playback starts. While USB DAC in the RR2150 supports reading the sample rate, it never returns a sample rate other than zero in my observation with common sample rates. Signed-off-by:
Eric Wong <normalperson@yhbt.net> Cc: Joe Turner <joe@oampo.co.uk> Signed-off-by:
-
Wolfram Sang authored
commit 1ef9f058 upstream. Fix this from the logs: usb 7-1: New USB device found, idVendor=046d, idProduct=08ca ... usb 7-1: Warning! Unlikely big volume range (=3072), cval->res is probably wrong. usb 7-1: [5] FU [Mic Capture Volume] ch = 1, val = 4608/7680/1 Signed-off-by:
-
Takashi Iwai authored
commit b5d724b1 upstream. Acer Aspire 9420 with ALC883 (1025:0107) needs the fixup for EAPD to make the sound working like other Aspire models. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94111Signed-off-by:
-
David Woodhouse authored
commit 4ed6a540 upstream. When we use 'intel_iommu=igfx_off' to disable translation for the graphics, and when we discover that the BIOS has misconfigured the DMAR setup for I/OAT, we use a special DUMMY_DEVICE_DOMAIN_INFO value in dev->archdata.iommu to indicate that translation is disabled. With passthrough mode, we were attempting to dereference that as a normal pointer to a struct device_domain_info when setting up an identity mapping for the affected device. This fixes the problem by making device_to_iommu() explicitly check for the special value and indicate that no IOMMU was found to handle the devices in question. Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
-
David Woodhouse authored
commit 18436afd upstream. Commit c875d2c1 ("iommu/vt-d: Exclude devices using RMRRs from IOMMU API domains") prevents certain options for devices with RMRRs. This even prevents those devices from getting a 1:1 mapping with 'iommu=pt', because we don't have the code to handle *preserving* the RMRR regions when moving the device between domains. There's already an exclusion for USB devices, because we know the only reason for RMRRs there is a misguided desire to keep legacy keyboard/mouse emulation running in some theoretical OS which doesn't have support for USB in its own right... but which *does* enable the IOMMU. Add an exclusion for graphics devices too, so that 'iommu=pt' works there. We should be able to successfully assign graphics devices to guests too, as long as the initial handling of stolen memory is reconfigured appropriately. This has certainly worked in the past. Signed-off-by:
-
Laura Abbott authored
commit 72586c60 upstream. Commit 32f13521 ("n_tty: Line copy to user buffer in canonical mode") changed cannonical mode copying to use copy_to_user but missed adding the call to the audit framework. Add in the appropriate functions to get audit support. Fixes: 32f13521 ("n_tty: Line copy to user buffer in canonical mode") Reported-by:
Miloslav Trmač <mitr@redhat.com> Signed-off-by:
Laura Abbott <labbott@fedoraproject.org> Reviewed-by:
Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
-
Sudeep Holla authored
commit 3370e13a upstream. On some simulators like GEM5, caches may not be simulated. In those cases, the cache levels and leaves will be zero and will result in following exception: Unable to handle kernel NULL pointer dereference at virtual address 0040 pgd = ffffffc0008fa000 [00000040] *pgd=00000009f6807003, *pud=00000009f6807003, *pmd=00000009f6808003, *pte=006000002c010707 Internal error: Oops: 96000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.1.0-rc5 #198 task: ffffffc9768a0000 ti: ffffffc9768a8000 task.ti: ffffffc9768a8000 PC is at detect_cache_attributes+0x98/0x2c8 LR is at detect_cache_attributes+0x88/0x2c8 kcalloc(0) returns a special value ZERO_SIZE_PTR which is non-NULL value but results in fault only on any attempt to dereferencing it. So checking for the non-NULL pointer will not suffice. This patch checks for non-zero cache leaf nodes and returns error if there are no cache leaves in detect_cache_attributes. Cc: Will Deacon <will.deacon@arm.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reported-by:
William Wang <william.wang@arm.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com> Signed-off-by:
-
Lars-Peter Clausen authored
commit d046ba26 upstream. The adis16448, unlike the other chips in this family, in addition to the hardware channels also sends out the DIAG_STAT register in burst mode before them. Handle that case by skipping over the first 2 bytes before we pass the received data to the buffer. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Fixes: 76ada52f ("iio:adis16400: Add support for the adis16448") Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Paul Cercueil authored
commit 9df56035 upstream. There are a few issues with the burst mode support. For one we don't setup the rx buffer, so the buffer will never be filled and all samples will read as the zero. Furthermore the tx buffer has the wrong type, which means the driver sends the wrong command and not the right data is returned. The final issue is that in burst mode all channels are transferred. Hence the length of the transfer length should be the number of hardware channels * 2 bytes. Currently the driver uses indio_dev->scan_bytes for this. But if the timestamp channel is enabled the scan_bytes will be larger than the burst length. Fix this by just calculating the burst length based on the number of hardware channels. Signed-off-by:
Paul Cercueil <paul.cercueil@analog.com> Signed-off-by:
-
Paul Cercueil authored
commit c2a8b623 upstream. We unfortunately can't use ~0UL for the scan mask to indicate that the only valid scan mask is all channels selected. The IIO core needs the exact mask to work correctly and not a super-set of it. So calculate the masked based on the channels that are available for a particular device. Signed-off-by:
-
Paul Cercueil authored
commit 7323d598 upstream. Previously, the two voltage channels had the same ID, which didn't cause conflicts in sysfs only because one channel is named and the other isn't; this is still violating the spec though, two indexed channels should never have the same index. Signed-off-by:
-
Lars-Peter Clausen authored
commit 69ca2d77 upstream. Add the scale for the pressure channel, which is currently missing. Signed-off-by:
-
Axel Lin authored
commit e5d73218 upstream. Remove extra space between platform prefix and DRIVER_NAME in MODULE_ALIAS. Signed-off-by:
-
Herbert Xu authored
[ Upstream commit: Not applicable ] The current rhashtable rehash code is buggy and can't deal with parallel insertions/removals without corrupting the hash table. This patch disables it by partially reverting c5adde94 ("netlink: eliminate nl_sk_hash_lock"). Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Nikolay Aleksandrov authored
[ Upstream commit c4c832f8 ] br_fdb_update() can be called in process context in the following way: br_fdb_add() -> __br_fdb_add() -> br_fdb_update() (if NTF_USE flag is set) so we need to disable softirqs because there are softirq users of the hash_lock. One easy way to reproduce this is to modify the bridge utility to set NTF_USE, enable stp and then set maxageing to a low value so br_fdb_cleanup() is called frequently and then just add new entries in a loop. This happens because br_fdb_cleanup() is called from timer/softirq context. The spin locks in br_fdb_update were _bh before commit f8ae737d ("[BRIDGE]: forwarding remove unneeded preempt and bh diasables") and at the time that commit was correct because br_fdb_update() couldn't be called from process context, but that changed after commit: 292d1398 ("bridge: add NTF_USE support") Using local_bh_disable/enable around br_fdb_update() allows us to keep using the spin_lock/unlock in br_fdb_update for the fast-path. Signed-off-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Fixes: 292d1398 ("bridge: add NTF_USE support") Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Sriharsha Basavapatna authored
[ Upstream commit e51000db ] There are several places in the driver (all in control paths) where coherent dma memory is being allocated using either dma_alloc_coherent() or the deprecated pci_alloc_consistent(). All these calls should be changed to use dma_zalloc_coherent() to avoid uninitialized fields in data structures backed by this memory. Reported-by:
Joerg Roedel <jroedel@suse.de> Tested-by:
Sriharsha Basavapatna <sriharsha.basavapatna@avagotech.com> Signed-off-by:
-
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:
-
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:
-
Neal Cardwell authored
[ Upstream commit 9f950415 ] Linux 3.17 and earlier are explicitly engineered so that if the app doesn't specifically request a CC module on a listener before the SYN arrives, then the child gets the system default CC when the connection is established. See tcp_init_congestion_control() in 3.17 or earlier, which says "if no choice made yet assign the current value set as default". The change ("net: tcp: assign tcp cong_ops when tcp sk is created") altered these semantics, so that children got their parent listener's congestion control even if the system default had changed after the listener was created. This commit returns to those original semantics from 3.17 and earlier, since they are the original semantics from 2007 in 4d4d3d1e ("[TCP]: Congestion control initialization."), and some Linux congestion control workflows depend on that. In summary, if a listener socket specifically sets TCP_CONGESTION to "x", or the route locks the CC module to "x", then the child gets "x". Otherwise the child gets current system default from net.ipv4.tcp_congestion_control. That's the behavior in 3.17 and earlier, and this commit restores that. Fixes: 55d8694f ("net: tcp: assign tcp cong_ops when tcp sk is created") Cc: Florian Westphal <fw@strlen.de> Cc: Daniel Borkmann <dborkman@redhat.com> Cc: Glenn Judd <glenn.judd@morganstanley.com> Cc: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Yuchung Cheng <ycheng@google.com> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> 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 authored
[ Upstream commit 71d9f614 ] br_multicast_query_expired() querier argument is a pointer to a struct bridge_mcast_querier : struct bridge_mcast_querier { struct br_ip addr; struct net_bridge_port __rcu *port; }; Intent of the code was to clear port field, not the pointer to querier. Fixes: 2cd41431 ("bridge: memorize and export selected IGMP/MLD querier port") Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@redhat.com> Acked-by:
Linus Lüssing <linus.luessing@c0d3.blue> Cc: Linus Lüssing <linus.luessing@web.de> Cc: Steinar H. Gunderson <sesse@samfundet.no> Signed-off-by:
-
Jason Gunthorpe authored
[ Upstream commit 9302d7bb ] sctp_v4_map_v6 was subtly writing and reading from members of a union in a way the clobbered data it needed to read before it read it. Zeroing the v6 flowinfo overwrites the v4 sin_addr with 0, meaning that every place that calls sctp_v4_map_v6 gets ::ffff:0.0.0.0 as the result. Reorder things to guarantee correct behaviour no matter what the union layout is. This impacts user space clients that open an IPv6 SCTP socket and receive IPv4 connections. Prior to 299ee user space would see a sockaddr with AF_INET and a correct address, after 299ee the sockaddr is AF_INET6, but the address is wrong. Fixes: 299ee123 (sctp: Fixup v4mapped behaviour to comply with Sock API) Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Acked-by:
Neil Horman <nhorman@tuxdriver.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:
-
Ross Lagerwall authored
[ Upstream commit ce0e5c52 ] Commit e9ce7cb6 ("xen-netback: Factor queue-specific data into queue struct") introduced a regression when moving queue-specific data into the queue struct by failing to set the credit_bytes field. This prevented bandwidth limiting from working. Initialize the field as it was done before multiqueue support was added. Signed-off-by:
Ross Lagerwall <ross.lagerwall@citrix.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 adbe088f ] A pair of nested spin locks was introduced in commit 63502b8d "dp83640: Fix receive timestamp race condition". Unfortunately the 'flags' parameter was reused for the inner lock, clobbering the originally saved IRQ state. This patch fixes the issue by changing the inner lock to plain spin_lock without irqsave. Signed-off-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
-
Richard Cochran authored
[ Upstream commit a935865c ] Callers of the ext_write function are supposed to hold a mutex that protects the state of the dialed page, but one caller was missing the lock from the very start, and over time the code has been changed without following the rule. This patch cleans up the call sites in violation of the rule. 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:
-
Thadeu Lima de Souza Cascardo authored
[ Upstream commit 47cc84ce ] 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:
-
Bjørn Mork authored
[ Upstream commit 44f6731d ] The tx_curr_frame_payload field is u32. When we try to calculate a small negative delta based on it, we end up with a positive integer close to 2^32 instead. So the tx_bytes pointer increases by about 2^32 for every transmitted frame. Fix by calculating the delta as a signed long. Cc: Ben Hutchings <ben.hutchings@codethink.co.uk> Reported-by:
Florian Bruhin <me@the-compiler.org> Fixes: 7a1e890e ("usbnet: Fix tx_bytes statistic running backward in cdc_ncm") Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Eric W. Biederman authored
[ Upstream commit 381c759d ] 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:
-
Daniel Borkmann authored
[ Upstream commit c78e1746 ] Vijay reported that a loop as simple as ... while true; do tc qdisc add dev foo root handle 1: prio tc filter add dev foo parent 1: u32 match u32 0 0 flowid 1 tc qdisc del dev foo root rmmod cls_u32 done ... will panic the kernel. Moreover, he bisected the change apparently introducing it to 78fd1d0a ("netlink: Re-add locking to netlink_lookup() and seq walker"). The removal of synchronize_net() from the netlink socket triggering the qdisc to be removed, seems to have uncovered an RCU resp. module reference count race from the tc API. Given that RCU conversion was done after e341694e ("netlink: Convert netlink_lookup() to use RCU protected hash table") which added the synchronize_net() originally, occasion of hitting the bug was less likely (not impossible though): When qdiscs that i) support attaching classifiers and, ii) have at least one of them attached, get deleted, they invoke tcf_destroy_chain(), and thus call into ->destroy() handler from a classifier module. After RCU conversion, all classifier that have an internal prio list, unlink them and initiate freeing via call_rcu() deferral. Meanhile, tcf_destroy() releases already reference to the tp->ops->owner module before the queued RCU callback handler has been invoked. Subsequent rmmod on the classifier module is then not prevented since all module references are already dropped. By the time, the kernel invokes the RCU callback handler from the module, that function address is then invalid. One way to fix it would be to add an rcu_barrier() to unregister_tcf_proto_ops() to wait for all pending call_rcu()s to complete. synchronize_rcu() is not appropriate as under heavy RCU callback load, registered call_rcu()s could be deferred longer than a grace period. In case we don't have any pending call_rcu()s, the barrier is allowed to return immediately. Since we came here via unregister_tcf_proto_ops(), there are no users of a given classifier anymore. Further nested call_rcu()s pointing into the module space are not being done anywhere. Only cls_bpf_delete_prog() may schedule a work item, to unlock pages eventually, but that is not in the range/context of cls_bpf anymore. Fixes: 25d8c0d5 ("net: rcu-ify tcf_proto") Fixes: 9888faef ("net: sched: cls_basic use RCU") Reported-by:
Vijay Subramanian <subramanian.vijay@gmail.com> Signed-off-by:
Alexei Starovoitov <ast@plumgrid.com> Acked-by:
-
