Re: [PATCH] libceph: init the cursor when preparing the sparse read

[Xiubo Li <xiubli@redhat.com>]

On 2/29/24 18:48, Ilya Dryomov wrote:
> On Thu, Feb 29, 2024 at 5:22 AM <xiubli@redhat.com> wrote:
>> From: Xiubo Li <xiubli@redhat.com>
>>
>> The osd code has remove cursor initilizing code and this will make
>> the sparse read state into a infinite loop. We should initialize
>> the cursor just before each sparse-read in messnger v2.
>>
>> Cc: stable@vger.kernel.org
>> URL: https://tracker.ceph.com/issues/64607
>> Fixes: 8e46a2d068c9 ("libceph: just wait for more data to be available on the socket")
>> Reported-by: Luis Henriques <lhenriques@suse.de>
>> Signed-off-by: Xiubo Li <xiubli@redhat.com>
>> ---
>>   net/ceph/messenger_v2.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/net/ceph/messenger_v2.c b/net/ceph/messenger_v2.c
>> index a0ca5414b333..7ae0f80100f4 100644
>> --- a/net/ceph/messenger_v2.c
>> +++ b/net/ceph/messenger_v2.c
>> @@ -2025,6 +2025,7 @@ static int prepare_sparse_read_cont(struct ceph_connection *con)
>>   static int prepare_sparse_read_data(struct ceph_connection *con)
>>   {
>>          struct ceph_msg *msg = con->in_msg;
>> +       u64 len = con->in_msg->sparse_read_total ? : data_len(con->in_msg);
>>
>>          dout("%s: starting sparse read\n", __func__);
>>
>> @@ -2034,6 +2035,8 @@ static int prepare_sparse_read_data(struct ceph_connection *con)
>>          if (!con_secure(con))
>>                  con->in_data_crc = -1;
>>
>> +       ceph_msg_data_cursor_init(&con->v2.in_cursor, con->in_msg, len);
>> +
>>          reset_in_kvecs(con);
>>          con->v2.in_state = IN_S_PREPARE_SPARSE_DATA_CONT;
>>          con->v2.data_len_remain = data_len(msg);
>> --
>> 2.43.0
>>
> Hi Xiubo,
>
> How did this get missed?  Was generic/580 not paired with msgr2 in crc
> mode or are we not running generic/580 at all?
>
> Multiple runs have happened since the patch was staged so if the matrix
> is set up correctly ms_mode=crc should have been in effect for xfstests
> at least a couple of times.

I just found that my test script is incorrect and missed this case.

The test locally is covered the msgr1 mostly and I think the qa test 
suite also doesn't cover it too. I will try to improve the qa tests later.

Thanks

- Xiubo


> Thanks,
>
>                  Ilya
>