* [PATCH 1/5] [DCCP]: Extend CCID packet dequeueing interface
From: Gerrit Renker @ 2008-02-14 13:48 UTC (permalink / raw)
To: acme; +Cc: dccp, netdev, Gerrit Renker
In-Reply-To: <1202996906-29652-1-git-send-email-gerrit@erg.abdn.ac.uk>
This extends the packet dequeuing interface of dccp_write_xmit() to allow
1. CCIDs to take care of timing when the next packet may be sent;
2. delayed sending (as before, with an inter-packet gap up to 65.535 seconds).
The main purpose is to take CCID2 out of its polling mode (when it is network-
limited, it tries every millisecond to send, without interruption).
The interface can also be used to support other CCIDs.
The mode of operation for (2) is as follows:
* new packet is enqueued via dccp_sendmsg() => dccp_write_xmit(),
* ccid_hc_tx_send_packet() detects that it may not send (e.g. window full),
* it signals this condition via `CCID_PACKET_WILL_DEQUEUE_LATER',
* dccp_write_xmit() returns without further action;
* after some time the wait-condition for CCID becomes true,
* that CCID schedules the tasklet,
* tasklet function calls ccid_hc_tx_send_packet() via dccp_write_xmit(),
* since the wait-condition is now true, ccid_hc_tx_packet() returns "send now",
* packet is sent, and possibly more (since dccp_write_xmit() loops).
Code reuse: the taskled function calls dccp_write_xmit(), the timer function
reduces to a wrapper around the same code.
If the tasklet finds that the socket is locked, it re-schedules the tasklet
function (not the tasklet) after one jiffy.
Changed DCCP_BUG to DCCP_WARN when transmit_skb returns an error (e.g. when a
local qdisc is used, NET_XMIT_DROP=1 can be returned for many packets).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
include/linux/dccp.h | 4 +-
net/dccp/ccid.h | 37 ++++++++++++++++-
net/dccp/ccids/ccid3.c | 4 +-
net/dccp/output.c | 103 +++++++++++++++++++++++++++++++----------------
net/dccp/timer.c | 25 ++++++-----
5 files changed, 122 insertions(+), 51 deletions(-)
--- a/include/linux/dccp.h
+++ b/include/linux/dccp.h
@@ -476,7 +476,8 @@ struct dccp_ackvec;
* @dccps_hc_tx_insert_options - sender wants to add options when sending
* @dccps_server_timewait - server holds timewait state on close (RFC 4340, 8.3)
* @dccps_sync_scheduled - flag which signals "send out-of-band message soon"
- * @dccps_xmit_timer - timer for when CCID is not ready to send
+ * @dccps_xmitlet - tasklet scheduled by the TX CCID to dequeue data packets
+ * @dccps_xmit_timer - used by the TX CCID to delay sending (rate-based pacing)
* @dccps_syn_rtt - RTT sample from Request/Response exchange (in usecs)
*/
struct dccp_sock {
@@ -517,6 +518,7 @@ struct dccp_sock {
__u8 dccps_hc_tx_insert_options:1;
__u8 dccps_server_timewait:1;
__u8 dccps_sync_scheduled:1;
+ struct tasklet_struct dccps_xmitlet;
struct timer_list dccps_xmit_timer;
};
--- a/net/dccp/ccid.h
+++ b/net/dccp/ccid.h
@@ -124,13 +124,44 @@ static inline int ccid_get_current_id(struct dccp_sock *dp, bool rx)
extern void ccid_hc_rx_delete(struct ccid *ccid, struct sock *sk);
extern void ccid_hc_tx_delete(struct ccid *ccid, struct sock *sk);
+/*
+ * Congestion control of queued data packets via CCID decision.
+ *
+ * The TX CCID performs its congestion-control by indicating whether and when a
+ * queued packet may be sent, using the return code of ccid_hc_tx_send_packet().
+ * The following modes are supported:
+ * - autonomous dequeueing (CCID internally schedules dccps_xmitlet);
+ * - timer-based pacing (CCID returns a delay value in milliseconds).
+ * Modes and error handling are identified using the symbolic constants below.
+ */
+enum ccid_dequeueing_decision {
+ CCID_PACKET_SEND_AT_ONCE = 0x00000,
+ CCID_PACKET_DELAY = 0x10000,
+ CCID_PACKET_WILL_DEQUEUE_LATER = 0x20000,
+ CCID_PACKET_ERR = 0xF0000,
+};
+
+/* maximum possible number of milliseconds to delay a packet (65.535 seconds) */
+#define CCID_PACKET_DELAY_MAX 0xFFFF
+#define CCID_PACKET_DELAY_MAX_USEC (CCID_PACKET_DELAY_MAX * USEC_PER_MSEC)
+
+static inline int ccid_packet_dequeue_eval(int return_code)
+{
+ if (return_code < 0)
+ return CCID_PACKET_ERR;
+ if (return_code == 0)
+ return CCID_PACKET_SEND_AT_ONCE;
+ if (return_code <= CCID_PACKET_DELAY_MAX)
+ return CCID_PACKET_DELAY;
+ return return_code;
+}
+
static inline int ccid_hc_tx_send_packet(struct ccid *ccid, struct sock *sk,
struct sk_buff *skb)
{
- int rc = 0;
if (ccid->ccid_ops->ccid_hc_tx_send_packet != NULL)
- rc = ccid->ccid_ops->ccid_hc_tx_send_packet(sk, skb);
- return rc;
+ return ccid->ccid_ops->ccid_hc_tx_send_packet(sk, skb);
+ return CCID_PACKET_SEND_AT_ONCE;
}
static inline void ccid_hc_tx_packet_sent(struct ccid *ccid, struct sock *sk,
--- a/net/dccp/ccids/ccid3.c
+++ b/net/dccp/ccids/ccid3.c
@@ -346,6 +346,8 @@ static int ccid3_hc_tx_send_packet(struct sock *sk, struct sk_buff *skb)
case TFRC_SSTATE_FBACK:
delay = ktime_us_delta(hctx->ccid3hctx_t_nom, now);
ccid3_pr_debug("delay=%ld\n", (long)delay);
+ if (delay > CCID_PACKET_DELAY_MAX_USEC)
+ delay = CCID_PACKET_DELAY_MAX_USEC;
/*
* Scheduling of packet transmissions [RFC 3448, 4.6]
*
@@ -371,7 +373,7 @@ static int ccid3_hc_tx_send_packet(struct sock *sk, struct sk_buff *skb)
/* set the nominal send time for the next following packet */
hctx->ccid3hctx_t_nom = ktime_add_us(hctx->ccid3hctx_t_nom,
hctx->ccid3hctx_t_ipi);
- return 0;
+ return CCID_PACKET_SEND_AT_ONCE;
}
static void ccid3_hc_tx_packet_sent(struct sock *sk, int more,
--- a/net/dccp/output.c
+++ b/net/dccp/output.c
@@ -249,52 +249,85 @@ do_interrupted:
goto out;
}
+/**
+ * dccp_xmit_packet - Send data packet under control of CCID
+ * Transmits next-queued payload and informs CCID to account for the packet.
+ */
+static void dccp_xmit_packet(struct sock *sk)
+{
+ int err, len;
+ struct dccp_sock *dp = dccp_sk(sk);
+ struct sk_buff *skb = skb_dequeue(&sk->sk_write_queue);
+
+ if (unlikely(skb == NULL))
+ return;
+ len = skb->len;
+
+ if (sk->sk_state == DCCP_PARTOPEN) {
+ /* See 8.1.5. Handshake Completion */
+ inet_csk_schedule_ack(sk);
+ inet_csk_reset_xmit_timer(sk, ICSK_TIME_DACK,
+ inet_csk(sk)->icsk_rto,
+ DCCP_RTO_MAX);
+ DCCP_SKB_CB(skb)->dccpd_type = DCCP_PKT_DATAACK;
+ } else if (dccp_ack_pending(sk)) {
+ DCCP_SKB_CB(skb)->dccpd_type = DCCP_PKT_DATAACK;
+ } else {
+ DCCP_SKB_CB(skb)->dccpd_type = DCCP_PKT_DATA;
+ }
+
+ err = dccp_transmit_skb(sk, skb);
+ if (err)
+ DCCP_WARN("transmit_skb() returned err=%d\n", err);
+ /*
+ * Register this one as sent even if an error occurred. To the remote
+ * end this error is indistinguishable from loss, so that finally (if
+ * the peer has no bugs) the drop is reported via receiver feedback.
+ */
+ ccid_hc_tx_packet_sent(dp->dccps_hc_tx_ccid, sk, 0, len);
+
+ /*
+ * If the CCID needs to transfer additional header options out-of-band
+ * (e.g. Ack Vectors or feature-negotiation options), it activates the
+ * flag to schedule a Sync. The Sync will automatically incorporate all
+ * currently valid header options so that this backlog is now cleared.
+ */
+ if (dp->dccps_sync_scheduled)
+ dccp_send_sync(sk, dp->dccps_gsr, DCCP_PKT_SYNC);
+}
+
void dccp_write_xmit(struct sock *sk, int block)
{
struct dccp_sock *dp = dccp_sk(sk);
struct sk_buff *skb;
while ((skb = skb_peek(&sk->sk_write_queue))) {
- int err = ccid_hc_tx_send_packet(dp->dccps_hc_tx_ccid, sk, skb);
+ int rc = ccid_hc_tx_send_packet(dp->dccps_hc_tx_ccid, sk, skb);
- if (err > 0) {
+ switch (ccid_packet_dequeue_eval(rc)) {
+ case CCID_PACKET_WILL_DEQUEUE_LATER:
+ return;
+ case CCID_PACKET_DELAY:
if (!block) {
sk_reset_timer(sk, &dp->dccps_xmit_timer,
- msecs_to_jiffies(err)+jiffies);
+ msecs_to_jiffies(rc)+jiffies);
+ return;
+ }
+ rc = dccp_wait_for_ccid(sk, skb, rc);
+ if (rc && rc != -EINTR) {
+ DCCP_BUG("err=%d after dccp_wait_for_ccid", rc);
+ skb_dequeue(&sk->sk_write_queue);
+ kfree_skb(skb);
break;
- } else
- err = dccp_wait_for_ccid(sk, skb, err);
- if (err && err != -EINTR)
- DCCP_BUG("err=%d after dccp_wait_for_ccid", err);
- }
-
- skb_dequeue(&sk->sk_write_queue);
- if (err == 0) {
- struct dccp_skb_cb *dcb = DCCP_SKB_CB(skb);
- const int len = skb->len;
-
- if (sk->sk_state == DCCP_PARTOPEN) {
- /* See 8.1.5. Handshake Completion */
- inet_csk_schedule_ack(sk);
- inet_csk_reset_xmit_timer(sk, ICSK_TIME_DACK,
- inet_csk(sk)->icsk_rto,
- DCCP_RTO_MAX);
- dcb->dccpd_type = DCCP_PKT_DATAACK;
- } else if (dccp_ack_pending(sk))
- dcb->dccpd_type = DCCP_PKT_DATAACK;
- else
- dcb->dccpd_type = DCCP_PKT_DATA;
-
- err = dccp_transmit_skb(sk, skb);
- ccid_hc_tx_packet_sent(dp->dccps_hc_tx_ccid, sk, 0, len);
- if (err)
- DCCP_BUG("err=%d after ccid_hc_tx_packet_sent",
- err);
- if (dp->dccps_sync_scheduled)
- dccp_send_sync(sk, dp->dccps_gsr, DCCP_PKT_SYNC);
- } else {
- dccp_pr_debug("packet discarded due to err=%d\n", err);
+ }
+ /* fall through */
+ case CCID_PACKET_SEND_AT_ONCE:
+ dccp_xmit_packet(sk);
+ break;
+ case CCID_PACKET_ERR:
+ skb_dequeue(&sk->sk_write_queue);
kfree_skb(skb);
+ dccp_pr_debug("packet discarded due to err=%d\n", rc);
}
}
}
--- a/net/dccp/timer.c
+++ b/net/dccp/timer.c
@@ -249,32 +249,35 @@ out:
sock_put(sk);
}
-/* Transmit-delay timer: used by the CCIDs to delay actual send time */
-static void dccp_write_xmit_timer(unsigned long data)
+/**
+ * dccp_write_xmitlet - Workhorse for CCID packet dequeueing interface
+ * See the comments above %ccid_dequeueing_decision for supported modes.
+ */
+static void dccp_write_xmitlet(unsigned long data)
{
struct sock *sk = (struct sock *)data;
- struct dccp_sock *dp = dccp_sk(sk);
bh_lock_sock(sk);
if (sock_owned_by_user(sk))
- sk_reset_timer(sk, &dp->dccps_xmit_timer, jiffies+1);
+ sk_reset_timer(sk, &dccp_sk(sk)->dccps_xmit_timer, jiffies + 1);
else
dccp_write_xmit(sk, 0);
bh_unlock_sock(sk);
- sock_put(sk);
}
-static void dccp_init_write_xmit_timer(struct sock *sk)
+static void dccp_write_xmit_timer(unsigned long data)
{
- struct dccp_sock *dp = dccp_sk(sk);
-
- setup_timer(&dp->dccps_xmit_timer, dccp_write_xmit_timer,
- (unsigned long)sk);
+ dccp_write_xmitlet(data);
+ sock_put((struct sock *)data);
}
void dccp_init_xmit_timers(struct sock *sk)
{
- dccp_init_write_xmit_timer(sk);
+ struct dccp_sock *dp = dccp_sk(sk);
+
+ tasklet_init(&dp->dccps_xmitlet, dccp_write_xmitlet, (unsigned long)sk);
+ setup_timer(&dp->dccps_xmit_timer, dccp_write_xmit_timer,
+ (unsigned long)sk);
inet_csk_init_xmit_timers(sk, &dccp_write_timer, &dccp_delack_timer,
&dccp_keepalive_timer);
}
^ permalink raw reply
* [PATCH 2/5] [CCID]: Refine the wait-for-ccid mechanism
From: Gerrit Renker @ 2008-02-14 13:48 UTC (permalink / raw)
To: acme; +Cc: dccp, netdev, Gerrit Renker
In-Reply-To: <1202996906-29652-2-git-send-email-gerrit@erg.abdn.ac.uk>
This extends the existing wait-for-ccid routine so that it may be used with
different types of CCID. It further addresses the problems listed below.
The code looks if the write queue is non-empty and grants the TX CCID up to
`timeout' jiffies to drain the queue. It will instead purge that queue if
* the delay suggested by the CCID exceeds the time budget;
* a socket error occurred while waiting for the CCID;
* there is a signal pending (eg. annoyed user pressed Control-C);
* the CCID does not support delays (we don't know how long it will take).
D e t a i l s [can be removed]
-------------------------------
DCCP's sending mechanism functions a bit like non-blocking I/O: dccp_sendmsg()
will enqueue up to net.dccp.default.tx_qlen packets (default=5), without waiting
for them to be released to the network.
Rate-based CCIDs, such as CCID3/4, can impose sending delays of up to maximally
64 seconds (t_mbi in RFC 3448). Hence the write queue may still contain packets
when the application closes. Since the write queue is congestion-controlled by
the CCID, draining the queue is also under control of the CCID.
There are several problems that needed to be addressed:
1) The queue-drain mechanism only works with rate-based CCIDs. If CCID2 for
example has a full TX queue and becomes network-limited just as the
application wants to close, then waiting for CCID2 to become unblocked could
lead to an indefinite delay (i.e., application "hangs").
2) Since each TX CCID in turn uses a feedback mechanism, there may be changes
in its sending policy while the queue is being drained. This can lead to
further delays during which the application will not be able to terminate.
3) The minimum wait time for CCID3/4 can be expected to be the queue length
times the current inter-packet delay. For example if tx_qlen=100 and a delay
of 15 ms is used for each packet, then the application would have to wait
for a minimum of 1.5 seconds before being allowed to exit.
4) There is no way for the user/application to control this behaviour. It would
be good to use the timeout argument of dccp_close() as an upper bound. Then
the maximum time that an application is willing to wait for its CCIDs to can
be set via the SO_LINGER option.
These problems are addressed by giving the CCID a grace period of up to the
`timeout' value.
The wait-for-ccid function is, as before, used when the application
(a) has read all the data in its receive buffer and
(b) if SO_LINGER was set with a non-zero linger time, or
(c) the socket is either in the OPEN (active close) or in the PASSIVE_CLOSEREQ
state (client application closes after receiving CloseReq).
In addition, there is a catch-all case by calling __skb_queue_purge() after
waiting for the CCID. This is necessary since the write queue may still have
data when
(a) the host has been passively-closed,
(b) abnormal termination (unread data, zero linger time),
(c) wait-for-ccid could not finish within the given time limit.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/dccp.h | 3 +-
net/dccp/output.c | 122 ++++++++++++++++++++++++++++++-----------------------
net/dccp/proto.c | 15 ++++++-
net/dccp/timer.c | 2 +-
4 files changed, 86 insertions(+), 56 deletions(-)
--- a/net/dccp/dccp.h
+++ b/net/dccp/dccp.h
@@ -215,8 +215,9 @@ extern void dccp_reqsk_send_ack(struct sk_buff *sk, struct request_sock *rsk);
extern void dccp_send_sync(struct sock *sk, const u64 seq,
const enum dccp_pkt_type pkt_type);
-extern void dccp_write_xmit(struct sock *sk, int block);
+extern void dccp_write_xmit(struct sock *sk);
extern void dccp_write_space(struct sock *sk);
+extern void dccp_flush_write_queue(struct sock *sk, long *time_budget);
extern void dccp_init_xmit_timers(struct sock *sk);
static inline void dccp_clear_xmit_timers(struct sock *sk)
--- a/net/dccp/output.c
+++ b/net/dccp/output.c
@@ -204,49 +204,29 @@ void dccp_write_space(struct sock *sk)
}
/**
- * dccp_wait_for_ccid - Wait for ccid to tell us we can send a packet
+ * dccp_wait_for_ccid - Await CCID send permission
* @sk: socket to wait for
- * @skb: current skb to pass on for waiting
- * @delay: sleep timeout in milliseconds (> 0)
- * This function is called by default when the socket is closed, and
- * when a non-zero linger time is set on the socket. For consistency
+ * @delay: timeout in jiffies
+ * This is used by CCIDs which need to delay the send time in process context.
*/
-static int dccp_wait_for_ccid(struct sock *sk, struct sk_buff *skb, int delay)
+static int dccp_wait_for_ccid(struct sock *sk, unsigned long delay)
{
- struct dccp_sock *dp = dccp_sk(sk);
DEFINE_WAIT(wait);
- unsigned long jiffdelay;
- int rc;
-
- do {
- dccp_pr_debug("delayed send by %d msec\n", delay);
- jiffdelay = msecs_to_jiffies(delay);
-
- prepare_to_wait(sk->sk_sleep, &wait, TASK_INTERRUPTIBLE);
+ long remaining;
- sk->sk_write_pending++;
- release_sock(sk);
- schedule_timeout(jiffdelay);
- lock_sock(sk);
- sk->sk_write_pending--;
+ prepare_to_wait(sk->sk_sleep, &wait, TASK_INTERRUPTIBLE);
+ sk->sk_write_pending++;
+ release_sock(sk);
- if (sk->sk_err)
- goto do_error;
- if (signal_pending(current))
- goto do_interrupted;
+ remaining = schedule_timeout(delay);
- rc = ccid_hc_tx_send_packet(dp->dccps_hc_tx_ccid, sk, skb);
- } while ((delay = rc) > 0);
-out:
+ lock_sock(sk);
+ sk->sk_write_pending--;
finish_wait(sk->sk_sleep, &wait);
- return rc;
-
-do_error:
- rc = -EPIPE;
- goto out;
-do_interrupted:
- rc = -EINTR;
- goto out;
+
+ if (signal_pending(current) || sk->sk_err)
+ return -1;
+ return remaining;
}
/**
@@ -296,7 +276,53 @@ static void dccp_xmit_packet(struct sock *sk)
dccp_send_sync(sk, dp->dccps_gsr, DCCP_PKT_SYNC);
}
-void dccp_write_xmit(struct sock *sk, int block)
+/**
+ * dccp_flush_write_queue - Drain queue at end of connection
+ * Since dccp_sendmsg queues packets without waiting for them to be sent, it may
+ * happen that the TX queue is not empty at the end of a connection. We give the
+ * HC-sender CCID a grace period of up to @time_budget jiffies. If this function
+ * returns with a non-empty write queue, it will be purged later.
+ */
+void dccp_flush_write_queue(struct sock *sk, long *time_budget)
+{
+ struct dccp_sock *dp = dccp_sk(sk);
+ struct sk_buff *skb;
+ long delay, rc;
+
+ while (*time_budget > 0 && (skb = skb_peek(&sk->sk_write_queue))) {
+ rc = ccid_hc_tx_send_packet(dp->dccps_hc_tx_ccid, sk, skb);
+
+ switch (ccid_packet_dequeue_eval(rc)) {
+ case CCID_PACKET_WILL_DEQUEUE_LATER:
+ /*
+ * If the CCID determines when to send, the next sending
+ * time is unknown or the CCID may not even send again
+ * (e.g. remote host crashes or lost Ack packets).
+ */
+ DCCP_WARN("CCID did not manage to send all packets");
+ return;
+ case CCID_PACKET_DELAY:
+ delay = msecs_to_jiffies(rc);
+ if (delay > *time_budget)
+ return;
+ rc = dccp_wait_for_ccid(sk, delay);
+ if (rc < 0)
+ return;
+ *time_budget -= (delay - rc);
+ /* check again if we can send now */
+ break;
+ case CCID_PACKET_SEND_AT_ONCE:
+ dccp_xmit_packet(sk);
+ break;
+ case CCID_PACKET_ERR:
+ skb_dequeue(&sk->sk_write_queue);
+ kfree_skb(skb);
+ dccp_pr_debug("packet discarded due to err=%ld\n", rc);
+ }
+ }
+}
+
+void dccp_write_xmit(struct sock *sk)
{
struct dccp_sock *dp = dccp_sk(sk);
struct sk_buff *skb;
@@ -308,19 +334,9 @@ void dccp_write_xmit(struct sock *sk, int block)
case CCID_PACKET_WILL_DEQUEUE_LATER:
return;
case CCID_PACKET_DELAY:
- if (!block) {
- sk_reset_timer(sk, &dp->dccps_xmit_timer,
- msecs_to_jiffies(rc)+jiffies);
- return;
- }
- rc = dccp_wait_for_ccid(sk, skb, rc);
- if (rc && rc != -EINTR) {
- DCCP_BUG("err=%d after dccp_wait_for_ccid", rc);
- skb_dequeue(&sk->sk_write_queue);
- kfree_skb(skb);
- break;
- }
- /* fall through */
+ sk_reset_timer(sk, &dp->dccps_xmit_timer, (jiffies +
+ msecs_to_jiffies(rc)));
+ return;
case CCID_PACKET_SEND_AT_ONCE:
dccp_xmit_packet(sk);
break;
@@ -631,9 +647,8 @@ void dccp_send_close(struct sock *sk, const int active)
DCCP_SKB_CB(skb)->dccpd_type = DCCP_PKT_CLOSE;
if (active) {
- dccp_write_xmit(sk, 1);
dccp_skb_entail(sk, skb);
- dccp_transmit_skb(sk, skb_clone(skb, prio));
+ skb = skb_clone(skb, prio);
/*
* Retransmission timer for active-close: RFC 4340, 8.3 requires
* to retransmit the Close/CloseReq until the CLOSING/CLOSEREQ
@@ -646,6 +661,7 @@ void dccp_send_close(struct sock *sk, const int active)
*/
inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
DCCP_TIMEOUT_INIT, DCCP_RTO_MAX);
- } else
- dccp_transmit_skb(sk, skb);
+ }
+
+ dccp_transmit_skb(sk, skb);
}
--- a/net/dccp/proto.c
+++ b/net/dccp/proto.c
@@ -756,7 +756,7 @@ int dccp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
goto out_discard;
skb_queue_tail(&sk->sk_write_queue, skb);
- dccp_write_xmit(sk,0);
+ dccp_write_xmit(sk);
out_release:
release_sock(sk);
return rc ? : len;
@@ -979,9 +979,22 @@ void dccp_close(struct sock *sk, long timeout)
/* Check zero linger _after_ checking for unread data. */
sk->sk_prot->disconnect(sk, 0);
} else if (sk->sk_state != DCCP_CLOSED) {
+ /*
+ * Normal connection termination. May need to wait if there are
+ * still packets in the TX queue that are delayed by the CCID.
+ */
+ dccp_flush_write_queue(sk, &timeout);
dccp_terminate_connection(sk);
}
+ /*
+ * Flush write queue. This may be necessary in several cases:
+ * - we have been closed by the peer but still have application data;
+ * - abortive termination (unread data or zero linger time),
+ * - normal termination but queue could not be flushed within time limit
+ */
+ __skb_queue_purge(&sk->sk_write_queue);
+
sk_stream_wait_close(sk, timeout);
adjudge_to_death:
--- a/net/dccp/timer.c
+++ b/net/dccp/timer.c
@@ -261,7 +261,7 @@ static void dccp_write_xmitlet(unsigned long data)
if (sock_owned_by_user(sk))
sk_reset_timer(sk, &dccp_sk(sk)->dccps_xmit_timer, jiffies + 1);
else
- dccp_write_xmit(sk, 0);
+ dccp_write_xmit(sk);
bh_unlock_sock(sk);
}
^ permalink raw reply
* [PATCH 5/5] [CCID]: Unused argument
From: Gerrit Renker @ 2008-02-14 13:48 UTC (permalink / raw)
To: acme; +Cc: dccp, netdev, Gerrit Renker
In-Reply-To: <1202996906-29652-5-git-send-email-gerrit@erg.abdn.ac.uk>
This removes the argument `more' from ccid_hc_tx_packet_sent, since it was
nowhere used in the entire code.
(Anecdotally, this argument was not even used in the original KAME code where
the function originally came from; compare the variable moreToSend in the
freebsd61-dccp-kame-28.08.2006.patch now maintained by Emmanuel Lochin.)
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/ccid.h | 6 +++---
net/dccp/ccids/ccid2.c | 2 +-
net/dccp/ccids/ccid3.c | 3 +--
net/dccp/output.c | 2 +-
4 files changed, 6 insertions(+), 7 deletions(-)
--- a/net/dccp/ccid.h
+++ b/net/dccp/ccid.h
@@ -75,7 +75,7 @@ struct ccid_operations {
int (*ccid_hc_tx_send_packet)(struct sock *sk,
struct sk_buff *skb);
void (*ccid_hc_tx_packet_sent)(struct sock *sk,
- int more, unsigned int len);
+ unsigned int len);
void (*ccid_hc_rx_get_info)(struct sock *sk,
struct tcp_info *info);
void (*ccid_hc_tx_get_info)(struct sock *sk,
@@ -165,10 +165,10 @@ static inline int ccid_hc_tx_send_packet(struct ccid *ccid, struct sock *sk,
}
static inline void ccid_hc_tx_packet_sent(struct ccid *ccid, struct sock *sk,
- int more, unsigned int len)
+ unsigned int len)
{
if (ccid->ccid_ops->ccid_hc_tx_packet_sent != NULL)
- ccid->ccid_ops->ccid_hc_tx_packet_sent(sk, more, len);
+ ccid->ccid_ops->ccid_hc_tx_packet_sent(sk, len);
}
static inline void ccid_hc_rx_packet_recv(struct ccid *ccid, struct sock *sk,
--- a/net/dccp/ccids/ccid2.c
+++ b/net/dccp/ccids/ccid2.c
@@ -224,7 +224,7 @@ static void ccid2_start_rto_timer(struct sock *sk)
jiffies + hctx->ccid2hctx_rto);
}
-static void ccid2_hc_tx_packet_sent(struct sock *sk, int more, unsigned int len)
+static void ccid2_hc_tx_packet_sent(struct sock *sk, unsigned int len)
{
struct dccp_sock *dp = dccp_sk(sk);
struct ccid2_hc_tx_sock *hctx = ccid2_hc_tx_sk(sk);
--- a/net/dccp/ccids/ccid3.c
+++ b/net/dccp/ccids/ccid3.c
@@ -376,8 +376,7 @@ static int ccid3_hc_tx_send_packet(struct sock *sk, struct sk_buff *skb)
return CCID_PACKET_SEND_AT_ONCE;
}
-static void ccid3_hc_tx_packet_sent(struct sock *sk, int more,
- unsigned int len)
+static void ccid3_hc_tx_packet_sent(struct sock *sk, unsigned int len)
{
struct ccid3_hc_tx_sock *hctx = ccid3_hc_tx_sk(sk);
--- a/net/dccp/output.c
+++ b/net/dccp/output.c
@@ -264,7 +264,7 @@ static void dccp_xmit_packet(struct sock *sk)
* end this error is indistinguishable from loss, so that finally (if
* the peer has no bugs) the drop is reported via receiver feedback.
*/
- ccid_hc_tx_packet_sent(dp->dccps_hc_tx_ccid, sk, 0, len);
+ ccid_hc_tx_packet_sent(dp->dccps_hc_tx_ccid, sk, len);
/*
* If the CCID needs to transfer additional header options out-of-band
^ permalink raw reply
* [PATCH 4/5] [CCID2]: Stop polling
From: Gerrit Renker @ 2008-02-14 13:48 UTC (permalink / raw)
To: acme; +Cc: dccp, netdev, Gerrit Renker
In-Reply-To: <1202996906-29652-4-git-send-email-gerrit@erg.abdn.ac.uk>
This updates CCID2 to use the CCID dequeuing mechanism, converting from
previous constant-polling to a now event-driven mechanism.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/ccids/ccid2.c | 21 +++++++++++++--------
net/dccp/ccids/ccid2.h | 5 +++++
2 files changed, 18 insertions(+), 8 deletions(-)
--- a/net/dccp/ccids/ccid2.h
+++ b/net/dccp/ccids/ccid2.h
@@ -70,6 +70,11 @@ struct ccid2_hc_tx_sock {
struct list_head ccid2hctx_parsed_ackvecs;
};
+static inline bool ccid2_cwnd_network_limited(struct ccid2_hc_tx_sock *hctx)
+{
+ return (hctx->ccid2hctx_pipe >= hctx->ccid2hctx_cwnd);
+}
+
struct ccid2_hc_rx_sock {
int ccid2hcrx_data;
};
--- a/net/dccp/ccids/ccid2.c
+++ b/net/dccp/ccids/ccid2.c
@@ -124,12 +124,9 @@ static int ccid2_hc_tx_alloc_seq(struct ccid2_hc_tx_sock *hctx)
static int ccid2_hc_tx_send_packet(struct sock *sk, struct sk_buff *skb)
{
- struct ccid2_hc_tx_sock *hctx = ccid2_hc_tx_sk(sk);
-
- if (hctx->ccid2hctx_pipe < hctx->ccid2hctx_cwnd)
- return 0;
-
- return 1; /* XXX CCID should dequeue when ready instead of polling */
+ if (ccid2_cwnd_network_limited(ccid2_hc_tx_sk(sk)))
+ return CCID_PACKET_WILL_DEQUEUE_LATER;
+ return CCID_PACKET_SEND_AT_ONCE;
}
static void ccid2_change_l_ack_ratio(struct sock *sk, u32 val)
@@ -169,6 +166,7 @@ static void ccid2_hc_tx_rto_expire(unsigned long data)
{
struct sock *sk = (struct sock *)data;
struct ccid2_hc_tx_sock *hctx = ccid2_hc_tx_sk(sk);
+ const bool sender_was_blocked = ccid2_cwnd_network_limited(hctx);
long s;
bh_lock_sock(sk);
@@ -189,8 +187,6 @@ static void ccid2_hc_tx_rto_expire(unsigned long data)
if (s > 60)
hctx->ccid2hctx_rto = 60 * HZ;
- ccid2_start_rto_timer(sk);
-
/* adjust pipe, cwnd etc */
hctx->ccid2hctx_ssthresh = hctx->ccid2hctx_cwnd / 2;
if (hctx->ccid2hctx_ssthresh < 2)
@@ -207,6 +203,11 @@ static void ccid2_hc_tx_rto_expire(unsigned long data)
hctx->ccid2hctx_rpdupack = -1;
ccid2_change_l_ack_ratio(sk, 1);
ccid2_hc_tx_check_sanity(hctx);
+
+ /* if we were blocked before, we may now send cwnd=1 packet */
+ if (sender_was_blocked)
+ tasklet_schedule(&dccp_sk(sk)->dccps_xmitlet);
+ ccid2_start_rto_timer(sk);
out:
bh_unlock_sock(sk);
sock_put(sk);
@@ -461,6 +462,7 @@ static void ccid2_hc_tx_packet_recv(struct sock *sk, struct sk_buff *skb)
{
struct dccp_sock *dp = dccp_sk(sk);
struct ccid2_hc_tx_sock *hctx = ccid2_hc_tx_sk(sk);
+ const bool sender_was_blocked = ccid2_cwnd_network_limited(hctx);
struct dccp_ackvec_parsed *avp;
u64 ackno, seqno;
struct ccid2_seq *seqp;
@@ -646,6 +648,9 @@ static void ccid2_hc_tx_packet_recv(struct sock *sk, struct sk_buff *skb)
ccid2_hc_tx_check_sanity(hctx);
done:
+ /* check if incoming Acks allow pending packets to be sent */
+ if (sender_was_blocked && !ccid2_cwnd_network_limited(hctx))
+ tasklet_schedule(&dccp_sk(sk)->dccps_xmitlet);
dccp_ackvec_parsed_cleanup(&hctx->ccid2hctx_parsed_ackvecs);
}
^ permalink raw reply
* [PATCH 3/5] [DCCP]: Empty the write queue when disconnecting
From: Gerrit Renker @ 2008-02-14 13:48 UTC (permalink / raw)
To: acme; +Cc: dccp, netdev, Gerrit Renker
In-Reply-To: <1202996906-29652-3-git-send-email-gerrit@erg.abdn.ac.uk>
dccp_disconnect() can be called due to several reasons:
1. when the connection setup failed (inet_stream_connect());
2. when shutting down (inet_shutdown(), inet_csk_listen_stop());
3. when aborting the connection (dccp_close() with 0 linger time).
In case (1) the write queue is empty. This patch empties the write queue,
if in case (2) or (3) it was not yet empty.
This avoids triggering the write-queue BUG_TRAP in sk_stream_kill_queues()
later on.
It also seems natural to do: when breaking an association, to delete all
packets that were originally intended for the soon-disconnected end (compare
with call to tcp_write_queue_purge in tcp_disconnect()).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/proto.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
--- a/net/dccp/proto.c
+++ b/net/dccp/proto.c
@@ -277,7 +277,9 @@ int dccp_disconnect(struct sock *sk, int flags)
sk->sk_err = ECONNRESET;
dccp_clear_xmit_timers(sk);
+
__skb_queue_purge(&sk->sk_receive_queue);
+ __skb_queue_purge(&sk->sk_write_queue);
if (sk->sk_send_head != NULL) {
__kfree_skb(sk->sk_send_head);
sk->sk_send_head = NULL;
^ permalink raw reply
* [DCCP] [PATCH 0/5]: Extend CCID interface so that CCID-2 stops polling
From: Gerrit Renker @ 2008-02-14 13:48 UTC (permalink / raw)
To: acme; +Cc: dccp, netdev
This set of patches extends the packet sending/dequeuing interface, which is
currently restricted to using time intervals only. This forces CCID-2 into
a constant polling mode, which is removed in patch #4.
Patch #1: Extends the CCID packet dequeuing interface to allow CCIDs to
autonomously schedule sending. Previously it was timer-only,
so that CCID-2 polls uninterruptedly.
Patch #2: Adds a similar extension to the routine which drains the packet queue
at the end of a connection (still under congestion control).
Patch #3: Please clean up your queue when disconnecting.
Patch #4: With the previous changes, CCID-2 is taken out of its polling mode.
Patch #5: Removes the `more' argument from tx_packet_sent.
^ permalink raw reply
* Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver
From: Jarek Poplawski @ 2008-02-14 13:00 UTC (permalink / raw)
To: James Chapman; +Cc: David Miller, netdev
In-Reply-To: <47B17BCD.2070903@katalix.com>
Hi,
It seems, this nice report is still uncomplete: could you check if
there could have been something more yet?
Thanks,
Jarek P.
On Tue, Feb 12, 2008 at 10:58:21AM +0000, James Chapman wrote:
...
> Here is a trace from when we had _bh locks.
>
> Feb 5 16:26:32 ======================================================
> Feb 5 16:26:32 [ INFO: soft-safe -> soft-unsafe lock order detected ]
> Feb 5 16:26:32 2.6.24-core2 #1
> Feb 5 16:26:32 ------------------------------------------------------
> Feb 5 16:26:32 pppd/3224 [HC0[0]:SC0[2]:HE1:SE0] is trying to acquire:
...
> Feb 5 16:26:32 [<f8d7b84d>] e1000_clean+0x5d/0x290 [e1000]
> Feb 5 16:26:32 [<c039d580>] net_rx_action+0x1a0/0x2a0
> Feb 5 16:26:32 [<c039d43f>] net_rx_action+0x5f/0x2a0
> Feb 5 16:26:32 [<c0131e72>] __do_softirq+0x92/0x120
> Feb 5 16:26:32 [<c0131f78>] do_softirq+0x78/0x80
> Feb 5 16:26:32 [<c010b15a>] do_IRQ+0x4a/0xa0
> Feb 5 16:26:32 [<c0127af0>] finish_task_switch+0x0/0xc0
> Feb 5 16:26:32 [<c0108dcc>] common_interrupt+0x24/0x34
> Feb 5 16:26:32 [<c0108dd6>] common_interrupt+0x2e/0x34
> Feb 5 16:26:32 [<c01062d6>] mwait_idle_with_hints+0x46/0x60
> Feb 5 16:26:32 [<c0106550>] mwait_idle+0x0/0x20
> Feb 5 16:26:32 [<c0106694>] cpu_idle+0x74/0xe0
> Feb 5 16:26:32 [<c0536a9a>] start_kernel+0x30a/0x3a0
>
> --
> James Chapman
> Katalix Systems Ltd
> http://www.katalix.com
> Catalysts for your Embedded Linux software development
>
^ permalink raw reply
* [PATCH][KEY] fix bug in spdadd
From: Kazunori MIYAZAWA @ 2008-02-14 11:55 UTC (permalink / raw)
To: David S. Miller, netdev
[-- Attachment #1: Type: text/plain, Size: 146 bytes --]
This patch fix a BUG when adding spds which have
same selector.
Signed-off-by: Kazunori MIYAZAWA <kazunori@miyazawa.org>
--
Kazunori Miyazawa
[-- Attachment #2: af_key.diff --]
[-- Type: text/x-patch, Size: 308 bytes --]
diff --git a/net/key/af_key.c b/net/key/af_key.c
index b3ac85e..1c85392 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -2291,6 +2291,7 @@ static int pfkey_spdadd(struct sock *sk, struct sk_buff *skb, struct sadb_msg *h
return 0;
out:
+ xp->dead = 1;
xfrm_policy_destroy(xp);
return err;
}
^ permalink raw reply related
* Re: [patch 2.6.24-git] net/enc28j60: oops fix, low power mode
From: Claudio Lanconelli @ 2008-02-14 10:28 UTC (permalink / raw)
To: David Brownell; +Cc: netdev
In-Reply-To: <200802111223.49823.david-b@pacbell.net>
David Brownell wrote:
> On Monday 11 February 2008, Claudio Lanconelli wrote:
>
>> I have tried your latest patch. Only after the following change it
>> works fine (no more rx errors during ifconfig up).
>>
>
> Hmm, what chip rev do you have? Different errata and all.
> ISTR mine is rev4; so, not the most current, but not the
> oldest version either.
>
I use the same revision.
>> I added enc28j60_lowpower(false) just before enc28j60_hw_init()
>>
>
> Hmm, I'd have expected it would go best *before* that, but
> what you include below shows it going *after* ...
>
> If there's some problem where reset doesn't work correctly
> in low power mode, who knows what else would need manual
> resetting.
>
>
I don't know why it needs low power resume before reset.
I read in the errata tath clkready bit after reset doesn't work reliably.
May be something related to this, but undocumented.
> Better yet, since I can't reproduce the problem, why don't
> you just update my latest patch with the relevant version
> of this tweak, and then forward it as "From: " me and with
> both our signoffs. That's the usual way to cope with this
> type of tweaking. (Not all updates to your driver should
> need your signoff, but then most patches shouldn't need
> very many iterations either.)
>
Done
^ permalink raw reply
* [PATCH] net/enc28j60: low power mode
From: Claudio Lanconelli @ 2008-02-14 10:20 UTC (permalink / raw)
To: netdev; +Cc: Jeff Garzik, David Brownell
[-- Attachment #1: Type: text/plain, Size: 605 bytes --]
Keep enc28j60 chips in low-power mode when they're not in use.
At typically 120 mA, these chips run hot even when idle; this
low power mode cuts that power usage by a factor of around 100.
This version provides a generic routine to poll a register until
its masked value equals some value ... e.g. bit set or cleared.
It's basically what the previous wait_phy_ready() did, but this
version is generalized to support the handshaking needed to
enter and exit low power mode.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Claudio Lanconelli <lanconelli.claudio@eptar.com>
[-- Attachment #2: enc28j60_lowpower.patch --]
[-- Type: text/x-patch, Size: 4622 bytes --]
--- a/drivers/net/enc28j60.c
+++ b/drivers/net/enc28j60.c
@@ -400,26 +400,31 @@ enc28j60_packet_write(struct enc28j60_ne
mutex_unlock(&priv->lock);
}
-/*
- * Wait until the PHY operation is complete.
- */
-static int wait_phy_ready(struct enc28j60_net *priv)
+static unsigned long msec20_to_jiffies;
+
+static int poll_ready(struct enc28j60_net *priv, u8 reg, u8 mask, u8 val)
{
- unsigned long timeout = jiffies + 20 * HZ / 1000;
- int ret = 1;
+ unsigned long timeout = jiffies + msec20_to_jiffies;
/* 20 msec timeout read */
- while (nolock_regb_read(priv, MISTAT) & MISTAT_BUSY) {
+ while ((nolock_regb_read(priv, reg) & mask) != val) {
if (time_after(jiffies, timeout)) {
if (netif_msg_drv(priv))
- printk(KERN_DEBUG DRV_NAME
- ": PHY ready timeout!\n");
- ret = 0;
- break;
+ dev_dbg(&priv->spi->dev,
+ "reg %02x ready timeout!\n", reg);
+ return -ETIMEDOUT;
}
cpu_relax();
}
- return ret;
+ return 0;
+}
+
+/*
+ * Wait until the PHY operation is complete.
+ */
+static int wait_phy_ready(struct enc28j60_net *priv)
+{
+ return poll_ready(priv, MISTAT, MISTAT_BUSY, 0) ? 0 : 1;
}
/*
@@ -594,6 +599,32 @@ static void nolock_txfifo_init(struct en
nolock_regw_write(priv, ETXNDL, end);
}
+/*
+ * Low power mode shrinks power consumption about 100x, so we'd like
+ * the chip to be in that mode whenever it's inactive. (However, we
+ * can't stay in lowpower mode during suspend with WOL active.)
+ */
+static void enc28j60_lowpower(struct enc28j60_net *priv, bool is_low)
+{
+ if (netif_msg_drv(priv))
+ dev_dbg(&priv->spi->dev, "%s power...\n",
+ is_low ? "low" : "high");
+
+ mutex_lock(&priv->lock);
+ if (is_low) {
+ nolock_reg_bfclr(priv, ECON1, ECON1_RXEN);
+ poll_ready(priv, ESTAT, ESTAT_RXBUSY, 0);
+ poll_ready(priv, ECON1, ECON1_TXRTS, 0);
+ /* ECON2_VRPS was set during initialization */
+ nolock_reg_bfset(priv, ECON2, ECON2_PWRSV);
+ } else {
+ nolock_reg_bfclr(priv, ECON2, ECON2_PWRSV);
+ poll_ready(priv, ESTAT, ESTAT_CLKRDY, ESTAT_CLKRDY);
+ /* caller sets ECON1_RXEN */
+ }
+ mutex_unlock(&priv->lock);
+}
+
static int enc28j60_hw_init(struct enc28j60_net *priv)
{
u8 reg;
@@ -612,8 +643,8 @@ static int enc28j60_hw_init(struct enc28
priv->tx_retry_count = 0;
priv->max_pk_counter = 0;
priv->rxfilter = RXFILTER_NORMAL;
- /* enable address auto increment */
- nolock_regb_write(priv, ECON2, ECON2_AUTOINC);
+ /* enable address auto increment and voltage regulator powersave */
+ nolock_regb_write(priv, ECON2, ECON2_AUTOINC | ECON2_VRPS);
nolock_rxfifo_init(priv, RXSTART_INIT, RXEND_INIT);
nolock_txfifo_init(priv, TXSTART_INIT, TXEND_INIT);
@@ -690,7 +721,7 @@ static int enc28j60_hw_init(struct enc28
static void enc28j60_hw_enable(struct enc28j60_net *priv)
{
- /* enable interrutps */
+ /* enable interrupts */
if (netif_msg_hw(priv))
printk(KERN_DEBUG DRV_NAME ": %s() enabling interrupts.\n",
__FUNCTION__);
@@ -726,15 +757,12 @@ enc28j60_setlink(struct net_device *ndev
int ret = 0;
if (!priv->hw_enable) {
- if (autoneg == AUTONEG_DISABLE && speed == SPEED_10) {
+ /* link is in low power mode now; duplex setting
+ * will take effect on next enc28j60_hw_init().
+ */
+ if (autoneg == AUTONEG_DISABLE && speed == SPEED_10)
priv->full_duplex = (duplex == DUPLEX_FULL);
- if (!enc28j60_hw_init(priv)) {
- if (netif_msg_drv(priv))
- dev_err(&ndev->dev,
- "hw_reset() failed\n");
- ret = -EINVAL;
- }
- } else {
+ else {
if (netif_msg_link(priv))
dev_warn(&ndev->dev,
"unsupported link setting\n");
@@ -1307,8 +1335,9 @@ static int enc28j60_net_open(struct net_
}
return -EADDRNOTAVAIL;
}
- /* Reset the hardware here */
+ /* Take it out of low power mode and reset the hardware here */
enc28j60_hw_disable(priv);
+ enc28j60_lowpower(priv, false);
if (!enc28j60_hw_init(priv)) {
if (netif_msg_ifup(priv))
dev_err(&dev->dev, "hw_reset() failed\n");
@@ -1337,6 +1365,7 @@ static int enc28j60_net_close(struct net
printk(KERN_DEBUG DRV_NAME ": %s() enter\n", __FUNCTION__);
enc28j60_hw_disable(priv);
+ enc28j60_lowpower(priv, true);
netif_stop_queue(dev);
return 0;
@@ -1537,6 +1566,8 @@ static int __devinit enc28j60_probe(stru
dev->watchdog_timeo = TX_TIMEOUT;
SET_ETHTOOL_OPS(dev, &enc28j60_ethtool_ops);
+ enc28j60_lowpower(priv, true);
+
ret = register_netdev(dev);
if (ret) {
if (netif_msg_probe(priv))
@@ -1582,6 +1613,8 @@ static struct spi_driver enc28j60_driver
static int __init enc28j60_init(void)
{
+ msec20_to_jiffies = msecs_to_jiffies(20);
+
return spi_register_driver(&enc28j60_driver);
}
^ permalink raw reply
* [PATCH][IPROUTE2]Add missing prefix bit length for addrlabel
From: Varun Chandramohan @ 2008-02-14 9:51 UTC (permalink / raw)
To: shemminger; +Cc: netdev, yoshfuji
The prefix bit lenght value was not updated, resulting in incorrect addrlabel
entry. This patch fixes that issue.
Signed-off-by: Varun Chandramohan <varunc@linux.vnet.ibm.com>
---
ip/ipaddrlabel.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/ip/ipaddrlabel.c b/ip/ipaddrlabel.c
index 1c873e9..a4cdece 100644
--- a/ip/ipaddrlabel.c
+++ b/ip/ipaddrlabel.c
@@ -173,6 +173,7 @@ static int ipaddrlabel_modify(int cmd, int argc, char **argv)
addattr32(&req.n, sizeof(req), IFAL_LABEL, label);
addattr_l(&req.n, sizeof(req), IFAL_ADDRESS, &prefix.data, prefix.bytelen);
+ req.ifal.ifal_prefixlen = prefix.bitlen;
if (req.ifal.ifal_family == AF_UNSPEC)
req.ifal.ifal_family = AF_INET6;
--
1.5.0.6
^ permalink raw reply related
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Christoph Raisch @ 2008-02-14 8:46 UTC (permalink / raw)
To: ossthema
Cc: apw, Greg KH, Dave Hansen, Jan-Bernd Themann, linux-kernel,
linuxppc-dev, netdev, Badari Pulavarty, Thomas Q Klein, tklein
In-Reply-To: <200802131617.58646.ossthema@de.ibm.com>
Dave Hansen <haveblue@us.ibm.com> wrote on 13.02.2008 18:05:00:
> On Wed, 2008-02-13 at 16:17 +0100, Jan-Bernd Themann wrote:
> > Constraints imposed by HW / FW:
> > - eHEA has own MMU
> > - eHEA Memory Regions (MRs) are used by the eHEA MMU to translate
virtual
> > addresses to absolute addresses (like DMA mapped memory on a PCI bus)
> > - The number of MRs is limited (not enough to have one MR per packet)
>
> Are there enough to have one per 16MB section?
Unfortunately this won't work. This was one of our first ideas we tossed
out,
but the number of MRs will not be sufficient.
>
> > Our current understanding about the current Memory Hotplug System are
> > (please correct me if I'm wrong):
> >
> > - depends on sparse mem
>
> You're wrong ;). In mainline, this is true. There was a version of the
> SUSE kernel that did otherwise. But you can not and should not depend
> on this never changing. But, someone is perfectly free to go out an
> implement something better than sparsemem for memory hotplug. If they
> go and do this, your driver may get left behind.
We understand that the add/remove area is not as
settled in the kernel like for example f_ops ;-)
Are there already base working assumptions which are very unlikely to
change?
>
> > - only whole memory sections are added / removed
> > - for each section a memory resource is registered
>
> True, and true. (There might be exceptions to the whole sections one,
> but that's blatant abuse and should be fixed. :)
>
> > From the driver side we need:
> > - some kind of memory notification mechanism.
> > For memory add we can live without any external memory notification
> > event. For memory remove we do need an external trigger (see
explanation
> > above).
>
> You can export and use (un)register_memory_notifier. You just need to
> do it in a reasonable way that compiles for randconfig on your
> architecture. Believe me, we don't want to start teaching drivers about
> sparsemem.
I'm a little confused here....
...the existing add/remove code depends on sparse mem.
Other pieces on the POWER6 version of the architecture do as well.
So we could either chose to disable add/remove if sparsemem is not there,
or disable the driver by Kconfig in this case.
> > - a way to iterate over all kernel pages and a way to detect holes in
the
> > kernel memory layout in order to build up our own ehea_bmap.
>
> Look at kernel/resource.c
>
> But, I'm really not convinced that you can actually keep this map
> yourselves. It's not as simple as you think. What happens if you get
> on an LPAR with two sections, one 256MB@0x0 and another
> 16MB@0x1000000000000000. That's quite possible. I think your vmalloc'd
> array will eat all of memory.
I'm glad you mention this part. There are many algorithms out there to
handle this problem,
hashes/trees/... all of these trade speed for smaller memory footprint.
We based the table decission on the existing implementations of the
architecture.
Do you see such a case coming along for the next generation POWER systems?
I would guess these drastic changes would also require changes in base
kernel.
Will you provide a generic mapping system with a contiguous virtual address
space
like the ehea_bmap we can query? This would need to be a "stable" part of
the implementation,
including translation functions from kernel to nextgen_ehea_generic_bmap
like virt_to_abs.
>
> That's why we have SPARSEMEM_EXTREME and SPARSEMEM_VMEMMAP implemented
> in the core, so that we can deal with these kinds of problems, once and
> *NOT* in every single little driver out there.
>
> > Functions to use while building ehea_bmap + MRs:
> > - Use either the functions that are used by the memory hotplug system
as
> > well, that means using the section defines + functions
(section_nr_to_pfn,
> > pfn_valid)
>
> Basically, you can't use anything related to sections outside of the
> core code. You can use things like pfn_valid(), or you can create new
> interfaces that are properly abstracted.
We picked sections instead of PFNs because this keeps the ehea_bmap in a
reasonable range
on the existing systems.
But if you provide a abstract method handling exactly the problem we
mention
we'll be happy to use that and dump our private implementation.
>
> > - Use currently other not exported functions in kernel/resource.c, like
> > walk_memory_resource (where we would still need the maximum
> possible number
> > of pages NR_MEM_SECTIONS)
>
> It isn't the act of exporting that's the problem. It's making sure that
> the exports won't be prone to abuse and that people are using them
> properly. You should assume that you can export and use
> walk_memory_resource().
So this seems to come down to a basic question:
New hardware seems to have a tendency to get "private MMUs",
which need private mappings from the kernel address space into a
"HW defined address space with potentially unique characteristics"
RDMA in Openfabrics with global MR is the most prominent example heading
there
>
> Do you know what other operating systems do with this hardware?
We're not aware of another open source Operating system trying to address
this topic.
>
> In the future, please make an effort to get review from knowledgeable
> people about these kinds of things before using them in your driver.
> Your company has many, many resources available, and all you need to do
> is ask. All that you have to do is look to the tops of the files of the
> functions you are calling.
>
So we're glad we finally found the right person who takes responsibility
for this topic!
> -- Dave
>
Gruss / Regards
Christoph Raisch + Jan-Bernd Themann
^ permalink raw reply
* Re: Network namespace and tc?
From: Daniel Lezcano @ 2008-02-14 8:37 UTC (permalink / raw)
To: Denis V. Lunev; +Cc: Stephen Hemminger, netdev, Linux Containers
In-Reply-To: <1202976470.7894.8.camel@iris.sw.ru>
Denis V. Lunev wrote:
> Hello, Stephen!
>
> Namespaces are not fully implemented yet :) Right now we we have only
> basic infrastructure in the mainstream and, currently, we can't even run
> TCP in different namespace :( We hope this will be changed very soon.
>
> These marks (net != &init_net) are used to
> - mark places we need to modify
> - ensure that we do not break initial namespace.
>
> Regards,
> Den
>
> On Wed, 2008-02-13 at 15:59 -0800, Stephen Hemminger wrote:
>> It looks like tc filter won't work on alternate namespaces:
>> /* Add/change/delete/get a filter node */
>>
>> static int tc_ctl_tfilter(struct sk_buff *skb, struct nlmsghdr *n, void *arg)
>> {
>> ...
>>
>> if (net != &init_net)
>> return -EINVAL;
>>
>>
>> Haven't played with namespace virtualization yet, but what else is
>> not supported? Where is this documented?
I wrote some documentation here:
http://lxc.sourceforge.net/network.php
That talk about configuration, bench, etc ...
Your question make me feel I should add a matrix with the current state
of the network namespace, what is in, what is done but not merged yet,
what is planned and what is not planned.
Thanks for paying attention at this.
-- Daniel
Sauf indication contraire ci-dessus:
Compagnie IBM France
Siège Social : Tour Descartes, 2, avenue Gambetta, La Défense 5, 92400
Courbevoie
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 542.737.118 ?
SIREN/SIRET : 552 118 465 02430
^ permalink raw reply
* Re: Network namespace and tc?
From: Denis V. Lunev @ 2008-02-14 8:07 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20080213155903.4ab6e454@extreme>
Hello, Stephen!
Namespaces are not fully implemented yet :) Right now we we have only
basic infrastructure in the mainstream and, currently, we can't even run
TCP in different namespace :( We hope this will be changed very soon.
These marks (net != &init_net) are used to
- mark places we need to modify
- ensure that we do not break initial namespace.
Regards,
Den
On Wed, 2008-02-13 at 15:59 -0800, Stephen Hemminger wrote:
> It looks like tc filter won't work on alternate namespaces:
> /* Add/change/delete/get a filter node */
>
> static int tc_ctl_tfilter(struct sk_buff *skb, struct nlmsghdr *n, void *arg)
> {
> ...
>
> if (net != &init_net)
> return -EINVAL;
>
>
> Haven't played with namespace virtualization yet, but what else is
> not supported? Where is this documented?
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Patch to latest iproute to get it to compile on FC5
From: Ben Greear @ 2008-02-14 6:06 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: NetDev
In-Reply-To: <20080213123402.43cdbd45@extreme>
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
Here's another try at the patch to make the __constant_htonl methods
be included, but without changing any of the .h files. I tested this on
an FC2 system, and it compiles fine.
Interesting to me, it seems you are not supposed to #include
<asm/byteorder.h> directly,
but when I tried the suggested <endian.h>, it didn't actually fix the
problem.
Signed-off-by: Ben Greear <greearb@candelatech.com>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
[-- Attachment #2: iproute.patch --]
[-- Type: text/x-patch, Size: 285 bytes --]
diff --git a/ip/iptunnel.c b/ip/iptunnel.c
index 3b466bf..2b2b78e 100644
--- a/ip/iptunnel.c
+++ b/ip/iptunnel.c
@@ -34,6 +34,7 @@
#include "ip_common.h"
#include "tunnel.h"
+#include <asm/byteorder.h>
static void usage(void) __attribute__((noreturn));
static void usage(void)
^ permalink raw reply related
* Re: [RFC] sky2: don't request unused i/o region
From: Jeff Garzik @ 2008-02-14 4:40 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20080213190237.7cd49d60@extreme>
Stephen Hemminger wrote:
> The sky2 driver only uses the PCI memory region (0) not the
> available I/O region. Some users want to use lots of boards, and the
> I/O space gets exhausted.
>
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
>
> --- a/drivers/net/sky2.c 2008-02-13 18:58:21.000000000 -0800
> +++ b/drivers/net/sky2.c 2008-02-13 18:58:55.000000000 -0800
> @@ -4135,9 +4135,9 @@ static int __devinit sky2_probe(struct p
> goto err_out;
> }
>
> - err = pci_request_regions(pdev, DRV_NAME);
> + err = pci_request_region(pdev, 0, DRV_NAME);
> if (err) {
> - dev_err(&pdev->dev, "cannot obtain PCI resources\n");
> + dev_err(&pdev->dev, "cannot obtain PCI resource\n");
Your description of the problem does not match the fix.
PCI resources are already allocated to the device (or not) by this point
in the code. pci_request_region/regions is purely internal kernel
software resource reservation -- protecting drivers from themselves, and
arguably not really needed anymore on modern buses.
Thus, I cannot see how this patch can possibly "exhaust I/O space" --
the relevant PCI resources are allocated to the device, or not,
regardless of these function calls.
As long as there is no resource conflict, you can have 1 million boards
and still use pci_request_regions().
Jeff
^ permalink raw reply
* Re: [PATCH 2/2] add rcu_assign_index() if ever needed
From: Andrew Morton @ 2008-02-14 3:41 UTC (permalink / raw)
To: ego
Cc: Paul E. McKenney, linux-kernel, shemminger, davem, netdev,
dipankar, herbert
In-Reply-To: <20080214033209.GA7266@in.ibm.com>
On Thu, 14 Feb 2008 09:02:09 +0530 Gautham R Shenoy <ego@in.ibm.com> wrote:
> > /**
> > + * rcu_assign_index - assign (publicize) a index of a newly
> > + * initialized array elementg that will be dereferenced by RCU
> ^^^^^^^^
>
> I hope Andrew got that one while porting against the latest -mm :)
I don't actually read the comments - I just like to make sure they're
there ;)
^ permalink raw reply
* Re: [PATCH 2/2] add rcu_assign_index() if ever needed
From: Gautham R Shenoy @ 2008-02-14 3:32 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-kernel, shemminger, davem, netdev, dipankar, herbert, akpm
In-Reply-To: <20080213220515.GA10642@linux.vnet.ibm.com>
On Wed, Feb 13, 2008 at 02:05:15PM -0800, Paul E. McKenney wrote:
> Hello again!
>
> This is a speculative patch that as far as I can tell is not yet required.
> If anyone applies RCU to a data structure allocated out of an array, using
> array indexes in place of pointers to link the array elements together,
> then the rcu_assign_index() function in this patch will be needed to
> assign a given element's array index to the RCU-traversed index. The
> implementation is exactly that of the old rcu_assign_pointer(), so is
> extremely well tested.
>
> The existing rcu_assign_pointer() will emit a compiler warning in cases
> where rcu_assign_index() is required.
>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> ---
>
> rcupdate.h | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff -urpNa -X dontdiff linux-2.6.24-rap/include/linux/rcupdate.h linux-2.6.24-rai/include/linux/rcupdate.h
> --- linux-2.6.24-rap/include/linux/rcupdate.h 2008-02-13 13:36:47.000000000 -0800
> +++ linux-2.6.24-rai/include/linux/rcupdate.h 2008-02-13 10:55:40.000000000 -0800
> @@ -286,6 +286,24 @@ extern struct lockdep_map rcu_lock_map;
> })
>
> /**
> + * rcu_assign_index - assign (publicize) a index of a newly
> + * initialized array elementg that will be dereferenced by RCU
^^^^^^^^
I hope Andrew got that one while porting against the latest -mm :)
Looks good otherwise.
> + * read-side critical sections. Returns the value assigned.
> + *
> + * Inserts memory barriers on architectures that require them
> + * (pretty much all of them other than x86), and also prevents
> + * the compiler from reordering the code that initializes the
> + * structure after the index assignment. More importantly, this
> + * call documents which indexes will be dereferenced by RCU read-side
> + * code.
> + */
> +
> +#define rcu_assign_index(p, v) ({ \
> + smp_wmb(); \
> + (p) = (v); \
> + })
> +
> +/**
> * synchronize_sched - block until all CPUs have exited any non-preemptive
> * kernel code sequences.
> *
--
Thanks and Regards
gautham
^ permalink raw reply
* [PATCH 2.6.25] igb: fix legacy mode irq issue
From: Andy Gospodarek @ 2008-02-14 3:19 UTC (permalink / raw)
To: netdev; +Cc: Auke Kok, David S. Miller, Jeff Garzik
I booted an igb kernel with the option pci=nomsi and instantly noticed
that interrupts no longer worked on my igb device. I took a look at the
interrupt initialization and quickly discovered a comment stating:
"DO NOT USE EIAME or IAME in legacy mode"
It seemed a bit odd that bits to enable IAM were being set in legacy
interrupt mode, so I dropped out the following parts and interrupts
began working fine again.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
---
igb_main.c | 3 ---
1 files changed, 3 deletions(-)
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index f3c144d..be5da09 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -472,9 +471,6 @@ static int igb_request_irq(struct igb_adapter *adapter)
goto request_done;
}
- /* enable IAM, auto-mask */
- wr32(E1000_IAM, IMS_ENABLE_MASK);
-
request_done:
return err;
}
^ permalink raw reply related
* [RFC] sky2: don't request unused i/o region
From: Stephen Hemminger @ 2008-02-14 3:02 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
The sky2 driver only uses the PCI memory region (0) not the
available I/O region. Some users want to use lots of boards, and the
I/O space gets exhausted.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/drivers/net/sky2.c 2008-02-13 18:58:21.000000000 -0800
+++ b/drivers/net/sky2.c 2008-02-13 18:58:55.000000000 -0800
@@ -4135,9 +4135,9 @@ static int __devinit sky2_probe(struct p
goto err_out;
}
- err = pci_request_regions(pdev, DRV_NAME);
+ err = pci_request_region(pdev, 0, DRV_NAME);
if (err) {
- dev_err(&pdev->dev, "cannot obtain PCI resources\n");
+ dev_err(&pdev->dev, "cannot obtain PCI resource\n");
goto err_out_disable;
}
^ permalink raw reply
* Dealing with limited resources and DMA Engine copies
From: Olof Johansson @ 2008-02-14 2:38 UTC (permalink / raw)
To: shannon.nelson, dan.j.williams; +Cc: netdev
Hi,
My DMA Engine has a limited resource: It's got a descriptor ring, so
it's not always possible to add a new descriptor to it (i.e. it might be
full). While allocating a huge ring will help, eventually I'm sure I
will hit a case where it'll overflow.
I thought this was going to be taken care of automatically by the fact
that you return your max(?) number of descriptors in the channel
allocation function, but it looks like that value is discarded in
dma_client_chan_alloc().
So, I just got a couple of spurious:
dma_cookie < 0
dma_cookie < 0
...on the console and the connection terminated. Looks like that came
from tcp_recvmsg(). Ouch.
How about falling back to the cpu-based copy in case of failure? Or would
you prefer that I sleep locally in my driver and wait on a descriptor
slot to open up?
-Olof
^ permalink raw reply
* Re: [2.6 patch] unexport inet_listen_wlock
From: David Miller @ 2008-02-14 1:40 UTC (permalink / raw)
To: bunk; +Cc: netdev
In-Reply-To: <20080213212948.GL3383@cs181133002.pp.htv.fi>
From: Adrian Bunk <bunk@kernel.org>
Date: Wed, 13 Feb 2008 23:29:48 +0200
> This patch removes the no linger used EXPORT_SYMBOL(inet_listen_wlock).
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
Applied.
^ permalink raw reply
* Re: [2.6 patch] unexport __inet_hash_connect
From: David Miller @ 2008-02-14 1:39 UTC (permalink / raw)
To: bunk; +Cc: xemul, linux-kernel, netdev
In-Reply-To: <20080213212946.GK3383@cs181133002.pp.htv.fi>
From: Adrian Bunk <bunk@kernel.org>
Date: Wed, 13 Feb 2008 23:29:46 +0200
> This patch removes the unused EXPORT_SYMBOL_GPL(__inet_hash_connect).
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] remove rcu_assign_pointer(NULL) penalty with type/macro safety
From: Stephen Hemminger @ 2008-02-14 1:37 UTC (permalink / raw)
To: paulmck
Cc: Stephen Hemminger, linux-kernel, davem, netdev, dipankar, ego,
herbert, akpm
In-Reply-To: <20080214013427.GT12393@linux.vnet.ibm.com>
On Wed, 13 Feb 2008 17:34:27 -0800
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> On Wed, Feb 13, 2008 at 04:53:56PM -0800, Stephen Hemminger wrote:
> > On Wed, 13 Feb 2008 16:42:53 -0800
> > "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> > > On Wed, Feb 13, 2008 at 04:27:00PM -0800, Stephen Hemminger wrote:
>
> [ . . . ]
>
> > > > That is heading towards ugly... Maybe not using the macro at all (for this case) would be best:
> > > >
> > > > static inline void node_set_parent(struct node *node, struct tnode *ptr)
> > > > {
> > > > smp_wmb();
> > > > node->parent = (unsigned long)ptr | NODE_TYPE(node);
> > > > }
> > >
> > > Or, alternatively, the rcu_assign_index() patch sent earlier to avoid
> > > the bare memory barrier?
> > >
> > > Thanx, Paul
> >
> > I am fine with rcu_assign_index(), and add a comment in node_set_parent.
>
> OK, how about the following?
>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> ---
>
> fib_trie.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff -urpNa -X dontdiff linux-2.6.25-rc1/net/ipv4/fib_trie.c linux-2.6.25-rc1-fib_trie-warn.compile/net/ipv4/fib_trie.c
> --- linux-2.6.25-rc1/net/ipv4/fib_trie.c 2008-02-13 14:38:12.000000000 -0800
> +++ linux-2.6.25-rc1-fib_trie-warn.compile/net/ipv4/fib_trie.c 2008-02-13 17:31:16.000000000 -0800
> @@ -96,6 +96,14 @@ typedef unsigned int t_key;
> #define IS_TNODE(n) (!(n->parent & T_LEAF))
> #define IS_LEAF(n) (n->parent & T_LEAF)
>
> +/*
> + * The "parent" fields in struct node and struct leaf are really pointers,
> + * but with the possibility that the T_LEAF bit is set. Therefore, both
> + * the C compiler and RCU see them as integers rather than pointers.
> + * This in turn means that rcu_assign_index() must be used to assign
> + * values to these fields, rather than the usual rcu_assign_pointer().
> + */
> +
> struct node {
> unsigned long parent;
> t_key key;
> @@ -179,8 +187,7 @@ static inline struct tnode *node_parent_
>
> static inline void node_set_parent(struct node *node, struct tnode *ptr)
> {
> - rcu_assign_pointer(node->parent,
> - (unsigned long)ptr | NODE_TYPE(node));
> + rcu_assign_index(node->parent, (unsigned long)ptr | NODE_TYPE(node));
> }
>
> static inline struct node *tnode_get_child(struct tnode *tn, unsigned int i)
Yes, thats great.
^ permalink raw reply
* Re: [PATCH 1/2] remove rcu_assign_pointer(NULL) penalty with type/macro safety
From: Paul E. McKenney @ 2008-02-14 1:34 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Stephen Hemminger, linux-kernel, davem, netdev, dipankar, ego,
herbert, akpm
In-Reply-To: <20080213165356.11d02092@extreme>
On Wed, Feb 13, 2008 at 04:53:56PM -0800, Stephen Hemminger wrote:
> On Wed, 13 Feb 2008 16:42:53 -0800
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> > On Wed, Feb 13, 2008 at 04:27:00PM -0800, Stephen Hemminger wrote:
[ . . . ]
> > > That is heading towards ugly... Maybe not using the macro at all (for this case) would be best:
> > >
> > > static inline void node_set_parent(struct node *node, struct tnode *ptr)
> > > {
> > > smp_wmb();
> > > node->parent = (unsigned long)ptr | NODE_TYPE(node);
> > > }
> >
> > Or, alternatively, the rcu_assign_index() patch sent earlier to avoid
> > the bare memory barrier?
> >
> > Thanx, Paul
>
> I am fine with rcu_assign_index(), and add a comment in node_set_parent.
OK, how about the following?
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
fib_trie.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff -urpNa -X dontdiff linux-2.6.25-rc1/net/ipv4/fib_trie.c linux-2.6.25-rc1-fib_trie-warn.compile/net/ipv4/fib_trie.c
--- linux-2.6.25-rc1/net/ipv4/fib_trie.c 2008-02-13 14:38:12.000000000 -0800
+++ linux-2.6.25-rc1-fib_trie-warn.compile/net/ipv4/fib_trie.c 2008-02-13 17:31:16.000000000 -0800
@@ -96,6 +96,14 @@ typedef unsigned int t_key;
#define IS_TNODE(n) (!(n->parent & T_LEAF))
#define IS_LEAF(n) (n->parent & T_LEAF)
+/*
+ * The "parent" fields in struct node and struct leaf are really pointers,
+ * but with the possibility that the T_LEAF bit is set. Therefore, both
+ * the C compiler and RCU see them as integers rather than pointers.
+ * This in turn means that rcu_assign_index() must be used to assign
+ * values to these fields, rather than the usual rcu_assign_pointer().
+ */
+
struct node {
unsigned long parent;
t_key key;
@@ -179,8 +187,7 @@ static inline struct tnode *node_parent_
static inline void node_set_parent(struct node *node, struct tnode *ptr)
{
- rcu_assign_pointer(node->parent,
- (unsigned long)ptr | NODE_TYPE(node));
+ rcu_assign_index(node->parent, (unsigned long)ptr | NODE_TYPE(node));
}
static inline struct node *tnode_get_child(struct tnode *tn, unsigned int i)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox