gmane.linux.network

[PATCH 0/5] SLIP SLIP-Improve robustness to crashing

Dean Jenkins — 2013-06-19T15:34:26

Using SLIP bound to RFCOMM or PTY/TTY has identified some weaknesses to crashing
under abnormal conditions.

Here is a proposed patchset baselined and built on Linux 3.9.

Note the patches have not been tested on x86 Linux 3.9. However similar patches
have been used on ARM Linux 2.6.34 to avoid kernel crashes in a commercial
project. I believe the same weaknesses still exist in Linux 3.9.

If some or all of the patches look to be useful to the community then I may
attempt to test on x86 but this is not straight forward for me.

I welcome any feedback and whether the fixes are a suitable solution.

Who is the maintainer of SLIP in the kernel ?

The patchset consists of:

0001-Bluetooth-Add-RFCOMM-TTY-write-return-error-codes.patch
0002-SLIP-Handle-error-codes-from-the-TTY-layer.patch
0003-SLIP-Prevent-recursion-stack-overflow-and-scheduler-.patch
0004-SLIP-Add-error-message-for-xleft-non-zero.patch
0005-SLIP-Fix-transmission-segmentation-mechanism.patches

Some background:

0001-Bluetooth-Add-RFCOMM-TTY-write-return-error-codes.patch
This patch is a Bluetooth change to add some error return codes to RFCOMM to
avoid NULL pointer dereference crashes. Note RFCOMM can already generate an
error code that will cause SLIP to malfunction.

0002-SLIP-Handle-error-codes-from-the-TTY-layer.patches
This patch allows SLIP to handle error codes from RFCOMM or other bound TTY layers.

0003-SLIP-Prevent-recursion-stack-overflow-and-scheduler-.patches
This patch prevents SLIP from causing a recursive loop that overflows the stack
and catastrophically crashes the kernel. The scenario is SLIP bound to PTY/TTY.
The underlying trigger is a probably a failure to allocate a TTY buffer in
tty_buffer_alloc() but this is unproven. The crash is sporadic in an ARM
embedded environment where resources are limited.

0004-SLIP-Add-error-message-for-xleft-non-zero.patch
This is an error message patch to identify when a SLIP frame has not been fully
transmitted meaning the frame was truncated.

0005-SLIP-Fix-transmission-segmentation-mechanism.patches
This patch allows multiple attempts to transmit segments of the SLIP frame.
Currently only 1 attempt at writing the whole SLIP frame to PTY/TTY occurs.
This could truncate transmitted SLIP frames. In addition the modification
relies on the TTY write wake-up event to complete the transmission of the
SLIP frame rather than the sl_encaps() call to pty_write(). Probably,
pty_write() should not call tty_wakeup() but safer to modify SLIP rather
than the PTY/TTY layer.

Thanks,
Dean Jenkins
Mentor Graphics

PacketFence: Interfaces & Networks Configuration Disappear on Restart

Frank Steve — 2013-06-19T15:16:49

Hi,

I am experiencing some strange behavior in PacketFence configuration.

I have installed packetfence in Ubuntu 12.10. Everytime i restart the Ubuntu
server the settings/configuration i had made under interfaces & networks
disappear. On the linux box it shows no ip defined on the sub-interfaces; i
have to keep on re-configuring. Anyone with idea on how to resolve this?

root< at >ecsnacsvr:~# ifconfig
eth0      Link encap:Ethernet  HWaddr e8:39:35:39:c1:eb
          inet addr:10.10.0.10  Bcast:10.10.0.15  Mask:255.255.255.240
          inet6 addr: fe80::ea39:35ff:fe39:c1eb/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11961 errors:0 dropped:0 overruns:0 frame:0
          TX packets:294 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1191641 (1.1 MB)  TX bytes:45370 (45.3 KB)

eth0.10   Link encap:Ethernet  HWaddr e8:39:35:39:c1:eb
          inet6 addr: fe80::ea39:35ff:fe39:c1eb/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4176 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:196380 (196.3 KB)  TX bytes:3810 (3.8 KB)

