summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* xprtrdma: Add ro_unmap_safe memreg methodChuck Lever2016-05-176-19/+150
| | | | | | | | | | | | | | | | | | | | | | | | | | | | There needs to be a safe method of releasing registered memory resources when an RPC terminates. Safe can mean a number of things: + Doesn't have to sleep + Doesn't rely on having a QP in RTS ro_unmap_safe will be that safe method. It can be used in cases where synchronous memory invalidation can deadlock, or needs to have an active QP. The important case is fencing an RPC's memory regions after it is signaled (^C) and before it exits. If this is not done, there is a window where the server can write an RPC reply into memory that the client has released and re-used for some other purpose. Note that this is a full solution for FRWR, but FMR and physical still have some gaps where a particularly bad server can wreak some havoc on the client. These gaps are not made worse by this patch and are expected to be exceptionally rare and timing-based. They are noted in documenting comments. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Tested-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* xprtrdma: Refactor __fmr_dma_unmap()Chuck Lever2016-05-171-5/+2
| | | | | | | | | | | | Separate the DMA unmap operation from freeing the MW. In a subsequent patch they will not always be done at the same time, and they are not related operations (except by order; freeing the MW must be the last step during invalidation). Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Tested-by: Steve Wise <swise@opengridcomputing.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* xprtrdma: Move fr_xprt and fr_worker to struct rpcrdma_mwChuck Lever2016-05-172-7/+7
| | | | | | | | | | | In a subsequent patch, the fr_xprt and fr_worker fields will be needed by another memory registration mode. Move them into the generic rpcrdma_mw structure that wraps struct rpcrdma_frmr. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Tested-by: Steve Wise <swise@opengridcomputing.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* xprtrdma: Refactor the FRWR recovery workerChuck Lever2016-05-171-9/+16
| | | | | | | | | | Maintain the order of invalidation and DMA unmapping when doing a background MR reset. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Tested-by: Steve Wise <swise@opengridcomputing.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* xprtrdma: Reset MRs in frwr_op_unmap_sync()Chuck Lever2016-05-171-38/+60
| | | | | | | | | | | | | | | frwr_op_unmap_sync() is now invoked in a workqueue context, the same as __frwr_queue_recovery(). There's no need to defer MR reset if posting LOCAL_INV MRs fails. This means that even when ib_post_send() fails (which should occur very rarely) the invalidation and DMA unmapping steps are still done in the correct order. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Tested-by: Steve Wise <swise@opengridcomputing.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* xprtrdma: Save I/O direction in struct rpcrdma_frwrChuck Lever2016-05-172-3/+4
| | | | | | | | | | | | | | Move the the I/O direction field from rpcrdma_mr_seg into the rpcrdma_frmr. This makes it possible to DMA-unmap the frwr long after an RPC has exited and its rpcrdma_mr_seg array has been released and re-used. This might occur if an RPC times out while waiting for a new connection to be established. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Tested-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* xprtrdma: Rename rpcrdma_frwr::sg and sg_nentsChuck Lever2016-05-172-20/+20
| | | | | | | | | | Clean up: Follow same naming convention as other fields in struct rpcrdma_frwr. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Tested-by: Steve Wise <swise@opengridcomputing.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* xprtrdma: Use core ib_drain_qp() APIChuck Lever2016-05-171-35/+6
| | | | | | | | | | | Clean up: Replace rpcrdma_flush_cqs() and rpcrdma_clean_cqs() with the new ib_drain_qp() API. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-By: Leon Romanovsky <leonro@mellanox.com> Tested-by: Steve Wise <swise@opengridcomputing.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* xprtrdma: Remove rpcrdma_create_chunks()Chuck Lever2016-05-171-151/+0
| | | | | | | | | rpcrdma_create_chunks() has been replaced, and can be removed. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Tested-by: Steve Wise <swise@opengridcomputing.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* xprtrdma: Allow Read list and Reply chunk simultaneouslyChuck Lever2016-05-172-60/+272
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | rpcrdma_marshal_req() makes a simplifying assumption: that NFS operations with large Call messages have small Reply messages, and vice versa. Therefore with RPC-over-RDMA, only one chunk type is ever needed for each Call/Reply pair, because one direction needs chunks, the other direction will always fit inline. In fact, this assumption is asserted in the code: if (rtype != rpcrdma_noch && wtype != rpcrdma_noch) { dprintk("RPC: %s: cannot marshal multiple chunk lists\n", __func__); return -EIO; } But RPCGSS_SEC breaks this assumption. Because krb5i and krb5p perform data transformation on RPC messages before they are transmitted, direct data placement techniques cannot be used, thus RPC messages must be sent via a Long call in both directions. All such calls are sent with a Position Zero Read chunk, and all such replies are handled with a Reply chunk. Thus the client must provide every Call/Reply pair with both a Read list and a Reply chunk. Without any special security in effect, NFSv4 WRITEs may now also use the Read list and provide a Reply chunk. The marshal_req logic was preventing that, meaning an NFSv4 WRITE with a large payload that included a GETATTR result larger than the inline threshold would fail. The code that encodes each chunk list is now completely contained in its own function. There is some code duplication, but the trade-off is that the overall logic should be more clear. Note that all three chunk lists now share the rl_segments array. Some additional per-req accounting is necessary to track this usage. For the same reasons that the above simplifying assumption has held true for so long, I don't expect more array elements are needed at this time. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Tested-by: Steve Wise <swise@opengridcomputing.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* xprtrdma: Update comments in rpcrdma_marshal_req()Chuck Lever2016-05-171-14/+4
| | | | | | | | | | Update documenting comments to reflect code changes over the past year. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Tested-by: Steve Wise <swise@opengridcomputing.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* xprtrdma: Avoid using Write list for small NFS READ requestsChuck Lever2016-05-171-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Avoid the latency and interrupt overhead of registering a Write chunk when handling NFS READ requests of a few hundred bytes or less. This change does not interoperate with Linux NFS/RDMA servers that do not have commit 9d11b51ce7c1 ('svcrdma: Fix send_reply() scatter/gather set-up'). Commit 9d11b51ce7c1 was introduced in v4.3, and is included in 4.2.y, 4.1.y, and 3.18.y. Oracle bug 22925946 has been filed to request that the above fix be included in the Oracle Linux UEK4 NFS/RDMA server. Red Hat bugzillas 1327280 and 1327554 have been filed to request that RHEL NFS/RDMA server backports include the above fix. Workaround: Replace the "proto=rdma,port=20049" mount options with "proto=tcp" until commit 9d11b51ce7c1 is applied to your NFS server. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Tested-by: Steve Wise <swise@opengridcomputing.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* xprtrdma: Prevent inline overflowChuck Lever2016-05-175-11/+90
| | | | | | | | | | | | | | | | | | | | | | | | | When deciding whether to send a Call inline, rpcrdma_marshal_req doesn't take into account header bytes consumed by chunk lists. This results in Call messages on the wire that are sometimes larger than the inline threshold. Likewise, when a Write list or Reply chunk is in play, the server's reply has to emit an RDMA Send that includes a larger-than-minimal RPC-over-RDMA header. The actual size of a Call message cannot be estimated until after the chunk lists have been registered. Thus the size of each RPC-over-RDMA header can be estimated only after chunks are registered; but the decision to register chunks is based on the size of that header. Chicken, meet egg. The best a client can do is estimate header size based on the largest header that might occur, and then ensure that inline content is always smaller than that. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Tested-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* xprtrdma: Limit number of RDMA segments in RPC-over-RDMA headersChuck Lever2016-05-175-26/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Send buffer space is shared between the RPC-over-RDMA header and an RPC message. A large RPC-over-RDMA header means less space is available for the associated RPC message, which then has to be moved via an RDMA Read or Write. As more segments are added to the chunk lists, the header increases in size. Typical modern hardware needs only a few segments to convey the maximum payload size, but some devices and registration modes may need a lot of segments to convey data payload. Sometimes so many are needed that the remaining space in the Send buffer is not enough for the RPC message. Sending such a message usually fails. To ensure a transport can always make forward progress, cap the number of RDMA segments that are allowed in chunk lists. This prevents less-capable devices and memory registrations from consuming a large portion of the Send buffer by reducing the maximum data payload that can be conveyed with such devices. For now I choose an arbitrary maximum of 8 RDMA segments. This allows a maximum size RPC-over-RDMA header to fit nicely in the current 1024 byte inline threshold with over 700 bytes remaining for an inline RPC message. The current maximum data payload of NFS READ or WRITE requests is one megabyte. To convey that payload on a client with 4KB pages, each chunk segment would need to handle 32 or more data pages. This is well within the capabilities of FMR. For physical registration, the maximum payload size on platforms with 4KB pages is reduced to 32KB. For FRWR, a device's maximum page list depth would need to be at least 34 to support the maximum 1MB payload. A device with a smaller maximum page list depth means the maximum data payload is reduced when using that device. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Tested-by: Steve Wise <swise@opengridcomputing.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* xprtrdma: Bound the inline threshold valuesChuck Lever2016-05-172-1/+9
| | | | | | | | | | | | | | | | | | Currently the sysctls that allow setting the inline threshold allow any value to be set. Small values only make the transport run slower. The default 1KB setting is as low as is reasonable. And the logic that decides how to divide a Send buffer between RPC-over-RDMA header and RPC message assumes (but does not check) that the lower bound is not crazy (say, 57 bytes). Send and receive buffers share a page with some control information. Values larger than about 3KB can't be supported, currently. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Tested-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* sunrpc: Advertise maximum backchannel payload sizeChuck Lever2016-05-178-4/+49
| | | | | | | | | | RPC-over-RDMA transports have a limit on how large a backward direction (backchannel) RPC message can be. Ensure that the NFSv4.x CREATE_SESSION operation advertises this limit to servers. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Tested-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* sunrpc: Update RPCBIND_MAXNETIDLENChuck Lever2016-05-171-2/+2
| | | | | | | | | | Commit 176e21ee2ec8 ("SUNRPC: Support for RPC over AF_LOCAL transports") added a 5-character netid, but did not bump RPCBIND_MAXNETIDLEN from 4 to 5. Fixes: 176e21ee2ec8 ("SUNRPC: Support for RPC over AF_LOCAL ...") Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* xprtrdma: Add rdma6 option to support NFS/RDMA IPv6Shirley Ma2016-05-171-0/+4
| | | | | | | | | | | | | | | | | | | RFC 5666: The "rdma" netid is to be used when IPv4 addressing is employed by the underlying transport, and "rdma6" for IPv6 addressing. Add mount -o proto=rdma6 option to support NFS/RDMA IPv6 addressing. Changes from v2: - Integrated comments from Chuck Level, Anna Schumaker, Trodt Myklebust - Add a little more to the patch description to describe NFS/RDMA IPv6 suggested by Chuck Level and Anna Schumaker - Removed duplicated rdma6 define - Remove Opt_xprt_rdma mountfamily since it doesn't support Signed-off-by: Shirley Ma <shirley.ma@oracle.com> Reviewed-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* nfs4: client: do not send empty SETATTR after OPEN_CREATETigran Mkrtchyan2016-05-171-9/+25
| | | | | | | | | | | | | | OPEN_CREATE with EXCLUSIVE4_1 sends initial file permission. Ignoring fact, that server have indicated that file mod is set, client will send yet another SETATTR request, but, as mode is already set, new SETATTR will be empty. This is not a problem, nevertheless an extra roundtrip and slow open on high latency networks. This change is aims to skip extra setattr after open if there are no attributes to be set. Signed-off-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* NFS: Add COPY nfs operationAnna Schumaker2016-05-179-0/+305
| | | | | | | | This adds the copy_range file_ops function pointer used by the sys_copy_range() function call. This patch only implements sync copies, so if an async copy happens we decode the stateid and ignore it. Signed-off-by: Anna Schumaker <bjschuma@netapp.com>
* NFS: Add nfs_commit_file()Anna Schumaker2016-05-173-6/+42
| | | | | | | | | Copy will use this to set up a commit request for a generic range. I don't want to allocate a new pagecache entry for the file, so I needed to change parts of the commit path to handle requests with a null wb_page. Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* Fixing oops in callback pathOlga Kornievskaia2016-05-171-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 80f9642724af5 ("NFSv4.x: Enforce the ca_maxreponsesize_cached on the back channel") causes an oops when it receives a callback with cachethis=yes. [ 109.667378] BUG: unable to handle kernel NULL pointer dereference at 00000000000002c8 [ 109.669476] IP: [<ffffffffa08a3e68>] nfs4_callback_compound+0x4f8/0x690 [nfsv4] [ 109.671216] PGD 0 [ 109.671736] Oops: 0000 [#1] SMP [ 109.705427] CPU: 1 PID: 3579 Comm: nfsv4.1-svc Not tainted 4.5.0-rc1+ #1 [ 109.706987] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014 [ 109.709468] task: ffff8800b4408000 ti: ffff88008448c000 task.ti: ffff88008448c000 [ 109.711207] RIP: 0010:[<ffffffffa08a3e68>] [<ffffffffa08a3e68>] nfs4_callback_compound+0x4f8/0x690 [nfsv4] [ 109.713521] RSP: 0018:ffff88008448fca0 EFLAGS: 00010286 [ 109.714762] RAX: ffff880081ee202c RBX: ffff8800b7b5b600 RCX: 0000000000000001 [ 109.716427] RDX: 0000000000000008 RSI: 0000000000000008 RDI: 0000000000000000 [ 109.718091] RBP: ffff88008448fda8 R08: 0000000000000000 R09: 000000000b000000 [ 109.719757] R10: ffff880137786000 R11: ffff8800b7b5b600 R12: 0000000001000000 [ 109.721415] R13: 0000000000000002 R14: 0000000053270000 R15: 000000000000000b [ 109.723061] FS: 0000000000000000(0000) GS:ffff880139640000(0000) knlGS:0000000000000000 [ 109.724931] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 109.726278] CR2: 00000000000002c8 CR3: 0000000034d50000 CR4: 00000000001406e0 [ 109.727972] Stack: [ 109.728465] ffff880081ee202c ffff880081ee201c 000000008448fcc0 ffff8800baccb800 [ 109.730349] ffff8800baccc800 ffffffffa08d0380 0000000000000000 0000000000000000 [ 109.732211] ffff8800b7b5b600 0000000000000001 ffffffff81d073c0 ffff880081ee3090 [ 109.734056] Call Trace: [ 109.734657] [<ffffffffa03795d4>] svc_process_common+0x5c4/0x6c0 [sunrpc] [ 109.736267] [<ffffffffa0379a4c>] bc_svc_process+0x1fc/0x360 [sunrpc] [ 109.737775] [<ffffffffa08a2c2c>] nfs41_callback_svc+0x10c/0x1d0 [nfsv4] [ 109.739335] [<ffffffff810cb380>] ? prepare_to_wait_event+0xf0/0xf0 [ 109.740799] [<ffffffffa08a2b20>] ? nfs4_callback_svc+0x50/0x50 [nfsv4] [ 109.742349] [<ffffffff810a6998>] kthread+0xd8/0xf0 [ 109.743495] [<ffffffff810a68c0>] ? kthread_park+0x60/0x60 [ 109.744776] [<ffffffff816abc4f>] ret_from_fork+0x3f/0x70 [ 109.746037] [<ffffffff810a68c0>] ? kthread_park+0x60/0x60 [ 109.747324] Code: cc 45 31 f6 48 8b 85 00 ff ff ff 44 89 30 48 8b 85 f8 fe ff ff 44 89 20 48 8b 9d 38 ff ff ff 48 8b bd 30 ff ff ff 48 85 db 74 4c <4c> 8b af c8 02 00 00 4d 8d a5 08 02 00 00 49 81 c5 98 02 00 00 [ 109.754361] RIP [<ffffffffa08a3e68>] nfs4_callback_compound+0x4f8/0x690 [nfsv4] [ 109.756123] RSP <ffff88008448fca0> [ 109.756951] CR2: 00000000000002c8 [ 109.757738] ---[ end trace 2b8555511ab5dfb4 ]--- [ 109.758819] Kernel panic - not syncing: Fatal exception [ 109.760126] Kernel Offset: disabled [ 118.938934] ---[ end Kernel panic - not syncing: Fatal exception It doesn't unlock the table nor does it set the cps->clp pointer which is later needed by nfs4_cb_free_slot(). Fixes: 80f9642724af5 ("NFSv4.x: Enforce the ca_maxresponsesize_cached ...") CC: stable@vger.kernel.org Signed-off-by: Olga Kornievskaia <kolga@netapp.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* nfs: don't share mounts between network namespacesJ. Bruce Fields2016-05-091-0/+5
| | | | | | | | | | | | | | | | There's no guarantee that an IP address in a different network namespace actually represents the same endpoint. Also, if we allow unprivileged nfs mounts some day then this might allow an unprivileged user in another network namespace to misdirect somebody else's nfs mounts. If sharing between containers is really what's wanted then that could still be arranged explicitly, for example with bind mounts. Reported-by: "Eric W. Biederman" <ebiederm@redhat.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* NFS: Fix an LOCK/OPEN race when unlinking an open fileChuck Lever2016-05-091-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At Connectathon 2016, we found that recent upstream Linux clients would occasionally send a LOCK operation with a zero stateid. This appeared to happen in close proximity to another thread returning a delegation before unlinking the same file while it remained open. Earlier, the client received a write delegation on this file and returned the open stateid. Now, as it is getting ready to unlink the file, it returns the write delegation. But there is still an open file descriptor on that file, so the client must OPEN the file again before it returns the delegation. Since commit 24311f884189 ('NFSv4: Recovery of recalled read delegations is broken'), nfs_open_delegation_recall() clears the NFS_DELEGATED_STATE flag _before_ it sends the OPEN. This allows a racing LOCK on the same inode to be put on the wire before the OPEN operation has returned a valid open stateid. To eliminate this race, serialize delegation return with the acquisition of a file lock on the same file. Adopt the same approach as is used in the unlock path. This patch also eliminates a similar race seen when sending a LOCK operation at the same time as returning a delegation on the same file. Fixes: 24311f884189 ('NFSv4: Recovery of recalled read ... ') Signed-off-by: Chuck Lever <chuck.lever@oracle.com> [Anna: Add sentence about LOCK / delegation race] Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* nfs: have flexfiles mirror keep creds for both ro and rw layoutsJeff Layton2016-05-093-10/+30
| | | | | | | | | | | | | | | | | | | | | | | | | A mirror can be shared between multiple layouts, even with different iomodes. That makes stats gathering simpler, but it causes a problem when we get different creds in READ vs. RW layouts. The current code drops the newer credentials onto the floor when this occurs. That's problematic when you fetch a READ layout first, and then a RW. If the READ layout doesn't have the correct creds to do a write, then writes will fail. We could just overwrite the READ credentials with the RW ones, but that would break the ability for the server to fence the layout for reads if things go awry. We need to be able to revert to the earlier READ creds if the RW layout is returned afterward. The simplest fix is to just keep two sets of creds per mirror. One for READ layouts and one for RW, and then use the appropriate set depending on the iomode of the layout segment. Also fix up some RCU nits that sparse found. Signed-off-by: Jeff Layton <jeff.layton@primarydata.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* nfs: get a reference to the credential in ff_layout_alloc_lsegJeff Layton2016-05-093-54/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We're just as likely to have allocation problems here as we would if we delay looking up the credential like we currently do. Fix the code to get a rpc_cred reference early, as soon as the mirror is set up. This allows us to eliminate the mirror early if there is a problem getting an rpc credential. This also allows us to drop the uid/gid from the layout_mirror struct as well. In the event that we find an existing mirror where this one would go, we swap in the new creds unconditionally, and drop the reference to the old one. Note that the old ff_layout_update_mirror_cred function wouldn't set this pointer unless the DS version was 3, but we don't know what the DS version is at this point. I'm a little unclear on why it did that as you still need creds to talk to v4 servers as well. I have the code set it regardless of the DS version here. Also note the change to using generic creds instead of calling lookup_cred directly. With that change, we also need to populate the group_info pointer in the acred as some functions expect that to never be NULL. Instead of allocating one every time however, we can allocate one when the module is loaded and share it since the group_info is refcounted. Signed-off-by: Jeff Layton <jeff.layton@primarydata.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* nfs: have ff_layout_get_ds_cred take a reference to the credJeff Layton2016-05-092-10/+35
| | | | | | | | | | | | | In later patches, we're going to want to allow the creds to be updated when we get a new layout with updated creds. Have this function take a reference to the cred that is later put once the call has been dispatched. Also, prepare for this change by ensuring we follow RCU rules when getting a reference to the cred as well. Signed-off-by: Jeff Layton <jeff.layton@primarydata.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* nfs: don't call nfs4_ff_layout_prepare_ds from ff_layout_get_ds_credJeff Layton2016-05-091-5/+1
| | | | | | | | All the callers already call that function before calling into here, so it ends up being a no-op anyway. Signed-off-by: Jeff Layton <jeff.layton@primarydata.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* sunrpc: add a get_rpccred_rcu inlineJeff Layton2016-05-091-0/+18
| | | | | | | | | | | Sometimes we might have a RCU managed credential pointer and don't want to use locking to handle it. Add a function that will take a reference to the cred iff the refcount is not already zero. Callers can dereference the pointer under the rcu_read_lock and use that function to take a reference only if the cred is not on its way to destruction. Signed-off-by: Jeff Layton <jeff.layton@primarydata.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* sunrpc: add rpc_lookup_generic_credWeston Andros Adamson2016-05-092-0/+8
| | | | | | | | | | Add function rpc_lookup_generic_cred, which allows lookups of a generic credential that's not current_cred(). [jlayton: add gfp_t parm] Signed-off-by: Jeff Layton <jeff.layton@primarydata.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* sunrpc: plumb gfp_t parm into crcreate operationJeff Layton2016-05-095-13/+13
| | | | | | | | | | We need to be able to call the generic_cred creator from different contexts. Add a gfp_t parm to the crcreate operation and to rpcauth_lookup_credcache. For now, we just push the gfp_t parms up one level to the *_lookup_cred functions. Signed-off-by: Jeff Layton <jeff.layton@primarydata.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* SUNRPC: init xdr_stream for zero iov_len, page_lenBenjamin Coddington2016-05-091-0/+2
| | | | | | | | | An xdr_buf with head[0].iov_len = 0 and page_len = 0 will cause xdr_init_decode() to incorrectly setup the xdr_stream. Specifically, xdr->end is never initialized. Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* NFS: Save struct inode * inside nfs_commit_info to clarify usage of i_lockDave Wysochanski2016-05-096-34/+34
| | | | | | | | | | | | Commit ea2cf22 created nfs_commit_info and saved &inode->i_lock inside this NFS specific structure. This obscures the usage of i_lock. Instead, save struct inode * so later it's clear the spinlock taken is i_lock. Should be no functional change. Signed-off-by: Dave Wysochanski <dwysocha@redhat.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* nfs: add debug to directio "good_bytes" countingWeston Andros Adamson2016-05-091-2/+5
| | | | | | | This will pop a warning if we count too many good bytes. Signed-off-by: Weston Andros Adamson <dros@primarydata.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* pnfs: set NFS_IOHDR_REDO in pnfs_read_resend_pnfsWeston Andros Adamson2016-05-092-7/+9
| | | | | | | | | | | | | | | Like other resend paths, mark the (old) hdr as NFS_IOHDR_REDO. This ensures the hdr completion function will not count the (old) hdr as good bytes. Also, vector the error back through the hdr->task.tk_status like other retry calls. This fixes a bug with the FlexFiles layout where libaio was reporting more bytes read than requested. Signed-off-by: Weston Andros Adamson <dros@primarydata.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
* Linux 4.6-rc7v4.6-rc7Linus Torvalds2016-05-081-1/+1
|
* Merge tag 'char-misc-4.6-rc7' of ↵Linus Torvalds2016-05-073-8/+27
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull misc driver fixes from Gfreg KH: "Here are three small fixes for some driver problems that were reported. Full details in the shortlog below. All of these have been in linux-next with no reported issues" * tag 'char-misc-4.6-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: nvmem: mxs-ocotp: fix buffer overflow in read Drivers: hv: vmbus: Fix signaling logic in hv_need_to_signal_on_read() misc: mic: Fix for double fetch security bug in VOP driver
| * nvmem: mxs-ocotp: fix buffer overflow in readStanislav Meduna2016-05-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes the issue where the mxs_ocotp_read is reading the ocotp in reg_size steps but decrements the remaining size by 1. The number of iterations is thus four times higher, overwriting the area behind the output buffer. Fixes: c01e9a11ab6f ("nvmem: add driver for ocotp in i.MX23 and i.MX28") Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Stanislav Meduna <stano@meduna.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Drivers: hv: vmbus: Fix signaling logic in hv_need_to_signal_on_read()K. Y. Srinivasan2016-04-301-6/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On the consumer side, we have interrupt driven flow management of the producer. It is sufficient to base the signaling decision on the amount of space that is available to write after the read is complete. The current code samples the previous available space and uses this in making the signaling decision. This state can be stale and is unnecessary. Since the state can be stale, we end up not signaling the host (when we should) and this can result in a hang. Fix this problem by removing the unnecessary check. I would like to thank Arseney Romanenko <arseneyr@microsoft.com> for pointing out this issue. Also, issue a full memory barrier before making the signaling descision to correctly deal with potential reordering of the write (read index) followed by the read of pending_sz. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Tested-by: Dexuan Cui <decui@microsoft.com> Cc: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * misc: mic: Fix for double fetch security bug in VOP driverAshutosh Dixit2016-04-271-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The MIC VOP driver does two successive reads from user space to read a variable length data structure. Kernel memory corruption can result if the data structure changes between the two reads. This patch disallows the chance of this happening. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116651 Reported by: Pengfei Wang <wpengfeinudt@gmail.com> Reviewed-by: Sudeep Dutt <sudeep.dutt@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | Merge tag 'staging-4.6-rc7' of ↵Linus Torvalds2016-05-074-7/+34
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull IIO driver fixes from Grek KH: "It's really just IIO drivers here, some small fixes that resolve some 'crash on boot' errors that have shown up in the -rc series, and other bugfixes that are required. All have been in linux-next with no reported problems" * tag 'staging-4.6-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: iio: imu: mpu6050: Fix name/chip_id when using ACPI iio: imu: mpu6050: fix possible NULL dereferences iio:adc:at91-sama5d2: Repair crash on module removal iio: ak8975: fix maybe-uninitialized warning iio: ak8975: Fix NULL pointer exception on early interrupt
| * \ Merge tag 'iio-fixes-for-4.6d' of ↵Greg Kroah-Hartman2016-05-052-4/+29
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus Jonathan writes: Fourth set of IIO fixes for the 4.6 cycle. This last minute set is concerned with a regression in the mpu6050 driver. The regression causes a null pointer dereference on any ACPI device that has one of these present such as the ASUS T100TA Baytrail/T. The issue was known but thought (i.e. missunderstood by me) to only be a possible with no reports, so was routed via the normal merge window. Turns out this was wrong (thanks to Alan for reporting the crash). The pull is just for the null dereference fix and a followup fix that also stops the reported name of the device being NULL. * mpu6050 - Fix a 'possible' NULL dereference introduced as part of splitting the driver to allow both i2c and spi to be supported. The issue affects ACPI systems with this device. - Fix a follow up issue where the name and chip id both get set to null if the device driver instance is instantiated from ACPI tables.
| | * | iio: imu: mpu6050: Fix name/chip_id when using ACPIDaniel Baluta2016-05-041-3/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using ACPI, id is NULL and the current code automatically defaults name to NULL and chip id to 0. We should instead use the data provided in the ACPI device table. Fixes: c816d9e7a57b ("iio: imu: mpu6050: fix possible NULL dereferences") Signed-off-by: Daniel Baluta <daniel.baluta@intel.com> Reviewed-By: Matt Ranostay <matt.ranostay@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
| | * | iio: imu: mpu6050: fix possible NULL dereferencesMatt Ranostay2016-05-042-2/+4
| |/ / | | | | | | | | | | | | | | | | | | Fix possible null dereferencing of i2c and spi driver data. Signed-off-by: Matt Ranostay <matt.ranostay@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
| * | Merge tag 'iio-fixes-for-4.6c' of ↵Greg Kroah-Hartman2016-04-262-3/+5
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus Jonathan writes: 3rd set of IIO fixes for the 4.6 cycle. * ak8975 - fix a null pointer exception if an interrupt occurs during probe. - fix a maybe-unitialized warning. * at91-sama5d2 - fix a crash on removal of the module.
| | * | iio:adc:at91-sama5d2: Repair crash on module removalMarek Vasut2016-04-181-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The driver never calls platform_set_drvdata() , so platform_get_drvdata() in .remove returns NULL and thus $indio_dev variable in .remove is NULL. Then it's only a matter of dereferencing the indio_dev variable to make the kernel blow as seen below. This patch adds the platform_set_drvdata() call to fix the problem. root@armhf:~# rmmod at91-sama5d2_adc Unable to handle kernel NULL pointer dereference at virtual address 000001d4 pgd = dd57c000 [000001d4] *pgd=00000000 Internal error: Oops: 5 [#1] ARM Modules linked in: at91_sama5d2_adc(-) CPU: 0 PID: 1334 Comm: rmmod Not tainted 4.6.0-rc3-next-20160418+ #3 Hardware name: Atmel SAMA5 task: dd4fcc40 ti: de910000 task.ti: de910000 PC is at mutex_lock+0x4/0x24 LR is at iio_device_unregister+0x14/0x6c pc : [<c05f4624>] lr : [<c0471f74>] psr: a00d0013 sp : de911f00 ip : 00000000 fp : be898bd8 r10: 00000000 r9 : de910000 r8 : c0107724 r7 : 00000081 r6 : bf001048 r5 : 000001d4 r4 : 00000000 r3 : bf000000 r2 : 00000000 r1 : 00000004 r0 : 000001d4 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c53c7d Table: 3d57c059 DAC: 00000051 Process rmmod (pid: 1334, stack limit = 0xde910208) Stack: (0xde911f00 to 0xde912000) 1f00: bf000000 00000000 df5c7e10 bf000010 bf000000 df5c7e10 df5c7e10 c0351ca8 1f20: c0351c84 df5c7e10 bf001048 c0350734 bf001048 df5c7e10 df5c7e44 c035087c 1f40: bf001048 7f62dd4c 00000800 c034fb30 bf0010c0 c0158ee8 de910000 31397461 1f60: 6d61735f 32643561 6364615f 00000000 de911f90 de910000 de910000 00000000 1f80: de911fb0 10c53c7d de911f9c c05f33d8 de911fa0 00910000 be898ecb 7f62dd10 1fa0: 00000000 c0107560 be898ecb 7f62dd10 7f62dd4c 00000800 6f844800 6f844800 1fc0: be898ecb 7f62dd10 00000000 00000081 00000000 7f62dd10 be898bd8 be898bd8 1fe0: b6eedab1 be898b6c 7f61056b b6eedab6 000d0030 7f62dd4c 00000000 00000000 [<c05f4624>] (mutex_lock) from [<c0471f74>] (iio_device_unregister+0x14/0x6c) [<c0471f74>] (iio_device_unregister) from [<bf000010>] (at91_adc_remove+0x10/0x3c [at91_sama5d2_adc]) [<bf000010>] (at91_adc_remove [at91_sama5d2_adc]) from [<c0351ca8>] (platform_drv_remove+0x24/0x3c) [<c0351ca8>] (platform_drv_remove) from [<c0350734>] (__device_release_driver+0x84/0x110) [<c0350734>] (__device_release_driver) from [<c035087c>] (driver_detach+0x8c/0x90) [<c035087c>] (driver_detach) from [<c034fb30>] (bus_remove_driver+0x4c/0xa0) [<c034fb30>] (bus_remove_driver) from [<c0158ee8>] (SyS_delete_module+0x110/0x1d0) [<c0158ee8>] (SyS_delete_module) from [<c0107560>] (ret_fast_syscall+0x0/0x3c) Code: e3520001 1affffd5 eafffff4 f5d0f000 (e1902f9f) ---[ end trace 86914d7ad3696fca ]--- Signed-off-by: Marek Vasut <marex@denx.de> Cc: Ludovic Desroches <ludovic.desroches@atmel.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
| | * | iio: ak8975: fix maybe-uninitialized warningRichard Leitner2016-04-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If i2c_device_id *id is NULL and acpi_match_device returns NULL too, then chipset may be unitialized when accessing &ak_def_array[chipset] in ak8975_probe. Therefore initialize chipset to AK_MAX_TYPE, which will return an error when not changed. This patch fixes the following maybe-uninitialized warning: drivers/iio/magnetometer/ak8975.c: In function ‘ak8975_probe’: drivers/iio/magnetometer/ak8975.c:788:14: warning: ‘chipset’ may be used uninitialized in this function [-Wmaybe-uninitialized] data->def = &ak_def_array[chipset]; Signed-off-by: Richard Leitner <dev@g0hl1n.net> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
| | * | iio: ak8975: Fix NULL pointer exception on early interruptKrzysztof Kozlowski2016-04-171-2/+2
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In certain probe conditions the interrupt came right after registering the handler causing a NULL pointer exception because of uninitialized waitqueue: $ udevadm trigger i2c-gpio i2c-gpio-1: using pins 143 (SDA) and 144 (SCL) i2c-gpio i2c-gpio-3: using pins 53 (SDA) and 52 (SCL) Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = e8b38000 [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: snd_soc_i2s(+) i2c_gpio(+) snd_soc_idma snd_soc_s3c_dma snd_soc_core snd_pcm_dmaengine snd_pcm snd_timer snd soundcore ac97_bus spi_s3c64xx pwm_samsung dwc2 exynos_adc phy_exynos_usb2 exynosdrm exynos_rng rng_core rtc_s3c CPU: 0 PID: 717 Comm: data-provider-m Not tainted 4.6.0-rc1-next-20160401-00011-g1b8d87473b9e-dirty #101 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) (...) (__wake_up_common) from [<c0379624>] (__wake_up+0x38/0x4c) (__wake_up) from [<c0a41d30>] (ak8975_irq_handler+0x28/0x30) (ak8975_irq_handler) from [<c0386720>] (handle_irq_event_percpu+0x88/0x140) (handle_irq_event_percpu) from [<c038681c>] (handle_irq_event+0x44/0x68) (handle_irq_event) from [<c0389c40>] (handle_edge_irq+0xf0/0x19c) (handle_edge_irq) from [<c0385e04>] (generic_handle_irq+0x24/0x34) (generic_handle_irq) from [<c05ee360>] (exynos_eint_gpio_irq+0x50/0x68) (exynos_eint_gpio_irq) from [<c0386720>] (handle_irq_event_percpu+0x88/0x140) (handle_irq_event_percpu) from [<c038681c>] (handle_irq_event+0x44/0x68) (handle_irq_event) from [<c0389a70>] (handle_fasteoi_irq+0xb4/0x194) (handle_fasteoi_irq) from [<c0385e04>] (generic_handle_irq+0x24/0x34) (generic_handle_irq) from [<c03860b4>] (__handle_domain_irq+0x5c/0xb4) (__handle_domain_irq) from [<c0301774>] (gic_handle_irq+0x54/0x94) (gic_handle_irq) from [<c030c910>] (__irq_usr+0x50/0x80) The bug was reproduced on exynos4412-trats2 (with a max77693 device also using i2c-gpio) after building max77693 as a module. Cc: <stable@vger.kernel.org> Fixes: 94a6d5cf7caa ("iio:ak8975 Implement data ready interrupt handling") Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Tested-by: Gregor Boirie <gregor.boirie@parrot.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* | | Merge tag 'usb-4.6-rc7' of ↵Linus Torvalds2016-05-076-19/+11
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB fixes from Greg KH: "Here are some last-remaining fixes for USB drivers to resolve issues that have shown up in testing. And two new device ids as well. All of these have been in linux-next with no reported issues" * tag 'usb-4.6-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: Revert "USB / PM: Allow USB devices to remain runtime-suspended when sleeping" usb: musb: jz4740: fix error check of usb_get_phy() Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb return in bottom half" usb: musb: gadget: nuke endpoint before setting its descriptor to NULL USB: serial: cp210x: add Straizona Focusers device ids USB: serial: cp210x: add ID for Link ECU
| * | | Revert "USB / PM: Allow USB devices to remain runtime-suspended when sleeping"Johan Hovold2016-05-022-13/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit e3345db85068ddb937fc0ba40dfc39c293dad977, which broke system resume for a large class of devices. Devices that after having been reset during resume need to be rebound due to a missing reset_resume callback, are now left in a suspended state. This specifically broke resume of common USB-serial devices, which are now unusable after system suspend (until disconnected and reconnected) when USB persist is enabled. During resume, usb_resume_interface will set the needs_binding flag for such interfaces, but unlike system resume, run-time resume does not honour it. Cc: stable <stable@vger.kernel.org> # 4.5 Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
OpenPOWER on IntegriCloud