- 24 Jan, 2017 27 commits
-
-
Bart Van Assche authored
Prepare for removal of ib_device.dma_device. Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Cc: Christian Benvenuti <benve@cisco.com> Cc: Dave Goodell <dgoodell@cisco.com> Signed-off-by:
Doug Ledford <dledford@redhat.com>
-
Bart Van Assche authored
Prepare for removal of ib_device.dma_device. Signed-off-by:
-
Bart Van Assche authored
Prepare for removal of ib_device.dma_device. Signed-off-by:
-
Bart Van Assche authored
Prepare for removal of ib_device.dma_device. Signed-off-by:
-
Bart Van Assche authored
Prepare for removal of ib_device.dma_device. Signed-off-by:
-
Bart Van Assche authored
Prepare for removal of ib_device.dma_device. Signed-off-by:
-
Bart Van Assche authored
Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
-
Bart Van Assche authored
Prepare for removal of ib_device.dma_device. Signed-off-by:
-
Bart Van Assche authored
Due to a previous patch initializing ib_device.dev.parent is sufficient and initializing dma_device is no longer needed. Signed-off-by:
Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by:
-
Bart Van Assche authored
Prepare for removal of ib_device.dma_device. Signed-off-by:
-
Bart Van Assche authored
Prepare for removal of ib_device.dma_device. Signed-off-by:
-
Bart Van Assche authored
Prepare for removal of ib_device.dma_device. Signed-off-by:
Steve Wise <swise@chelsio.com> Signed-off-by:
-
Bart Van Assche authored
Prepare for removal of ib_device.dma_device. Signed-off-by:
-
Bart Van Assche authored
Prepare for removal of ib_device.dma_device. Signed-off-by:
-
Bart Van Assche authored
Move the ib_device.dev.parent initialization code from ib_device_register_sysfs() to ib_register_device(). Additionally, allow HBA drivers to set ib_device.dev.parent without setting ib_device.dma_device. This is the first step towards removing ib_device.dma_device. Signed-off-by:
-
Bart Van Assche authored
The qib DMA mapping code is no longer built since commit eb636ac0 ("IB/qib: Remove dma.c and use rdmavt version of dma functions"). Hence remove it. Signed-off-by:
-
Bart Van Assche authored
The hfi1 DMA mapping code has never been built in any upstream kernel. Hence remove it. Signed-off-by:
-
Bart Van Assche authored
Change the type of the dma_handle argument from u64 * to dma_addr_t *. This patch does not change any functionality. Signed-off-by:
-
Bart Van Assche authored
Signed-off-by:
Santosh Shilimkar <santosh.shilimkar@oracle.com> Cc: David S. Miller <davem@davemloft.net> Cc: linux-rdma@vger.kernel.org Cc: netdev@vger.kernel.org Cc: rds-devel@oss.oracle.com Signed-off-by:
-
Bart Van Assche authored
Remove these functions because these are not used. Additionally, the implementation of these functions is not correct for the hfi1, qib and rxe drivers because dma_device is used instead of dma_ops. Signed-off-by:
-
Bart Van Assche authored
Several RDMA drivers (hfi1, qib and rxe) expect that ib_sge.addr is a virtual address. Provide DMA mapping operations that are suitable for these drivers. Signed-off-by:
-
Bart Van Assche authored
Reduce the kernel size by only building dma_noop_ops for those architectures that actually use it. This was suggested by Christoph Hellwig. Signed-off-by:
-
Bart Van Assche authored
The next patch in this series will introduce another set of DMA operations that map 1:1 with memory. Clarify that dma-noop maps to physical addresses. Signed-off-by:
-
Bart Van Assche authored
Introduce a new architecture-specific get_arch_dma_ops() function that takes a struct bus_type * argument. Add get_dma_ops() in <linux/dma-mapping.h>. Signed-off-by:
-
Bart Van Assche authored
Now that all set_dma_ops() implementations are identical (ignoring BUG_ON() statements), remove the architecture specific definitions and add a definition in <linux/dma-mapping.h>. Signed-off-by:
-
Bart Van Assche authored
Some but not all architectures provide set_dma_ops(). Move dma_ops from struct dev_archdata into struct device such that it becomes possible on all architectures to configure dma_ops per device. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Juergen Gross <jgross@suse.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: linux-arch@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Russell King <linux@armlinux.org.uk> Cc: x86@kernel.org Signed-off-by:
-
Bart Van Assche authored
Most dma_map_ops structures are never modified. Constify these structures such that these can be write-protected. This patch has been generated as follows: git grep -l 'struct dma_map_ops' | xargs -d\\n sed -i \ -e 's/struct dma_map_ops/const struct dma_map_ops/g' \ -e 's/const struct dma_map_ops {/struct dma_map_ops {/g' \ -e 's/^const struct dma_map_ops;$/struct dma_map_ops;/' \ -e 's/const const struct dma_map_ops /const struct dma_map_ops /g'; sed -i -e 's/const \(struct dma_map_ops intel_dma_ops\)/\1/' \ $(git grep -l 'struct dma_map_ops intel_dma_ops'); sed -i -e 's/const \(struct dma_map_ops dma_iommu_ops\)/\1/' \ $(git grep -l 'struct dma_map_ops' | grep ^arch/powerpc); sed -i -e '/^struct vmd_dev {$/,/^};$/ s/const \(struct dma_map_ops[[:blank:]]dma_ops;\)/\1/' \ -e '/^static void vmd_setup_dma_ops/,/^}$/ s/const \(struct dma_map_ops \*dest\)/\1/' \ -e 's/const \(struct dma_map_ops \*dest = \&vmd->dma_ops\)/\1/' \ drivers/pci/host/*.c sed -i -e '/^void __init pci_iommu_alloc(void)$/,/^}$/ s/dma_ops->/intel_dma_ops./' arch/ia64/kernel/pci-dma.c sed -i -e 's/static const struct dma_map_ops sn_dma_ops/static struct dma_map_ops sn_dma_ops/' arch/ia64/sn/pci/pci_dma.c sed -i -e 's/(const struct dma_map_ops \*)//' drivers/misc/mic/bus/vop_bus.c Signed-off-by:Christoph Hellwig <hch@lst.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Juergen Gross <jgross@suse.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: linux-arch@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Russell King <linux@armlinux.org.uk> Cc: x86@kernel.org Signed-off-by:
-
- 13 Jan, 2017 4 commits
-
-
Jack Wang authored
Signed-off-by:
Jack Wang <jinpu.wang@profitbricks.com> Reviewed-by:
Michael Wang <yun.wang@profitbricks.com> Acked-by:
Sean Hefty <sean.hefty@intel.com> Signed-off-by:
-
Jack Wang authored
When we try to resolve a dest addr, if we don't give src addr, cma core will try to resolve to our source ib device automatically. The current logic only checks if a given port has the same subnet_prefix as our dest, which is not enough if we use default well known subnet_prefix on our active port, as it will be the same as the subnet_prefix on inactive ports and we might match against an inactive port by accident. To resolve this, we should also check if port is active before we resolve it as a suitable src address for a given dest. Signed-off-by:
-
Jack Wang authored
Export function for rdma_cm, patch for rdma_cm to follow. Signed-off-by:
-
Jack Wang authored
We need a port state cache in ib_core, later we will use in rdma_cm. Signed-off-by:
-
- 12 Jan, 2017 9 commits
-
-
Feras Daoud authored
Since ipoib_cm_tx_start function and ipoib_cm_tx_reap function belong to different work queues, they can run in parallel. In this case if ipoib_cm_tx_reap calls list_del and release the lock, ipoib_cm_tx_start may acquire it and call list_del_init on the already deleted object. Changing list_del to list_del_init in ipoib_cm_tx_reap fixes the problem. Fixes: 839fcaba ("IPoIB: Connected mode experimental support") Signed-off-by:
Feras Daoud <ferasda@mellanox.com> Signed-off-by:
Erez Shitrit <erezsh@mellanox.com> Reviewed-by:
Alex Vesker <valex@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Reviewed-by:
Yuval Shaia <yuval.shaia@oracle.com> Signed-off-by:
-
Feras Daoud authored
In order to resolve a situation where a few process delete the same list element in sequence and cause panic, list_del is replaced with list_del_init. In this case if the first process that calls list_del releases the lock before acquiring it again, other processes who can acquire the lock will call list_del_init. Fixes: b63b70d8 ("IPoIB: Use a private hash table for path lookup") Signed-off-by:
-
Feras Daoud authored
If a receive request has not been posted to the work queue, the incoming message is rejected and the peer will receive a receiver-not-ready (RNR) error. In IPoIB, IB_WC_RNR_RETRY_EXC_ERR error is part of the life cycle therefore ipoib_cm_handle_tx_wc function will print to debug instead of warnings. Signed-off-by:
-
Feras Daoud authored
Add a detailed return code to dev_queue_xmit function when calling to requeue packet via __skb_dequeue. Signed-off-by:
-
Feras Daoud authored
The ipoib_vlan_add function calls rtnl_unlock after free_netdev, rtnl_unlock not only releases the lock, but also calls netdev_run_todo. The latter function browses the net_todo_list array and completes the unregistration of all its net_device instances. If we call free_netdev before rtnl_unlock, then netdev_run_todo call over the freed device causes panic. To fix, move rtnl_unlock call before free_netdev call. Fixes: 9baa0b03 ("IB/ipoib: Add rtnl_link_ops support") Cc: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
-
Feras Daoud authored
When calling set_mode from sys/fs, the call flow locks the sys/fs lock first and then tries to lock rtnl_lock (when calling ipoib_set_mod). On the other hand, the rmmod call flow takes the rtnl_lock first (when calling unregister_netdev) and then tries to take the sys/fs lock. Deadlock a->b, b->a. The problem starts when ipoib_set_mod frees it's rtnl_lck and tries to get it after that. set_mod: [<ffffffff8104f2bd>] ? check_preempt_curr+0x6d/0x90 [<ffffffff814fee8e>] __mutex_lock_slowpath+0x13e/0x180 [<ffffffff81448655>] ? __rtnl_unlock+0x15/0x20 [<ffffffff814fed2b>] mutex_lock+0x2b/0x50 [<ffffffff81448675>] rtnl_lock+0x15/0x20 [<ffffffffa02ad807>] ipoib_set_mode+0x97/0x160 [ib_ipoib] [<ffffffffa02b5f5b>] set_mode+0x3b/0x80 [ib_ipoib] [<ffffffff8134b840>] dev_attr_store+0x20/0x30 [<ffffffff811f0fe5>] sysfs_write_file+0xe5/0x170 [<ffffffff8117b068>] vfs_write+0xb8/0x1a0 [<ffffffff8117ba81>] sys_write+0x51/0x90 [<ffffffff8100b0f2>] system_call_fastpath+0x16/0x1b rmmod: [<ffffffff81279ffc>] ? put_dec+0x10c/0x110 [<ffffffff8127a2ee>] ? number+0x2ee/0x320 [<ffffffff814fe6a5>] schedule_timeout+0x215/0x2e0 [<ffffffff8127cc04>] ? vsnprintf+0x484/0x5f0 [<ffffffff8127b550>] ? string+0x40/0x100 [<ffffffff814fe323>] wait_for_common+0x123/0x180 [<ffffffff81060250>] ? default_wake_function+0x0/0x20 [<ffffffff8119661e>] ? ifind_fast+0x5e/0xb0 [<ffffffff814fe43d>] wait_for_completion+0x1d/0x20 [<ffffffff811f2e68>] sysfs_addrm_finish+0x228/0x270 [<ffffffff811f2fb3>] sysfs_remove_dir+0xa3/0xf0 [<ffffffff81273f66>] kobject_del+0x16/0x40 [<ffffffff8134cd14>] device_del+0x184/0x1e0 [<ffffffff8144e59b>] netdev_unregister_kobject+0xab/0xc0 [<ffffffff8143c05e>] rollback_registered+0xae/0x130 [<ffffffff8143c102>] unregister_netdevice+0x22/0x70 [<ffffffff8143c16e>] unregister_netdev+0x1e/0x30 [<ffffffffa02a91b0>] ipoib_remove_one+0xe0/0x120 [ib_ipoib] [<ffffffffa01ed95f>] ib_unregister_device+0x4f/0x100 [ib_core] [<ffffffffa021f5e1>] mlx4_ib_remove+0x41/0x180 [mlx4_ib] [<ffffffffa01ab771>] mlx4_remove_device+0x71/0x90 [mlx4_core] Fixes: 862096a8 ("IB/ipoib: Add more rtnl_link_ops callbacks") Cc: <stable@vger.kernel.org> # v3.6+ Cc: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: -
Feras Daoud authored
This patch fixes Deadlock while executing ipoib_vlan_delete. The function takes the vlan_rwsem semaphore and calls unregister_netdevice. The later function calls ipoib_mcast_stop_thread that cause workqueue flush. When the queue has one of the ipoib_ib_dev_flush_xxx events, a deadlock occur because these events also tries to catch the same vlan_rwsem semaphore. To fix, unregister_netdevice should be called after releasing the semaphore. Fixes: cbbe1efa ("IPoIB: Fix deadlock between ipoib_open() and child interface create") Signed-off-by:
-
Feras Daoud authored
When changing the connection mode, the ipoib_set_mode function did not check if the previous connection mode equals to the new one. This commit adds the required check and return 0 if the new mode equals to the previous one. Fixes: 839fcaba ("IPoIB: Connected mode experimental support") Signed-off-by:
-
Feras Daoud authored
In datagram mode, the IB UD (Unreliable Datagram) transport is used so the MTU of the interface is equal to the IB L2 MTU minus the IPoIB encapsulation header. Any request to change the MTU value above the maximum range will change the MTU to the max allowed, but will not show any warning message. An ipoib_warn is issued in such cases, letting the user know that even though the value is legal, it can't be currently applied. Signed-off-by:
Noa Osherovich <noaos@mellanox.com> Signed-off-by:
-