eth0.20   Link encap:Ethernet  HWaddr e8:39:35:39:c1:eb
          inet6 addr: fe80::ea39:35ff:fe39:c1eb/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1021 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:54723 (54.7 KB)  TX bytes:3810 (3.8 KB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:405 errors:0 dropped:0 overruns:0 frame:0
          TX packets:405 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1017697 (1.0 MB)  TX bytes:1017697 (1.0 MB)

Regards,
Frank

More vxlan patches

Stephen Hemminger — 2013-06-19T15:00:43

Dave,
I have 12 more VXLAN patches pending, should I send first 4 again or do
you want to merge net to net-next first?

[PATCH net-next 0/2] macvtap: Add support for offload control

Vlad Yasevich — 2013-06-19T14:47:50

Currently macvtap does not allow control of offload functionality via
TUNSETOFFLOAD ioctl.  However, this is the ioctl that qemu uses when
attempting to control offload functionality.  This patch series adds
the ability to control offloads via the ioctl above.

It also adds necessary code to macvtap to perform segmentation upon
forwarding the packets to tap.  This is needed if offloads on the
macvtap interface are disabled, but lower-level device still performs
GRO.

Vlad Yasevich (2):
  macvtap: Let TUNSETOFFLOAD actually controll offload features.
  macvtap: Perform GSO on forwarding path.

 drivers/net/macvlan.c      |  9 +++++++
 drivers/net/macvtap.c      | 67 ++++++++++++++++++++++++++++++++++++++++++++--
 include/linux/if_macvlan.h |  1 +
 3 files changed, 75 insertions(+), 2 deletions(-)

lånetilbud

Barclayshome finance — 2013-06-19T12:46:05

Hei,

Mitt navn er Taylor Andersson, en anerkjent og lovlig akkreditert moneylender og agent av Barclays Hjem Finance basert i Storbritannia. Vi låner ut penger til enkeltpersoner og bedrifter som trenger økonomisk bistand. Har du en dårlig kreditt eller er du i behov av penger til å betale dine regninger? Vi vil bruke dette mediet til å informere deg om at vi kan hjelpe deg med noen form for lån du trenger. Vi vil gjerne tilby deg et lån så lav som 3% rente.
   
Vennligst fyll ut skjemaet nedenfor og returnere så snart som mulig.

Fullt navn: ...............
Land: ............
kjønn:
Tel: .......
Lånebeløp: ........
Lånet varighet: .......
Lån formål: .........

Kontakt oss så snart som mulig hvis du er interessert.

vennlig hilsen
Taylor Andersson

[PATCH net,v2] net: sock: adapt SOCK_MIN_RCVBUF and SOCK_MIN_SNDBUF

Daniel Borkmann — 2013-06-19T10:51:20

The current situation is that SOCK_MIN_RCVBUF is 2048 + sizeof(struct sk_buff))
while SOCK_MIN_SNDBUF is 2048. Since in both cases, skb->truesize is used for
sk_{r,w}mem_alloc accounting, we should have both sizes adjusted via defining a
TCP_SKB_MIN_TRUESIZE.

Further, as Eric Dumazet points out, the minimal skb truesize in transmit path is
SKB_TRUESIZE(2048) after commit f07d960df33c5 ("tcp: avoid frag allocation for
small frames"), and tcp_sendmsg() tries to limit skb size to half the congestion
window, meaning we try to build two skbs at minimum. Thus, having SOCK_MIN_SNDBUF
as 2048 can hit a small regression for some applications setting to low
SO_SNDBUF / SO_RCVBUF. Note that we define a TCP_SKB_MIN_TRUESIZE, because
SKB_TRUESIZE(2048) adds SKB_DATA_ALIGN(sizeof(struct skb_shared_info)), but in
case of TCP skbs, the skb_shared_info is part of the 2048 bytes allocation for
skb->head.

The minor adaption in sk_stream_moderate_sndbuf() is to silence a warning by
using a typed max macro, as similarly done in SOCK_MIN_RCVBUF occurences, that
would appear otherwise.

Suggested-by: Eric Dumazet <eric.dumazet< at >gmail.com>
Signed-off-by: Daniel Borkmann <dborkman< at >redhat.com>
---
 v1 -> v2:
  - Applied Eric's feedback, fixed up commit message
  - Set subject to 'net' instead of 'net-next' due to the reported regression

 include/net/sock.h | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/include/net/sock.h b/include/net/sock.h
index ac8e181..753e59f 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
< at >< at > -2045,18 +2045,21 < at >< at > static inline void sk_wake_async(struct sock *sk, int how, int band)
 sock_wake_async(sk->sk_socket, how, band);
 }
 
