* Re: [PATCH -next 0/5] netlink: remove mmapped netlink support
From: Richard Weinberger @ 2016-03-27 7:32 UTC (permalink / raw)
To: Florian Westphal
Cc: netdev@vger.kernel.org, Daniel Borkmann, Ken-ichirou MATSUZAWA,
Thomas Graf, Pablo Neira Ayuso, Patrick McHardy
In-Reply-To: <1455804208-30512-1-git-send-email-fw@strlen.de>
On Thu, Feb 18, 2016 at 3:03 PM, Florian Westphal <fw@strlen.de> wrote:
> As discussed during netconf 2016 in Seville, this series removes
> CONFIG_NETLINK_MMAP.
Sorry for hopping in so^Wtoo late.
I always thought mmaped netlink is the way to go for
userspace packet processing.
Sure, the problems you state are real but that the whole concept
is now thrown away kind of surprises me.
> Close to three years after it was merged it has retained several problems
> that do not appear to be fixable.
>
> No official netfilter libmnl release contains support for mmap backed netlink
> sockets. No openvswitch release makes use of it either.
>
> To use the mmap interface, userspace not only has to probe for mmap netlink
> support, it also has to implement a recv/socket receive path in order to
> handle messages that exceed the size of an rx ring element (NL_MMAP_STATUS_COPY).
>
> So if there are odd programs out there that attempt to use MMAP netlink
> they should continue to work as they already need a socket based code path
> to work properly.
>
> The actual revert (first patch) has a list of problems.
> The followup patches remove a couple of helpers that are no longer needed
> after the revert.
>
> I did a few tests with mmap vs. socket based interface on a 4.4 based
> kernel on an i7-4790 box and there are no performance advantages:
Did you also test smaller devices?
i.e. stuff one would use for cheap routers.
--
Thanks,
//richard
^ permalink raw reply
* [PATCH 25/31] ethernet: use parity8 in sun/niu.c
From: zhaoxiu.zeng @ 2016-03-27 7:36 UTC (permalink / raw)
To: Jiri Pirko, Andrew Morton, Michal Nazarewicz, David S. Miller,
Vlastimil Babka, Joonsoo Kim
Cc: linux-kernel, netdev
In-Reply-To: <1458788612-4367-1-git-send-email-zhaoxiu.zeng@gmail.com>
From: Zeng Zhaoxiu <zhaoxiu.zeng@gmail.com>
Signed-off-by: Zeng Zhaoxiu <zhaoxiu.zeng@gmail.com>
---
drivers/net/ethernet/sun/niu.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/sun/niu.c b/drivers/net/ethernet/sun/niu.c
index 9cc4564..8c344ef 100644
--- a/drivers/net/ethernet/sun/niu.c
+++ b/drivers/net/ethernet/sun/niu.c
@@ -2742,18 +2742,12 @@ static int niu_set_alt_mac_rdc_table(struct niu *np, int idx,
static u64 vlan_entry_set_parity(u64 reg_val)
{
- u64 port01_mask;
- u64 port23_mask;
-
- port01_mask = 0x00ff;
- port23_mask = 0xff00;
-
- if (hweight64(reg_val & port01_mask) & 1)
+ if (parity8(reg_val))
reg_val |= ENET_VLAN_TBL_PARITY0;
else
reg_val &= ~ENET_VLAN_TBL_PARITY0;
- if (hweight64(reg_val & port23_mask) & 1)
+ if (parity8((unsigned int)reg_val >> 8))
reg_val |= ENET_VLAN_TBL_PARITY1;
else
reg_val &= ~ENET_VLAN_TBL_PARITY1;
--
2.5.5
^ permalink raw reply related
* [PATCH 31/31] ethernet: broadcom: use parity8 in tg3.c
From: zhaoxiu.zeng @ 2016-03-27 7:50 UTC (permalink / raw)
To: Siva Reddy Kallam, Prashant Sreedharan, Michael Chan; +Cc: linux-kernel, netdev
In-Reply-To: <1458788612-4367-1-git-send-email-zhaoxiu.zeng@gmail.com>
From: Zeng Zhaoxiu <zhaoxiu.zeng@gmail.com>
Signed-off-by: Zeng Zhaoxiu <zhaoxiu.zeng@gmail.com>
---
drivers/net/ethernet/broadcom/tg3.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 3010080..802a429 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -12939,11 +12939,7 @@ static int tg3_test_nvram(struct tg3 *tp)
err = -EIO;
for (i = 0; i < NVRAM_SELFBOOT_DATA_SIZE; i++) {
- u8 hw8 = hweight8(data[i]);
-
- if ((hw8 & 0x1) && parity[i])
- goto out;
- else if (!(hw8 & 0x1) && !parity[i])
+ if (parity8(data[i]) == !!parity[i])
goto out;
}
err = 0;
--
2.5.5
^ permalink raw reply related
* Re: [PATCH] net: sxgbe: fix error paths in sxgbe_platform_probe()
From: Francois Romieu @ 2016-03-27 8:22 UTC (permalink / raw)
To: Rasmus Villemoes; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <1459027449-2667-1-git-send-email-linux@rasmusvillemoes.dk>
Rasmus Villemoes <linux@rasmusvillemoes.dk> :
> We need to use post-decrement to ensure that irq_dispose_mapping is
> also called on priv->rxq[0]->irq_no; moreover, if one of the above for
> loops failed already at i==0 (so we reach one of these labels with
> that value of i), we'll enter an essentially infinite loop of
> out-of-bounds accesses.
>
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
(ok, i is signed)
Reviewed-by: Francois Romieu <romieu@fr.zoreil.com>
Someone messed with my review on 2014/03/25 and got it wrong. :o/
Two years after the initial submission, there is zero change regarding use
of sxgbe_core_ops for extension or manageability. The extra indirection is
ripe for removal during next net-next.
--
Ueimor
^ permalink raw reply
* [PATCH] ravb: fix software timestamping
From: Lino Sanfilippo @ 2016-03-27 10:22 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, Lino Sanfilippo
In ravb_start_xmit dont call skb_tx_timestamp only when hardware
timestamping is requested: in the latter case software timestamps are
suppressed and thus the call of skb_tx_timestamp does not have any effect.
Instead call skb_tx_timestamp unconditionally in ravb_start_xmit, since
the function checks itself if software timestamping is required or should
be skipped due to hardware timestamping.
Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
---
drivers/net/ethernet/renesas/ravb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Sergei, please note that this is only compile tested, since I dont have access
to the concerning hardware.
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 4e1a7db..087e14a 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -1377,11 +1377,11 @@ static netdev_tx_t ravb_start_xmit(struct sk_buff *skb, struct net_device *ndev)
/* TAG and timestamp required flag */
skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
- skb_tx_timestamp(skb);
desc->tagh_tsr = (ts_skb->tag >> 4) | TX_TSR;
desc->ds_tagl |= le16_to_cpu(ts_skb->tag << 12);
}
+ skb_tx_timestamp(skb);
/* Descriptor type must be set after all the above writes */
dma_wmb();
desc->die_dt = DT_FEND;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] drivers : Remove unnecessary void pointer conversions
From: Sergei Shtylyov @ 2016-03-27 11:46 UTC (permalink / raw)
To: Bhaskar Jupudi, davem, igal.liberman, netdev, linux-kernel
In-Reply-To: <1459050140-14621-1-git-send-email-njupudi@ucsc.edu>
Hello.
On 3/27/2016 6:42 AM, Bhaskar Jupudi wrote:
> Explicit void pointer conversion is unnecessary
> because the conversions to and from a void pointer
> are always implicit in 'C'. Changed two instances
> of such conversions.
>
>
> Signed-off-by: Bhaskar Jupudi <njupudi@ucsc.edu>
> ---
> This patch is based on Kernel Janitors To-Do list
>
> drivers/net/ethernet/freescale/fman/fman.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/fman/fman.c b/drivers/net/ethernet/freescale/fman/fman.c
> index 623aa1c..8719f7b 100644
> --- a/drivers/net/ethernet/freescale/fman/fman.c
> +++ b/drivers/net/ethernet/freescale/fman/fman.c
> @@ -2668,7 +2668,7 @@ static struct fman *read_dts_node(struct platform_device *of_dev)
>
> fm_node = of_node_get(of_dev->dev.of_node);
>
> - u32_prop = (const u32 *)of_get_property(fm_node, "cell-index", &lenp);
> + u32_prop = of_get_property(fm_node, "cell-index", &lenp);
This function returns a pointer to big-endian data, no?
> if (!u32_prop) {
> dev_err(&of_dev->dev, "%s: of_get_property(%s, cell-index) failed\n",
> __func__, fm_node->full_name);
> @@ -2724,7 +2724,7 @@ static struct fman *read_dts_node(struct platform_device *of_dev)
> /* Rounding to MHz */
> fman->dts_params.clk_freq = DIV_ROUND_UP(clk_rate, 1000000);
>
> - u32_prop = (const u32 *)of_get_property(fm_node,
> + u32_prop = of_get_property(fm_node,
Same here...
> "fsl,qman-channel-range",
> &lenp);
Please re-align these continuation lines.
[...]
MBR, Sergei
^ permalink raw reply
* BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet
From: Baozeng Ding @ 2016-03-27 12:35 UTC (permalink / raw)
To: pablo, kaber, kadlec, davem; +Cc: netfilter-devel, netdev
Hi all,
The following program triggers stack-out-of-bounds in tcp_packet. The
kernel version is 4.5 (on Mar 16 commit 09fd671ccb2475436bd5f597f751ca4a7d177aea).
Uncovered with syzkaller. Thanks.
==================================================================
BUG: KASAN: stack-out-of-bounds in tcp_packet+0x4b77/0x51c0 at addr ffff8800a45df3c8
Read of size 1 by task 0327/11132
page:ffffea00029177c0 count:0 mapcount:0 mapping: (null) index:0x0
flags: 0x1fffc0000000000()
page dumped because: kasan: bad access detected
CPU: 1 PID: 11132 Comm: 0327 Tainted: G B 4.5.0+ #12
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
0000000000000001 ffff8800a45df148 ffffffff82945051 ffff8800a45df1d8
ffff8800a45df3c8 0000000000000027 0000000000000001 ffff8800a45df1c8
ffffffff81709f88 ffff8800b4f7e3d0 0000000000000028 0000000000000286
Call Trace:
[< inline >] __dump_stack /kernel/lib/dump_stack.c:15
[<ffffffff82945051>] dump_stack+0xb3/0x112 /kernel/lib/dump_stack.c:51
[< inline >] print_address_description /kernel/mm/kasan/report.c:150
[<ffffffff81709f88>] kasan_report_error+0x4f8/0x530 /kernel/mm/kasan/report.c:236
[<ffffffff84c54b8d>] ? skb_copy_bits+0x49d/0x6d0 /kernel/net/core/skbuff.c:1675
[< inline >] ? spin_lock_bh /kernel/include/linux/spinlock.h:307
[<ffffffff84e0e9b9>] ? tcp_packet+0x1c9/0x51c0 /kernel/net/netfilter/nf_conntrack_proto_tcp.c:833
[< inline >] kasan_report /kernel/mm/kasan/report.c:259
[<ffffffff81709ffe>] __asan_report_load1_noabort+0x3e/0x40 /kernel/mm/kasan/report.c:277
[< inline >] ? tcp_sack /kernel/net/netfilter/nf_conntrack_proto_tcp.c:473
[< inline >] ? tcp_in_window /kernel/net/netfilter/nf_conntrack_proto_tcp.c:527
[<ffffffff84e13367>] ? tcp_packet+0x4b77/0x51c0 /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1036
[< inline >] tcp_sack /kernel/net/netfilter/nf_conntrack_proto_tcp.c:473
[< inline >] tcp_in_window /kernel/net/netfilter/nf_conntrack_proto_tcp.c:527
[<ffffffff84e13367>] tcp_packet+0x4b77/0x51c0 /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1036
[<ffffffff817094b8>] ? memset+0x28/0x30 /kernel/mm/kasan/kasan.c:302
[<ffffffff84e0dd74>] ? tcp_new+0x1a4/0xc20 /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1122
[< inline >] ? build_report /kernel/include/net/netlink.h:499
[<ffffffff8518c4d6>] ? xfrm_send_report+0x426/0x450 /kernel/net/xfrm/xfrm_user.c:3039
[<ffffffff84e0e7f0>] ? tcp_new+0xc20/0xc20 /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1169
[<ffffffff84dfb03a>] ? init_conntrack+0xca/0x9e0 /kernel/net/netfilter/nf_conntrack_core.c:972
[<ffffffff84dfaf70>] ? nf_conntrack_alloc+0x40/0x40 /kernel/net/netfilter/nf_conntrack_core.c:903
[<ffffffff84e0cdf0>] ? tcp_init_net+0x6e0/0x6e0 /kernel/include/net/netfilter/nf_conntrack_l4proto.h:137
[<ffffffff85121732>] ? ipv4_get_l4proto+0x262/0x390 /kernel/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c:89
[<ffffffff84df372f>] ? nf_ct_get_tuple+0xaf/0x190 /kernel/net/netfilter/nf_conntrack_core.c:197
[<ffffffff84dfc23e>] nf_conntrack_in+0x8ee/0x1170 /kernel/net/netfilter/nf_conntrack_core.c:1177
[<ffffffff84dfb950>] ? init_conntrack+0x9e0/0x9e0 /kernel/net/netfilter/nf_conntrack_core.c:287
[<ffffffff8512ab06>] ? ipt_do_table+0xa16/0x1260 /kernel/net/ipv4/netfilter/ip_tables.c:423
[<ffffffff81405ced>] ? trace_hardirqs_on+0xd/0x10 /kernel/kernel/locking/lockdep.c:2635
[<ffffffff81311fcb>] ? __local_bh_enable_ip+0x6b/0xc0 /kernel/kernel/softirq.c:175
[<ffffffff8512a0f0>] ? check_entry.isra.4+0x190/0x190 /kernel/net/ipv6/netfilter/ip6_tables.c:594
[<ffffffff84f9d4e0>] ? ip_reply_glue_bits+0xc0/0xc0 /kernel/net/ipv4/ip_output.c:1530
[<ffffffff851219ae>] ipv4_conntrack_local+0x14e/0x1a0 /kernel/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c:161
[<ffffffff85131b3d>] ? iptable_raw_hook+0x9d/0x1e0 /kernel/net/ipv4/netfilter/iptable_raw.c:32
[<ffffffff84de5b7d>] nf_iterate+0x15d/0x230 /kernel/net/netfilter/core.c:274
[<ffffffff84de5c50>] ? nf_iterate+0x230/0x230 /kernel/net/netfilter/core.c:268
[<ffffffff84de5dfd>] nf_hook_slow+0x1ad/0x310 /kernel/net/netfilter/core.c:306
[<ffffffff84de5c50>] ? nf_iterate+0x230/0x230 /kernel/net/netfilter/core.c:268
[<ffffffff84de5c50>] ? nf_iterate+0x230/0x230 /kernel/net/netfilter/core.c:268
[<ffffffff82979274>] ? prandom_u32+0x24/0x30 /kernel/lib/random32.c:83
[<ffffffff84f747ff>] ? ip_idents_reserve+0x9f/0xf0 /kernel/net/ipv4/route.c:484
[< inline >] nf_hook_thresh /kernel/include/linux/netfilter.h:187
[< inline >] nf_hook /kernel/include/linux/netfilter.h:197
[<ffffffff84fa4f53>] __ip_local_out+0x263/0x3c0 /kernel/net/ipv4/ip_output.c:104
[<ffffffff84fa4cf0>] ? ip_finish_output+0xd00/0xd00 /kernel/include/net/ip.h:322
[<ffffffff84fa0230>] ? __ip_flush_pending_frames.isra.45+0x2e0/0x2e0 /kernel/net/ipv4/ip_output.c:1337
[<ffffffff84faa336>] ? __ip_make_skb+0xfe6/0x1610 /kernel/net/ipv4/ip_output.c:1436
[<ffffffff84fa50dd>] ip_local_out+0x2d/0x1c0 /kernel/net/ipv4/ip_output.c:113
[<ffffffff84faa99c>] ip_send_skb+0x3c/0xc0 /kernel/net/ipv4/ip_output.c:1443
[<ffffffff84faaa84>] ip_push_pending_frames+0x64/0x80 /kernel/net/ipv4/ip_output.c:1463
[< inline >] rcu_read_unlock /kernel/include/linux/rcupdate.h:922
[<ffffffff8504e10b>] raw_sendmsg+0x17bb/0x25c0 /kernel/net/ieee802154/socket.c:53
[<ffffffff8504c950>] ? dst_output+0x190/0x190 /kernel/include/net/dst.h:492
[< inline >] ? trace_mm_page_alloc /kernel/include/trace/events/kmem.h:217
[<ffffffff81621609>] ? __alloc_pages_nodemask+0x559/0x16b0 /kernel/mm/page_alloc.c:3368
[<ffffffff81406260>] ? debug_check_no_locks_freed+0x290/0x290 /kernel/kernel/locking/lockdep.c:4104
[<ffffffff814c0e30>] ? is_module_text_address+0x10/0x20 /kernel/kernel/module.c:4057
[<ffffffff81360533>] ? __kernel_text_address+0x73/0xa0 /kernel/kernel/extable.c:103
[<ffffffff81406260>] ? debug_check_no_locks_freed+0x290/0x290 /kernel/kernel/locking/lockdep.c:4104
[<ffffffff81406260>] ? debug_check_no_locks_freed+0x290/0x290 /kernel/kernel/locking/lockdep.c:4104
[<ffffffff81405ced>] ? trace_hardirqs_on+0xd/0x10 /kernel/kernel/locking/lockdep.c:2635
[<ffffffff81406260>] ? debug_check_no_locks_freed+0x290/0x290 /kernel/kernel/locking/lockdep.c:4104
[< inline >] ? sock_rps_record_flow /kernel/include/net/sock.h:874
[<ffffffff85089113>] ? inet_sendmsg+0x73/0x4c0 /kernel/net/ipv4/af_inet.c:729
[< inline >] ? rcu_read_unlock /kernel/include/linux/rcupdate.h:922
[< inline >] ? sock_rps_record_flow_hash /kernel/include/net/sock.h:867
[< inline >] ? sock_rps_record_flow /kernel/include/net/sock.h:874
[<ffffffff8508929a>] ? inet_sendmsg+0x1fa/0x4c0 /kernel/net/ipv4/af_inet.c:729
[<ffffffff85089395>] inet_sendmsg+0x2f5/0x4c0 /kernel/net/ipv4/af_inet.c:736
[< inline >] ? sock_rps_record_flow /kernel/include/net/sock.h:874
[<ffffffff85089113>] ? inet_sendmsg+0x73/0x4c0 /kernel/net/ipv4/af_inet.c:729
[<ffffffff850890a0>] ? inet_recvmsg+0x4a0/0x4a0 /kernel/include/linux/compiler.h:222
[< inline >] sock_sendmsg_nosec /kernel/net/socket.c:611
[<ffffffff84c3434a>] sock_sendmsg+0xca/0x110 /kernel/net/socket.c:621
[<ffffffff84c35448>] SYSC_sendto+0x208/0x350 /kernel/net/socket.c:1651
[<ffffffff84c35240>] ? SYSC_connect+0x2e0/0x2e0 /kernel/net/socket.c:1543
[<ffffffff81698650>] ? __pmd_alloc+0x350/0x350 /kernel/mm/memory.c:3928
[<ffffffff81230b3b>] ? __do_page_fault+0x2ab/0x8e0 /kernel/arch/x86/mm/fault.c:1184
[<ffffffff81230c30>] ? __do_page_fault+0x3a0/0x8e0 /kernel/arch/x86/mm/fault.c:1271
[<ffffffff813fb5da>] ? up_read+0x1a/0x40 /kernel/kernel/locking/rwsem.c:79
[<ffffffff81230a29>] ? __do_page_fault+0x199/0x8e0 /kernel/arch/x86/mm/fault.c:1187
[<ffffffff84c379b0>] SyS_sendto+0x40/0x50 /kernel/net/socket.c:1619
[<ffffffff85dab940>] entry_SYSCALL_64_fastpath+0x23/0xc1 /kernel/arch/x86/entry/entry_64.S:207
Memory state around the buggy address:
ffff8800a45df280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8800a45df300: f1 f1 f1 f1 00 00 04 f4 f2 f2 f2 f2 00 00 04 f4
>ffff8800a45df380: f2 f2 f2 f2 00 00 00 00 00 f4 f4 f4 f3 f3 f3 f3
^
ffff8800a45df400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8800a45df480: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 01 f4 f4 f4
==================================================================
#include <unistd.h>
#include <sys/syscall.h>
#include <string.h>
#include <stdint.h>
#include <pthread.h>
#include <sys/socket.h>
#include <sys/mman.h>
#include <netinet/in.h>
int main()
{
mmap((void *)0x20000000ul, 0x19000ul, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0);
int sock = socket(AF_INET, SOCK_RAW, IPPROTO_TCP);
int sock_dup = dup(sock);
memcpy((void*)0x2000b000, "\x11\xaf\x7d\x99\x91\x3c\x87\x34\x85\x18\xc4\xd6\xf2\x30\x0a", 15);
*(uint16_t*)0x20002fec = (uint16_t)0x2;
*(uint16_t*)0x20002fee = (uint16_t)0x11ab;
*(uint32_t*)0x20002ff0 = (uint32_t)0x100007f;
sendto(sock_dup, (void *)0x2000b000ul, 0xful, 0x8800ul, (struct sockaddr *)0x20002fe4ul, 0x1cul);
memcpy((void*)0x2001504f, "\x7e\xb1\x52\x5b\x78\x85\x27\xe7\xcc\x3d\xf5\x18\x1b\xba\xda\x97\x6c\x18\x72\x0c\xd2\x0a\xa6\x77\xb7\x8b\xa2\xd2\x1d\xf0\x6b\xf6\x1a\x27\x6b\x98\x3e\x0b\x49\x8d\x54\x6e\x9e\xbb\x21\x4a\x72\x79\x1f\x82\xaf\x89\x2c\xf6\xd3\xc9\xd7\xed\x18\x29\x4d\x2e\x03\x15\xe2\x03\x14\xd0\xac\xa5\x81\x37\x73\x88\xa9\xf5\x08\xe5\xef\x5b\x56\xb7\x18\x8f\xe6\x19\xea\x91\x82\x23\xdd\x2c\x5c\xa5\xf0\xfc\xd8\xe2\x8b\x91\x48\x70\x24\xed\xae\xf9\x06\xac\xc4\x53\x01\xc3\xf5\xa3\x10\xef\xf1\xa6\x2b\xae\x72\xc7\x1a\x02\xee\x78\xcd\xd1\x7e\x8c\x9c\x1a\x36\xc7\xd4\x7c\x82\x64\xf7\x8b\x5a\xb0\x72\xa8\x87\x3c\xdc\xd0\xba\xfe\x70\x7d\x8c\x23\x78\xad\x7c\x31\x04\xec\xab\x1e\x4c\xee\xae\x84\xd8\x1a\x1d\x85\xa5\x57\xa8\x24\x53\x08\x1c\x4f\xda\x49\xe5\x3a\x99\x8c\x29\xa1\xed\x4b\x42\x7a\x15
\x48\x2a\x22\x3b\x81\xfe\x47\x74\xc1\x2f\x64\xcf\x10\xd4\x71\x72\x50\x71\xd7\xf6\xb0\xca\x41\x9a\x5e\x3e\xe4\x31\x19\xd1\x19\x46\x20\x66\x4c\x2f\xea\x76\x17\x2d\x94", 232);
*(uint16_t*)0x2001501c = (uint16_t)0xa;
*(uint16_t*)0x2001501e = (uint16_t)0x11ab;
*(uint32_t*)0x20015020 = (uint32_t)0xbdc;
*(uint32_t*)0x20015024 = (uint32_t)0x0;
*(uint32_t*)0x20015028 = (uint32_t)0x0;
*(uint32_t*)0x2001502c = (uint32_t)0x0;
*(uint32_t*)0x20015030 = (uint32_t)0x1000000;
*(uint32_t*)0x20015034 = (uint32_t)0x3;
sendto(sock_dup, (void *)0x2001504ful, 0xe8ul, 0x880ul, (struct sockaddr *)0x20015000ul, 0x1cul);
return 0;
}
Best Regards,
Baozeng Ding
^ permalink raw reply
* Re: [PATCH] ravb: fix software timestamping
From: Sergei Shtylyov @ 2016-03-27 12:50 UTC (permalink / raw)
To: Lino Sanfilippo; +Cc: netdev
In-Reply-To: <1459074122-6964-1-git-send-email-LinoSanfilippo@gmx.de>
Hello.
On 03/27/2016 01:22 PM, Lino Sanfilippo wrote:
> In ravb_start_xmit dont call skb_tx_timestamp only when hardware
> timestamping is requested: in the latter case software timestamps are
> suppressed and thus the call of skb_tx_timestamp does not have any effect.
>
> Instead call skb_tx_timestamp unconditionally in ravb_start_xmit, since
> the function checks itself if software timestamping is required or should
> be skipped due to hardware timestamping.
>
> Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* Darlehen Angebot
From: info @ 2016-03-27 12:44 UTC (permalink / raw)
To: Recipients
Sie benötigen ein Darlehen niedrige Rate? Altanlage gibt aus Darlehen in günstigen Preis gilt jetzt: legacyassetgrougp@hotmail.com
^ permalink raw reply
* Re: [PATCH v8 net-next] ravb: Add dma queue interrupt support
From: Sergei Shtylyov @ 2016-03-27 13:02 UTC (permalink / raw)
To: Yoshihiro Kaneko, netdev
Cc: David S. Miller, Simon Horman, Magnus Damm, linux-renesas-soc
In-Reply-To: <1458660120-23594-1-git-send-email-ykaneko0929@gmail.com>
Hello.
On 03/22/2016 06:22 PM, Yoshihiro Kaneko wrote:
> From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
>
> This patch supports the following interrupts.
>
> - One interrupt for multiple (timestamp, error, gPTP)
> - One interrupt for emac
> - Four interrupts for dma queue (best effort rx/tx, network control rx/tx)
>
> This patch improve efficiency of the interrupt handler by adding the
> interrupt handler corresponding to each interrupt source described
> above. Additionally, it reduces the number of times of the access to
> EthernetAVB IF.
> Also this patch prevent this driver depends on the whim of a boot loader.
>
> [ykaneko0929@gmail.com: define bit names of registers]
> [ykaneko0929@gmail.com: add comment for gen3 only registers]
> [ykaneko0929@gmail.com: fix coding style]
> [ykaneko0929@gmail.com: update changelog]
> [ykaneko0929@gmail.com: gen3: fix initialization of interrupts]
> [ykaneko0929@gmail.com: gen3: fix clearing interrupts]
> [ykaneko0929@gmail.com: gen3: add helper function for request_irq()]
> [ykaneko0929@gmail.com: gen3: remove IRQF_SHARED flag for request_irq()]
> [ykaneko0929@gmail.com: revert ravb_close() and ravb_ptp_stop()]
> [ykaneko0929@gmail.com: avoid calling free_irq() to non-hooked interrupts]
> [ykaneko0929@gmail.com: make NC/BE interrupt handler a function]
> [ykaneko0929@gmail.com: make timestamp interrupt handler a function]
> [ykaneko0929@gmail.com: timestamp interrupt is handled in multiple
> interrupt handler instead of dma queue interrupt handler]
> Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
[...]
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* [PATCH] Fix returned tc and hoplimit values for route with IPv6 encapsulation
From: Quentin Armitage @ 2016-03-27 16:06 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev
Cc: Quentin Armitage
For a route with IPv6 encapsulation, the traffic class and hop limit
values are interchanged when returned to userspace by the kernel.
For example, see below.
># ip route add 192.168.0.1 dev eth0.2 encap ip6 dst 0x50 tc 0x50 hoplimit 100 table 1000
># ip route show table 1000
192.168.0.1 encap ip6 id 0 src :: dst fe83::1 hoplimit 80 tc 100 dev eth0.2 scope link
Signed-off-by: Quentin Armitage <quentin@armitage.org.uk>
---
net/ipv4/ip_tunnel_core.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ip_tunnel_core.c b/net/ipv4/ip_tunnel_core.c
index 02dd990..6165f30 100644
--- a/net/ipv4/ip_tunnel_core.c
+++ b/net/ipv4/ip_tunnel_core.c
@@ -372,8 +372,8 @@ static int ip6_tun_fill_encap_info(struct sk_buff *skb,
if (nla_put_be64(skb, LWTUNNEL_IP6_ID, tun_info->key.tun_id) ||
nla_put_in6_addr(skb, LWTUNNEL_IP6_DST, &tun_info->key.u.ipv6.dst) ||
nla_put_in6_addr(skb, LWTUNNEL_IP6_SRC, &tun_info->key.u.ipv6.src) ||
- nla_put_u8(skb, LWTUNNEL_IP6_HOPLIMIT, tun_info->key.tos) ||
- nla_put_u8(skb, LWTUNNEL_IP6_TC, tun_info->key.ttl) ||
+ nla_put_u8(skb, LWTUNNEL_IP6_TC, tun_info->key.tos) ||
+ nla_put_u8(skb, LWTUNNEL_IP6_HOPLIMIT, tun_info->key.ttl) ||
nla_put_be16(skb, LWTUNNEL_IP6_FLAGS, tun_info->key.tun_flags))
return -ENOMEM;
--
1.7.7.6
^ permalink raw reply related
* Re: [PATCH 1/2 net-next v3.16]r8169: Disable set bit multicast enable per multicast address.
From: Corcodel Marian @ 2016-03-27 16:31 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Francois Romieu
In-Reply-To: <1459012726.6473.72.camel@edumazet-glaptop3.roam.corp.google.com>
On Sat, 26 Mar 2016 10:18:46 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Sat, 2016-03-26 at 12:57 +0200, Corcodel Marian wrote:
> > This patch correct set bit multicast enable only once per
> > set_rx_mode invocation.
> >
> > Signed-off-by: Corcodel Marian <asd@marian1000.go.ro>
> > ---
> > drivers/net/ethernet/realtek/r8169.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/realtek/r8169.c
> > b/drivers/net/ethernet/realtek/r8169.c index 7f6fb1f..f7b0dfb 100644
> > --- a/drivers/net/ethernet/realtek/r8169.c
> > +++ b/drivers/net/ethernet/realtek/r8169.c
> > @@ -4619,12 +4619,11 @@ static void rtl_set_rx_mode(struct
> > net_device *dev) } else {
> > struct netdev_hw_addr *ha;
> >
> > - rx_mode = AcceptBroadcast | AcceptMyPhys;
> > + rx_mode = AcceptBroadcast | AcceptMyPhys |
> > AcceptMulticast; mc_filter[1] = mc_filter[0] = 0;
> > netdev_for_each_mc_addr(ha, dev) {
> > int bit_nr = ether_crc(ETH_ALEN, ha->addr)
> > >> 26; mc_filter[bit_nr >> 5] |= 1 << (bit_nr & 31);
> > - rx_mode |= AcceptMulticast;
> > }
> > }
> >
>
> If the list is empty, why should we enable AcceptMulticast ?
>
>
>
I not experienced list empty, allways on my case exist bit_nr variable.
^ permalink raw reply
* Re: [PATCH iproute2 v1 1/1] lib/utils: fix get_addr() and get_prefix() error messages
From: Stephen Hemminger @ 2016-03-27 17:35 UTC (permalink / raw)
To: Varlese, Marco
Cc: netdev@vger.kernel.org, davem@davemloft.net, Jiri Pirko,
John Fastabend, jhs@mojatatu.com, Szczerbik, PrzemyslawX
In-Reply-To: <C4896FB061E7DE4AAC93031BDCA044B11A2146FF@IRSMSX108.ger.corp.intel.com>
On Tue, 22 Mar 2016 13:02:02 +0000
"Varlese, Marco" <marco.varlese@intel.com> wrote:
> An attempt to add invalid address to interface would print "???" string
> instead of the address family name.
>
> For example:
> $ ip address add 256.10.166.1/24 dev ens8
> Error: ??? prefix is expected rather than "256.10.166.1/24".
>
> $ ip neighbor add proxy 2001:db8::g dev ens8
> Error: ??? address is expected rather than "2001:db8::g".
>
> With this patch the output will look like:
> $ ip address add 256.10.166.1/24 dev ens8
> Error: inet prefix is expected rather than "256.10.166.1/24".
>
> $ ip neighbor add proxy 2001:db8::g dev ens8
> Error: inet6 address is expected rather than "2001:db8::g".
>
> Signed-off-by: Przemyslaw Szczerbik <przemyslawx.szczerbik@intel.com>
> Signed-off-by: Marco Varlese <marco.varlese@intel.com>
> ---
> lib/utils.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/utils.c b/lib/utils.c
> index fa35f4d..4820de1 100644
> --- a/lib/utils.c
> +++ b/lib/utils.c
> @@ -567,7 +567,7 @@ int get_addr(inet_prefix *dst, const char *arg, int family)
> {
> if (get_addr_1(dst, arg, family)) {
> fprintf(stderr, "Error: %s address is expected rather than \"%s\".\n",
> - family_name(family) ,arg);
> + family_name(dst->family), arg);
> exit(1);
> }
> return 0;
> @@ -581,7 +581,7 @@ int get_prefix(inet_prefix *dst, char *arg, int family)
> }
> if (get_prefix_1(dst, arg, family)) {
> fprintf(stderr, "Error: %s prefix is expected rather than \"%s\".\n",
> - family_name(family) ,arg);
> + family_name(dst->family), arg);
> exit(1);
> }
> return 0;
Your patch was corrupted by your email client?
$ patch -p1 <~/Downloads/iproute2-v1-1-1-lib-utils-fix-get_addr-and-get_prefix-error-messages.patch
patching file lib/utils.c
patch: **** malformed patch at line 6: {
^ permalink raw reply
* Re: [iproute PATCH 0/7] Refactor some internal library functions
From: Stephen Hemminger @ 2016-03-27 17:38 UTC (permalink / raw)
To: Phil Sutter; +Cc: netdev
In-Reply-To: <1458671719-14361-1-git-send-email-phil@nwl.cc>
On Tue, 22 Mar 2016 19:35:12 +0100
Phil Sutter <phil@nwl.cc> wrote:
> The following series is a result of reviewing color output support and
> some formatting helpers usually used with struct rtattr fields.
>
> Phil Sutter (7):
> color: introduce color helpers and COLOR_CLEAR
> ipaddress: colorize peer, broadcast and anycast addresses as well
> make format_host non-reentrant by default
> utils: make rt_addr_n2a() non-reentrant by default
> lib/utils: introduce format_host_rta()
> lib/utils: introduce rt_addr_n2a_rta()
> lib/ll_addr: improve ll_addr_n2a() a bit
>
> bridge/fdb.c | 4 +--
> include/color.h | 5 ++-
> include/utils.h | 10 ++++--
> ip/ip6tunnel.c | 4 +--
> ip/ipaddress.c | 87 ++++++++++++++++++---------------------------------
> ip/ipaddrlabel.c | 7 ++---
> ip/iplink_bond.c | 7 +----
> ip/iplink_geneve.c | 5 ++-
> ip/iplink_vxlan.c | 13 ++++----
> ip/ipmaddr.c | 6 +---
> ip/ipmroute.c | 11 ++-----
> ip/ipneigh.c | 6 +---
> ip/ipprefix.c | 17 ++--------
> ip/iproute.c | 68 ++++++++++++----------------------------
> ip/iproute_lwtunnel.c | 29 ++++-------------
> ip/iprule.c | 39 +++++++----------------
> ip/iptoken.c | 11 ++-----
> ip/iptunnel.c | 8 ++---
> ip/ipxfrm.c | 29 ++++-------------
> ip/link_gre.c | 5 ++-
> ip/link_gre6.c | 5 ++-
> ip/link_ip6tnl.c | 11 ++-----
> ip/link_iptnl.c | 7 ++---
> ip/link_vti.c | 5 ++-
> ip/link_vti6.c | 5 ++-
> ip/tcp_metrics.c | 6 ++--
> ip/xfrm_monitor.c | 16 ++--------
> lib/color.c | 30 +++++++++++++++++-
> lib/ll_addr.c | 15 ++-------
> lib/utils.c | 20 ++++++++++--
> misc/ss.c | 4 +--
> tc/f_flower.c | 11 ++-----
> tc/m_nat.c | 4 +--
> 33 files changed, 187 insertions(+), 323 deletions(-)
>
Applied thanks
^ permalink raw reply
* Re: [iproute PATCH v3] Use ARRAY_SIZE macro everywhere
From: Stephen Hemminger @ 2016-03-27 17:42 UTC (permalink / raw)
To: Phil Sutter; +Cc: netdev
In-Reply-To: <1458661973-31210-1-git-send-email-phil@nwl.cc>
On Tue, 22 Mar 2016 16:52:53 +0100
Phil Sutter <phil@nwl.cc> wrote:
> This patch was generated by the following semantic patch (a trimmed down
> version of what is shipped with Linux sources):
>
> @@
> type T;
> T[] E;
> @@
> (
> - (sizeof(E)/sizeof(*E))
> + ARRAY_SIZE(E)
> |
> - (sizeof(E)/sizeof(E[...]))
> + ARRAY_SIZE(E)
> |
> - (sizeof(E)/sizeof(T))
> + ARRAY_SIZE(E)
> )
>
> The only manual adjustment was to include utils.h in misc/nstat.c to make
> the macro known there.
>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
> ---
> Changes since v1:
> - Rebased onto current master to avoid merge conflicts.
>
> Changes since v2:
> - Patch recreated from scratch.
> ---
> bridge/link.c | 2 +-
> misc/nstat.c | 2 +-
> misc/ss.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
You need to test build after coccinelle!
nstat.c: In function ‘useless_number’:
nstat.c:98:2: warning: implicit declaration of function ‘ARRAY_SIZE’ [-Wimplicit-function-declaration]
for (i = 0; i < ARRAY_SIZE(useless_numbers); i++)
^
gcc -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wold-style-definition -Wformat=2 -O2 -I../include -DRESOLVE_HOSTNAMES -DLIBDIR=\"/usr/lib\" -DCONFDIR=\"/etc/iproute2\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DHAVE_SELINUX -DHAVE_SETNS -c -o ssfilter.o ssfilter.c
gcc lnstat.o lnstat_util.o ../lib/libnetlink.a ../lib/libutil.a -lselinux -o lnstat
/tmp/ccoYmLJI.o: In function `useless_number':
nstat.c:(.text+0x40): undefined reference to `ARRAY_SIZE'
Please fix and resubmit
^ permalink raw reply
* Re: [PATCH iproute2 master 0/2] setting flow label support
From: Stephen Hemminger @ 2016-03-27 18:00 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev
In-Reply-To: <cover.1458833866.git.daniel@iogearbox.net>
On Thu, 24 Mar 2016 16:49:54 +0100
Daniel Borkmann <daniel@iogearbox.net> wrote:
> On top of Jesse's csum patches for vxlan, geneve:
>
> - http://patchwork.ozlabs.org/patch/599746/
> - http://patchwork.ozlabs.org/patch/599747/
>
> Thanks!
>
> Daniel Borkmann (2):
> vxlan: add support to set flow label
> geneve: add support to set flow label
>
> ip/ip_common.h | 4 ++++
> ip/iplink_geneve.c | 29 ++++++++++++++++++++++++-----
> ip/iplink_vxlan.c | 29 ++++++++++++++++++++++++-----
> man/man8/ip-link.8.in | 12 ++++++++++++
> 4 files changed, 64 insertions(+), 10 deletions(-)
>
Applied thanks
^ permalink raw reply
* Re: [patch iproute2 v2 1/2] include: add linked list implementation from kernel
From: Stephen Hemminger @ 2016-03-27 18:00 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, idosch, eladr, yotamg, ogerlitz, yishaih, dledford,
sean.hefty, hal.rosenstock, eugenia, roopa, nikolay, hadarh, jhs,
john.fastabend, jeffrey.t.kirsher, brouer, ivecera, rami.rosen,
hannes, gospo
In-Reply-To: <1458637341-3434-1-git-send-email-jiri@resnulli.us>
On Tue, 22 Mar 2016 10:02:20 +0100
Jiri Pirko <jiri@resnulli.us> wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> Rename hlist.h to list.h while adding it to be aligned with kernel
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> ---
> v1->v2:
> - fix some checkpatch issues
Applied, I did cleanup extra blank line on devlink.c
There are still some whitespace issues in list.h which I ignored.
^ permalink raw reply
* Re: [PATCH iproute2 1/2] vxlan: Follow kernel defaults for outer UDP checksum.
From: Stephen Hemminger @ 2016-03-27 18:01 UTC (permalink / raw)
To: Jesse Gross; +Cc: netdev
In-Reply-To: <1458348669-48437-1-git-send-email-jesse@kernel.org>
On Fri, 18 Mar 2016 17:51:08 -0700
Jesse Gross <jesse@kernel.org> wrote:
> On recent kernels, UDP checksum computation has become more efficient and
> the default behavior was changed, however, the ip command overrides this
> by always specifying a particular behavior.
>
> If the user does not specify that UDP checksums should either be computed
> or not then we don't need to send an explicit netlink message - the kernel
> can just use its default behavior.
>
> Signed-off-by: Jesse Gross <jesse@kernel.org>
> ---
Applied both, thanks
^ permalink raw reply
* Re: [PATCH iproute2 v1 1/1] lib/utils: fix get_addr() and get_prefix() error messages
From: Stephen Hemminger @ 2016-03-27 18:02 UTC (permalink / raw)
To: Varlese, Marco
Cc: netdev@vger.kernel.org, davem@davemloft.net, Jiri Pirko,
John Fastabend, jhs@mojatatu.com, Szczerbik, PrzemyslawX
In-Reply-To: <C4896FB061E7DE4AAC93031BDCA044B11A2146FF@IRSMSX108.ger.corp.intel.com>
On Tue, 22 Mar 2016 13:02:02 +0000
"Varlese, Marco" <marco.varlese@intel.com> wrote:
> An attempt to add invalid address to interface would print "???" string
> instead of the address family name.
>
> For example:
> $ ip address add 256.10.166.1/24 dev ens8
> Error: ??? prefix is expected rather than "256.10.166.1/24".
>
> $ ip neighbor add proxy 2001:db8::g dev ens8
> Error: ??? address is expected rather than "2001:db8::g".
>
> With this patch the output will look like:
> $ ip address add 256.10.166.1/24 dev ens8
> Error: inet prefix is expected rather than "256.10.166.1/24".
>
> $ ip neighbor add proxy 2001:db8::g dev ens8
> Error: inet6 address is expected rather than "2001:db8::g".
>
> Signed-off-by: Przemyslaw Szczerbik <przemyslawx.szczerbik@intel.com>
> Signed-off-by: Marco Varlese <marco.varlese@intel.com>
Since this was so trivial, I did change manually since patch was corrupted.
^ permalink raw reply
* Re: [PATCH] net: sxgbe: fix error paths in sxgbe_platform_probe()
From: Rasmus Villemoes @ 2016-03-27 21:40 UTC (permalink / raw)
To: Francois Romieu; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <20160327082254.GA10620@electric-eye.fr.zoreil.com>
On Sun, Mar 27 2016, Francois Romieu <romieu@fr.zoreil.com> wrote:
> Rasmus Villemoes <linux@rasmusvillemoes.dk> :
>> We need to use post-decrement to ensure that irq_dispose_mapping is
>> also called on priv->rxq[0]->irq_no; moreover, if one of the above for
>> loops failed already at i==0 (so we reach one of these labels with
>> that value of i), we'll enter an essentially infinite loop of
>> out-of-bounds accesses.
>>
>> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
>
> (ok, i is signed)
>
> Reviewed-by: Francois Romieu <romieu@fr.zoreil.com>
>
Thanks for reviewing, but just FTR I want to point out that it doesn't
matter whether i is signed or not in
while (i--)
However, when i is signed, there's another slightly less popular variant
which is equivalent:
while (--i >= 0)
(a precondition for their equivalence is that i has a non-negative value
before reaching the while statement).
Neither are equivalent to the almost-always broken
while (--i)
Rasmus
^ permalink raw reply
* Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet
From: Jozsef Kadlecsik @ 2016-03-27 22:11 UTC (permalink / raw)
To: Baozeng Ding; +Cc: pablo, kaber, davem, netfilter-devel, netdev
In-Reply-To: <56F7D3AD.10003@gmail.com>
On Sun, 27 Mar 2016, Baozeng Ding wrote:
> The following program triggers stack-out-of-bounds in tcp_packet. The
> kernel version is 4.5 (on Mar 16 commit
> 09fd671ccb2475436bd5f597f751ca4a7d177aea).
> Uncovered with syzkaller. Thanks.
>
> ==================================================================
> BUG: KASAN: stack-out-of-bounds in tcp_packet+0x4b77/0x51c0 at addr
> ffff8800a45df3c8
> Read of size 1 by task 0327/11132
> page:ffffea00029177c0 count:0 mapcount:0 mapping: (null) index:0x0
> flags: 0x1fffc0000000000()
> page dumped because: kasan: bad access detected
> CPU: 1 PID: 11132 Comm: 0327 Tainted: G B 4.5.0+ #12
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
> 0000000000000001 ffff8800a45df148 ffffffff82945051 ffff8800a45df1d8
> ffff8800a45df3c8 0000000000000027 0000000000000001 ffff8800a45df1c8
> ffffffff81709f88 ffff8800b4f7e3d0 0000000000000028 0000000000000286
> Call Trace:
> [< inline >] __dump_stack /kernel/lib/dump_stack.c:15
> [<ffffffff82945051>] dump_stack+0xb3/0x112 /kernel/lib/dump_stack.c:51
> [< inline >] print_address_description /kernel/mm/kasan/report.c:150
> [<ffffffff81709f88>] kasan_report_error+0x4f8/0x530
> /kernel/mm/kasan/report.c:236
> [<ffffffff84c54b8d>] ? skb_copy_bits+0x49d/0x6d0
> /kernel/net/core/skbuff.c:1675
> [< inline >] ? spin_lock_bh /kernel/include/linux/spinlock.h:307
> [<ffffffff84e0e9b9>] ? tcp_packet+0x1c9/0x51c0
> /kernel/net/netfilter/nf_conntrack_proto_tcp.c:833
> [< inline >] kasan_report /kernel/mm/kasan/report.c:259
> [<ffffffff81709ffe>] __asan_report_load1_noabort+0x3e/0x40
> /kernel/mm/kasan/report.c:277
> [< inline >] ? tcp_sack
> /kernel/net/netfilter/nf_conntrack_proto_tcp.c:473
> [< inline >] ? tcp_in_window
> /kernel/net/netfilter/nf_conntrack_proto_tcp.c:527
> [<ffffffff84e13367>] ? tcp_packet+0x4b77/0x51c0
> /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1036
> [< inline >] tcp_sack
> /kernel/net/netfilter/nf_conntrack_proto_tcp.c:473
> [< inline >] tcp_in_window
> /kernel/net/netfilter/nf_conntrack_proto_tcp.c:527
> [<ffffffff84e13367>] tcp_packet+0x4b77/0x51c0
> /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1036
> [<ffffffff817094b8>] ? memset+0x28/0x30 /kernel/mm/kasan/kasan.c:302
> [<ffffffff84e0dd74>] ? tcp_new+0x1a4/0xc20
> /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1122
> [< inline >] ? build_report /kernel/include/net/netlink.h:499
> [<ffffffff8518c4d6>] ? xfrm_send_report+0x426/0x450
> /kernel/net/xfrm/xfrm_user.c:3039
> [<ffffffff84e0e7f0>] ? tcp_new+0xc20/0xc20
> /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1169
> [<ffffffff84dfb03a>] ? init_conntrack+0xca/0x9e0
> /kernel/net/netfilter/nf_conntrack_core.c:972
> [<ffffffff84dfaf70>] ? nf_conntrack_alloc+0x40/0x40
> /kernel/net/netfilter/nf_conntrack_core.c:903
> [<ffffffff84e0cdf0>] ? tcp_init_net+0x6e0/0x6e0
> /kernel/include/net/netfilter/nf_conntrack_l4proto.h:137
> [<ffffffff85121732>] ? ipv4_get_l4proto+0x262/0x390
> /kernel/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c:89
> [<ffffffff84df372f>] ? nf_ct_get_tuple+0xaf/0x190
> /kernel/net/netfilter/nf_conntrack_core.c:197
> [<ffffffff84dfc23e>] nf_conntrack_in+0x8ee/0x1170
> /kernel/net/netfilter/nf_conntrack_core.c:1177
> [<ffffffff84dfb950>] ? init_conntrack+0x9e0/0x9e0
> /kernel/net/netfilter/nf_conntrack_core.c:287
> [<ffffffff8512ab06>] ? ipt_do_table+0xa16/0x1260
> /kernel/net/ipv4/netfilter/ip_tables.c:423
> [<ffffffff81405ced>] ? trace_hardirqs_on+0xd/0x10
> /kernel/kernel/locking/lockdep.c:2635
> [<ffffffff81311fcb>] ? __local_bh_enable_ip+0x6b/0xc0
> /kernel/kernel/softirq.c:175
> [<ffffffff8512a0f0>] ? check_entry.isra.4+0x190/0x190
> /kernel/net/ipv6/netfilter/ip6_tables.c:594
> [<ffffffff84f9d4e0>] ? ip_reply_glue_bits+0xc0/0xc0
> /kernel/net/ipv4/ip_output.c:1530
> [<ffffffff851219ae>] ipv4_conntrack_local+0x14e/0x1a0
> /kernel/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c:161
> [<ffffffff85131b3d>] ? iptable_raw_hook+0x9d/0x1e0
> /kernel/net/ipv4/netfilter/iptable_raw.c:32
> [<ffffffff84de5b7d>] nf_iterate+0x15d/0x230 /kernel/net/netfilter/core.c:274
> [<ffffffff84de5c50>] ? nf_iterate+0x230/0x230 /kernel/net/netfilter/core.c:268
> [<ffffffff84de5dfd>] nf_hook_slow+0x1ad/0x310 /kernel/net/netfilter/core.c:306
> [<ffffffff84de5c50>] ? nf_iterate+0x230/0x230 /kernel/net/netfilter/core.c:268
> [<ffffffff84de5c50>] ? nf_iterate+0x230/0x230 /kernel/net/netfilter/core.c:268
> [<ffffffff82979274>] ? prandom_u32+0x24/0x30 /kernel/lib/random32.c:83
> [<ffffffff84f747ff>] ? ip_idents_reserve+0x9f/0xf0
> /kernel/net/ipv4/route.c:484
> [< inline >] nf_hook_thresh /kernel/include/linux/netfilter.h:187
> [< inline >] nf_hook /kernel/include/linux/netfilter.h:197
> [<ffffffff84fa4f53>] __ip_local_out+0x263/0x3c0
> /kernel/net/ipv4/ip_output.c:104
> [<ffffffff84fa4cf0>] ? ip_finish_output+0xd00/0xd00
> /kernel/include/net/ip.h:322
> [<ffffffff84fa0230>] ? __ip_flush_pending_frames.isra.45+0x2e0/0x2e0
> /kernel/net/ipv4/ip_output.c:1337
> [<ffffffff84faa336>] ? __ip_make_skb+0xfe6/0x1610
> /kernel/net/ipv4/ip_output.c:1436
> [<ffffffff84fa50dd>] ip_local_out+0x2d/0x1c0 /kernel/net/ipv4/ip_output.c:113
> [<ffffffff84faa99c>] ip_send_skb+0x3c/0xc0 /kernel/net/ipv4/ip_output.c:1443
> [<ffffffff84faaa84>] ip_push_pending_frames+0x64/0x80
> /kernel/net/ipv4/ip_output.c:1463
> [< inline >] rcu_read_unlock /kernel/include/linux/rcupdate.h:922
> [<ffffffff8504e10b>] raw_sendmsg+0x17bb/0x25c0
> /kernel/net/ieee802154/socket.c:53
> [<ffffffff8504c950>] ? dst_output+0x190/0x190 /kernel/include/net/dst.h:492
> [< inline >] ? trace_mm_page_alloc
> /kernel/include/trace/events/kmem.h:217
> [<ffffffff81621609>] ? __alloc_pages_nodemask+0x559/0x16b0
> /kernel/mm/page_alloc.c:3368
> [<ffffffff81406260>] ? debug_check_no_locks_freed+0x290/0x290
> /kernel/kernel/locking/lockdep.c:4104
> [<ffffffff814c0e30>] ? is_module_text_address+0x10/0x20
> /kernel/kernel/module.c:4057
> [<ffffffff81360533>] ? __kernel_text_address+0x73/0xa0
> /kernel/kernel/extable.c:103
> [<ffffffff81406260>] ? debug_check_no_locks_freed+0x290/0x290
> /kernel/kernel/locking/lockdep.c:4104
> [<ffffffff81406260>] ? debug_check_no_locks_freed+0x290/0x290
> /kernel/kernel/locking/lockdep.c:4104
> [<ffffffff81405ced>] ? trace_hardirqs_on+0xd/0x10
> /kernel/kernel/locking/lockdep.c:2635
> [<ffffffff81406260>] ? debug_check_no_locks_freed+0x290/0x290
> /kernel/kernel/locking/lockdep.c:4104
> [< inline >] ? sock_rps_record_flow /kernel/include/net/sock.h:874
> [<ffffffff85089113>] ? inet_sendmsg+0x73/0x4c0 /kernel/net/ipv4/af_inet.c:729
> [< inline >] ? rcu_read_unlock /kernel/include/linux/rcupdate.h:922
> [< inline >] ? sock_rps_record_flow_hash
> /kernel/include/net/sock.h:867
> [< inline >] ? sock_rps_record_flow /kernel/include/net/sock.h:874
> [<ffffffff8508929a>] ? inet_sendmsg+0x1fa/0x4c0 /kernel/net/ipv4/af_inet.c:729
> [<ffffffff85089395>] inet_sendmsg+0x2f5/0x4c0 /kernel/net/ipv4/af_inet.c:736
> [< inline >] ? sock_rps_record_flow /kernel/include/net/sock.h:874
> [<ffffffff85089113>] ? inet_sendmsg+0x73/0x4c0 /kernel/net/ipv4/af_inet.c:729
> [<ffffffff850890a0>] ? inet_recvmsg+0x4a0/0x4a0
> /kernel/include/linux/compiler.h:222
> [< inline >] sock_sendmsg_nosec /kernel/net/socket.c:611
> [<ffffffff84c3434a>] sock_sendmsg+0xca/0x110 /kernel/net/socket.c:621
> [<ffffffff84c35448>] SYSC_sendto+0x208/0x350 /kernel/net/socket.c:1651
> [<ffffffff84c35240>] ? SYSC_connect+0x2e0/0x2e0 /kernel/net/socket.c:1543
> [<ffffffff81698650>] ? __pmd_alloc+0x350/0x350 /kernel/mm/memory.c:3928
> [<ffffffff81230b3b>] ? __do_page_fault+0x2ab/0x8e0
> /kernel/arch/x86/mm/fault.c:1184
> [<ffffffff81230c30>] ? __do_page_fault+0x3a0/0x8e0
> /kernel/arch/x86/mm/fault.c:1271
> [<ffffffff813fb5da>] ? up_read+0x1a/0x40 /kernel/kernel/locking/rwsem.c:79
> [<ffffffff81230a29>] ? __do_page_fault+0x199/0x8e0
> /kernel/arch/x86/mm/fault.c:1187
> [<ffffffff84c379b0>] SyS_sendto+0x40/0x50 /kernel/net/socket.c:1619
> [<ffffffff85dab940>] entry_SYSCALL_64_fastpath+0x23/0xc1
> /kernel/arch/x86/entry/entry_64.S:207
> Memory state around the buggy address:
> ffff8800a45df280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff8800a45df300: f1 f1 f1 f1 00 00 04 f4 f2 f2 f2 f2 00 00 04 f4
> > ffff8800a45df380: f2 f2 f2 f2 00 00 00 00 00 f4 f4 f4 f3 f3 f3 f3
> ^
> ffff8800a45df400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff8800a45df480: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 01 f4 f4 f4
> ==================================================================
>
> #include <unistd.h>
> #include <sys/syscall.h>
> #include <string.h>
> #include <stdint.h>
> #include <pthread.h>
> #include <sys/socket.h>
> #include <sys/mman.h>
> #include <netinet/in.h>
> int main()
> {
> mmap((void *)0x20000000ul, 0x19000ul, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0);
> int sock = socket(AF_INET, SOCK_RAW, IPPROTO_TCP);
> int sock_dup = dup(sock);
> memcpy((void*)0x2000b000,
> "\x11\xaf\x7d\x99\x91\x3c\x87\x34\x85\x18\xc4\xd6\xf2\x30\x0a", 15);
> *(uint16_t*)0x20002fec = (uint16_t)0x2;
> *(uint16_t*)0x20002fee = (uint16_t)0x11ab;
> *(uint32_t*)0x20002ff0 = (uint32_t)0x100007f;
> sendto(sock_dup, (void *)0x2000b000ul, 0xful, 0x8800ul, (struct
> sockaddr *)0x20002fe4ul, 0x1cul);
> memcpy((void*)0x2001504f,
> "\x7e\xb1\x52\x5b\x78\x85\x27\xe7\xcc\x3d\xf5\x18\x1b\xba\xda\x97\x6c\x18\x72\x0c\xd2\x0a\xa6\x77\xb7\x8b\xa2\xd2\x1d\xf0\x6b\xf6\x1a\x27\x6b\x98\x3e\x0b\x49\x8d\x54\x6e\x9e\xbb\x21\x4a\x72\x79\x1f\x82\xaf\x89\x2c\xf6\xd3\xc9\xd7\xed\x18\x29\x4d\x2e\x03\x15\xe2\x03\x14\xd0\xac\xa5\x81\x37\x73\x88\xa9\xf5\x08\xe5\xef\x5b\x56\xb7\x18\x8f\xe6\x19\xea\x91\x82\x23\xdd\x2c\x5c\xa5\xf0\xfc\xd8\xe2\x8b\x91\x48\x70\x24\xed\xae\xf9\x06\xac\xc4\x53\x01\xc3\xf5\xa3\x10\xef\xf1\xa6\x2b\xae\x72\xc7\x1a\x02\xee\x78\xcd\xd1\x7e\x8c\x9c\x1a\x36\xc7\xd4\x7c\x82\x64\xf7\x8b\x5a\xb0\x72\xa8\x87\x3c\xdc\xd0\xba\xfe\x70\x7d\x8c\x23\x78\xad\x7c\x31\x04\xec\xab\x1e\x4c\xee\xae\x84\xd8\x1a\x1d\x85\xa5\x57\xa8\x24\x53\x08\x1c\x4f\xda\x49\xe5\x3a\x99\x8c\x29\xa1\xed\x4b\x42\x7a\x15\x48\x2a\x22\x3b\x81\xfe\x47\x74\
xc1\x2f\x64\xcf\x10\xd4\x71\x72\x50\x71\xd7\xf6\xb0\xca\x41\x9a\x5e\x3e\xe4\x31\x19\xd1\x19\x46\x20\x66\x4c\x2f\xea\x76\x17\x2d\x94",
> 232);
> *(uint16_t*)0x2001501c = (uint16_t)0xa;
> *(uint16_t*)0x2001501e = (uint16_t)0x11ab;
> *(uint32_t*)0x20015020 = (uint32_t)0xbdc;
> *(uint32_t*)0x20015024 = (uint32_t)0x0;
> *(uint32_t*)0x20015028 = (uint32_t)0x0;
> *(uint32_t*)0x2001502c = (uint32_t)0x0;
> *(uint32_t*)0x20015030 = (uint32_t)0x1000000;
> *(uint32_t*)0x20015034 = (uint32_t)0x3;
> sendto(sock_dup, (void *)0x2001504ful, 0xe8ul, 0x880ul, (struct
> sockaddr *)0x20015000ul, 0x1cul);
> return 0;
> }
Please verify that the patch below fixes the issue:
diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
index 278f3b9..7cc1d9c 100644
--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
@@ -410,6 +410,8 @@ static void tcp_options(const struct sk_buff *skb,
length--;
continue;
default:
+ if (length < 2)
+ return;
opsize=*ptr++;
if (opsize < 2) /* "silly options" */
return;
@@ -470,6 +472,8 @@ static void tcp_sack(const struct sk_buff *skb, unsigned int dataoff,
length--;
continue;
default:
+ if (length < 2)
+ return;
opsize = *ptr++;
if (opsize < 2) /* "silly options" */
return;
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply related
* Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet
From: Jozsef Kadlecsik @ 2016-03-27 22:25 UTC (permalink / raw)
To: Baozeng Ding
Cc: Pablo Neira Ayuso, Patrick McHardy, David Miller, netfilter-devel,
netdev
In-Reply-To: <alpine.DEB.2.10.1603280010120.19633@blackhole.kfki.hu>
On Mon, 28 Mar 2016, Jozsef Kadlecsik wrote:
> On Sun, 27 Mar 2016, Baozeng Ding wrote:
>
> > The following program triggers stack-out-of-bounds in tcp_packet. The
> > kernel version is 4.5 (on Mar 16 commit
> > 09fd671ccb2475436bd5f597f751ca4a7d177aea).
> > Uncovered with syzkaller. Thanks.
> >
> > ==================================================================
> > BUG: KASAN: stack-out-of-bounds in tcp_packet+0x4b77/0x51c0 at addr
> > ffff8800a45df3c8
> > Read of size 1 by task 0327/11132
> > page:ffffea00029177c0 count:0 mapcount:0 mapping: (null) index:0x0
> > flags: 0x1fffc0000000000()
> > page dumped because: kasan: bad access detected
> > CPU: 1 PID: 11132 Comm: 0327 Tainted: G B 4.5.0+ #12
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> > rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
> > 0000000000000001 ffff8800a45df148 ffffffff82945051 ffff8800a45df1d8
> > ffff8800a45df3c8 0000000000000027 0000000000000001 ffff8800a45df1c8
> > ffffffff81709f88 ffff8800b4f7e3d0 0000000000000028 0000000000000286
> > Call Trace:
> > [< inline >] __dump_stack /kernel/lib/dump_stack.c:15
> > [<ffffffff82945051>] dump_stack+0xb3/0x112 /kernel/lib/dump_stack.c:51
> > [< inline >] print_address_description /kernel/mm/kasan/report.c:150
> > [<ffffffff81709f88>] kasan_report_error+0x4f8/0x530
> > /kernel/mm/kasan/report.c:236
> > [<ffffffff84c54b8d>] ? skb_copy_bits+0x49d/0x6d0
> > /kernel/net/core/skbuff.c:1675
> > [< inline >] ? spin_lock_bh /kernel/include/linux/spinlock.h:307
> > [<ffffffff84e0e9b9>] ? tcp_packet+0x1c9/0x51c0
> > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:833
> > [< inline >] kasan_report /kernel/mm/kasan/report.c:259
> > [<ffffffff81709ffe>] __asan_report_load1_noabort+0x3e/0x40
> > /kernel/mm/kasan/report.c:277
> > [< inline >] ? tcp_sack
> > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:473
> > [< inline >] ? tcp_in_window
> > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:527
> > [<ffffffff84e13367>] ? tcp_packet+0x4b77/0x51c0
> > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1036
> > [< inline >] tcp_sack
> > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:473
> > [< inline >] tcp_in_window
> > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:527
> > [<ffffffff84e13367>] tcp_packet+0x4b77/0x51c0
> > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1036
> > [<ffffffff817094b8>] ? memset+0x28/0x30 /kernel/mm/kasan/kasan.c:302
> > [<ffffffff84e0dd74>] ? tcp_new+0x1a4/0xc20
> > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1122
> > [< inline >] ? build_report /kernel/include/net/netlink.h:499
> > [<ffffffff8518c4d6>] ? xfrm_send_report+0x426/0x450
> > /kernel/net/xfrm/xfrm_user.c:3039
> > [<ffffffff84e0e7f0>] ? tcp_new+0xc20/0xc20
> > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1169
> > [<ffffffff84dfb03a>] ? init_conntrack+0xca/0x9e0
> > /kernel/net/netfilter/nf_conntrack_core.c:972
> > [<ffffffff84dfaf70>] ? nf_conntrack_alloc+0x40/0x40
> > /kernel/net/netfilter/nf_conntrack_core.c:903
> > [<ffffffff84e0cdf0>] ? tcp_init_net+0x6e0/0x6e0
> > /kernel/include/net/netfilter/nf_conntrack_l4proto.h:137
> > [<ffffffff85121732>] ? ipv4_get_l4proto+0x262/0x390
> > /kernel/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c:89
> > [<ffffffff84df372f>] ? nf_ct_get_tuple+0xaf/0x190
> > /kernel/net/netfilter/nf_conntrack_core.c:197
> > [<ffffffff84dfc23e>] nf_conntrack_in+0x8ee/0x1170
> > /kernel/net/netfilter/nf_conntrack_core.c:1177
> > [<ffffffff84dfb950>] ? init_conntrack+0x9e0/0x9e0
> > /kernel/net/netfilter/nf_conntrack_core.c:287
> > [<ffffffff8512ab06>] ? ipt_do_table+0xa16/0x1260
> > /kernel/net/ipv4/netfilter/ip_tables.c:423
> > [<ffffffff81405ced>] ? trace_hardirqs_on+0xd/0x10
> > /kernel/kernel/locking/lockdep.c:2635
> > [<ffffffff81311fcb>] ? __local_bh_enable_ip+0x6b/0xc0
> > /kernel/kernel/softirq.c:175
> > [<ffffffff8512a0f0>] ? check_entry.isra.4+0x190/0x190
> > /kernel/net/ipv6/netfilter/ip6_tables.c:594
> > [<ffffffff84f9d4e0>] ? ip_reply_glue_bits+0xc0/0xc0
> > /kernel/net/ipv4/ip_output.c:1530
> > [<ffffffff851219ae>] ipv4_conntrack_local+0x14e/0x1a0
> > /kernel/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c:161
> > [<ffffffff85131b3d>] ? iptable_raw_hook+0x9d/0x1e0
> > /kernel/net/ipv4/netfilter/iptable_raw.c:32
> > [<ffffffff84de5b7d>] nf_iterate+0x15d/0x230 /kernel/net/netfilter/core.c:274
> > [<ffffffff84de5c50>] ? nf_iterate+0x230/0x230 /kernel/net/netfilter/core.c:268
> > [<ffffffff84de5dfd>] nf_hook_slow+0x1ad/0x310 /kernel/net/netfilter/core.c:306
> > [<ffffffff84de5c50>] ? nf_iterate+0x230/0x230 /kernel/net/netfilter/core.c:268
> > [<ffffffff84de5c50>] ? nf_iterate+0x230/0x230 /kernel/net/netfilter/core.c:268
> > [<ffffffff82979274>] ? prandom_u32+0x24/0x30 /kernel/lib/random32.c:83
> > [<ffffffff84f747ff>] ? ip_idents_reserve+0x9f/0xf0
> > /kernel/net/ipv4/route.c:484
> > [< inline >] nf_hook_thresh /kernel/include/linux/netfilter.h:187
> > [< inline >] nf_hook /kernel/include/linux/netfilter.h:197
> > [<ffffffff84fa4f53>] __ip_local_out+0x263/0x3c0
> > /kernel/net/ipv4/ip_output.c:104
> > [<ffffffff84fa4cf0>] ? ip_finish_output+0xd00/0xd00
> > /kernel/include/net/ip.h:322
> > [<ffffffff84fa0230>] ? __ip_flush_pending_frames.isra.45+0x2e0/0x2e0
> > /kernel/net/ipv4/ip_output.c:1337
> > [<ffffffff84faa336>] ? __ip_make_skb+0xfe6/0x1610
> > /kernel/net/ipv4/ip_output.c:1436
> > [<ffffffff84fa50dd>] ip_local_out+0x2d/0x1c0 /kernel/net/ipv4/ip_output.c:113
> > [<ffffffff84faa99c>] ip_send_skb+0x3c/0xc0 /kernel/net/ipv4/ip_output.c:1443
> > [<ffffffff84faaa84>] ip_push_pending_frames+0x64/0x80
> > /kernel/net/ipv4/ip_output.c:1463
> > [< inline >] rcu_read_unlock /kernel/include/linux/rcupdate.h:922
> > [<ffffffff8504e10b>] raw_sendmsg+0x17bb/0x25c0
> > /kernel/net/ieee802154/socket.c:53
> > [<ffffffff8504c950>] ? dst_output+0x190/0x190 /kernel/include/net/dst.h:492
> > [< inline >] ? trace_mm_page_alloc
> > /kernel/include/trace/events/kmem.h:217
> > [<ffffffff81621609>] ? __alloc_pages_nodemask+0x559/0x16b0
> > /kernel/mm/page_alloc.c:3368
> > [<ffffffff81406260>] ? debug_check_no_locks_freed+0x290/0x290
> > /kernel/kernel/locking/lockdep.c:4104
> > [<ffffffff814c0e30>] ? is_module_text_address+0x10/0x20
> > /kernel/kernel/module.c:4057
> > [<ffffffff81360533>] ? __kernel_text_address+0x73/0xa0
> > /kernel/kernel/extable.c:103
> > [<ffffffff81406260>] ? debug_check_no_locks_freed+0x290/0x290
> > /kernel/kernel/locking/lockdep.c:4104
> > [<ffffffff81406260>] ? debug_check_no_locks_freed+0x290/0x290
> > /kernel/kernel/locking/lockdep.c:4104
> > [<ffffffff81405ced>] ? trace_hardirqs_on+0xd/0x10
> > /kernel/kernel/locking/lockdep.c:2635
> > [<ffffffff81406260>] ? debug_check_no_locks_freed+0x290/0x290
> > /kernel/kernel/locking/lockdep.c:4104
> > [< inline >] ? sock_rps_record_flow /kernel/include/net/sock.h:874
> > [<ffffffff85089113>] ? inet_sendmsg+0x73/0x4c0 /kernel/net/ipv4/af_inet.c:729
> > [< inline >] ? rcu_read_unlock /kernel/include/linux/rcupdate.h:922
> > [< inline >] ? sock_rps_record_flow_hash
> > /kernel/include/net/sock.h:867
> > [< inline >] ? sock_rps_record_flow /kernel/include/net/sock.h:874
> > [<ffffffff8508929a>] ? inet_sendmsg+0x1fa/0x4c0 /kernel/net/ipv4/af_inet.c:729
> > [<ffffffff85089395>] inet_sendmsg+0x2f5/0x4c0 /kernel/net/ipv4/af_inet.c:736
> > [< inline >] ? sock_rps_record_flow /kernel/include/net/sock.h:874
> > [<ffffffff85089113>] ? inet_sendmsg+0x73/0x4c0 /kernel/net/ipv4/af_inet.c:729
> > [<ffffffff850890a0>] ? inet_recvmsg+0x4a0/0x4a0
> > /kernel/include/linux/compiler.h:222
> > [< inline >] sock_sendmsg_nosec /kernel/net/socket.c:611
> > [<ffffffff84c3434a>] sock_sendmsg+0xca/0x110 /kernel/net/socket.c:621
> > [<ffffffff84c35448>] SYSC_sendto+0x208/0x350 /kernel/net/socket.c:1651
> > [<ffffffff84c35240>] ? SYSC_connect+0x2e0/0x2e0 /kernel/net/socket.c:1543
> > [<ffffffff81698650>] ? __pmd_alloc+0x350/0x350 /kernel/mm/memory.c:3928
> > [<ffffffff81230b3b>] ? __do_page_fault+0x2ab/0x8e0
> > /kernel/arch/x86/mm/fault.c:1184
> > [<ffffffff81230c30>] ? __do_page_fault+0x3a0/0x8e0
> > /kernel/arch/x86/mm/fault.c:1271
> > [<ffffffff813fb5da>] ? up_read+0x1a/0x40 /kernel/kernel/locking/rwsem.c:79
> > [<ffffffff81230a29>] ? __do_page_fault+0x199/0x8e0
> > /kernel/arch/x86/mm/fault.c:1187
> > [<ffffffff84c379b0>] SyS_sendto+0x40/0x50 /kernel/net/socket.c:1619
> > [<ffffffff85dab940>] entry_SYSCALL_64_fastpath+0x23/0xc1
> > /kernel/arch/x86/entry/entry_64.S:207
> > Memory state around the buggy address:
> > ffff8800a45df280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > ffff8800a45df300: f1 f1 f1 f1 00 00 04 f4 f2 f2 f2 f2 00 00 04 f4
> > > ffff8800a45df380: f2 f2 f2 f2 00 00 00 00 00 f4 f4 f4 f3 f3 f3 f3
> > ^
> > ffff8800a45df400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > ffff8800a45df480: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 01 f4 f4 f4
> > ==================================================================
> >
> > #include <unistd.h>
> > #include <sys/syscall.h>
> > #include <string.h>
> > #include <stdint.h>
> > #include <pthread.h>
> > #include <sys/socket.h>
> > #include <sys/mman.h>
> > #include <netinet/in.h>
> > int main()
> > {
> > mmap((void *)0x20000000ul, 0x19000ul, PROT_READ|PROT_WRITE,
> > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0);
> > int sock = socket(AF_INET, SOCK_RAW, IPPROTO_TCP);
> > int sock_dup = dup(sock);
> > memcpy((void*)0x2000b000,
> > "\x11\xaf\x7d\x99\x91\x3c\x87\x34\x85\x18\xc4\xd6\xf2\x30\x0a", 15);
> > *(uint16_t*)0x20002fec = (uint16_t)0x2;
> > *(uint16_t*)0x20002fee = (uint16_t)0x11ab;
> > *(uint32_t*)0x20002ff0 = (uint32_t)0x100007f;
> > sendto(sock_dup, (void *)0x2000b000ul, 0xful, 0x8800ul, (struct
> > sockaddr *)0x20002fe4ul, 0x1cul);
> > memcpy((void*)0x2001504f,
> > "\x7e\xb1\x52\x5b\x78\x85\x27\xe7\xcc\x3d\xf5\x18\x1b\xba\xda\x97\x6c\x18\x72\x0c\xd2\x0a\xa6\x77\xb7\x8b\xa2\xd2\x1d\xf0\x6b\xf6\x1a\x27\x6b\x98\x3e\x0b\x49\x8d\x54\x6e\x9e\xbb\x21\x4a\x72\x79\x1f\x82\xaf\x89\x2c\xf6\xd3\xc9\xd7\xed\x18\x29\x4d\x2e\x03\x15\xe2\x03\x14\xd0\xac\xa5\x81\x37\x73\x88\xa9\xf5\x08\xe5\xef\x5b\x56\xb7\x18\x8f\xe6\x19\xea\x91\x82\x23\xdd\x2c\x5c\xa5\xf0\xfc\xd8\xe2\x8b\x91\x48\x70\x24\xed\xae\xf9\x06\xac\xc4\x53\x01\xc3\xf5\xa3\x10\xef\xf1\xa6\x2b\xae\x72\xc7\x1a\x02\xee\x78\xcd\xd1\x7e\x8c\x9c\x1a\x36\xc7\xd4\x7c\x82\x64\xf7\x8b\x5a\xb0\x72\xa8\x87\x3c\xdc\xd0\xba\xfe\x70\x7d\x8c\x23\x78\xad\x7c\x31\x04\xec\xab\x1e\x4c\xee\xae\x84\xd8\x1a\x1d\x85\xa5\x57\xa8\x24\x53\x08\x1c\x4f\xda\x49\xe5\x3a\x99\x8c\x29\xa1\xed\x4b\x42\x7a\x15\x48\x2a\x22\x3b\x81\xfe\x47\x7
4\xc1\x2f\x64\xcf\x10\xd4\x71\x72\x50\x71\xd7\xf6\xb0\xca\x41\x9a\x5e\x3e\xe4\x31\x19\xd1\x19\x46\x20\x66\x4c\x2f\xea\x76\x17\x2d\x94",
> > 232);
> > *(uint16_t*)0x2001501c = (uint16_t)0xa;
> > *(uint16_t*)0x2001501e = (uint16_t)0x11ab;
> > *(uint32_t*)0x20015020 = (uint32_t)0xbdc;
> > *(uint32_t*)0x20015024 = (uint32_t)0x0;
> > *(uint32_t*)0x20015028 = (uint32_t)0x0;
> > *(uint32_t*)0x2001502c = (uint32_t)0x0;
> > *(uint32_t*)0x20015030 = (uint32_t)0x1000000;
> > *(uint32_t*)0x20015034 = (uint32_t)0x3;
> > sendto(sock_dup, (void *)0x2001504ful, 0xe8ul, 0x880ul, (struct
> > sockaddr *)0x20015000ul, 0x1cul);
> > return 0;
> > }
Actually, in order to fix the non-conntrack case too, I believe the next
patch is required:
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index d4c5115..365f4fb 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3716,6 +3716,8 @@ void tcp_parse_options(const struct sk_buff *skb,
length--;
continue;
default:
+ if (length < 2)
+ return;
opsize = *ptr++;
if (opsize < 2) /* "silly options" */
return;
@@ -3873,6 +3875,8 @@ const u8 *tcp_parse_md5sig_option(const struct tcphdr *th)
length--;
continue;
default:
+ if (length < 2)
+ return;
opsize = *ptr++;
if (opsize < 2 || opsize > length)
return NULL;
diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
index 278f3b9..7cc1d9c 100644
--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
@@ -410,6 +410,8 @@ static void tcp_options(const struct sk_buff *skb,
length--;
continue;
default:
+ if (length < 2)
+ return;
opsize=*ptr++;
if (opsize < 2) /* "silly options" */
return;
@@ -470,6 +472,8 @@ static void tcp_sack(const struct sk_buff *skb, unsigned int dataoff,
length--;
continue;
default:
+ if (length < 2)
+ return;
opsize = *ptr++;
if (opsize < 2) /* "silly options" */
return;
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply related
* [RFC] r8169: Module parameter for opt-in of ASPM
From: Kast Bernd @ 2016-03-27 22:54 UTC (permalink / raw)
To: nic_swsd; +Cc: netdev, linux-kernel
Hello,
this patch adds a module parameter in order to activate ASPM.
Basically it reapplies d64ec841517a25f6d468bde9f67e5b4cffdc67c7, which
was reverted as some people reported delayed link status detection and
increased boot times: https://lkml.org/lkml/2013/2/6/372.
The differences to this patch are:
1) Turned off by default but with module parameter for activation
2) Flags for aspm and clock request are set after ephy_init
3) Minor changes because of merging
Motivation for changes compared to previous patch:
1) Probably the patch wouldn't be merged when it is active by
default
2) There are comments, that state: "disable aspm and clock
request before access ephy", thus I tried to respect that and
activate it afterwards.
Perhaps that was even the cause for the problems that let to
reverting the old patch, but unfortunately couldn't reproduce
these bugs and therefore wasn't able to check if it's solved with
my version.
Remarks:
1) This patch drops power usage from 13W to 8W and therefore
leads to a vastly increased battery life and reduced heat
dissipation on my notebook. Some people reported similar issues
on different hardware (for example):
https://bugzilla.kernel.org/show_bug.cgi?id=72211
http://www.spinics.net/lists/netdev/msg298949.html
Especially on newer systems (Haswell) the power savings seem to
be huge, as the network chip prevents the CPU from entering
deeper package sleep states (no PC6/PC7 are reached, only PC3).
2) To benefit from the power savings a reboot is not sufficient.
At least on my system it has to be powered off completely (cold
boot). There seem to be no kernel functions to enable a link
state, there is just pci_disable_link_state to disable low power
states, thus this problem can't be solved by now.
3) This patch was tested only on a single system and supports
only the same cards than the old patch, as I couldn't find any
documents to read about the registers and flags of newer cards.
If anybody could send me a link, or tell me that it's save to
set the same flags on newer cards this patch could probably also
cover those cards.
Should I add support for newer cards, too?
Is there any chance to enable ASPM by default again?
Which improvements do I need to do in order to get this patch to the
kernel again?
I would appreciate any kind of feedback.
Signed-off-by: Kast Bernd <kastbernd@gmx.de>
---
drivers/net/ethernet/realtek/r8169.c | 82 ++++++++++++++++++++++++++++++++----
1 file changed, 74 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 537974c..6a533a4 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -346,6 +346,7 @@ MODULE_DEVICE_TABLE(pci, rtl8169_pci_tbl);
static int rx_buf_sz = 16383;
static int use_dac;
+static int use_aspm;
static struct {
u32 msg_enable;
} debug = { -1 };
@@ -509,6 +510,7 @@ enum rtl8168_registers {
#define PWM_EN (1 << 22)
#define RXDV_GATED_EN (1 << 19)
#define EARLY_TALLY_EN (1 << 16)
+#define FORCE_CLK (1 << 15) /* force clock request */
};
enum rtl_register_content {
@@ -860,6 +862,8 @@ MODULE_AUTHOR("Realtek and the Linux r8169 crew <netdev@vger.kernel.org>");
MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver");
module_param(use_dac, int, 0);
MODULE_PARM_DESC(use_dac, "Enable PCI DAC. Unsafe on 32 bit PCI slot.");
+module_param(use_aspm, int, 0);
+MODULE_PARM_DESC(use_aspm, "Enable ASPM power saving. Unsave on some systems");
module_param_named(debug, debug.msg_enable, int, 0);
MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., 16=all)");
MODULE_LICENSE("GPL");
@@ -5899,7 +5903,8 @@ static void rtl_hw_start_8168e_2(struct rtl8169_private *tp)
RTL_W8(MaxTxPacketSize, EarlySize);
- rtl_disable_clock_request(pdev);
+ if (!use_aspm)
+ rtl_disable_clock_request(pdev);
RTL_W32(TxConfig, RTL_R32(TxConfig) | TXCFG_AUTO_FIFO);
RTL_W8(MCU, RTL_R8(MCU) & ~NOW_IS_OOB);
@@ -5909,7 +5914,13 @@ static void rtl_hw_start_8168e_2(struct rtl8169_private *tp)
RTL_W8(DLLPR, RTL_R8(DLLPR) | PFM_EN);
RTL_W32(MISC, RTL_R32(MISC) | PWM_EN);
- RTL_W8(Config5, RTL_R8(Config5) & ~Spi_en);
+
+ if (use_aspm) {
+ RTL_W8(Config5, (RTL_R8(Config5) & ~Spi_en) | ASPM_en);
+ RTL_W8(Config2, RTL_R8(Config2) | ClkReqEn);
+ } else {
+ RTL_W8(Config5, RTL_R8(Config5) & ~Spi_en);
+ }
}
static void rtl_hw_start_8168f(struct rtl8169_private *tp)
@@ -5934,13 +5945,21 @@ static void rtl_hw_start_8168f(struct rtl8169_private *tp)
RTL_W8(MaxTxPacketSize, EarlySize);
- rtl_disable_clock_request(pdev);
+ if (!use_aspm)
+ rtl_disable_clock_request(pdev);
RTL_W32(TxConfig, RTL_R32(TxConfig) | TXCFG_AUTO_FIFO);
RTL_W8(MCU, RTL_R8(MCU) & ~NOW_IS_OOB);
RTL_W8(DLLPR, RTL_R8(DLLPR) | PFM_EN);
- RTL_W32(MISC, RTL_R32(MISC) | PWM_EN);
- RTL_W8(Config5, RTL_R8(Config5) & ~Spi_en);
+
+ if (use_aspm) {
+ RTL_W32(MISC, RTL_R32(MISC) | PWM_EN | FORCE_CLK);
+ RTL_W8(Config5, (RTL_R8(Config5) & ~Spi_en) | ASPM_en);
+ RTL_W8(Config2, RTL_R8(Config2) | ClkReqEn);
+ } else {
+ RTL_W32(MISC, RTL_R32(MISC) | PWM_EN);
+ RTL_W8(Config5, RTL_R8(Config5) & ~Spi_en);
+ }
}
static void rtl_hw_start_8168f_1(struct rtl8169_private *tp)
@@ -5957,6 +5976,12 @@ static void rtl_hw_start_8168f_1(struct rtl8169_private *tp)
rtl_ephy_init(tp, e_info_8168f_1, ARRAY_SIZE(e_info_8168f_1));
+ if (use_aspm) {
+ RTL_W32(MISC, (RTL_R32(MISC) | FORCE_CLK));
+ RTL_W8(Config5, RTL_R8(Config5) | ASPM_en);
+ RTL_W8(Config2, RTL_R8(Config2) | ClkReqEn);
+ }
+
rtl_w0w1_eri(tp, 0x0d4, ERIAR_MASK_0011, 0x0c00, 0xff00, ERIAR_EXGMAC);
/* Adjust EEE LED frequency */
@@ -6031,6 +6056,12 @@ static void rtl_hw_start_8168g_1(struct rtl8169_private *tp)
RTL_W8(Config2, RTL_R8(Config2) & ~ClkReqEn);
RTL_W8(Config5, RTL_R8(Config5) & ~ASPM_en);
rtl_ephy_init(tp, e_info_8168g_1, ARRAY_SIZE(e_info_8168g_1));
+
+ if (use_aspm) {
+ RTL_W8(Config5, RTL_R8(Config5) | ASPM_en);
+ RTL_W8(Config2, RTL_R8(Config2) | ClkReqEn);
+ RTL_W32(MISC, RTL_R32(MISC) | FORCE_CLK);
+ }
}
static void rtl_hw_start_8168g_2(struct rtl8169_private *tp)
@@ -6049,6 +6080,12 @@ static void rtl_hw_start_8168g_2(struct rtl8169_private *tp)
RTL_W8(Config2, RTL_R8(Config2) & ~ClkReqEn);
RTL_W8(Config5, RTL_R8(Config5) & ~ASPM_en);
rtl_ephy_init(tp, e_info_8168g_2, ARRAY_SIZE(e_info_8168g_2));
+
+ if (use_aspm) {
+ RTL_W8(Config5, RTL_R8(Config5) | ASPM_en);
+ RTL_W8(Config2, RTL_R8(Config2) | ClkReqEn);
+ RTL_W32(MISC, RTL_R32(MISC) | FORCE_CLK);
+ }
}
static void rtl_hw_start_8411_2(struct rtl8169_private *tp)
@@ -6068,6 +6105,12 @@ static void rtl_hw_start_8411_2(struct rtl8169_private *tp)
RTL_W8(Config2, RTL_R8(Config2) & ~ClkReqEn);
RTL_W8(Config5, RTL_R8(Config5) & ~ASPM_en);
rtl_ephy_init(tp, e_info_8411_2, ARRAY_SIZE(e_info_8411_2));
+
+ if (use_aspm) {
+ RTL_W8(Config5, RTL_R8(Config5) | ASPM_en);
+ RTL_W8(Config2, RTL_R8(Config2) | ClkReqEn);
+ RTL_W32(MISC, RTL_R32(MISC) | FORCE_CLK);
+ }
}
static void rtl_hw_start_8168h_1(struct rtl8169_private *tp)
@@ -6514,6 +6557,12 @@ static void rtl_hw_start_8105e_1(struct rtl8169_private *tp)
rtl_ephy_init(tp, e_info_8105e_1, ARRAY_SIZE(e_info_8105e_1));
+ if (use_aspm) {
+ RTL_W8(Config5, RTL_R8(Config5) | ASPM_en);
+ RTL_W8(Config2, RTL_R8(Config2) | ClkReqEn);
+ RTL_W32(MISC, RTL_R32(MISC) | FORCE_CLK);
+ }
+
rtl_pcie_state_l2l3_enable(tp, false);
}
@@ -6541,6 +6590,12 @@ static void rtl_hw_start_8402(struct rtl8169_private *tp)
rtl_ephy_init(tp, e_info_8402, ARRAY_SIZE(e_info_8402));
+ if (use_aspm) {
+ RTL_W8(Config5, RTL_R8(Config5) | ASPM_en);
+ RTL_W8(Config2, RTL_R8(Config2) | ClkReqEn);
+ RTL_W32(MISC, RTL_R32(MISC) | FORCE_CLK);
+ }
+
rtl_tx_performance_tweak(tp->pci_dev, 0x5 << MAX_READ_REQUEST_SHIFT);
rtl_eri_write(tp, 0xc8, ERIAR_MASK_1111, 0x00000002, ERIAR_EXGMAC);
@@ -6561,7 +6616,16 @@ static void rtl_hw_start_8106(struct rtl8169_private *tp)
/* Force LAN exit from ASPM if Rx/Tx are not idle */
RTL_W32(FuncEvent, RTL_R32(FuncEvent) | 0x002800);
- RTL_W32(MISC, (RTL_R32(MISC) | DISABLE_LAN_EN) & ~EARLY_TALLY_EN);
+ if (!use_aspm) {
+ RTL_W32(MISC, (RTL_R32(MISC) | DISABLE_LAN_EN) &
+ ~EARLY_TALLY_EN);
+ } else {
+ RTL_W32(MISC, (RTL_R32(MISC) | DISABLE_LAN_EN | FORCE_CLK) &
+ ~EARLY_TALLY_EN);
+ RTL_W8(Config5, RTL_R8(Config5) | ASPM_en);
+ RTL_W8(Config2, RTL_R8(Config2) | ClkReqEn);
+ }
+
RTL_W8(MCU, RTL_R8(MCU) | EN_NDP | EN_OOB_RESET);
RTL_W8(DLLPR, RTL_R8(DLLPR) & ~PFM_EN);
@@ -8181,8 +8245,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
/* disable ASPM completely as that cause random device stop working
* problems as well as full system hangs for some PCIe devices users */
- pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S | PCIE_LINK_STATE_L1 |
- PCIE_LINK_STATE_CLKPM);
+ if (!use_aspm) {
+ pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S
+ | PCIE_LINK_STATE_L1 | PCIE_LINK_STATE_CLKPM);
+ }
/* enable device (incl. PCI PM wakeup and hotplug setup) */
rc = pci_enable_device(pdev);
--
2.7.4
^ permalink raw reply related
* [PATCH TRIVIAL] drivers/net/usb/plusb.c: Fix typo
From: Diego Viola @ 2016-03-27 23:58 UTC (permalink / raw)
To: linux-usb-u79uwXL29TY76Z2rM5mHXA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
trivial-DgEjT+Ai2ygdnm+yROfE0A, Diego Viola
Signed-off-by: Diego Viola <diego.viola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/usb/plusb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/plusb.c b/drivers/net/usb/plusb.c
index 1bfe0fc..22e1a9a 100644
--- a/drivers/net/usb/plusb.c
+++ b/drivers/net/usb/plusb.c
@@ -38,7 +38,7 @@
* HEADS UP: this handshaking isn't all that robust. This driver
* gets confused easily if you unplug one end of the cable then
* try to connect it again; you'll need to restart both ends. The
- * "naplink" software (used by some PlayStation/2 deveopers) does
+ * "naplink" software (used by some PlayStation/2 developers) does
* the handshaking much better! Also, sometimes this hardware
* seems to get wedged under load. Prolific docs are weak, and
* don't identify differences between PL2301 and PL2302, much less
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 related
* Re: [PATCH net] inet: add proper locking in __inet{6}_lookup()
From: David Miller @ 2016-03-28 2:32 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, lorenzo
In-Reply-To: <1458944115.6473.62.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 25 Mar 2016 15:15:15 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Blocking BH in __inet{6}_lookup() is not correct, as the lookups
> are done using RCU protection.
>
> It matters only starting from Lorenzo Colitti patches to destroy
> a TCP socket, since rcu_read_lock() is already held by other users
> of these functions.
>
> This can be backported to all known stable versions, since TCP got RCU
> lookups back in 2.6.29 : Even if iproute2 contained no code to trigger
> the bug, some user programs could have used the API.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Lorenzo Colitti <lorenzo@google.com>
This is quite the maze of RCU locking here. With this change,
inet_lookup is now:
rcu_read_lock();
sk = x(); {
rcu_read_lock();
...
rcu_read_unlock();
}
if (!sk) {
sk = y(); {
rcu_read_lock();
...
rcu_read_unlock();
}
}
rcu_read_unlock();
It would seem to me that we should bubble up the rcu locking calls.
If, as you say, the other users do RCU locking already, then it should
be safe to do what your patch is doing and also remove the RCU locking
done by __inet_lookup_established() and __inet_lookup_listener().
^ 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