* [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 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 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
* Re: [PATCH][KEY] fix bug in spdadd
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2008-02-14 14:54 UTC (permalink / raw)
To: kazunori, davem; +Cc: netdev
In-Reply-To: <47B42C3C.5090104@miyazawa.org>
In article <47B42C3C.5090104@miyazawa.org> (at Thu, 14 Feb 2008 20:55:40 +0900), Kazunori MIYAZAWA <kazunori@miyazawa.org> says:
> This patch fix a BUG when adding spds which have
> same selector.
>
> Signed-off-by: Kazunori MIYAZAWA <kazunori@miyazawa.org>
I think we need to fix xfrm_user side as well.
---
[PATCH] [XFRM]: Avoid bogus BUG() when throwing new policy away.
When we destory a new policy entry, we need to tell
xfrm_policy_destroy() explicitly that the entry is not
alive yet.
---
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 7833807..f971ca5 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1105,6 +1105,7 @@ static struct xfrm_policy *xfrm_policy_construct(struct xfrm_userpolicy_info *p,
return xp;
error:
*errp = err;
+ xp->dead = 1;
xfrm_policy_destroy(xp);
return NULL;
}
--
YOSHIFUJI Hideaki @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply related
* [PATCH 06/14] drivers/net/arcnet/arcnet.c: Use time_* macros
From: S.Çağlar Onur @ 2008-02-14 15:36 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, S.Çağlar Onur
The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at linux/jiffies.h, which deals with wrapping correctly
Cc: netdev@vger.kernel.org
Signed-off-by: S.Çağlar Onur <caglar@pardus.org.tr>
---
drivers/net/arcnet/arcnet.c | 4 ++--
include/linux/arcdevice.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/arcnet/arcnet.c b/drivers/net/arcnet/arcnet.c
index c59c806..c298615 100644
--- a/drivers/net/arcnet/arcnet.c
+++ b/drivers/net/arcnet/arcnet.c
@@ -940,7 +940,7 @@ irqreturn_t arcnet_interrupt(int irq, void *dev_id)
/* is the RECON info empty or old? */
if (!lp->first_recon || !lp->last_recon ||
- jiffies - lp->last_recon > HZ * 10) {
+ time_after(jiffies, lp->last_recon + HZ * 10)) {
if (lp->network_down)
BUGMSG(D_NORMAL, "reconfiguration detected: cabling restored?\n");
lp->first_recon = lp->last_recon = jiffies;
@@ -974,7 +974,7 @@ irqreturn_t arcnet_interrupt(int irq, void *dev_id)
lp->num_recons = 1;
}
}
- } else if (lp->network_down && jiffies - lp->last_recon > HZ * 10) {
+ } else if (lp->network_down && time_after(jiffies, lp->last_recon + HZ * 10)) {
if (lp->network_down)
BUGMSG(D_NORMAL, "cabling restored?\n");
lp->first_recon = lp->last_recon = 0;
diff --git a/include/linux/arcdevice.h b/include/linux/arcdevice.h
index fde6758..537d661 100644
--- a/include/linux/arcdevice.h
+++ b/include/linux/arcdevice.h
@@ -283,7 +284,7 @@ struct arcnet_local {
int next_buf, first_free_buf;
/* network "reconfiguration" handling */
- time_t first_recon, /* time of "first" RECON message to count */
+ unsigned long first_recon, /* time of "first" RECON message to count */
last_recon; /* time of most recent RECON */
int num_recons; /* number of RECONs between first and last. */
bool network_down; /* do we think the network is down? */
--
1.5.3.7
^ permalink raw reply related
* [PATCH 07/14] drivers/net/ax88796.c: Use time_* macros
From: S.Çağlar Onur @ 2008-02-14 15:36 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, S.Çağlar Onur
The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at linux/jiffies.h, which deals with wrapping correctly
Cc: netdev@vger.kernel.org
Signed-off-by: S.Çağlar Onur <caglar@pardus.org.tr>
---
drivers/net/ax88796.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ax88796.c b/drivers/net/ax88796.c
index 194949a..0f823d7 100644
--- a/drivers/net/ax88796.c
+++ b/drivers/net/ax88796.c
@@ -11,6 +11,7 @@
* published by the Free Software Foundation.
*/
+#include <linux/jiffies.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
@@ -151,7 +152,7 @@ static void ax_reset_8390(struct net_device *dev)
/* This check _should_not_ be necessary, omit eventually. */
while ((ei_inb(addr + EN0_ISR) & ENISR_RESET) == 0) {
- if (jiffies - reset_start_time > 2*HZ/100) {
+ if (time_after(jiffies, reset_start_time + 2 * HZ/100)) {
dev_warn(&ax->dev->dev, "%s: %s did not complete.\n",
__FUNCTION__, dev->name);
break;
@@ -287,7 +288,7 @@ static void ax_block_output(struct net_device *dev, int count,
dma_start = jiffies;
while ((ei_inb(nic_base + EN0_ISR) & ENISR_RDC) == 0) {
- if (jiffies - dma_start > 2*HZ/100) { /* 20ms */
+ if (time_after(jiffies, dma_start + 2 * HZ/100)) { /* 20ms */
dev_warn(&ax->dev->dev,
"%s: timeout waiting for Tx RDC.\n", dev->name);
ax_reset_8390(dev);
--
1.5.3.7
^ permalink raw reply related
* [PATCH 10/14] drivers/net/tokenring/3c359.c: Use time_* macros
From: S.Çağlar Onur @ 2008-02-14 15:36 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, S.Çağlar Onur
The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at linux/jiffies.h, which deals with wrapping correctly
Cc: netdev@vger.kernel.org
Signed-off-by: S.Çağlar Onur <caglar@pardus.org.tr>
---
drivers/net/tokenring/3c359.c | 21 +++++++++++----------
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/net/tokenring/3c359.c b/drivers/net/tokenring/3c359.c
index 44a06f8..88fe955 100644
--- a/drivers/net/tokenring/3c359.c
+++ b/drivers/net/tokenring/3c359.c
@@ -42,6 +42,7 @@
#define XL_DEBUG 0
+#include <linux/jiffies.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
@@ -408,7 +409,7 @@ static int xl_hw_reset(struct net_device *dev)
t=jiffies;
while (readw(xl_mmio + MMIO_INTSTATUS) & INTSTAT_CMD_IN_PROGRESS) {
schedule();
- if(jiffies-t > 40*HZ) {
+ if(time_after(jiffies, t + 40 * HZ)) {
printk(KERN_ERR "%s: 3COM 3C359 Velocity XL card not responding to global reset.\n", dev->name);
return -ENODEV;
}
@@ -519,7 +520,7 @@ static int xl_hw_reset(struct net_device *dev)
t=jiffies;
while ( !(readw(xl_mmio + MMIO_INTSTATUS_AUTO) & INTSTAT_SRB) ) {
schedule();
- if(jiffies-t > 15*HZ) {
+ if(time_after(jiffies, t + 15 * HZ)) {
printk(KERN_ERR "3COM 3C359 Velocity XL card not responding.\n");
return -ENODEV;
}
@@ -790,7 +791,7 @@ static int xl_open_hw(struct net_device *dev)
t=jiffies;
while (! (readw(xl_mmio + MMIO_INTSTATUS) & INTSTAT_SRB)) {
schedule();
- if(jiffies-t > 40*HZ) {
+ if(time_after(jiffies, t + 40 * HZ)) {
printk(KERN_ERR "3COM 3C359 Velocity XL card not responding.\n");
break ;
}
@@ -1003,7 +1004,7 @@ static void xl_reset(struct net_device *dev)
t=jiffies;
while (readw(xl_mmio + MMIO_INTSTATUS) & INTSTAT_CMD_IN_PROGRESS) {
- if(jiffies-t > 40*HZ) {
+ if(time_after(jiffies, t + 40 * HZ)) {
printk(KERN_ERR "3COM 3C359 Velocity XL card not responding.\n");
break ;
}
@@ -1270,7 +1271,7 @@ static int xl_close(struct net_device *dev)
t=jiffies;
while (readw(xl_mmio + MMIO_INTSTATUS) & INTSTAT_CMD_IN_PROGRESS) {
schedule();
- if(jiffies-t > 10*HZ) {
+ if(time_after(jiffies, t + 10 * HZ)) {
printk(KERN_ERR "%s: 3COM 3C359 Velocity XL-DNSTALL not responding.\n", dev->name);
break ;
}
@@ -1279,7 +1280,7 @@ static int xl_close(struct net_device *dev)
t=jiffies;
while (readw(xl_mmio + MMIO_INTSTATUS) & INTSTAT_CMD_IN_PROGRESS) {
schedule();
- if(jiffies-t > 10*HZ) {
+ if(time_after(jiffies, t + 10 * HZ)) {
printk(KERN_ERR "%s: 3COM 3C359 Velocity XL-DNDISABLE not responding.\n", dev->name);
break ;
}
@@ -1288,7 +1289,7 @@ static int xl_close(struct net_device *dev)
t=jiffies;
while (readw(xl_mmio + MMIO_INTSTATUS) & INTSTAT_CMD_IN_PROGRESS) {
schedule();
- if(jiffies-t > 10*HZ) {
+ if(time_after(jiffies, t + 10 * HZ)) {
printk(KERN_ERR "%s: 3COM 3C359 Velocity XL-UPSTALL not responding.\n", dev->name);
break ;
}
@@ -1305,7 +1306,7 @@ static int xl_close(struct net_device *dev)
t=jiffies;
while (!(readw(xl_mmio + MMIO_INTSTATUS) & INTSTAT_SRB)) {
schedule();
- if(jiffies-t > 10*HZ) {
+ if(time_after(jiffies, t + 10 * HZ)) {
printk(KERN_ERR "%s: 3COM 3C359 Velocity XL-CLOSENIC not responding.\n", dev->name);
break ;
}
@@ -1334,7 +1335,7 @@ static int xl_close(struct net_device *dev)
t=jiffies;
while (readw(xl_mmio + MMIO_INTSTATUS) & INTSTAT_CMD_IN_PROGRESS) {
schedule();
- if(jiffies-t > 10*HZ) {
+ if(time_after(jiffies, t + 10 * HZ)) {
printk(KERN_ERR "%s: 3COM 3C359 Velocity XL-UPRESET not responding.\n", dev->name);
break ;
}
@@ -1343,7 +1344,7 @@ static int xl_close(struct net_device *dev)
t=jiffies;
while (readw(xl_mmio + MMIO_INTSTATUS) & INTSTAT_CMD_IN_PROGRESS) {
schedule();
- if(jiffies-t > 10*HZ) {
+ if(time_after(jiffies, t + 10 * HZ)) {
printk(KERN_ERR "%s: 3COM 3C359 Velocity XL-DNRESET not responding.\n", dev->name);
break ;
}
--
1.5.3.7
^ permalink raw reply related
* Re: [PATCH][RFC] race in generic address resolution
From: Benjamin Thery @ 2008-02-14 16:56 UTC (permalink / raw)
To: David Miller; +Cc: blaschka, netdev
In-Reply-To: <20080211.214711.134366517.davem@davemloft.net>
Hi,
It seems this patch hangs my machine very quickly when there are some
ICMPv6 traffic.
I'm using net-2.6, pulled today (14th Feb).
I had some unexpected hangs on my SMP test machines and I bisected the
problem to 69cc64d8d92bf852f933e90c888dfff083bd4fc9
"[NDISC]: Fix race in generic address resolution".
Looks like a deadlock:
"BUG: soft lockup - CPU#1 stuck for 61s! [swapper:0]"
Here are some traces printed on the console:
Pid: 0, comm: swapper Not tainted (2.6.25-rc1-netns-00113-g69cc64d-dirty #34)
EIP: 0060:[<c02eb5f6>] EFLAGS: 00000287 CPU: 0
EIP is at __write_lock_failed+0xa/0x20
EAX: c7b3fab4 EBX: c7b3fab4 ECX: 00000000 EDX: c0377986
ESI: c7b3fa90 EDI: c7b6f290 EBP: c03cbd24 ESP: c03cbd24
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
CR0: 8005003b CR2: b7f9b404 CR3: 07ac8000 CR4: 00000690
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00000000 DR7: 00000000
[<c020e43f>] _raw_write_lock+0x57/0x6c
[<c02eba95>] _write_lock_bh+0x25/0x2d
[<c026b107>] ? neigh_resolve_output+0x93/0x238
[<c026b107>] neigh_resolve_output+0x93/0x238
[<c02a5635>] ip6_output2+0x241/0x289
[<c02a61cd>] ip6_output+0xa92/0xaad
[<c025ff11>] ? __alloc_skb+0x4f/0xfb
[<c02b2596>] ? __ndisc_send+0x1fb/0x3f5
[<c02b26a0>] __ndisc_send+0x305/0x3f5
[<c02b2fb5>] ndisc_send_ns+0x63/0x6e
[<c02b3f3e>] ndisc_solicit+0x183/0x18d
[<c0121071>] ? __mod_timer+0x96/0xa1
[<c026b81e>] neigh_timer_handler+0x214/0x252
[<c0120c90>] run_timer_softirq+0xfe/0x159
[<c026b60a>] ? neigh_timer_handler+0x0/0x252
[<c011dbfa>] __do_softirq+0x6f/0xe9
[<c011dcae>] do_softirq+0x3a/0x52
[<c011dfc3>] irq_exit+0x44/0x46
[<c0105273>] do_IRQ+0x5a/0x73
[<c0103666>] common_interrupt+0x2e/0x34
[<c0101954>] ? default_idle+0x4a/0x77
[<c010190a>] ? default_idle+0x0/0x77
[<c0101855>] cpu_idle+0x89/0x9d
[<c02e6135>] rest_init+0x49/0x4b
=======================
BUG: soft lockup - CPU#1 stuck for 61s! [swapper:0]
Pid: 0, comm: swapper Not tainted (2.6.25-rc1-netns-00113-g69cc64d-dirty #34)
EIP: 0060:[<c02eb5f6>] EFLAGS: 00000287 CPU: 1
EIP is at __write_lock_failed+0xa/0x20
EAX: c7b3fab4 EBX: c7b3fab4 ECX: 00000000 EDX: 00000000
ESI: c03bb9c0 EDI: c7b3fab4 EBP: c7841eb0 ESP: c7841eb0
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
CR0: 8005003b CR2: 08560008 CR3: 07b04000 CR4: 00000690
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00000000 DR7: 00000000
[<c020e43f>] _raw_write_lock+0x57/0x6c
[<c02eba68>] _write_lock+0x20/0x28
[<c026982c>] ? neigh_periodic_timer+0x99/0x142
[<c026982c>] neigh_periodic_timer+0x99/0x142
[<c0120c90>] run_timer_softirq+0xfe/0x159
[<c0269793>] ? neigh_periodic_timer+0x0/0x142
[<c011dbfa>] __do_softirq+0x6f/0xe9
[<c011dcae>] do_softirq+0x3a/0x52
[<c011dfc3>] irq_exit+0x44/0x46
[<c010d680>] smp_apic_timer_interrupt+0x71/0x81
[<c0103747>] apic_timer_interrupt+0x33/0x38
[<c0101954>] ? default_idle+0x4a/0x77
[<c010190a>] ? default_idle+0x0/0x77
[<c0101855>] cpu_idle+0x89/0x9d
=======================
BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
Pid: 0, comm: swapper Not tainted (2.6.25-rc1-netns-00113-g69cc64d-dirty #34)
EIP: 0060:[<c02eb5f6>] EFLAGS: 00000287 CPU: 0
EIP is at __write_lock_failed+0xa/0x20
EAX: c7b3fab4 EBX: c7b3fab4 ECX: 00000000 EDX: c0377986
ESI: c7b3fa90 EDI: c7b6f290 EBP: c03cbd24 ESP: c03cbd24
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
CR0: 8005003b CR2: b7f9b404 CR3: 07ac8000 CR4: 00000690
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00000000 DR7: 00000000
[<c020e43f>] _raw_write_lock+0x57/0x6c
[<c02eba95>] _write_lock_bh+0x25/0x2d
[<c026b107>] ? neigh_resolve_output+0x93/0x238
[<c026b107>] neigh_resolve_output+0x93/0x238
[<c02a5635>] ip6_output2+0x241/0x289
[<c02a61cd>] ip6_output+0xa92/0xaad
[<c025ff11>] ? __alloc_skb+0x4f/0xfb
[<c02b2596>] ? __ndisc_send+0x1fb/0x3f5
[<c02b26a0>] __ndisc_send+0x305/0x3f5
[<c02b2fb5>] ndisc_send_ns+0x63/0x6e
[<c02b3f3e>] ndisc_solicit+0x183/0x18d
[<c0121071>] ? __mod_timer+0x96/0xa1
[<c026b81e>] neigh_timer_handler+0x214/0x252
[<c0120c90>] run_timer_softirq+0xfe/0x159
[<c026b60a>] ? neigh_timer_handler+0x0/0x252
[<c011dbfa>] __do_softirq+0x6f/0xe9
[<c011dcae>] do_softirq+0x3a/0x52
[<c011dfc3>] irq_exit+0x44/0x46
[<c0105273>] do_IRQ+0x5a/0x73
[<c0103666>] common_interrupt+0x2e/0x34
[<c0101954>] ? default_idle+0x4a/0x77
[<c010190a>] ? default_idle+0x0/0x77
[<c0101855>] cpu_idle+0x89/0x9d
[<c02e6135>] rest_init+0x49/0x4b
=======================
BUG: soft lockup - CPU#1 stuck for 61s! [swapper:0]
...
Benjamin
On Tue, Feb 12, 2008 at 6:47 AM, David Miller <davem@davemloft.net> wrote:
> From: Frank Blaschka <blaschka@linux.vnet.ibm.com>
> Date: Mon, 11 Feb 2008 10:01:20 +0100
>
>
> > we run your patch during the weekend on single CPU and SMP
> > machines. We do not see any problems. Thanks for providing the fix.
>
> Thanks for testing Frank, I can now push this fix upstream.
>
>
> --
> 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
* broken link-local multicast?
From: Marco d'Itri @ 2008-02-14 16:28 UTC (permalink / raw)
To: netdev
Link-local multicast appears to be broken on some interfaces of some of
my firewalls. I think that this started after I configured quagga's
ospf6d (which does not work because of this), but I am not totally sure.
Does anybody have any idea about how to debug this?
root@frwl-5a:~# ping6 -c 1 -I eth1 ff02::1
connect: Network is unreachable
root@frwl-5a:~# ping6 -c 1 -I eth0 ff02::1
PING ff02::1(ff02::1) from fe80::204:23ff:fed8:7dc eth0: 56 data bytes
64 bytes from fe80::204:23ff:fed8:7dc: icmp_seq=1 ttl=64 time=0.032 ms
--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.032/0.032/0.032/0.000 ms
root@frwl-5a:~# ip -6 ro | egrep '^fe80:.* eth[01] '
fe80::/64 dev eth0 metric 256 expires 18788161sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev eth1 metric 256 expires 18788161sec mtu 1500 advmss 1440 hoplimit 4294967295
root@frwl-5a:~# uname -a
Linux frwl-5a 2.6.18-3-686 #1 SMP Mon Dec 4 16:41:14 UTC 2006 i686 GNU/Linux
--
ciao,
Marco
^ permalink raw reply
* Re: [PATCH][RFC] race in generic address resolution
From: Benjamin Thery @ 2008-02-14 16:59 UTC (permalink / raw)
To: David Miller; +Cc: blaschka, netdev
In-Reply-To: <939d53060802140856v5168a4a2md8c8ed3fad6798e4@mail.gmail.com>
I ran some additional tests and these traces may also be usefull.
They appears before the soft-lockup are detected.
fermi:~# ping6 -c 500 -f 2007::1
PING 2007::1(2007::1) 56 data bytes
.
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.25-rc1-00113-g69cc64d-dirty #34
-------------------------------------------------------
ping6/1058 is trying to acquire lock:
(&tbl->lock){-+-+}, at: [<c02691ac>] neigh_lookup+0x43/0xa2
but task is already holding lock:
(&n->lock){-+..}, at: [<c026b620>] neigh_timer_handler+0x16/0x252
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&n->lock){-+..}:
[<c01330b8>] __lock_acquire+0x947/0xafc
[<c026982c>] neigh_periodic_timer+0x99/0x142
[<c01332d0>] lock_acquire+0x63/0x80
[<c026982c>] neigh_periodic_timer+0x99/0x142
[<c02eba61>] _write_lock+0x19/0x28
[<c026982c>] neigh_periodic_timer+0x99/0x142
[<c026982c>] neigh_periodic_timer+0x99/0x142
[<c0120c90>] run_timer_softirq+0xfe/0x159
[<c0269793>] neigh_periodic_timer+0x0/0x142
[<c011dbfa>] __do_softirq+0x6f/0xe9
[<c011dcae>] do_softirq+0x3a/0x52
[<c011dfc3>] irq_exit+0x44/0x46
[<c010d680>] smp_apic_timer_interrupt+0x71/0x81
[<c0103747>] apic_timer_interrupt+0x33/0x38
[<c014e0ce>] mmap_region+0xe1/0x376
[<c014e680>] arch_get_unmapped_area_topdown+0x0/0x12e
[<c014e625>] do_mmap_pgoff+0x1e2/0x23d
[<c0181895>] elf_map+0xd8/0x104
[<c0182072>] load_elf_binary+0x5b4/0x11cd
[<c015ed73>] search_binary_handler+0x74/0x164
[<c0181abe>] load_elf_binary+0x0/0x11cd
[<c015ed7a>] search_binary_handler+0x7b/0x164
[<c015ff2e>] do_execve+0x121/0x16a
[<c01012e3>] sys_execve+0x29/0x52
[<c0102c56>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
-> #0 (&tbl->lock){-+-+}:
[<c0132fdf>] __lock_acquire+0x86e/0xafc
[<c01332d0>] lock_acquire+0x63/0x80
[<c02691ac>] neigh_lookup+0x43/0xa2
[<c02ebae9>] _read_lock_bh+0x1e/0x2d
[<c02691ac>] neigh_lookup+0x43/0xa2
[<c02691ac>] neigh_lookup+0x43/0xa2
[<c02af858>] ndisc_dst_alloc+0xb5/0x155
[<c02b240d>] __ndisc_send+0x72/0x3f5
[<c02a573b>] ip6_output+0x0/0xaad
[<c0133225>] __lock_acquire+0xab4/0xafc
[<c02b2fb5>] ndisc_send_ns+0x63/0x6e
[<c02eb92c>] _read_unlock_bh+0x25/0x28
[<c02b3f3e>] ndisc_solicit+0x183/0x18d
[<c0121071>] __mod_timer+0x96/0xa1
[<c026b81e>] neigh_timer_handler+0x214/0x252
[<c0120c90>] run_timer_softirq+0xfe/0x159
[<c026b60a>] neigh_timer_handler+0x0/0x252
[<c011dbfa>] __do_softirq+0x6f/0xe9
[<c011dcae>] do_softirq+0x3a/0x52
[<c011dfc3>] irq_exit+0x44/0x46
[<c0105273>] do_IRQ+0x5a/0x73
[<c0103666>] common_interrupt+0x2e/0x34
[<c02ebd3a>] _spin_unlock_irqrestore+0x38/0x3c
[<c02188fb>] tty_ldisc_deref+0x5c/0x63
[<c021a5bd>] tty_write+0x1a8/0x1b9
[<c021c5e1>] write_chan+0x0/0x2a9
[<c021a633>] redirected_tty_write+0x65/0x72
[<c021a5ce>] redirected_tty_write+0x0/0x72
[<c015be18>] vfs_write+0x8c/0x108
[<c015c3a2>] sys_write+0x3b/0x60
[<c0102c56>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
other info that might help us debug this:
1 lock held by ping6/1058:
#0: (&n->lock){-+..}, at: [<c026b620>] neigh_timer_handler+0x16/0x252
stack backtrace:
Pid: 1058, comm: ping6 Not tainted 2.6.25-rc1-netns-00113-g69cc64d-dirty #34
[<c013176b>] print_circular_bug_tail+0x5b/0x66
[<c0132fdf>] __lock_acquire+0x86e/0xafc
[<c01332d0>] lock_acquire+0x63/0x80
[<c02691ac>] ? neigh_lookup+0x43/0xa2
[<c02ebae9>] _read_lock_bh+0x1e/0x2d
[<c02691ac>] ? neigh_lookup+0x43/0xa2
[<c02691ac>] neigh_lookup+0x43/0xa2
[<c02af858>] ndisc_dst_alloc+0xb5/0x155
[<c02b240d>] __ndisc_send+0x72/0x3f5
[<c02a573b>] ? ip6_output+0x0/0xaad
[<c0133225>] ? __lock_acquire+0xab4/0xafc
[<c02b2fb5>] ndisc_send_ns+0x63/0x6e
[<c02eb92c>] ? _read_unlock_bh+0x25/0x28
[<c02b3f3e>] ndisc_solicit+0x183/0x18d
[<c0121071>] ? __mod_timer+0x96/0xa1
[<c026b81e>] neigh_timer_handler+0x214/0x252
[<c0120c90>] run_timer_softirq+0xfe/0x159
[<c026b60a>] ? neigh_timer_handler+0x0/0x252
[<c011dbfa>] __do_softirq+0x6f/0xe9
[<c011dcae>] do_softirq+0x3a/0x52
[<c011dfc3>] irq_exit+0x44/0x46
[<c0105273>] do_IRQ+0x5a/0x73
[<c0103666>] common_interrupt+0x2e/0x34
[<c02ebd3a>] ? _spin_unlock_irqrestore+0x38/0x3c
[<c02188fb>] tty_ldisc_deref+0x5c/0x63
[<c021a5bd>] tty_write+0x1a8/0x1b9
[<c021c5e1>] ? write_chan+0x0/0x2a9
[<c021a633>] redirected_tty_write+0x65/0x72
[<c021a5ce>] ? redirected_tty_write+0x0/0x72
[<c015be18>] vfs_write+0x8c/0x108
[<c015c3a2>] sys_write+0x3b/0x60
[<c0102c56>] syscall_call+0x7/0xb
=======================
On Thu, Feb 14, 2008 at 5:56 PM, Benjamin Thery <ben.thery@gmail.com> wrote:
> Hi,
>
> It seems this patch hangs my machine very quickly when there are some
> ICMPv6 traffic.
>
> I'm using net-2.6, pulled today (14th Feb).
>
> I had some unexpected hangs on my SMP test machines and I bisected the
> problem to 69cc64d8d92bf852f933e90c888dfff083bd4fc9
> "[NDISC]: Fix race in generic address resolution".
>
> Looks like a deadlock:
> "BUG: soft lockup - CPU#1 stuck for 61s! [swapper:0]"
>
> Here are some traces printed on the console:
>
> Pid: 0, comm: swapper Not tainted (2.6.25-rc1-netns-00113-g69cc64d-dirty #34)
> EIP: 0060:[<c02eb5f6>] EFLAGS: 00000287 CPU: 0
> EIP is at __write_lock_failed+0xa/0x20
> EAX: c7b3fab4 EBX: c7b3fab4 ECX: 00000000 EDX: c0377986
> ESI: c7b3fa90 EDI: c7b6f290 EBP: c03cbd24 ESP: c03cbd24
> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
> CR0: 8005003b CR2: b7f9b404 CR3: 07ac8000 CR4: 00000690
> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> DR6: 00000000 DR7: 00000000
> [<c020e43f>] _raw_write_lock+0x57/0x6c
> [<c02eba95>] _write_lock_bh+0x25/0x2d
> [<c026b107>] ? neigh_resolve_output+0x93/0x238
> [<c026b107>] neigh_resolve_output+0x93/0x238
> [<c02a5635>] ip6_output2+0x241/0x289
> [<c02a61cd>] ip6_output+0xa92/0xaad
> [<c025ff11>] ? __alloc_skb+0x4f/0xfb
> [<c02b2596>] ? __ndisc_send+0x1fb/0x3f5
> [<c02b26a0>] __ndisc_send+0x305/0x3f5
> [<c02b2fb5>] ndisc_send_ns+0x63/0x6e
> [<c02b3f3e>] ndisc_solicit+0x183/0x18d
> [<c0121071>] ? __mod_timer+0x96/0xa1
> [<c026b81e>] neigh_timer_handler+0x214/0x252
> [<c0120c90>] run_timer_softirq+0xfe/0x159
> [<c026b60a>] ? neigh_timer_handler+0x0/0x252
> [<c011dbfa>] __do_softirq+0x6f/0xe9
> [<c011dcae>] do_softirq+0x3a/0x52
> [<c011dfc3>] irq_exit+0x44/0x46
> [<c0105273>] do_IRQ+0x5a/0x73
> [<c0103666>] common_interrupt+0x2e/0x34
> [<c0101954>] ? default_idle+0x4a/0x77
> [<c010190a>] ? default_idle+0x0/0x77
> [<c0101855>] cpu_idle+0x89/0x9d
> [<c02e6135>] rest_init+0x49/0x4b
> =======================
> BUG: soft lockup - CPU#1 stuck for 61s! [swapper:0]
>
> Pid: 0, comm: swapper Not tainted (2.6.25-rc1-netns-00113-g69cc64d-dirty #34)
> EIP: 0060:[<c02eb5f6>] EFLAGS: 00000287 CPU: 1
> EIP is at __write_lock_failed+0xa/0x20
> EAX: c7b3fab4 EBX: c7b3fab4 ECX: 00000000 EDX: 00000000
> ESI: c03bb9c0 EDI: c7b3fab4 EBP: c7841eb0 ESP: c7841eb0
> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
> CR0: 8005003b CR2: 08560008 CR3: 07b04000 CR4: 00000690
> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> DR6: 00000000 DR7: 00000000
> [<c020e43f>] _raw_write_lock+0x57/0x6c
> [<c02eba68>] _write_lock+0x20/0x28
> [<c026982c>] ? neigh_periodic_timer+0x99/0x142
> [<c026982c>] neigh_periodic_timer+0x99/0x142
> [<c0120c90>] run_timer_softirq+0xfe/0x159
> [<c0269793>] ? neigh_periodic_timer+0x0/0x142
> [<c011dbfa>] __do_softirq+0x6f/0xe9
> [<c011dcae>] do_softirq+0x3a/0x52
> [<c011dfc3>] irq_exit+0x44/0x46
> [<c010d680>] smp_apic_timer_interrupt+0x71/0x81
> [<c0103747>] apic_timer_interrupt+0x33/0x38
> [<c0101954>] ? default_idle+0x4a/0x77
> [<c010190a>] ? default_idle+0x0/0x77
> [<c0101855>] cpu_idle+0x89/0x9d
> =======================
> BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
>
> Pid: 0, comm: swapper Not tainted (2.6.25-rc1-netns-00113-g69cc64d-dirty #34)
> EIP: 0060:[<c02eb5f6>] EFLAGS: 00000287 CPU: 0
> EIP is at __write_lock_failed+0xa/0x20
> EAX: c7b3fab4 EBX: c7b3fab4 ECX: 00000000 EDX: c0377986
> ESI: c7b3fa90 EDI: c7b6f290 EBP: c03cbd24 ESP: c03cbd24
> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
> CR0: 8005003b CR2: b7f9b404 CR3: 07ac8000 CR4: 00000690
> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> DR6: 00000000 DR7: 00000000
> [<c020e43f>] _raw_write_lock+0x57/0x6c
> [<c02eba95>] _write_lock_bh+0x25/0x2d
> [<c026b107>] ? neigh_resolve_output+0x93/0x238
> [<c026b107>] neigh_resolve_output+0x93/0x238
> [<c02a5635>] ip6_output2+0x241/0x289
> [<c02a61cd>] ip6_output+0xa92/0xaad
> [<c025ff11>] ? __alloc_skb+0x4f/0xfb
> [<c02b2596>] ? __ndisc_send+0x1fb/0x3f5
> [<c02b26a0>] __ndisc_send+0x305/0x3f5
> [<c02b2fb5>] ndisc_send_ns+0x63/0x6e
> [<c02b3f3e>] ndisc_solicit+0x183/0x18d
> [<c0121071>] ? __mod_timer+0x96/0xa1
> [<c026b81e>] neigh_timer_handler+0x214/0x252
> [<c0120c90>] run_timer_softirq+0xfe/0x159
> [<c026b60a>] ? neigh_timer_handler+0x0/0x252
> [<c011dbfa>] __do_softirq+0x6f/0xe9
> [<c011dcae>] do_softirq+0x3a/0x52
> [<c011dfc3>] irq_exit+0x44/0x46
> [<c0105273>] do_IRQ+0x5a/0x73
> [<c0103666>] common_interrupt+0x2e/0x34
> [<c0101954>] ? default_idle+0x4a/0x77
> [<c010190a>] ? default_idle+0x0/0x77
> [<c0101855>] cpu_idle+0x89/0x9d
> [<c02e6135>] rest_init+0x49/0x4b
> =======================
> BUG: soft lockup - CPU#1 stuck for 61s! [swapper:0]
> ...
>
>
> Benjamin
>
>
>
> On Tue, Feb 12, 2008 at 6:47 AM, David Miller <davem@davemloft.net> wrote:
> > From: Frank Blaschka <blaschka@linux.vnet.ibm.com>
> > Date: Mon, 11 Feb 2008 10:01:20 +0100
> >
> >
> > > we run your patch during the weekend on single CPU and SMP
> > > machines. We do not see any problems. Thanks for providing the fix.
> >
> > Thanks for testing Frank, I can now push this fix upstream.
> >
> >
> > --
> > 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 2/2] add rcu_assign_index() if ever needed
From: Paul E. McKenney @ 2008-02-14 17:08 UTC (permalink / raw)
To: Gautham R Shenoy
Cc: linux-kernel, shemminger, davem, netdev, dipankar, herbert, akpm
In-Reply-To: <20080214033209.GA7266@in.ibm.com>
On Thu, Feb 14, 2008 at 09:02:09AM +0530, Gautham R Shenoy wrote:
> 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.
Good catch!!!
Thanx, Paul
^ permalink raw reply
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Dave Hansen @ 2008-02-14 17:12 UTC (permalink / raw)
To: Christoph Raisch
Cc: ossthema, apw, Greg KH, Jan-Bernd Themann, linux-kernel,
linuxppc-dev, netdev, Badari Pulavarty, Thomas Q Klein, tklein
In-Reply-To: <OF64B9886B.CE795DED-ONC12573EF.002FFA8B-C12573EF.00301683@de.ibm.com>
On Thu, 2008-02-14 at 09:46 +0100, Christoph Raisch wrote:
> 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.
Can you give a ballpark of how many there are to work with? 10? 100?
1000?
> 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?
If you use good interfaces, and someone changes them, they'll likely
also fix your driver.
If you use bad interfaces, people may not even notice when they break.
As I showed you with those compile failures, you're using bad interfaces
that don't even compile on some .configs.
> 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.
Technically, you can do this. But, it's not a sign of a professionally
written driver that is going to get its patches accepted into mainline.
Technically, you can also use lots of magic numbers and not obey
CodingStyle. But, you'll probably get review comments asking you to
change it.
> > > - 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?
Dude. It exists *TODAY*. Go take a machine, add tens of gigabytes of
memory to it. Then, remove all of the sections of memory in the middle.
You'll be left with a very sparse memory configuration that we *DO*
handle today in the core VM. We handle it quite well, actually.
The hypervisor does not shrink memory from the top down. It pulls
things out of the middle and shuffles things around. In fact, a NUMA
node's memory isn't even contiguous.
Your code will OOM the machine in this case. I consider the ehea driver
buggy in this regard.
> I would guess these drastic changes would also require changes in base
> kernel.
No, we actually solved those a couple years ago.
> 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.
Yes, that's a real possibility, especially if some other users for it
come forward. We could definitely add something like that to the
generic code. But, you'll have to be convincing that what we have now
is insufficient.
Does this requirement:
"- MRs cover a contiguous virtual memory block (no holes)"
come from the hardware?
Is that *EACH* MR? OR all MRs?
Where does EHEA_BUSMAP_START come from? Is that defined in the
hardware? Have you checked to ensure that no other users might want a
chunk of memory in that area?
Can you query the existing MRs? Not change them in place, but can you
query their contents?
> > 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.
One thing you can guarantee today is that things are contiguous up to
MAX_ORDER_NR_PAGES. That's a symbol that is unlikely to change and is
much more appropriate than using sparsemem. We could also give you a
nice new #define like MINIMUM_CONTIGUOUS_PAGES or something. I think
that's what you really want.
> > > - 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
That's not a question. ;)
Please explain to me why walk_memory_resource() is insufficient for your
needs. I've now pointed it out to you at least 3 times.
> > 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.
What about AIX? Do you know who wrote its driver? Perhaps you should
go ask them.
-- Dave
^ permalink raw reply
* [PATCH] Make sure sockets implement splice_read
From: Rémi Denis-Courmont @ 2008-02-14 16:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Fixes a segmentation fault when trying to splice from a non-TCP socket.
Signed-off-by: Rémi Denis-Courmont <rdenis@simphalempin.com>
---
net/socket.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index 7651de0..b6d35cd 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -701,6 +701,9 @@ static ssize_t sock_splice_read(struct file *file, loff_t *ppos,
{
struct socket *sock = file->private_data;
+ if (unlikely(!sock->ops->splice_read))
+ return -EINVAL;
+
return sock->ops->splice_read(sock, ppos, pipe, len, flags);
}
--
1.5.4.1
^ permalink raw reply related
* Re: [PATCH 2.6.25] igb: fix legacy mode irq issue
From: Kok, Auke @ 2008-02-14 17:24 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: netdev, Auke Kok, David S. Miller, Jeff Garzik
In-Reply-To: <20080214031920.GI856@gospo.usersys.redhat.com>
Andy Gospodarek wrote:
> 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>
looks valid, I'll test and see, thanks Andy
Auke
> ---
>
> 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;
> }
> --
> 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 2/2] add rcu_assign_index() if ever needed
From: Randy Dunlap @ 2008-02-14 17:24 UTC (permalink / raw)
To: paulmck
Cc: linux-kernel, shemminger, davem, netdev, dipankar, ego, herbert,
akpm
In-Reply-To: <20080213220515.GA10642@linux.vnet.ibm.com>
On Wed, 13 Feb 2008 14:05:15 -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
> + * 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.
> + */
s/a index/index/
Along with Gautham's typo fix, you could also make this be passable
kernel-doc notation. :)
See Documentation/kernel-doc-nano-HOWTO.txt for details.
Summary:
The function (or macro) name and short description must be on one line.
This is followed by the parameters, then a "blank" (actually " *") line,
then any (longer) description, notes, etc. So basically:
/**
* rcu_assign_index - assign (publicize) index of a newly initialized array element
* @p: description of @p
* @v: description of @v
*
* This function assigns (publicizes) the index of a newly
* initialized array element that will be dereferenced by RCU
* 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.
> *
---
~Randy
^ permalink raw reply
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Badari Pulavarty @ 2008-02-14 17:36 UTC (permalink / raw)
To: Dave Hansen
Cc: Christoph Raisch, ossthema, apw, Greg KH, Jan-Bernd Themann,
linux-kernel, linuxppc-dev, netdev, Thomas Q Klein, tklein
In-Reply-To: <1203009163.19205.42.camel@nimitz.home.sr71.net>
On Thu, 2008-02-14 at 09:12 -0800, Dave Hansen wrote:
..
> > > > - 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
>
> That's not a question. ;)
>
> Please explain to me why walk_memory_resource() is insufficient for your
> needs. I've now pointed it out to you at least 3 times.
I am not sure what you are trying to do with walk_memory_resource(). The
behavior is different on ppc64. Hotplug memory usage assumes that all
the memory resources (all system memory, not just IOMEM) are represented
in /proc/iomem. Its the case with i386 and ia64. But on ppc64 is
contains ONLY iomem related. Paulus didn't want to export all the system
memory into /proc/iomem on ppc64. So I had to workaround by providing
arch-specific walk_memory_resource() function for ppc64.
Thanks,
Badari
^ permalink raw reply
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Dave Hansen @ 2008-02-14 17:38 UTC (permalink / raw)
To: Badari Pulavarty
Cc: Christoph Raisch, ossthema, apw, Greg KH, Jan-Bernd Themann,
linux-kernel, linuxppc-dev, netdev, Thomas Q Klein, tklein
In-Reply-To: <1203010575.12312.6.camel@dyn9047017100.beaverton.ibm.com>
On Thu, 2008-02-14 at 09:36 -0800, Badari Pulavarty wrote:
>
> I am not sure what you are trying to do with walk_memory_resource().
> The
> behavior is different on ppc64. Hotplug memory usage assumes that all
> the memory resources (all system memory, not just IOMEM) are
> represented
> in /proc/iomem. Its the case with i386 and ia64. But on ppc64 is
> contains ONLY iomem related. Paulus didn't want to export all the
> system
> memory into /proc/iomem on ppc64. So I had to workaround by providing
> arch-specific walk_memory_resource() function for ppc64.
OK, let's use that one.
-- Dave
^ permalink raw reply
* [PATCH 1/2] igb: PCIe devices do not need to unset MANC_ARP_ENA
From: Auke Kok @ 2008-02-14 18:17 UTC (permalink / raw)
To: jeff; +Cc: e1000-devel, netdev
From: David Graham <david.graham@intel.com>
Users reported that ARP's were lost with igb. The problem
is fixed by not enabling this manageability configuration
bit.
None of the release_manageability code is actually needed as the
normal device reset during a shutdown returns everthing to
the right condition automatically.
Signed-off-by: David Graham <david.graham@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/igb/igb_main.c | 28 ----------------------------
1 files changed, 0 insertions(+), 28 deletions(-)
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index d4eb8e2..bff280e 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -606,9 +606,6 @@ static void igb_init_manageability(struct igb_adapter *adapter)
u32 manc2h = rd32(E1000_MANC2H);
u32 manc = rd32(E1000_MANC);
- /* disable hardware interception of ARP */
- manc &= ~(E1000_MANC_ARP_EN);
-
/* enable receiving management packets to the host */
/* this will probably generate destination unreachable messages
* from the host OS, but the packets will be handled on SMBUS */
@@ -623,25 +620,6 @@ static void igb_init_manageability(struct igb_adapter *adapter)
}
}
-static void igb_release_manageability(struct igb_adapter *adapter)
-{
- struct e1000_hw *hw = &adapter->hw;
-
- if (adapter->en_mng_pt) {
- u32 manc = rd32(E1000_MANC);
-
- /* re-enable hardware interception of ARP */
- manc |= E1000_MANC_ARP_EN;
- manc &= ~E1000_MANC_EN_MNG2HOST;
-
- /* don't explicitly have to mess with MANC2H since
- * MANC has an enable disable that gates MANC2H */
-
- /* XXX stop the hardware watchdog ? */
- wr32(E1000_MANC, manc);
- }
-}
-
/**
* igb_configure - configure the hardware for RX and TX
* @adapter: private board structure
@@ -844,7 +822,6 @@ void igb_reset(struct igb_adapter *adapter)
igb_reset_adaptive(&adapter->hw);
adapter->hw.phy.ops.get_phy_info(&adapter->hw);
- igb_release_manageability(adapter);
}
/**
@@ -1178,9 +1155,6 @@ static void __devexit igb_remove(struct pci_dev *pdev)
flush_scheduled_work();
-
- igb_release_manageability(adapter);
-
/* Release control of h/w to f/w. If f/w is AMT enabled, this
* would have already happened in close and is redundant. */
igb_release_hw_control(adapter);
@@ -3955,8 +3929,6 @@ static int igb_suspend(struct pci_dev *pdev, pm_message_t state)
pci_enable_wake(pdev, PCI_D3cold, 0);
}
- igb_release_manageability(adapter);
-
/* make sure adapter isn't asleep if manageability is enabled */
if (adapter->en_mng_pt) {
pci_enable_wake(pdev, PCI_D3hot, 1);
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
^ permalink raw reply related
* [PATCH 2/2] e1000e: PCIe devices do not need to unset MANC_ARP_ENA
From: Auke Kok @ 2008-02-14 18:17 UTC (permalink / raw)
To: jeff; +Cc: netdev, e1000-devel
In-Reply-To: <20080214181712.11070.48342.stgit@localhost.localdomain>
From: David Graham <david.graham@intel.com>
Users reported that ARP's were lost with e1000e. The problem
is fixed by not enabling this manageability configuration
bit.
None of the release_manageability code is actually needed as the
normal device reset during a shutdown returns everthing to
the right condition automatically.
Signed-off-by: David Graham <david.graham@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/e1000e/netdev.c | 26 --------------------------
1 files changed, 0 insertions(+), 26 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index ea4ecc3..3031d6d 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -1055,23 +1055,6 @@ static void e1000_release_hw_control(struct e1000_adapter *adapter)
}
}
-static void e1000_release_manageability(struct e1000_adapter *adapter)
-{
- if (adapter->flags & FLAG_MNG_PT_ENABLED) {
- struct e1000_hw *hw = &adapter->hw;
-
- u32 manc = er32(MANC);
-
- /* re-enable hardware interception of ARP */
- manc |= E1000_MANC_ARP_EN;
- manc &= ~E1000_MANC_EN_MNG2HOST;
-
- /* don't explicitly have to mess with MANC2H since
- * MANC has an enable disable that gates MANC2H */
- ew32(MANC, manc);
- }
-}
-
/**
* @e1000_alloc_ring - allocate memory for a ring structure
**/
@@ -1561,9 +1544,6 @@ static void e1000_init_manageability(struct e1000_adapter *adapter)
manc = er32(MANC);
- /* disable hardware interception of ARP */
- manc &= ~(E1000_MANC_ARP_EN);
-
/* enable receiving management packets to the host. this will probably
* generate destination unreachable messages from the host OS, but
* the packets will be handled on SMBUS */
@@ -2140,8 +2120,6 @@ void e1000e_reset(struct e1000_adapter *adapter)
phy_data &= ~IGP02E1000_PM_SPD;
e1e_wphy(hw, IGP02E1000_PHY_POWER_MGMT, phy_data);
}
-
- e1000_release_manageability(adapter);
}
int e1000e_up(struct e1000_adapter *adapter)
@@ -3487,8 +3465,6 @@ static int e1000_suspend(struct pci_dev *pdev, pm_message_t state)
pci_enable_wake(pdev, PCI_D3cold, 0);
}
- e1000_release_manageability(adapter);
-
/* make sure adapter isn't asleep if manageability is enabled */
if (adapter->flags & FLAG_MNG_PT_ENABLED) {
pci_enable_wake(pdev, PCI_D3hot, 1);
@@ -4054,8 +4030,6 @@ static void __devexit e1000_remove(struct pci_dev *pdev)
flush_scheduled_work();
- e1000_release_manageability(adapter);
-
/* Release control of h/w to f/w. If f/w is AMT enabled, this
* would have already happened in close and is redundant. */
e1000_release_hw_control(adapter);
^ permalink raw reply related
* Re: [Bugme-new] [Bug 9990] New: tg3: eth0: The system may be re-ordering memory-mapped I/O cycles
From: Andrew Morton @ 2008-02-14 18:24 UTC (permalink / raw)
To: Matt Carlson, Michael Chan; +Cc: bugme-daemon, netdev, ralf.hildebrandt
In-Reply-To: <bug-9990-10286@http.bugzilla.kernel.org/>
On Thu, 14 Feb 2008 01:59:12 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9990
>
> Summary: tg3: eth0: The system may be re-ordering memory-mapped
> I/O cycles
> Product: Drivers
> Version: 2.5
> KernelVersion: 2.6.24-git18
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: jgarzik@pobox.com
> ReportedBy: ralf.hildebrandt@charite.de
>
>
> Latest working kernel version: 2.6.24
> Earliest failing kernel version: 2.6.24-git18
> Distribution: Debian/testing
> Hardware Environment:
> Software Environment:
> Problem Description:
>
> Feb 11 13:11:52 www kernel: [ 12.015569] tg3: eth0: Link is up at 100 Mbps,
> full duplex.
> Feb 11 13:11:52 www kernel: [ 12.015633] tg3: eth0: Flow control is on for TX
> and on for RX.
> Feb 11 13:33:44 www kernel: [ 1328.538204] tg3: eth0: The system may be
> re-ordering memory-mapped I/O cycles to the network
> device, attempting to recover. Please report the problem to the driver
> maintainer and include system chipset information.
> Feb 11 13:33:44 www kernel: [ 1328.667255] tg3: eth0: Link is down.
> Feb 11 13:33:46 www kernel: [ 1330.560734] tg3: eth0: Link is up at 100 Mbps,
> full duplex.
> Feb 11 13:33:46 www kernel: [ 1330.560734] tg3: eth0: Flow control is on for TX
> and on for RX.
>
> After that, the machine rebooted (panic?)
>
> Feb 11 13:35:14 www kernel: klogd 1.5.0#1.1, log source = /proc/kmsg started.
>
> lspci -vvv info:
> 02:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit
> Ethernet (rev 10)
> Subsystem: Compaq Computer Corporation NC7782 Gigabit Server Adapter
> (PCI-X, 10,100,1000-T)
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
> Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 64 (16000ns min), Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 19
> Region 0: Memory at fdf70000 (64-bit, non-prefetchable) [size=64K]
> [virtual] Expansion ROM at 88140000 [disabled] [size=64K]
> Capabilities: [40] PCI-X non-bridge device
> Command: DPERE- ERO- RBC=2048 OST=1
> Status: Dev=02:02.0 64bit+ 133MHz+ SCD- USC- DC=simple
> DMMRBC=2048 DMOST=1 DMCRS=16 RSCEM- 266MHz- 533MHz-
> Capabilities: [48] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot+,D3cold+)
> Status: D0 PME-Enable+ DSel=0 DScale=1 PME-
> Capabilities: [50] Vital Product Data <?>
> Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3
> Enable-
> Address: fd7ffd6fdf7deeb8 Data: bdfd
> Kernel driver in use: tg3
> Kernel modules: tg3
>
> 02:02.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit
> Ethernet (rev 10)
> Subsystem: Compaq Computer Corporation NC7782 Gigabit Server Adapter
> (PCI-X, 10,100,1000-T)
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
> Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 64 (16000ns min), Cache Line Size: 64 bytes
> Interrupt: pin B routed to IRQ 20
> Region 0: Memory at fdf60000 (64-bit, non-prefetchable) [size=64K]
> Capabilities: [40] PCI-X non-bridge device
> Command: DPERE- ERO+ RBC=512 OST=1
> Status: Dev=02:02.1 64bit+ 133MHz+ SCD- USC- DC=simple
> DMMRBC=2048 DMOST=1 DMCRS=16 RSCEM- 266MHz- 533MHz-
> Capabilities: [48] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=1 PME-
> Capabilities: [50] Vital Product Data <?>
> Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3
> Enable-
> Address: f73feeefffffe7f8 Data: 9bcd
> Kernel driver in use: tg3
> Kernel modules: tg3
>
>
> Steps to reproduce:
>
>
^ permalink raw reply
* Re: [PATCH 2/2] add rcu_assign_index() if ever needed
From: Paul E. McKenney @ 2008-02-14 18:48 UTC (permalink / raw)
To: Randy Dunlap
Cc: linux-kernel, shemminger, davem, netdev, dipankar, ego, herbert,
akpm
In-Reply-To: <20080214092427.960d1f67.randy.dunlap@oracle.com>
On Thu, Feb 14, 2008 at 09:24:27AM -0800, Randy Dunlap wrote:
> On Wed, 13 Feb 2008 14:05:15 -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
> > + * 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.
> > + */
>
> s/a index/index/
>
> Along with Gautham's typo fix, you could also make this be passable
> kernel-doc notation. :)
Guess I should do the same for rcu_assign_pointer() and probably several
others as well... Good catch!!!
Thanx, Paul
> See Documentation/kernel-doc-nano-HOWTO.txt for details.
>
> Summary:
> The function (or macro) name and short description must be on one line.
> This is followed by the parameters, then a "blank" (actually " *") line,
> then any (longer) description, notes, etc. So basically:
>
> /**
> * rcu_assign_index - assign (publicize) index of a newly initialized array element
> * @p: description of @p
> * @v: description of @v
> *
> * This function assigns (publicizes) the index of a newly
> * initialized array element that will be dereferenced by RCU
> * 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.
> > *
>
> ---
> ~Randy
^ permalink raw reply
* Re: [Bugme-new] [Bug 9990] New: tg3: eth0: The system may be re-ordering memory-mapped I/O cycles
From: Andy Gospodarek @ 2008-02-14 18:56 UTC (permalink / raw)
To: Andrew Morton
Cc: Matt Carlson, Michael Chan, bugme-daemon, netdev,
ralf.hildebrandt
In-Reply-To: <20080214102425.0fc8e3c1.akpm@linux-foundation.org>
On Thu, Feb 14, 2008 at 10:24:25AM -0800, Andrew Morton wrote:
> On Thu, 14 Feb 2008 01:59:12 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=9990
> >
> > Summary: tg3: eth0: The system may be re-ordering memory-mapped
> > I/O cycles
> > Product: Drivers
> > Version: 2.5
> > KernelVersion: 2.6.24-git18
> > Platform: All
> > OS/Version: Linux
> > Tree: Mainline
> > Status: NEW
> > Severity: normal
> > Priority: P1
> > Component: Network
> > AssignedTo: jgarzik@pobox.com
> > ReportedBy: ralf.hildebrandt@charite.de
> >
> >
> > Latest working kernel version: 2.6.24
> > Earliest failing kernel version: 2.6.24-git18
> > Distribution: Debian/testing
> > Hardware Environment:
> > Software Environment:
> > Problem Description:
> >
> > Feb 11 13:11:52 www kernel: [ 12.015569] tg3: eth0: Link is up at 100 Mbps,
> > full duplex.
> > Feb 11 13:11:52 www kernel: [ 12.015633] tg3: eth0: Flow control is on for TX
> > and on for RX.
> > Feb 11 13:33:44 www kernel: [ 1328.538204] tg3: eth0: The system may be
> > re-ordering memory-mapped I/O cycles to the network
> > device, attempting to recover. Please report the problem to the driver
> > maintainer and include system chipset information.
> > Feb 11 13:33:44 www kernel: [ 1328.667255] tg3: eth0: Link is down.
> > Feb 11 13:33:46 www kernel: [ 1330.560734] tg3: eth0: Link is up at 100 Mbps,
> > full duplex.
> > Feb 11 13:33:46 www kernel: [ 1330.560734] tg3: eth0: Flow control is on for TX
> > and on for RX.
> >
> > After that, the machine rebooted (panic?)
> >
> > Feb 11 13:35:14 www kernel: klogd 1.5.0#1.1, log source = /proc/kmsg started.
> >
> > lspci -vvv info:
> > 02:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit
> > Ethernet (rev 10)
> > Subsystem: Compaq Computer Corporation NC7782 Gigabit Server Adapter
> > (PCI-X, 10,100,1000-T)
> > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
> > Stepping- SERR+ FastB2B- DisINTx-
> > Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> > <TAbort- <MAbort- >SERR- <PERR- INTx-
> > Latency: 64 (16000ns min), Cache Line Size: 64 bytes
> > Interrupt: pin A routed to IRQ 19
> > Region 0: Memory at fdf70000 (64-bit, non-prefetchable) [size=64K]
> > [virtual] Expansion ROM at 88140000 [disabled] [size=64K]
> > Capabilities: [40] PCI-X non-bridge device
> > Command: DPERE- ERO- RBC=2048 OST=1
> > Status: Dev=02:02.0 64bit+ 133MHz+ SCD- USC- DC=simple
> > DMMRBC=2048 DMOST=1 DMCRS=16 RSCEM- 266MHz- 533MHz-
> > Capabilities: [48] Power Management version 2
> > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> > PME(D0-,D1-,D2-,D3hot+,D3cold+)
> > Status: D0 PME-Enable+ DSel=0 DScale=1 PME-
> > Capabilities: [50] Vital Product Data <?>
> > Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3
> > Enable-
> > Address: fd7ffd6fdf7deeb8 Data: bdfd
> > Kernel driver in use: tg3
> > Kernel modules: tg3
> >
> > 02:02.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit
> > Ethernet (rev 10)
> > Subsystem: Compaq Computer Corporation NC7782 Gigabit Server Adapter
> > (PCI-X, 10,100,1000-T)
> > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
> > Stepping- SERR+ FastB2B- DisINTx-
> > Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> > <TAbort- <MAbort- >SERR- <PERR- INTx-
> > Latency: 64 (16000ns min), Cache Line Size: 64 bytes
> > Interrupt: pin B routed to IRQ 20
> > Region 0: Memory at fdf60000 (64-bit, non-prefetchable) [size=64K]
> > Capabilities: [40] PCI-X non-bridge device
> > Command: DPERE- ERO+ RBC=512 OST=1
> > Status: Dev=02:02.1 64bit+ 133MHz+ SCD- USC- DC=simple
> > DMMRBC=2048 DMOST=1 DMCRS=16 RSCEM- 266MHz- 533MHz-
> > Capabilities: [48] Power Management version 2
> > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> > PME(D0-,D1-,D2-,D3hot+,D3cold+)
> > Status: D0 PME-Enable- DSel=0 DScale=1 PME-
> > Capabilities: [50] Vital Product Data <?>
> > Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3
> > Enable-
> > Address: f73feeefffffe7f8 Data: 9bcd
> > Kernel driver in use: tg3
> > Kernel modules: tg3
> >
> >
> > Steps to reproduce:
> >
> >
That should be a simple matter of adding the right pci-ids to
tg3_get_invariants -- hopefully Ralf will respond and we can get that
knocked out quickly.
^ permalink raw reply
* Re: [RFC, PATCH]: Pass link level header from/to PPP interface
From: Urs Thuermann @ 2008-02-14 19:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20080213.145355.57741113.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> Can tcpdump and libpcap already handle PPP properly?
Yes, with the (admittedly non-serious) limitation, that both, tcpdump
and tcpdump -e don't show the PPP header. I don't remember how
tcpdump behaved on BSD in this respect (so many years ago), but I
think libpcap will use the DLT_PPP link type on BSD, which has the PPP
header.
urs
^ permalink raw reply
* Re: [PATCH] plusb.c patched to support Belkin F5U258 USB host-to-host cable
From: David Brownell @ 2008-02-14 21:20 UTC (permalink / raw)
To: tony_gibbs; +Cc: NETDEV mailing list, Linux USB mailing list
In-Reply-To: <200802141557_MC3-1-FBB3-3DA7@compuserve.com>
On Thursday 14 February 2008, tony_gibbs wrote:
> I have tried to make the changes I have been working on and testing with
> your help into a patch as attached.
>
> Please let me know what you think of it.
It arrived line wrapped, and turned on debug options that
should stay off by default ... it couldn't merge, on those
bases alone. Also, "PL-25A1hack" isn't a product name. ;)
Did you get this to pass data back and forth yet? The last
report I had from you was that it wouldn't pass data. The
Prolific hardware tends to enter that mode after a while.
(Maybe there's documentation unseen by any Linux developer,
saying how to make those chips actually work...) But you
reported that they didn't seem to work even when freshly
plugged in.
- Dave
^ permalink raw reply
* Re: [Bugme-new] [Bug 9990] New: tg3: eth0: The system may be re-ordering memory-mapped I/O cycles
From: Michael Chan @ 2008-02-14 21:25 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Andrew Morton, Matt Carlson, bugme-daemon, netdev,
ralf.hildebrandt
In-Reply-To: <20080214185627.GK856@gospo.usersys.redhat.com>
On Thu, 2008-02-14 at 13:56 -0500, Andy Gospodarek wrote:
> On Thu, Feb 14, 2008 at 10:24:25AM -0800, Andrew Morton wrote:
> > On Thu, 14 Feb 2008 01:59:12 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote:
> >
> > > http://bugzilla.kernel.org/show_bug.cgi?id=9990
> > >
> > > Summary: tg3: eth0: The system may be re-ordering memory-mapped
> > > I/O cycles
> > > Product: Drivers
> > > Version: 2.5
> > > KernelVersion: 2.6.24-git18
> > > Platform: All
> > > OS/Version: Linux
> > > Tree: Mainline
> > > Status: NEW
> > > Severity: normal
> > > Priority: P1
> > > Component: Network
> > > AssignedTo: jgarzik@pobox.com
> > > ReportedBy: ralf.hildebrandt@charite.de
> > >
> > >
>
> That should be a simple matter of adding the right pci-ids to
> tg3_get_invariants -- hopefully Ralf will respond and we can get that
> knocked out quickly.
>
>
It doesn't look like it was re-ordered IO. If it was, it should have
self-recovered without hitting the BUG().
One possibility is that the nr_frags in the SKB got corrupted before the
TX SKB was freed. The driver relies on the nr_frags in the SKB to find
the packet boundaries in the TX ring. If it cannot find the packet
boundaries, it will exhibit the same symptom as re-ordered IO, only that
it cannot be self-recovered.
Ralf, please try this debug patch with the same traffic condition you
ran before. This patch stores the nr_frags when transmitting an SKB.
During tx completion, it will compare the stored nr_frags with the one
in the SKB and will print out something in dmesg if they don't match.
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index db606b6..73f1ddd 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -3324,12 +3324,20 @@ static void tg3_tx(struct tg3 *tp)
struct tx_ring_info *ri = &tp->tx_buffers[sw_idx];
struct sk_buff *skb = ri->skb;
int i, tx_bug = 0;
+ unsigned short nr_frags = ri->nr_frags;
if (unlikely(skb == NULL)) {
tg3_tx_recover(tp);
return;
}
+ if (nr_frags != skb_shinfo(skb)->nr_frags) {
+ printk(KERN_ALERT "tg3: %s: Tx skb->nr_frags corrupted "
+ "before skb is freed. Expected nr_frags %d, "
+ "corrupted nr_frags %d\n", tp->dev->name,
+ nr_frags, skb_shinfo(skb)->nr_frags);
+ }
+
pci_unmap_single(tp->pdev,
pci_unmap_addr(ri, mapping),
skb_headlen(skb),
@@ -3339,7 +3347,7 @@ static void tg3_tx(struct tg3 *tp)
sw_idx = NEXT_TX(sw_idx);
- for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
+ for (i = 0; i < nr_frags; i++) {
ri = &tp->tx_buffers[sw_idx];
if (unlikely(ri->skb != NULL || sw_idx == hw_idx))
tx_bug = 1;
@@ -4105,6 +4113,7 @@ static int tigon3_dma_hwbug_workaround(struct tg3 *tp, struct sk_buff *skb,
len, PCI_DMA_TODEVICE);
if (i == 0) {
tp->tx_buffers[entry].skb = new_skb;
+ tp->tx_buffers[entry].nr_frags = 0;
pci_unmap_addr_set(&tp->tx_buffers[entry], mapping, new_addr);
} else {
tp->tx_buffers[entry].skb = NULL;
@@ -4211,6 +4220,7 @@ static int tg3_start_xmit(struct sk_buff *skb, struct net_device *dev)
mapping = pci_map_single(tp->pdev, skb->data, len, PCI_DMA_TODEVICE);
tp->tx_buffers[entry].skb = skb;
+ tp->tx_buffers[entry].nr_frags = skb_shinfo(skb)->nr_frags;
pci_unmap_addr_set(&tp->tx_buffers[entry], mapping, mapping);
tg3_set_txd(tp, entry, mapping, len, base_flags,
@@ -4388,6 +4398,7 @@ static int tg3_start_xmit_dma_bug(struct sk_buff *skb, struct net_device *dev)
mapping = pci_map_single(tp->pdev, skb->data, len, PCI_DMA_TODEVICE);
tp->tx_buffers[entry].skb = skb;
+ tp->tx_buffers[entry].nr_frags = skb_shinfo(skb)->nr_frags;
pci_unmap_addr_set(&tp->tx_buffers[entry], mapping, mapping);
would_hit_hwbug = 0;
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index 3938eb3..d4a3aca 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -2098,6 +2098,7 @@ struct tx_ring_info {
struct sk_buff *skb;
DECLARE_PCI_UNMAP_ADDR(mapping)
u32 prev_vlan_tag;
+ unsigned short nr_frags;
};
struct tg3_config_info {
^ permalink raw reply related
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