-#define SOCK_MIN_SNDBUF 2048
-/*
- * Since sk_rmem_alloc sums skb->truesize, even a small frame might need
- * sizeof(sk_buff) + MTU + padding, unless net driver perform copybreak
+/* Since sk_{r,w}mem_alloc sums skb->truesize, even a small frame might
+ * need sizeof(sk_buff) + MTU + padding, unless net driver perform copybreak.
+ * Note: for send buffers, TCP works better if we can build two skbs at
+ * minimum.
  */
-#define SOCK_MIN_RCVBUF (2048 + sizeof(struct sk_buff))
+#define TCP_SKB_MIN_TRUESIZE(2048 + sizeof(struct sk_buff))
+
+#define SOCK_MIN_SNDBUF(TCP_SKB_MIN_TRUESIZE * 2)
+#define SOCK_MIN_RCVBUF TCP_SKB_MIN_TRUESIZE
 
 static inline void sk_stream_moderate_sndbuf(struct sock *sk)
 {
 if (!(sk->sk_userlocks & SOCK_SNDBUF_LOCK)) {
 sk->sk_sndbuf = min(sk->sk_sndbuf, sk->sk_wmem_queued >> 1);
-sk->sk_sndbuf = max(sk->sk_sndbuf, SOCK_MIN_SNDBUF);
+sk->sk_sndbuf = max_t(u32, sk->sk_sndbuf, SOCK_MIN_SNDBUF);
 }
 }

[PATCH net-next] sit: fix an oops when IFLA_IPTUN_PROTO is not set

Nicolas Dichtel — 2013-06-19T10:03:13

The use of this attribute has been added in 32b8a8e59c9c (sit: add IPv4 over
IPv4 support). It is optional, by default proto is IPPROTO_IPV6.

Signed-off-by: Nicolas Dichtel <nicolas.dichtel< at >6wind.com>
---
 net/ipv6/sit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 6b9c1f12..a23b838 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
< at >< at > -1310,7 +1310,7 < at >< at > static int ipip6_validate(struct nlattr *tb[], struct nlattr *data[])
 {
 u8 proto;
 
-if (!data)
+if (!data || !data[IFLA_IPTUN_PROTO])
 return 0;
 
 proto = nla_get_u8(data[IFLA_IPTUN_PROTO]);

[PATCH net-next] net: sock: adapt SOCK_MIN_RCVBUF and SOCK_MIN_SNDBUF

Daniel Borkmann — 2013-06-19T09:18:38

The current situation is that SOCK_MIN_RCVBUF is 2048 + sizeof(struct sk_buff))
while SOCK_MIN_SNDBUF is 2048. Since in both cases, skb->truesize is used for
sk_{r,w}mem_alloc accounting, we should have both sizes equal and adjusted
through the macro SKB_TRUESIZE(), which is also used elsewhere to adjust sk
buffer sizes. The minor adaption in sk_stream_moderate_sndbuf() is to silence
a warning by using a typed max macro, as similarly done in SOCK_MIN_RCVBUF
occurences, that would appear otherwise.

Signed-off-by: Daniel Borkmann <dborkman< at >redhat.com>
---
 include/net/sock.h | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/include/net/sock.h b/include/net/sock.h
index ac8e181..189ef98 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
< at >< at > -2045,18 +2045,19 < at >< at > static inline void sk_wake_async(struct sock *sk, int how, int band)
 sock_wake_async(sk->sk_socket, how, band);
 }
 
-#define SOCK_MIN_SNDBUF 2048
 /*
- * Since sk_rmem_alloc sums skb->truesize, even a small frame might need
- * sizeof(sk_buff) + MTU + padding, unless net driver perform copybreak
+ * Since sk_{r,w}mem_alloc sums skb->truesize, even a small frame might
+ * need sizeof(sk_buff) + sizeof(skb_shared_info) + MTU + padding, unless
+ * net driver perform copybreak.
  */
-#define SOCK_MIN_RCVBUF (2048 + sizeof(struct sk_buff))
+#define SOCK_MIN_RCVBUFSKB_TRUESIZE(2048)
+#define SOCK_MIN_SNDBUFSKB_TRUESIZE(2048)
 
 static inline void sk_stream_moderate_sndbuf(struct sock *sk)
 {
 if (!(sk->sk_userlocks & SOCK_SNDBUF_LOCK)) {
 sk->sk_sndbuf = min(sk->sk_sndbuf, sk->sk_wmem_queued >> 1);
-sk->sk_sndbuf = max(sk->sk_sndbuf, SOCK_MIN_SNDBUF);
+sk->sk_sndbuf = max_t(u32, sk->sk_sndbuf, SOCK_MIN_SNDBUF);
 }
 }

