summaryrefslogtreecommitdiff
path: root/include/linux/ceph
diff options
context:
space:
mode:
authorAlex Elder <elder@inktank.com>2013-03-05 19:25:10 +0400
committerSage Weil <sage@inktank.com>2013-05-02 08:16:28 +0400
commit4137577ae398837b0d5e47d4d9365320584efdad (patch)
treeab5bb90c96242c8201f56ed6a455cbe2d3cf19c2 /include/linux/ceph
parent0fff87ec798abdb4a99f01cbb0197266bb68c5dc (diff)
downloadlinux-4137577ae398837b0d5e47d4d9365320584efdad.tar.xz
libceph: clean up skipped message logic
In ceph_con_in_msg_alloc() it is possible for a connection's alloc_msg method to indicate an incoming message should be skipped. By default, read_partial_message() initializes the skip variable to 0 before it gets provided to ceph_con_in_msg_alloc(). The osd client, mon client, and mds client each supply an alloc_msg method. The mds client always assigns skip to be 0. The other two leave the skip value of as-is, or assigns it to zero, except: - if no (osd or mon) request having the given tid is found, in which case skip is set to 1 and NULL is returned; or - in the osd client, if the data of the reply message is not adequate to hold the message to be read, it assigns skip value 1 and returns NULL. So the returned message pointer will always be NULL if skip is ever non-zero. Clean up the logic a bit in ceph_con_in_msg_alloc() to make this state of affairs more obvious. Add a comment explaining how a null message pointer can mean either a message that should be skipped or a problem allocating a message. This resolves: http://tracker.ceph.com/issues/4324 Reported-by: Greg Farnum <greg@inktank.com> Signed-off-by: Alex Elder <elder@inktank.com> Reviewed-by: Greg Farnum <greg@inktank.com>
Diffstat (limited to 'include/linux/ceph')
0 files changed, 0 insertions, 0 deletions