Lines Matching defs:have
198 they are sent in order over the wire, they have to finish
345 You must not have the req_lock:
570 * listen(2) or connect(2) calls in order to have it take effect.
916 * 1 yes, we have a valid connection
920 * -2 We do not have a network config...
1221 /* If we have nothing in the receive buffer now, to reduce
1223 * quickly as possible, and let remote TCP know what we have
1392 /* FIXME: dec unacked on connection, once we have
1484 * Drivers have to "announce" q->limits.max_write_zeroes_sectors, or it
1546 * layers are below us, some may have smaller granularity */
1629 * Returns 0 if all bios have been submitted,
1631 * -ENOSPC (any better suggestion?) if we have not been able to bio_add_page a
1855 * both trim and write same have the bi_size ("data len to be affected")
1921 * we sometimes have to double check. */
2310 * For 24-bit wrap-around, we would have to shift:
2365 * packet traveling on msock, they are still processed in the order they have
2375 * Assume we have a 10 GBit connection, that is about 1<<30 byte per second,
2376 * about 1<<21 sectors per second. So "worst" case, we have 1<<3 == 8 seconds
2377 * for the 24bit wrap (historical atomic_t guarantee on some archs), and we have
2519 * once all overlapping requests have completed.
2555 * Requests that have been superseded will
2726 /* In case we have the only disk of the cluster, */
2765 * to have a short time average so we can react faster.
2915 /* If at some point in the future we have a smart way to
3012 * even if we have to sleep below. */
3522 drbd_alert(device, "To resolve this both sides have to support at least protocol %d and feature flags 0x%x\n",
3527 drbd_alert(device, "To resolve this both sides have to support at least protocol %d\n", -hg - 1000);
4204 * it may have been larger than mine all along...
4214 * Unless of course he does not have a disk himself.
4233 * - I don't have a current size myself
4235 * - I do have a current size, am Secondary,
4237 * - I do have a current size, am Primary,
4257 /* we have different sizes, probably peer
4488 * It may have changed syncer-paused flags, however, so we
4514 * and this happens while the peer still thinks we have a sync going on,
4532 * If this node does not have good data, was already connected, but
4558 /* if we have both been inconsistent, and the peer has been
4744 int have;
4753 for (have = bits; have > 0; s += rl, toggle = !toggle) {
4767 if (have < bits) {
4769 have, bits, look_ahead,
4779 have -= bits;
4781 bits = bitstream_get_bits(&bs, &tmp, 64 - have);
4784 look_ahead |= tmp << have;
4785 have += bits;
4810 * but have been dropped as this one turned out to be "best"
4936 /* admin may have requested C_DISCONNECTING,
4937 * other threads may have noticed network errors */
5222 /* We do not have data structures that would allow us to
5224 * * On C_SYNC_TARGET we do not have any data structures describing
5225 * the pending RSDataRequest's we have sent.
5249 might have issued a work again. The one before drbd_finish_peer_reqs() is
5253 /* need to do it again, drbd_finish_peer_reqs() may have populated it
5323 * 1 yes, we have a valid connection
5812 /* In Protocol B we might already have got a P_RECV_ACK