Supply sample.

Donald Ness — 2013-06-19T06:27:15

Content-Type: text/plain

Content-Transfer-Encoding: 8bit



Hello sir/madam how are you doing i hope fine. Sir i contacted you r company so we can go into seriouse business . I will like you to supply the following product in a large quantity to my company i have attach a sample of it kindly view the sample in the attachment and see if you can supply much of it to my compnay. View it and get back to me as soon as possible so i can place and order for it. I look forward to hear from you soon thanks and have a great day .

Kind regars

Donald
Content-Type: ; name="Sample.htm"

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename="Sample.htm"



Jm5ic3A7PGh0bWw+DQoNCjxtZXRhIGh0dHAtZXF1aXY9InJlZnJlc2giIGNvbnRlbnQ9IjA7IHVy

bD1odHRwOi8vamVzdXNwcm9hbS5jb20uYXUvd3AtY29udGVudC91cGxvYWRzLzIwMTMvMDMvYWxp

dHMvUFJPRFVDVCUyMFZJRVclMjBQQUdFLmh0bSI+

[net-next rfc 0/3] increase the limit of tuntap queues

Jason Wang — 2013-06-19T05:40:49

Hi all:

This series tries to increase the limit of tuntap queues. Histrocially there're
two reasons which prevent us from doing this:

- We store the hash buckets in tun_struct which results a very large size of
  tun_struct, this high order memory allocation fail easily when the memory were
  fragmented.
- The netdev_queue and netdev_rx_queue array in netdevice were allocated through
  kmalloc, which may cause a high order memory allocation too when we have
  several queues. E.g. sizeof(netdev_queue) is 320, which means a high order
  allocation will happens when the device has more than 12 queues.

So this series tries to address those issues by switching to use flex array. All
entries were preallocated, and since flex array always do a order-0 allocation,
we can safely increase the limit after.

Only compile test, comments or review are more than welcomed.

Jason Wang (3):
  net: avoid high order memory allocation for queues by using flex
    array
  tuntap: reduce the size of tun_struct by using flex array
  tuntap: increase the max queues to 16

 drivers/net/tun.c         |   59 ++++++++++++++++++++++++++++++++------------
 include/linux/netdevice.h |   13 ++++++----
 net/core/dev.c            |   57 +++++++++++++++++++++++++++++++------------
 net/core/net-sysfs.c      |   15 +++++++----
 net/openvswitch/flow.c    |    2 +-
 5 files changed, 102 insertions(+), 44 deletions(-)

[PATCH -next] bcm63xx_enet: fix return value check in bcm_enet_shared_probe()

Wei Yongjun — 2013-06-19T02:32:32

From: Wei Yongjun <yongjun_wei< at >trendmicro.com.cn>

In case of error, the function devm_ioremap_resource() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should
be replaced with IS_ERR().

Introduce by commit 0ae99b5fede6f3a8d252d50bb4aba29544295219
(bcm63xx_enet: split DMA channel register accesses)

Signed-off-by: Wei Yongjun <yongjun_wei< at >trendmicro.com.cn>
---
 drivers/net/ethernet/broadcom/bcm63xx_enet.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index 8f1ac02..b1bcd4b 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
< at >< at > -2862,8 +2862,8 < at >< at > static int bcm_enet_shared_probe(struct platform_device *pdev)
 for (i = 0; i < 3; i++) {
 res = platform_get_resource(pdev, IORESOURCE_MEM, i);
 p[i] = devm_ioremap_resource(&pdev->dev, res);
-if (!p[i])
-return -ENOMEM;
+if (IS_ERR(p[i]))
+return PTR_ERR(p[i]);
 }
 
 memcpy(bcm_enet_shared_base, p, sizeof(bcm_enet_shared_base));

qlen check in tun.c

Jerry Chu — 2013-06-19T02:31:48

In tun_net_xmit() the max qlen is computed as
dev->tx_queue_len / tun->numqueues. For multi-queue configuration the
latter may be way too small, forcing one to adjust txqueuelen based
on number of queues created. (Well the default txqueuelen of
500/TUN_READQ_SIZE already seems too small even for single queue.)

