On Tue, 2023-10-31 at 08:17 +0800, Xiubo Li wrote: > On 10/30/23 20:30, Jeff Layton wrote: > > On Mon, 2023-10-30 at 06:21 -0400, Jeff Layton wrote: > > > On Tue, 2023-10-24 at 13:00 +0800, xiubli@xxxxxxxxxx wrote: > > > > From: Xiubo Li <xiubli@xxxxxxxxxx> > > > > > > > > No need to decrease the data length again if we need to read the > > > > left data. > > > > > > > > URL: https://tracker.ceph.com/issues/62081 > > > > Signed-off-by: Xiubo Li <xiubli@xxxxxxxxxx> > > > > --- > > > > net/ceph/messenger_v2.c | 1 - > > > > 1 file changed, 1 deletion(-) > > > > > > > > diff --git a/net/ceph/messenger_v2.c b/net/ceph/messenger_v2.c > > > > index d09a39ff2cf0..9e3f95d5e425 100644 > > > > --- a/net/ceph/messenger_v2.c > > > > +++ b/net/ceph/messenger_v2.c > > > > @@ -1966,7 +1966,6 @@ static int prepare_sparse_read_cont(struct ceph_connection *con) > > > > bv.bv_offset = 0; > > > > } > > > > set_in_bvec(con, &bv); > > > > - con->v2.data_len_remain -= bv.bv_len; > > > > return 0; > > > > } > > > > } else if (iov_iter_is_kvec(&con->v2.in_iter)) { > > > It's been a while since I was in this code, but where does this get > > > decremented if you're removing it here? > > > > > My question was a bit vague, so let me elaborate a bit: > > > > data_len_remain should be how much unconsumed data is in the message > > (IIRC). As we call prepare_sparse_read_cont multiple times, we're > > consuming the message data and this gets decremented as we go. > > > > In the above case, we're consuming the message data into the bvec, so > > why shouldn't we be decrementing the remaining data by that amount? > > Hi Jeff, > > If I didn't miss something about this. IMO we have already decreased it > in the following two cases: > > [1] > https://github.com/ceph/ceph-client/blob/for-linus/net/ceph/messenger_v2.c#L2000 > > [2] > https://github.com/ceph/ceph-client/blob/for-linus/net/ceph/messenger_v2.c#L2025 > > And here won't we decrease them twice ? > > I don't get it. The functions returns in both of those cases just after decrementing data_len_remain, so how can it have already decremented it? Maybe I don't understand the bug you're trying to fix. data_len_remain only comes into play when we need to revert. Does the problem involve a trip through revoke_at_prepare_sparse_data()? -- Jeff Layton <jlayton@xxxxxxxxxx>
