* [PATCH net-next] tcp: speedup SIOCINQ ioctl
From: Eric Dumazet @ 2012-10-22 6:06 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
SIOCINQ can use the lock_sock_fast() version to avoid double acquisition
of socket lock.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/tcp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index b7c2f43..eace049 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -536,13 +536,14 @@ int tcp_ioctl(struct sock *sk, int cmd, unsigned long arg)
{
struct tcp_sock *tp = tcp_sk(sk);
int answ;
+ bool slow;
switch (cmd) {
case SIOCINQ:
if (sk->sk_state == TCP_LISTEN)
return -EINVAL;
- lock_sock(sk);
+ slow = lock_sock_fast(sk);
if ((1 << sk->sk_state) & (TCPF_SYN_SENT | TCPF_SYN_RECV))
answ = 0;
else if (sock_flag(sk, SOCK_URGINLINE) ||
@@ -557,7 +558,7 @@ int tcp_ioctl(struct sock *sk, int cmd, unsigned long arg)
answ--;
} else
answ = tp->urg_seq - tp->copied_seq;
- release_sock(sk);
+ unlock_sock_fast(sk, slow);
break;
case SIOCATMARK:
answ = tp->urg_data && tp->urg_seq == tp->copied_seq;
^ permalink raw reply related
* [PATCH net-next] tcp: RFC 5961 5.2 Blind Data Injection Attack Mitigation
From: Eric Dumazet @ 2012-10-22 5:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Neal Cardwell, Yuchung Cheng, Jerry Chu
From: Eric Dumazet <edumazet@google.com>
RFC 5961 5.2 [Blind Data Injection Attack].[Mitigation]
All TCP stacks MAY implement the following mitigation. TCP stacks
that implement this mitigation MUST add an additional input check to
any incoming segment. The ACK value is considered acceptable only if
it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <=
SND.NXT). All incoming segments whose ACK value doesn't satisfy the
above condition MUST be discarded and an ACK sent back.
Move tcp_send_challenge_ack() before tcp_ack() to avoid a forward
declaration.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Jerry Chu <hkchu@google.com>
---
net/ipv4/tcp_input.c | 43 +++++++++++++++++++++++------------------
1 file changed, 25 insertions(+), 18 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 432c366..60cf836 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3552,6 +3552,24 @@ static bool tcp_process_frto(struct sock *sk, int flag)
return false;
}
+/* RFC 5961 7 [ACK Throttling] */
+static void tcp_send_challenge_ack(struct sock *sk)
+{
+ /* unprotected vars, we dont care of overwrites */
+ static u32 challenge_timestamp;
+ static unsigned int challenge_count;
+ u32 now = jiffies / HZ;
+
+ if (now != challenge_timestamp) {
+ challenge_timestamp = now;
+ challenge_count = 0;
+ }
+ if (++challenge_count <= sysctl_tcp_challenge_ack_limit) {
+ NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPCHALLENGEACK);
+ tcp_send_ack(sk);
+ }
+}
+
/* This routine deals with incoming acks, but not outgoing ones. */
static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag)
{
@@ -3571,8 +3589,14 @@ static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag)
/* If the ack is older than previous acks
* then we can probably ignore it.
*/
- if (before(ack, prior_snd_una))
+ if (before(ack, prior_snd_una)) {
+ /* RFC 5961 5.2 [Blind Data Injection Attack].[Mitigation] */
+ if (before(ack, prior_snd_una - tp->max_window)) {
+ tcp_send_challenge_ack(sk);
+ return -1;
+ }
goto old_ack;
+ }
/* If the ack includes data we haven't sent yet, discard
* this segment (RFC793 Section 3.9).
@@ -5241,23 +5265,6 @@ out:
}
#endif /* CONFIG_NET_DMA */
-static void tcp_send_challenge_ack(struct sock *sk)
-{
- /* unprotected vars, we dont care of overwrites */
- static u32 challenge_timestamp;
- static unsigned int challenge_count;
- u32 now = jiffies / HZ;
-
- if (now != challenge_timestamp) {
- challenge_timestamp = now;
- challenge_count = 0;
- }
- if (++challenge_count <= sysctl_tcp_challenge_ack_limit) {
- NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPCHALLENGEACK);
- tcp_send_ack(sk);
- }
-}
-
/* Does PAWS and seqno based validation of an incoming segment, flags will
* play significant role here.
*/
^ permalink raw reply related
* [PATCH] vlan: set sysfs device_type to 'vlan'
From: Doug Goldstein @ 2012-10-22 5:53 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, systemd-devel, linux-kernel, Doug Goldstein
Sets the sysfs device_type to 'vlan' for udev. This makes it easier for
applications that query network information via udev to identify vlans
instead of using strrchr().
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
---
Pre-patch output:
swanson ~ # udevadm info -q all -p /sys/devices/virtual/net/br0.4
P: /devices/virtual/net/br0.4
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/net/br0.4
E: INTERFACE=br0.4
E: IFINDEX=6
E: SUBSYSTEM=net
Post-patch output:
swanson ~ # udevadm info -q all -p /sys/devices/virtual/net/br0.4
P: /devices/virtual/net/br0.4
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/net/br0.4
E: DEVTYPE=vlan
E: INTERFACE=br0.4
E: IFINDEX=12
E: SUBSYSTEM=net
The intent was to match other virtual network types such as bridges.
swanson ~ # udevadm info -q all -p /sys/devices/virtual/net/br0
P: /devices/virtual/net/br0
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/net/br0
E: DEVTYPE=bridge
E: INTERFACE=br0
E: IFINDEX=5
E: SUBSYSTEM=net
---
net/8021q/vlan_dev.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 4024424..78a8744 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -531,6 +531,10 @@ static const struct header_ops vlan_header_ops = {
.parse = eth_header_parse,
};
+static struct device_type vlan_type = {
+ .name = "vlan",
+};
+
static const struct net_device_ops vlan_netdev_ops;
static int vlan_dev_init(struct net_device *dev)
@@ -579,6 +583,8 @@ static int vlan_dev_init(struct net_device *dev)
dev->netdev_ops = &vlan_netdev_ops;
+ SET_NETDEV_DEVTYPE(dev, &vlan_type);
+
if (is_vlan_dev(real_dev))
subclass = 1;
--
1.7.8.6
^ permalink raw reply related
* RE: [net-next:master 28/31] drivers/net/ethernet/emulex/benet/be_main.c:3116 be_flash() error: __builtin_memcpy() 'req->params.data_buf' too small (4 vs 32768)
From: Perla, Sathya @ 2012-10-22 5:16 UTC (permalink / raw)
To: Yuanhan Liu, Ratnakar, Padmanabh
Cc: fengguang.wu@intel.com, Vasundhara, Volam, netdev@vger.kernel.org
In-Reply-To: <20121022032027.GA14218@yliu-dev.sh.intel.com>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
>Behalf Of Yuanhan Liu
>
>Hi Padmanabh,
>
>FYI, there are new smatch warnings show up in
>
>tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
>head: 46baac38ef633b08168d27df7b02eb14578fb760
>commit: 773a2d7c55a3d63207841c824d21920bd3683460 [28/31] be2net: Fix FW
>flashing on Skyhawk-R
>
>+ drivers/net/ethernet/emulex/benet/be_main.c:3116 be_flash() error:
>__builtin_memcpy() 'req->params.data_buf' too small (4 vs 32768)
>
Padmanabh is not in today. We'll check this and send a fix asap...
Thanks!
-Sathya
^ permalink raw reply
* Re: [BUG] Kernel recieves DNS reply, but doesn't deliver it to a waiting application
From: Andrew Savchenko @ 2012-10-22 3:36 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1350823941.13333.2167.camel@edumazet-glaptop>
[-- Attachment #1.1: Type: text/plain, Size: 5420 bytes --]
Hello,
On Sun, 21 Oct 2012 14:52:21 +0200 Eric Dumazet wrote:
> On Sun, 2012-10-21 at 03:25 +0400, Andrew Savchenko wrote:
[...]
> > This bug is back again on kernel 3.4.14, but this time I was able to
> > get debug data and to recover running kernel without reboot.
> >
> > Drowpatch showed that DNS UDP replies are always dropped here:
> > 1 drops at __udp_queue_rcv_skb+61 (0xffffffff813bd670)
> >
> > Another observations:
> > - only UDP replies are lost, TCP works fine;
> > - if network load is dropped dramatically (ip_forward disabled, most
> > network daemons are stopped) UDP DNS queries work again; but with
> > gradual load increase replies became first slow and than cease at all.
> > - CPU load is very low (uptime is below 0.05), so this shouldn't be
> > an insufficient computing power issue.
> >
> > I found __udp_queue_rcv_skb function in net/ipv4/udp.c. From the code
> > and observations above it follows that this is likely to be a ENOMEM
> > condition leading to a packet loss.
> >
> > This is a memory data after bug happened:
> > # cat /proc/meminfo
> > MemTotal: 1021576 kB
> > MemFree: 32056 kB
> > Buffers: 105204 kB
> > Cached: 646716 kB
> > SwapCached: 236 kB
> > Active: 205932 kB
> > Inactive: 587156 kB
> > Active(anon): 20636 kB
> > Inactive(anon): 22488 kB
> > Active(file): 185296 kB
> > Inactive(file): 564668 kB
> > Unevictable: 2152 kB
> > Mlocked: 2152 kB
> > SwapTotal: 995992 kB
> > SwapFree: 995020 kB
> > Dirty: 0 kB
> > Writeback: 0 kB
> > AnonPages: 43120 kB
> > Mapped: 7504 kB
> > Shmem: 148 kB
> > Slab: 176004 kB
> > SReclaimable: 118636 kB
> > SUnreclaim: 57368 kB
> > KernelStack: 688 kB
> > PageTables: 2948 kB
> > NFS_Unstable: 0 kB
> > Bounce: 0 kB
> > WritebackTmp: 0 kB
> > CommitLimit: 1506780 kB
> > Committed_AS: 62708 kB
> > VmallocTotal: 34359738367 kB
> > VmallocUsed: 262732 kB
> > VmallocChunk: 34359474615 kB
> > AnonHugePages: 0 kB
> > DirectMap4k: 33536 kB
> > DirectMap2M: 1013760 kB
> >
> > # sysctl -a | grep mem
> > net.core.optmem_max = 20480
> > net.core.rmem_default = 229376
> > net.core.rmem_max = 131071
> > net.core.wmem_default = 229376
> > net.core.wmem_max = 131071
> > net.ipv4.igmp_max_memberships = 20
> > net.ipv4.tcp_mem = 22350 29801 44700
> > net.ipv4.tcp_rmem = 4096 87380 6291456
> > net.ipv4.tcp_wmem = 4096 16384 4194304
> > net.ipv4.udp_mem = 24150 32202 48300
> > net.ipv4.udp_rmem_min = 4096
> > net.ipv4.udp_wmem_min = 4096
> > vm.lowmem_reserve_ratio = 256 256 32
> > vm.overcommit_memory = 0
> >
> > Sysctl memory parameters are system defaults, I haven't changed them
> > via sysctl or /proc interfaces.
> >
> > I tried to increase udm_mem values to the following:
> > net.ipv4.udp_mem = 100000 150000 200000
> >
> > This solved my issue, at least for a while: DNS queries are working
> > fine now.
> >
> > But I suspect that there is some memory loss in the kernel UDP stack,
> > because this issue never happens after reboot and always after about
> > a week of network operation. So this memory increase should help only
> > for a month or so, if memory loss is linear.
> >
> > If you need some memory debug information, let me know which one and
> > what tools will be needed.
>
> If drop is in __udp_queue_rcv_skb(), its not because you dont have
> enough memory. Frame was already received and handled by IP stack.
>
> Thats because sock_queue_rcv_skb() said : there are already enough
> frames in socket receive buffer, I dont want to add another frame.
Actually there was a lot of dropwatch output. I decided that drops
are in __udp_queue_rcv_skb() by comparison between dropwatch outputs
under normal operation and under bug condition. I'm attaching both of
them.
> You forgot to attach :
>
> cat /proc/net/udp
> netstat -s
Now bug is perfectly reproducible using net.ipv4.udp_mem values as
described in my previous mail. I reproduced reproducing bug
conditions and attaching these outputs.
> By the way, I suspect you are hit by skb recycling.
> (skb truesize is too big after few iterations)
>
> We removed skb recycling in linux-3.7-rc1
>
> If so, linux-3.7-rc1 or linux-3.7-rc2 should be fine.
I'll try 3.7 branch in a week or so. New kernel will require some
reconfiguration.
> What NIC are you using ?
This host has four NICs:
2x Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (10ec:8139)
2x D-Link System Inc DGE-528T Gigabit Ethernet Adapter (1462:223c)
One D-Link card is operating on 1Gbit/FD with mtu 7000, other cards
are used as 100Mbit/FD mtu 1500.
2 D-Link and 1 Realtek card are forming a bridge and remaining Realtek
card is used for an uplink. This host serves as a NAT between
the bridge and the uplink (both MASQUERADE and DNAT are used). Also it
has several ipsec tunnels for multiple hosts (mostly AH), l2tp tunnel
(independent from ipsec) and serves as a multicast router using
mrouted. Rather sophisticated ebtables, iptables and ipset setup is
used.
Best regards,
Andrew Savchenko
[-- Attachment #1.2: dropwatch.bug --]
[-- Type: application/octet-stream, Size: 6228 bytes --]
dropwatch> start
Enabling monitoring...
Kernel monitoring activated.
Issue Ctrl-C to stop monitoring
1 drops at netlink_unicast+1ae (0xffffffff8136a7cc)
891 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
1 drops at skb_free_datagram_locked+0 (0xffffffff8134200b)
1 drops at __udp_queue_rcv_skb+61 (0xffffffff813bd670)
1 drops at nf_hook_slow+107 (0xffffffff8136cac8)
1043 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
2 drops at unix_stream_connect+1b8 (0xffffffff813f479b)
4 drops at __udp_queue_rcv_skb+61 (0xffffffff813bd670)
2 drops at skb_free_datagram_locked+0 (0xffffffff8134200b)
1 drops at br_stp_rcv+77 (0xffffffff81438201)
861 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
3 drops at __udp_queue_rcv_skb+61 (0xffffffff813bd670)
1 drops at nf_hook_slow+107 (0xffffffff8136cac8)
3 drops at skb_free_datagram_locked+0 (0xffffffff8134200b)
1 drops at __udp4_lib_rcv+4a1 (0xffffffff813c0d0c)
760 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
2 drops at __udp_queue_rcv_skb+61 (0xffffffff813bd670)
1 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
2 drops at nf_hook_slow+107 (0xffffffff8136cac8)
1 drops at br_stp_rcv+77 (0xffffffff81438201)
610 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
1 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
3 drops at nf_hook_slow+107 (0xffffffff8136cac8)
1 drops at ppp_read+13c (0xffffffff812dcb86)
1 drops at skb_free_datagram_locked+0 (0xffffffff8134200b)
1 drops at __udp_queue_rcv_skb+61 (0xffffffff813bd670)
915 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
1 drops at __udp_queue_rcv_skb+61 (0xffffffff813bd670)
1 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
1 drops at br_stp_rcv+77 (0xffffffff81438201)
1 drops at nf_hook_slow+107 (0xffffffff8136cac8)
737 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
2 drops at __udp_queue_rcv_skb+61 (0xffffffff813bd670)
1 drops at skb_free_datagram_locked+0 (0xffffffff8134200b)
1 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
592 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
1 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
1 drops at nf_hook_slow+107 (0xffffffff8136cac8)
1 drops at br_stp_rcv+77 (0xffffffff81438201)
1 drops at __udp4_lib_rcv+4a1 (0xffffffff813c0d0c)
624 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
1 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
2 drops at nf_hook_slow+107 (0xffffffff8136cac8)
629 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
1 drops at __udp_queue_rcv_skb+61 (0xffffffff813bd670)
2 drops at nf_hook_slow+107 (0xffffffff8136cac8)
2 drops at skb_free_datagram_locked+0 (0xffffffff8134200b)
2 drops at ppp_read+13c (0xffffffff812dcb86)
1 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
1 drops at br_stp_rcv+77 (0xffffffff81438201)
506 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
1 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
1 drops at nf_hook_slow+107 (0xffffffff8136cac8)
573 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
2 drops at nf_hook_slow+107 (0xffffffff8136cac8)
1 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
1 drops at __udp4_lib_rcv+4a1 (0xffffffff813c0d0c)
1 drops at ip_mr_forward+79 (0xffffffff813d816e)
1 drops at br_stp_rcv+77 (0xffffffff81438201)
2 drops at icmp_rcv+11d (0xffffffff813c3f39)
1 drops at __udp_queue_rcv_skb+61 (0xffffffff813bd670)
506 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
4 drops at nf_hook_slow+107 (0xffffffff8136cac8)
2 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
1 drops at __udp4_lib_rcv+4a1 (0xffffffff813c0d0c)
574 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
2 drops at nf_hook_slow+107 (0xffffffff8136cac8)
2 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
1 drops at br_stp_rcv+77 (0xffffffff81438201)
1 drops at __udp_queue_rcv_skb+61 (0xffffffff813bd670)
571 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
1 drops at ip_mr_forward+79 (0xffffffff813d816e)
2 drops at nf_hook_slow+107 (0xffffffff8136cac8)
1 drops at ppp_read+13c (0xffffffff812dcb86)
2 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
878 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
1 drops at br_stp_rcv+77 (0xffffffff81438201)
1 drops at nf_hook_slow+107 (0xffffffff8136cac8)
707 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
548 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
1 drops at nf_hook_slow+107 (0xffffffff8136cac8)
1 drops at ip_mr_forward+79 (0xffffffff813d816e)
1 drops at br_stp_rcv+77 (0xffffffff81438201)
1 drops at __udp4_lib_rcv+4a1 (0xffffffff813c0d0c)
735 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
2 drops at nf_hook_slow+107 (0xffffffff8136cac8)
684 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
2 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
2 drops at nf_hook_slow+107 (0xffffffff8136cac8)
2 drops at ppp_read+13c (0xffffffff812dcb86)
1 drops at br_stp_rcv+77 (0xffffffff81438201)
702 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
1 drops at ip_mr_forward+79 (0xffffffff813d816e)
1 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
1 drops at nf_hook_slow+107 (0xffffffff8136cac8)
560 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
1 drops at br_stp_rcv+77 (0xffffffff81438201)
668 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
1 drops at nf_hook_slow+107 (0xffffffff8136cac8)
1 drops at __udp4_lib_rcv+4a1 (0xffffffff813c0d0c)
824 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
1 drops at ip_mr_forward+79 (0xffffffff813d816e)
2 drops at nf_hook_slow+107 (0xffffffff8136cac8)
1 drops at br_stp_rcv+77 (0xffffffff81438201)
762 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
3 drops at nf_hook_slow+107 (0xffffffff8136cac8)
1 drops at ppp_read+13c (0xffffffff812dcb86)
1 drops at skb_free_datagram_locked+0 (0xffffffff8134200b)
1 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
857 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
1 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
1 drops at br_stp_rcv+77 (0xffffffff81438201)
1 drops at nf_hook_slow+107 (0xffffffff8136cac8)
1096 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
1 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
1 drops at ip_mr_forward+79 (0xffffffff813d816e)
1 drops at icmp_rcv+11d (0xffffffff813c3f39)
1170 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
1 drops at nf_hook_slow+107 (0xffffffff8136cac8)
2 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
1 drops at br_stp_rcv+77 (0xffffffff81438201)
1 drops at __udp4_lib_rcv+4a1 (0xffffffff813c0d0c)
^CGot a stop message
[-- Attachment #1.3: dropwatch.normal --]
[-- Type: application/octet-stream, Size: 3613 bytes --]
dropwatch> start
Enabling monitoring...
Kernel monitoring activated.
Issue Ctrl-C to stop monitoring
1 drops at netlink_unicast+1ae (0xffffffff8136a7cc)
1393 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
1 drops at br_stp_rcv+77 (0xffffffff81438201)
1 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
1 drops at nf_hook_slow+107 (0xffffffff8136cac8)
1751 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
3 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
1345 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
5 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
1 drops at nf_hook_slow+107 (0xffffffff8136cac8)
1 drops at br_stp_rcv+77 (0xffffffff81438201)
1 drops at __udp4_lib_rcv+4a1 (0xffffffff813c0d0c)
2116 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
6 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
4 drops at nf_hook_slow+107 (0xffffffff8136cac8)
2098 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
7 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
2 drops at nf_hook_slow+107 (0xffffffff8136cac8)
2 drops at ppp_read+13c (0xffffffff812dcb86)
1 drops at br_stp_rcv+77 (0xffffffff81438201)
1978 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
7 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
1 drops at nf_hook_slow+107 (0xffffffff8136cac8)
2299 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
2 drops at nf_hook_slow+107 (0xffffffff8136cac8)
6 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
1 drops at __udp4_lib_rcv+4a1 (0xffffffff813c0d0c)
1 drops at br_stp_rcv+77 (0xffffffff81438201)
2123 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
6 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
4 drops at nf_hook_slow+107 (0xffffffff8136cac8)
1 drops at __udp4_lib_rcv+4a1 (0xffffffff813c0d0c)
2082 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
5 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
1 drops at br_stp_rcv+77 (0xffffffff81438201)
2 drops at nf_hook_slow+107 (0xffffffff8136cac8)
2136 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
5 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
2 drops at nf_hook_slow+107 (0xffffffff8136cac8)
1 drops at ppp_read+13c (0xffffffff812dcb86)
1710 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
1 drops at br_stp_rcv+77 (0xffffffff81438201)
3 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
1 drops at nf_hook_slow+107 (0xffffffff8136cac8)
1676 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
4 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
1599 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
5 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
1 drops at nf_hook_slow+107 (0xffffffff8136cac8)
1 drops at br_stp_rcv+77 (0xffffffff81438201)
1 drops at __udp4_lib_rcv+4a1 (0xffffffff813c0d0c)
1989 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
7 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
5 drops at nf_hook_slow+107 (0xffffffff8136cac8)
3 drops at skb_free_datagram_locked+0 (0xffffffff8134200b)
2001 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
6 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
4 drops at nf_hook_slow+107 (0xffffffff8136cac8)
2 drops at ppp_read+13c (0xffffffff812dcb86)
1 drops at br_stp_rcv+77 (0xffffffff81438201)
2189 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
7 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
3 drops at nf_hook_slow+107 (0xffffffff8136cac8)
1805 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
3 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
5 drops at skb_free_datagram_locked+0 (0xffffffff8134200b)
1 drops at br_stp_rcv+77 (0xffffffff81438201)
1788 drops at packet_rcv_spkt+39 (0xffffffff8142aeb9)
2 drops at ipv6_rcv+147 (0xffffffff813fb9cd)
1 drops at nf_hook_slow+107 (0xffffffff8136cac8)
1 drops at __udp4_lib_rcv+4a1 (0xffffffff813c0d0c)
^CGot a stop message
[-- Attachment #1.4: netstat-s --]
[-- Type: application/octet-stream, Size: 3429 bytes --]
$ netstat -s
Ip:
1258376226 total packets received
68 with invalid headers
8729 with invalid addresses
986336591 forwarded
0 incoming packets discarded
226645746 incoming packets delivered
1397083323 requests sent out
4220 fragments dropped after timeout
101092287 reassemblies required
50310250 packets reassembled ok
471302 packet reassembles failed
156043507 fragments received ok
13056 fragments failed
312087425 fragments created
Icmp:
16951 ICMP messages received
10501 input ICMP message failed.
ICMP input histogram:
destination unreachable: 16908
echo requests: 12
echo replies: 31
81582 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 78532
time exceeded: 3006
echo request: 32
echo replies: 12
IcmpMsg:
InType0: 31
InType3: 16908
InType8: 12
OutType0: 12
OutType3: 78532
OutType8: 32
OutType11: 3006
Tcp:
5903 active connections openings
3298 passive connection openings
5697 failed connection attempts
22 connection resets received
3 connections established
17065674 segments received
6067567 segments send out
11794 segments retransmited
0 bad segments received.
36 resets sent
Udp:
198891130 packets received
40714 packets to unknown port received.
845 packet receive errors
315052 packets sent
0 receive buffer errors
0 send buffer errors
UdpLite:
TcpExt:
18 resets received for embryonic SYN_RECV sockets
15 packets pruned from receive queue because of socket buffer overrun
9 ICMP packets dropped because they were out-of-window
2769 TCP sockets finished time wait in fast timer
2090 delayed acks sent
1204 delayed acks further delayed because of locked socket
Quick ack mode was activated 2 times
1181909 packets directly queued to recvmsg prequeue.
2172536151 bytes directly in process context from backlog
1992120562 bytes directly received in process context from prequeue
12959268 packet headers predicted
2159999 packets header predicted and directly queued to user
62159 acknowledgments not containing data payload received
1855367 predicted acknowledgments
90 times recovered from packet loss by selective acknowledgements
12 congestion windows recovered without slow start after partial ack
TCPLostRetransmit: 2
889 fast retransmits
11 forward retransmits
5694 other TCP timeouts
1 SACK retransmits failed
6 times receiver scheduled too late for direct processing
1444 packets collapsed in receive queue due to low socket buffer
3 DSACKs sent for old packets
28 DSACKs received
3 connections reset due to unexpected data
40 connections aborted due to timeout
TCPDSACKIgnoredOld: 1
TCPDSACKIgnoredNoUndo: 3
TCPSpuriousRTOs: 1
TCPSackShifted: 4881
TCPSackMerged: 1465
TCPSackShiftFallback: 1217
TCPBacklogDrop: 5000
TCPDeferAcceptDrop: 2939
IPReversePathFilter: 64181
TCPRcvCoalesce: 4
IpExt:
InMcastPkts: 532105
OutMcastPkts: 310186
InBcastPkts: 110406
OutBcastPkts: 25354
InOctets: 953399407223
OutOctets: 1130740735729
InMcastOctets: 88775757
OutMcastOctets: 24850249
InBcastOctets: 12840305
OutBcastOctets: 2949734
[-- Attachment #1.5: proc_net_udp --]
[-- Type: application/octet-stream, Size: 4073 bytes --]
$ cat /proc/net/udp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode ref pointer drops
13: 0100007F:2745 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 253469 2 ffff88000423c380 0
44: 00000000:2D64 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 251478 2 ffff88003d581180 0
70: 00000000:857E 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 253765 2 ffff880039aa1880 0
171: 00000000:A9E3 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4859 2 ffff88003d4ece00 0
188: 7E0F330A:01F4 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 5332 2 ffff880039aa0380 0
199: 0100007F:03FF 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4853 2 ffff88003d4eca80 0
201: 00000000:0801 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 253755 2 ffff880039aa0e00 0
253: 010013AC:0035 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 253582 2 ffff880039aa0a80 0
253: 0100007F:0035 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 253581 2 ffff880039aa0700 0
267: 00000000:0043 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 251500 2 ffff88003d580e00 0
288: 7E0F330A:9458 1200320A:06A5 01 00000000:00000000 00:00000000 00000000 0 0 254288 4 ffff88003b9b2e00 0
311: 00000000:006F 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4550 2 ffff88003d4ec000 0
319: 00000000:0277 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 253883 2 ffff880039aa1180 0
323: 074A070A:007B 00000000:0000 07 FFFDF700:00000000 00:00000000 00000000 123 0 254469 2 ffff88003d581880 0
323: 010213AC:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 5189 2 ffff880039aa0000 0
323: 010013AC:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 5188 2 ffff880039993c00 0
323: 00FCA8C0:007B 00000000:0000 07 FFFFF900:00000000 00:00000000 00000000 0 0 5187 2 ffff880039993880 0
323: 7E0F330A:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 5186 2 ffff880039993500 0
323: 0100007F:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 5185 2 ffff880039993180 0
323: 00000000:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 5178 2 ffff880039992a80 0
337: FF0013AC:0089 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 253948 2 ffff88003d580380 0
337: 010013AC:0089 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 253947 2 ffff880039992e00 0
337: FF0213AC:0089 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 253944 2 ffff88000423ca80 0
337: 010213AC:0089 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 253943 2 ffff88000423ce00 0
337: 00000000:0089 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 253940 2 ffff880039aa1c00 0
338: FF0013AC:008A 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 253950 2 ffff88003d581c00 0
338: 010013AC:008A 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 253949 2 ffff88003d580a80 0
338: FF0213AC:008A 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 253946 2 ffff88003d4edc00 0
338: 010213AC:008A 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 253945 2 ffff88000420e700 0
338: 00000000:008A 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 253941 2 ffff88000423d180 0
365: 00000000:06A5 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 254281 2 ffff88003b9b2380 0
454: 00000000:90FE 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 253718 2 ffff880039aa1500 0
477: 00000000:0315 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4569 2 ffff88003d4ec380 0
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [net-next:master 28/31] drivers/net/ethernet/emulex/benet/be_main.c:3116 be_flash() error: __builtin_memcpy() 'req->params.data_buf' too small (4 vs 32768)
From: Yuanhan Liu @ 2012-10-22 3:20 UTC (permalink / raw)
To: Padmanabh Ratnakar; +Cc: Yuanhan Liu, fengguang.wu, Vasundhara Volam, netdev
Hi Padmanabh,
FYI, there are new smatch warnings show up in
tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: 46baac38ef633b08168d27df7b02eb14578fb760
commit: 773a2d7c55a3d63207841c824d21920bd3683460 [28/31] be2net: Fix FW flashing on Skyhawk-R
+ drivers/net/ethernet/emulex/benet/be_main.c:3116 be_flash() error: __builtin_memcpy() 'req->params.data_buf' too small (4 vs 32768)
vim +3116 drivers/net/ethernet/emulex/benet/be_main.c
773a2d7c Padmanabh Ratnakar 2012-10-20 3100 num_bytes = min_t(u32, 32*1024, total_bytes);
773a2d7c Padmanabh Ratnakar 2012-10-20 3101
773a2d7c Padmanabh Ratnakar 2012-10-20 3102 total_bytes -= num_bytes;
773a2d7c Padmanabh Ratnakar 2012-10-20 3103
773a2d7c Padmanabh Ratnakar 2012-10-20 3104 if (!total_bytes) {
773a2d7c Padmanabh Ratnakar 2012-10-20 3105 if (optype == OPTYPE_PHY_FW)
773a2d7c Padmanabh Ratnakar 2012-10-20 3106 flash_op = FLASHROM_OPER_PHY_FLASH;
773a2d7c Padmanabh Ratnakar 2012-10-20 3107 else
773a2d7c Padmanabh Ratnakar 2012-10-20 3108 flash_op = FLASHROM_OPER_FLASH;
773a2d7c Padmanabh Ratnakar 2012-10-20 3109 } else {
773a2d7c Padmanabh Ratnakar 2012-10-20 3110 if (optype == OPTYPE_PHY_FW)
773a2d7c Padmanabh Ratnakar 2012-10-20 3111 flash_op = FLASHROM_OPER_PHY_SAVE;
773a2d7c Padmanabh Ratnakar 2012-10-20 3112 else
773a2d7c Padmanabh Ratnakar 2012-10-20 3113 flash_op = FLASHROM_OPER_SAVE;
773a2d7c Padmanabh Ratnakar 2012-10-20 3114 }
773a2d7c Padmanabh Ratnakar 2012-10-20 3115
773a2d7c Padmanabh Ratnakar 2012-10-20 @3116 memcpy(req->params.data_buf, img, num_bytes);
773a2d7c Padmanabh Ratnakar 2012-10-20 3117 img += num_bytes;
773a2d7c Padmanabh Ratnakar 2012-10-20 3118 status = be_cmd_write_flashrom(adapter, flash_cmd, optype,
773a2d7c Padmanabh Ratnakar 2012-10-20 3119 flash_op, num_bytes);
773a2d7c Padmanabh Ratnakar 2012-10-20 3120 if (status) {
773a2d7c Padmanabh Ratnakar 2012-10-20 3121 if (status == ILLEGAL_IOCTL_REQ &&
773a2d7c Padmanabh Ratnakar 2012-10-20 3122 optype == OPTYPE_PHY_FW)
773a2d7c Padmanabh Ratnakar 2012-10-20 3123 break;
773a2d7c Padmanabh Ratnakar 2012-10-20 3124 dev_err(&adapter->pdev->dev,
---
0-DAY kernel build testing backend Open Source Technology Center
Fengguang Wu, Yuanhan Liu Intel Corporation
^ permalink raw reply
* Re: [PATCH net-next] pkt_sched: use ns_to_ktime() helper
From: David Miller @ 2012-10-22 2:21 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1350729651.13333.570.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 20 Oct 2012 12:40:51 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> ns_to_ktime() seems better than ktime_set() + ktime_add_ns()
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next 00/14] be2net updates
From: David Miller @ 2012-10-22 2:20 UTC (permalink / raw)
To: padmanabh.ratnakar; +Cc: netdev
In-Reply-To: <158bb887-7f4c-4d3d-abc3-c5cb50c06edb@CMEXHTCAS2.ad.emulex.com>
From: Padmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
Date: Sat, 20 Oct 2012 21:31:05 +0530
> Padmanabh Ratnakar (14):
> be2net: Fix driver load failure for different FW configs in Lancer
> be2net: Fix setting QoS for VF for Lancer
> be2net: Fix change MAC operation for VF for Lancer
> be2net: Wait till resources are available for VF in error recovery
> be2net: Fix configuring VLAN for VF for Lancer
> be2net: Fix error messages while driver load for VFs
> be2net: Fix ethtool get_settings output for VF
> be2net: Fix issues in error recovery due to wrong queue state
> be2net: Fix unnecessary delay in PCI EEH
> be2net: Fix VF driver load on newer Lancer FW
> be2net: Enabling Wake-on-LAN is not supported in S5 state
> be2net: Fix FW flashing on Skyhawk-R
> be2net: Fix skyhawk VF PCI Device ID
> be2net: Update driver version
Series applied.
^ permalink raw reply
* Re: pull request: wireless 2012-10-19
From: David Miller @ 2012-10-22 1:01 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20121019211410.GC2208@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 19 Oct 2012 17:14:10 -0400
> This is a batch of fixes intended for the 3.7 stream.
...
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
Pulled, thanks a lot John.
^ permalink raw reply
* Re: [PATCH] cxgb4: Remove unnecessary #ifdef condition
From: David Miller @ 2012-10-22 0:57 UTC (permalink / raw)
To: vipul; +Cc: netdev, divy, dm
In-Reply-To: <1350648593-16370-1-git-send-email-vipul@chelsio.com>
From: Vipul Pandya <vipul@chelsio.com>
Date: Fri, 19 Oct 2012 17:39:53 +0530
> This patch also fixes the build failure caused due to removal of #ifdef
> CONFIG_CHELSIO_T4_OFFLOAD condition
>
> Signed-off-by: Vipul Pandya <vipul@chelsio.com>
Applied to 'net'.
Please ALWAYS make it clear, in your Subject line, what tree you want
your patches applied to.
^ permalink raw reply
* Re: [PATCH 1/1] [PATCH net-next] net:dev: remove double indentical assignment in dev_change_net_namespace().
From: David Miller @ 2012-10-22 0:45 UTC (permalink / raw)
To: ramirose; +Cc: netdev, serge.hallyn
In-Reply-To: <1350644970-2877-1-git-send-email-ramirose@gmail.com>
From: Rami Rosen <ramirose@gmail.com>
Date: Fri, 19 Oct 2012 13:09:30 +0200
> This patch removes double assignment of err to -EINVAL in dev_change_net_namespace().
>
> Signed-off-by: Rami Rosen <ramirose@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] sockopt: Make SO_BINDTODEVICE readable
From: David Miller @ 2012-10-22 0:43 UTC (permalink / raw)
To: xemul; +Cc: netdev
In-Reply-To: <508123AC.5080208@parallels.com>
From: Pavel Emelyanov <xemul@parallels.com>
Date: Fri, 19 Oct 2012 13:55:56 +0400
> The SO_BINDTODEVICE option is the only SOL_SOCKET one that can be set, but
> cannot be get via sockopt API. The only way we can find the device id a
> socket is bound to is via sock-diag interface. But the diag works only on
> hashed sockets, while the opt in question can be set for yet unhashed one.
>
> That said, in order to know what device a socket is bound to (we do want
> to know this in checkpoint-restore project) I propose to make this option
> getsockopt-able and report the respective device index.
>
> Another solution to the problem might be to teach the sock-diag reporting
> info on unhashed sockets. Should I go this way instead?
>
> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Applied. I can't believe we didn't support this when the feature
was added.
I guess we figured that if the application made this setting, then
it knows and doesn't need to query it.
^ permalink raw reply
* Re: [PATCH net-next v7 1/1] ipv6: add support of equal cost multipath (ECMP)
From: David Miller @ 2012-10-22 0:41 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: eric.dumazet, joe, bernat, netdev, yoshfuji
In-Reply-To: <1350638006-4213-2-git-send-email-nicolas.dichtel@6wind.com>
Why do you go through all of the effort to create a nice
abstraction in a header file:
> +#ifdef CONFIG_IPV6_MULTIPATH
> +static inline unsigned int
> +ipv6_multipath_get_nsiblings(const struct rt6_info *rt)
> +{
> + return rt->rt6i_nsiblings;
> +}
...
Only to screw it up by still plopping ifdef crap into foo.c files?
> +#ifdef CONFIG_IPV6_MULTIPATH
> + INIT_LIST_HEAD(&rt->rt6i_siblings);
> +#endif
> + ipv6_multipath_reset_nsiblings(rt);
I really don't want to see these ifdefs.
And if they are unavoidable, remove this configure option
altogether and make the code unconditionally included.
^ permalink raw reply
* [PATCH] qla3xxx: Ensure request/response queue addr writes to the registers
From: Joe Jin @ 2012-10-22 0:40 UTC (permalink / raw)
To: Jitendra Kalsaria, Ron Mercer, Linux Driver, David S. Miller,
Andrew Morton
Cc: netdev, linux-kernel, Greg Marsden
Before use the request and response queue addr, make sure it has wrote
to the registers.
Signed-off-by: Joe Jin <joe.jin@oracle.com>
Cc: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Cc: Ron Mercer <ron.mercer@qlogic.com>
---
drivers/net/ethernet/qlogic/qla3xxx.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qla3xxx.c b/drivers/net/ethernet/qlogic/qla3xxx.c
index df09b1c..6407d0d 100644
--- a/drivers/net/ethernet/qlogic/qla3xxx.c
+++ b/drivers/net/ethernet/qlogic/qla3xxx.c
@@ -2525,6 +2525,13 @@ static int ql_alloc_net_req_rsp_queues(struct ql3_adapter *qdev)
qdev->req_q_size =
(u32) (NUM_REQ_Q_ENTRIES * sizeof(struct ob_mac_iocb_req));
+ qdev->rsp_q_size = NUM_RSP_Q_ENTRIES * sizeof(struct net_rsp_iocb);
+
+ /* The barrier is required to ensure request and response queue
+ * addr writes to the registers.
+ */
+ wmb();
+
qdev->req_q_virt_addr =
pci_alloc_consistent(qdev->pdev,
(size_t) qdev->req_q_size,
@@ -2536,8 +2543,6 @@ static int ql_alloc_net_req_rsp_queues(struct ql3_adapter *qdev)
return -ENOMEM;
}
- qdev->rsp_q_size = NUM_RSP_Q_ENTRIES * sizeof(struct net_rsp_iocb);
-
qdev->rsp_q_virt_addr =
pci_alloc_consistent(qdev->pdev,
(size_t) qdev->rsp_q_size,
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH net-next] unix: Remove unused field from unix_sock
From: David Miller @ 2012-10-22 0:37 UTC (permalink / raw)
To: xemul; +Cc: netdev
In-Reply-To: <5080F30C.2090206@parallels.com>
From: Pavel Emelyanov <xemul@parallels.com>
Date: Fri, 19 Oct 2012 10:28:28 +0400
> The struct sock *other one seem to be unused. Grep and make do not object.
>
> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] pktgen: Use ipv6_addr_any
From: David Miller @ 2012-10-22 0:37 UTC (permalink / raw)
To: joe; +Cc: linux-kernel, netdev
In-Reply-To: <408090aa33c0ebcd8d02ce1d14b3dca590fbae62.1350618840.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Thu, 18 Oct 2012 20:55:31 -0700
> Use the standard test for a non-zero ipv6 address.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next,1/1] hyperv: Remove unnecessary comments in rndis_filter_receive_data()
From: David Miller @ 2012-10-22 0:36 UTC (permalink / raw)
To: haiyangz; +Cc: olaf, netdev, jasowang, linux-kernel, devel
In-Reply-To: <1350594052-15714-1-git-send-email-haiyangz@microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Thu, 18 Oct 2012 14:00:52 -0700
> Checked with Windows networking team, there is only one RNDIS message
> in each netvsc packet.
>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ixgbe: Use is_valid_ether_addr
From: Jeff Kirsher @ 2012-10-22 0:23 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev, linux-kernel
In-Reply-To: <1350750159.10791.3.camel@joe-AO722>
[-- Attachment #1: Type: text/plain, Size: 748 bytes --]
On Sat, 2012-10-20 at 09:22 -0700, Joe Perches wrote:
> Use the normal kernel test instead of a module specific one.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> found when doing that larger style conversion,
> might as well submit it.
>
> drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c | 2 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 27
> +------------------------
> drivers/net/ethernet/intel/ixgbe/ixgbe_common.h | 1 -
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 9 ---------
> drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c | 2 +-
> 6 files changed, 4 insertions(+), 39 deletions(-)
Thanks, I will add this to the queue.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: 3.5 bridging regression
From: Willy Tarreau @ 2012-10-21 23:56 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, edumazet, netdev
In-Reply-To: <20121021235432.GY21937@1wt.eu>
On Mon, Oct 22, 2012 at 01:54:32AM +0200, Willy Tarreau wrote:
> On Sun, Oct 21, 2012 at 07:38:25PM -0400, David Miller wrote:
> > From: Willy Tarreau <w@1wt.eu>
> > Date: Mon, 22 Oct 2012 01:31:41 +0200
> >
> > > On Sun, Oct 21, 2012 at 07:25:56PM -0400, David Miller wrote:
> > >> From: Willy Tarreau <w@1wt.eu>
> > >> Date: Sun, 21 Oct 2012 15:26:10 +0200
> > >>
> > >> > David, are you OK with sending this patch for -stable ? It fixes
> > >> > a 3.5 regression causing bridge to panic.
> > >>
> > >> Why do people ask me so many questions they can answer on their
> > >> own?
> > >>
> > >> http://patchwork.ozlabs.org/user/bundle/2566/?state=*
> > >
> > > I wasn't aware of this URL and don't have an account there, though I
> > > can register to follow your work from now on.
> >
> > You don't need an account, it's a public URL of my -stable patch queue.
>
> But when I click this link I am redirected to a login page :-/
And I can confirm that after being logged I have access to your list.
Thank you for the link, it will greatly help me.
Willy
^ permalink raw reply
* Re: 3.5 bridging regression
From: Willy Tarreau @ 2012-10-21 23:54 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, edumazet, netdev
In-Reply-To: <20121021.193825.2244790136717525771.davem@davemloft.net>
On Sun, Oct 21, 2012 at 07:38:25PM -0400, David Miller wrote:
> From: Willy Tarreau <w@1wt.eu>
> Date: Mon, 22 Oct 2012 01:31:41 +0200
>
> > On Sun, Oct 21, 2012 at 07:25:56PM -0400, David Miller wrote:
> >> From: Willy Tarreau <w@1wt.eu>
> >> Date: Sun, 21 Oct 2012 15:26:10 +0200
> >>
> >> > David, are you OK with sending this patch for -stable ? It fixes
> >> > a 3.5 regression causing bridge to panic.
> >>
> >> Why do people ask me so many questions they can answer on their
> >> own?
> >>
> >> http://patchwork.ozlabs.org/user/bundle/2566/?state=*
> >
> > I wasn't aware of this URL and don't have an account there, though I
> > can register to follow your work from now on.
>
> You don't need an account, it's a public URL of my -stable patch queue.
But when I click this link I am redirected to a login page :-/
Willy
^ permalink raw reply
* Re: 3.5 bridging regression
From: David Miller @ 2012-10-21 23:38 UTC (permalink / raw)
To: w; +Cc: eric.dumazet, edumazet, netdev
In-Reply-To: <20121021233141.GA15770@1wt.eu>
From: Willy Tarreau <w@1wt.eu>
Date: Mon, 22 Oct 2012 01:31:41 +0200
> On Sun, Oct 21, 2012 at 07:25:56PM -0400, David Miller wrote:
>> From: Willy Tarreau <w@1wt.eu>
>> Date: Sun, 21 Oct 2012 15:26:10 +0200
>>
>> > David, are you OK with sending this patch for -stable ? It fixes
>> > a 3.5 regression causing bridge to panic.
>>
>> Why do people ask me so many questions they can answer on their
>> own?
>>
>> http://patchwork.ozlabs.org/user/bundle/2566/?state=*
>
> I wasn't aware of this URL and don't have an account there, though I
> can register to follow your work from now on.
You don't need an account, it's a public URL of my -stable patch queue.
^ permalink raw reply
* Re: 3.5 bridging regression
From: Willy Tarreau @ 2012-10-21 23:31 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, edumazet, netdev
In-Reply-To: <20121021.192556.952646404147204428.davem@davemloft.net>
On Sun, Oct 21, 2012 at 07:25:56PM -0400, David Miller wrote:
> From: Willy Tarreau <w@1wt.eu>
> Date: Sun, 21 Oct 2012 15:26:10 +0200
>
> > David, are you OK with sending this patch for -stable ? It fixes
> > a 3.5 regression causing bridge to panic.
>
> Why do people ask me so many questions they can answer on their
> own?
>
> http://patchwork.ozlabs.org/user/bundle/2566/?state=*
I wasn't aware of this URL and don't have an account there, though I
can register to follow your work from now on.
Willy
^ permalink raw reply
* Re: [PATCH 1/5] net/cadence: get rid of HAVE_NET_MACB
From: David Miller @ 2012-10-21 23:27 UTC (permalink / raw)
To: manabian
Cc: nicolas.ferre, hskinnemoen, egtvedt, plagnioj, bgat, netdev,
linux-arm-kernel
In-Reply-To: <1350829392-3812-2-git-send-email-manabian@gmail.com>
You do know that this is going to generate warnings on 64-bit
platforms?
I was hoping you would have noticed and corrected this before
enabling the driver everywhere, I guess my expectations were
way too high :-/
^ permalink raw reply
* Re: 3.5 bridging regression
From: David Miller @ 2012-10-21 23:25 UTC (permalink / raw)
To: w; +Cc: eric.dumazet, edumazet, netdev
In-Reply-To: <20121021132610.GG21937@1wt.eu>
From: Willy Tarreau <w@1wt.eu>
Date: Sun, 21 Oct 2012 15:26:10 +0200
> David, are you OK with sending this patch for -stable ? It fixes
> a 3.5 regression causing bridge to panic.
Why do people ask me so many questions they can answer on their
own?
http://patchwork.ozlabs.org/user/bundle/2566/?state=*
^ permalink raw reply
* Business Proposal
From: Wong Hui @ 2012-10-21 23:09 UTC (permalink / raw)
Please I would like you to keep this proposal as a top secret and delete it if you
are not interested and get back to me if you are interested for details as regards
to the transfer of $24,500,000 to you.
This money initially belongs to a Libyan client who died in the libya crisis and had no next of kin in his
account-opening package in my bank here in Hong kong where I am a bank director.
In other to achieve this, I shall require your full name, and telephone number to reach you.
Most importantly, a confirmation of acceptance from you will be needed after which I
shall furnish you with the full details of this transaction.
Yours Truly,
Wong Hui.
^ 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