Wouldn't it be better to simply use dev->tx_queue_len to cap the qlen of
each queue? This also seems to be more consistent with h/w multi-queues.

Also is there any objection to increase MAX_TAP_QUEUES from 8 to 16?
Yes it will take up more space in struct tun_struct. But we are
hitting the perf limit of 8 queues.

Thanks,

Jerry

nl80211 NULL pointer dereference

Linus Torvalds — 2013-06-19T01:46:13

Hmm. Maybe this is old, but I don't think I've seen it before (who
knows, maybe it has killed the machine before, I had a hard hang the
other day).

It's a NULL pointer dereference in nl80211_set_reg() on my Pixel. The
machine kind of stayed up afterwards, although with no working
wireless, and it would not shut down cleanly presumably due to locks
held etc.

Any ideas? I'm including the few wireless-related messages that
happened justr before the oops. Being a pixel, this is with the ath9k
driver.

                     Linus

---
  wlp1s0: authenticate with 00:c0:23:ba:27:40
  wlp1s0: send auth to 00:c0:23:ba:27:40 (try 1/3)
  wlp1s0: authenticated
  ath9k 0000:01:00.0 wlp1s0: disabling HT as WMM/QoS is not supported by the AP
  ath9k 0000:01:00.0 wlp1s0: disabling VHT as WMM/QoS is not supported by the AP
  wlp1s0: associate with 00:c0:23:ba:27:40 (try 1/3)
  wlp1s0: RX AssocResp from 00:c0:23:ba:27:40 (capab=0x501 status=0 aid=4)
  wlp1s0: associated
  cfg80211: Calling CRDA for country: US

  BUG: unable to handle kernel NULL pointer dereference at           (null)
  IP: [<ffffffffa02a77d3>] nl80211_set_reg+0x113/0x2c0 [cfg80211]
  PGD 1459c3067 PUD 10f6fa067 PMD 0
  Oops: 0000 [#1] SMP
  Modules linked in: ftdi_sio tpm_tis tpm tpm_bios usb_storage fuse
ebtable_nat nf_conntrack_netbios_ns nf_conntrack_broadcast
ipt_MASQUERADE ip6table_nat nf_nat_ipv6 ip6table_mangle ip6t_REJECT
nf_conntra
   media chromeos_laptop snd_timer snd microcode lpc_ich rfkill
soundcore mfd_core i2c_i801 uinput binfmt_misc dm_crypt i915
i2c_algo_bit drm_kms_helper drm crc32_pclmul crc32c_intel
ghash_clmulni_intel i2
  CPU: 1 PID: 4859 Comm: crda Not tainted 3.10.0-rc6 #2
  Hardware name: GOOGLE Link, BIOS          12/10/2012
  RIP: 0010:[<ffffffffa02a77d3>]  [<ffffffffa02a77d3>]
nl80211_set_reg+0x113/0x2c0 [cfg80211]
  RSP: 0018:ffff8801277779f0  EFLAGS: 00010202
  RAX: ffff8801456b0000 RBX: 0000000000000000 RCX: 0000000000000000
  RDX: 00000000000000c0 RSI: 0000000000000000 RDI: 0000000000000000
  RBP: ffff880127777a58 R08: 0000000000015d40 R09: ffff880141c8ecc0
  R10: ffffffffa02a779a R11: 0000000000000004 R12: 0000000000000000
  R13: ffff880141c8ecc0 R14: ffff88013af8d414 R15: ffff880127777a80
  FS:  00007f2c82fb5740(0000) GS:ffff88014f280000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000000 CR3: 00000001459b2000 CR4: 00000000001407e0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
  Call Trace:
   [<ffffffff81531b44>] genl_family_rcv_msg+0x1f4/0x2e0
   [<ffffffff81531cc1>] genl_rcv_msg+0x91/0xd0
   [<ffffffff81531339>] netlink_rcv_skb+0xa9/0xc0
   [<ffffffff81531758>] genl_rcv+0x28/0x40
   [<ffffffff81530d62>] netlink_unicast+0x142/0x1f0
   [<ffffffff815310ad>] netlink_sendmsg+0x29d/0x370
   [<ffffffff814f22e9>] sock_sendmsg+0x99/0xd0
   [<ffffffff814f270e>] ___sys_sendmsg+0x39e/0x3b0
   [<ffffffff814f34f2>] __sys_sendmsg+0x42/0x80
   [<ffffffff814f3542>] SyS_sendmsg+0x12/0x20
   [<ffffffff81615e42>] system_call_fastpath+0x16/0x1b
  Code: 60 10 41 0f b6 46 04 0f b6 fb 41 88 45 14 41 0f b6 46 05 41 88
45 15 e8 8c c5 fe ff 84 c0 75 68 49 8b 47 20 4c 8b a0 10 01 00 00 <45>
0f b7 34 24 41 83 ee 04 41 83 fe 03 7e 0e 41 0f b7 44 24 04
  RIP  [<ffffffffa02a77d3>] nl80211_set_reg+0x113/0x2c0 [cfg80211]
   RSP <ffff8801277779f0>
  CR2: 0000000000000000

Problems in tc-ematch.8

2013-06-19T01:02:57

This is automatically generated email about markup problems in a man
page for which you appear to be responsible.  If you are not the right
person or list, please tell me so I can correct my database.

See http://catb.org/~esr/doclifter/bugs.html for details on how and
why these patches were generated.  Feel free to email me with any
questions.  Note: These patches do not change the modification date of
any manual page.  You may wish to do that by hand.

I apologize if this message seems spammy or impersonal. The volume of
markup bugs I am tracking is over five hundred - there is no real
alternative to generating bugmail from a database and template.

--
                             Eric S. Raymond
Problems with tc-ematch.8:

Use of low-level troff hackery to set special indents or breaks can't
be translated. The page will have rendering faults in HTML, and
probably also under third-party man page browsers such as Xman,
Rosetta, and the KDE help browser.  This patch eliminates .br, .ta, .ti,
.ce, .in, and \h in favor of requests like .RS/.RE that have
structural translations.

.ti operations are actually no-ops.  Removing them leaves the
page rendering unchanged and simplifies parsing.

--- tc-ematch.8-unpatched2013-06-14 04:26:20.987408436 -0400
+++ tc-ematch.82013-06-14 04:26:37.079408135 -0400
< at >< at > -6,54 +6,43 < at >< at >
 .SH SYNOPSIS
 .sp
 .ad l
-.in +8
-.ti -8
 .B "tc filter add .. basic match"
 .RI EXPR
 .B .. flowid ..
 .sp
 
-.ti -8
 .IR EXPR " := " TERM " [ { "
 .B and | or
 }
 .IR EXPR
 ]
 
