format string mismatch in drivers/iio/industrialio-core.c:206
Hi, FIWI cppcheck blames this : [drivers/iio/industrialio-core.c:206]: (warning) %i in format string (no. 1) requires 'int *' but the argument type is 'unsigned int *'. [drivers/iio/industrialio-core.c:206]: (warning) %i in format string (no. 2) requires 'int *' but the argument type is 'unsigned int *'. -- Toralf -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: format string mismatch in drivers/iio/industrialio-core.c:206
On 05/19/2014 04:19 PM, Toralf Förster wrote: Hi, FIWI cppcheck blames this : [drivers/iio/industrialio-core.c:206]: (warning) %i in format string (no. 1) requires 'int *' but the argument type is 'unsigned int *'. [drivers/iio/industrialio-core.c:206]: (warning) %i in format string (no. 2) requires 'int *' but the argument type is 'unsigned int *'. And btw : [drivers/infiniband/hw/cxgb3/iwch_provider.c:1138]: (warning) %i in format string (no. 1) requires 'int *' but the argument type is 'unsigned int *'. [drivers/infiniband/hw/cxgb3/iwch_provider.c:1140]: (warning) %i in format string (no. 1) requires 'int *' but the argument type is 'unsigned int *'. [drivers/infiniband/hw/cxgb3/iwch_provider.c:1142]: (warning) %i in format string (no. 1) requires 'int *' but the argument type is 'unsigned int *'. -- Toralf -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] OFED 3.12 rc3 release is available
Hi, OFED-3.12-rc3 is available at: https://www.openfabrics.org/downloads/OFED/ofed-3.12/OFED-3.12-rc3.tgz To get BUILD_ID run ofed_info Please report any issues in bugzilla http://bugs.openfabrics.org/bugzilla/ for OFED 3.12 OFED-3.12-rc3 Main Changes from OFED 3.12-rc2 --- Updated packages: - perftest-2.2-0.17.g5eba807 Regards, Vladimir Open Fabrics Enterprise Distribution (OFED) Version 3.12-rc3 Release Notes May 2014 === Table of Contents === 1. Overview, which includes: - OFED Distribution Rev 3.12-rc3 Contents - Supported Platforms and Operating Systems - Supported HCA and RNIC Adapter Cards and Firmware Versions - Tested Switch Platforms - Third party Test Packages - OFED sources 2. Change log 3. Known Issues === 1. Overview === These are the release notes of OpenFabrics Enterprise Distribution (OFED) release 3.12-rc2. The OFED software package is composed of several software modules, and is intended for use on a computer cluster constructed as an InfiniBand Fabric, an iWARP Network or a RoCE Fabric. Note: If you plan to upgrade the OFED package on your cluster, please upgrade all of its nodes to this new version. 1.1 OFED 3.12-rc3 Contents --- The OFED package contains the following components: - OpenFabrics core and ULPs: - IB HCA drivers (mthca, mlx4, mlx5, qib, ehca, ocrdma) - iWARP RNIC driver (cxgb3, cxgb4, nes) - RoCE drivers (mlx4, ocrdma) - ib core - Upper Layer Protocols: IPoIB, SRP Initiator and target, iSER Initiator and target, RDS, uDAPL, qlgc_vnic and NFS-RDMA*. - OpenFabrics utilities: - OpenSM (OSM): InfiniBand Subnet Manager - Diagnostic tools - Performance tests - Extra packages: - infinipath-psm: Performance-Scaled Messaging API, an accelerated interface to Intel(R) HCAs - Sources of all software modules (under conditions mentioned in the modules' LICENSE files) - Documentation 1.2 Supported Platforms and Operating Systems - o CPU architectures: - x86_64 - x86 - ppc64 o Linux Operating Systems: - RedHat EL6.4 2.6.32-358.el6 - RedHat EL6.5 2.6.32-431.el6 - SLES11 SP33.0.76-0.9.1 - kernel.org3.12* * Minimal QA for these versions. 1.3 HCAs and RNICs Supported This release supports IB HCAs by IBM, Intel and Mellanox Technologies, iWARP RNICs by Chelsio Communications and Intel and RoCE adapters by IBM and Mellanox. InfiniBand Adapters o IBM HCAs: - GX Dual-port SDR 4x IB HCA - GX Dual-port SDR 12x IB HCA - GX Dual-port DDR 4x IB HCA - GX Dual-port DDR 12x IB HCA o Intel (formerly QLogic) HCAs: - Intel(R) True Scale DDR PCIe x8 and x16 HCAs - Intel(R) True Scale QDR PCIe x8 Gen2 HCAs o Mellanox Technologies HCAs (SDR, DDR and QDR Modes are Supported): - ConnectX(R) and ConnectX EN (fw-25408 Rev 2.9.1000) - ConnectX-2 (fw-ConnectX2 Rev 2.9.1000) o Mellanox Technologies HCAs (FDR and FDR10 Modes are Supported): - ConnectX-3 (fw-ConnectX3 Rev 2.30.8000) o Mellanox Technologies HCAs (FDR and FDR10 Modes are Supported): - Connect-IB™ (fw-ConnectIB.mlx Rev 10.10.2000 and above) For official firmware versions please see: http://www.mellanox.com/content/pages.php?pg=firmware_download iWARP Adapters o Chelsio RNICs: - S310/S320 10GbE Storage Accelerators - R310/R320 10GbE iWARP Adapters - T4 Based Adapters with the exception of the T420-SO-CR o Intel RNICs: - NE020 10Gb iWARP Adapter RoCE Adapters o IBM - IBM Flex System EN4132 2-port 10 GbE RoCE - IBM EL27 PCIe LP 2-Port 10GbE RoCE SFP+ adapter - IBM EC28 PCIe 2-Port 10GbE RoCE SFP+ adapter o Mellanox - ConnectX-2 EN (fw-ConnectX2 Rev 2.9.1200) - ConnectX-3 EN (fw-ConnectX3 Rev 2.11.0500) 1.4 Switches Supported -- This release was tested with switches and gateways provided by the following companies: InfiniBand Switches o Flextronics - F-X430044 o Intel (formerly QLogic) - 12200 o Mellanox - IS-5030 - SX6025 - SX6036 iWARP Switches o Fujitsu - XG2000C 10Gb Ethernet Switch RoCE Switches o Arista o BLADE Network Technologies (BNT) o Mellanox
[PATCH] NFSD: Ignore client's source port on RDMA transports
An NFS/RDMA client's source port is meaningless for RDMA transports.
The transport layer typically sets the source port value on the
connection to a random ephemeral port.
Currently, NFS server administrators must specify the insecure
export option to enable clients to access exports via RDMA.
But this means NFS clients can access such an export via IP using an
ephemeral port, which may not be desirable.
This patch eliminates the need to specify the insecure export
option to allow NFS/RDMA clients access to an export.
BugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=250
Signed-off-by: Chuck Lever chuck.le...@oracle.com
---
Hi Bruce-
I've done some simple testing. insecure still behaves correctly
for IP-based clients, and is now unnecessary for RDMA-based clients.
Would you consider this for nfsd-next?
include/linux/sunrpc/svc_xprt.h |1 +
net/sunrpc/svc_xprt.c|2 +-
net/sunrpc/svcsock.c |9 +
net/sunrpc/xprtrdma/svc_rdma_transport.c |7 +++
4 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/include/linux/sunrpc/svc_xprt.h b/include/linux/sunrpc/svc_xprt.h
index b05963f..0cec1b9 100644
--- a/include/linux/sunrpc/svc_xprt.h
+++ b/include/linux/sunrpc/svc_xprt.h
@@ -24,6 +24,7 @@ struct svc_xprt_ops {
void(*xpo_release_rqst)(struct svc_rqst *);
void(*xpo_detach)(struct svc_xprt *);
void(*xpo_free)(struct svc_xprt *);
+ int (*xpo_secure_port)(struct svc_rqst *);
};
struct svc_xprt_class {
diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
index 06c6ff0..614956f 100644
--- a/net/sunrpc/svc_xprt.c
+++ b/net/sunrpc/svc_xprt.c
@@ -793,7 +793,7 @@ int svc_recv(struct svc_rqst *rqstp, long timeout)
clear_bit(XPT_OLD, xprt-xpt_flags);
- rqstp-rq_secure = svc_port_is_privileged(svc_addr(rqstp));
+ rqstp-rq_secure = xprt-xpt_ops-xpo_secure_port(rqstp);
rqstp-rq_chandle.defer = svc_defer;
if (serv-sv_stats)
diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
index 43bcb46..0cb34f5 100644
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
@@ -400,6 +400,12 @@ static void svc_sock_setbufsize(struct socket *sock,
unsigned int snd,
release_sock(sock-sk);
#endif
}
+
+static int svc_sock_secure_port(struct svc_rqst *rqstp)
+{
+ return svc_port_is_privileged(svc_addr(rqstp));
+}
+
/*
* INET callback when data has been received on the socket.
*/
@@ -678,6 +684,7 @@ static struct svc_xprt_ops svc_udp_ops = {
.xpo_prep_reply_hdr = svc_udp_prep_reply_hdr,
.xpo_has_wspace = svc_udp_has_wspace,
.xpo_accept = svc_udp_accept,
+ .xpo_secure_port = svc_sock_secure_port,
};
static struct svc_xprt_class svc_udp_class = {
@@ -1234,6 +1241,7 @@ static struct svc_xprt_ops svc_tcp_bc_ops = {
.xpo_detach = svc_bc_tcp_sock_detach,
.xpo_free = svc_bc_sock_free,
.xpo_prep_reply_hdr = svc_tcp_prep_reply_hdr,
+ .xpo_secure_port = svc_sock_secure_port,
};
static struct svc_xprt_class svc_tcp_bc_class = {
@@ -1272,6 +1280,7 @@ static struct svc_xprt_ops svc_tcp_ops = {
.xpo_prep_reply_hdr = svc_tcp_prep_reply_hdr,
.xpo_has_wspace = svc_tcp_has_wspace,
.xpo_accept = svc_tcp_accept,
+ .xpo_secure_port = svc_sock_secure_port,
};
static struct svc_xprt_class svc_tcp_class = {
diff --git a/net/sunrpc/xprtrdma/svc_rdma_transport.c
b/net/sunrpc/xprtrdma/svc_rdma_transport.c
index 25688fa..02db8d9 100644
--- a/net/sunrpc/xprtrdma/svc_rdma_transport.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_transport.c
@@ -65,6 +65,7 @@ static void dto_tasklet_func(unsigned long data);
static void svc_rdma_detach(struct svc_xprt *xprt);
static void svc_rdma_free(struct svc_xprt *xprt);
static int svc_rdma_has_wspace(struct svc_xprt *xprt);
+static int svc_rdma_secure_port(struct svc_rqst *);
static void rq_cq_reap(struct svcxprt_rdma *xprt);
static void sq_cq_reap(struct svcxprt_rdma *xprt);
@@ -82,6 +83,7 @@ static struct svc_xprt_ops svc_rdma_ops = {
.xpo_prep_reply_hdr = svc_rdma_prep_reply_hdr,
.xpo_has_wspace = svc_rdma_has_wspace,
.xpo_accept = svc_rdma_accept,
+ .xpo_secure_port = svc_rdma_secure_port,
};
struct svc_xprt_class svc_rdma_class = {
@@ -1207,6 +1209,11 @@ static int svc_rdma_has_wspace(struct svc_xprt *xprt)
return 1;
}
+static int svc_rdma_secure_port(struct svc_rqst *rqstp)
+{
+ return 1;
+}
+
/*
* Attempt to register the kvec representing the RPC memory with the
* device.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Soft lockup in unloading kernel modules
Hi Klemens- On May 13, 2014, at 12:48 PM, Klemens Senn klemens.s...@ims.co.at wrote: Hi Anna, today I retried unloading the kernel modules with your updated kernel and additionally I tried the nfsd-next kernel from J. Bruce Fields and Chuck's nfs-rdma-client kernel. I filed https://bugzilla.linux-nfs.org/show_bug.cgi?id=252 to track this issue. In short: None of these was able to unload the kernel modules with an active connection. In detail: With your kernel I got following 3 faults: o BUG: soft lockup - CPU#0 stuck for 22s! [modprobe:4615] o BUG: unable to handle kernel NULL pointer dereference at 0003 o BUG: unable to handle kernel paging request at 5b8c With the nfsd-next kernel I got following results: o BUG: soft lockup - CPU#0 stuck for 23s! [modprobe:4452] o module unloading blocks forever, dmesg shows: nfsd: last server has exited, flushing export cache waiting module removal not supported: please upgrade o Kernel keeps running but reports the following: nfsd: last server has exited, flushing export cache waiting module removal not supported: please upgrade svc_xprt_enqueue: threads and transports both waiting?? INFO: task modprobe:4510 blocked for more than 480 seconds. Not tainted 3.15.0-rc1-bfields-master+ #1 echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. modprobeD 88087fc13440 0 4510 4458 0x 88105bb23c58 0086 88105c14e690 00013440 88105bb23fd8 00013440 81a14480 88105c14e690 0037 88085d7f74d8 88085d7f74e0 7fff Call Trace: [815a2424] schedule+0x24/0x70 [815a18cc] schedule_timeout+0x1ec/0x260 [8159a504] ? printk+0x5c/0x5e [815a3406] wait_for_completion+0x96/0x100 [81080c90] ? try_to_wake_up+0x2b0/0x2b0 [a0314039] cma_remove_one+0x1a9/0x220 [rdma_cm] [a01fea86] ib_unregister_device+0x46/0x120 [ib_core] [a02c5dc9] mlx4_ib_remove+0x29/0x260 [mlx4_ib] [a04319d0] mlx4_remove_device+0xa0/0xc0 [mlx4_core] [a0431a2b] mlx4_unregister_interface+0x3b/0xa0 [mlx4_core] [a02d74cc] mlx4_ib_cleanup+0x10/0x23 [mlx4_ib] [810bd612] SyS_delete_module+0x152/0x220 [81149684] ? vm_munmap+0x54/0x70 [815ad5a6] system_call_fastpath+0x1a/0x1f With the nfs-rdma-client I got following results: o module unloading blocks forever, dmesg shows: nfsd: last server has exited, flushing export cache svc_xprt_enqueue: threads and transports both waiting?? o BUG: unable to handle kernel paging request at 4dec IP: [815a63b5] _raw_spin_lock_bh+0x15/0x40 PGD 107ba9a067 PUD 105c093067 PMD 0 Oops: 0002 [#1] SMP Modules linked in: nfsd nfs_acl auth_rpcgss oid_registry svcrdma dm_mod cpuid nfs fscache lockd sunrpc af_packet 8021q garp stp llc rdma_ucm ib_ucm rdma_cm iw_cm ib_ipoib ib_cm ib_uverbs ib_umad mlx4_en mlx4_ib(-) ib_sa ib_mad ib_core ib_addr sr_mod cdrom usb_storage joydev mlx4_core usbhid x86_pkg_temp_thermal coretemp kvm_intel kvm ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw gf128mul glue_helper ehci_pci aes_x86_64 ehci_hcd isci iTCO_wdt libsas pcspkr iTCO_vendor_support igb i2c_algo_bit sb_edac lpc_ich edac_core ioatdma usbcore tpm_tis ptp microcode i2c_i801 sg mfd_core scsi_transport_sas ipmi_si usb_common tpm wmi pps_core dca ipmi_msghandler acpi_cpufreq button edd autofs4 xfs libcrc32c crc32c_intel processor thermal_sys scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua scsi_dh CPU: 14 PID: 4813 Comm: modprobe Not tainted 3.15.0-rc5-cel-nfs-rdma-client-unpatched+ #2 Hardware name: Supermicro B9DRG-E/B9DRG-E, BIOS 3.0 09/04/2013 task: 88085bf96190 ti: 88085d42a000 task.ti: 88085d42a000 RIP: 0010:[815a63b5] [815a63b5] _raw_spin_lock_bh+0x15/0x40 RSP: 0018:88085d42bd18 EFLAGS: 00010286 RAX: 0001 RBX: 4de8 RCX: RDX: 000b RSI: 000e RDI: 4dec RBP: 88085d42bd18 R08: 88087c611f38 R09: a140 R10: 002b R11: R12: 88085dcc3c00 R13: 88105ca13280 R14: 4dec R15: 4df0 FS: 7f0e49fb5700() GS:88107fcc() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 4dec CR3: 00105b027000 CR4: 000407e0 Stack: 88085d42bd58 a03bd9f0 01328b88 88085dcc3c00 88085dce8000 88105ca13280 88085dce8260 88085dce81c8 88085d42bd78 a0441ce9 88085dce8000 88105ca13240 Call Trace: [a03bd9f0] svc_xprt_enqueue+0x50/0x220 [sunrpc] [a0441ce9]
RE: [PATCH V2 RFC 0/3] svcrdma: refactor marshalling logic
While testing with ocrdma driver I am finding server side SQ full. Following is the log, yet to identify why it's happening. Once this is reported Client side crashes due to some reason. My kdump is not working properly therefore I am not able to analyze the situation properly. May 19 23:47:02 neo01-el64 kernel: svcrdma: RDMA_WRITE rmr=8008b12, to=45a2d790c, xdr_off=0, write_len=68, vec-sge=88086cb4a0c8, vec-count=2 May 19 23:47:02 neo01-el64 kernel: svcrdma: send_reply returns 0 May 19 23:47:02 neo01-el64 kernel: svc: server 88086409a000 waiting for data (to = 360) May 19 23:47:02 neo01-el64 kernel: svc: transport 88087dfa2400 served by daemon 88086409a000 May 19 23:47:02 neo01-el64 kernel: svc: server 88086409a000, pool 0, transport 88087dfa2400, inuse=18 May 19 23:47:02 neo01-el64 kernel: svcrdma: rqstp=88086409a000 May 19 23:47:02 neo01-el64 kernel: svcrdma: processing ctxt=880866754540 on xprt=88087dfa2400, rqstp=88086409a000, status=0 May 19 23:47:02 neo01-el64 kernel: svcrdma: failed to post SQ WR rc=-22, sc_sq_count=0, sc_sq_depth=128 May 19 23:47:02 neo01-el64 kernel: svcrdma: Error -22 posting RDMA_READ May 19 23:47:02 neo01-el64 kernel: svc: got len=0 May 19 23:47:02 neo01-el64 kernel: svc: transport 88087dfa2400 served by daemon 88086e782000 May 19 23:47:02 neo01-el64 kernel: svc: transport 88087dfa2400 busy, not enqueued May 19 23:47:02 neo01-el64 kernel: svc: server 88086409a000 waiting for data (to = 360) May 19 23:47:02 neo01-el64 kernel: svc_recv: found XPT_CLOSE May 19 23:47:02 neo01-el64 kernel: svc: svc_delete_xprt(88087dfa2400) May 19 23:47:02 neo01-el64 kernel: svc: svc_rdma_detach(88087dfa2400) -Original Message- From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma- ow...@vger.kernel.org] On Behalf Of Steve Wise Sent: Wednesday, May 07, 2014 2:39 AM To: J. Bruce Fields Cc: linux-...@vger.kernel.org; linux-rdma@vger.kernel.org; t...@opengridcomputing.com Subject: Re: [PATCH V2 RFC 0/3] svcrdma: refactor marshalling logic On 5/6/2014 2:27 PM, J. Bruce Fields wrote: On Tue, May 06, 2014 at 12:46:21PM -0500, Steve Wise wrote: This patch series refactors the NFSRDMA server marshalling logic to remove the intermediary map structures. It also fixes an existing bug where the NFSRDMA server was not minding the device fast register page list length limitations. I've also made a git repo available with these patches on top of 3.15-rc4: git://git.openfabrics.org/~swise/linux svcrdma-refactor Changes since V1: - fixed regression for devices that don't support FRMRs (see rdma_read_chunk_lcl()) - split patch up for closer review. However I request it be squashed before merging as they is not bisectable, and I think these changes should all be a single commit anyway. If it's not split up in a way that's bisectable, then yes, just don't bother. I didn't see a good way to split it up, have it bisectable, and not have all the big stuff in one patch. I think its a little more reviewable in these 3 patches, but when I post V3, I'll put it back as an uber patch. Hopefully folks can have a look at these 3 patches ignoring the bisect issue.Having said that, the rdma read logic really is better reviewed by look at the code after applying the patches. That's why I published a git branch. Thanks! Steve. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2 RFC 0/3] svcrdma: refactor marshalling logic
-Original Message- From: linux-nfs-ow...@vger.kernel.org [mailto:linux-nfs-ow...@vger.kernel.org] On Behalf Of Devesh Sharma Sent: Monday, May 19, 2014 2:07 PM To: Steve Wise; J. Bruce Fields Cc: linux-...@vger.kernel.org; linux-rdma@vger.kernel.org; t...@opengridcomputing.com Subject: RE: [PATCH V2 RFC 0/3] svcrdma: refactor marshalling logic While testing with ocrdma driver I am finding server side SQ full. Following is the log, yet to identify why it's happening. Once this is reported Client side crashes due to some reason. My kdump is not working properly therefore I am not able to analyze the situation properly. May 19 23:47:02 neo01-el64 kernel: svcrdma: RDMA_WRITE rmr=8008b12, to=45a2d790c, xdr_off=0, write_len=68, vec-sge=88086cb4a0c8, vec-count=2 May 19 23:47:02 neo01-el64 kernel: svcrdma: send_reply returns 0 May 19 23:47:02 neo01-el64 kernel: svc: server 88086409a000 waiting for data (to = 360) May 19 23:47:02 neo01-el64 kernel: svc: transport 88087dfa2400 served by daemon 88086409a000 May 19 23:47:02 neo01-el64 kernel: svc: server 88086409a000, pool 0, transport 88087dfa2400, inuse=18 May 19 23:47:02 neo01-el64 kernel: svcrdma: rqstp=88086409a000 May 19 23:47:02 neo01-el64 kernel: svcrdma: processing ctxt=880866754540 on xprt=88087dfa2400, rqstp=88086409a000, status=0 May 19 23:47:02 neo01-el64 kernel: svcrdma: failed to post SQ WR rc=-22, sc_sq_count=0, sc_sq_depth=128 May 19 23:47:02 neo01-el64 kernel: svcrdma: Error -22 posting RDMA_READ Hey Deevesh, Looking ocrdma_post_send(),-22 (-EINVAL) is returned when the QP is not in RTS. If the SQ is full, -ENOMEM is returned. So I think the send error is a downstream error because the connection got knocked down. You should try and figure out what kicked the QP out of RTS. Steve. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Soft lockup in unloading kernel modules
Klements, Can you add more details on how to unloading the modules (step by step) in the bug report? Thanks Shirley On 05/19/2014 10:51 AM, Chuck Lever wrote: Hi Klemens- On May 13, 2014, at 12:48 PM, Klemens Senn klemens.s...@ims.co.at wrote: Hi Anna, today I retried unloading the kernel modules with your updated kernel and additionally I tried the nfsd-next kernel from J. Bruce Fields and Chuck's nfs-rdma-client kernel. I filed https://bugzilla.linux-nfs.org/show_bug.cgi?id=252 to track this issue. In short: None of these was able to unload the kernel modules with an active connection. In detail: With your kernel I got following 3 faults: o BUG: soft lockup - CPU#0 stuck for 22s! [modprobe:4615] o BUG: unable to handle kernel NULL pointer dereference at 0003 o BUG: unable to handle kernel paging request at 5b8c With the nfsd-next kernel I got following results: o BUG: soft lockup - CPU#0 stuck for 23s! [modprobe:4452] o module unloading blocks forever, dmesg shows: nfsd: last server has exited, flushing export cache waiting module removal not supported: please upgrade o Kernel keeps running but reports the following: nfsd: last server has exited, flushing export cache waiting module removal not supported: please upgrade svc_xprt_enqueue: threads and transports both waiting?? INFO: task modprobe:4510 blocked for more than 480 seconds. Not tainted 3.15.0-rc1-bfields-master+ #1 echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. modprobeD 88087fc13440 0 4510 4458 0x 88105bb23c58 0086 88105c14e690 00013440 88105bb23fd8 00013440 81a14480 88105c14e690 0037 88085d7f74d8 88085d7f74e0 7fff Call Trace: [815a2424] schedule+0x24/0x70 [815a18cc] schedule_timeout+0x1ec/0x260 [8159a504] ? printk+0x5c/0x5e [815a3406] wait_for_completion+0x96/0x100 [81080c90] ? try_to_wake_up+0x2b0/0x2b0 [a0314039] cma_remove_one+0x1a9/0x220 [rdma_cm] [a01fea86] ib_unregister_device+0x46/0x120 [ib_core] [a02c5dc9] mlx4_ib_remove+0x29/0x260 [mlx4_ib] [a04319d0] mlx4_remove_device+0xa0/0xc0 [mlx4_core] [a0431a2b] mlx4_unregister_interface+0x3b/0xa0 [mlx4_core] [a02d74cc] mlx4_ib_cleanup+0x10/0x23 [mlx4_ib] [810bd612] SyS_delete_module+0x152/0x220 [81149684] ? vm_munmap+0x54/0x70 [815ad5a6] system_call_fastpath+0x1a/0x1f With the nfs-rdma-client I got following results: o module unloading blocks forever, dmesg shows: nfsd: last server has exited, flushing export cache svc_xprt_enqueue: threads and transports both waiting?? o BUG: unable to handle kernel paging request at 4dec IP: [815a63b5] _raw_spin_lock_bh+0x15/0x40 PGD 107ba9a067 PUD 105c093067 PMD 0 Oops: 0002 [#1] SMP Modules linked in: nfsd nfs_acl auth_rpcgss oid_registry svcrdma dm_mod cpuid nfs fscache lockd sunrpc af_packet 8021q garp stp llc rdma_ucm ib_ucm rdma_cm iw_cm ib_ipoib ib_cm ib_uverbs ib_umad mlx4_en mlx4_ib(-) ib_sa ib_mad ib_core ib_addr sr_mod cdrom usb_storage joydev mlx4_core usbhid x86_pkg_temp_thermal coretemp kvm_intel kvm ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw gf128mul glue_helper ehci_pci aes_x86_64 ehci_hcd isci iTCO_wdt libsas pcspkr iTCO_vendor_support igb i2c_algo_bit sb_edac lpc_ich edac_core ioatdma usbcore tpm_tis ptp microcode i2c_i801 sg mfd_core scsi_transport_sas ipmi_si usb_common tpm wmi pps_core dca ipmi_msghandler acpi_cpufreq button edd autofs4 xfs libcrc32c crc32c_intel processor thermal_sys scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua scsi_dh CPU: 14 PID: 4813 Comm: modprobe Not tainted 3.15.0-rc5-cel-nfs-rdma-client-unpatched+ #2 Hardware name: Supermicro B9DRG-E/B9DRG-E, BIOS 3.0 09/04/2013 task: 88085bf96190 ti: 88085d42a000 task.ti: 88085d42a000 RIP: 0010:[815a63b5] [815a63b5] _raw_spin_lock_bh+0x15/0x40 RSP: 0018:88085d42bd18 EFLAGS: 00010286 RAX: 0001 RBX: 4de8 RCX: RDX: 000b RSI: 000e RDI: 4dec RBP: 88085d42bd18 R08: 88087c611f38 R09: a140 R10: 002b R11: R12: 88085dcc3c00 R13: 88105ca13280 R14: 4dec R15: 4df0 FS: 7f0e49fb5700() GS:88107fcc() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 4dec CR3: 00105b027000 CR4: 000407e0 Stack: 88085d42bd58 a03bd9f0 01328b88 88085dcc3c00 88085dce8000 88105ca13280 88085dce8260 88085dce81c8 88085d42bd78 a0441ce9
Re: [PATCH v3 0/9] SRP initiator patches for kernel 3.16
The series looks good to me. Reviewed-by: Sagi Grimberg sa...@mellanox.com thanks, queued all 9 patches up. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] mlx5 signature handover fixes for kernel 3.16
On Sun, May 18, 2014 at 8:32 AM, Sagi Grimberg sa...@mellanox.com wrote: This patchset addresses 3 issues signature handover mlx5 implementation. Thanks, applied all 3. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 for-next 0/3] IB: Use GFP_NOIO calls in IPoIB connected mode TX path
On Sat, May 17, 2014 at 1:52 PM, Or Gerlitz or.gerl...@gmail.com wrote: Roland, we're soon on -rc6 and there's no reason for this to miss 3.16, could you please comment whether you want it to go through your tree or net-next? I will pick it up. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH libibverbs V1] Align Flow Steering API to the extension verbs scheme
On Thu, May 15, 2014 at 6:16 AM, Or Gerlitz ogerl...@mellanox.com wrote: Hi Roland -- this addresses all the comments by Jason who gave a ack/reviewed-by note for both the libibverbs and libmlx4 fixes. So you can move ahead and conduct point releases for both libs. OK... so I should do one more libmlx4 release before you take over? - R. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] RDMA/core: iWARP Port Mapper Overview
On Wed, Mar 26, 2014 at 3:07 PM, Tatyana Nikolova tatyana.e.nikol...@intel.com wrote: 1) The IWPM functionality, common for both iWarp drivers (nes and cxgb4) is refactored from the drivers source files and is moved to new shared files in infiniband/core which are compiled as part of the iw_cm module. So I'm looking to include this for 3.16. One question: I assume unpatched iwarp drivers (eg cxgb3) continue to work as before? In other words they don't get the new port mapper support but at least they don't regress? - R. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2 RFC 0/3] svcrdma: refactor marshalling logic
Hi Steve, -Original Message- From: Steve Wise [mailto:sw...@opengridcomputing.com] Sent: Tuesday, May 20, 2014 12:44 AM To: Devesh Sharma; 'J. Bruce Fields' Cc: linux-...@vger.kernel.org; linux-rdma@vger.kernel.org; t...@opengridcomputing.com Subject: RE: [PATCH V2 RFC 0/3] svcrdma: refactor marshalling logic -Original Message- From: linux-nfs-ow...@vger.kernel.org [mailto:linux-nfs-ow...@vger.kernel.org] On Behalf Of Devesh Sharma Sent: Monday, May 19, 2014 2:07 PM To: Steve Wise; J. Bruce Fields Cc: linux-...@vger.kernel.org; linux-rdma@vger.kernel.org; t...@opengridcomputing.com Subject: RE: [PATCH V2 RFC 0/3] svcrdma: refactor marshalling logic While testing with ocrdma driver I am finding server side SQ full. Following is the log, yet to identify why it's happening. Once this is reported Client side crashes due to some reason. My kdump is not working properly therefore I am not able to analyze the situation properly. May 19 23:47:02 neo01-el64 kernel: svcrdma: RDMA_WRITE rmr=8008b12, to=45a2d790c, xdr_off=0, write_len=68, vec-sge=88086cb4a0c8, vec-count=2 May 19 23:47:02 neo01-el64 kernel: svcrdma: send_reply returns 0 May 19 23:47:02 neo01-el64 kernel: svc: server 88086409a000 waiting for data (to = 360) May 19 23:47:02 neo01-el64 kernel: svc: transport 88087dfa2400 served by daemon 88086409a000 May 19 23:47:02 neo01-el64 kernel: svc: server 88086409a000, pool 0, transport 88087dfa2400, inuse=18 May 19 23:47:02 neo01-el64 kernel: svcrdma: rqstp=88086409a000 May 19 23:47:02 neo01-el64 kernel: svcrdma: processing ctxt=880866754540 on xprt=88087dfa2400, rqstp=88086409a000, status=0 May 19 23:47:02 neo01-el64 kernel: svcrdma: failed to post SQ WR rc=-22, sc_sq_count=0, sc_sq_depth=128 May 19 23:47:02 neo01-el64 kernel: svcrdma: Error -22 posting RDMA_READ Hey Deevesh, Looking ocrdma_post_send(),-22 (-EINVAL) is returned when the QP is not in RTS. If the SQ is full, -ENOMEM is returned. So I think the send error is a downstream error because the connection got knocked down. You should try and figure out what kicked the QP out of RTS. Oh wow! I perfectly missed it, let me go through the logs once again and update you. Steve. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
