* Re: [PATCH iproute2] ip route: don't assume default route
From: Stephen Hemminger @ 2014-12-03 17:17 UTC (permalink / raw)
To: Pavel Šimerda; +Cc: netdev
In-Reply-To: <20141202164510.GA9005@mole.pavlix.net>
On Tue, 2 Dec 2014 17:45:10 +0100
=?UTF-8?q?Pavel=20=C5=A0imerda?= <psimerda@redhat.com> wrote:
> Just print the help when "ip route del" is called without any other
> arguments.
>
> Resolves:
>
> * https://bugzilla.redhat.com/show_bug.cgi?id=997965
>
> Signed-off-by: Pavel Šimerda <psimerda@redhat.com>
> ---
> ip/iproute.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/ip/iproute.c b/ip/iproute.c
> index d77b1e3..c171f29 100644
> --- a/ip/iproute.c
> +++ b/ip/iproute.c
> @@ -975,6 +975,9 @@ static int iproute_modify(int cmd, unsigned flags, int argc, char **argv)
> argc--; argv++;
> }
>
> + if (!dst_ok)
> + usage();
> +
> if (d || nhs_ok) {
> int idx;
>
Good catch. Applied
^ permalink raw reply
* Re: [PATCH iproute2] man ip-link: Fix indentation for 'ip link show' options
From: Stephen Hemminger @ 2014-12-03 17:18 UTC (permalink / raw)
To: Vadim Kochan; +Cc: netdev
In-Reply-To: <1417552751-3132-1-git-send-email-vadim4j@gmail.com>
On Tue, 2 Dec 2014 22:39:11 +0200
Vadim Kochan <vadim4j@gmail.com> wrote:
> BEFORE:
> The show command has additional formatting options:
>
> -s, -stats, -statistics
> output more statistics about packet usage.
>
> -d, -details
> output more detailed information.
>
> -h, -human, -human-readble
> output statistics with human readable values number followed by suffix
>
> -iec print human readable rates in IEC units (ie. 1K = 1024).
> AFTER:
> The show command has additional formatting options:
>
> -s, -stats, -statistics
> output more statistics about packet usage.
>
> -d, -details
> output more detailed information.
>
> -h, -human, -human-readble
> output statistics with human readable values number followed by suffix
>
> -iec print human readable rates in IEC units (ie. 1K = 1024).
>
> Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
> ---
> man/man8/ip-link.8.in | 3 +++
> 1 file changed, 3 insertions(+)
Applied
^ permalink raw reply
* Re: [PATCH iproute2] ip monitor: Fixed printing timestamp few times
From: vadim4j @ 2014-12-03 17:11 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20141203091338.2d32de2c@urahara>
On Wed, Dec 03, 2014 at 09:13:38AM -0800, Stephen Hemminger wrote:
> I don't see how you could get into accept_msg and cause this.
>
> The filtering should already be done by kernel for most things.
> The code already filters TC messages in kernel. Other types
> should be done as well.
I think it was caused by RTM_NEWNDUSEROPT which was sent by router.
So in this case the message will be skipped with printed timestamp.
> Ps: this code is crying to be a switch statement.
I agree.
^ permalink raw reply
* Re: [PATCH iproute2] ss: Use rtnl_dump_filter in handle_netlink_request
From: Stephen Hemminger @ 2014-12-03 17:21 UTC (permalink / raw)
To: Vadim Kochan; +Cc: netdev
In-Reply-To: <1417531984-3522-1-git-send-email-vadim4j@gmail.com>
On Tue, 2 Dec 2014 16:53:04 +0200
Vadim Kochan <vadim4j@gmail.com> wrote:
> Replaced handling netlink messages by rtnl_dump_filter
> from lib/libnetlink.c, also:
>
> - removed unused dump_fp arg;
> - added MAGIC_SEQ #define for 123456 seq id
>
> Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
This doesn't work correctly.
Simple test
$ misc/ss >/dev/null
RTNETLINK answers: No such file or directory
RTNETLINK answers: No such file or directory
RTNETLINK answers: No such file or directory
^ permalink raw reply
* Re: [PATCH v2] iproute2: Refactor: using new nl_msg struct for the all Netlink handlers
From: Stephen Hemminger @ 2014-12-03 17:23 UTC (permalink / raw)
To: Vadim Kochan; +Cc: netdev
In-Reply-To: <1409913328-9003-1-git-send-email-vadim4j@gmail.com>
On Fri, 5 Sep 2014 13:35:28 +0300
Vadim Kochan <vadim4j@gmail.com> wrote:
> It will easy to extend with new parameters in future.
>
> Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
This is a big change and not needed yet. Please hold off refactoring until the
new parameters are actually needed.
^ permalink raw reply
* Re: [PATCH iproute2] ss: Use rtnl_dump_filter in handle_netlink_request
From: vadim4j @ 2014-12-03 17:20 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20141203092129.49f16769@urahara>
On Wed, Dec 03, 2014 at 09:21:29AM -0800, Stephen Hemminger wrote:
> On Tue, 2 Dec 2014 16:53:04 +0200
> Vadim Kochan <vadim4j@gmail.com> wrote:
>
> > Replaced handling netlink messages by rtnl_dump_filter
> > from lib/libnetlink.c, also:
> >
> > - removed unused dump_fp arg;
> > - added MAGIC_SEQ #define for 123456 seq id
> >
> > Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
>
> This doesn't work correctly.
>
> Simple test
> $ misc/ss >/dev/null
> RTNETLINK answers: No such file or directory
> RTNETLINK answers: No such file or directory
> RTNETLINK answers: No such file or directory
Just tried, I did not get such errors.
^ permalink raw reply
* [PATCH net-next] tc_act: export uapi header file
From: Stephen Hemminger @ 2014-12-03 17:33 UTC (permalink / raw)
To: Jiri Pirko, Jamal Hadi Salim, David Miller; +Cc: netdev
This file is used by iproute2 and should be exported.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--- a/include/uapi/linux/tc_act/Kbuild 2014-02-12 08:21:56.614859066 -0800
+++ b/include/uapi/linux/tc_act/Kbuild 2014-12-03 09:31:10.619225148 -0800
@@ -7,3 +7,4 @@ header-y += tc_mirred.h
header-y += tc_nat.h
header-y += tc_pedit.h
header-y += tc_skbedit.h
+header-y += tc_vlan.h
^ permalink raw reply
* Re: [PATCH v2 4/7] fs/proc/task_mmu.c: shift mm_access() from m_start() to proc_maps_open()
From: Oleg Nesterov @ 2014-12-03 17:34 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: David S. Miller, Linus Torvalds, Andrew Morton, Alexander Viro,
Cyrill Gorcunov, David Howells, Eric W. Biederman,
Kirill A. Shutemov, Peter Zijlstra, Sasha Levin, linux-fsdevel,
linux-kernel, Alexey Dobriyan, netdev
In-Reply-To: <20141203141433.GA25683@node.dhcp.inet.fi>
On 12/03, Kirill A. Shutemov wrote:
>
> On Tue, Aug 05, 2014 at 09:46:55PM +0200, Oleg Nesterov wrote:
> > A simple test-case from Kirill Shutemov
> >
> > cat /proc/self/maps >/dev/null
> > chmod +x /proc/self/net/packet
> > exec /proc/self/net/packet
> >
> > makes lockdep unhappy, cat/exec take seq_file->lock + cred_guard_mutex in
> > the opposite order.
>
> Oleg, I see it again with almost the same test-case:
>
> cat /proc/self/stack >/dev/null
> chmod +x /proc/self/net/packet
> exec /proc/self/net/packet
Yes, there are more lock_trace/mm_access (ab)users. Fortunately, they
are much simpler than proc/pid/maps (which also asked for other cleanups
and fixes).
I'll try to take a look, thanks for reminding.
And I agree with Eric, chmod+x probably makes no sense. Still I think
this code deserves some cleanups regardless. To the point I think that
lock_trace() should probably die.
Thanks!
Oleg.
^ permalink raw reply
* Re: [patch iproute2 v4] tc: add support for vlan tc action
From: Stephen Hemminger @ 2014-12-03 17:35 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, jhs, pshelar, therbert, edumazet, willemb,
dborkman, mst, fw, Paul.Durrant, tgraf, cwang
In-Reply-To: <1416402506-31852-1-git-send-email-jiri@resnulli.us>
On Wed, 19 Nov 2014 14:08:26 +0100
Jiri Pirko <jiri@resnulli.us> wrote:
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> Reviewed-by: Cong Wang <cwang@twopensource.com>
Applied to net-next branch.
^ permalink raw reply
* Re: [PATCH Iproute2 next v2] ip link: Add ipvlan support to the iproute2/ip util
From: Stephen Hemminger @ 2014-12-03 17:38 UTC (permalink / raw)
To: Mahesh Bandewar
Cc: netdev, Eric Dumazet, Maciej Zenczykowski, Laurent Chavey,
Tim Hockin, David Miller, Brandon Philips, Pavel Emelianov
In-Reply-To: <1416794771-11193-1-git-send-email-maheshb@google.com>
On Sun, 23 Nov 2014 18:06:11 -0800
Mahesh Bandewar <maheshb@google.com> wrote:
> Adding basic support to create virtual devices using 'ip'
> utility. Following is the syntax -
>
> ip link add link <master> <virtual> type ipvlan mode [ l2 | l3 ]
> e.g. ip link add link eth0 ipvl0 type ipvlan mode l3
>
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> Cc: Stephen Hemminger <stephen@networkplumber.org>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Maciej Żenczykowski <maze@google.com>
> Cc: Laurent Chavey <chavey@google.com>
> Cc: Tim Hockin <thockin@google.com>
> Cc: Brandon Philips <brandon.philips@coreos.com>
> Cc: Pavel Emelianov <xemul@parallels.com>
Applied to net-next branch.
^ permalink raw reply
* Re: [PATCH iproute2] ip monitor: Fixed printing timestamp few times
From: Stephen Hemminger @ 2014-12-03 17:47 UTC (permalink / raw)
To: vadim4j; +Cc: netdev
In-Reply-To: <20141203171126.GA7381@angus-think.wlc.globallogic.com>
On Wed, 3 Dec 2014 19:11:26 +0200
vadim4j@gmail.com wrote:
> I think it was caused by RTM_NEWNDUSEROPT which was sent by router.
> So in this case the message will be skipped with printed timestamp.
Can that be decoded? it might be useful.
^ permalink raw reply
* Re: [PATCH iproute2] ss: Use rtnl_dump_filter in handle_netlink_request
From: Stephen Hemminger @ 2014-12-03 17:51 UTC (permalink / raw)
To: vadim4j; +Cc: netdev
In-Reply-To: <20141203172010.GA8639@angus-think.wlc.globallogic.com>
On Wed, 3 Dec 2014 19:20:10 +0200
vadim4j@gmail.com wrote:
> On Wed, Dec 03, 2014 at 09:21:29AM -0800, Stephen Hemminger wrote:
> > On Tue, 2 Dec 2014 16:53:04 +0200
> > Vadim Kochan <vadim4j@gmail.com> wrote:
> >
> > > Replaced handling netlink messages by rtnl_dump_filter
> > > from lib/libnetlink.c, also:
> > >
> > > - removed unused dump_fp arg;
> > > - added MAGIC_SEQ #define for 123456 seq id
> > >
> > > Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
> >
> > This doesn't work correctly.
> >
> > Simple test
> > $ misc/ss >/dev/null
> > RTNETLINK answers: No such file or directory
> > RTNETLINK answers: No such file or directory
> > RTNETLINK answers: No such file or directory
>
> Just tried, I did not get such errors.
I have OpenVPN running.
^ permalink raw reply
* Re: [PATCH iproute2] ip monitor: Fixed printing timestamp few times
From: vadim4j @ 2014-12-03 17:41 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20141203094731.4d310fc5@urahara>
On Wed, Dec 03, 2014 at 09:47:31AM -0800, Stephen Hemminger wrote:
> On Wed, 3 Dec 2014 19:11:26 +0200
> vadim4j@gmail.com wrote:
>
> > I think it was caused by RTM_NEWNDUSEROPT which was sent by router.
> > So in this case the message will be skipped with printed timestamp.
>
> Can that be decoded? it might be useful.
Sorry, you mean how it can be reproduced by clean scenario?
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: bcmgenet: add support for new GENET PHY revision scheme
From: Florian Fainelli @ 2014-12-03 17:54 UTC (permalink / raw)
To: Sergei Shtylyov, netdev; +Cc: davem
In-Reply-To: <547EF2BC.60504@cogentembedded.com>
On 03/12/14 03:23, Sergei Shtylyov wrote:
> Hello.
>
> On 12/3/2014 2:28 AM, Florian Fainelli wrote:
>
>> Starting with GPHY revision G0, the GENET register layout has changed to
>> use the same numbering scheme as the Starfighter 2 switch. This means
>> that GPHY major revision is in bits 15:12, minor in bits 11:8 and patch
>> level is in bits 7:4.
>
>> Introduce a small heuristic which checks for the old scheme first, tests
>> for the new scheme and finally attempts to catch reserved values and
>> aborts.
>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> drivers/net/ethernet/broadcom/genet/bcmgenet.c | 24
>> +++++++++++++++++++++++-
>> 1 file changed, 23 insertions(+), 1 deletion(-)
>
>> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> index f2fadb053d52..23e283174c4e 100644
>> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> [...]
>> @@ -2551,8 +2552,29 @@ static void bcmgenet_set_hw_params(struct
>> bcmgenet_priv *priv)
>> * to pass this information to the PHY driver. The PHY driver
>> expects
>> * to find the PHY major revision in bits 15:8 while the GENET
>> register
>> * stores that information in bits 7:0, account for that.
>> + *
>> + * On newer chips, starting with PHY revision G0, a new scheme is
>> + * deployed similar to the Starfighter 2 switch with GPHY major
>> + * revision in bits 15:8 and patch level in bits 7:0. Major
>> revision 0
>> + * is reserved as well as special value 0x01ff, we have a small
>> + * heuristic to check for the new GPHY revision and re-arrange
>> things
>> + * so the GPHY driver is happy.
>> */
>> - priv->gphy_rev = (reg & 0xffff) << 8;
>> + gphy_rev = (reg & 0xffff);
>
> Parens not needed anymore.
>
>> +
>> + /* This the good old scheme, just GPHY major, no minor nor patch */
>
> Missing "is" after "This"?
Alright, I will resubmit...
>
>> + if ((gphy_rev & 0xf0) != 0)
>> + priv->gphy_rev = gphy_rev << 8;
>> +
>> + /* This is the new scheme, GPHY major rolls over with 0x10 = rev
>> G0 */
>> + else if ((gphy_rev & 0xff00) != 0)
>> + priv->gphy_rev = gphy_rev;
>> +
>> + /* This is reserved so should require special treatment */
>> + else if (gphy_rev == 0 || gphy_rev == 0x01ff) {
>> + pr_warn("Invalid GPHY revision detected: 0x%04x\n", gphy_rev);
>> + return;
>> + }
>
> Hm, {} are needed on all *if* branches.
checkpatch.pl did not complain about that.
>
> [...]
>
> WBR, Sergei
>
^ permalink raw reply
* Re: [PATCH iproute2] ss: Use rtnl_dump_filter in handle_netlink_request
From: vadim4j @ 2014-12-03 17:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20141203095123.40429f4c@urahara>
On Wed, Dec 03, 2014 at 09:51:23AM -0800, Stephen Hemminger wrote:
> On Wed, 3 Dec 2014 19:20:10 +0200
> vadim4j@gmail.com wrote:
>
> > On Wed, Dec 03, 2014 at 09:21:29AM -0800, Stephen Hemminger wrote:
> > > On Tue, 2 Dec 2014 16:53:04 +0200
> > > Vadim Kochan <vadim4j@gmail.com> wrote:
> > >
> > > > Replaced handling netlink messages by rtnl_dump_filter
> > > > from lib/libnetlink.c, also:
> > > >
> > > > - removed unused dump_fp arg;
> > > > - added MAGIC_SEQ #define for 123456 seq id
> > > >
> > > > Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
> > >
> > > This doesn't work correctly.
> > >
> > > Simple test
> > > $ misc/ss >/dev/null
> > > RTNETLINK answers: No such file or directory
> > > RTNETLINK answers: No such file or directory
> > > RTNETLINK answers: No such file or directory
> >
> > Just tried, I did not get such errors.
>
> I have OpenVPN running.
Hm, it is reproduced only with this patch ?
If so I will try to setup OpenVPN ... can't imagine how it can be
related ...
^ permalink raw reply
* [PATCH net-next v2 0/2] net: bcmgenet: support for new GPHY revision scheme
From: Florian Fainelli @ 2014-12-03 17:56 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli
Hi David,
These two patches update the GENET GPHY revision logic to account for some
of our newer designs starting with GPHY rev G0.
Florian Fainelli (2):
net: bcmgenet: add support for new GENET PHY revision scheme
net: phy: bcm7xxx: add an explicit version check for GPHY rev G0
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 24 +++++++++++++++++++++++-
drivers/net/phy/bcm7xxx.c | 2 ++
2 files changed, 25 insertions(+), 1 deletion(-)
--
2.1.0
^ permalink raw reply
* [PATCH net-next v2 1/2] net: bcmgenet: add support for new GENET PHY revision scheme
From: Florian Fainelli @ 2014-12-03 17:56 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli
In-Reply-To: <1417629420-31146-1-git-send-email-f.fainelli@gmail.com>
Starting with GPHY revision G0, the GENET register layout has changed to
use the same numbering scheme as the Starfighter 2 switch. This means
that GPHY major revision is in bits 15:12, minor in bits 11:8 and patch
level is in bits 7:4.
Introduce a small heuristic which checks for the old scheme first, tests
for the new scheme and finally attempts to catch reserved values and
aborts.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Changes in v2:
- remove unnecessary parenthesis
- add missing "is" in paragraph about the scheme
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index f2fadb053d52..410c22bc655a 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -2503,6 +2503,7 @@ static void bcmgenet_set_hw_params(struct bcmgenet_priv *priv)
struct bcmgenet_hw_params *params;
u32 reg;
u8 major;
+ u16 gphy_rev;
if (GENET_IS_V4(priv)) {
bcmgenet_dma_regs = bcmgenet_dma_regs_v3plus;
@@ -2551,8 +2552,29 @@ static void bcmgenet_set_hw_params(struct bcmgenet_priv *priv)
* to pass this information to the PHY driver. The PHY driver expects
* to find the PHY major revision in bits 15:8 while the GENET register
* stores that information in bits 7:0, account for that.
+ *
+ * On newer chips, starting with PHY revision G0, a new scheme is
+ * deployed similar to the Starfighter 2 switch with GPHY major
+ * revision in bits 15:8 and patch level in bits 7:0. Major revision 0
+ * is reserved as well as special value 0x01ff, we have a small
+ * heuristic to check for the new GPHY revision and re-arrange things
+ * so the GPHY driver is happy.
*/
- priv->gphy_rev = (reg & 0xffff) << 8;
+ gphy_rev = reg & 0xffff;
+
+ /* This is the good old scheme, just GPHY major, no minor nor patch */
+ if ((gphy_rev & 0xf0) != 0)
+ priv->gphy_rev = gphy_rev << 8;
+
+ /* This is the new scheme, GPHY major rolls over with 0x10 = rev G0 */
+ else if ((gphy_rev & 0xff00) != 0)
+ priv->gphy_rev = gphy_rev;
+
+ /* This is reserved so should require special treatment */
+ else if (gphy_rev == 0 || gphy_rev == 0x01ff) {
+ pr_warn("Invalid GPHY revision detected: 0x%04x\n", gphy_rev);
+ return;
+ }
#ifdef CONFIG_PHYS_ADDR_T_64BIT
if (!(params->flags & GENET_HAS_40BITS))
--
2.1.0
^ permalink raw reply related
* [PATCH net-next v2 2/2] net: phy: bcm7xxx: add an explicit version check for GPHY rev G0
From: Florian Fainelli @ 2014-12-03 17:57 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli
In-Reply-To: <1417629420-31146-1-git-send-email-f.fainelli@gmail.com>
GPHY revision G0 has its version rolled over to 0x10, introduce an
explicit check for that revision and invoke the proper workaround
function for it.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/phy/bcm7xxx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/phy/bcm7xxx.c b/drivers/net/phy/bcm7xxx.c
index 7a53af4346e4..974ec4515269 100644
--- a/drivers/net/phy/bcm7xxx.c
+++ b/drivers/net/phy/bcm7xxx.c
@@ -252,6 +252,8 @@ static int bcm7xxx_28nm_config_init(struct phy_device *phydev)
break;
case 0xe0:
case 0xf0:
+ /* Rev G0 introduces a roll over */
+ case 0x10:
ret = bcm7xxx_28nm_e0_plus_afe_config_init(phydev);
break;
default:
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] bpf: arm64: lift restriction on last instruction
From: Will Deacon @ 2014-12-03 18:04 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Zi Shen Lim, David S. Miller, Catalin Marinas, Daniel Borkmann,
Network Development, linux-arm-kernel@lists.infradead.org, LKML
In-Reply-To: <CAMEtUuwJHC2eyOh3pD=qDXw1YbfJqx1a7W0o65n5Ur_B_TvNOA@mail.gmail.com>
On Wed, Dec 03, 2014 at 03:54:32PM +0000, Alexei Starovoitov wrote:
> On Wed, Dec 3, 2014 at 12:38 AM, Zi Shen Lim <zlim.lnx@gmail.com> wrote:
> > Earlier implementation assumed last instruction is BPF_EXIT.
> > Since this is no longer a restriction in eBPF, we remove this
> > limitation.
> >
> > Per Alexei Starovoitov [1]:
> >> classic BPF has a restriction that last insn is always BPF_RET.
> >> eBPF doesn't have BPF_RET instruction and this restriction.
> >> It has BPF_EXIT insn which can appear anywhere in the program
> >> one or more times and it doesn't have to be last insn.
> >
> > [1] https://lkml.org/lkml/2014/11/27/2
> >
> > Fixes: e54bcde3d69d ("arm64: eBPF JIT compiler")
> > Signed-off-by: Zi Shen Lim <zlim.lnx@gmail.com>
>
> yours is cleaner than my own attempt to fix it.
> Thanks!
> Acked-by: Alexei Starovoitov <ast@plumgrid.com>
Cheers, I've applied this for 3.19.
Will
^ permalink raw reply
* Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
From: Jesse Gross @ 2014-12-03 18:07 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Thomas Graf, Du, Fan, Jason Wang, netdev@vger.kernel.org,
davem@davemloft.net, fw@strlen.de, dev@openvswitch.org,
Pravin Shelar
In-Reply-To: <20141203090339.GA9299@redhat.com>
On Wed, Dec 3, 2014 at 1:03 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Tue, Dec 02, 2014 at 10:12:04AM -0800, Jesse Gross wrote:
>> On Tue, Dec 2, 2014 at 9:41 AM, Thomas Graf <tgraf@suug.ch> wrote:
>> > On 12/02/14 at 07:34pm, Michael S. Tsirkin wrote:
>> >> On Tue, Dec 02, 2014 at 05:09:27PM +0000, Thomas Graf wrote:
>> >> > On 12/02/14 at 01:48pm, Flavio Leitner wrote:
>> >> > > What about containers or any other virtualization environment that
>> >> > > doesn't use Virtio?
>> >> >
>> >> > The host can dictate the MTU in that case for both veth or OVS
>> >> > internal which would be primary container plumbing techniques.
>> >>
>> >> It typically can't do this easily for VMs with emulated devices:
>> >> real ethernet uses a fixed MTU.
>> >>
>> >> IMHO it's confusing to suggest MTU as a fix for this bug, it's
>> >> an unrelated optimization.
>> >> ICMP_DEST_UNREACH/ICMP_FRAG_NEEDED is the right fix here.
>> >
>> > PMTU discovery only resolves the issue if an actual IP stack is
>> > running inside the VM. This may not be the case at all.
>>
>> It's also only really a correct thing to do if the ICMP packet is
>> coming from an L3 node. If you are doing straight bridging then you
>> have to resort to hacks like OVS had before, which I agree are not
>> particularly desirable.
>
> The issue seems to be that fundamentally, this is
> bridging interfaces with variable MTUs (even if MTU values
> on devices don't let us figure this out)-
> that is already not straight bridging, and
> I would argue sending ICMPs back is the right thing to do.
How do you deal with the fact that there is no host IP stack inside
the tunnel? And isn't this exactly the same as the former OVS
implementation that you said you didn't like?
>> > I agree that exposing an MTU towards the guest is not applicable
>> > in all situations, in particular because it is difficult to decide
>> > what MTU to expose. It is a relatively elegant solution in a lot
>> > of virtualization host cases hooked up to an orchestration system
>> > though.
>>
>> I also think this is the right thing to do as a common case
>> optimization and I know other platforms (such as Hyper-V) do it. It's
>> not a complete solution so we still need the original patch in this
>> thread to handle things transparently.
>
> Well, as I believe David (and independently Jason) is saying, it looks like
> the ICMPs we are sending back after applying the original patch have the
> wrong MTU.
The problem is actually that the ICMP messages won't even go to the
sending VM because the host IP stack and the VM are isolated from each
other and there is no route.
> And if I understand what David is saying here, IP is also the wrong place to
> do it.
ICMP can't be the complete solution in any case because it only works
for IP traffic. I think there are only two full solutions: find a way
to adjust the guest MTU to the minimum MTU that its traffic could hit
in an L2 domain or fragmentation. ICMP could be a possible
optimization in the fragmentation case.
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: bcmgenet: add support for new GENET PHY revision scheme
From: Sergei Shtylyov @ 2014-12-03 18:12 UTC (permalink / raw)
To: Florian Fainelli, netdev; +Cc: davem
In-Reply-To: <547F4E4E.5030906@gmail.com>
Hello.
On 12/03/2014 08:54 PM, Florian Fainelli wrote:
>>> Starting with GPHY revision G0, the GENET register layout has changed to
>>> use the same numbering scheme as the Starfighter 2 switch. This means
>>> that GPHY major revision is in bits 15:12, minor in bits 11:8 and patch
>>> level is in bits 7:4.
>>> Introduce a small heuristic which checks for the old scheme first, tests
>>> for the new scheme and finally attempts to catch reserved values and
>>> aborts.
>>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>>> ---
>>> drivers/net/ethernet/broadcom/genet/bcmgenet.c | 24
>>> +++++++++++++++++++++++-
>>> 1 file changed, 23 insertions(+), 1 deletion(-)
>>> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>>> b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>>> index f2fadb053d52..23e283174c4e 100644
>>> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>>> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> [...]
>>> @@ -2551,8 +2552,29 @@ static void bcmgenet_set_hw_params(struct
[...]
>>> + if ((gphy_rev & 0xf0) != 0)
>>> + priv->gphy_rev = gphy_rev << 8;
>>> +
>>> + /* This is the new scheme, GPHY major rolls over with 0x10 = rev
>>> G0 */
>>> + else if ((gphy_rev & 0xff00) != 0)
>>> + priv->gphy_rev = gphy_rev;
>>> +
>>> + /* This is reserved so should require special treatment */
>>> + else if (gphy_rev == 0 || gphy_rev == 0x01ff) {
>>> + pr_warn("Invalid GPHY revision detected: 0x%04x\n", gphy_rev);
>>> + return;
>>> + }
>>
>> Hm, {} are needed on all *if* branches.
> checkpatch.pl did not complain about that.
It probably still doesn't. Nevertheless, refer to
Documentation/CodingStyle, chapter 3.
>> [...]
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
From: Michael S. Tsirkin @ 2014-12-03 18:38 UTC (permalink / raw)
To: Jesse Gross
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jason Wang,
Du, Fan, fw-HFFVJYpyMKqzQB+pC5nmwQ@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
In-Reply-To: <CAEP_g=9C+D3gbjJ4n1t6xuyjqEAMYi4ZfqPoe92UAoQJH-UsKg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Dec 03, 2014 at 10:07:42AM -0800, Jesse Gross wrote:
> On Wed, Dec 3, 2014 at 1:03 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Tue, Dec 02, 2014 at 10:12:04AM -0800, Jesse Gross wrote:
> >> On Tue, Dec 2, 2014 at 9:41 AM, Thomas Graf <tgraf@suug.ch> wrote:
> >> > On 12/02/14 at 07:34pm, Michael S. Tsirkin wrote:
> >> >> On Tue, Dec 02, 2014 at 05:09:27PM +0000, Thomas Graf wrote:
> >> >> > On 12/02/14 at 01:48pm, Flavio Leitner wrote:
> >> >> > > What about containers or any other virtualization environment that
> >> >> > > doesn't use Virtio?
> >> >> >
> >> >> > The host can dictate the MTU in that case for both veth or OVS
> >> >> > internal which would be primary container plumbing techniques.
> >> >>
> >> >> It typically can't do this easily for VMs with emulated devices:
> >> >> real ethernet uses a fixed MTU.
> >> >>
> >> >> IMHO it's confusing to suggest MTU as a fix for this bug, it's
> >> >> an unrelated optimization.
> >> >> ICMP_DEST_UNREACH/ICMP_FRAG_NEEDED is the right fix here.
> >> >
> >> > PMTU discovery only resolves the issue if an actual IP stack is
> >> > running inside the VM. This may not be the case at all.
> >>
> >> It's also only really a correct thing to do if the ICMP packet is
> >> coming from an L3 node. If you are doing straight bridging then you
> >> have to resort to hacks like OVS had before, which I agree are not
> >> particularly desirable.
> >
> > The issue seems to be that fundamentally, this is
> > bridging interfaces with variable MTUs (even if MTU values
> > on devices don't let us figure this out)-
> > that is already not straight bridging, and
> > I would argue sending ICMPs back is the right thing to do.
>
> How do you deal with the fact that there is no host IP stack inside
> the tunnel? And isn't this exactly the same as the former OVS
> implementation that you said you didn't like?
I was talking about the high level requirement, not the implementation
here. I agree it's not at all trivial, we need to propagate this across
tunnels.
But let's agree on what we are trying to accomplish first.
> >> > I agree that exposing an MTU towards the guest is not applicable
> >> > in all situations, in particular because it is difficult to decide
> >> > what MTU to expose. It is a relatively elegant solution in a lot
> >> > of virtualization host cases hooked up to an orchestration system
> >> > though.
> >>
> >> I also think this is the right thing to do as a common case
> >> optimization and I know other platforms (such as Hyper-V) do it. It's
> >> not a complete solution so we still need the original patch in this
> >> thread to handle things transparently.
> >
> > Well, as I believe David (and independently Jason) is saying, it looks like
> > the ICMPs we are sending back after applying the original patch have the
> > wrong MTU.
>
> The problem is actually that the ICMP messages won't even go to the
> sending VM because the host IP stack and the VM are isolated from each
> other and there is no route.
Exactly.
But all this is talking about implementation.
Let's agree on what we want to do first.
And in my mind, we typically want originator to adjust its PMTU,
just for a given destination.
Sending ICMP to originating VM will typically accomplish this.
> > And if I understand what David is saying here, IP is also the wrong place to
> > do it.
>
> ICMP can't be the complete solution in any case because it only works
> for IP traffic.
Let's be specific please. What protocols do you most care about? IPX?
> I think there are only two full solutions: find a way
> to adjust the guest MTU to the minimum MTU that its traffic could hit
> in an L2 domain or fragmentation. ICMP could be a possible
> optimization in the fragmentation case.
Both approaches seem strange. You are sending 1 packet an hour to
some destination behind 100 tunnels. Why would you want to
cut down your MTU for all packets? On the other hand,
doubling the amount of packets because your MTU is off
by a couple of bytes will hurt performance significantly.
Still, if you want to cut down the MTU within guest,
that's only an ifconfig away.
Most people would not want to bother, I think it's a good
idea to make PMTU work properly for them.
--
MST
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCHv11 net-next 2/2] openvswitch: Add support for unique flow IDs.
From: Joe Stringer @ 2014-12-03 18:47 UTC (permalink / raw)
To: Pravin Shelar; +Cc: Linux Kernel, dev@openvswitch.org, Linux Netdev List
In-Reply-To: <1417575363-13770-2-git-send-email-joestringer@nicira.com>
I forgot to mention that this is the first post based against net-next.
On 2 December 2014 at 18:56, Joe Stringer <joestringer@nicira.com> wrote:
> <....snip...>
> diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h
> index a8b30f3..7f31dbf 100644
> --- a/net/openvswitch/flow.h
> +++ b/net/openvswitch/flow.h
> @@ -197,6 +197,13 @@ struct sw_flow_match {
> struct sw_flow_mask *mask;
> };
>
> +#define MAX_UFID_LENGTH 256
> +
> +struct sw_flow_id {
> + u32 ufid_len;
> + u32 ufid[MAX_UFID_LENGTH / 4];
> +};
> +
> struct sw_flow_actions {
> struct rcu_head rcu;
> u32 actions_len;
Pravin, I changed the 'struct sw_flow_id' to the above after feedback
from the previous round, but it doesn't seem quite right. Is this what
you meant? Given that current ovs-vswitchd userspace only generates
128bit UFIDs, it seems wasteful to be allocating so much for this. Did
you have in mind for this to be united with the unmasked_key?
^ permalink raw reply
* Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
From: Rick Jones @ 2014-12-03 18:56 UTC (permalink / raw)
To: Michael S. Tsirkin, Jesse Gross
Cc: Thomas Graf, Du, Fan, Jason Wang, netdev@vger.kernel.org,
davem@davemloft.net, fw@strlen.de, dev@openvswitch.org,
Pravin Shelar
In-Reply-To: <20141203183859.GB16447@redhat.com>
Trying to "fake-out" an ICMP message to paper-over "devices" in the
"middle" of same Layer2 network having different MTUs from the ends goes
back to at least the days when people started joining FDDI networks to
Ethernet networks with bridges rather than routers. Perhaps back even
further. It had problems them (including not all traffic being IP), I
doubt today would be any different.
All devices in a Layer2 network must have the same MTU. (*)
The only exception to that which does not lead one down a rathole is
that you can have the MTU at the "edges" of the Layer 2 network be
smaller than the MTU in the "middle." And then only if the middle
"never" tries to talk itself to the edges directly.
rick jones
(*) Or at least any communicating device must be kept ignorant of what
one does to have a smaller MTU in there somewhere.
^ permalink raw reply
* Re: [PATCH v2 5/6] myri10ge: use eth_skb_pad helper
From: Sergei Shtylyov @ 2014-12-03 18:56 UTC (permalink / raw)
To: Alexander Duyck, netdev; +Cc: Hyong-Youb Kim, davem
In-Reply-To: <20141203161758.9223.85476.stgit@ahduyck-vm-fedora20>
Hello.
On 12/03/2014 07:17 PM, Alexander Duyck wrote:
> Update myri10ge to use eth_skb_pad helper. This also corrects a minor
> issue as the driver was updating length without updating the tail pointer.
> Cc: Hyong-Youb Kim <hykim@myri.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
> ---
> drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 15 +++++----------
> 1 file changed, 5 insertions(+), 10 deletions(-)
> diff --git a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
> index 9e7e3f1..af09905 100644
> --- a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
> +++ b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
> @@ -2913,16 +2913,11 @@ again:
> flags |= MXGEFW_FLAGS_SMALL;
>
> /* pad frames to at least ETH_ZLEN bytes */
> - if (unlikely(skb->len < ETH_ZLEN)) {
> - if (skb_padto(skb, ETH_ZLEN)) {
> - /* The packet is gone, so we must
> - * return 0 */
> - ss->stats.tx_dropped += 1;
> - return NETDEV_TX_OK;
> - }
> - /* adjust the len to account for the zero pad
> - * so that the nic can know how long it is */
> - skb->len = ETH_ZLEN;
> + if (eth_skb_pad(skb)) {
> + /* The packet is gone, so we must
> + * return 0 */
Time to fix the comment style, perhaps? The preferred one for the
networking code is:
/* bla
* bla
*/
> + ss->stats.tx_dropped += 1;
Hm, why not 'ss->stats.tx_dropped++'?
> + return NETDEV_TX_OK;
> }
> }
WBR, Sergei
^ 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