- 20 Jun, 2018 40 commits
-
-
Parav Pandit authored
[ Upstream commit 9aa16921 ] When commit [1] was added, SGID was queried to derive the SMAC address. Then, later on during a refactor [2], SMAC was no longer needed. However, the now useless GID query remained. Then during additional code changes later on, the GID query was being done in such a way that it caused iWARP queries to start breaking. Remove the useless GID query and resolve the iWARP breakage at the same time. This is discussed in [3]. [1] commit dd5f03be ("IB/core: Ethernet L2 attributes in verbs/cm structures") [2] commit 5c266b23 ("IB/cm: Remove the usage of smac and vid of qp_attr and cm_av") [3] https://www.spinics.net/lists/linux-rdma/msg63951.htmlSuggested-by:
Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by:
Parav Pandit <parav@mellanox.com> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sebastian Sanchez authored
[ Upstream commit 59482a14 ] When IRQ affinity is set and the interrupt type is unknown, a cpu mask allocated within the function is never freed. Fix this memory leak by allocating memory within the scope where it is used. Reviewed-by:
Mike Marciniszyn <mike.marciniszyn@intel.com> Reviewed-by:
Michael J. Ruhl <michael.j.ruhl@intel.com> Signed-off-by:
Sebastian Sanchez <sebastian.sanchez@intel.com> Signed-off-by:
Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by:
-
Michael J. Ruhl authored
[ Upstream commit 5da9e742 ] The module parameter num_user_context is defined as 'int' and defaults to -1. The module_param_named() says that it is uint. Correct module_param_named() type information and update the modinfo text to reflect the default value. Reviewed-by:
-
Stefan Raspl authored
[ Upstream commit bda27ff5 ] The sendpage() call grabs the sock lock before calling the default implementation - which tries to grab it once again. Signed-off-by:
Stefan Raspl <raspl@linux.ibm.com> Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>< Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Janusz Krzysztofik authored
[ Upstream commit baf64250 ] The deferred_fiq handler used to limit hardware operations to IRQ unmask only, relying on gpio-omap assigned handler performing the ACKs. Since commit 80ac93c2 ("gpio: omap: Fix lost edge interrupts") this is no longer the case as handle_edge_irq() has been replaced with handle_simmple_irq() which doesn't touch the hardware. Add single ACK operation per each active IRQ pin to the handler. While being at it, move unmask operation out of irq_counter loop so it is also called only once for each active IRQ pin. Fixes: 80ac93c2 ("gpio: omap: Fix lost edge interrupts") Signed-off-by:
Janusz Krzysztofik <jmkrzyszt@gmail.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Keith Busch authored
[ Upstream commit f31a2110 ] If the command a separate metadata buffer attached, the request needs to have the integrity flag set so the driver knows to map it. Signed-off-by:
Keith Busch <keith.busch@intel.com> Reviewed-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Chengguang Xu authored
[ Upstream commit 59a2f3f0 ] When specifying same string type option several times, current option parsing may cause memory leak. Hence, call kfree for previous one in this case. Signed-off-by:
Chengguang Xu <cgxu519@gmx.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
-
Changbin Du authored
[ Upstream commit 0dfc0c79 ] It allows to flush more than 4GB of device TLBs. So the mask should be 64bit wide. UBSAN captured this fault as below. [ 3.760024] ================================================================================ [ 3.768440] UBSAN: Undefined behaviour in drivers/iommu/dmar.c:1348:3 [ 3.774864] shift exponent 64 is too large for 32-bit type 'int' [ 3.780853] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G U 4.17.0-rc1+ #89 [ 3.788661] Hardware name: Dell Inc. OptiPlex 7040/0Y7WYT, BIOS 1.2.8 01/26/2016 [ 3.796034] Call Trace: [ 3.798472] <IRQ> [ 3.800479] dump_stack+0x90/0xfb [ 3.803787] ubsan_epilogue+0x9/0x40 [ 3.807353] __ubsan_handle_shift_out_of_bounds+0x10e/0x170 [ 3.812916] ? qi_flush_dev_iotlb+0x124/0x180 [ 3.817261] qi_flush_dev_iotlb+0x124/0x180 [ 3.821437] iommu_flush_dev_iotlb+0x94/0xf0 [ 3.825698] iommu_flush_iova+0x10b/0x1c0 [ 3.829699] ? fq_ring_free+0x1d0/0x1d0 [ 3.833527] iova_domain_flush+0x25/0x40 [ 3.837448] fq_flush_timeout+0x55/0x160 [ 3.841368] ? fq_ring_free+0x1d0/0x1d0 [ 3.845200] ? fq_ring_free+0x1d0/0x1d0 [ 3.849034] call_timer_fn+0xbe/0x310 [ 3.852696] ? fq_ring_free+0x1d0/0x1d0 [ 3.856530] run_timer_softirq+0x223/0x6e0 [ 3.860625] ? sched_clock+0x5/0x10 [ 3.864108] ? sched_clock+0x5/0x10 [ 3.867594] __do_softirq+0x1b5/0x6f5 [ 3.871250] irq_exit+0xd4/0x130 [ 3.874470] smp_apic_timer_interrupt+0xb8/0x2f0 [ 3.879075] apic_timer_interrupt+0xf/0x20 [ 3.883159] </IRQ> [ 3.885255] RIP: 0010:poll_idle+0x60/0xe7 [ 3.889252] RSP: 0018:ffffb1b201943e30 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13 [ 3.896802] RAX: 0000000080200000 RBX: 000000000000008e RCX: 000000000000001f [ 3.903918] RDX: 0000000000000000 RSI: 000000002819aa06 RDI: 0000000000000000 [ 3.911031] RBP: ffff9e93c6b33280 R08: 00000010f717d567 R09: 000000000010d205 [ 3.918146] R10: ffffb1b201943df8 R11: 0000000000000001 R12: 00000000e01b169d [ 3.925260] R13: 0000000000000000 R14: ffffffffb12aa400 R15: 0000000000000000 [ 3.932382] cpuidle_enter_state+0xb4/0x470 [ 3.936558] do_idle+0x222/0x310 [ 3.939779] cpu_startup_entry+0x78/0x90 [ 3.943693] start_secondary+0x205/0x2e0 [ 3.947607] secondary_startup_64+0xa5/0xb0 [ 3.951783] ================================================================================ Signed-off-by:
Changbin Du <changbin.du@intel.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Bhadram Varka authored
[ Upstream commit 9df50ba7 ] Need to configure PHY interrupt as active low for P3310 Tegra186 platform otherwise it results in spurious interrupts. This issue wasn't seen before because the generic PHY driver without interrupt support was used. Signed-off-by:
Bhadram Varka <vbhadram@nvidia.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Peter Zijlstra authored
[ Upstream commit 741a76b3 ] Gaurav reported a problem with __kthread_parkme() where a concurrent try_to_wake_up() could result in competing stores to ->state which, when the TASK_PARKED store got lost bad things would happen. The comment near set_current_state() actually mentions this competing store, but only mentions the case against TASK_RUNNING. This same store, with different timing, can happen against a subsequent !RUNNING store. This normally is not a problem, because as per that same comment, the !RUNNING state store is inside a condition based wait-loop: for (;;) { set_current_state(TASK_UNINTERRUPTIBLE); if (!need_sleep) break; schedule(); } __set_current_state(TASK_RUNNING); If we loose the (first) TASK_UNINTERRUPTIBLE store to a previous (concurrent) wakeup, the schedule() will NO-OP and we'll go around the loop once more. The problem here is that the TASK_PARKED store is not inside the KTHREAD_SHOULD_PARK condition wait-loop. There is a genuine issue with sleeps that do not have a condition; this is addressed in a subsequent patch. Reported-by:
Gaurav Kohli <gkohli@codeaurora.org> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by:
Oleg Nesterov <oleg@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Peter Zijlstra authored
[ Upstream commit 0b26351b ] Matt reported the following deadlock: CPU0 CPU1 schedule(.prev=migrate/0) <fault> pick_next_task() ... idle_balance() migrate_swap() active_balance() stop_two_cpus() spin_lock(stopper0->lock) spin_lock(stopper1->lock) ttwu(migrate/0) smp_cond_load_acquire() -- waits for schedule() stop_one_cpu(1) spin_lock(stopper1->lock) -- waits for stopper lock Fix this deadlock by taking the wakeups out from under stopper->lock. This allows the active_balance() to queue the stop work and finish the context switch, which in turn allows the wakeup from migrate_swap() to observe the context and complete the wakeup. Signed-off-by:
Matt Fleming <matt@codeblueprint.co.uk> Signed-off-by:
-
Helge Deller authored
[ Upstream commit b819439f ] Fix two section mismatches in drivers.c: 1) Section mismatch in reference from the function alloc_tree_node() to the function .init.text:create_tree_node(). 2) Section mismatch in reference from the function walk_native_bus() to the function .init.text:alloc_pa_dev(). Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Daniel Borkmann authored
[ Upstream commit 3aab8884 ] While reviewing x64 JIT code, I noticed that we leak the prior allocated JIT image in the case where proglen != oldproglen during the JIT passes. Prior to the commit e0ee9c12 ("x86: bpf_jit: fix two bugs in eBPF JIT compiler") we would just break out of the loop, and using the image as the JITed prog since it could only shrink in size anyway. After e0ee9c12, we would bail out to out_addrs label where we free addrs and jit_data but not the image coming from bpf_jit_binary_alloc(). Fixes: e0ee9c12 ("x86: bpf_jit: fix two bugs in eBPF JIT compiler") Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
-
Jim Gill authored
[ Upstream commit f4b02427 ] The vmw_pvscsi driver returns DID_ABORT for commands aborted internally by the adapter, leading to the filesystem going read-only. Change the result to DID_BUS_BUSY, causing the kernel to retry the command. Signed-off-by:
Jim Gill <jgill@vmware.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 330e261c ] This is needed to link ipv6 as a loadable module, which in turn happens in allmodconfig. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Richard Kuo <rkuo@codeaurora.org> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit a57ab96e ] We already have memcpy_toio(), but not memset_io(), so let's add the obvious version to allow building an allmodconfig kernel without errors like drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_bo_move_memcpy': drivers/gpu/drm/ttm/ttm_bo_util.c:390:3: error: implicit declaration of function 'memset_io' [-Werror=implicit-function-declaration] Signed-off-by:
-
Nick Dyer authored
[ Upstream commit 068bdb67 ] The automatic update mechanism will trigger an update if the info block CRCs are different between maxtouch configuration file (maxtouch.cfg) and chip. The driver compared the CRCs without retrieving the chip CRC, resulting always in a failure and firmware flashing action triggered. Fix this issue by retrieving the chip info block CRC before the check. Note that this solution has the benefit that by reading the information block and the object table into a contiguous region of memory, we can verify the checksum at probe time. This means we make sure that we are indeed talking to a chip that supports object protocol correctly. Using this patch on a kevin chromebook, the touchscreen and touchpad drivers are able to match the CRC: atmel_mxt_ts 3-004b: Family: 164 Variant: 14 Firmware V2.3.AA Objects: 40 atmel_mxt_ts 5-004a: Family: 164 Variant: 17 Firmware V2.0.AA Objects: 31 atmel_mxt_ts 3-004b: Resetting device atmel_mxt_ts 5-004a: Resetting device atmel_mxt_ts 3-004b: Config CRC 0x573E89: OK atmel_mxt_ts 3-004b: Touchscreen size X4095Y2729 input: Atmel maXTouch Touchscreen as /devices/platform/ff130000.i2c/i2c-3/3-004b/input/input5 atmel_mxt_ts 5-004a: Config CRC 0x0AF6BA: OK atmel_mxt_ts 5-004a: Touchscreen size X1920Y1080 input: Atmel maXTouch Touchpad as /devices/platform/ff140000.i2c/i2c-5/5-004a/input/input6 Signed-off-by:
Nick Dyer <nick.dyer@shmanahar.org> Acked-by:
Benson Leung <bleung@chromium.org> [Ezequiel: minor patch massage] Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Tested-by:
Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Adam Ford authored
[ Upstream commit 95e59fc3 ] The Audio has worked, but the mute pin has a weak pulldown which alows some of the audio signal to pass very quietly. This patch fixes that so the mute pin is actively driven high for mute or low for normal operation. Fixes: ab8dd3ae ("ARM: DTS: Add minimal Support for Logic PD DM3730 SOM-LV") Signed-off-by:
Adam Ford <aford173@gmail.com> Signed-off-by:
-
Adam Ford authored
[ Upstream commit 189822cb ] The VAUX3 rail from the PMIC powers a clock driver which clocks the WL127x. This corrects a bug which did not correctly associate the vin-supply with the proper power rail. This also fixes a typo in the pinmuxing to properly configure the interrupt pin. Fixes: ab8dd3ae ("ARM: DTS: Add minimal Support for Logic PD DM3730 SOM-LV") Signed-off-by:
-
Tero Kristo authored
[ Upstream commit 33e95724 ] smp_processor_id() checks preemption if CONFIG_DEBUG_PREEMPT is enabled, causing a warning dump during boot: [ 5.042377] BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 [ 5.050281] caller is pwrdm_set_next_pwrst+0x48/0x88 [ 5.055330] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.14.24-g57341df0b4 #1 Use the raw_smp_processor_id() for the trace instead, this value does not need to be perfectly correct. The alternative of disabling preempt is too heavy weight operation to be applied in PM hot path for just tracing purposes. Signed-off-by:
Tero Kristo <t-kristo@ti.com> Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit f1303070 ] Fixes: 14da3ed8 ("devicetree/bindings: display: Document common panel properties") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Sekhar Nori authored
[ Upstream commit 5c054de2 ] Since commit 09f3756b ("dm9000: Return an ERR_PTR() in all error conditions of dm9000_parse_dt()"), passing either non-NULL platform data or device-tree for dm9000 driver to probe is mandatory. DM335 board was using none, so networking failed to initialize. Fix it by passing non-NULL (but empty) platform data. Fixes: 09f3756b ("dm9000: Return an ERR_PTR() in all error conditions of dm9000_parse_dt()") Signed-off-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
-
Sekhar Nori authored
[ Upstream commit d45622c0 ] commit c4dc56be ("ARM: davinci: fix the GPIO lookup for omapl138-hawk") fixed the GPIO chip name for look-up of MMC/SD CD and WP pins, but forgot to change the GPIO numbers passed. The GPIO numbers are not offsets from within a 32 GPIO bank. Fix the GPIO numbers as well as remove the misleading comment. Fixes: c4dc56be ("ARM: davinci: fix the GPIO lookup for omapl138-hawk") Reviewed-by:
David Lechner <david@lechnology.com> Signed-off-by:
-
Sekhar Nori authored
[ Upstream commit 67c6b6ff ] The GPIO chip is called davinci_gpio.0 in legacy mode. Fix it, so that mmc can correctly lookup the wp and cp gpios. Also fix the GPIO numbers as they are not offsets within a bank. Note that it is the gpio-davinci driver that sets the gpiochip label to davinci_gpio.0. Fixes: bdf0e836 ("ARM: davinci: da850-evm: use gpio descriptor for mmc pins") Reviewed-by:
-
Sekhar Nori authored
[ Upstream commit 51e9f121 ] The GPIO chip is called davinci_gpio.0 in legacy mode. Fix it, so that mmc can correctly lookup the wp and cp gpios. Also fix the GPIO numbers as they are not offsets within a bank. Note that it is the gpio-davinci driver that sets the gpiochip label to davinci_gpio.0. Fixes: b5e1438c ("ARM: davinci: da830-evm: use gpio descriptor for mmc pins") Reported-by:
-
Håkon Bugge authored
[ Upstream commit db82476f ] Currently, the kernel protects access to the agent ID allocator on a per port basis using a spinlock, so it is impossible for two apps/threads on the same port to get the same TID, but it is entirely possible for two threads on different ports to end up with the same TID. As this can be confusing (regardless of it being legal according to the IB Spec 1.3, C13-18.1.1, in section 13.4.6.4 - TransactionID usage), and as the rdma-core user space API for /dev/umad devices implies unique TIDs even across ports, make the TID an atomic type so that no two allocations, regardless of port number, will be the same. Signed-off-by:
Håkon Bugge <haakon.bugge@oracle.com> Reviewed-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Reviewed-by:
Ira Weiny <ira.weiny@intel.com> Reviewed-by:
Zhu Yanjun <yanjun.zhu@oracle.com> Signed-off-by:
-
Amir Goldstein authored
[ Upstream commit 19b9ad67 ] The comment claims that this helper will try not to loose bits, but for 64bit long it looses the high bits before hashing 64bit long into 32bit int. Use the helper hash_long() to do the right thing for 64bit long. For 32bit long, there is no change. All the callers of end_name_hash() either assign the result to qstr->hash, which is u32 or return the result as an int value (e.g. full_name_hash()). Change the helper return type to int to conform to its users. [ It took me a while to apply this, because my initial reaction to it was - incorrectly - that it could make for slower code. After having looked more at it, I take back all my complaints about the patch, Amir was right and I was mis-reading things or just being stupid. I also don't worry too much about the possible performance impact of this on 64-bit, since most architectures that actually care about performance end up not using this very much (the dcache code is the most performance-critical, but the word-at-a-time case uses its own hashing anyway). So this ends up being mostly used for filesystems that do their own degraded hashing (usually because they want a case-insensitive comparison function). A _tiny_ worry remains, in that not everybody uses DCACHE_WORD_ACCESS, and then this potentially makes things more expensive on 64-bit architectures with slow or lacking multipliers even for the normal case. That said, realistically the only such architecture I can think of is PA-RISC. Nobody really cares about performance on that, it's more of a "look ma, I've got warts^W an odd machine" platform. So the patch is fine, and all my initial worries were just misplaced from not looking at this properly. - Linus ] Signed-off-by:
Amir Goldstein <amir73il@gmail.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Zhu Yanjun authored
[ Upstream commit 9fd4350b ] When skb is sent, it will pass the following functions in soft roce. rxe_send [rdma_rxe] ip_local_out __ip_local_out ip_output ip_finish_output ip_finish_output2 dev_queue_xmit __dev_queue_xmit dev_hard_start_xmit In the above functions, if error occurs in the above functions or iptables rules drop skb after ip_local_out, kfree_skb will be called. So it is not necessary to call kfree_skb in soft roce module again. Or else crash will occur. The steps to reproduce: server client --------- --------- |1.1.1.1|<----rxe-channel--->|1.1.1.2| --------- --------- On server: rping -s -a 1.1.1.1 -v -C 10000 -S 512 On client: rping -c -a 1.1.1.1 -v -C 10000 -S 512 The kernel configs CONFIG_DEBUG_KMEMLEAK and CONFIG_DEBUG_OBJECTS are enabled on both server and client. When rping runs, run the following command in server: iptables -I OUTPUT -p udp --dport 4791 -j DROP Without this patch, crash will occur. CC: Srinivas Eeda <srinivas.eeda@oracle.com> CC: Junxiao Bi <junxiao.bi@oracle.com> Signed-off-by:
Yuval Shaia <yuval.shaia@oracle.com> Signed-off-by:
-
Jianchao Wang authored
[ Upstream commit 2da36d44 ] w/o RXE_START_MASK, the last_psn of IB_OPCODE_RC_SEND_ONLY_INV will not be updated in update_wqe_psn, and the corresponding wqe will not be acked in rxe_completer due to its last_psn is zero. Finally, the other wqe will also not be able to be acked, because the wqe of IB_OPCODE_RC_SEND_ONLY_INV with last_psn 0 is still there. This causes large amount of io timeout when nvmeof is over rxe. Add RXE_START_MASK for IB_OPCODE_RC_SEND_ONLY_INV to fix this. Signed-off-by:
Jianchao Wang <jianchao.w.wang@oracle.com> Reviewed-by:
-
Colin Ian King authored
[ Upstream commit f96416ce ] In the cases where iwpm_hash_bucket is NULL and where function get_mapinfo_hash_bucket returns NULL then the map_info is never added to hash_bucket_head and hence there is a leak of map_info. Fix this by nullifying hash_bucket_head and if that is null we know that that map_info was not added to hash_bucket_head and hence map_info should be free'd. Detected by CoverityScan, CID#1222481 ("Resource Leak") Fixes: 30dc5e63 ("RDMA/core: Add support for iWARP Port Mapper user space service") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Parav Pandit authored
[ Upstream commit 2918c1a9 ] There are few issues with validation of netdevice and listen id lookup for IB (IPoIB) while processing incoming CM request as below. 1. While performing lookup of bind_list in cma_ps_find(), net namespace of the netdevice can get deleted in cma_exit_net(), resulting in use after free access of idr and/or net namespace structures. This lookup occurs from the workqueue context (and not userspace context where net namespace is always valid). CPU0 CPU1 ==== ==== bind_list = cma_ps_find(); move netdevice to new namespace delete net namespace cma_exit_net() idr_destroy(idr); [..] cma_find_listener(bind_list, ..); 2. While netdevice is validated for IP address in given net namespace, netdevice's net namespace and/or ifindex can change in cma_get_net_dev() and cma_match_net_dev(). Above issues are overcome by using rcu lock along with netdevice UP/DOWN state as described below. When a net namespace is getting deleted, netdevice is closed and shutdown before moving it back to init_net namespace. change_net_namespace() synchronizes with any existing use of netdevice before changing the netdev properties such as net or ifindex. Once netdevice IFF_UP flags is cleared, such fields are not guaranteed to be valid. Therefore, rcu lock along with netdevice state check ensures that, while route lookup and cm_id lookup is in progress, netdevice of interest won't migrate to any other net namespace. This ensures that associated net namespace of netdevice won't get deleted while rcu lock is held for netdevice which is in IFF_UP state. Fixes: fa20105e ("IB/cma: Add support for network namespaces") Fixes: 4be74b42 ("IB/cma: Separate port allocation to network namespaces") Fixes: f887f2ac ("IB/cma: Validate routing of incoming requests") Signed-off-by:
-
Matan Barak authored
[ Upstream commit f604db64 ] Previously, if a method contained mandatory attributes in a namespace that wasn't given by the user, these attributes weren't validated. Fixing this by iterating over all specification namespaces. Fixes: fac9658c ("IB/core: Add new ioctl interface") Signed-off-by:
Matan Barak <matanb@mellanox.com> Signed-off-by:
-
Greg Thelen authored
[ Upstream commit f7cb7b85 ] Allow INFINIBAND without INFINIBAND_ADDR_TRANS because fuzzing has been finding fair number of CM bugs. So provide option to disable it. Signed-off-by:
Greg Thelen <gthelen@google.com> Cc: Tarick Bedeir <tarick@google.com> Reviewed-by:
Bart Van Assche <bart.vanassche@wdc.com> Signed-off-by:
-
Greg Thelen authored
[ Upstream commit 5a3bc8a4 ] INFINIBAND_SRP code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by:
-
Greg Thelen authored
[ Upstream commit 346a47b6 ] INFINIBAND_SRPT code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by:
-
Greg Thelen authored
[ Upstream commit d6fc6a22 ] NVME_TARGET_RDMA code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by:
-
Greg Thelen authored
[ Upstream commit 3af7a156 ] NVME_RDMA code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by:
-
Jon Maloy authored
[ Upstream commit 7dbc73e6 ] Commit 36a50a98 ("tipc: fix infinite loop when dumping link monitor summary") intended to fix a problem with user tool looping when max number of bearers are enabled. Unfortunately, the wrong version of the commit was posted, so the problem was not solved at all. This commit adds the missing part. Fixes: 36a50a98 ("tipc: fix infinite loop when dumping link monitor summary") Signed-off-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
-
Baolin Wang authored
[ Upstream commit 2a010461 ] We found the I2C controller count register is unreliable sometimes, that will cause I2C to lose data. Thus we can read the data count from 'i2c_dev->count' instead of the I2C controller count register. Signed-off-by:
Baolin Wang <baolin.wang@linaro.org> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Baolin Wang authored
[ Upstream commit da33aa03 ] Add one flag to indicate if the i2c controller has been in suspend state, which can prevent i2c accesses after i2c controller is suspended following system suspend. Signed-off-by:
-
