user/sven/linux.git/fs/dlm, branch stable/4.3.y

Merge tag 'dlm-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm

2015-09-03T19:57:48Z

Pull dlm updates from David Teigland: "This set mainly includes a change to the way the dlm uses the SCTP API in the kernel, removing the direct dependency on the sctp module. Other odd SCTP-related fixes are also included. The other notable fix is for a long standing regression in the behavior of lock value blocks for user space locks" * tag 'dlm-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm: dlm: print error from kernel_sendpage dlm: fix lvb copy for user locks dlm: sctp_accept_from_sock() can be static dlm: fix reconnecting but not sending data dlm: replace BUG_ON with a less severe handling dlm: use sctp 1-to-1 API dlm: fix not reconnecting on connecting error handling dlm: fix race while closing connections dlm: fix connection stealing if using SCTP

dlm: print error from kernel_sendpage

2015-08-27T14:34:47Z

Print a dlm-specific error when a socket error occurs when sending a dlm message. Signed-off-by: Bob Peterson Signed-off-by: David Teigland

dlm: fix lvb copy for user locks

2015-08-25T19:41:50Z

For a userland lock request, the previous and current lock modes are used to decide when the lvb should be copied back to the user. The wrong previous value was used, so that it always matched the current value. This caused the lvb to be copied back to the user in the wrong cases. Signed-off-by: David Teigland

dlm: sctp_accept_from_sock() can be static

2015-08-17T21:23:09Z

Signed-off-by: Fengguang Wu Signed-off-by: David Teigland

dlm: fix reconnecting but not sending data

2015-08-17T21:22:21Z

There are cases on which lowcomms_connect_sock() is called directly, which caused the CF_WRITE_PENDING flag to not bet set upon reconnect, specially on send_to_sock() error handling. On this last, the flag was already cleared and no further attempt on transmitting would be done. As dlm tends to connect when it needs to transmit something, it makes sense to always mark this flag right after the connect. Signed-off-by: Marcelo Ricardo Leitner Signed-off-by: David Teigland

dlm: replace BUG_ON with a less severe handling

2015-08-17T21:22:21Z

BUG_ON() is a severe action for this case, specially now that DLM with SCTP will use 1 socket per association. Instead, we can just close the socket on this error condition and return from the function. Also move the check to an earlier stage as it won't change and thus we can abort as soon as possible. Although this issue was reported when still using SCTP with 1-to-many API, this cleanup wouldn't be that simple back then because we couldn't close the socket and making sure such event would cease would be hard. And actually, previous code was closing the association, yet SCTP layer is still raising the new data event. Probably a bug to be fixed in SCTP. Reported-by: Signed-off-by: Marcelo Ricardo Leitner Signed-off-by: David Teigland

dlm: use sctp 1-to-1 API

2015-08-17T21:22:20Z

DLM is using 1-to-many API but in a 1-to-1 fashion. That is, it's not needed but this causes it to use sctp_do_peeloff() to mimic an kernel_accept() and this causes a symbol dependency on sctp module. By switching it to 1-to-1 API we can avoid this dependency and also reduce quite a lot of SCTP-specific code in lowcomms.c. The caveat is that now DLM won't always use the same src port. It will choose a random one, just like TCP code. This allows the peers to attempt simultaneous connections, which now are handled just like for TCP. Even more sharing between TCP and SCTP code on DLM is possible, but it is intentionally left for a later commit. Note that for using nodes with this commit, you have to have at least the early fixes on this patchset otherwise it will trigger some issues on old nodes. Signed-off-by: Marcelo Ricardo Leitner Signed-off-by: David Teigland

dlm: fix not reconnecting on connecting error handling

2015-08-17T21:22:19Z

If we don't clear that bit, lowcomms_connect_sock() will not schedule another attempt, and no further attempt will be done. Signed-off-by: Marcelo Ricardo Leitner Signed-off-by: David Teigland

dlm: fix race while closing connections

2015-08-17T21:22:19Z

When a connection have issues DLM may need to close it. Therefore we should also cancel pending workqueues for such connection at that time, and not just when dlm is not willing to use this connection anymore. Also, if we don't clear CF_CONNECT_PENDING flag, the error handling routines won't be able to re-connect as lowcomms_connect_sock() will check for it. Signed-off-by: Marcelo Ricardo Leitner Signed-off-by: David Teigland

dlm: fix connection stealing if using SCTP

2015-08-17T21:22:15Z

When using SCTP and accepting a new connection, DLM currently validates if the peer trying to connect to it is one of the cluster nodes, but it doesn't check if it already has a connection to it or not. If it already had a connection, it will be overwritten, and the new one will be used for writes, possibly causing the node to leave the cluster due to communication breakage. Still, one could DoS the node by attempting N connections and keeping them open. As said, but being explicit, both situations are only triggerable from other cluster nodes, but are doable with only user-level perms. Signed-off-by: Marcelo Ricardo Leitner Signed-off-by: David Teigland