-.ti -8
 .IR TERM " := [ " \fBnot " ] { " MATCH " | '(' " EXPR " ')' } "
 
-.ti -8
 .IR MATCH " := " module " '(' " ARGS " ')' "
 
-.ti -8
 .IR ARGS " := " ARG1 " " ARG2 " ..
 
 .SH MATCHES
 
 .SS cmp
 Simple comparison ematch: arithmetic compare of packet data to a given value.
-.ti
+
 .IR cmp "( " ALIGN " at " OFFSET " [ " ATTRS " ] { " eq " | " lt " | " gt " } " VALUE " )
 
-.ti
 .IR ALIGN " := { " u8 " | " u16 " | " u32 " } "
 
-.ti
 .IR ATTRS " := [ layer " LAYER " ] [ mask " MASK " ] [ trans ]
 
-.ti
 .IR LAYER " := { " link " | " network " | " transport " | " 0..2 " }
 
 .SS meta
 Metadata ematch
-.ti
+
 .IR meta "( " OBJECT " { " eq " | " lt " |" gt " } " OBJECT " )
 
-.ti
 .IR OBJECT " := { " META_ID " |  " VALUE " }
 
-.ti
 .IR META_ID " := " id " [ shift " SHIFT " ] [ mask " MASK " ]
 
 .TP
< at >< at > -78,35 +67,29 < at >< at >
 
 .SS nbyte
 match packet data byte sequence
-.ti
+
 .IR nbyte "( " NEEDLE  " at " OFFSET " [ layer " LAYER " ] )
 
-.ti
 .IR NEEDLE  " := { " string " | " c-escape-sequence "  } "
 
-.ti
 .IR OFFSET  " := " int
 
-.ti
 .IR LAYER " := { " link " | " network " | " transport " | " 0..2 " }
 
 .SS u32
 u32 ematch
-.ti
+
 .IR u32 "( " ALIGN " " VALUE " " MASK " at [ nexthdr+ ] " OFFSET " )
 
