* Re: [iproute PATCH] man: tc-csum.8: Fix example
From: Guillaume Nault @ 2017-01-30 12:12 UTC (permalink / raw)
To: Phil Sutter, Stephen Hemminger, netdev
In-Reply-To: <20170128111648.GX5197@orbyte.nwl.cc>
On Sat, Jan 28, 2017 at 12:16:48PM +0100, Phil Sutter wrote:
> On Fri, Jan 27, 2017 at 09:49:58PM +0100, Guillaume Nault wrote:
> > On Fri, Jan 27, 2017 at 12:15:01PM +0100, Phil Sutter wrote:
> > > +# tc filter add dev eth0 prio 1 protocol ip parent ffff: \\
> > > u32 match ip src 192.168.1.100/32 flowid :1 \\
> > > - action pedit munge ip dst set 0x12345678 pipe \\
> > > + action pedit munge ip dst set 1.2.3.4 pipe \\
> > >
> > Just nitpicking here, but IMHO examples like this should better use IP
> > addresses reserved for documentation (192.0.2.0/24, 198.51.100.0/24 or
> > 203.0.113.0/24).
>
> Good point! This wasn't on my radar yet and I didn't know there were
> IPv4 ranges specifically for that purpose.
>
The same exists for IPv6: 2001:db8::/32, reserved by RFC 3849. But I
guess you probably already figured it out.
> I guess the reasoning here is analogous to why one shouldn't use
> 'example.com' everywhere.
>
Not sure about what you mean by "one shouldn't use 'example.com'
everywhere". Other domains may sometime be more appropriate (like
.invalid), but example.com is one of the domains reserved for
documentation by RFC 2606.
> Luckily, 1.2.3.0/24 seems to be reserved by APNIC for testing purposes.
> :)
>
I'd expect that too many martians target these addresses. But AFAIK, in
theory, nothing prevents APNIC from allocating 1.2.3.0/24.
^ permalink raw reply
* Re: 4.9 conntrack performance issues
From: Guillaume Nault @ 2017-01-30 12:21 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: Netfilter Devel, Pablo Neira Ayuso,
Linux Kernel Network Developers
In-Reply-To: <c18a30d1b61b758e8de93ea373247da7@nuclearcat.com>
On Mon, Jan 30, 2017 at 01:37:43PM +0200, Denys Fedoryshchenko wrote:
> On 2017-01-30 13:26, Guillaume Nault wrote:
> > On Sun, Jan 15, 2017 at 01:05:58AM +0200, Denys Fedoryshchenko wrote:
> > > Hi!
> > >
> > > Sorry if i added someone wrongly to CC, please let me know, if i
> > > should
> > > remove.
> > > I just run successfully 4.9 on my nat several days ago, and seems
> > > panic
> > > issue disappeared.
> > >
> > Hi Denys,
> >
> > After two weeks running Linux 4.9, do you confirm that the original
> > issue[1] is gone?
> >
> > Regards,
> >
> > Guillaume
> >
> > [1]: https://www.spinics.net/lists/netdev/msg410795.html
> Yes, no more reboots at all and 4.9 patched for gc issues seems
> significantly better for NAT performance (CPU load lower almost twice than
> previous kernels, i dont have exact numbers).
Great! Thanks for the feedback.
^ permalink raw reply
* RE: [PATCH 1/2] batman-adv: Fix double call of dev_queue_xmit
From: David Laight @ 2017-01-30 12:07 UTC (permalink / raw)
To: 'Simon Wunderlich', davem@davemloft.net
Cc: netdev@vger.kernel.org, b.a.t.m.a.n@lists.open-mesh.org,
Sven Eckelmann
In-Reply-To: <20170128105651.3061-2-sw@simonwunderlich.de>
From: Simon Wunderlich
> Sent: 28 January 2017 10:57
> From: Sven Eckelmann <sven@narfation.org>
>
> The net_xmit_eval has side effects because it is not making sure that e
> isn't evaluated twice.
>
> #define net_xmit_eval(e) ((e) == NET_XMIT_CN ? 0 : (e))
It is probably worth fixing the #define.
David
^ permalink raw reply
* [PATCH net] net/mlx4_core: Avoid command timeouts during VF driver device shutdown
From: Tariq Toukan @ 2017-01-30 13:11 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Jack Morgenstein, Tariq Toukan
From: Jack Morgenstein <jackm@dev.mellanox.co.il>
Some Hypervisors detach VFs from VMs by instantly causing an FLR event
to be generated for a VF.
In the mlx4 case, this will cause that VF's comm channel to be disabled
before the VM has an opportunity to invoke the VF device's "shutdown"
method.
The result is that the VF driver on the VM will experience a command
timeout during the shutdown process when the Hypervisor does not deliver
a command-completion event to the VM.
To avoid FW command timeouts on the VM when the driver's shutdown method
is invoked, we detect the absence of the VF's comm channel at the very
start of the shutdown process. If the comm-channel has already been
disabled, we cause all FW commands during the device shutdown process to
immediately return success (and thus avoid all command timeouts).
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/catas.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/intf.c | 12 ++++++++++++
drivers/net/ethernet/mellanox/mlx4/mlx4.h | 1 +
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/catas.c b/drivers/net/ethernet/mellanox/mlx4/catas.c
index c7e939945259..53daa6ca5d83 100644
--- a/drivers/net/ethernet/mellanox/mlx4/catas.c
+++ b/drivers/net/ethernet/mellanox/mlx4/catas.c
@@ -158,7 +158,7 @@ static int mlx4_reset_slave(struct mlx4_dev *dev)
return -ETIMEDOUT;
}
-static int mlx4_comm_internal_err(u32 slave_read)
+int mlx4_comm_internal_err(u32 slave_read)
{
return (u32)COMM_CHAN_EVENT_INTERNAL_ERR ==
(slave_read & (u32)COMM_CHAN_EVENT_INTERNAL_ERR) ? 1 : 0;
diff --git a/drivers/net/ethernet/mellanox/mlx4/intf.c b/drivers/net/ethernet/mellanox/mlx4/intf.c
index 0e8b7c44931f..8258d08acd8c 100644
--- a/drivers/net/ethernet/mellanox/mlx4/intf.c
+++ b/drivers/net/ethernet/mellanox/mlx4/intf.c
@@ -222,6 +222,18 @@ void mlx4_unregister_device(struct mlx4_dev *dev)
return;
mlx4_stop_catas_poll(dev);
+ if (dev->persist->interface_state & MLX4_INTERFACE_STATE_DELETION &&
+ mlx4_is_slave(dev)) {
+ /* In mlx4_remove_one on a VF */
+ u32 slave_read =
+ swab32(readl(&mlx4_priv(dev)->mfunc.comm->slave_read));
+
+ if (mlx4_comm_internal_err(slave_read)) {
+ mlx4_dbg(dev, "%s: comm channel is down, entering error state.\n",
+ __func__);
+ mlx4_enter_error_state(dev->persist);
+ }
+ }
mutex_lock(&intf_mutex);
list_for_each_entry(intf, &intf_list, list)
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4.h b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
index 88ee7d8a5923..086920b615af 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
@@ -1220,6 +1220,7 @@ int mlx4_comm_cmd(struct mlx4_dev *dev, u8 cmd, u16 param,
void mlx4_srq_event(struct mlx4_dev *dev, u32 srqn, int event_type);
void mlx4_enter_error_state(struct mlx4_dev_persistent *persist);
+int mlx4_comm_internal_err(u32 slave_read);
int mlx4_SENSE_PORT(struct mlx4_dev *dev, int port,
enum mlx4_port_type *type);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next v2 1/2] qed: Add infrastructure for PTP support.
From: Richard Cochran @ 2017-01-30 13:26 UTC (permalink / raw)
To: Mintz, Yuval
Cc: davem@davemloft.net, netdev@vger.kernel.org, Kalluru, Sudarsana
In-Reply-To: <BL2PR07MB23063CA6DC624BDC4ABCCC268D480@BL2PR07MB2306.namprd07.prod.outlook.com>
On Sun, Jan 29, 2017 at 09:36:11PM +0000, Mintz, Yuval wrote:
> I might have gotten it all wrong, but I was under the assumption that time-
> stamped packets are periodic, and that the interval between two isn't
> going to be so small.
That is an incorrect assumption. Consider the Delay_Req packets
arriving on a port in the MASTER state.
> Is so, how does having a couple of additional instructions in between
> jeopardizes the next time stamp?
It is not just about the few instructions, but there is also
preemption possible.
Thanks,
Richard
^ permalink raw reply
* [PATCH] net: thunderx: avoid dereferencing xcv when NULL
From: Vincent Stehlé @ 2017-01-30 14:06 UTC (permalink / raw)
To: linux-arm-kernel, netdev; +Cc: Sunil Goutham, linux-kernel, Vincent Stehlé
This fixes the following smatch and coccinelle warnings:
drivers/net/ethernet/cavium/thunder/thunder_xcv.c:119 xcv_setup_link() error: we previously assumed 'xcv' could be null (see line 118) [smatch]
drivers/net/ethernet/cavium/thunder/thunder_xcv.c:119:16-20: ERROR: xcv is NULL but dereferenced. [coccinelle]
Fixes: 6465859aba1e66a5 ("net: thunderx: Add RGMII interface type support")
Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net>
Cc: Sunil Goutham <sgoutham@cavium.com>
---
drivers/net/ethernet/cavium/thunder/thunder_xcv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/thunder_xcv.c b/drivers/net/ethernet/cavium/thunder/thunder_xcv.c
index 67befedef709..578c7f8f11bf 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_xcv.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_xcv.c
@@ -116,8 +116,7 @@ void xcv_setup_link(bool link_up, int link_speed)
int speed = 2;
if (!xcv) {
- dev_err(&xcv->pdev->dev,
- "XCV init not done, probe may have failed\n");
+ pr_err("XCV init not done, probe may have failed\n");
return;
}
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [linux-next] NULL pointer dereference in rt6_fill_node
From: Eric Dumazet @ 2017-01-30 14:07 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: netdev
In-Reply-To: <201701302036.GGH60927.MFJLFOOStHOQFV@I-love.SAKURA.ne.jp>
On Mon, 2017-01-30 at 20:36 +0900, Tetsuo Handa wrote:
> Hello.
>
> I'm hitting this with linux-next-20170125. Is this known?
> ----------------------------------------
> [ OK ] Started Show Plymouth Reboot Screen.
>
> [ OK ] Stopped PostgreSQL database server.
>
> [ OK ] Stopped Dynamic System Tuning Daemon.
>
> [ OK ] Stopped target Network.
>
> Stopping LSB: Bring up/down networking...
>
> [ 828.169782] BUG: unable to handle kernel NULL pointer dereference at 00000000000002a4
> [ 828.172557] IP: rt6_fill_node.isra.60+0x181/0x5c0
> [ 828.174211] PGD 0
> [ 828.174212]
> [ 828.175467] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
> [ 828.177068] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter coretemp vmw_balloon pcspkr vmw_vmci i2c_piix4 shpchp ip_tables xfs libcrc32c sr_mod cdrom ata_generic sd_mod pata_acpi serio_raw vmwgfx drm_kms_helper syscopyarea sysfillrect sysimgblt mptspi fb_sys_fops scsi_transport_spi ttm ata_piix mptscsih drm i2c_core e1000 mptbase libata
> [ 828.200197] CPU: 3 PID: 539 Comm: NetworkManager Not tainted 4.10.0-rc5-next-20170125+ #45
> [ 828.203094] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
> [ 828.206835] task: ffff88006f984100 task.stack: ffffc90005afc000
> [ 828.208934] RIP: 0010:rt6_fill_node.isra.60+0x181/0x5c0
> [ 828.210701] RSP: 0018:ffffc90005aff938 EFLAGS: 00010246
> [ 828.212485] RAX: 0000000000000000 RBX: ffff88006c71ae00 RCX: 0000000000000000
> [ 828.214933] RDX: 0000000000000000 RSI: ffffc90005aff95c RDI: ffff880071773ee0
> [ 828.217394] RBP: ffffc90005aff9e0 R08: 0000000000000000 R09: 0000000000000004
> [ 828.219945] R10: ffff880071773ee4 R11: 0000000000000000 R12: ffff880071983f00
> [ 828.222381] R13: 0000000000000000 R14: 0000000000000000 R15: ffff880071773ec0
> [ 828.224920] FS: 00007ffaa9733940(0000) GS:ffff880075800000(0000) knlGS:0000000000000000
> [ 828.227664] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 828.229670] CR2: 00000000000002a4 CR3: 0000000071269000 CR4: 00000000001406e0
> [ 828.232149] Call Trace:
> [ 828.232998] ? slab_kernel_map+0xa0/0x130
> [ 828.234468] rt6_dump_route+0x60/0x70
> [ 828.235717] fib6_dump_node+0x2e/0x60
> [ 828.237005] fib6_walk_continue+0x124/0x140
> [ 828.238425] fib6_walk+0x64/0x90
> [ 828.239567] ? _raw_read_lock_bh+0x6e/0x80
> [ 828.240962] inet6_dump_fib+0x237/0x370
> [ 828.242309] ? inet6_dump_fib+0x4b/0x370
> [ 828.243646] netlink_dump+0x126/0x280
> [ 828.244963] __netlink_dump_start+0x16f/0x210
> [ 828.246464] ? fib6_flush_trees+0x40/0x40
> [ 828.247848] rtnetlink_rcv_msg+0x13b/0x230
> [ 828.249275] ? fib6_flush_trees+0x40/0x40
> [ 828.250641] ? rtnl_newlink+0x880/0x880
> [ 828.252021] netlink_rcv_skb+0x99/0xb0
> [ 828.253399] rtnetlink_rcv+0x25/0x30
> [ 828.254646] netlink_unicast+0x16d/0x200
> [ 828.255982] netlink_sendmsg+0x36b/0x390
> [ 828.257348] ___sys_sendmsg+0x1c9/0x2c0
> [ 828.259271] ? ___cache_free+0x14a/0x5b0
> [ 828.261112] ? __fget+0x117/0x210
> [ 828.262777] ? expand_files+0x2e0/0x2e0
> [ 828.264657] __sys_sendmsg+0x4f/0x90
> [ 828.266399] SyS_sendmsg+0xd/0x20
> [ 828.268042] do_syscall_64+0x67/0x1f0
> [ 828.269810] entry_SYSCALL64_slow_path+0x25/0x25
> [ 828.271885] RIP: 0033:0x7ffaa7f639fd
> [ 828.273594] RSP: 002b:00007ffc0e0c13b0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
> [ 828.276704] RAX: ffffffffffffffda RBX: 000055f219737bd0 RCX: 00007ffaa7f639fd
> [ 828.279712] RDX: 0000000000000000 RSI: 00007ffc0e0c1460 RDI: 000000000000000c
> [ 828.282623] RBP: 000055f219737ae0 R08: 0000000000000001 R09: 0000000000001000
> [ 828.286019] R10: 0000000000000063 R11: 0000000000000293 R12: 000055f21977e4f0
> [ 828.288921] R13: 00007ffc0e0c1460 R14: 0000000000000000 R15: 000055f21977e4f0
> [ 828.291766] Code: c7 47 18 00 00 00 00 48 8b 43 18 48 8b 50 48 83 e2 01 74 08 48 8b 40 48 a8 04 74 21 41 c7 47 18 10 00 00 00 48 8b 83 58 01 00 00 <8b> 88 a4 02 00 00 85 c9 74 08 41 c7 47 18 11 00 00 00 41 c6 47
> [ 828.299024] RIP: rt6_fill_node.isra.60+0x181/0x5c0 RSP: ffffc90005aff938
> [ 828.301732] CR2: 00000000000002a4
Hi Tetsuo, thanks for the report.
Fix was sent few days back :
https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=1f17e2f2c8a8be3430813119fa7b633398f6185b
^ permalink raw reply
* Re: [PATCH v6 4/5] arm: mvebu: Add device tree for 98DX3236 SoCs
From: Gregory CLEMENT @ 2017-01-30 14:29 UTC (permalink / raw)
To: Chris Packham
Cc: linux-I+IVW8TIWO2tmTQ+vhA3Yw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Mark Rutland, Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170129232035.25189-5-chris.packham-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>
Hi Chris,
On lun., janv. 30 2017, Chris Packham <chris.packham-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org> wrote:
> The Marvell 98DX3236, 98DX3336, 98DX4521 and variants are switch ASICs
> with integrated CPUs. They are similar to the Armada XP SoCs but have
> different I/O interfaces.
>
> Signed-off-by: Chris Packham <chris.packham-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Applied on mvebu/dt
Thanks,
Gregory
> ---
>
> Notes:
> Changes in v2:
> - Update devicetree binding documentation to reflect that 98DX3336 and
> 984251 are supersets of 98DX3236.
> - disable crypto block
> - disable sdio for 98DX3236, enable for 98DX4251
> Changes in v3:
> - fix typo 4521 -> 4251
> - document prestera bindings
> - rework corediv-clock binding
> - add label to packet processor node
> - add new compatible string for DFX server
> Changes in v4:
> - Collect ack from Rob
> Changes in v5:
> - Fixup license text. Add labels to nodes.
> Changes in v6:
> - None
>
> .../devicetree/bindings/arm/marvell/98dx3236.txt | 23 ++
> .../devicetree/bindings/net/marvell,prestera.txt | 50 ++++
> arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 254 +++++++++++++++++++++
> arch/arm/boot/dts/armada-xp-98dx3336.dtsi | 76 ++++++
> arch/arm/boot/dts/armada-xp-98dx4251.dtsi | 90 ++++++++
> 5 files changed, 493 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
> create mode 100644 Documentation/devicetree/bindings/net/marvell,prestera.txt
> create mode 100644 arch/arm/boot/dts/armada-xp-98dx3236.dtsi
> create mode 100644 arch/arm/boot/dts/armada-xp-98dx3336.dtsi
> create mode 100644 arch/arm/boot/dts/armada-xp-98dx4251.dtsi
>
> diff --git a/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt b/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
> new file mode 100644
> index 000000000000..64e8c73fc5ab
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
> @@ -0,0 +1,23 @@
> +Marvell 98DX3236, 98DX3336 and 98DX4251 Platforms Device Tree Bindings
> +----------------------------------------------------------------------
> +
> +Boards with a SoC of the Marvell 98DX3236, 98DX3336 and 98DX4251 families
> +shall have the following property:
> +
> +Required root node property:
> +
> +compatible: must contain "marvell,armadaxp-98dx3236"
> +
> +In addition, boards using the Marvell 98DX3336 SoC shall have the
> +following property:
> +
> +Required root node property:
> +
> +compatible: must contain "marvell,armadaxp-98dx3336"
> +
> +In addition, boards using the Marvell 98DX4251 SoC shall have the
> +following property:
> +
> +Required root node property:
> +
> +compatible: must contain "marvell,armadaxp-98dx4251"
> diff --git a/Documentation/devicetree/bindings/net/marvell,prestera.txt b/Documentation/devicetree/bindings/net/marvell,prestera.txt
> new file mode 100644
> index 000000000000..5fbab29718e8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/marvell,prestera.txt
> @@ -0,0 +1,50 @@
> +Marvell Prestera Switch Chip bindings
> +-------------------------------------
> +
> +Required properties:
> +- compatible: one of the following
> + "marvell,prestera-98dx3236",
> + "marvell,prestera-98dx3336",
> + "marvell,prestera-98dx4251",
> +- reg: address and length of the register set for the device.
> +- interrupts: interrupt for the device
> +
> +Optional properties:
> +- dfx: phandle reference to the "DFX Server" node
> +
> +Example:
> +
> +switch {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 MBUS_ID(0x03, 0x00) 0 0x100000>;
> +
> + packet-processor@0 {
> + compatible = "marvell,prestera-98dx3236";
> + reg = <0 0x4000000>;
> + interrupts = <33>, <34>, <35>;
> + dfx = <&dfx>;
> + };
> +};
> +
> +DFX Server bindings
> +-------------------
> +
> +Required properties:
> +- compatible: must be "marvell,dfx-server"
> +- reg: address and length of the register set for the device.
> +
> +Example:
> +
> +dfx-registers {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 MBUS_ID(0x08, 0x00) 0 0x100000>;
> +
> + dfx: dfx@0 {
> + compatible = "marvell,dfx-server";
> + reg = <0 0x100000>;
> + };
> +};
> diff --git a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
> new file mode 100644
> index 000000000000..9461128fae24
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
> @@ -0,0 +1,254 @@
> +/*
> + * Device Tree Include file for Marvell 98dx3236 family SoC
> + *
> + * Copyright (C) 2016 Allied Telesis Labs
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * Contains definitions specific to the 98dx3236 SoC that are not
> + * common to all Armada XP SoCs.
> + */
> +
> +#include "armada-xp.dtsi"
> +
> +/ {
> + model = "Marvell 98DX3236 SoC";
> + compatible = "marvell,armadaxp-98dx3236", "marvell,armadaxp", "marvell,armada-370-xp";
> +
> + aliases {
> + gpio0 = &gpio0;
> + gpio1 = &gpio1;
> + gpio2 = &gpio2;
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + enable-method = "marvell,98dx3236-smp";
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "marvell,sheeva-v7";
> + reg = <0>;
> + clocks = <&cpuclk 0>;
> + clock-latency = <1000000>;
> + };
> + };
> +
> + soc {
> + ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000
> + MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
> + MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000
> + MBUS_ID(0x03, 0x00) 0 0 0xa8000000 0x4000000
> + MBUS_ID(0x08, 0x00) 0 0 0xac000000 0x100000>;
> +
> + /*
> + * 98DX3236 has 1 x1 PCIe unit Gen2.0
> + */
> + pciec: pcie-controller@82000000 {
> + compatible = "marvell,armada-xp-pcie";
> + status = "disabled";
> + device_type = "pci";
> +
> + #address-cells = <3>;
> + #size-cells = <2>;
> +
> + msi-parent = <&mpic>;
> + bus-range = <0x00 0xff>;
> +
> + ranges =
> + <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000 /* Port 0.0 registers */
> + 0x82000000 0x1 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
> + 0x81000000 0x1 0 MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO */
> + 0x82000000 0x2 0 MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */>;
> +
> + pcie1: pcie@1,0 {
> + device_type = "pci";
> + assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
> + reg = <0x0800 0 0 0 0>;
> + #address-cells = <3>;
> + #size-cells = <2>;
> + #interrupt-cells = <1>;
> + ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
> + 0x81000000 0 0 0x81000000 0x1 0 1 0>;
> + interrupt-map-mask = <0 0 0 0>;
> + interrupt-map = <0 0 0 0 &mpic 58>;
> + marvell,pcie-port = <0>;
> + marvell,pcie-lane = <0>;
> + clocks = <&gateclk 5>;
> + status = "disabled";
> + };
> + };
> +
> + internal-regs {
> + coreclk: mvebu-sar@18230 {
> + compatible = "marvell,mv98dx3236-core-clock";
> + };
> +
> + cpuclk: clock-complex@18700 {
> + compatible = "marvell,mv98dx3236-cpu-clock";
> + };
> +
> + corediv-clock@18740 {
> + status = "disabled";
> + };
> +
> + xor@60900 {
> + status = "disabled";
> + };
> +
> + crypto@90000 {
> + status = "disabled";
> + };
> +
> + xor@f0900 {
> + status = "disabled";
> + };
> +
> + xor@f0800 {
> + compatible = "marvell,orion-xor";
> + reg = <0xf0800 0x100
> + 0xf0a00 0x100>;
> + clocks = <&gateclk 22>;
> + status = "okay";
> +
> + xor10 {
> + interrupts = <51>;
> + dmacap,memcpy;
> + dmacap,xor;
> + };
> + xor11 {
> + interrupts = <52>;
> + dmacap,memcpy;
> + dmacap,xor;
> + dmacap,memset;
> + };
> + };
> +
> + gpio0: gpio@18100 {
> + compatible = "marvell,orion-gpio";
> + reg = <0x18100 0x40>;
> + ngpios = <32>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + interrupts = <82>, <83>, <84>, <85>;
> + };
> +
> + /* does not exist */
> + gpio1: gpio@18140 {
> + compatible = "marvell,orion-gpio";
> + reg = <0x18140 0x40>;
> + status = "disabled";
> + };
> +
> + gpio2: gpio@18180 { /* rework some properties */
> + compatible = "marvell,orion-gpio";
> + reg = <0x18180 0x40>;
> + ngpios = <1>; /* only gpio #32 */
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + interrupts = <87>;
> + };
> +
> + nand: nand@d0000 {
> + clocks = <&dfx_coredivclk 0>;
> + };
> + };
> +
> + dfxr: dfx-registers@ac000000 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 MBUS_ID(0x08, 0x00) 0 0x100000>;
> +
> + dfx_coredivclk: corediv-clock@f8268 {
> + compatible = "marvell,mv98dx3236-corediv-clock";
> + reg = <0xf8268 0xc>;
> + #clock-cells = <1>;
> + clocks = <&mainpll>;
> + clock-output-names = "nand";
> + };
> +
> + dfx: dfx@0 {
> + compatible = "marvell,dfx-server";
> + reg = <0 0x100000>;
> + };
> + };
> +
> + switch: switch@a8000000 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 MBUS_ID(0x03, 0x00) 0 0x100000>;
> +
> + pp0: packet-processor@0 {
> + compatible = "marvell,prestera-98dx3236";
> + reg = <0 0x4000000>;
> + interrupts = <33>, <34>, <35>;
> + dfx = <&dfx>;
> + };
> + };
> + };
> +};
> +
> +&pinctrl {
> + compatible = "marvell,98dx3236-pinctrl";
> +
> + spi0_pins: spi0-pins {
> + marvell,pins = "mpp0", "mpp1",
> + "mpp2", "mpp3";
> + marvell,function = "spi0";
> + };
> +};
> +
> +&sdio {
> + status = "disabled";
> +};
> +
> +&crypto_sram0 {
> + status = "disabled";
> +};
> +
> +&crypto_sram1 {
> + status = "disabled";
> +};
> diff --git a/arch/arm/boot/dts/armada-xp-98dx3336.dtsi b/arch/arm/boot/dts/armada-xp-98dx3336.dtsi
> new file mode 100644
> index 000000000000..e1580afdc260
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-xp-98dx3336.dtsi
> @@ -0,0 +1,76 @@
> +/*
> + * Device Tree Include file for Marvell 98dx3336 family SoC
> + *
> + * Copyright (C) 2016 Allied Telesis Labs
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * Contains definitions specific to the 98dx3236 SoC that are not
> + * common to all Armada XP SoCs.
> + */
> +
> +#include "armada-xp-98dx3236.dtsi"
> +
> +/ {
> + model = "Marvell 98DX3336 SoC";
> + compatible = "marvell,armadaxp-98dx3336", "marvell,armadaxp-98dx3236", "marvell,armadaxp", "marvell,armada-370-xp";
> +
> + cpus {
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "marvell,sheeva-v7";
> + reg = <1>;
> + clocks = <&cpuclk 1>;
> + clock-latency = <1000000>;
> + };
> + };
> +
> + soc {
> + internal-regs {
> + resume@20980 {
> + compatible = "marvell,98dx3336-resume-ctrl";
> + reg = <0x20980 0x10>;
> + };
> + };
> + };
> +};
> +
> +&pp0 {
> + compatible = "marvell,prestera-98dx3336";
> +};
> diff --git a/arch/arm/boot/dts/armada-xp-98dx4251.dtsi b/arch/arm/boot/dts/armada-xp-98dx4251.dtsi
> new file mode 100644
> index 000000000000..4b0533a4ccb7
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-xp-98dx4251.dtsi
> @@ -0,0 +1,90 @@
> +/*
> + * Device Tree Include file for Marvell 98dx4521 family SoC
> + *
> + * Copyright (C) 2016 Allied Telesis Labs
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * Contains definitions specific to the 98dx4521 SoC that are not
> + * common to all Armada XP SoCs.
> + */
> +
> +#include "armada-xp-98dx3236.dtsi"
> +
> +/ {
> + model = "Marvell 98DX4251 SoC";
> + compatible = "marvell,armadaxp-98dx4521", "marvell,armadaxp-98dx3236", "marvell,armadaxp", "marvell,armada-370-xp";
> +
> + cpus {
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "marvell,sheeva-v7";
> + reg = <1>;
> + clocks = <&cpuclk 1>;
> + clock-latency = <1000000>;
> + };
> + };
> +
> + soc {
> + internal-regs {
> + resume@20980 {
> + compatible = "marvell,98dx3336-resume-ctrl";
> + reg = <0x20980 0x10>;
> + };
> + };
> + };
> +};
> +
> +&sdio {
> + status = "okay";
> +};
> +
> +&pinctrl {
> + compatible = "marvell,98dx4251-pinctrl";
> +
> + sdio_pins: sdio-pins {
> + marvell,pins = "mpp5", "mpp6", "mpp7",
> + "mpp8", "mpp9", "mpp10";
> + marvell,function = "sd0";
> + };
> +};
> +
> +&pp0 {
> + compatible = "marvell,prestera-98dx4251";
> +};
> --
> 2.11.0.24.ge6920cf
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH net-next v2 2/2] qede: Add driver support for PTP.
From: David Laight @ 2017-01-30 14:34 UTC (permalink / raw)
To: 'Richard Cochran', Sudarsana Kalluru
Cc: davem@davemloft.net, netdev@vger.kernel.org,
Yuval.Mintz@cavium.com
In-Reply-To: <20170129153536.GD2223@localhost.localdomain>
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Richard Cochran
> Sent: 29 January 2017 15:36
...
> > +static int qede_ptp_adjfreq(struct ptp_clock_info *info, s32 ppb)
> > +{
> > + struct qede_ptp *ptp = container_of(info, struct qede_ptp, clock_info);
> > + struct qede_dev *edev = ptp->edev;
> > + int rc;
> > +
> > + __qede_lock(edev);
> > + if (edev->state == QEDE_STATE_OPEN) {
> > + spin_lock_bh(&ptp->lock);
> > + rc = ptp->ops->adjfreq(edev->cdev, ppb);
>
> Why add this extra layer of indirection?
There might be two extra layers of indirection!
One can be removed by copying the function vector instead of referencing it.
So that call would be ptp->ops.adjfreq(...).
Even from the later emails I can't see which way around that call is.
How many different implementations of 'ops->adjfreq' are there?
If there is only one you don't need an indirect call.
David
^ permalink raw reply
* Re: [PATCHv2 RFC net-next 0/7] net: dst_confirm replacement
From: David Miller @ 2017-01-30 15:13 UTC (permalink / raw)
To: ja; +Cc: netdev, linux-sctp, yuehaibing
In-Reply-To: <1485613578-19973-1-git-send-email-ja@ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Sat, 28 Jan 2017 16:26:11 +0200
> This patchset addresses the problem of neighbour
> confirmation where received replies from one nexthop
> can cause confirmation of different nexthop when using
> the same dst. Thanks to YueHaibing <yuehaibing@huawei.com>
> for tracking the dst->pending_confirm problem.
>
> Sockets can obtain cached output route. Such
> routes can be to known nexthop (rt_gateway=IP) or to be
> used simultaneously for different nexthop IPs by different
> subnet prefixes (nh->nh_scope = RT_SCOPE_HOST, rt_gateway=0).
>
> At first look, there are more problems:
>
> - dst_confirm() sets flag on dst and not on dst->path,
> as result, indication is lost when XFRM is used
>
> - DNAT can change the nexthop, so the really used nexthop is
> not confirmed
>
> So, the following solution is to avoid using
> dst->pending_confirm.
For the most part this series looks good to me, nice work.
> - I failed to understand the CXGB* code, I see dst_confirm()
> calls but I'm not sure dst_neigh_output() was called. For now
> I just removed the dst->pending_confirm flag and left all
> dst_confirm() calls there. Any better idea?
It is trying to manage the dst and neigh state for TCP connections
managed by it's offload engine. So you will not therefore see any
actual packet output for the sessions it is performing confirmation
for.
^ permalink raw reply
* Re: [PATCH net] net: ethtool: add support for 2500BaseT and 5000BaseT link modes
From: David Miller @ 2017-01-30 15:14 UTC (permalink / raw)
To: pavel.s.belous; +Cc: netdev, decot, linux-kernel
In-Reply-To: <1485633208-2012-1-git-send-email-pavel.s.belous@gmail.com>
From: Pavel Belous <pavel.s.belous@gmail.com>
Date: Sat, 28 Jan 2017 22:53:28 +0300
> This patch introduce support for 2500BaseT and 5000BaseT link modes.
> These modes are included in the new IEEE 802.3bz standard.
>
> Signed-off-by: Pavel Belous <pavel.s.belous@gmail.com>
Applied.
^ permalink raw reply
* fou: udp encapsulation - how to configure multiple ports per tunnel
From: Mihail Dakov @ 2017-01-30 14:52 UTC (permalink / raw)
To: netdev
[-- Attachment #1.1: Type: text/plain, Size: 802 bytes --]
Hi there,
I am having trouble setting up the following tunnels on the tx path.
#!/bin/bash
sudo ip link add name fou11 \
type ipip \
remote 192.168.1.1 \
local 192.168.2.1 \
encap fou \
encap-sport 21001 \
encap-dport 21001
sudo ip link add name fou21 \
type ipip \
remote 192.168.1.1 \
local 192.168.2.1 \
encap fou \
encap-sport 21002 \
encap-dport 21002
this script returns:
RTNETLINK answers: File exists
which tells me that the kernel doesn't use sport and/or dport to
identify a tunnel.
Is it possible to configure a tunnel with different dport and/or sport?
If so how?
P.S. On the other hand if this was possible then the kernel would need
some policy to decide which dport and/or sport to use for each packet
arriving in this tunnel.
br,md.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH net] net/sched: cls_flower: Correct matching on ICMPv6 code
From: Simon Horman @ 2017-01-30 15:19 UTC (permalink / raw)
To: David Miller; +Cc: Dinan Gunawardena, netdev, oss-drivers, Simon Horman
When matching on the ICMPv6 code ICMPV6_CODE rather than
ICMPV4_CODE attributes should be used.
This corrects what appears to be a typo.
Sample usage:
tc qdisc add dev eth0 ingress
tc filter add dev eth0 protocol ipv6 parent ffff: flower \
indev eth0 ip_proto icmpv6 type 128 code 0 action drop
Without this change the code parameter above is effectively ignored.
Fixes: 7b684884fbfa ("net/sched: cls_flower: Support matching on ICMP type and code")
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
net/sched/cls_flower.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index 970db7a41684..5752789acc13 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -568,9 +568,9 @@ static int fl_set_key(struct net *net, struct nlattr **tb,
&mask->icmp.type,
TCA_FLOWER_KEY_ICMPV6_TYPE_MASK,
sizeof(key->icmp.type));
- fl_set_key_val(tb, &key->icmp.code, TCA_FLOWER_KEY_ICMPV4_CODE,
+ fl_set_key_val(tb, &key->icmp.code, TCA_FLOWER_KEY_ICMPV6_CODE,
&mask->icmp.code,
- TCA_FLOWER_KEY_ICMPV4_CODE_MASK,
+ TCA_FLOWER_KEY_ICMPV6_CODE_MASK,
sizeof(key->icmp.code));
}
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* Re: [PATCH net-next v3 0/4] net: ipv6: Improve user experience with multipath routes
From: David Ahern @ 2017-01-30 15:23 UTC (permalink / raw)
To: nicolas.dichtel, Roopa Prabhu; +Cc: netdev
In-Reply-To: <8f5334f0-20a3-0eb2-6baa-1fe8331ad2db@6wind.com>
On 1/30/17 4:07 AM, Nicolas Dichtel wrote:
> Le 29/01/2017 à 19:02, David Ahern a écrit :
> [snip]
>> Data centers are moving to L3, and multipath is a big part of that. Anyone who looks at ip -6 route enough knows it gets painful mentally pulling the individual routes into a single one.
> I agree, but it's only an iproute2 problem. iproute2 could group routes to have
> a better output, there is no need to have a kernel patch for this ;-)
>
iproute2 is not the only rtnetlink user. The comment above uses ip show as an example. libnl has a workaround for IPv6 to update route objects versus replacing them - unnecessary complexity that does not need to replicated to iproute2, Quagga/FRR or python libraries implementing rtnetlink. Really, RTA_MULTIPATH support in notifications should have been added when multipath support was added to the IPv6. Patch 3 is mostly a refactoring of rt6_fill_node to fill in nexthop information. This could have been done 4+ years ago when RTA_MULTIPATH route adds was added to the stack.
^ permalink raw reply
* RE: [PATCH net-next V3 5/8] net/mlx4_en: Adding support of turning off link autonegotiation via ethtool
From: David Laight @ 2017-01-30 14:00 UTC (permalink / raw)
To: 'Tariq Toukan', David S. Miller
Cc: netdev@vger.kernel.org, Eran Ben Elisha, Ariel Levkovich
In-Reply-To: <1485708980-23468-6-git-send-email-tariqt@mellanox.com>
From: Tariq Toukan
> Sent: 29 January 2017 16:56
> From: Ariel Levkovich <lariel@mellanox.com>
>
> This feature will allow the user to disable auto negotiation
> on the port for mlx4 devices while setting the speed is limited
> to 1GbE speeds.
> Other speeds will not be accepted in autoneg off mode.
What is the rationale behind this change?
When I was writing ethernet drivers it was always better to
leave autonegotiation enabled with restricted modes than to
fix the speed.
That ensures that far end is using the same mode.
This was particularly important for FDX v HDX at 10/100 speeds,
but I suspect it is equally relevant now.
David
^ permalink raw reply
* Re: [PATCH net-next v3 0/4] net: ipv6: Improve user experience with multipath routes
From: Roopa Prabhu @ 2017-01-30 15:45 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: David Ahern, netdev
In-Reply-To: <7a7dcae4-a01b-3217-3296-b0aa2c7052f3@6wind.com>
On 1/30/17, 3:08 AM, Nicolas Dichtel wrote:
> Le 30/01/2017 à 00:55, Roopa Prabhu a écrit :
>> On 1/29/17, 10:02 AM, David Ahern wrote:
>>> On 1/28/17 6:00 PM, Roopa Prabhu wrote:
>>>>> 4. Route Appends
>>>>> - IPv6 allows nexthops to be appended to an existing route. In this
>>>>> case one notification is sent per nexthop added
>>>> thanks for listing all of these...I think you mentioned this case to me..
>>>> but I don't remember now why this notification is
>>>> sent per nexthop added. This is an update to an existing multipath route.
>>>> so seems like the notification should be a RTM_NEWROUTE with the full RTA_MULTIPATH route
>>>> (similar to route add)
>>> It could be; it's a question of what should userspace get -- the full route or the change? Append to me suggests the latter - userspace is told what changed. It is simpler kernel code wise to send the full new route. The append changes were done after our conversation. ;-)
>> ok, yeah. you listing all the cases here made it more simpler to understand in the context of other notifications :). I would prefer all
>> RTM_NEWLINK notifications (ie new add or update to an existing route..replace/append), contain the full route via RTA_MULTIPATH.
> I don't agree. With the previous proposal, you know *exactly* what happens with
> each notification and this is the primary goal of the notifications. With the
> last proposal, where RTA_MULTIPATH is used for replace and append, you have the
> new result, but you don't know what has been done.
> Usually, notifications are used to notify an event, not the result of an event.
> If you want the result, you can use the dump cmd.
what has been done is conveyed by the APPEND and REPLACE flag in the notification. The user only cares about the updated multipath route...
giving parts of the route has never been very useful... and this is consistent with ipv4.
^ permalink raw reply
* Re: [PATCH net-next v3 0/4] net: ipv6: Improve user experience with multipath routes
From: Roopa Prabhu @ 2017-01-30 15:49 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, nicolas.dichtel
In-Reply-To: <5be4a78e-64b8-abc4-4015-6751a2bab12b@cumulusnetworks.com>
On 1/29/17, 6:57 PM, David Ahern wrote:
> On 1/29/17 7:20 PM, Roopa Prabhu wrote:
>>> 2. Delete - 1 notification for each hop for all combinations of delete commands
>> here I was trying to say, for people deleting the full multipath route, you should send a RTA_MULTIPATH.
> The only way to do that is to call inet6_rt_notify() *before* the route delete work has been done in fib6_del_route. Right now it is called at the end - after all sibling associations have been dropped, a time in which it can no longer fill in RTA_MULTIPATH.
>
> fib6_del_route function does not have any failure paths and is called with the write lock held, so moving the notification might be ok. But it also means ignoring all subsequent failures from fib6_del, again which might be ok since the only failure is ENOENT which can not happen if we are walking the sibling list.
>
>
>> For the odd case of ipv6 single nexthop delete, you can continue to send a single nexthop delete (like today ..without RTA_MULTIPATH)
>> because there is no other way to notify a single nexthop delete with a RTM_DELROUTE.
>>
>> The reason I say this is because: keeping future in mind, this will make things consistent for majority of people who will
>> start using RTA_MULTIPATH for both ipv4 and ipv6 for adds and deletes (requests/notifications and dumps) the same way.
>> single next hop delete will just be around because of fear of breaking existing applications.
> Single next hop delete will be around because IPv6 allows it -- and because IPv4 needs to support it.
>
understand single next hop delete for ipv6 will be around..and my only point was to leave it around but not optimize for that case.
I don't think we should support single nexthop delete in ipv4 (I have not seen a requirement for that)... ipv4 is good as it is right now.
the additional complexity is not needed.
^ permalink raw reply
* Re: [PATCH net] mlx4: xdp_prog becomes inactive after ethtool '-L' or '-G'
From: David Miller @ 2017-01-30 14:56 UTC (permalink / raw)
To: kafai; +Cc: netdev, bblanco, saeedm, tariqt, kernel-team
In-Reply-To: <1485589251-3896393-1-git-send-email-kafai@fb.com>
From: Martin KaFai Lau <kafai@fb.com>
Date: Fri, 27 Jan 2017 23:40:51 -0800
> If the rx-queues ever get re-initialized (e.g. by changing the
> number of rx-queues with ethtool -L), the existing xdp_prog becomes
> inactive.
>
> The bug is that the xdp_prog ptr has not been carried over from
> the old rx-queues to the new rx-queues
>
> Fixes: 47a38e155037 ("net/mlx4_en: add support for fast rx drop bpf program")
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Mellanox folks, please review.
^ permalink raw reply
* Re: [PATCHv2 RFC net-next 3/7] sctp: add dst_pending_confirm flag
From: Neil Horman @ 2017-01-30 14:45 UTC (permalink / raw)
To: Julian Anastasov; +Cc: netdev, linux-sctp, YueHaibing
In-Reply-To: <1485613578-19973-4-git-send-email-ja@ssi.bg>
On Sat, Jan 28, 2017 at 04:26:14PM +0200, Julian Anastasov wrote:
> Add new transport flag to allow sockets to confirm neighbour.
> When same struct dst_entry can be used for many different
> neighbours we can not use it for pending confirmations.
> The flag is propagated from transport to every packet.
> It is reset when cached dst is reset.
>
> Reported-by: YueHaibing <yuehaibing@huawei.com>
> Fixes: 5110effee8fd ("net: Do delayed neigh confirmation.")
> Fixes: f2bb4bedf35d ("ipv4: Cache output routes in fib_info nexthops.")
> Signed-off-by: Julian Anastasov <ja@ssi.bg>
> ---
> include/net/sctp/sctp.h | 6 ++----
> include/net/sctp/structs.h | 4 ++++
> net/sctp/associola.c | 3 +--
> net/sctp/output.c | 10 +++++++++-
> net/sctp/outqueue.c | 2 +-
> net/sctp/sm_make_chunk.c | 6 ++----
> net/sctp/sm_sideeffect.c | 2 +-
> net/sctp/socket.c | 4 ++--
> net/sctp/transport.c | 17 ++++++++++++++++-
> 9 files changed, 38 insertions(+), 16 deletions(-)
>
> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
> index 3cfd365b..480b65a 100644
> --- a/include/net/sctp/sctp.h
> +++ b/include/net/sctp/sctp.h
> @@ -593,10 +593,8 @@ static inline void sctp_v4_map_v6(union sctp_addr *addr)
> */
> static inline struct dst_entry *sctp_transport_dst_check(struct sctp_transport *t)
> {
> - if (t->dst && !dst_check(t->dst, t->dst_cookie)) {
> - dst_release(t->dst);
> - t->dst = NULL;
> - }
> + if (t->dst && !dst_check(t->dst, t->dst_cookie))
> + sctp_transport_dst_release(t);
>
> return t->dst;
> }
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index 231fa9ac..6a68504 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -804,6 +804,8 @@ struct sctp_transport {
>
> __u32 burst_limited; /* Holds old cwnd when max.burst is applied */
>
> + __u32 dst_pending_confirm; /* need to confirm neighbour */
> +
> /* Destination */
> struct dst_entry *dst;
> /* Source address. */
> @@ -950,6 +952,8 @@ void sctp_transport_route(struct sctp_transport *, union sctp_addr *,
> void sctp_transport_reset(struct sctp_transport *);
> void sctp_transport_update_pmtu(struct sock *, struct sctp_transport *, u32);
> void sctp_transport_immediate_rtx(struct sctp_transport *);
> +void sctp_transport_dst_release(struct sctp_transport *t);
> +void sctp_transport_dst_confirm(struct sctp_transport *t);
>
>
> /* This is the structure we use to queue packets as they come into
> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
> index e50dc6d..2a6835b 100644
> --- a/net/sctp/associola.c
> +++ b/net/sctp/associola.c
> @@ -832,8 +832,7 @@ void sctp_assoc_control_transport(struct sctp_association *asoc,
> if (transport->state != SCTP_UNCONFIRMED)
> transport->state = SCTP_INACTIVE;
> else {
> - dst_release(transport->dst);
> - transport->dst = NULL;
> + sctp_transport_dst_release(transport);
> ulp_notify = false;
> }
>
> diff --git a/net/sctp/output.c b/net/sctp/output.c
> index 07ab506..814eac0 100644
> --- a/net/sctp/output.c
> +++ b/net/sctp/output.c
> @@ -546,6 +546,7 @@ int sctp_packet_transmit(struct sctp_packet *packet, gfp_t gfp)
> struct sctp_association *asoc = tp->asoc;
> struct sctp_chunk *chunk, *tmp;
> int pkt_count, gso = 0;
> + int confirm;
> struct dst_entry *dst;
> struct sk_buff *head;
> struct sctphdr *sh;
> @@ -624,7 +625,14 @@ int sctp_packet_transmit(struct sctp_packet *packet, gfp_t gfp)
> asoc->peer.last_sent_to = tp;
> }
> head->ignore_df = packet->ipfragok;
> - tp->af_specific->sctp_xmit(head, tp);
> + confirm = tp->dst_pending_confirm;
> + if (confirm)
> + skb_set_dst_pending_confirm(head, 1);
> + /* neighbour should be confirmed on successful transmission or
> + * positive error
> + */
> + if (tp->af_specific->sctp_xmit(head, tp) >= 0 && confirm)
> + tp->dst_pending_confirm = 0;
>
> out:
> list_for_each_entry_safe(chunk, tmp, &packet->chunk_list, list) {
> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
> index 65abe22..db352e5 100644
> --- a/net/sctp/outqueue.c
> +++ b/net/sctp/outqueue.c
> @@ -1654,7 +1654,7 @@ static void sctp_check_transmitted(struct sctp_outq *q,
>
> if (forward_progress) {
> if (transport->dst)
> - dst_confirm(transport->dst);
> + sctp_transport_dst_confirm(transport);
> }
> }
>
> diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
> index ad3445b..c7d3249 100644
> --- a/net/sctp/sm_make_chunk.c
> +++ b/net/sctp/sm_make_chunk.c
> @@ -3333,8 +3333,7 @@ static void sctp_asconf_param_success(struct sctp_association *asoc,
> local_bh_enable();
> list_for_each_entry(transport, &asoc->peer.transport_addr_list,
> transports) {
> - dst_release(transport->dst);
> - transport->dst = NULL;
> + sctp_transport_dst_release(transport);
> }
> break;
> case SCTP_PARAM_DEL_IP:
> @@ -3348,8 +3347,7 @@ static void sctp_asconf_param_success(struct sctp_association *asoc,
> local_bh_enable();
> list_for_each_entry(transport, &asoc->peer.transport_addr_list,
> transports) {
> - dst_release(transport->dst);
> - transport->dst = NULL;
> + sctp_transport_dst_release(transport);
> }
> break;
> default:
> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
> index a455271..51abcc9 100644
> --- a/net/sctp/sm_sideeffect.c
> +++ b/net/sctp/sm_sideeffect.c
> @@ -755,7 +755,7 @@ static void sctp_cmd_transport_on(sctp_cmd_seq_t *cmds,
> * forward progress.
> */
> if (t->dst)
> - dst_confirm(t->dst);
> + sctp_transport_dst_confirm(t);
>
> /* The receiver of the HEARTBEAT ACK should also perform an
> * RTT measurement for that destination transport address
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index d699d2c..9e98c87 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -588,7 +588,7 @@ static int sctp_send_asconf_add_ip(struct sock *sk,
> list_for_each_entry(trans,
> &asoc->peer.transport_addr_list, transports) {
> /* Clear the source and route cache */
> - dst_release(trans->dst);
> + sctp_transport_dst_release(trans);
> trans->cwnd = min(4*asoc->pathmtu, max_t(__u32,
> 2*asoc->pathmtu, 4380));
> trans->ssthresh = asoc->peer.i.a_rwnd;
> @@ -839,7 +839,7 @@ static int sctp_send_asconf_del_ip(struct sock *sk,
> */
> list_for_each_entry(transport, &asoc->peer.transport_addr_list,
> transports) {
> - dst_release(transport->dst);
> + sctp_transport_dst_release(transport);
> sctp_transport_route(transport, NULL,
> sctp_sk(asoc->base.sk));
> }
> diff --git a/net/sctp/transport.c b/net/sctp/transport.c
> index baa1ac0..df274ff 100644
> --- a/net/sctp/transport.c
> +++ b/net/sctp/transport.c
> @@ -240,7 +240,7 @@ void sctp_transport_pmtu(struct sctp_transport *transport, struct sock *sk)
> {
> /* If we don't have a fresh route, look one up */
> if (!transport->dst || transport->dst->obsolete) {
> - dst_release(transport->dst);
> + sctp_transport_dst_release(transport);
> transport->af_specific->get_dst(transport, &transport->saddr,
> &transport->fl, sk);
> }
> @@ -672,3 +672,18 @@ void sctp_transport_immediate_rtx(struct sctp_transport *t)
> sctp_transport_hold(t);
> }
> }
> +
> +/* Drop dst */
> +void sctp_transport_dst_release(struct sctp_transport *t)
> +{
> + dst_release(t->dst);
> + t->dst = NULL;
> + t->dst_pending_confirm = 0;
> +}
> +
> +/* Schedule neighbour confirm */
> +void sctp_transport_dst_confirm(struct sctp_transport *t)
> +{
> + t->dst_pending_confirm = 1;
> +}
> +
> --
> 1.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
For the SCTP bits:
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH net-next v3 0/4] net: ipv6: Improve user experience with multipath routes
From: David Ahern @ 2017-01-30 15:59 UTC (permalink / raw)
To: nicolas.dichtel, Roopa Prabhu; +Cc: netdev
In-Reply-To: <ef322f4a-07d7-31af-b402-769b0f446fc7@6wind.com>
On 1/30/17 4:13 AM, Nicolas Dichtel wrote:
> Le 30/01/2017 à 03:57, David Ahern a écrit :
>> On 1/29/17 7:20 PM, Roopa Prabhu wrote:
>>>> 2. Delete - 1 notification for each hop for all combinations of delete commands
>>>
>>> here I was trying to say, for people deleting the full multipath route, you should send a RTA_MULTIPATH.
>>
>> The only way to do that is to call inet6_rt_notify() *before* the route delete work has been done in fib6_del_route. Right now it is called at the end - after all sibling associations have been dropped, a time in which it can no longer fill in RTA_MULTIPATH.
>>
>> fib6_del_route function does not have any failure paths and is called with the write lock held, so moving the notification might be ok. But it also means ignoring all subsequent failures from fib6_del, again which might be ok since the only failure is ENOENT which can not happen if we are walking the sibling list.
> Is it not possible to prepare the RTA_MULTIPATH attribute during the deletion
> (when needed information are still available) and to use/copy it later when the
> notification is done?
What I outlined above has the least complexity and does not require copies. And it is only proper for the 1 case where a multipath route is deleted by prefix and length -- the ability enabled by Patch 2.
>
> Or at least, having RTA_MUTLTIPATH with one nexthop only, so that the user knows
> that this route was part of an ECMP routes?
>
For the ip6_route_multipath_del path, sure the nexthops deleted can be wrapped in RTA_MULTIPATH if the nexthop indeed has siblings, but does it help userspace? If all attributes outside of the nexthops are identical, then userspace would match the route without it.
^ permalink raw reply
* Re: [PATCH V2 3/3] net: bgmac: use PHY subsystem for initializing PHY
From: Jon Mason @ 2017-01-30 16:07 UTC (permalink / raw)
To: Florian Fainelli
Cc: Rafał Miłecki, David S . Miller, Felix Fietkau,
Network Development, Rafał Miłecki
In-Reply-To: <08f74e19-f9b2-a0ea-ee21-d35cbdf6ee76@gmail.com>
On Sat, Jan 28, 2017 at 10:08 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>
> On 01/28/2017 01:08 PM, Rafał Miłecki wrote:
>> From: Rafał Miłecki <rafal@milecki.pl>
>>
>> This adds support for using bgmac with PHYs supported by standalone PHY
>> drivers. Having any PHY initialization in bgmac is hacky and shouldn't
>> be extended but rather removed if anyone has hardware to test it.
>>
>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>> ---
>> drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c b/drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c
>> index 9d9984999dce..6ce80cbcb48e 100644
>> --- a/drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c
>> +++ b/drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c
>> @@ -132,6 +132,10 @@ static void bcma_mdio_phy_init(struct bgmac *bgmac)
>> struct bcma_chipinfo *ci = &bgmac->bcma.core->bus->chipinfo;
>> u8 i;
>>
>> + /* For some legacy hardware we do chipset-based PHY initialization here
>> + * without even detecting PHY ID. It's hacky and should be cleaned as
>> + * soon as someone can test it.
>> + */
>> if (ci->id == BCMA_CHIP_ID_BCM5356) {
>> for (i = 0; i < 5; i++) {
>> bcma_mdio_phy_write(bgmac, i, 0x1f, 0x008b);
>> @@ -140,6 +144,7 @@ static void bcma_mdio_phy_init(struct bgmac *bgmac)
>> bcma_mdio_phy_write(bgmac, i, 0x12, 0x2aaa);
>> bcma_mdio_phy_write(bgmac, i, 0x1f, 0x000b);
>> }
>> + return;
>
> That part is clearly initializing the built-in Ethernet switch's PHYs,
> and so the natural place for that would be to stick these init values
> into the Broadcom PHY driver. When b53-srab/b53_common attaches the
> switch, it will scan all of these port's builtin PHYs and bind to an
> appropriate PHY driver which could have this initialization as part of
> the config_init routine for instance. Right now, we are most likely
> using the Generic PHY.
>
> Here are the different PHY IDs you should read from these models if you
> want to make a subsequent patch that moves this initialization down to
> the Broadcom PHY driver:
>
> 5356: 0x03625DA0
> 5357/53572: 0x03625F00
> 4749: could either be 0x600D85F0 or the same as 53010 (0x600D8760),
> unclear where that product came from... Jon, would you know by chance?
The 4749 I have has a switch chip (bcm53115, according to the
datasheet). So, I do not have any idea what PHYs this is referring
to.
> --
> Florian
^ permalink raw reply
* Re: [PATCH net-next v3 0/4] net: ipv6: Improve user experience with multipath routes
From: David Ahern @ 2017-01-30 16:12 UTC (permalink / raw)
To: Roopa Prabhu; +Cc: netdev, nicolas.dichtel
In-Reply-To: <588F607D.2050600@cumulusnetworks.com>
On 1/30/17 8:49 AM, Roopa Prabhu wrote:
>> Single next hop delete will be around because IPv6 allows it -- and because IPv4 needs to support it.
>>
> understand single next hop delete for ipv6 will be around..and my only point was to leave it around but not optimize for that case.
> I don't think we should support single nexthop delete in ipv4 (I have not seen a requirement for that)... ipv4 is good as it is right now.
> the additional complexity is not needed.
>
IPv4 has a known bug -- delete a virtual interface in a multihop route and the entire route is deleted, including the nexthops for other devices. This does not happen for IPv6.
Simple example of that bug:
ip li add dummy1 type dummy
ip li add dummy2 type dummy
ip addr add dev dummy1 10.11.1.1/28
ip li set dummy1 up
ip addr add dev dummy2 10.11.2.1/28
ip li set dummy2 up
ip ro add 1.1.1.0/24 nexthop via 10.11.1.2 nexthop via 10.11.2.2
ip li del dummy2
--> the entire multipath route has been deleted.
And, fixing this bug enables work to make IPv4 append to be sane -- appending a route should modify an existing route by adding the nexthop, not adding a new route that I believe can never actually be hit.
Both cases mean modifying an IPv4 route -- adding or removing nexthops -- a capability that IPv6 allows so fixing this means closing another difference between the stacks.
^ permalink raw reply
* Re: [PATCH 5/9] treewide: use kv[mz]alloc* rather than opencoded variants
From: Vlastimil Babka @ 2017-01-30 16:14 UTC (permalink / raw)
To: Michal Hocko, Andrew Morton
Cc: David Rientjes, Mel Gorman, Johannes Weiner, Al Viro, linux-mm,
LKML, Michal Hocko, Martin Schwidefsky, Heiko Carstens,
Herbert Xu, Anton Vorontsov, Colin Cross, Kees Cook, Tony Luck,
Rafael J. Wysocki, Ben Skeggs, Kent Overstreet, Santosh Raspatur,
Hariprasad S, Yishai Hadas, Oleg Drokin, Yan, Zheng,
Alexei Starovoitov, Eric Dumazet, net
In-Reply-To: <20170130094940.13546-6-mhocko@kernel.org>
On 01/30/2017 10:49 AM, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
>
> There are many code paths opencoding kvmalloc. Let's use the helper
> instead. The main difference to kvmalloc is that those users are usually
> not considering all the aspects of the memory allocator. E.g. allocation
> requests <= 32kB (with 4kB pages) are basically never failing and invoke
> OOM killer to satisfy the allocation. This sounds too disruptive for
> something that has a reasonable fallback - the vmalloc. On the other
> hand those requests might fallback to vmalloc even when the memory
> allocator would succeed after several more reclaim/compaction attempts
> previously. There is no guarantee something like that happens though.
>
> This patch converts many of those places to kv[mz]alloc* helpers because
> they are more conservative.
>
> Changes since v1
> - add kvmalloc_array - this might silently fix some overflow issues
> because most users simply didn't check the overflow for the vmalloc
> fallback.
>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: Anton Vorontsov <anton@enomsg.org>
> Cc: Colin Cross <ccross@android.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Tony Luck <tony.luck@intel.com>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: Kent Overstreet <kent.overstreet@gmail.com>
> Cc: Santosh Raspatur <santosh@chelsio.com>
> Cc: Hariprasad S <hariprasad@chelsio.com>
> Cc: Yishai Hadas <yishaih@mellanox.com>
> Cc: Oleg Drokin <oleg.drokin@intel.com>
> Cc: "Yan, Zheng" <zyan@redhat.com>
> Cc: Alexander Viro <viro@zeniv.linux.org.uk>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: netdev@vger.kernel.org
> Acked-by: Andreas Dilger <andreas.dilger@intel.com> # Lustre
> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> # Xen bits
> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> # KVM/s390
> Acked-by: Dan Williams <dan.j.williams@intel.com> # nvdim
> Acked-by: David Sterba <dsterba@suse.com> # btrfs
> Acked-by: Ilya Dryomov <idryomov@gmail.com> # Ceph
> Acked-by: Tariq Toukan <tariqt@mellanox.com> # mlx4
> Signed-off-by: Michal Hocko <mhocko@suse.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 0/6 v3] kvmalloc
From: Daniel Borkmann @ 2017-01-30 16:15 UTC (permalink / raw)
To: Michal Hocko
Cc: Alexei Starovoitov, Andrew Morton, Vlastimil Babka, Mel Gorman,
Johannes Weiner, linux-mm, LKML, netdev@vger.kernel.org,
marcelo.leitner
In-Reply-To: <20170130075626.GC8443@dhcp22.suse.cz>
On 01/30/2017 08:56 AM, Michal Hocko wrote:
> On Fri 27-01-17 21:12:26, Daniel Borkmann wrote:
>> On 01/27/2017 11:05 AM, Michal Hocko wrote:
>>> On Thu 26-01-17 21:34:04, Daniel Borkmann wrote:
> [...]
>>>> So to answer your second email with the bpf and netfilter hunks, why
>>>> not replacing them with kvmalloc() and __GFP_NORETRY flag and add that
>>>> big fat FIXME comment above there, saying explicitly that __GFP_NORETRY
>>>> is not harmful though has only /partial/ effect right now and that full
>>>> support needs to be implemented in future. That would still be better
>>>> that not having it, imo, and the FIXME would make expectations clear
>>>> to anyone reading that code.
>>>
>>> Well, we can do that, I just would like to prevent from this (ab)use
>>> if there is no _real_ and _sensible_ usecase for it. Having a real bug
>>
>> Understandable.
>>
>>> report or a fallback mechanism you are mentioning above would justify
>>> the (ab)use IMHO. But that abuse would be documented properly and have a
>>> real reason to exist. That sounds like a better approach to me.
>>>
>>> But if you absolutely _insist_ I can change that.
>>
>> Yeah, please do (with a big FIXME comment as mentioned), this originally
>> came from a real bug report. Anyway, feel free to add my Acked-by then.
>
> Thanks! I will repost the whole series today.
Looks like I got only Cc'ed on the cover letter of your v3 from today
(should have been v4 actually?). Anyway, I looked up the last patch
on lkml [1] and it seems you forgot the __GFP_NORETRY we talked about?
At least that was what was discussed above (insisting on __GFP_NORETRY
plus FIXME comment) for providing my Acked-by then. Can you still fix
that up in a final respin?
Thanks again,
Daniel
[1] https://lkml.org/lkml/2017/1/30/129
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v2 0/3] sh_eth: E-DMAC interrupt mask cleanups
From: David Miller @ 2017-01-30 16:18 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, linux-renesas-soc
In-Reply-To: <3387005.NzsGXf10rT@wasted.cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Sun, 29 Jan 2017 15:06:39 +0300
> Here's a set of 3 patches against DaveM's 'net-next.git' repo. The main goal
> of this set is to stop using the bare numbers for the E-DMAC interrupt masks.
>
> [1/3] sh_eth: rename EESIPR bits
> [2/3] sh_eth: add missing EESIPR bits
> [3/3] sh_eth: stop using bare numbers for EESIPR values
Series applied, thank you.
^ 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