* [PATCH v2 net-next] via-rhine: add 64bit statistics.
From: Jamie Gloudon @ 2013-01-24 4:05 UTC (permalink / raw)
To: netdev; +Cc: davem, eric.dumazet
Switch to use ndo_get_stats64 to get 64bit statistics.
Signed-off-by: Jamie Gloudon <jamie.gloudon@gmail.com>
Tested-by: Jamie Gloudon <jamie.gloudon@gmail.com>
---
drivers/net/ethernet/via/via-rhine.c | 47 ++++++++++++++++++++++++++++++------
1 file changed, 39 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/via/via-rhine.c b/drivers/net/ethernet/via/via-rhine.c
index eab63e1..ec4a5e1 100644
--- a/drivers/net/ethernet/via/via-rhine.c
+++ b/drivers/net/ethernet/via/via-rhine.c
@@ -417,6 +417,12 @@ enum chip_cmd_bits {
Cmd1NoTxPoll=0x08, Cmd1Reset=0x80,
};
+struct rhine_stats {
+ u64 packets;
+ u64 bytes;
+ struct u64_stats_sync syncp;
+};
+
struct rhine_private {
/* Bit mask for configured VLAN ids */
unsigned long active_vlans[BITS_TO_LONGS(VLAN_N_VID)];
@@ -458,6 +464,8 @@ struct rhine_private {
unsigned int cur_rx, dirty_rx; /* Producer/consumer ring indices */
unsigned int cur_tx, dirty_tx;
unsigned int rx_buf_sz; /* Based on MTU+slack. */
+ struct rhine_stats rx_stats;
+ struct rhine_stats tx_stats;
u8 wolopts;
u8 tx_thresh, rx_thresh;
@@ -495,7 +503,8 @@ static irqreturn_t rhine_interrupt(int irq, void *dev_instance);
static void rhine_tx(struct net_device *dev);
static int rhine_rx(struct net_device *dev, int limit);
static void rhine_set_rx_mode(struct net_device *dev);
-static struct net_device_stats *rhine_get_stats(struct net_device *dev);
+static struct rtnl_link_stats64 *rhine_get_stats64(struct net_device *dev,
+ struct rtnl_link_stats64 *stats);
static int netdev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
static const struct ethtool_ops netdev_ethtool_ops;
static int rhine_close(struct net_device *dev);
@@ -842,7 +851,7 @@ static const struct net_device_ops rhine_netdev_ops = {
.ndo_open = rhine_open,
.ndo_stop = rhine_close,
.ndo_start_xmit = rhine_start_tx,
- .ndo_get_stats = rhine_get_stats,
+ .ndo_get_stats64 = rhine_get_stats64,
.ndo_set_rx_mode = rhine_set_rx_mode,
.ndo_change_mtu = eth_change_mtu,
.ndo_validate_addr = eth_validate_addr,
@@ -1790,8 +1799,11 @@ static void rhine_tx(struct net_device *dev)
dev->stats.collisions += txstatus & 0x0F;
netif_dbg(rp, tx_done, dev, "collisions: %1.1x:%1.1x\n",
(txstatus >> 3) & 0xF, txstatus & 0xF);
- dev->stats.tx_bytes += rp->tx_skbuff[entry]->len;
- dev->stats.tx_packets++;
+
+ u64_stats_update_begin(&rp->tx_stats.syncp);
+ rp->tx_stats.bytes += rp->tx_skbuff[entry]->len;
+ rp->tx_stats.packets++;
+ u64_stats_update_end(&rp->tx_stats.syncp);
}
/* Free the original skb. */
if (rp->tx_skbuff_dma[entry]) {
@@ -1923,8 +1935,11 @@ static int rhine_rx(struct net_device *dev, int limit)
if (unlikely(desc_length & DescTag))
__vlan_hwaccel_put_tag(skb, vlan_tci);
netif_receive_skb(skb);
- dev->stats.rx_bytes += pkt_len;
- dev->stats.rx_packets++;
+
+ u64_stats_update_begin(&rp->rx_stats.syncp);
+ rp->rx_stats.bytes += pkt_len;
+ rp->rx_stats.packets++;
+ u64_stats_update_end(&rp->rx_stats.syncp);
}
entry = (++rp->cur_rx) % RX_RING_SIZE;
rp->rx_head_desc = &rp->rx_ring[entry];
@@ -2019,15 +2034,31 @@ out_unlock:
mutex_unlock(&rp->task_lock);
}
-static struct net_device_stats *rhine_get_stats(struct net_device *dev)
+static struct rtnl_link_stats64 *
+rhine_get_stats64(struct net_device *dev, struct rtnl_link_stats64 *stats)
{
struct rhine_private *rp = netdev_priv(dev);
+ unsigned int start;
spin_lock_bh(&rp->lock);
rhine_update_rx_crc_and_missed_errord(rp);
spin_unlock_bh(&rp->lock);
- return &dev->stats;
+ netdev_stats_to_stats64(stats, &dev->stats);
+
+ do {
+ start = u64_stats_fetch_begin_bh(&rp->rx_stats.syncp);
+ stats->rx_packets = rp->rx_stats.packets;
+ stats->rx_bytes = rp->rx_stats.bytes;
+ } while (u64_stats_fetch_retry_bh(&rp->rx_stats.syncp, start));
+
+ do {
+ start = u64_stats_fetch_begin_bh(&rp->tx_stats.syncp);
+ stats->tx_packets = rp->tx_stats.packets;
+ stats->tx_bytes = rp->tx_stats.bytes;
+ } while (u64_stats_fetch_retry_bh(&rp->tx_stats.syncp, start));
+
+ return stats;
}
static void rhine_set_rx_mode(struct net_device *dev)
--
1.7.12
^ permalink raw reply related
* Re: [PATCH RESEND] ipv6: add anti-spoofing checks for 6to4 and 6rd
From: YOSHIFUJI Hideaki @ 2013-01-24 3:59 UTC (permalink / raw)
To: netdev, davem; +Cc: YOSHIFUJI Hideaki
In-Reply-To: <20130123100248.GB7317@order.stressinduktion.org>
(2013年01月23日 19:02), Hannes Frederic Sowa wrote:
> This patch adds anti-spoofing checks in sit.c as specified in RFC3964
> section 5.2 for 6to4 and RFC5969 section 12 for 6rd. I left out the
> checks which could easily be implemented with netfilter.
>
> Specifically this patch adds following logic (based loosely on the
> pseudocode in RFC3964 section 5.2):
>
> if prefix (inner_src_v6) == rd6_prefix (2002::/16 is the default)
> and outer_src_v4 != embedded_ipv4 (inner_src_v6)
> drop
> if prefix (inner_dst_v6) == rd6_prefix (or 2002::/16 is the default)
> and outer_dst_v4 != embedded_ipv4 (inner_dst_v6)
> drop
> accept
>
> To accomplish the specified security checks proposed by above RFCs,
> it is still necessary to employ uRPF filters with netfilter. These new
> checks only kick in if the employed addresses are within the 2002::/16 or
> another range specified by the 6rd-prefix (which defaults to 2002::/16).
>
> Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> Cc: David Miller <davem@davemloft.net>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> ---
> net/ipv6/sit.c | 29 +++++++++++++++++++++++++++--
> 1 file changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
> index cfba99b..5a09f13 100644
> --- a/net/ipv6/sit.c
> +++ b/net/ipv6/sit.c
> @@ -73,6 +73,8 @@ static int ipip6_tunnel_init(struct net_device *dev);
> static void ipip6_tunnel_setup(struct net_device *dev);
> static void ipip6_dev_free(struct net_device *dev);
> static struct rtnl_link_ops sit_link_ops __read_mostly;
> +static inline __be32 try_6rd(const struct in6_addr *v6dst,
> + struct ip_tunnel *tunnel);
>
> static int sit_net_id __read_mostly;
> struct sit_net {
> @@ -590,6 +592,22 @@ out:
> return err;
> }
>
> +static int sit_chk_encap_addr(struct ip_tunnel *tunnel, const __be32 *addr,
> + const struct in6_addr *addr6)
> +{
> +#ifdef CONFIG_IPV6_SIT_6RD
> + if (ipv6_prefix_equal(addr6, &tunnel->ip6rd.prefix,
> + tunnel->ip6rd.prefixlen) &&
> + *addr != try_6rd(addr6, tunnel))
> + return 0;
> +#else
> + if (addr6->s6_addr16[0] == htons(0x2002) &&
> + *addr != try_6rd(addr6, tunnel))
> + return 0;
> +#endif
> + return 1;
> +}
> +
I need to do more research. I am still not convinced
to have such destination check here because the standard
seems silent about it, and we have several basic checks
in standard input path and tunnel search.
Anyway, try_6rd() can do check for prefix as well
but we are doing slightly different thing.
So I think we can introduce new __check_6rd() to
return non-6rd/6to4 addresses.
bool __check_6rd(struct ip_tunnel *tunnel,
const struct in6_addr *v6dst,
__be32 *v4dst);
If prefix matches, fill *v4dst and return true.
Otherwise, return false.
__be32 __try_6rd()
{
__be32 dst = 0;
__check_6rd(tunnel, v6dst, &dst);
return dst;
}
--yoshfuji
^ permalink raw reply
* Re: [PATCH 2/2] tuntap: limit the number of flow caches
From: Jason Wang @ 2013-01-24 3:22 UTC (permalink / raw)
To: David Miller; +Cc: mst, netdev, linux-kernel, stephen
In-Reply-To: <20130123.135024.1407137924304146015.davem@davemloft.net>
On 01/24/2013 02:50 AM, David Miller wrote:
> From: Jason Wang <jasowang@redhat.com>
> Date: Wed, 23 Jan 2013 21:59:13 +0800
>
>> We create new flow caches when a new flow is identified by tuntap, This may lead
>> some issues:
>>
>> - userspace may produce a huge amount of short live flows to exhaust host memory
>> - the unlimited number of flow caches may produce a long list which increase the
>> time in the linear searching
>>
>> Solve this by introducing a limit of total number of flow caches.
>>
>> Cc: Stephen Hemminger <stephen@networkplumber.org>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> ---
> Applied, but really flow caches are an extremely broken concept especially
> when external entities control the population of such caches.
>
> We removed the routing cache of the ipv4 networking code exactly because
> this kind of crap does not work at all.
>
> Next you're going to have to add a delicately managed garbage
> collection scheme for this tuntap flow cache, and that will be tuned
> endlessly, when the real issue is that fundamentally this does not
> work.
>
> Instead, make the full lookup scale properly and use appropriate data
> structures. It won't be as fast as a simple hash table demux, but
> it'll actually be immune to growth issues and DoS attacks and give
> consistent and repeatable lookup performance regardless of traffic
> patterns.
Ok, I will rework it in 3.9.
Thanks
> --
> 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
* [PATCH v2] sctp: set association state to established in dupcook_a handler
From: xufengzhang.main @ 2013-01-24 2:44 UTC (permalink / raw)
To: vyasevich, nhorman, davem; +Cc: linux-sctp, netdev, linux-kernel
From: Xufeng Zhang <xufeng.zhang@windriver.com>
While sctp handling a duplicate COOKIE-ECHO and the action is
'Association restart', sctp_sf_do_dupcook_a() will processing
the unexpected COOKIE-ECHO for peer restart, but it does not set
the association state to SCTP_STATE_ESTABLISHED, so the association
could stuck in SCTP_STATE_SHUTDOWN_PENDING state forever.
This violates the sctp specification:
RFC 4960 5.2.4. Handle a COOKIE ECHO when a TCB Exists
Action
A) In this case, the peer may have restarted. .....
After this, the endpoint shall enter the ESTABLISHED state.
To resolve this problem, adding a SCTP_CMD_NEW_STATE cmd to the
command list before SCTP_CMD_REPLY cmd, this will set the restart
association to SCTP_STATE_ESTABLISHED state properly and also avoid
I-bit being set in the DATA chunk header when COOKIE_ACK is bundled
with DATA chunks.
Signed-off-by: Xufeng Zhang <xufeng.zhang@windriver.com>
---
v2:
- Put the SCTP_CMD_NEW_STATE command before SCTP_CMD_REPLY and after SCTP_CMD_EVENT_ULP
suggested by Vlad and Neil
- Improve the last paragraph of the commit header
net/sctp/sm_statefuns.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
index 618ec7e..5131fcf 100644
--- a/net/sctp/sm_statefuns.c
+++ b/net/sctp/sm_statefuns.c
@@ -1779,8 +1779,10 @@ static sctp_disposition_t sctp_sf_do_dupcook_a(struct net *net,
/* Update the content of current association. */
sctp_add_cmd_sf(commands, SCTP_CMD_UPDATE_ASSOC, SCTP_ASOC(new_asoc));
- sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(repl));
sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP, SCTP_ULPEVENT(ev));
+ sctp_add_cmd_sf(commands, SCTP_CMD_NEW_STATE,
+ SCTP_STATE(SCTP_STATE_ESTABLISHED));
+ sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(repl));
return SCTP_DISPOSITION_CONSUME;
nomem_ev:
--
1.7.0.2
^ permalink raw reply related
* Re: [PATCH V6 1/3] virtio-net: fix the set affinity bug when CPU IDs are not consecutive
From: Wanlong Gao @ 2013-01-24 2:28 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Rusty Russell, linux-kernel, Jason Wang, Eric Dumazet,
virtualization, netdev
In-Reply-To: <87hamavx4n.fsf@rustcorp.com.au>
On 01/22/2013 09:12 AM, Rusty Russell wrote:
> Wanlong Gao <gaowanlong@cn.fujitsu.com> writes:
>
>> As Michael mentioned, set affinity and select queue will not work very
>> well when CPU IDs are not consecutive, this can happen with hot unplug.
>> Fix this bug by traversal the online CPUs, and create a per cpu variable
>> to find the mapping from CPU to the preferable virtual-queue.
>
> This series looks fairly sane at a glance, to me, but MST is the Ack you
> need.
Hi Michael,
Any comments?
Thanks,
Wanlong Gao
>
> Thanks,
> Rusty.
>
^ permalink raw reply
* Re: [PATCH 1/2 net-next] net: fec: add napi support to improve proformance
From: Frank Li @ 2013-01-24 2:26 UTC (permalink / raw)
To: Eric Dumazet
Cc: Frank Li, shawn.guo, B38611, davem, linux-arm-kernel, netdev,
bhutchings, s.hauer
In-Reply-To: <1358948954.12374.758.camel@edumazet-glaptop>
2013/1/23 Eric Dumazet <eric.dumazet@gmail.com>:
> On Wed, 2013-01-23 at 15:37 +0800, Frank Li wrote:
>> 2013/1/23 Eric Dumazet <eric.dumazet@gmail.com>:
>> > On Wed, 2013-01-23 at 12:12 +0800, Frank Li wrote:
>> >> Add napi support
>> >>
>> >> Before this patch
>> >>
>> >> iperf -s -i 1
>> >> ------------------------------------------------------------
>> >> Server listening on TCP port 5001
>> >> TCP window size: 85.3 KByte (default)
>> >> ------------------------------------------------------------
>> >> [ 4] local 10.192.242.153 port 5001 connected with 10.192.242.138 port 50004
>> >> [ ID] Interval Transfer Bandwidth
>> >> [ 4] 0.0- 1.0 sec 41.2 MBytes 345 Mbits/sec
>> >> [ 4] 1.0- 2.0 sec 43.7 MBytes 367 Mbits/sec
>> >> [ 4] 2.0- 3.0 sec 42.8 MBytes 359 Mbits/sec
>> >> [ 4] 3.0- 4.0 sec 43.7 MBytes 367 Mbits/sec
>> >> [ 4] 4.0- 5.0 sec 42.7 MBytes 359 Mbits/sec
>> >> [ 4] 5.0- 6.0 sec 43.8 MBytes 367 Mbits/sec
>> >> [ 4] 6.0- 7.0 sec 43.0 MBytes 361 Mbits/sec
>> >>
>> >> After this patch
>> >> [ 4] 2.0- 3.0 sec 51.6 MBytes 433 Mbits/sec
>> >> [ 4] 3.0- 4.0 sec 51.8 MBytes 435 Mbits/sec
>> >> [ 4] 4.0- 5.0 sec 52.2 MBytes 438 Mbits/sec
>> >> [ 4] 5.0- 6.0 sec 52.1 MBytes 437 Mbits/sec
>> >> [ 4] 6.0- 7.0 sec 52.1 MBytes 437 Mbits/sec
>> >> [ 4] 7.0- 8.0 sec 52.3 MBytes 439 Mbits/sec
>> >
>> > Strange, as you still call netif_rx()
>> >
>> > NAPI should call netif_receive_skb() instead
>> >
>>
>> Thank you point out.
>> After re-test, I found performance is almost no change if use netif_receive_skb.
>> I am not sure if it is my NAPI implement problem.
>>
>> napi_gro_received is better than netif_receive_skb, but worse than netif_rx.
>>
>> From performance point view,
>>
>> netif_rx --- fastest
>> napi_gro_received --- middle, near to netif_rx
>> netif_receive_skb --- slowest, almost the same as original no-napi version.
>>
>> Do you have any idea about this phenomena?
>
> No idea, you'll have to find out using perf tool if available.
>
> Is your machine SMP, and the application running on another cpu than the
> softirq handler for your device ?
Yes, we support SMP. Possibly run on another cpu. I will check.
>
> A NAPI driver must call netif_receive_skb(), especially if
> the RX path does a full copy of the frame : Its hot in cpu cache and
> should be processed at once.
How about napi_gro_receive? is it correct function? I found many driver use it.
>
> Escaping to netif_rx() is only adding an extra softirq and risk of data
> being evicted from cpu caches.
>
> Here your performance increase only comes from hw_lock being not anymore
> locked in RX path.
>
>
>
^ permalink raw reply
* Re: [PATCH v3 1/1 net-next] net: fec: enable pause frame to improve rx prefomance for 1G network
From: Frank Li @ 2013-01-24 2:16 UTC (permalink / raw)
To: Ben Hutchings
Cc: Frank Li, shawn.guo, B38611, davem, linux-arm-kernel, netdev,
s.hauer
In-Reply-To: <1358973584.2658.14.camel@bwh-desktop.uk.solarflarecom.com>
2013/1/24 Ben Hutchings <bhutchings@solarflare.com>:
> On Thu, 2013-01-17 at 10:55 +0800, Frank Li wrote:
>> The limition of imx6 internal bus cause fec can't achieve 1G perfomance.
>> There will be many packages lost because FIFO over run.
>>
>> This patch enable pause frame flow control.
> [...]
>> --- a/drivers/net/ethernet/freescale/fec.c
>> +++ b/drivers/net/ethernet/freescale/fec.c
> [...]
>> +static int fec_enet_set_pauseparam(struct net_device *ndev,
>> + struct ethtool_pauseparam *pause)
>> +{
>> + struct fec_enet_private *fep = netdev_priv(ndev);
>> +
>> + if (pause->tx_pause != pause->rx_pause) {
>> + netdev_info(ndev,
>> + "hardware only support enable/disable both tx and rx");
>> + return -EINVAL;
>> + }
>> +
>> + fep->pause_flag = 0;
>> +
>> + /* tx pause must be same as rx pause */
>> + fep->pause_flag |= pause->rx_pause ? FEC_PAUSE_FLAG_ENABLE : 0;
>> + fep->pause_flag |= pause->autoneg ? FEC_PAUSE_FLAG_AUTONEG : 0;
>> +
>> + if (pause->rx_pause || pause->autoneg) {
>> + fep->phy_dev->supported |= ADVERTISED_Pause;
>> + fep->phy_dev->advertising |= ADVERTISED_Pause;
>> + } else {
>> + fep->phy_dev->supported &= ~ADVERTISED_Pause;
>> + fep->phy_dev->advertising &= ~ADVERTISED_Pause;
>> + }
> [...]
>
> Why is this changing the supported flags, i.e. device capabilities? You
> need to leave those flags alone and reject an attempt to enable pause
> frames on a device that doesn't support them.
I go through phylib, I have not found good place set ADVERTISED_Pause
capabilities.
genphy_config_init never check Pause capabilities.
>
> Ben.
>
> --
> Ben Hutchings, Staff Engineer, Solarflare
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
>
^ permalink raw reply
* Re: v3 for tcp friends?
From: Xiaotian Feng @ 2013-01-24 2:04 UTC (permalink / raw)
To: Li Yu; +Cc: netdev, David Miller, Eric Dumazet, Bruce Curtis
In-Reply-To: <50FFAFE7.5030707@gmail.com>
On Wed, Jan 23, 2013 at 5:39 PM, Li Yu <raise.sail@gmail.com> wrote:
> 于 2013年01月23日 15:58, Li Yu 写道:
>
>> 于 2013年01月23日 15:21, Li Yu 写道:
>>>
>>> 于 2013年01月23日 14:46, Eric Dumazet 写道:
>>>>
>>>> On Wed, 2013-01-23 at 14:12 +0800, Li Yu wrote:
>>>>>
>>>>> Oops, this hang is not since TCP friends patch!
>>>>>
>>>>> sk_sndbuf_get() is broken by 32 bits integer overflow
>>>>> because of so large value in net.ipv4.tcp_{rmem,wmem}.
>>>>>
>>>>> but this hang also can be found in net-next.git
>>>>> (3.8.0-rc3+), if we run below commands, then all new
>>>>> TCP connections stop working!
>>>>>
>>>>> # when TCP friends is disabled
>>>>> sysctl -w net.ipv4.tcp_rmem="4096 4294967296 4294967296" # 4GB
>>>>> sysctl -w net.ipv4.tcp_wmem="4096 4294967296 4294967296"
>>>>
>>>>
>>>> Right we need to make sure we dont overflow.
>>>>
>>>> Try the following fix :
>>>>
>>>> diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
>>>> index a25e1d2..1459145 100644
>>>> --- a/net/ipv4/sysctl_net_ipv4.c
>>>> +++ b/net/ipv4/sysctl_net_ipv4.c
>>>> @@ -549,14 +549,16 @@ static struct ctl_table ipv4_table[] = {
>>>> .data = &sysctl_tcp_wmem,
>>>> .maxlen = sizeof(sysctl_tcp_wmem),
>>>> .mode = 0644,
>>>> - .proc_handler = proc_dointvec
>>>> + .extra1 = &zero,
>
>
> If we added below:
>
> +static int one = 1;
one is defined in kernel/sysctl.c
> +static int int_max = INT_MAX;
> ....
> + .extra1 = &one,
> + .extra2 = &int_max,
I believe INT_MAX does not have actual effect, because any value
bigger than INT_MAX will be cast to negative value, which is prevented
by extra1...
>
> The bug is fixed without TCP friends.
>
> Maybe, TCP friends need to use long integer to record result
> of "sk->sk_sndbuf + sk->sk_friend->sk_rcvbuf" ?
>
> BTW: This overflow problem also breaks UDP sockets.
>
> Thanks
>
> Yu
>
>
>>>> + .proc_handler = proc_dointvec_minmax
>>>> },
>>>> {
>>>> .procname = "tcp_rmem",
>>>> .data = &sysctl_tcp_rmem,
>>>> .maxlen = sizeof(sysctl_tcp_rmem),
>>>> .mode = 0644,
>>>> - .proc_handler = proc_dointvec
>>>> + .extra1 = &zero,
>>>> + .proc_handler = proc_dointvec_minmax
>>>> },
>>>> {
>>>> .procname = "tcp_app_win",
>>>>
>>>>
>>>>
>>> Thanks for so quick reply, I will test it soon.
>>>
>>> however I suspect whether this patch could fix overflow if we merged TCP
>>> friends patch in future.
>>>
>>
>> Tested on 3.7.0-rc1+, but bug is still alive
>> with disabled TCP friends ...
>>
>> Thanks
>>
>> Yu
>>
>>> With TCP friends, we have source like below, or TCP friends should care
>>> this ?
>>>
>>> static inline int sk_sndbuf_get(const struct sock *sk)
>>> {
>>> if (sk->sk_friend)
>>> return sk->sk_sndbuf + sk->sk_friend->sk_rcvbuf;
>>> else
>>> return sk->sk_sndbuf;
>>> }
>>>
>>> static inline bool sk_stream_memory_free(const struct sock *sk)
>>> {
>>> return sk_wmem_queued_get(sk) < sk_sndbuf_get(sk);
>>> }
>>>
>>> So sk_sndbuf_get() still may be overflow when we have right value in
>>> net.ipv4.tcp_{rmem,wmem}.
>>>
>>> Thanks
>>
>>
>
> --
> 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: 3.7.3+: Bad paging request in ip_rcv_finish while running NFS traffic.
From: Eric Dumazet @ 2013-01-24 1:45 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <1358989843.12374.1334.camel@edumazet-glaptop>
On Wed, 2013-01-23 at 17:10 -0800, Eric Dumazet wrote:
> Excellent, thats the bug.
>
> I'll send a fix asap, thanks !
loopback device doesnt have a qdisc, and unsets IFF_XMIT_DST_RELEASE
Its hard to believe such an old bug never hit us in the past.
Probably because most of the time, the packet given to netif_rx() is
immediately processed (and loopback device is hard wired ?)
diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
index 81f8f9e..fcbf680 100644
--- a/drivers/net/loopback.c
+++ b/drivers/net/loopback.c
@@ -77,6 +77,11 @@ static netdev_tx_t loopback_xmit(struct sk_buff *skb,
skb_orphan(skb);
+ /* Before queueing this packet to netif_rx(),
+ * make sure dst is refcounted.
+ */
+ skb_dst_force(skb);
+
skb->protocol = eth_type_trans(skb, dev);
/* it's OK to use per_cpu_ptr() because BHs are off */
^ permalink raw reply related
* Re: [PATCH] sctp: set association state to established in dupcook_a handler
From: Xufeng Zhang @ 2013-01-24 1:36 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: Neil Horman, sri, davem, linux-sctp, netdev, linux-kernel
In-Reply-To: <50FFF218.1010204@gmail.com>
On 1/23/13, Vlad Yasevich <vyasevich@gmail.com> wrote:
> On 01/23/2013 08:46 AM, Neil Horman wrote:
>> On Wed, Jan 23, 2013 at 03:38:40PM +0800, xufengzhang.main@gmail.com
>> wrote:
>>> From: Xufeng Zhang <xufeng.zhang@windriver.com>
>>>
>>> While sctp handling a duplicate COOKIE-ECHO and the action is
>>> 'Association restart', sctp_sf_do_dupcook_a() will processing
>>> the unexpected COOKIE-ECHO for peer restart, but it does not set
>>> the association state to SCTP_STATE_ESTABLISHED, so the association
>>> could stuck in SCTP_STATE_SHUTDOWN_PENDING state forever.
>>> This violates the sctp specification:
>>> RFC 4960 5.2.4. Handle a COOKIE ECHO when a TCB Exists
>>> Action
>>> A) In this case, the peer may have restarted. .....
>>> After this, the endpoint shall enter the ESTABLISHED state.
>>>
>>> Fix this problem by adding a SCTP_CMD_NEW_STATE cmd to the command
>>> list so as to set the restart association to SCTP_STATE_ESTABLISHED
>>> state properly.
>>>
>>> Signed-off-by: Xufeng Zhang <xufeng.zhang@windriver.com>
>>> ---
>>> net/sctp/sm_statefuns.c | 2 ++
>>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
>>> index 618ec7e..528f1c8 100644
>>> --- a/net/sctp/sm_statefuns.c
>>> +++ b/net/sctp/sm_statefuns.c
>>> @@ -1779,6 +1779,8 @@ static sctp_disposition_t
>>> sctp_sf_do_dupcook_a(struct net *net,
>>>
>>> /* Update the content of current association. */
>>> sctp_add_cmd_sf(commands, SCTP_CMD_UPDATE_ASSOC,
>>> SCTP_ASOC(new_asoc));
>>> + sctp_add_cmd_sf(commands, SCTP_CMD_NEW_STATE,
>>> + SCTP_STATE(SCTP_STATE_ESTABLISHED));
>>> sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(repl));
>>> sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP, SCTP_ULPEVENT(ev));
>>> return SCTP_DISPOSITION_CONSUME;
>>> --
>>> 1.7.0.2
>>>
>>>
>>
>> Looks reasonable to me, thanks
>>
>> nit: The RFC indicate the association should enter the ESTABLISHED state
>> after
>> preforming all other actions, so it seems that the state change should
>> occur
>> after the ULP event is sent
>>
>
> I have a slight concern here that if we change state last, then any data
> that may have been bundled with COOKIE-ACK as part of CMD_REPLY will get
> the SACK_IMMEDIATE flag set since we are still in the SHUTDOWN_PENDING
> state.
>
> I would be more correct (and would match sctp_sf_do_5_1D_ce) to
> do it in this order:
> UPDATE_ASSOC - resets all the congestion/association variables
> EVENT_UP - send RESTART to USER
> NEW_STATE - set ESTABLISHED state (as per spec)
> REPLY - Send cookie-ack along with any pending data.
Yep, I agree with you, I'll send V2 patch based on your suggestion.
Thanks for your review!
Thanks,
Xufeng
>
> -vlad
>> Neil
>>
>
>
^ permalink raw reply
* Re: [PATCH] sctp: set association state to established in dupcook_a handler
From: Xufeng Zhang @ 2013-01-24 1:34 UTC (permalink / raw)
To: Neil Horman; +Cc: vyasevich, sri, davem, linux-sctp, netdev, linux-kernel
In-Reply-To: <20130123134650.GA3512@hmsreliant.think-freely.org>
On 1/23/13, Neil Horman <nhorman@tuxdriver.com> wrote:
> On Wed, Jan 23, 2013 at 03:38:40PM +0800, xufengzhang.main@gmail.com wrote:
>> From: Xufeng Zhang <xufeng.zhang@windriver.com>
>>
>> While sctp handling a duplicate COOKIE-ECHO and the action is
>> 'Association restart', sctp_sf_do_dupcook_a() will processing
>> the unexpected COOKIE-ECHO for peer restart, but it does not set
>> the association state to SCTP_STATE_ESTABLISHED, so the association
>> could stuck in SCTP_STATE_SHUTDOWN_PENDING state forever.
>> This violates the sctp specification:
>> RFC 4960 5.2.4. Handle a COOKIE ECHO when a TCB Exists
>> Action
>> A) In this case, the peer may have restarted. .....
>> After this, the endpoint shall enter the ESTABLISHED state.
>>
>> Fix this problem by adding a SCTP_CMD_NEW_STATE cmd to the command
>> list so as to set the restart association to SCTP_STATE_ESTABLISHED
>> state properly.
>>
>> Signed-off-by: Xufeng Zhang <xufeng.zhang@windriver.com>
>> ---
>> net/sctp/sm_statefuns.c | 2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
>> index 618ec7e..528f1c8 100644
>> --- a/net/sctp/sm_statefuns.c
>> +++ b/net/sctp/sm_statefuns.c
>> @@ -1779,6 +1779,8 @@ static sctp_disposition_t
>> sctp_sf_do_dupcook_a(struct net *net,
>>
>> /* Update the content of current association. */
>> sctp_add_cmd_sf(commands, SCTP_CMD_UPDATE_ASSOC, SCTP_ASOC(new_asoc));
>> + sctp_add_cmd_sf(commands, SCTP_CMD_NEW_STATE,
>> + SCTP_STATE(SCTP_STATE_ESTABLISHED));
>> sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(repl));
>> sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP, SCTP_ULPEVENT(ev));
>> return SCTP_DISPOSITION_CONSUME;
>> --
>> 1.7.0.2
>>
>>
>
> Looks reasonable to me, thanks
>
> nit: The RFC indicate the association should enter the ESTABLISHED state
> after
> preforming all other actions, so it seems that the state change should
> occur
> after the ULP event is sent
Good catch! I'll do what vlad suggested.
Thanks for your review!
Thanks,
Xufeng
>
> Neil
>
>
^ permalink raw reply
* Re: 3.7.3+: Bad paging request in ip_rcv_finish while running NFS traffic.
From: Eric Dumazet @ 2013-01-24 1:10 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <51008900.2010803@candelatech.com>
On Wed, 2013-01-23 at 17:06 -0800, Ben Greear wrote:
> On 01/23/2013 05:00 PM, Eric Dumazet wrote:
> > On Wed, 2013-01-23 at 16:51 -0800, Ben Greear wrote:
> >
> >>
> >> I was poking around in drivers/net/loopback.c. Maybe it needs
> >> to clean up the skb_dst() before calling the rx logic in the
> >> loopback_xmit method?
> >
> > Nope. Its ok there. We need a dst for loopback
>
> Here's the crash with the BUG_ON(). Did I understand your
> suggestion properly? This hit immediately when booting.
>
>
> int netif_rx(struct sk_buff *skb)
> {
> int ret;
>
> BUG_ON(skb->_skb_refdst & SKB_DST_NOREF);
>
> /* if netpoll wants it, pretend we never saw it */
> if (netpoll_rx(skb))
> return NET_RX_DROP;
>
>
> kernel BUG at /home/greearb/git/linux-3.7.dev.y/net/core/dev.c:2982!
> invalid opcode: 0000 [#1] PREEMPT SMP
> Modules linked in: lockd sunrpc macvlan pktgen uinput coretemp hwmon kvm_intel kvm iTCO_wdt iTCO_vendor_e
> CPU 0
> Pid: 1554, comm: btserver Tainted: G C O 3.7.3+ #51 Iron Systems Inc. EE2610R/X8ST3
> RIP: 0010:[<ffffffff8147685a>] [<ffffffff8147685a>] netif_rx+0x14/0x109
> RSP: 0018:ffff8804030359a8 EFLAGS: 00010202
> RAX: 0000000000000000 RBX: ffff8803fff3a2f0 RCX: ffff88040d3b4490
> RDX: ffff880403035a08 RSI: ffff88040d3f8000 RDI: ffff8803fff3a2f0
> RBP: ffff8804030359d8 R08: 0000000000000001 R09: 0000000000000000
> R10: ffffffff81472e61 R11: ffff8803fff62cc0 R12: 0000000000016ff0
> R13: 000000000000003c R14: ffff88041fc00000 R15: ffffffff81670560
> FS: 00007fcbd5c01740(0000) GS:ffff88041fc00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000439004 CR3: 00000003ff68d000 CR4: 00000000000007f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process btserver (pid: 1554, threadinfo ffff880403034000, task ffff880407e09f50)
> Stack:
> ffff8804030359d8 ffffffff814c0290 ffff880403035a08 ffff8803fff3a2f0
> ffff8803fff3a2f0 0000000000016ff0 ffff880403035a08 ffffffff813a3c4d
> ffff8803fff3a2f0 ffff88040d3f8000 00000000a01b7c08 ffff88040d0b7400
> Call Trace:
> [<ffffffff814c0290>] ? tcp_wfree+0xc0/0xc8
> [<ffffffff813a3c4d>] loopback_xmit+0x64/0x83
> [<ffffffff81477364>] dev_hard_start_xmit+0x26c/0x35e
> [<ffffffff8147771a>] dev_queue_xmit+0x2c4/0x37c
> [<ffffffff81477456>] ? dev_hard_start_xmit+0x35e/0x35e
> [<ffffffff8148cfa6>] ? eth_header+0x28/0xb6
> [<ffffffff81480f09>] neigh_resolve_output+0x176/0x1a7
> [<ffffffff814ad835>] ip_finish_output2+0x297/0x30d
> [<ffffffff814ad6d5>] ? ip_finish_output2+0x137/0x30d
> [<ffffffff814ad90e>] ip_finish_output+0x63/0x68
> [<ffffffff814ae412>] ip_output+0x61/0x67
> [<ffffffff814ab904>] dst_output+0x17/0x1b
> [<ffffffff814adb6d>] ip_local_out+0x1e/0x23
> [<ffffffff814ae1c4>] ip_queue_xmit+0x315/0x353
> [<ffffffff814adeaf>] ? ip_send_unicast_reply+0x2cc/0x2cc
> [<ffffffff814c018f>] tcp_transmit_skb+0x7ca/0x80b
> [<ffffffff814c3571>] tcp_connect+0x53c/0x587
> [<ffffffff810c2f0c>] ? getnstimeofday+0x44/0x7d
> [<ffffffff810c2f56>] ? ktime_get_real+0x11/0x3e
> [<ffffffff814c6f9b>] tcp_v4_connect+0x3c2/0x431
> [<ffffffff814d6913>] __inet_stream_connect+0x84/0x287
> [<ffffffff814d6b38>] ? inet_stream_connect+0x22/0x49
> [<ffffffff8108d695>] ? _local_bh_enable_ip+0x84/0x9f
> [<ffffffff8108d6c8>] ? local_bh_enable+0xd/0x11
> [<ffffffff8146763c>] ? lock_sock_nested+0x6e/0x79
> [<ffffffff814d6b38>] ? inet_stream_connect+0x22/0x49
> [<ffffffff814d6b49>] inet_stream_connect+0x33/0x49
> [<ffffffff814632c6>] sys_connect+0x75/0x98
> [<ffffffff811551fd>] ? path_put+0x1d/0x21
> [<ffffffff810e8d06>] ? __audit_syscall_entry+0x11c/0x148
> [<ffffffff8128a509>] ? lockdep_sys_exit_thunk+0x35/0x67
> [<ffffffff81162f8b>] ? __fd_install+0x26/0x52
> [<ffffffff81537e69>] system_call_fastpath+0x16/0x1b
> Code: 49 8b 5c 24 10 48 8b 43 68 48 85 c0 0f 85 5e fe ff ff e9 79 fe ff ff 55 48 89 e5 41 54 53 48 89 fb
> RIP [<ffffffff8147685a>] netif_rx+0x14/0x109
> RSP <ffff8804030359a8>
> ... DONE
Excellent, thats the bug.
I'll send a fix asap, thanks !
^ permalink raw reply
* Re: 3.7.3+: Bad paging request in ip_rcv_finish while running NFS traffic.
From: Ben Greear @ 2013-01-24 1:06 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1358989242.12374.1323.camel@edumazet-glaptop>
On 01/23/2013 05:00 PM, Eric Dumazet wrote:
> On Wed, 2013-01-23 at 16:51 -0800, Ben Greear wrote:
>
>>
>> I was poking around in drivers/net/loopback.c. Maybe it needs
>> to clean up the skb_dst() before calling the rx logic in the
>> loopback_xmit method?
>
> Nope. Its ok there. We need a dst for loopback
Here's the crash with the BUG_ON(). Did I understand your
suggestion properly? This hit immediately when booting.
int netif_rx(struct sk_buff *skb)
{
int ret;
BUG_ON(skb->_skb_refdst & SKB_DST_NOREF);
/* if netpoll wants it, pretend we never saw it */
if (netpoll_rx(skb))
return NET_RX_DROP;
kernel BUG at /home/greearb/git/linux-3.7.dev.y/net/core/dev.c:2982!
invalid opcode: 0000 [#1] PREEMPT SMP
Modules linked in: lockd sunrpc macvlan pktgen uinput coretemp hwmon kvm_intel kvm iTCO_wdt iTCO_vendor_e
CPU 0
Pid: 1554, comm: btserver Tainted: G C O 3.7.3+ #51 Iron Systems Inc. EE2610R/X8ST3
RIP: 0010:[<ffffffff8147685a>] [<ffffffff8147685a>] netif_rx+0x14/0x109
RSP: 0018:ffff8804030359a8 EFLAGS: 00010202
RAX: 0000000000000000 RBX: ffff8803fff3a2f0 RCX: ffff88040d3b4490
RDX: ffff880403035a08 RSI: ffff88040d3f8000 RDI: ffff8803fff3a2f0
RBP: ffff8804030359d8 R08: 0000000000000001 R09: 0000000000000000
R10: ffffffff81472e61 R11: ffff8803fff62cc0 R12: 0000000000016ff0
R13: 000000000000003c R14: ffff88041fc00000 R15: ffffffff81670560
FS: 00007fcbd5c01740(0000) GS:ffff88041fc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000439004 CR3: 00000003ff68d000 CR4: 00000000000007f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process btserver (pid: 1554, threadinfo ffff880403034000, task ffff880407e09f50)
Stack:
ffff8804030359d8 ffffffff814c0290 ffff880403035a08 ffff8803fff3a2f0
ffff8803fff3a2f0 0000000000016ff0 ffff880403035a08 ffffffff813a3c4d
ffff8803fff3a2f0 ffff88040d3f8000 00000000a01b7c08 ffff88040d0b7400
Call Trace:
[<ffffffff814c0290>] ? tcp_wfree+0xc0/0xc8
[<ffffffff813a3c4d>] loopback_xmit+0x64/0x83
[<ffffffff81477364>] dev_hard_start_xmit+0x26c/0x35e
[<ffffffff8147771a>] dev_queue_xmit+0x2c4/0x37c
[<ffffffff81477456>] ? dev_hard_start_xmit+0x35e/0x35e
[<ffffffff8148cfa6>] ? eth_header+0x28/0xb6
[<ffffffff81480f09>] neigh_resolve_output+0x176/0x1a7
[<ffffffff814ad835>] ip_finish_output2+0x297/0x30d
[<ffffffff814ad6d5>] ? ip_finish_output2+0x137/0x30d
[<ffffffff814ad90e>] ip_finish_output+0x63/0x68
[<ffffffff814ae412>] ip_output+0x61/0x67
[<ffffffff814ab904>] dst_output+0x17/0x1b
[<ffffffff814adb6d>] ip_local_out+0x1e/0x23
[<ffffffff814ae1c4>] ip_queue_xmit+0x315/0x353
[<ffffffff814adeaf>] ? ip_send_unicast_reply+0x2cc/0x2cc
[<ffffffff814c018f>] tcp_transmit_skb+0x7ca/0x80b
[<ffffffff814c3571>] tcp_connect+0x53c/0x587
[<ffffffff810c2f0c>] ? getnstimeofday+0x44/0x7d
[<ffffffff810c2f56>] ? ktime_get_real+0x11/0x3e
[<ffffffff814c6f9b>] tcp_v4_connect+0x3c2/0x431
[<ffffffff814d6913>] __inet_stream_connect+0x84/0x287
[<ffffffff814d6b38>] ? inet_stream_connect+0x22/0x49
[<ffffffff8108d695>] ? _local_bh_enable_ip+0x84/0x9f
[<ffffffff8108d6c8>] ? local_bh_enable+0xd/0x11
[<ffffffff8146763c>] ? lock_sock_nested+0x6e/0x79
[<ffffffff814d6b38>] ? inet_stream_connect+0x22/0x49
[<ffffffff814d6b49>] inet_stream_connect+0x33/0x49
[<ffffffff814632c6>] sys_connect+0x75/0x98
[<ffffffff811551fd>] ? path_put+0x1d/0x21
[<ffffffff810e8d06>] ? __audit_syscall_entry+0x11c/0x148
[<ffffffff8128a509>] ? lockdep_sys_exit_thunk+0x35/0x67
[<ffffffff81162f8b>] ? __fd_install+0x26/0x52
[<ffffffff81537e69>] system_call_fastpath+0x16/0x1b
Code: 49 8b 5c 24 10 48 8b 43 68 48 85 c0 0f 85 5e fe ff ff e9 79 fe ff ff 55 48 89 e5 41 54 53 48 89 fb
RIP [<ffffffff8147685a>] netif_rx+0x14/0x109
RSP <ffff8804030359a8>
... DONE
>
>
>
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [BUG] via-rhine: NOHZ: local_softirq_pending 08
From: Jamie Gloudon @ 2013-01-24 1:04 UTC (permalink / raw)
To: netdev; +Cc: rl
In-Reply-To: <51007b84.03ab640a.1cde.fffff62a@mx.google.com>
On Wed, Jan 23, 2013 at 08:08:29PM -0400, Jamie Gloudon wrote:
> Hey,
>
> While conducting some tests on a VT6105M card. I noticed this message:
>
> kernel: [ 160.311113] NOHZ: local_softirq_pending 08
>
> I was able to reliably reproduce the error message by setting autoneg off and changing the interface speed from 100 to 10 with ethtool.
>
> Regards,
> Jamie Gloudon
I forget to mention this error message occur on stable 3.7.
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the mips tree
From: Stephen Rothwell @ 2013-01-24 1:03 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Ralf Baechle, Tom Herbert
[-- Attachment #1: Type: text/plain, Size: 1437 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
arch/mips/include/uapi/asm/socket.h between commit c4ff4842935c ("MIPS:
Whitespace cleanup") from the mips tree and commit 055dc21a1d1d
("soreuseport: infrastructure") from the net-next tree.
Also, that net-next tree patch can't be right (it removes an "#if 0" but
not the matching "#endif") - I fixed that as well.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/mips/include/uapi/asm/socket.h
index cc208f9,7e27236..0000000
--- a/arch/mips/include/uapi/asm/socket.h
+++ b/arch/mips/include/uapi/asm/socket.h
@@@ -28,12 -28,11 +28,10 @@@
#define SO_LINGER 0x0080 /* Block on close of a reliable
socket to transmit pending data. */
#define SO_OOBINLINE 0x0100 /* Receive out-of-band data in-band. */
- #if 0
- To add: #define SO_REUSEPORT 0x0200 /* Allow local address and port reuse. */
- #endif
+ #define SO_REUSEPORT 0x0200 /* Allow local address and port reuse. */
-#endif
#define SO_TYPE 0x1008 /* Compatible name for SO_STYLE. */
-#define SO_STYLE SO_TYPE /* Synonym */
+#define SO_STYLE SO_TYPE /* Synonym */
#define SO_ERROR 0x1007 /* get error status and clear */
#define SO_SNDBUF 0x1001 /* Send buffer size. */
#define SO_RCVBUF 0x1002 /* Receive buffer. */
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: 3.7.3+: Bad paging request in ip_rcv_finish while running NFS traffic.
From: Eric Dumazet @ 2013-01-24 1:00 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <51008598.4000603@candelatech.com>
On Wed, 2013-01-23 at 16:51 -0800, Ben Greear wrote:
>
> I was poking around in drivers/net/loopback.c. Maybe it needs
> to clean up the skb_dst() before calling the rx logic in the
> loopback_xmit method?
Nope. Its ok there. We need a dst for loopback
^ permalink raw reply
* Re: 3.7.3+: Bad paging request in ip_rcv_finish while running NFS traffic.
From: Ben Greear @ 2013-01-24 0:51 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1358988358.12374.1303.camel@edumazet-glaptop>
On 01/23/2013 04:45 PM, Eric Dumazet wrote:
> On Wed, 2013-01-23 at 16:38 -0800, Ben Greear wrote:
>> On 01/23/2013 04:23 PM, Eric Dumazet wrote:
>>> On Wed, 2013-01-23 at 16:13 -0800, Ben Greear wrote:
>>>> On 01/23/2013 04:01 PM, Eric Dumazet wrote:
>>
>>>> I was worried that the dev_seq_stop might be called
>>>> incorrectly causing an asymetric unlock. I have no
>>>> idea how that might happened, but several crashes
>>>> have that dev_seq_stop method listed, so it got me suspicious.
>>>
>>> dev_seq_stop() is some word in the kernel stack, result of a prior
>>> system call. Stack is not cleanup.
>>>
>>> Each function reserves an amount of stack but not always write on all
>>> reserved space (some automatic variables might be not set)
>>>
>>> Note the "? " before the name : linux printed the symbol but this was
>>> not a call site for this particular call graph. Its only an extra
>>> indication, that can be useful sometimes.
>>
>> Ahh, thanks for that info...I'd never quite pieced that together
>> before.
>>
>> Here's another crash. Interestingly, the dst is bad before the rcu-read-lock()
>> (the bug is from the first of the 'deadbeef' debugging code below)
>>
>> Perhaps other useful info: The skb->dev claims to be 'lo'. The dst 'pointer'
>> in the skb has 0x1 set, so it is the 'noref' variant.
>>
>>
>> static int __netif_receive_skb(struct sk_buff *skb)
>> {
>> struct packet_type *ptype, *pt_prev;
>> rx_handler_func_t *rx_handler;
>> struct net_device *orig_dev;
>> struct net_device *null_or_dev;
>> bool deliver_exact = false;
>> int ret = NET_RX_DROP;
>> __be16 type;
>> unsigned long pflags = current->flags;
>>
>> net_timestamp_check(!netdev_tstamp_prequeue, skb);
>>
>> trace_netif_receive_skb(skb);
>>
>> /*
>> * PFMEMALLOC skbs are special, they should
>> * - be delivered to SOCK_MEMALLOC sockets only
>> * - stay away from userspace
>> * - have bounded memory usage
>> *
>> * Use PF_MEMALLOC as this saves us from propagating the allocation
>> * context down to all allocation sites.
>> */
>> if (sk_memalloc_socks() && skb_pfmemalloc(skb))
>> current->flags |= PF_MEMALLOC;
>>
>> /* if we've gotten here through NAPI, check netpoll */
>> if (netpoll_receive_skb(skb))
>> goto out;
>>
>> orig_dev = skb->dev;
>>
>> skb_reset_network_header(skb);
>> skb_reset_transport_header(skb);
>> skb_reset_mac_len(skb);
>>
>> pt_prev = NULL;
>>
>> if (skb_dst(skb)) {
>> if (skb_dst(skb)->input == 0xdeadbeef) {
>> printk("bad dst: %lu, skb->dev: %s len: %i\n",
>> skb->_skb_refdst, skb->dev->name, skb->len);
>> BUG_ON(1);
>> }
>> }
>>
>
> You should add your debuging code in netif_rx() so that we know the
> caller
>
> by the way you could only add
>
> BUG_ON(skb->_skb_refdst & SKB_DST_NOREF)
Ok, will add that.
I was poking around in drivers/net/loopback.c. Maybe it needs
to clean up the skb_dst() before calling the rx logic in the
loopback_xmit method?
Thanks,
ben
>
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: 3.7.3+: Bad paging request in ip_rcv_finish while running NFS traffic.
From: Eric Dumazet @ 2013-01-24 0:45 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <51008294.2010201@candelatech.com>
On Wed, 2013-01-23 at 16:38 -0800, Ben Greear wrote:
> On 01/23/2013 04:23 PM, Eric Dumazet wrote:
> > On Wed, 2013-01-23 at 16:13 -0800, Ben Greear wrote:
> >> On 01/23/2013 04:01 PM, Eric Dumazet wrote:
>
> >> I was worried that the dev_seq_stop might be called
> >> incorrectly causing an asymetric unlock. I have no
> >> idea how that might happened, but several crashes
> >> have that dev_seq_stop method listed, so it got me suspicious.
> >
> > dev_seq_stop() is some word in the kernel stack, result of a prior
> > system call. Stack is not cleanup.
> >
> > Each function reserves an amount of stack but not always write on all
> > reserved space (some automatic variables might be not set)
> >
> > Note the "? " before the name : linux printed the symbol but this was
> > not a call site for this particular call graph. Its only an extra
> > indication, that can be useful sometimes.
>
> Ahh, thanks for that info...I'd never quite pieced that together
> before.
>
> Here's another crash. Interestingly, the dst is bad before the rcu-read-lock()
> (the bug is from the first of the 'deadbeef' debugging code below)
>
> Perhaps other useful info: The skb->dev claims to be 'lo'. The dst 'pointer'
> in the skb has 0x1 set, so it is the 'noref' variant.
>
>
> static int __netif_receive_skb(struct sk_buff *skb)
> {
> struct packet_type *ptype, *pt_prev;
> rx_handler_func_t *rx_handler;
> struct net_device *orig_dev;
> struct net_device *null_or_dev;
> bool deliver_exact = false;
> int ret = NET_RX_DROP;
> __be16 type;
> unsigned long pflags = current->flags;
>
> net_timestamp_check(!netdev_tstamp_prequeue, skb);
>
> trace_netif_receive_skb(skb);
>
> /*
> * PFMEMALLOC skbs are special, they should
> * - be delivered to SOCK_MEMALLOC sockets only
> * - stay away from userspace
> * - have bounded memory usage
> *
> * Use PF_MEMALLOC as this saves us from propagating the allocation
> * context down to all allocation sites.
> */
> if (sk_memalloc_socks() && skb_pfmemalloc(skb))
> current->flags |= PF_MEMALLOC;
>
> /* if we've gotten here through NAPI, check netpoll */
> if (netpoll_receive_skb(skb))
> goto out;
>
> orig_dev = skb->dev;
>
> skb_reset_network_header(skb);
> skb_reset_transport_header(skb);
> skb_reset_mac_len(skb);
>
> pt_prev = NULL;
>
> if (skb_dst(skb)) {
> if (skb_dst(skb)->input == 0xdeadbeef) {
> printk("bad dst: %lu, skb->dev: %s len: %i\n",
> skb->_skb_refdst, skb->dev->name, skb->len);
> BUG_ON(1);
> }
> }
>
You should add your debuging code in netif_rx() so that we know the
caller
by the way you could only add
BUG_ON(skb->_skb_refdst & SKB_DST_NOREF)
^ permalink raw reply
* Re: 3.7.3+: Bad paging request in ip_rcv_finish while running NFS traffic.
From: Ben Greear @ 2013-01-24 0:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1358987031.12374.1276.camel@edumazet-glaptop>
On 01/23/2013 04:23 PM, Eric Dumazet wrote:
> On Wed, 2013-01-23 at 16:13 -0800, Ben Greear wrote:
>> On 01/23/2013 04:01 PM, Eric Dumazet wrote:
>> I was worried that the dev_seq_stop might be called
>> incorrectly causing an asymetric unlock. I have no
>> idea how that might happened, but several crashes
>> have that dev_seq_stop method listed, so it got me suspicious.
>
> dev_seq_stop() is some word in the kernel stack, result of a prior
> system call. Stack is not cleanup.
>
> Each function reserves an amount of stack but not always write on all
> reserved space (some automatic variables might be not set)
>
> Note the "? " before the name : linux printed the symbol but this was
> not a call site for this particular call graph. Its only an extra
> indication, that can be useful sometimes.
Ahh, thanks for that info...I'd never quite pieced that together
before.
Here's another crash. Interestingly, the dst is bad before the rcu-read-lock()
(the bug is from the first of the 'deadbeef' debugging code below)
Perhaps other useful info: The skb->dev claims to be 'lo'. The dst 'pointer'
in the skb has 0x1 set, so it is the 'noref' variant.
static int __netif_receive_skb(struct sk_buff *skb)
{
struct packet_type *ptype, *pt_prev;
rx_handler_func_t *rx_handler;
struct net_device *orig_dev;
struct net_device *null_or_dev;
bool deliver_exact = false;
int ret = NET_RX_DROP;
__be16 type;
unsigned long pflags = current->flags;
net_timestamp_check(!netdev_tstamp_prequeue, skb);
trace_netif_receive_skb(skb);
/*
* PFMEMALLOC skbs are special, they should
* - be delivered to SOCK_MEMALLOC sockets only
* - stay away from userspace
* - have bounded memory usage
*
* Use PF_MEMALLOC as this saves us from propagating the allocation
* context down to all allocation sites.
*/
if (sk_memalloc_socks() && skb_pfmemalloc(skb))
current->flags |= PF_MEMALLOC;
/* if we've gotten here through NAPI, check netpoll */
if (netpoll_receive_skb(skb))
goto out;
orig_dev = skb->dev;
skb_reset_network_header(skb);
skb_reset_transport_header(skb);
skb_reset_mac_len(skb);
pt_prev = NULL;
if (skb_dst(skb)) {
if (skb_dst(skb)->input == 0xdeadbeef) {
printk("bad dst: %lu, skb->dev: %s len: %i\n",
skb->_skb_refdst, skb->dev->name, skb->len);
BUG_ON(1);
}
}
rcu_read_lock();
if (skb_dst(skb)) {
if (skb_dst(skb)->input == 0xdeadbeef) {
printk("bad dst: %lu, skb->dev: %s len: %i\n",
skb->_skb_refdst, skb->dev->name, skb->len);
BUG_ON(1);
}
}
another_round:
skb->skb_iif = skb->dev->ifindex;
__this_cpu_inc(softnet_data.processed);
...
[root@lf1011-12060006 ~]# bad dst: 18446612148864241601, skb->dev: lo len: 3232
------------[ cut here ]------------
kernel BUG at /home/greearb/git/linux-3.7.dev.y/net/core/dev.c:3266!
invalid opcode: 0000 [#1] PREEMPT SMP
Modules linked in: macvlan pktgen lockd sunrpc uinput coretemp hwmon kvm_intel kvm microcode iTCO_wdt iTe
CPU 4
Pid: 35, comm: ksoftirqd/4 Tainted: G C O 3.7.3+ #50 Iron Systems Inc. EE2610R/X8ST3
RIP: 0010:[<ffffffff81473d22>] [<ffffffff81473d22>] __netif_receive_skb+0x101/0x5b8
RSP: 0018:ffff88040d711c58 EFLAGS: 00010296
RAX: 0000000000000036 RBX: ffff88041fc93e80 RCX: 000000000000a6a5
RDX: ffffffff810883a6 RSI: 00000000000005fc RDI: 0000000000000246
RBP: ffff88040d711cb8 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000004 R11: 0000000000000000 R12: ffff88041fc93fd0
R13: 0000000000000040 R14: ffff88040d3f8000 R15: ffff88041fc93f80
FS: 0000000000000000(0000) GS:ffff88041fc80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000262c118 CR3: 00000003da651000 CR4: 00000000000007e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process ksoftirqd/4 (pid: 35, threadinfo ffff88040d710000, task ffff88040d701f50)
Stack:
0000000000000046 0420804000000100 ffffffff81aaf0a0 ffff8803da901200
000000000d711cb8 ffffffff81aaf0a0 ffff8803ffa90428 ffff88041fc93e80
ffff88041fc93fd0 0000000000000040 0000000000000024 ffff88041fc93f80
Call Trace:
[<ffffffff814742d2>] process_backlog+0xf9/0x1da
[<ffffffff814766db>] net_rx_action+0xad/0x218
[<ffffffff8108d50a>] __do_softirq+0x9c/0x161
[<ffffffff8108d5f2>] run_ksoftirqd+0x23/0x42
[<ffffffff810a7ebe>] smpboot_thread_fn+0x253/0x259
[<ffffffff810a7c6b>] ? test_ti_thread_flag.clone.0+0x11/0x11
[<ffffffff810a0a6d>] kthread+0xc2/0xca
[<ffffffff810a09ab>] ? __init_kthread_worker+0x56/0x56
[<ffffffff81537dbc>] ret_from_fork+0x7c/0xb0
[<ffffffff810a09ab>] ? __init_kthread_worker+0x56/0x56
Code: fc ff ff ba ef be ad de 48 39 50 50 75 21 48 8b 45 b8 48 c7 c7 50 ea 82 81 8b 48 68 48 8b 50 20 48
RIP [<ffffffff81473d22>] __netif_receive_skb+0x101/0x5b8
RSP <ffff88040d711c58>
---[ end trace e5f94dc78f5e5277 ]---
Kernel panic - not syncing: Fatal exception in interrupt
>
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH net-next] via-rhine: add 64bit statistics.
From: Jamie Gloudon @ 2013-01-24 0:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem
In-Reply-To: <1358987262.12374.1283.camel@edumazet-glaptop>
On Wed, Jan 23, 2013 at 04:27:42PM -0800, Eric Dumazet wrote:
> On Wed, 2013-01-23 at 20:20 -0400, Jamie Gloudon wrote:
>
> > Right. Also, I added rx_dropped to increment for oversize ethernet. Is
> > that valid?
> >
> > @@ -1857,6 +1869,7 @@ static int rhine_rx(struct net_device *dev, int
> > limit)
> > "Oversized Ethernet frame %p vs %p\n", rp->rx_head_desc, &rp->rx_ring[entry]);
> > + dev->stats.rx_dropped++;
> > dev->stats.rx_length_errors++;
>
> Take other drivers as reference
>
> git grep -n2 rx_length_errors -- drivers/net
>
> Most of them dont do that (they are more likely increasing rx_errors)
>
>
Alright then, I will remove that line and queue up another patch for submission.
Thanks for the feedback!
^ permalink raw reply
* Re: [PATCH net-next] via-rhine: add 64bit statistics.
From: Eric Dumazet @ 2013-01-24 0:27 UTC (permalink / raw)
To: Jamie Gloudon; +Cc: netdev, davem
In-Reply-To: <51007e6c.4170ec0a.7218.18c2@mx.google.com>
On Wed, 2013-01-23 at 20:20 -0400, Jamie Gloudon wrote:
> Right. Also, I added rx_dropped to increment for oversize ethernet. Is
> that valid?
>
> @@ -1857,6 +1869,7 @@ static int rhine_rx(struct net_device *dev, int
> limit)
> "Oversized Ethernet frame %p vs %p\n", rp->rx_head_desc, &rp->rx_ring[entry]);
> + dev->stats.rx_dropped++;
> dev->stats.rx_length_errors++;
Take other drivers as reference
git grep -n2 rx_length_errors -- drivers/net
Most of them dont do that (they are more likely increasing rx_errors)
^ permalink raw reply
* Re: 3.7.3+: Bad paging request in ip_rcv_finish while running NFS traffic.
From: Eric Dumazet @ 2013-01-24 0:23 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev, linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <51007CA8.2050105-my8/4N5VtI7c+919tysfdA@public.gmane.org>
On Wed, 2013-01-23 at 16:13 -0800, Ben Greear wrote:
> On 01/23/2013 04:01 PM, Eric Dumazet wrote:
> > On Wed, 2013-01-23 at 15:55 -0800, Ben Greear wrote:
> >> On 01/22/2013 06:32 PM, Ben Greear wrote:
> >>
> >> So, I'm slowly making some progress. I've verified that the skb
> >> has bogus dst (0xdeadbeef) at the top of the ip_rcv_finish
> >> method. I'm trying to track it backwards and figure out which
> >> device it belongs to, etc....takes a while to reproduce though.
> >>
> >> One thing about this stack trace below...the dev_seq_stop() does
> >> a rcu read-unlock. Now, I can't figure out exactly how ip_rcv()
> >> can cause dev_seq_stop() to run, but if this stack is legit,
> >> then maybe by the time we enter the ip_rcv_finish() code we are
> >> running without rcu_readlock() held?
> >>
> >> If so, that would probably explain the bug.
> >>
> >
> > The whole thing is run under rcu_read_lock() done in
> > __netif_receive_skb()
>
> I was worried that the dev_seq_stop might be called
> incorrectly causing an asymetric unlock. I have no
> idea how that might happened, but several crashes
> have that dev_seq_stop method listed, so it got me suspicious.
dev_seq_stop() is some word in the kernel stack, result of a prior
system call. Stack is not cleanup.
Each function reserves an amount of stack but not always write on all
reserved space (some automatic variables might be not set)
Note the "? " before the name : linux printed the symbol but this was
not a call site for this particular call graph. Its only an extra
indication, that can be useful sometimes.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] via-rhine: add 64bit statistics.
From: Jamie Gloudon @ 2013-01-24 0:20 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem
In-Reply-To: <1358985772.12374.1250.camel@edumazet-glaptop>
On Wed, Jan 23, 2013 at 04:02:52PM -0800, Eric Dumazet wrote:
> On Wed, 2013-01-23 at 19:55 -0400, Jamie Gloudon wrote:
>
> > Eric, do you mean like this below? If not, please illustrate.
> >
> > + netdev_stats_to_stats64(stats, &dev->stats);
> > +
> > + do {
> > + start = u64_stats_fetch_begin_bh(&rp->rx_stats.syncp);
> > + stats->rx_packets = rp->rx_stats.packets;
> > + stats->rx_bytes = rp->rx_stats.bytes;
> > + } while (u64_stats_fetch_retry_bh(&rp->rx_stats.syncp, start));
> > +
> > + do {
> > + start = u64_stats_fetch_begin_bh(&rp->tx_stats.syncp);
> > + stats->tx_packets = rp->tx_stats.packets;
> > + stats->tx_bytes = rp->tx_stats.bytes;
> > + } while (u64_stats_fetch_retry_bh(&rp->tx_stats.syncp, start));
> > +
> > + return stats;
> >
>
> Yes, this is exactly how you should do that, since
> netdev_stats_to_stats64(stats, &dev->stats); would overwrite
> {tr}x_packets, {tr}x_bytes anyway.
>
>
Right. Also, I added rx_dropped to increment for oversize ethernet. Is
that valid?
@@ -1857,6 +1869,7 @@ static int rhine_rx(struct net_device *dev, int
limit)
"Oversized Ethernet frame %p vs %p\n", rp->rx_head_desc, &rp->rx_ring[entry]);
+ dev->stats.rx_dropped++;
dev->stats.rx_length_errors++;
^ permalink raw reply
* Re: 3.7.3+: Bad paging request in ip_rcv_finish while running NFS traffic.
From: Ben Greear @ 2013-01-24 0:13 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1358985688.12374.1247.camel@edumazet-glaptop>
On 01/23/2013 04:01 PM, Eric Dumazet wrote:
> On Wed, 2013-01-23 at 15:55 -0800, Ben Greear wrote:
>> On 01/22/2013 06:32 PM, Ben Greear wrote:
>>
>> So, I'm slowly making some progress. I've verified that the skb
>> has bogus dst (0xdeadbeef) at the top of the ip_rcv_finish
>> method. I'm trying to track it backwards and figure out which
>> device it belongs to, etc....takes a while to reproduce though.
>>
>> One thing about this stack trace below...the dev_seq_stop() does
>> a rcu read-unlock. Now, I can't figure out exactly how ip_rcv()
>> can cause dev_seq_stop() to run, but if this stack is legit,
>> then maybe by the time we enter the ip_rcv_finish() code we are
>> running without rcu_readlock() held?
>>
>> If so, that would probably explain the bug.
>>
>
> The whole thing is run under rcu_read_lock() done in
> __netif_receive_skb()
I was worried that the dev_seq_stop might be called
incorrectly causing an asymetric unlock. I have no
idea how that might happened, but several crashes
have that dev_seq_stop method listed, so it got me suspicious.
>
> My suspicion was that we called netif_rx() from macvlan leaving a
> not refcounted skb dst.
>
> But the patch I sent to you didnt solve the bug, so its something else.
>
> You could trace at which point the dst was released. (where you set
> dst->input/output to deadbeef)
My current code is in some garbage collector timer code, but I can
work on saving the call-site that first pokes the dst into the
garbage collection list...
Thanks,
Ben
--
Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [BUG] via-rhine: NOHZ: local_softirq_pending 08
From: Jamie Gloudon @ 2013-01-24 0:08 UTC (permalink / raw)
To: netdev; +Cc: rl
Hey,
While conducting some tests on a VT6105M card. I noticed this message:
kernel: [ 160.311113] NOHZ: local_softirq_pending 08
I was able to reliably reproduce the error message by setting autoneg off and changing the interface speed from 100 to 10 with ethtool.
Regards,
Jamie Gloudon
^ 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