* Re: [PATCH net-next 2/7] net: dsa: mv88e6xxx: 6185 has only 256 FDBs
From: Andrew Lunn @ 2016-03-27 2:52 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, linux-kernel, kernel, David S. Miller, Patrick Uiterwijk,
Guenter Roeck
In-Reply-To: <1459043983-12088-3-git-send-email-vivien.didelot@savoirfairelinux.com>
On Sat, Mar 26, 2016 at 09:59:38PM -0400, Vivien Didelot wrote:
> The 6185 family has only 256 indexable address databases, while the
> others (such as 6352) have 4095. Explicit and use these maximum values
> in the _mv88e6xxx_fid_new function.
Hi Vivien
I've been looking at the Marvell reference code, in particular, the
function gfdbGetAtuAllCount().
The following device have 16 databases.
( DEV_88E6021 | DEV_88E6060 | DEV_88E6063 | \
DEV_FH_VPN | DEV_88E6083 | DEV_88E6183 | DEV_88E6093 | DEV_88E6061 )
The following device have 64 databases.
( DEV_88E6065 )
The following devices have 256 databases
( DEV_88E6095_FAMILY | DEV_88E6185_FAMILY )
And the following devices have 4096
( DEV_88E6097_FAMILY | DEV_88E6165_FAMILY | DEV_88E6\
351_FAMILY| DEV_88E6352_FAMILY )
Andrew
^ permalink raw reply
* Re: [PATCH net-next 4/7] net: dsa: mv88e6xxx: fix ATU FID access for 6185
From: Andrew Lunn @ 2016-03-27 3:04 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, linux-kernel, kernel, David S. Miller, Patrick Uiterwijk,
Guenter Roeck
In-Reply-To: <1459043983-12088-5-git-send-email-vivien.didelot@savoirfairelinux.com>
On Sat, Mar 26, 2016 at 09:59:40PM -0400, Vivien Didelot wrote:
> The 6185 family does not have a ATU FID register. It splits it in the
> ATU Control register and the ATU Operation.
Looking at the reference code, the following devices have a FID
register:
( DEV_88E6097_FAMILY | DEV_88E6165_FAMILY | DEV_88E6351_FAMILY |
DEV_88E6352_FAMILY)
If there are 256 databases, it gets split across the two registers.
If there are only 64, it all goes in the ATU operation.
Andrew
>
> Add 6185 support for FID (a.k.a. DBNum) in ATU commands.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
> ---
> drivers/net/dsa/mv88e6xxx.c | 14 ++++++++++++++
> drivers/net/dsa/mv88e6xxx.h | 2 +-
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
> index df3f219..4b3c466 100644
> --- a/drivers/net/dsa/mv88e6xxx.c
> +++ b/drivers/net/dsa/mv88e6xxx.c
> @@ -961,6 +961,20 @@ static int _mv88e6xxx_atu_cmd(struct dsa_switch *ds, u16 fid, u16 cmd)
> ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_FID, fid);
> if (ret < 0)
> return ret;
> + } else if (mv88e6xxx_6185_family(ds)) {
> + /* ATU DBNum[7:4] are located in ATU Control 15:12 */
> + ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, GLOBAL_ATU_CONTROL);
> + if (ret < 0)
> + return ret;
> +
> + ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_CONTROL,
> + (ret & 0xfff) |
> + ((fid << 8) & 0xf000));
> + if (ret < 0)
> + return ret;
> +
> + /* ATU DBNum[3:0] are located in ATU Operation 3:0 */
> + cmd |= fid & 0xf;
> } else {
> return -EOPNOTSUPP;
> }
> diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
> index febab76..94d3cb3 100644
> --- a/drivers/net/dsa/mv88e6xxx.h
> +++ b/drivers/net/dsa/mv88e6xxx.h
> @@ -366,7 +366,7 @@ struct mv88e6xxx_switch_id {
> };
>
> struct mv88e6xxx_atu_entry {
> - u16 fid;
> + u16 fid; /* 8-bit DBNum in 88E6185 family */
> u8 state;
> bool trunk;
> u16 portv_trunkid;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] drivers : Remove unnecessary void pointer conversions
From: Bhaskar Jupudi @ 2016-03-27 3:42 UTC (permalink / raw)
To: davem, igal.liberman, netdev, linux-kernel; +Cc: Bhaskar Jupudi
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);
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,
"fsl,qman-channel-range",
&lenp);
if (!u32_prop) {
--
2.5.0
^ permalink raw reply related
* Re: [PATCH] drivers : Remove unnecessary void pointer conversions
From: Joe Perches @ 2016-03-27 5:49 UTC (permalink / raw)
To: Bhaskar Jupudi, davem, igal.liberman, netdev, linux-kernel
In-Reply-To: <1459050140-14621-1-git-send-email-njupudi@ucsc.edu>
On Sat, 2016-03-26 at 20:42 -0700, 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.
Your patch subject is incorrect, this is for fman
not all of drivers/
If you do one file, you should do them all.
$ git grep -E "\*\s*\)\s*of_get_property" drivers/net/ethernet/freescale/
drivers/net/ethernet/freescale/fman/fman.c: u32_prop = (const u32 *)of_get_property(fm_node, "cell-index", &lenp);
drivers/net/ethernet/freescale/fman/fman.c: u32_prop = (const u32 *)of_get_property(fm_node,
drivers/net/ethernet/freescale/fman/fman_port.c: u32_prop = (const u32 *)of_get_property(port_node, "cell-index", &lenp);
drivers/net/ethernet/freescale/fman/fman_port.c: u32_prop = (const u32 *)of_get_property(port_node,
drivers/net/ethernet/freescale/fman/fman_port.c: u32_prop = (const u32 *)of_get_property(port_node,
drivers/net/ethernet/freescale/fman/mac.c: char_prop = (const char *)of_get_property(mac_node,
> drivers/net/ethernet/freescale/fman/fman.c | 4 ++--
^ permalink raw reply
* [PATCH 12/31] sunrpc: auth_gss: use parity8
From: zhaoxiu.zeng @ 2016-03-27 6:51 UTC (permalink / raw)
To: Trond Myklebust, Anna Schumaker, J. Bruce Fields, Jeff Layton,
David S. Miller, Herbert Xu
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1458788612-4367-1-git-send-email-zhaoxiu.zeng-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Zeng Zhaoxiu <zhaoxiu.zeng-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Zeng Zhaoxiu <zhaoxiu.zeng-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/sunrpc/auth_gss/gss_krb5_keys.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/net/sunrpc/auth_gss/gss_krb5_keys.c b/net/sunrpc/auth_gss/gss_krb5_keys.c
index 8701331..c41b389 100644
--- a/net/sunrpc/auth_gss/gss_krb5_keys.c
+++ b/net/sunrpc/auth_gss/gss_krb5_keys.c
@@ -243,16 +243,12 @@ err_return:
return ret;
}
-#define smask(step) ((1<<step)-1)
-#define pstep(x, step) (((x)&smask(step))^(((x)>>step)&smask(step)))
-#define parity_char(x) pstep(pstep(pstep((x), 4), 2), 1)
-
static void mit_des_fixup_key_parity(u8 key[8])
{
int i;
for (i = 0; i < 8; i++) {
key[i] &= 0xfe;
- key[i] |= 1^parity_char(key[i]);
+ key[i] |= !parity8(key[i]);
}
}
--
2.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* 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
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