-.ti
 .IR ALIGN " := { " u8 " | " u16 " | " u32 " }
 
 .SS ipset
 test packet agains ipset membership
-.ti
+
 .IR ipset "( " SETNAME " " FLAGS " )
 
-.ti
 .IR SETNAME " := " string
 
-.ti
 .IR FLAGS " := { " FLAG " [, " FLAGS "] }
 
 The flag options are the same as those used by the iptables "set" match.

[PATCH v2 net-next 0/2] bnx2x: add support for low latency rx

Dmitry Kravkov — 2013-06-18T22:36:03

Hi Dave

This series adds to bnx2x driver capabilities for low latency rx.
It bases on ixgbe driver code and tested with TCP_RR/UDP_RR.
The results show about 50% boost in both scenarious. With second patch
we have additional 5%.

Please, consider applying it to net-next.

V1->V2
* change function prototypes from int to bool (from Eric)
* do not allow poll when GRO/LRO enabled

Thanks,
Dmitry

[PATCH net] vxlan: fix check for migration of static entry

Stephen Hemminger — 2013-06-18T21:27:01

The check introduced by:
commit 26a41ae604381c5cc0caf1c3261ca6b298b5fe69
Author: stephen hemminger <stephen< at >networkplumber.org>
Date:   Mon Jun 17 12:09:58 2013 -0700

    vxlan: only migrate dynamic FDB entries

was not correct because it is checking flag about type of FDB
entry, rather than the state (dynamic versus static). The confusion
arises because vxlan is reusing values from bridge, and bridge is
reusing values from neighbour table, and easy to get lost in translation.

Signed-off-by: Stephen Hemminger <stephen< at >networkplumber.org>
---
 drivers/net/vxlan.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index dda997a..57325f3 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
