Re: [PATCH 1/3] libceph: do not decrease the data length more than once

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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? 
-- 
Jeff Layton <jlayton@xxxxxxxxxx>





[Index of Archives]     [CEPH Users]     [Ceph Large]     [Ceph Dev]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux