On Tue, Apr 10, 2018 at 5:14 AM, Dongsheng Yang <dongsheng.yang@xxxxxxxxxxxx> wrote: > > > On 04/09/2018 08:35 PM, Ilya Dryomov wrote: >> >> On Mon, Mar 26, 2018 at 4:53 PM, Ilya Dryomov <idryomov@xxxxxxxxx> wrote: >>> >>> On Mon, Mar 26, 2018 at 4:22 PM, Dongsheng Yang >>> <dongsheng.yang@xxxxxxxxxxxx> wrote: >>>> >>>> currently, the rbd_wait_state_locked() will wait forever if we >>>> can't get our state locked. Example: > > ... >>>> >>>> Looks good to me. >>>> >>>> I don't like that rbd_wait_state_locked() has kind of two return values >>>> now: the error code and RBD_DEV_FLAG_BLACKLISTED flag which needs to be >>>> tested afterwards, but I'll fix it myself. >> >> Hi Dongsheng, >> >> I pushed the updated patch to testing, please take a look: >> >> >> https://github.com/ceph/ceph-client/commit/4eb7d6b3554a7c2f39c588a4c636d8eef6784665 >> >> Thanks, > > > Thanx Ilya, that looks good to me. > > BTW, I took a look at the preparation commit: "rbd: refactor > rbd_wait_state_locked() " > bad477c8ce9748dbd762eda93e3c2281c8d2eabf > > That looks good to me too. But could you add a comment for the parameter of > may_queue. > > may_queue means whether we will try to acquire lock. When the lock_state is > not RBD_LOCK_STATE_LOCKED, > if may_queue is true, we will queue a lock work and wait lock_state to be > locked; > if may_queue is false, we will return -EROFS immediately. > > Do I understand it correctly? Yes. I have renamed it to may_acquire for clarity. Thanks, Ilya -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
