linux/net/ceph, branch v6.0

libceph: clean up ceph_osdc_start_request prototype

2022-08-03T12:05:39Z

This function always returns 0, and ignores the nofail boolean. Drop the nofail argument, make the function void return and fix up the callers. Signed-off-by: Jeff Layton Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov

libceph: fix ceph_pagelist_reserve() comment typo

2022-08-02T22:54:13Z

The double `without' is duplicated in the comment, remove one. Signed-off-by: Jason Wang Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov

libceph: print fsid and epoch with osd id

2022-08-02T22:54:12Z

Print fsid and epoch in libceph log messages to distinct from which each message come. [ idryomov: don't bother with gid for now, print epoch instead ] Signed-off-by: Satoru Takeuchi Signed-off-by: Daichi Mukai Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov

libceph: check pointer before assigned to "c->rules[]"

2022-08-02T22:54:12Z

It should be better to check pointer firstly, then assign it to c->rules[]. Refine code a little bit. Signed-off-by: Li Qiong Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov

libceph: use swap() macro instead of taking tmp variable

2022-05-25T18:45:13Z

Fix the following coccicheck warning: net/ceph/crush/mapper.c:1077:8-9: WARNING opportunity for swap() by using swap() for the swapping of variable values and drop the tmp variable that is not needed any more. Signed-off-by: Guo Zhengkui Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov

libceph: fix misleading ceph_osdc_cancel_request() comment

2022-05-18T19:21:29Z

cancel_request() never guaranteed that after its return the OSD client would be completely done with the OSD request. The callback (if specified) can still be invoked and a ref can still be held. Signed-off-by: Ilya Dryomov Reviewed-by: Xiubo Li

libceph: fix potential use-after-free on linger ping and resends

2022-05-18T19:21:05Z

request_reinit() is not only ugly as the comment rightfully suggests, but also unsafe. Even though it is called with osdc->lock held for write in all cases, resetting the OSD request refcount can still race with handle_reply() and result in use-after-free. Taking linger ping as an example: handle_timeout thread handle_reply thread down_read(&osdc->lock) req = lookup_request(...) ... finish_request(req) # unregisters up_read(&osdc->lock) __complete_request(req) linger_ping_cb(req) # req->r_kref == 2 because handle_reply still holds its ref down_write(&osdc->lock) send_linger_ping(lreq) req = lreq->ping_req # same req # cancel_linger_request is NOT # called - handle_reply already # unregistered request_reinit(req) WARN_ON(req->r_kref != 1) # fires request_init(req) kref_init(req->r_kref) # req->r_kref == 1 after kref_init ceph_osdc_put_request(req) kref_put(req->r_kref) # req->r_kref == 0 after kref_put, req is freed !!! This happens because send_linger_ping() always (re)uses the same OSD request for watch ping requests, relying on cancel_linger_request() to unregister it from the OSD client and rip its messages out from the messenger. send_linger() does the same for watch/notify registration and watch reconnect requests. Unfortunately cancel_request() doesn't guarantee that after it returns the OSD client would be completely done with the OSD request -- a ref could still be held and the callback (if specified) could still be invoked too. The original motivation for request_reinit() was inability to deal with allocation failures in send_linger() and send_linger_ping(). Switching to using osdc->req_mempool (currently only used by CephFS) respects that and allows us to get rid of request_reinit(). Cc: stable@vger.kernel.org Signed-off-by: Ilya Dryomov Reviewed-by: Xiubo Li Acked-by: Jeff Layton

libceph: disambiguate cluster/pool full log message

2022-04-25T08:45:15Z

Signed-off-by: Ilya Dryomov

libceph: drop else branches in prepare_read_data{,_cont}

2022-03-01T17:26:36Z

Just call set_in_bvec in the non-conditional part. Signed-off-by: Jeff Layton Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov

libceph: optionally use bounce buffer on recv path in crc mode

2022-02-02T17:50:36Z

Both msgr1 and msgr2 in crc mode are zero copy in the sense that message data is read from the socket directly into the destination buffer. We assume that the destination buffer is stable (i.e. remains unchanged while it is being read to) though. Otherwise, CRC errors ensue: libceph: read_partial_message 0000000048edf8ad data crc 1063286393 != exp. 228122706 libceph: osd1 (1)192.168.122.1:6843 bad crc/signature libceph: bad data crc, calculated 57958023, expected 1805382778 libceph: osd2 (2)192.168.122.1:6876 integrity error, bad crc Introduce rxbounce option to enable use of a bounce buffer when receiving message data. In particular this is needed if a mapped image is a Windows VM disk, passed to QEMU. Windows has a system-wide "dummy" page that may be mapped into the destination buffer (potentially more than once into the same buffer) by the Windows Memory Manager in an effort to generate a single large I/O [1][2]. QEMU makes a point of preserving overlap relationships when cloning I/O vectors, so krbd gets exposed to this behaviour. [1] "What Is Really in That MDL?" https://docs.microsoft.com/en-us/previous-versions/windows/hardware/design/dn614012(v=vs.85) [2] https://blogs.msmvps.com/kernelmustard/2005/05/04/dummy-pages/ URL: https://bugzilla.redhat.com/show_bug.cgi?id=1973317 Signed-off-by: Ilya Dryomov Reviewed-by: Jeff Layton