* [PATCH net-next] tcp: rename tcp_skb_cb flags
From: Eric Dumazet @ 2011-09-27 9:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110927.022025.1306291417181821045.davem@davemloft.net>
Rename struct tcp_skb_cb "flags" to "tcp_flags" to ease code review and
maintenance.
Its content is a combination of FIN/SYN/RST/PSH/ACK/URG/ECE/CWR flags
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/tcp.h | 2 -
net/ipv4/tcp.c | 8 ++---
net/ipv4/tcp_input.c | 4 +-
net/ipv4/tcp_output.c | 63 ++++++++++++++++++++--------------------
4 files changed, 39 insertions(+), 38 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 28a9997..0113d30 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -636,7 +636,7 @@ struct tcp_skb_cb {
__u32 seq; /* Starting sequence number */
__u32 end_seq; /* SEQ + FIN + SYN + datalen */
__u32 when; /* used to compute rtt's */
- __u8 flags; /* TCP header flags. */
+ __u8 tcp_flags; /* TCP header flags. (tcp[13]) */
__u8 sacked; /* State flags for SACK/FACK. */
#define TCPCB_SACKED_ACKED 0x01 /* SKB ACK'd by a SACK block */
#define TCPCB_SACKED_RETRANS 0x02 /* SKB retransmitted */
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index cc0d5de..131c45f 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -524,7 +524,7 @@ EXPORT_SYMBOL(tcp_ioctl);
static inline void tcp_mark_push(struct tcp_sock *tp, struct sk_buff *skb)
{
- TCP_SKB_CB(skb)->flags |= TCPHDR_PSH;
+ TCP_SKB_CB(skb)->tcp_flags |= TCPHDR_PSH;
tp->pushed_seq = tp->write_seq;
}
@@ -540,7 +540,7 @@ static inline void skb_entail(struct sock *sk, struct sk_buff *skb)
skb->csum = 0;
tcb->seq = tcb->end_seq = tp->write_seq;
- tcb->flags = TCPHDR_ACK;
+ tcb->tcp_flags = TCPHDR_ACK;
tcb->sacked = 0;
skb_header_release(skb);
tcp_add_write_queue_tail(sk, skb);
@@ -830,7 +830,7 @@ new_segment:
skb_shinfo(skb)->gso_segs = 0;
if (!copied)
- TCP_SKB_CB(skb)->flags &= ~TCPHDR_PSH;
+ TCP_SKB_CB(skb)->tcp_flags &= ~TCPHDR_PSH;
copied += copy;
poffset += copy;
@@ -1074,7 +1074,7 @@ new_segment:
}
if (!copied)
- TCP_SKB_CB(skb)->flags &= ~TCPHDR_PSH;
+ TCP_SKB_CB(skb)->tcp_flags &= ~TCPHDR_PSH;
tp->write_seq += copy;
TCP_SKB_CB(skb)->end_seq += copy;
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 7008fcc..143221e 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1449,7 +1449,7 @@ static int tcp_shifted_skb(struct sock *sk, struct sk_buff *skb,
tp->lost_cnt_hint -= tcp_skb_pcount(prev);
}
- TCP_SKB_CB(skb)->flags |= TCP_SKB_CB(prev)->flags;
+ TCP_SKB_CB(skb)->tcp_flags |= TCP_SKB_CB(prev)->tcp_flags;
if (skb == tcp_highest_sack(sk))
tcp_advance_highest_sack(sk, skb);
@@ -3348,7 +3348,7 @@ static int tcp_clean_rtx_queue(struct sock *sk, int prior_fackets,
* connection startup slow start one packet too
* quickly. This is severely frowned upon behavior.
*/
- if (!(scb->flags & TCPHDR_SYN)) {
+ if (!(scb->tcp_flags & TCPHDR_SYN)) {
flag |= FLAG_DATA_ACKED;
} else {
flag |= FLAG_SYN_ACKED;
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 081dcd6..dde6b57 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -297,9 +297,9 @@ static u16 tcp_select_window(struct sock *sk)
/* Packet ECN state for a SYN-ACK */
static inline void TCP_ECN_send_synack(struct tcp_sock *tp, struct sk_buff *skb)
{
- TCP_SKB_CB(skb)->flags &= ~TCPHDR_CWR;
+ TCP_SKB_CB(skb)->tcp_flags &= ~TCPHDR_CWR;
if (!(tp->ecn_flags & TCP_ECN_OK))
- TCP_SKB_CB(skb)->flags &= ~TCPHDR_ECE;
+ TCP_SKB_CB(skb)->tcp_flags &= ~TCPHDR_ECE;
}
/* Packet ECN state for a SYN. */
@@ -309,7 +309,7 @@ static inline void TCP_ECN_send_syn(struct sock *sk, struct sk_buff *skb)
tp->ecn_flags = 0;
if (sysctl_tcp_ecn == 1) {
- TCP_SKB_CB(skb)->flags |= TCPHDR_ECE | TCPHDR_CWR;
+ TCP_SKB_CB(skb)->tcp_flags |= TCPHDR_ECE | TCPHDR_CWR;
tp->ecn_flags = TCP_ECN_OK;
}
}
@@ -356,7 +356,7 @@ static void tcp_init_nondata_skb(struct sk_buff *skb, u32 seq, u8 flags)
skb->ip_summed = CHECKSUM_PARTIAL;
skb->csum = 0;
- TCP_SKB_CB(skb)->flags = flags;
+ TCP_SKB_CB(skb)->tcp_flags = flags;
TCP_SKB_CB(skb)->sacked = 0;
skb_shinfo(skb)->gso_segs = 1;
@@ -826,7 +826,7 @@ static int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb, int clone_it,
tcb = TCP_SKB_CB(skb);
memset(&opts, 0, sizeof(opts));
- if (unlikely(tcb->flags & TCPHDR_SYN))
+ if (unlikely(tcb->tcp_flags & TCPHDR_SYN))
tcp_options_size = tcp_syn_options(sk, skb, &opts, &md5);
else
tcp_options_size = tcp_established_options(sk, skb, &opts,
@@ -850,9 +850,9 @@ static int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb, int clone_it,
th->seq = htonl(tcb->seq);
th->ack_seq = htonl(tp->rcv_nxt);
*(((__be16 *)th) + 6) = htons(((tcp_header_size >> 2) << 12) |
- tcb->flags);
+ tcb->tcp_flags);
- if (unlikely(tcb->flags & TCPHDR_SYN)) {
+ if (unlikely(tcb->tcp_flags & TCPHDR_SYN)) {
/* RFC1323: The window in SYN & SYN/ACK segments
* is never scaled.
*/
@@ -875,7 +875,7 @@ static int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb, int clone_it,
}
tcp_options_write((__be32 *)(th + 1), tp, &opts);
- if (likely((tcb->flags & TCPHDR_SYN) == 0))
+ if (likely((tcb->tcp_flags & TCPHDR_SYN) == 0))
TCP_ECN_send(sk, skb, tcp_header_size);
#ifdef CONFIG_TCP_MD5SIG
@@ -889,7 +889,7 @@ static int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb, int clone_it,
icsk->icsk_af_ops->send_check(sk, skb);
- if (likely(tcb->flags & TCPHDR_ACK))
+ if (likely(tcb->tcp_flags & TCPHDR_ACK))
tcp_event_ack_sent(sk, tcp_skb_pcount(skb));
if (skb->len != tcp_header_size)
@@ -1032,9 +1032,9 @@ int tcp_fragment(struct sock *sk, struct sk_buff *skb, u32 len,
TCP_SKB_CB(skb)->end_seq = TCP_SKB_CB(buff)->seq;
/* PSH and FIN should only be set in the second packet. */
- flags = TCP_SKB_CB(skb)->flags;
- TCP_SKB_CB(skb)->flags = flags & ~(TCPHDR_FIN | TCPHDR_PSH);
- TCP_SKB_CB(buff)->flags = flags;
+ flags = TCP_SKB_CB(skb)->tcp_flags;
+ TCP_SKB_CB(skb)->tcp_flags = flags & ~(TCPHDR_FIN | TCPHDR_PSH);
+ TCP_SKB_CB(buff)->tcp_flags = flags;
TCP_SKB_CB(buff)->sacked = TCP_SKB_CB(skb)->sacked;
if (!skb_shinfo(skb)->nr_frags && skb->ip_summed != CHECKSUM_PARTIAL) {
@@ -1340,7 +1340,8 @@ static inline unsigned int tcp_cwnd_test(struct tcp_sock *tp,
u32 in_flight, cwnd;
/* Don't be strict about the congestion window for the final FIN. */
- if ((TCP_SKB_CB(skb)->flags & TCPHDR_FIN) && tcp_skb_pcount(skb) == 1)
+ if ((TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN) &&
+ tcp_skb_pcount(skb) == 1)
return 1;
in_flight = tcp_packets_in_flight(tp);
@@ -1409,7 +1410,7 @@ static inline int tcp_nagle_test(struct tcp_sock *tp, struct sk_buff *skb,
* Nagle can be ignored during F-RTO too (see RFC4138).
*/
if (tcp_urg_mode(tp) || (tp->frto_counter == 2) ||
- (TCP_SKB_CB(skb)->flags & TCPHDR_FIN))
+ (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN))
return 1;
if (!tcp_nagle_check(tp, skb, cur_mss, nonagle))
@@ -1497,9 +1498,9 @@ static int tso_fragment(struct sock *sk, struct sk_buff *skb, unsigned int len,
TCP_SKB_CB(skb)->end_seq = TCP_SKB_CB(buff)->seq;
/* PSH and FIN should only be set in the second packet. */
- flags = TCP_SKB_CB(skb)->flags;
- TCP_SKB_CB(skb)->flags = flags & ~(TCPHDR_FIN | TCPHDR_PSH);
- TCP_SKB_CB(buff)->flags = flags;
+ flags = TCP_SKB_CB(skb)->tcp_flags;
+ TCP_SKB_CB(skb)->tcp_flags = flags & ~(TCPHDR_FIN | TCPHDR_PSH);
+ TCP_SKB_CB(buff)->tcp_flags = flags;
/* This packet was never sent out yet, so no SACK bits. */
TCP_SKB_CB(buff)->sacked = 0;
@@ -1530,7 +1531,7 @@ static int tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb)
u32 send_win, cong_win, limit, in_flight;
int win_divisor;
- if (TCP_SKB_CB(skb)->flags & TCPHDR_FIN)
+ if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN)
goto send_now;
if (icsk->icsk_ca_state != TCP_CA_Open)
@@ -1657,7 +1658,7 @@ static int tcp_mtu_probe(struct sock *sk)
TCP_SKB_CB(nskb)->seq = TCP_SKB_CB(skb)->seq;
TCP_SKB_CB(nskb)->end_seq = TCP_SKB_CB(skb)->seq + probe_size;
- TCP_SKB_CB(nskb)->flags = TCPHDR_ACK;
+ TCP_SKB_CB(nskb)->tcp_flags = TCPHDR_ACK;
TCP_SKB_CB(nskb)->sacked = 0;
nskb->csum = 0;
nskb->ip_summed = skb->ip_summed;
@@ -1677,11 +1678,11 @@ static int tcp_mtu_probe(struct sock *sk)
if (skb->len <= copy) {
/* We've eaten all the data from this skb.
* Throw it away. */
- TCP_SKB_CB(nskb)->flags |= TCP_SKB_CB(skb)->flags;
+ TCP_SKB_CB(nskb)->tcp_flags |= TCP_SKB_CB(skb)->tcp_flags;
tcp_unlink_write_queue(skb, sk);
sk_wmem_free_skb(sk, skb);
} else {
- TCP_SKB_CB(nskb)->flags |= TCP_SKB_CB(skb)->flags &
+ TCP_SKB_CB(nskb)->tcp_flags |= TCP_SKB_CB(skb)->tcp_flags &
~(TCPHDR_FIN|TCPHDR_PSH);
if (!skb_shinfo(skb)->nr_frags) {
skb_pull(skb, copy);
@@ -1987,7 +1988,7 @@ static void tcp_collapse_retrans(struct sock *sk, struct sk_buff *skb)
TCP_SKB_CB(skb)->end_seq = TCP_SKB_CB(next_skb)->end_seq;
/* Merge over control information. This moves PSH/FIN etc. over */
- TCP_SKB_CB(skb)->flags |= TCP_SKB_CB(next_skb)->flags;
+ TCP_SKB_CB(skb)->tcp_flags |= TCP_SKB_CB(next_skb)->tcp_flags;
/* All done, get rid of second SKB and account for it so
* packet counting does not break.
@@ -2035,7 +2036,7 @@ static void tcp_retrans_try_collapse(struct sock *sk, struct sk_buff *to,
if (!sysctl_tcp_retrans_collapse)
return;
- if (TCP_SKB_CB(skb)->flags & TCPHDR_SYN)
+ if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_SYN)
return;
tcp_for_write_queue_from_safe(skb, tmp, sk) {
@@ -2127,12 +2128,12 @@ int tcp_retransmit_skb(struct sock *sk, struct sk_buff *skb)
* since it is cheap to do so and saves bytes on the network.
*/
if (skb->len > 0 &&
- (TCP_SKB_CB(skb)->flags & TCPHDR_FIN) &&
+ (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN) &&
tp->snd_una == (TCP_SKB_CB(skb)->end_seq - 1)) {
if (!pskb_trim(skb, 0)) {
/* Reuse, even though it does some unnecessary work */
tcp_init_nondata_skb(skb, TCP_SKB_CB(skb)->end_seq - 1,
- TCP_SKB_CB(skb)->flags);
+ TCP_SKB_CB(skb)->tcp_flags);
skb->ip_summed = CHECKSUM_NONE;
}
}
@@ -2322,7 +2323,7 @@ void tcp_send_fin(struct sock *sk)
mss_now = tcp_current_mss(sk);
if (tcp_send_head(sk) != NULL) {
- TCP_SKB_CB(skb)->flags |= TCPHDR_FIN;
+ TCP_SKB_CB(skb)->tcp_flags |= TCPHDR_FIN;
TCP_SKB_CB(skb)->end_seq++;
tp->write_seq++;
} else {
@@ -2384,11 +2385,11 @@ int tcp_send_synack(struct sock *sk)
struct sk_buff *skb;
skb = tcp_write_queue_head(sk);
- if (skb == NULL || !(TCP_SKB_CB(skb)->flags & TCPHDR_SYN)) {
+ if (skb == NULL || !(TCP_SKB_CB(skb)->tcp_flags & TCPHDR_SYN)) {
printk(KERN_DEBUG "tcp_send_synack: wrong queue state\n");
return -EFAULT;
}
- if (!(TCP_SKB_CB(skb)->flags & TCPHDR_ACK)) {
+ if (!(TCP_SKB_CB(skb)->tcp_flags & TCPHDR_ACK)) {
if (skb_cloned(skb)) {
struct sk_buff *nskb = skb_copy(skb, GFP_ATOMIC);
if (nskb == NULL)
@@ -2402,7 +2403,7 @@ int tcp_send_synack(struct sock *sk)
skb = nskb;
}
- TCP_SKB_CB(skb)->flags |= TCPHDR_ACK;
+ TCP_SKB_CB(skb)->tcp_flags |= TCPHDR_ACK;
TCP_ECN_send_synack(tcp_sk(sk), skb);
}
TCP_SKB_CB(skb)->when = tcp_time_stamp;
@@ -2799,13 +2800,13 @@ int tcp_write_wakeup(struct sock *sk)
if (seg_size < TCP_SKB_CB(skb)->end_seq - TCP_SKB_CB(skb)->seq ||
skb->len > mss) {
seg_size = min(seg_size, mss);
- TCP_SKB_CB(skb)->flags |= TCPHDR_PSH;
+ TCP_SKB_CB(skb)->tcp_flags |= TCPHDR_PSH;
if (tcp_fragment(sk, skb, seg_size, mss))
return -1;
} else if (!tcp_skb_pcount(skb))
tcp_set_skb_tso_segs(sk, skb, mss);
- TCP_SKB_CB(skb)->flags |= TCPHDR_PSH;
+ TCP_SKB_CB(skb)->tcp_flags |= TCPHDR_PSH;
TCP_SKB_CB(skb)->when = tcp_time_stamp;
err = tcp_transmit_skb(sk, skb, 1, GFP_ATOMIC);
if (!err)
^ permalink raw reply related
* Re: [PATCH net-next] tcp: unalias tcp_skb_cb flags and ip_dsfield
From: Eric Dumazet @ 2011-09-27 9:40 UTC (permalink / raw)
To: christoph.paasch; +Cc: David Miller, netdev, hkchu, ilpo.jarvinen, jhs
In-Reply-To: <201109271228.44232.christoph.paasch@uclouvain.be>
Le mardi 27 septembre 2011 à 12:28 +0300, Christoph Paasch a écrit :
>
> Ok, I understand.
> Thanks for the info. I didn't knew this...
>
> It's good news...
> Maybe we win now a little bit of space in MultiPath TCP by rearranging our
> fields... :-)
To ease your task, I suggest you take a look at pahole
http://lwn.net/Articles/365844/
^ permalink raw reply
* Re: [PATCH net-next] tcp: unalias tcp_skb_cb flags and ip_dsfield
From: Christoph Paasch @ 2011-09-27 9:28 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, hkchu, ilpo.jarvinen, jhs
In-Reply-To: <1317115409.2541.6.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Eric,
On Tuesday 27 September 2011 wrote Eric Dumazet:
> Le mardi 27 septembre 2011 à 11:38 +0300, Christoph Paasch a écrit :
> > On Tuesday 27 September 2011 wrote David Miller:
> > This two-byte hole, is it because "flags" and "sacked" are both __u8 and
> > fields are aligned to 32-bit ?
>
> Not exactly.
>
> Reason for the hole is the following :
>
> struct whatever {
> u8 first;
> u8 second;
> u32 third;
> };
>
> "third" field has an alignement requirement of 4 bytes on most arches.
>
> Compiler inserts a 2 bytes hole before "third" to respect this
> requirement.
>
> There is no hole between "first" and "second", since second has no
> alignment requirement.
>
> sizeof(struct whatever) = 8
Ok, I understand.
Thanks for the info. I didn't knew this...
It's good news...
Maybe we win now a little bit of space in MultiPath TCP by rearranging our
fields... :-)
Cheers,
Christoph
--
Christoph Paasch
PhD Student
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
Université Catholique de Louvain
www.rollerbulls.be
--
^ permalink raw reply
* Re: [PATCH net-next] tcp: unalias tcp_skb_cb flags and ip_dsfield
From: Eric Dumazet @ 2011-09-27 9:23 UTC (permalink / raw)
To: christoph.paasch; +Cc: David Miller, netdev, hkchu, ilpo.jarvinen, jhs
In-Reply-To: <201109271138.00318.christoph.paasch@uclouvain.be>
Le mardi 27 septembre 2011 à 11:38 +0300, Christoph Paasch a écrit :
> On Tuesday 27 September 2011 wrote David Miller:
> > From: Christoph Paasch <christoph.paasch@uclouvain.be>
> > Date: Tue, 27 Sep 2011 10:37:38 +0300
> >
> > > However, (as far as I can see) before Eric's change it was 42 bytes long
> > > and now it became 43 bytes.
> >
> > Then, I suggest that you go buy a pair of glasses. :-)
>
> Yeah, maybe it's time to... ;-)
>
> This two-byte hole, is it because "flags" and "sacked" are both __u8 and
> fields are aligned to 32-bit ?
Not exactly.
Reason for the hole is the following :
struct whatever {
u8 first;
u8 second;
u32 third;
};
"third" field has an alignement requirement of 4 bytes on most arches.
Compiler inserts a 2 bytes hole before "third" to respect this
requirement.
There is no hole between "first" and "second", since second has no
alignment requirement.
sizeof(struct whatever) = 8
^ permalink raw reply
* Re: [PATCH net-next] tcp: unalias tcp_skb_cb flags and ip_dsfield
From: Christoph Paasch @ 2011-09-27 8:38 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev, hkchu, ilpo.jarvinen, jhs
In-Reply-To: <20110927.040853.516739403765881835.davem@davemloft.net>
On Tuesday 27 September 2011 wrote David Miller:
> From: Christoph Paasch <christoph.paasch@uclouvain.be>
> Date: Tue, 27 Sep 2011 10:37:38 +0300
>
> > However, (as far as I can see) before Eric's change it was 42 bytes long
> > and now it became 43 bytes.
>
> Then, I suggest that you go buy a pair of glasses. :-)
Yeah, maybe it's time to... ;-)
This two-byte hole, is it because "flags" and "sacked" are both __u8 and
fields are aligned to 32-bit ?
Thanks,
Christoph
--
Christoph Paasch
PhD Student
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
Université Catholique de Louvain
www.rollerbulls.be
--
^ permalink raw reply
* Re: [GIT PULL net-next] IPVS
From: Pablo Neira Ayuso @ 2011-09-27 8:16 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, netfilter-devel, netfilter, Wensong Zhang,
Julian Anastasov, Patrick McHardy, David S. Miller
In-Reply-To: <1317027938-22053-1-git-send-email-horms@verge.net.au>
On Mon, Sep 26, 2011 at 06:05:33PM +0900, Simon Horman wrote:
> Hi,
>
> with all the excitement of kernel.org being offline and a bunch of trees
> likewise being offline I am a little unsure who should take this pull
> request which is based on the current net-next tree. But I guess it should
> be Patrick, Pablo or Dave.
I'll try to set up one tree in one of my servers along today, I'll
send you the URI. We can use it until kernel.org comes back.
@Patrick: Contact me and I'll create one account for you so we can
access the same tree.
^ permalink raw reply
* Re: [PATCH net-next] tcp: unalias tcp_skb_cb flags and ip_dsfield
From: David Miller @ 2011-09-27 8:08 UTC (permalink / raw)
To: christoph.paasch; +Cc: eric.dumazet, netdev, hkchu, ilpo.jarvinen, jhs
In-Reply-To: <201109271037.38786.christoph.paasch@uclouvain.be>
From: Christoph Paasch <christoph.paasch@uclouvain.be>
Date: Tue, 27 Sep 2011 10:37:38 +0300
> However, (as far as I can see) before Eric's change it was 42 bytes long and
> now it became 43 bytes.
Then, I suggest that you go buy a pair of glasses. :-)
^ permalink raw reply
* Re: TSO support
From: Michio Honda @ 2011-09-27 8:00 UTC (permalink / raw)
To: Sedat Cakir; +Cc: netdev
In-Reply-To: <CAG+4w0mNdSwwQMH7+DSGUzMUrqjE_v7M55EP8Ug6JxytuJsN7g@mail.gmail.com>
Hi,
On TSO and TCP options, as far as I tested approx. 10 NICs, TSO copies TCP options to all the split segments. (We performed this test for Timestamp and an undefined option).
This paper (http://nrg.cs.ucl.ac.uk/mjh/tmp/mboxes.pdf) would be helpful.
Thanks,
- Michio
On Sep 27, 2011, at 4:19 PM, Sedat Cakir wrote:
> Hi,
>
> We are adding the TCP Segmentation offload (TSO) support to the device
> driver and the hardware. I am wondering: Can Linux subsystem supports
> the use of IP options and TCP options? If so then which options (e.g
> SACK processing for TCP)? Do we need any implementation in the NIC to
> manage TCP/IP options?
>
> Thanks,
> Sedat
> --
> 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 net-next] tcp: unalias tcp_skb_cb flags and ip_dsfield
From: Eric Dumazet @ 2011-09-27 8:01 UTC (permalink / raw)
To: christoph.paasch; +Cc: David Miller, netdev, hkchu, ilpo.jarvinen, jhs
In-Reply-To: <201109271037.38786.christoph.paasch@uclouvain.be>
Le mardi 27 septembre 2011 à 10:37 +0300, Christoph Paasch a écrit :
> Hi,
>
> I realize that before "struct tcp_skb_cb" is a comment saying that it's 44
> bytes long.
>
> However, (as far as I can see) before Eric's change it was 42 bytes long and
> now it became 43 bytes.
>
> Wouldn't it make sense to change the comment, so that it's consistent again
> with the real size of tcp_skb_cb ?
You are mistaken :)
There was a two bytes hole.
I took one byte for dsfield, and left one byte hole,
I added a comment to remind there is this hole
Thanks !
^ permalink raw reply
* Re: [PATCH net-next] tcp: unalias tcp_skb_cb flags and ip_dsfield
From: Christoph Paasch @ 2011-09-27 7:37 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev, hkchu, ilpo.jarvinen, jhs
In-Reply-To: <20110927.022025.1306291417181821045.davem@davemloft.net>
Hi,
I realize that before "struct tcp_skb_cb" is a comment saying that it's 44
bytes long.
However, (as far as I can see) before Eric's change it was 42 bytes long and
now it became 43 bytes.
Wouldn't it make sense to change the comment, so that it's consistent again
with the real size of tcp_skb_cb ?
Cheers,
Christoph
On Tuesday 27 September 2011 wrote David Miller:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 27 Sep 2011 08:00:49 +0200
>
> > struct tcp_skb_cb contains a "flags" field containing either tcp flags
> > or IP dsfield depending on context (input or output path)
> >
> > Introduce ip_dsfield to make the difference clear and ease maintenance.
> > If later we want to save space, we can union flags/ip_dsfield
> >
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Applied, thanks Eric.
>
> > If there is no objection, I plan to rename "flags" to "tcp_flags" in a
> > following patch.
>
> No objections.
> --
> 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
--
Christoph Paasch
PhD Student
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
Université Catholique de Louvain
www.rollerbulls.be
--
^ permalink raw reply
* TSO support
From: Sedat Cakir @ 2011-09-27 7:19 UTC (permalink / raw)
To: netdev
Hi,
We are adding the TCP Segmentation offload (TSO) support to the device
driver and the hardware. I am wondering: Can Linux subsystem supports
the use of IP options and TCP options? If so then which options (e.g
SACK processing for TCP)? Do we need any implementation in the NIC to
manage TCP/IP options?
Thanks,
Sedat
^ permalink raw reply
* Re: [PATCH 1/2] virtio-net: Verify page list size before fitting into skb
From: Michael S. Tsirkin @ 2011-09-27 7:00 UTC (permalink / raw)
To: Sasha Levin; +Cc: linux-kernel, Rusty Russell, virtualization, netdev, kvm
In-Reply-To: <1317105842.3467.3.camel@lappy>
On Tue, Sep 27, 2011 at 09:44:02AM +0300, Sasha Levin wrote:
> On Mon, 2011-09-26 at 22:55 +0300, Michael S. Tsirkin wrote:
> > On Mon, Sep 26, 2011 at 10:37:22PM +0300, Sasha Levin wrote:
> > > On Mon, 2011-09-26 at 21:44 +0300, Michael S. Tsirkin wrote:
> > > > On Mon, Sep 26, 2011 at 08:41:08PM +0300, Sasha Levin wrote:
> > > > > This patch verifies that the length of a buffer stored in a linked list
> > > > > of pages is small enough to fit into a skb.
> > > > >
> > > > > If the size is larger than a max size of a skb, it means that we shouldn't
> > > > > go ahead building skbs anyway since we won't be able to send the buffer as
> > > > > the user requested.
> > > > >
> > > > > Cc: Rusty Russell <rusty@rustcorp.com.au>
> > > > > Cc: "Michael S. Tsirkin" <mst@redhat.com>
> > > > > Cc: virtualization@lists.linux-foundation.org
> > > > > Cc: netdev@vger.kernel.org
> > > > > Cc: kvm@vger.kernel.org
> > > > > Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
> > > >
> > > > Interesting. This is a theoretical issue, correct?
> > > > Not a crash you actually see.
> > >
> > > Actually it was an actual crash caused when our virtio-net driver in kvm
> > > tools did funny things and passed '(u32)-1' length as a buffer length to
> > > the guest kernel.
> > >
> > > > This crash would mean device is giving us packets
> > > > that are way too large. Avoiding crashes even in the face of
> > > > a misbehaved device is a good idea, but should
> > > > we print a diagnostic to a system log?
> > > > Maybe rate-limited or print once to avoid filling
> > > > up the disk. Other places in driver print with pr_debug
> > > > I'm not sure that's right but better than nothing.
> > >
> > > Yup, I'll add some debug info.
> > >
> > > > > ---
> > > > > drivers/net/virtio_net.c | 3 +++
> > > > > 1 files changed, 3 insertions(+), 0 deletions(-)
> > > > >
> > > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > > > index 0c7321c..64e0717 100644
> > > > > --- a/drivers/net/virtio_net.c
> > > > > +++ b/drivers/net/virtio_net.c
> > > > > @@ -165,6 +165,9 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> > > > > unsigned int copy, hdr_len, offset;
> > > > > char *p;
> > > > >
> > > > > + if (len > MAX_SKB_FRAGS * PAGE_SIZE)
> > > >
> > > > unlikely()?
> > > >
> > > > Also, this seems too aggressive: at this point len includes the header
> > > > and the linear part. The right place for this
> > > > test is probably where we fill in the frags, just before
> > > > while (len)
> > > >
> > > > The whole can only happen when mergeable buffers
> > > > are disabled, right?
> > >
> > > >From what I understand it can happen whenever you're going to build a
> > > skb longer than PAGE_SIZE.
> >
> > Hmm how exactly? With mergeable buffers this only gets
> > the length of the 1st chunk which is up to 4K unless the driver
> > is buggy ...
>
> What about the case where TSO or ECN features are set? The code flow
> suggests that mergeable would get ignored in that case:
>
> /* If we can receive ANY GSO packets, we must allocate large ones. */
> if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO4) ||
> virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO6) ||
> virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_ECN))
> vi->big_packets = true;
>
> [...]
>
> if (!vi->mergeable_rx_bufs && !vi->big_packets) {
> skb = buf;
> len -= sizeof(struct virtio_net_hdr);
> skb_trim(skb, len);
> } else {
> page = buf;
> skb = page_to_skb(vi, page, len);
> ...
Sorry I don't get it yet. Where is mergeable ignored here?
> I haven't actually tested it with mergeable buffers enabled, but could
> do it later today.
Please do.
> --
>
> Sasha.
^ permalink raw reply
* [patch] 9p: fix min_t() casting in p9pdu_vwritef()
From: Dan Carpenter @ 2011-09-27 6:44 UTC (permalink / raw)
To: Eric Van Hensbergen
Cc: David S. Miller, Eric Van Hensbergen, Venkateswararao Jujjuri,
Aneesh Kumar K.V, Harsh Prateek Bora, netdev, kernel-janitors
I don't think we're actually likely to hit this limit but if we do
then the comparison should be done as size_t. The original code
is equivalent to:
len = strlen(sptr) % USHRT_MAX;
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/net/9p/protocol.c b/net/9p/protocol.c
index 55e10a9..39a4c18 100644
--- a/net/9p/protocol.c
+++ b/net/9p/protocol.c
@@ -368,7 +368,7 @@ p9pdu_vwritef(struct p9_fcall *pdu, int proto_version, const char *fmt,
const char *sptr = va_arg(ap, const char *);
uint16_t len = 0;
if (sptr)
- len = min_t(uint16_t, strlen(sptr),
+ len = min_t(size_t, strlen(sptr),
USHRT_MAX);
errcode = p9pdu_writef(pdu, proto_version,
^ permalink raw reply related
* Re: [PATCH 1/2] virtio-net: Verify page list size before fitting into skb
From: Sasha Levin @ 2011-09-27 6:44 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, Rusty Russell, virtualization, netdev, kvm
In-Reply-To: <20110926195541.GA23086@redhat.com>
On Mon, 2011-09-26 at 22:55 +0300, Michael S. Tsirkin wrote:
> On Mon, Sep 26, 2011 at 10:37:22PM +0300, Sasha Levin wrote:
> > On Mon, 2011-09-26 at 21:44 +0300, Michael S. Tsirkin wrote:
> > > On Mon, Sep 26, 2011 at 08:41:08PM +0300, Sasha Levin wrote:
> > > > This patch verifies that the length of a buffer stored in a linked list
> > > > of pages is small enough to fit into a skb.
> > > >
> > > > If the size is larger than a max size of a skb, it means that we shouldn't
> > > > go ahead building skbs anyway since we won't be able to send the buffer as
> > > > the user requested.
> > > >
> > > > Cc: Rusty Russell <rusty@rustcorp.com.au>
> > > > Cc: "Michael S. Tsirkin" <mst@redhat.com>
> > > > Cc: virtualization@lists.linux-foundation.org
> > > > Cc: netdev@vger.kernel.org
> > > > Cc: kvm@vger.kernel.org
> > > > Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
> > >
> > > Interesting. This is a theoretical issue, correct?
> > > Not a crash you actually see.
> >
> > Actually it was an actual crash caused when our virtio-net driver in kvm
> > tools did funny things and passed '(u32)-1' length as a buffer length to
> > the guest kernel.
> >
> > > This crash would mean device is giving us packets
> > > that are way too large. Avoiding crashes even in the face of
> > > a misbehaved device is a good idea, but should
> > > we print a diagnostic to a system log?
> > > Maybe rate-limited or print once to avoid filling
> > > up the disk. Other places in driver print with pr_debug
> > > I'm not sure that's right but better than nothing.
> >
> > Yup, I'll add some debug info.
> >
> > > > ---
> > > > drivers/net/virtio_net.c | 3 +++
> > > > 1 files changed, 3 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > > index 0c7321c..64e0717 100644
> > > > --- a/drivers/net/virtio_net.c
> > > > +++ b/drivers/net/virtio_net.c
> > > > @@ -165,6 +165,9 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> > > > unsigned int copy, hdr_len, offset;
> > > > char *p;
> > > >
> > > > + if (len > MAX_SKB_FRAGS * PAGE_SIZE)
> > >
> > > unlikely()?
> > >
> > > Also, this seems too aggressive: at this point len includes the header
> > > and the linear part. The right place for this
> > > test is probably where we fill in the frags, just before
> > > while (len)
> > >
> > > The whole can only happen when mergeable buffers
> > > are disabled, right?
> >
> > >From what I understand it can happen whenever you're going to build a
> > skb longer than PAGE_SIZE.
>
> Hmm how exactly? With mergeable buffers this only gets
> the length of the 1st chunk which is up to 4K unless the driver
> is buggy ...
What about the case where TSO or ECN features are set? The code flow
suggests that mergeable would get ignored in that case:
/* If we can receive ANY GSO packets, we must allocate large ones. */
if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO4) ||
virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO6) ||
virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_ECN))
vi->big_packets = true;
[...]
if (!vi->mergeable_rx_bufs && !vi->big_packets) {
skb = buf;
len -= sizeof(struct virtio_net_hdr);
skb_trim(skb, len);
} else {
page = buf;
skb = page_to_skb(vi, page, len);
...
I haven't actually tested it with mergeable buffers enabled, but could
do it later today.
--
Sasha.
^ permalink raw reply
* Re: [PATCH net-next] tcp: unalias tcp_skb_cb flags and ip_dsfield
From: David Miller @ 2011-09-27 6:20 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, hkchu, ilpo.jarvinen, jhs
In-Reply-To: <1317103249.2796.25.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 27 Sep 2011 08:00:49 +0200
> struct tcp_skb_cb contains a "flags" field containing either tcp flags
> or IP dsfield depending on context (input or output path)
>
> Introduce ip_dsfield to make the difference clear and ease maintenance.
> If later we want to save space, we can union flags/ip_dsfield
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
> If there is no objection, I plan to rename "flags" to "tcp_flags" in a
> following patch.
No objections.
^ permalink raw reply
* [PATCH net-next] tcp: unalias tcp_skb_cb flags and ip_dsfield
From: Eric Dumazet @ 2011-09-27 6:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev, hkchu, ilpo.jarvinen, jhs
In-Reply-To: <20110927.005905.1166544891922183065.davem@davemloft.net>
struct tcp_skb_cb contains a "flags" field containing either tcp flags
or IP dsfield depending on context (input or output path)
Introduce ip_dsfield to make the difference clear and ease maintenance.
If later we want to save space, we can union flags/ip_dsfield
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
If there is no objection, I plan to rename "flags" to "tcp_flags" in a
following patch.
include/net/tcp.h | 3 ++-
net/ipv4/tcp_input.c | 2 +-
net/ipv4/tcp_ipv4.c | 2 +-
net/ipv6/tcp_ipv6.c | 2 +-
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 702aefc..28a9997 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -642,7 +642,8 @@ struct tcp_skb_cb {
#define TCPCB_SACKED_RETRANS 0x02 /* SKB retransmitted */
#define TCPCB_LOST 0x04 /* SKB is lost */
#define TCPCB_TAGBITS 0x07 /* All tag bits */
-
+ __u8 ip_dsfield; /* IPv4 tos or IPv6 dsfield */
+ /* 1 byte hole */
#define TCPCB_EVER_RETRANS 0x80 /* Ever retransmitted frame */
#define TCPCB_RETRANS (TCPCB_SACKED_RETRANS|TCPCB_EVER_RETRANS)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 5a4408c..7008fcc 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -222,7 +222,7 @@ static inline void TCP_ECN_check_ce(struct tcp_sock *tp, const struct sk_buff *s
if (!(tp->ecn_flags & TCP_ECN_OK))
return;
- switch (TCP_SKB_CB(skb)->flags & INET_ECN_MASK) {
+ switch (TCP_SKB_CB(skb)->ip_dsfield & INET_ECN_MASK) {
case INET_ECN_NOT_ECT:
/* Funny extension: if ECT is not set on a segment,
* and we already seen ECT on a previous segment,
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index c29912c..dd3fad9 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1677,7 +1677,7 @@ int tcp_v4_rcv(struct sk_buff *skb)
skb->len - th->doff * 4);
TCP_SKB_CB(skb)->ack_seq = ntohl(th->ack_seq);
TCP_SKB_CB(skb)->when = 0;
- TCP_SKB_CB(skb)->flags = iph->tos;
+ TCP_SKB_CB(skb)->ip_dsfield = ipv4_get_dsfield(iph);
TCP_SKB_CB(skb)->sacked = 0;
sk = __inet_lookup_skb(&tcp_hashinfo, skb, th->source, th->dest);
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 12bdb9a..00797d8 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1717,7 +1717,7 @@ static int tcp_v6_rcv(struct sk_buff *skb)
skb->len - th->doff*4);
TCP_SKB_CB(skb)->ack_seq = ntohl(th->ack_seq);
TCP_SKB_CB(skb)->when = 0;
- TCP_SKB_CB(skb)->flags = ipv6_get_dsfield(hdr);
+ TCP_SKB_CB(skb)->ip_dsfield = ipv6_get_dsfield(hdr);
TCP_SKB_CB(skb)->sacked = 0;
sk = __inet6_lookup_skb(&tcp_hashinfo, skb, th->source, th->dest);
^ permalink raw reply related
* Re: Question about memory leak detector giving false positive report for net/core/flow.c
From: Eric Dumazet @ 2011-09-27 5:55 UTC (permalink / raw)
To: Huajun Li
Cc: Catalin Marinas, linux-mm@kvack.org, netdev, linux-kernel,
Tejun Heo, Christoph Lameter
In-Reply-To: <CA+v9cxYzWJScCa2mMoEovq3WULSZYQaq6EjoRV7SQUjr0L_RiQ@mail.gmail.com>
Le mardi 27 septembre 2011 à 13:29 +0800, Huajun Li a écrit :
> 2011/9/27 Eric Dumazet <eric.dumazet@gmail.com>:
> > Le lundi 26 septembre 2011 à 17:50 +0100, Catalin Marinas a écrit :
> >> On Mon, Sep 26, 2011 at 05:32:54PM +0100, Eric Dumazet wrote:
> >> > Le lundi 26 septembre 2011 à 23:17 +0800, Huajun Li a écrit :
> >> > > Memory leak detector gives following memory leak report, it seems the
> >> > > report is triggered by net/core/flow.c, but actually, it should be a
> >> > > false positive report.
> >> > > So, is there any idea from kmemleak side to fix/disable this false
> >> > > positive report like this?
> >> > > Yes, kmemleak_not_leak(...) could disable it, but is it suitable for this case ?
> >> ...
> >> > CC lkml and percpu maintainers (Tejun Heo & Christoph Lameter ) as well
> >> >
> >> > AFAIK this false positive only occurs if percpu data is allocated
> >> > outside of embedded pcu space.
> >> >
> >> > (grep pcpu_get_vm_areas /proc/vmallocinfo)
> >> >
> >> > I suspect this is a percpu/kmemleak cooperation problem (a missing
> >> > kmemleak_alloc() ?)
> >> >
> >> > I am pretty sure kmemleak_not_leak() is not the right answer to this
> >> > problem.
> >>
> >> kmemleak_not_leak() definitely not the write answer. The alloc_percpu()
> >> call does not have any kmemleak_alloc() callback, so it doesn't scan
> >> them.
> >>
> >> Huajun, could you please try the patch below:
> >>
> >> 8<--------------------------------
> >> kmemleak: Handle percpu memory allocation
> >>
> >> From: Catalin Marinas <catalin.marinas@arm.com>
> >>
> >> This patch adds kmemleak callbacks from the percpu allocator, reducing a
> >> number of false positives caused by kmemleak not scanning such memory
> >> blocks.
> >>
> >> Reported-by: Huajun Li <huajun.li.lee@gmail.com>
> >> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> >> ---
> >> mm/percpu.c | 11 +++++++++--
> >> 1 files changed, 9 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/mm/percpu.c b/mm/percpu.c
> >> index bf80e55..c47a90b 100644
> >> --- a/mm/percpu.c
> >> +++ b/mm/percpu.c
> >> @@ -67,6 +67,7 @@
> >> #include <linux/spinlock.h>
> >> #include <linux/vmalloc.h>
> >> #include <linux/workqueue.h>
> >> +#include <linux/kmemleak.h>
> >>
> >> #include <asm/cacheflush.h>
> >> #include <asm/sections.h>
> >> @@ -833,7 +834,9 @@ fail_unlock_mutex:
> >> */
> >> void __percpu *__alloc_percpu(size_t size, size_t align)
> >> {
> >> - return pcpu_alloc(size, align, false);
> >> + void __percpu *ptr = pcpu_alloc(size, align, false);
> >> + kmemleak_alloc(ptr, size, 1, GFP_KERNEL);
> >> + return ptr;
> >> }
> >> EXPORT_SYMBOL_GPL(__alloc_percpu);
> >>
> >> @@ -855,7 +858,9 @@ EXPORT_SYMBOL_GPL(__alloc_percpu);
> >> */
> >> void __percpu *__alloc_reserved_percpu(size_t size, size_t align)
> >> {
> >> - return pcpu_alloc(size, align, true);
> >> + void __percpu *ptr = pcpu_alloc(size, align, true);
> >> + kmemleak_alloc(ptr, size, 1, GFP_KERNEL);
> >> + return ptr;
> >> }
> >>
> >> /**
> >> @@ -915,6 +920,8 @@ void free_percpu(void __percpu *ptr)
> >> if (!ptr)
> >> return;
> >>
> >> + kmemleak_free(ptr);
> >> +
> >> addr = __pcpu_ptr_to_addr(ptr);
> >>
> >> spin_lock_irqsave(&pcpu_lock, flags);
> >>
> >
> > Hmm, you need to call kmemleak_alloc() for each chunk allocated per
> > possible cpu.
> >
> > Here is the (untested) patch for the allocation phase, need the same at
> > freeing time
> >
> > diff --git a/mm/percpu-km.c b/mm/percpu-km.c
> > index 89633fe..5061ac5 100644
> > --- a/mm/percpu-km.c
> > +++ b/mm/percpu-km.c
> > @@ -37,9 +37,12 @@ static int pcpu_populate_chunk(struct pcpu_chunk *chunk, int off, int size)
> > {
> > unsigned int cpu;
> >
> > - for_each_possible_cpu(cpu)
> > - memset((void *)pcpu_chunk_addr(chunk, cpu, 0) + off, 0, size);
> > + for_each_possible_cpu(cpu) {
> > + void *chunk_addr = (void *)pcpu_chunk_addr(chunk, cpu, 0) + off;
> >
> > + kmemleak_alloc(chunk_addr, size, 1, GFP_KERNEL);
> > + memset(chunk_addr, 0, size);
> > + }
> > return 0;
> > }
> >
> > diff --git a/mm/percpu-vm.c b/mm/percpu-vm.c
> > index ea53496..0d397cc 100644
> > --- a/mm/percpu-vm.c
> > +++ b/mm/percpu-vm.c
> > @@ -342,8 +342,12 @@ static int pcpu_populate_chunk(struct pcpu_chunk *chunk, int off, int size)
> > /* commit new bitmap */
> > bitmap_copy(chunk->populated, populated, pcpu_unit_pages);
> > clear:
> > - for_each_possible_cpu(cpu)
> > - memset((void *)pcpu_chunk_addr(chunk, cpu, 0) + off, 0, size);
> > + for_each_possible_cpu(cpu) {
> > + void *chunk_addr = (void *)pcpu_chunk_addr(chunk, cpu, 0) + off;
> > +
> > + kmemleak_alloc(chunk_addr, size, 1, GFP_KERNEL);
> > + memset(chunk_addr, 0, size);
> > + }
> > return 0;
> >
> > err_unmap:
> >
> >
>
> About this one, memory leak detector disabled(actually I enable it
> while config the kernel) while booting system, and and found following
> info in dmesg:
Yes, it was not a patch, but the general idea for Catalin ;)
You hit the fact that same zone (embedded percpu space) is now in a
mixed state.
In current kernels, the embedded percpu zone is already known by
kmemleak, but with a large granularity. kmemleak is not aware of
individual allocations/freeing in this large zone.
Once kmemleak and percpu allocator are cooperating, we might find more
kmemleaks. Right now, kmemleak can find pointers in percpu chunks that
are not anymore reachable (they were freed), and therefore doesnt warn
of possible memory leaks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] RDSRDMA: Fix cleanup of rds_iw_mr_pool
From: David Miller @ 2011-09-27 5:32 UTC (permalink / raw)
To: jonathan; +Cc: venkat.x.venkatsubra, netdev
In-Reply-To: <20110913194101.7497.65515.stgit@build.ogc.int>
From: Jonathan Lallinger <jonathan@ogc.us>
Date: Tue, 13 Sep 2011 14:41:01 -0500
> @@ -548,6 +550,7 @@ static int rds_iw_flush_mr_pool(struct rds_iw_mr_pool *pool, int free_all)
> spin_unlock_irqrestore(&pool->list_lock, flags);
> }
>
> + atomic_sub(unpinned, &poll->free_pinned);
> atomic_sub(ncleaned, &pool->dirty_count);
> atomic_sub(nfreed, &pool->item_count);
>
net/rds/iw_rdma.c: In function ‘rds_iw_flush_mr_pool’:
net/rds/iw_rdma.c:553:24: error: ‘poll’ undeclared (first use in this function)
net/rds/iw_rdma.c:553:24: note: each undeclared identifier is reported only once for each function it appears in
If you didn't even build test it, I know you didn't test it's
functionality either.
This is crazy.
Well if it's not important enough to even build test this change
before you post it, then it obviously doesn't matter if the RDMA
module crashes the kernel when it's unloaded.
^ permalink raw reply
* Re: Question about memory leak detector giving false positive report for net/core/flow.c
From: Huajun Li @ 2011-09-27 5:29 UTC (permalink / raw)
To: Eric Dumazet
Cc: Catalin Marinas, linux-mm@kvack.org, netdev, linux-kernel,
Tejun Heo, Christoph Lameter, Huajun Li
In-Reply-To: <1317066395.2796.11.camel@edumazet-laptop>
2011/9/27 Eric Dumazet <eric.dumazet@gmail.com>:
> Le lundi 26 septembre 2011 à 17:50 +0100, Catalin Marinas a écrit :
>> On Mon, Sep 26, 2011 at 05:32:54PM +0100, Eric Dumazet wrote:
>> > Le lundi 26 septembre 2011 à 23:17 +0800, Huajun Li a écrit :
>> > > Memory leak detector gives following memory leak report, it seems the
>> > > report is triggered by net/core/flow.c, but actually, it should be a
>> > > false positive report.
>> > > So, is there any idea from kmemleak side to fix/disable this false
>> > > positive report like this?
>> > > Yes, kmemleak_not_leak(...) could disable it, but is it suitable for this case ?
>> ...
>> > CC lkml and percpu maintainers (Tejun Heo & Christoph Lameter ) as well
>> >
>> > AFAIK this false positive only occurs if percpu data is allocated
>> > outside of embedded pcu space.
>> >
>> > (grep pcpu_get_vm_areas /proc/vmallocinfo)
>> >
>> > I suspect this is a percpu/kmemleak cooperation problem (a missing
>> > kmemleak_alloc() ?)
>> >
>> > I am pretty sure kmemleak_not_leak() is not the right answer to this
>> > problem.
>>
>> kmemleak_not_leak() definitely not the write answer. The alloc_percpu()
>> call does not have any kmemleak_alloc() callback, so it doesn't scan
>> them.
>>
>> Huajun, could you please try the patch below:
>>
>> 8<--------------------------------
>> kmemleak: Handle percpu memory allocation
>>
>> From: Catalin Marinas <catalin.marinas@arm.com>
>>
>> This patch adds kmemleak callbacks from the percpu allocator, reducing a
>> number of false positives caused by kmemleak not scanning such memory
>> blocks.
>>
>> Reported-by: Huajun Li <huajun.li.lee@gmail.com>
>> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
>> ---
>> mm/percpu.c | 11 +++++++++--
>> 1 files changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/percpu.c b/mm/percpu.c
>> index bf80e55..c47a90b 100644
>> --- a/mm/percpu.c
>> +++ b/mm/percpu.c
>> @@ -67,6 +67,7 @@
>> #include <linux/spinlock.h>
>> #include <linux/vmalloc.h>
>> #include <linux/workqueue.h>
>> +#include <linux/kmemleak.h>
>>
>> #include <asm/cacheflush.h>
>> #include <asm/sections.h>
>> @@ -833,7 +834,9 @@ fail_unlock_mutex:
>> */
>> void __percpu *__alloc_percpu(size_t size, size_t align)
>> {
>> - return pcpu_alloc(size, align, false);
>> + void __percpu *ptr = pcpu_alloc(size, align, false);
>> + kmemleak_alloc(ptr, size, 1, GFP_KERNEL);
>> + return ptr;
>> }
>> EXPORT_SYMBOL_GPL(__alloc_percpu);
>>
>> @@ -855,7 +858,9 @@ EXPORT_SYMBOL_GPL(__alloc_percpu);
>> */
>> void __percpu *__alloc_reserved_percpu(size_t size, size_t align)
>> {
>> - return pcpu_alloc(size, align, true);
>> + void __percpu *ptr = pcpu_alloc(size, align, true);
>> + kmemleak_alloc(ptr, size, 1, GFP_KERNEL);
>> + return ptr;
>> }
>>
>> /**
>> @@ -915,6 +920,8 @@ void free_percpu(void __percpu *ptr)
>> if (!ptr)
>> return;
>>
>> + kmemleak_free(ptr);
>> +
>> addr = __pcpu_ptr_to_addr(ptr);
>>
>> spin_lock_irqsave(&pcpu_lock, flags);
>>
>
> Hmm, you need to call kmemleak_alloc() for each chunk allocated per
> possible cpu.
>
> Here is the (untested) patch for the allocation phase, need the same at
> freeing time
>
> diff --git a/mm/percpu-km.c b/mm/percpu-km.c
> index 89633fe..5061ac5 100644
> --- a/mm/percpu-km.c
> +++ b/mm/percpu-km.c
> @@ -37,9 +37,12 @@ static int pcpu_populate_chunk(struct pcpu_chunk *chunk, int off, int size)
> {
> unsigned int cpu;
>
> - for_each_possible_cpu(cpu)
> - memset((void *)pcpu_chunk_addr(chunk, cpu, 0) + off, 0, size);
> + for_each_possible_cpu(cpu) {
> + void *chunk_addr = (void *)pcpu_chunk_addr(chunk, cpu, 0) + off;
>
> + kmemleak_alloc(chunk_addr, size, 1, GFP_KERNEL);
> + memset(chunk_addr, 0, size);
> + }
> return 0;
> }
>
> diff --git a/mm/percpu-vm.c b/mm/percpu-vm.c
> index ea53496..0d397cc 100644
> --- a/mm/percpu-vm.c
> +++ b/mm/percpu-vm.c
> @@ -342,8 +342,12 @@ static int pcpu_populate_chunk(struct pcpu_chunk *chunk, int off, int size)
> /* commit new bitmap */
> bitmap_copy(chunk->populated, populated, pcpu_unit_pages);
> clear:
> - for_each_possible_cpu(cpu)
> - memset((void *)pcpu_chunk_addr(chunk, cpu, 0) + off, 0, size);
> + for_each_possible_cpu(cpu) {
> + void *chunk_addr = (void *)pcpu_chunk_addr(chunk, cpu, 0) + off;
> +
> + kmemleak_alloc(chunk_addr, size, 1, GFP_KERNEL);
> + memset(chunk_addr, 0, size);
> + }
> return 0;
>
> err_unmap:
>
>
About this one, memory leak detector disabled(actually I enable it
while config the kernel) while booting system, and and found following
info in dmesg:
---------------------------------------------------------------------------------------------------------------
[ 0.370000] smpboot cpu 1: start_ip = 9a000
[ 0.010000] numa_add_cpu cpu 1 node 0: mask now 0-1
[ 0.530124] NMI watchdog enabled, takes one hw-pmu counter.
[ 0.530344] Brought up 2 CPUs
[ 0.530348] Total of 2 processors activated (10639.45 BogoMIPS).
[ 0.533083] kmemleak: Cannot insert 0xffff88007a3d7448 into the
object search tree (already existing)
[ 0.533083] Pid: 1, comm: swapper Tainted: G I 3.1.0-rc7+ #25
[ 0.533083] Call Trace:
[ 0.533083] [<ffffffff81256512>] create_object+0x2c2/0x360
[ 0.533083] [<ffffffff81920c5e>] kmemleak_alloc+0x7e/0x110
[ 0.533083] [<ffffffff811fd8cd>] pcpu_alloc+0xd2d/0x10f0
[ 0.533083] [<ffffffff81243129>] ? __kmalloc_track_caller+0x139/0x310
[ 0.533083] [<ffffffff811fdca8>] __alloc_percpu+0x18/0x30
[ 0.533083] [<ffffffff8128dded>] alloc_vfsmnt+0x11d/0x250
[ 0.533083] [<ffffffff8128dfd6>] vfs_kern_mount+0x46/0x130
[ 0.533083] [<ffffffff8194a283>] ? _raw_write_unlock+0x43/0x60
[ 0.533083] [<ffffffff82117cec>] shmem_init+0xb9/0x13b
[ 0.533083] [<ffffffff820ea2c6>] kernel_init+0x10e/0x23a
[ 0.533083] [<ffffffff8195a484>] kernel_thread_helper+0x4/0x10
[ 0.533083] [<ffffffff8194ac20>] ? _raw_spin_unlock_irq+0x50/0x80
[ 0.533083] [<ffffffff8194b834>] ? retint_restore_args+0x13/0x13
[ 0.533083] [<ffffffff820ea1b8>] ? start_kernel+0x6ce/0x6ce
[ 0.533083] [<ffffffff8195a480>] ? gs_change+0x13/0x13
[ 0.533083] kmemleak: Kernel memory leak detector disabled
[ 0.533083] kmemleak: Object 0xffff88007a200000 (size 1949696):
[ 0.533083] kmemleak: comm "swapper", pid 0, jiffies 4294937296
[ 0.533083] kmemleak: min_count = 0
[ 0.533083] kmemleak: count = 0
[ 0.533083] kmemleak: flags = 0x1
[ 0.533083] kmemleak: checksum = 0
[ 0.533083] kmemleak: backtrace:
[ 0.533083] [<ffffffff81256394>] create_object+0x144/0x360
[ 0.533083] [<ffffffff819214c8>] kmemleak_free_part+0x138/0x1d0
[ 0.533083] [<ffffffff8211e4e8>] kmemleak_init+0x30b/0x3fd
[ 0.533083] [<ffffffff820ea01c>] start_kernel+0x532/0x6ce
[ 0.533083] [<ffffffff820e938d>] x86_64_start_reservations+0x178/0x183
[ 0.533083] [<ffffffff820e94fb>] x86_64_start_kernel+0x163/0x179
[ 0.533083] [<ffffffffffffffff>] 0xffffffffffffffff
[ 0.533083] devtmpfs: initialized
[ 0.533083] gcov: version magic: 0x3430352a
[ 0.533083] PM: Registering ACPI NVS region at 7d2afe00 (8352 bytes)
[ 0.533083] print_constraints: dummy:
[ 0.533083] RTC time: 12:40:24, date: 09/27/11
[ 0.533083] NET: Registered protocol family 16
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Question about memory leak detector giving false positive report for net/core/flow.c
From: Huajun Li @ 2011-09-27 5:27 UTC (permalink / raw)
To: Catalin Marinas
Cc: Eric Dumazet, linux-mm@kvack.org, netdev, linux-kernel, Tejun Heo,
Christoph Lameter, Huajun Li
In-Reply-To: <20110926165024.GA21617@e102109-lin.cambridge.arm.com>
2011/9/27 Catalin Marinas <Catalin.Marinas@arm.com>:
> On Mon, Sep 26, 2011 at 05:32:54PM +0100, Eric Dumazet wrote:
>> Le lundi 26 septembre 2011 à 23:17 +0800, Huajun Li a écrit :
>> > Memory leak detector gives following memory leak report, it seems the
>> > report is triggered by net/core/flow.c, but actually, it should be a
>> > false positive report.
>> > So, is there any idea from kmemleak side to fix/disable this false
>> > positive report like this?
>> > Yes, kmemleak_not_leak(...) could disable it, but is it suitable for this case ?
> ...
>> CC lkml and percpu maintainers (Tejun Heo & Christoph Lameter ) as well
>>
>> AFAIK this false positive only occurs if percpu data is allocated
>> outside of embedded pcu space.
>>
>> (grep pcpu_get_vm_areas /proc/vmallocinfo)
>>
>> I suspect this is a percpu/kmemleak cooperation problem (a missing
>> kmemleak_alloc() ?)
>>
>> I am pretty sure kmemleak_not_leak() is not the right answer to this
>> problem.
>
> kmemleak_not_leak() definitely not the write answer. The alloc_percpu()
> call does not have any kmemleak_alloc() callback, so it doesn't scan
> them.
>
> Huajun, could you please try the patch below:
>
> 8<--------------------------------
> kmemleak: Handle percpu memory allocation
>
> From: Catalin Marinas <catalin.marinas@arm.com>
>
> This patch adds kmemleak callbacks from the percpu allocator, reducing a
> number of false positives caused by kmemleak not scanning such memory
> blocks.
>
> Reported-by: Huajun Li <huajun.li.lee@gmail.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
> mm/percpu.c | 11 +++++++++--
> 1 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/mm/percpu.c b/mm/percpu.c
> index bf80e55..c47a90b 100644
> --- a/mm/percpu.c
> +++ b/mm/percpu.c
> @@ -67,6 +67,7 @@
> #include <linux/spinlock.h>
> #include <linux/vmalloc.h>
> #include <linux/workqueue.h>
> +#include <linux/kmemleak.h>
>
> #include <asm/cacheflush.h>
> #include <asm/sections.h>
> @@ -833,7 +834,9 @@ fail_unlock_mutex:
> */
> void __percpu *__alloc_percpu(size_t size, size_t align)
> {
> - return pcpu_alloc(size, align, false);
> + void __percpu *ptr = pcpu_alloc(size, align, false);
> + kmemleak_alloc(ptr, size, 1, GFP_KERNEL);
> + return ptr;
> }
> EXPORT_SYMBOL_GPL(__alloc_percpu);
>
> @@ -855,7 +858,9 @@ EXPORT_SYMBOL_GPL(__alloc_percpu);
> */
> void __percpu *__alloc_reserved_percpu(size_t size, size_t align)
> {
> - return pcpu_alloc(size, align, true);
> + void __percpu *ptr = pcpu_alloc(size, align, true);
> + kmemleak_alloc(ptr, size, 1, GFP_KERNEL);
> + return ptr;
> }
>
> /**
> @@ -915,6 +920,8 @@ void free_percpu(void __percpu *ptr)
> if (!ptr)
> return;
>
> + kmemleak_free(ptr);
> +
> addr = __pcpu_ptr_to_addr(ptr);
>
> spin_lock_irqsave(&pcpu_lock, flags);
>
> --
> Catalin
>
Applied the patch and found following msg after system boot up :
--------------------------------------------------------------------------------------------------------
...
[ 48.040027] eth0: no IPv6 routers present
[ 69.240960] BUG: unable to handle kernel paging request at 00000000001d7270
[ 69.241010] IP: [<ffffffff81256c62>] scan_block+0x62/0x220
[ 69.241045] PGD 5f289067 PUD 5f292067 PMD 0
[ 69.241074] Oops: 0000 [#1] SMP
[ 69.241098] CPU 0
[ 69.241110] Modules linked in: binfmt_misc dm_crypt
snd_hda_codec_analog snd_hda_intel snd_hda_codec usbhid hid snd_hwdep
snd_pcm snd_seq_midi snd_rawmidi i915 snd_seq_midi_event hp_wmi ppdev
sparse_keymap snd_seq snd_timer snd_seq_device ehci_hcd uhci_hcd
drm_kms_helper usbcore tpm_infineon psmouse snd e1000e drm serio_raw
soundcore tpm_tis snd_page_alloc tpm floppy tpm_bios parport_pc
i2c_algo_bit video lp parport
[ 69.249303]
[ 69.250246] Pid: 47, comm: kmemleak Tainted: G I
3.1.0-rc7+ #24 Hewlett-Packard HP Compaq dc7800p Convertible
Minitower/0AACh
[ 69.250246] RIP: 0010:[<ffffffff81256c62>] [<ffffffff81256c62>]
scan_block+0x62/0x220
[ 69.250246] RSP: 0018:ffff880073f69d90 EFLAGS: 00010012
[ 69.250246] RAX: 0000000000000000 RBX: ffff880078750858 RCX: 0000000000000000
[ 69.250246] RDX: ffff880078750858 RSI: 0000000000000001 RDI: 00000000001d7270
[ 69.250246] RBP: ffff880073f69dd0 R08: 0000000000000000 R09: 0000000000000000
[ 69.250246] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8800787508b8
[ 69.250246] R13: 00000000001d7270 R14: 00000000001d7431 R15: 0000000000000000
[ 69.250246] FS: 0000000000000000(0000) GS:ffff88007a200000(0000)
knlGS:0000000000000000
[ 69.250246] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 69.250246] CR2: 00000000001d7270 CR3: 000000006d735000 CR4: 00000000000006f0
[ 69.250246] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 69.250246] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 69.250246] Process kmemleak (pid: 47, threadinfo ffff880073f68000,
task ffff880073e4a460)
[ 69.250246] Stack:
[ 69.250246] ffff880073f69dd0 ffffffff8194b49a ffffffff81256ed1
ffff880078750858
[ 69.250246] ffff8800787508b8 00000000001d8270 00000000001d7438
0000000000000206
[ 69.250246] ffff880073f69e10 ffffffff8125702a 000000000007d2af
ffffffff81e0d120
[ 69.250246] Call Trace:
[ 69.250246] [<ffffffff8194b49a>] ? _raw_spin_lock_irqsave+0xfa/0x110
[ 69.250246] [<ffffffff81256ed1>] ? scan_gray_list+0xb1/0x280
[ 69.250246] [<ffffffff8125702a>] scan_gray_list+0x20a/0x280
[ 69.250246] [<ffffffff8125787a>] kmemleak_scan+0x44a/0xbd0
[ 69.250246] [<ffffffff81257430>] ? kmemleak_do_cleanup+0x210/0x210
[ 69.250246] [<ffffffff81258630>] ? kmemleak_write+0x630/0x630
[ 69.250246] [<ffffffff812586bf>] kmemleak_scan_thread+0x8f/0x150
[ 69.250246] [<ffffffff810dc4e6>] kthread+0xe6/0x100
[ 69.250246] [<ffffffff8195a4c4>] kernel_thread_helper+0x4/0x10
[ 69.250246] [<ffffffff8194ac50>] ? _raw_spin_unlock_irq+0x50/0x80
[ 69.250246] [<ffffffff8194b874>] ? retint_restore_args+0x13/0x13
[ 69.250246] [<ffffffff810dc400>] ? __init_kthread_worker+0x80/0x80
[ 69.250246] [<ffffffff8195a4c0>] ? gs_change+0x13/0x13
[ 69.250246] Code: 00 00 e9 d2 01 00 00 66 90 e8 ab f4 ff ff 48 83
05 33 ef 06 02 01 85 c0 0f 85 bb 01 00 00 48 83 05 2b ef 06 02 01 be
01 00 00 00
[ 69.250246] 8b 7d 00 e8 c5 fc ff ff 48 85 c0 49 89 c4 0f 84 69 01 00 00
[ 69.250246] RIP [<ffffffff81256c62>] scan_block+0x62/0x220
[ 69.250246] RSP <ffff880073f69d90>
[ 69.250246] CR2: 00000000001d7270
[ 69.360917] ---[ end trace a7919e7f17c0a727 ]---
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3] enic: updates to version 2.1.1.28
From: David Miller @ 2011-09-27 5:13 UTC (permalink / raw)
To: roprabhu; +Cc: netdev
In-Reply-To: <20110922134410.2145.72210.stgit@savbu-pc100.cisco.com>
From: Roopa Prabhu <roprabhu@cisco.com>
Date: Thu, 22 Sep 2011 06:44:27 -0700
> This patch series implements the following enic driver updates:
>
> 01/3 - Add SRIOV support
> 02/3 - Helper code for SRIOV proxy commands
> 03/3 - Add support for port profile association on a enic SRIOV VF
>
> Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
> Signed-off-by: Sujith Sankar <ssujith@cisco.com>
> Signed-off-by: Christian Benvenuti <benve@cisco.com>
> Signed-off-by: David Wang <dwang2@cisco.com>
All applied, thank you.
^ permalink raw reply
* Re: [PATCH] tcp: ECN blackhole should not force quickack mode
From: David Miller @ 2011-09-27 4:59 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, hkchu, ilpo.jarvinen, jhs, jg, dave.taht
In-Reply-To: <1316757739.2560.12.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 23 Sep 2011 08:02:19 +0200
> While playing with a new ADSL box at home, I discovered that ECN
> blackhole can trigger suboptimal quickack mode on linux : We send one
> ACK for each incoming data frame, without any delay and eventual
> piggyback.
>
> This is because TCP_ECN_check_ce() considers that if no ECT is seen on a
> segment, this is because this segment was a retransmit.
>
> Refine this heuristic and apply it only if we seen ECT in a previous
> segment, to detect ECN blackhole at IP level.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-next, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next] sky2: manage irq better on single port card
From: David Miller @ 2011-09-27 4:51 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20110923141340.39a8de91@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 23 Sep 2011 14:13:40 -0700
> Most sky2 hardware only has a single port, although some variations of the
> chip support two interfaces. For the single port case, use the standard
> Ethernet driver convention of allocating IRQ when device is brought up
> rather than at probe time.
>
> Also, change the error handling of dual port cards so that if second
> port can not be brought up, then just fail. No point in continuing, since
> the failure is most certainly because of out of memory.
>
> The dual port sky2 device has a single irq and a single status ring,
> therefore it has a single NAPI object shared by both ports.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] pch_gbe: remove unused variable
From: David Miller @ 2011-09-27 4:50 UTC (permalink / raw)
To: jdmason; +Cc: toshiharu-linux, netdev
In-Reply-To: <1317065858-3201-1-git-send-email-jdmason@kudzu.us>
From: Jon Mason <jdmason@kudzu.us>
Date: Mon, 26 Sep 2011 14:37:38 -0500
> netdev is unused in pch_gbe_setup_rctl. Remove this declaration to
> avoid a compiler warning.
>
> Signed-off-by: Jon Mason <jdmason@kudzu.us>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ehea: Remove sleep at .ndo_get_stats
From: David Miller @ 2011-09-27 4:47 UTC (permalink / raw)
To: eric.dumazet; +Cc: brenohl, netdev
In-Reply-To: <1317068935.2796.12.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 26 Sep 2011 22:28:55 +0200
> Le lundi 26 septembre 2011 à 17:11 -0300, brenohl@br.ibm.com a écrit :
>> Currently ehea ndo_get_stats can sleep in two places, in a hcall
>> and in a GFP_KERNEL alloc, which is not correct.
>> This patch creates a delayed workqueue that grabs the information each 1
>> sec from the hardware, and place it into the device structure, so that,
>> .ndo_get_stats quickly returns the device structure statistics block.
>>
>> Signed-off-by: Breno Leitao <brenohl@br.ibm.com>
>> ---
>
> Seems good, thanks
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ 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