---
name: "sk_has_sleeper"
section: "9"
platform: "linux"
package: "linux-manual-2.6.32"
version: "2.6.32-48squeeze6"
release: "Debian 6.0 (Squeeze)"
platforms: ["linux"]
url: "https://new.carta.tech/sk_has_sleeper"
---

# sk\_has\_sleeper(9)

check if there are any waiting processes

## NAME

sk\_has\_sleeper - check if there are any waiting processes

## SYNOPSIS

**int sk\_has\_sleeper(struct sock \*** *sk***);**

## ARGUMENTS

*sk*

socket

## DESCRIPTION

Returns true if socket has waiting processes

The purpose of the sk\_has\_sleeper and sock\_poll\_wait is to wrap the memory barrier call. They were added due to the race found within the tcp code.

## CONSIDER FOLLOWING TCP CODE PATHS

CPU1 CPU2

sys\_select receive packet ... ... \_\_add\_wait\_queue update tp-\>rcv\_nxt ... ... tp-\>rcv\_nxt check sock\_def\_readable ... { schedule ... if (sk-\>sk\_sleep && waitqueue\_active(sk-\>sk\_sleep)) wake\_up\_interruptible(sk-\>sk\_sleep) ... }

The race for tcp fires when the \_\_add\_wait\_queue changes done by CPU1 stay in its cache, and so does the tp-\>rcv\_nxt update on CPU2 side. The CPU1 could then endup calling schedule and sleep forever if there are no more data on the socket.

The sk\_has\_sleeper is always called right after a call to read\_lock, so we can use smp\_mb\_\_after\_lock barrier.

## COPYRIGHT