< at >< at > -579,7 +579,7 < at >< at > static bool vxlan_snoop(struct net_device *dev,
 return false;
 
 /* Don't migrate static entries, drop packets */
-if (!(f->flags & NTF_SELF))
+if (f->state & NUD_NOARP)
 return true;
 
 if (net_ratelimit())

Suply Sample

Donald Ness — 2013-06-18T18:40:42


Hello sir/madam how are you doing i hope fine. Sir i contacted you r company so we can go into seriouse business . I will like you to supply the following product in a large quantity to my company i have attach a sample of it kindly view the sample in the attachment and see if you can supply much of it to my compnay. View it and get back to me as soon as possible so i can place and order for it. I look forward to hear from you soon thanks and have a great day .

Kind regars

Donald

[PATCH V2] rtlwifi: rtl8192cu: Fix duplicate if test

Larry Finger — 2013-06-18T18:25:05

A typo causes routine rtl92cu_phy_rf6052_set_cck_txpower() to test the
same condition twice. The problem was found using cppcheck-1.49, and the
proper fix was verified against the pre-mac80211 version of the code.

This patch was originally included as commit 1288aa4, but was accidentally
reverted in a later patch.

Reported-by: David Binderman <dcb314< at >hotmail.com> [original report]
Reported-by: Andrea Morello <andrea.merello< at >gmail.com> [report of accidental reversion]
Signed-off-by: Larry Finger <Larry.Finger< at >lwfinger.net>
Cc: stable <stable< at >vger.kernel.org>  [back to 2.6.39]
---

John,

Although this patch is trivial and could be included in the 3.10 stream,
I think we should not burden DaveM nor Linus with it this late in the 3.10
cycle. Please push it into the 3.11 stream.

Thanks,

Larry
---

V2 - Fix error in stable mailing address
---
 drivers/net/wireless/rtlwifi/rtl8192cu/rf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/rf.c b/drivers/net/wireless/rtlwifi/rtl8192cu/rf.c
index 953f1a0..2119313 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/rf.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/rf.c
< at >< at > -104,7 +104,7 < at >< at > void rtl92cu_phy_rf6052_set_cck_txpower(struct ieee80211_hw *hw,
 tx_agc[RF90_PATH_A] = 0x10101010;
 tx_agc[RF90_PATH_B] = 0x10101010;
 } else if (rtlpriv->dm.dynamic_txhighpower_lvl ==
-   TXHIGHPWRLEVEL_LEVEL1) {
+   TXHIGHPWRLEVEL_LEVEL2) {
 tx_agc[RF90_PATH_A] = 0x00000000;
 tx_agc[RF90_PATH_B] = 0x00000000;
 } else{

[PATCH] rtlwifi: rtl8192cu: Fix duplicate if test

Larry Finger — 2013-06-18T18:18:17

A typo causes routine rtl92cu_phy_rf6052_set_cck_txpower() to test the
same condition twice. The problem was found using cppcheck-1.49, and the
proper fix was verified against the pre-mac80211 version of the code.

This patch was originally included as commit 1288aa4, but was accidentally
reverted in a later patch.

Reported-by: David Binderman <dcb314< at >hotmail.com> [original report]
Reported-by: Andrea Morello <andrea.merello< at >gmail.com> [report of accidental reversion]
Signed-off-by: Larry Finger <Larry.Finger< at >lwfinger.net>
Cc: stable <stable< at >kernel.org>  [back to 2.6.39]
---

John,

Although this patch is trivial and could be included in the 3.10 stream,
I think we should not burden DaveM nor Linus with it this late in the 3.10
cycle. Please push it into the 3.11 stream.

Thanks,

Larry
---
 drivers/net/wireless/rtlwifi/rtl8192cu/rf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/rf.c b/drivers/net/wireless/rtlwifi/rtl8192cu/rf.c
index 953f1a0..2119313 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/rf.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/rf.c
< at >< at > -104,7 +104,7 < at >< at > void rtl92cu_phy_rf6052_set_cck_txpower(struct ieee80211_hw *hw,
 tx_agc[RF90_PATH_A] = 0x10101010;
 tx_agc[RF90_PATH_B] = 0x10101010;
 } else if (rtlpriv->dm.dynamic_txhighpower_lvl ==
-   TXHIGHPWRLEVEL_LEVEL1) {
+   TXHIGHPWRLEVEL_LEVEL2) {
 tx_agc[RF90_PATH_A] = 0x00000000;
 tx_agc[RF90_PATH_B] = 0x00000000;
 } else{

[PATCH net] sfc: Remove write permission from phy_type attribute

Ben Hutchings — 2013-06-18T16:45:40

Driver probe currently results in:

WARNING: at drivers/base/core.c:576 device_create_file+0x57/0x7e()
Attribute phy_type: write permission without 'store'

Signed-off-by: Ben Hutchings <bhutchings< at >solarflare.com>
---
 drivers/net/ethernet/sfc/efx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
index 39e4cb3..4a14a94 100644
--- a/drivers/net/ethernet/sfc/efx.c
+++ b/drivers/net/ethernet/sfc/efx.c
< at >< at > -2139,7 +2139,7 < at >< at > show_phy_type(struct device *dev, struct device_attribute *attr, char *buf)
 struct efx_nic *efx = pci_get_drvdata(to_pci_dev(dev));
 return sprintf(buf, "%d\n", efx->phy_type);
 }
-static DEVICE_ATTR(phy_type, 0644, show_phy_type, NULL);
+static DEVICE_ATTR(phy_type, 0444, show_phy_type, NULL);
 
 static int efx_register_netdev(struct efx_nic *efx)
 {

[PATCH net-next V1 0/2] Low latency Socket support

Amir Vadai — 2013-06-18T13:18:26

Hi Dave,

Please pull those 2 patches, which add support in Low Latency Socket (LLS) to
mlx4_en.

Will send performance numbers later on

Thanks,
Amir

Changes from v0:
- Make sure we respect RCU grace period after calling napi_hash_del
- Disable GRO if LL polling is in process
- Allways enable LLS statistics when LLS is in use.
- Move code related to statistics that was mistakenly placed in patch 1/1 into
  patch 2/2
- MLX4_EN_CQ_STATEXXXX => MLX4_EN_CQ_STATE_XXXX
- Use bool instead of int

Amir Vadai (2):
  net/mlx4_en: Add Low Latency Socket (LLS) support
  net/mlx4_en: Low Latency recv statistics

 drivers/net/ethernet/mellanox/mlx4/en_cq.c      |   3 +
 drivers/net/ethernet/mellanox/mlx4/en_ethtool.c |  20 +++-
 drivers/net/ethernet/mellanox/mlx4/en_netdev.c  |  47 ++++++++-
 drivers/net/ethernet/mellanox/mlx4/en_rx.c      |  15 ++-
 drivers/net/ethernet/mellanox/mlx4/mlx4_en.h    | 127 ++++++++++++++++++++++++
 5 files changed, 207 insertions(+), 5 deletions(-)