user/sven/linux.git/include/linux/ceph, branch v4.1.18

libceph: fix ceph_msg_revoke()

2016-02-15T20:45:18Z

[ Upstream commit 67645d7619738e51c668ca69f097cb90b5470422 ] There are a number of problems with revoking a "was sending" message: (1) We never make any attempt to revoke data - only kvecs contibute to con->out_skip. However, once the header (envelope) is written to the socket, our peer learns data_len and sets itself to expect at least data_len bytes to follow front or front+middle. If ceph_msg_revoke() is called while the messenger is sending message's data portion, anything we send after that call is counted by the OSD towards the now revoked message's data portion. The effects vary, the most common one is the eventual hang - higher layers get stuck waiting for the reply to the message that was sent out after ceph_msg_revoke() returned and treated by the OSD as a bunch of data bytes. This is what Matt ran into. (2) Flat out zeroing con->out_kvec_bytes worth of bytes to handle kvecs is wrong. If ceph_msg_revoke() is called before the tag is sent out or while the messenger is sending the header, we will get a connection reset, either due to a bad tag (0 is not a valid tag) or a bad header CRC, which kind of defeats the purpose of revoke. Currently the kernel client refuses to work with header CRCs disabled, but that will likely change in the future, making this even worse. (3) con->out_skip is not reset on connection reset, leading to one or more spurious connection resets if we happen to get a real one between con->out_skip is set in ceph_msg_revoke() and before it's cleared in write_partial_skip(). Fixing (1) and (3) is trivial. The idea behind fixing (2) is to never zero the tag or the header, i.e. send out tag+header regardless of when ceph_msg_revoke() is called. That way the header is always correct, no unnecessary resets are induced and revoke stands ready for disabled CRCs. Since ceph_msg_revoke() rips out con->out_msg, introduce a new "message out temp" and copy the header into it before sending. Cc: stable@vger.kernel.org # 4.0+ Reported-by: Matt Conner Signed-off-by: Ilya Dryomov Tested-by: Matt Conner Reviewed-by: Sage Weil Signed-off-by: Sasha Levin

libceph: announce support for straw2 buckets

2015-04-22T15:33:48Z

Sync up feature bits and enable CEPH_FEATURE_CRUSH_V4. Signed-off-by: Ilya Dryomov

ceph: rename snapshot support

2015-04-22T15:33:41Z

Signed-off-by: Yan, Zheng

libceph: simplify our debugfs attr macro

2015-04-20T15:55:39Z

No need to do single_open()'s job ourselves. Signed-off-by: Ilya Dryomov

libceph: expose client options through debugfs

2015-04-20T15:55:39Z

Add a client_options attribute for showing libceph options. Signed-off-by: Ilya Dryomov

libceph, ceph: split ceph_show_options()

2015-04-20T15:55:38Z

Split ceph_show_options() into two pieces and move the piece responsible for printing client (libceph) options into net/ceph. This way people adding a libceph option wouldn't have to remember to update code in fs/ceph. Signed-off-by: Ilya Dryomov

libceph: osdmap.h: Add missing format newlines

2015-04-20T15:55:35Z

To avoid possible interleaving, add missing '\n' to formats. Convert pr_warning to pr_warn while there. Signed-off-by: Joe Perches Signed-off-by: Ilya Dryomov

libceph: tcp_nodelay support

2015-02-19T10:31:40Z

TCP_NODELAY socket option set on connection sockets, disables Nagle’s algorithm and improves latency characteristics. tcp_nodelay(default)/notcp_nodelay option flags provided to enable/disable setting the socket option. Signed-off-by: Chaitanya Huilgol [idryomov@redhat.com: NO_TCP_NODELAY -> TCP_NODELAY, minor adjustments] Signed-off-by: Ilya Dryomov

ceph: handle SESSION_FORCE_RO message

2015-02-19T10:31:37Z

mark session as readonly and wake up all cap waiters. Signed-off-by: Yan, Zheng

libceph: nuke pool op infrastructure

2015-02-19T10:31:37Z

On Mon, Dec 22, 2014 at 5:35 PM, Sage Weil wrote: > On Mon, 22 Dec 2014, Ilya Dryomov wrote: >> Actually, pool op stuff has been unused for over two years - looks like >> it was added for rbd create_snap and that got ripped out in 2012. It's >> unlikely we'd ever need to manage pools or snaps from the kernel client >> so I think it makes sense to nuke it. Sage? > > Yep! Signed-off-by: Ilya Dryomov