* Re: [PATCH net-next v5 12/12] sock: Add SO_RCVTIMEO_NEW and SO_SNDTIMEO_NEW
From: Deepa Dinamani @ 2019-02-03 2:47 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: David S. Miller, Linux Kernel Mailing List,
Linux Network Devel Mailing List, Arnd Bergmann,
y2038 Mailman List, ccaulfie, Helge Deller, Paul Mackerras,
Ralf Baechle, Richard Henderson, cluster-devel, linuxppc-dev,
linux-alpha, linux-arch, linux-mips, Parisc List, sparclinux
In-Reply-To: <0fad3f4d-4c0e-d9f2-1af0-7890d40c19c0@hartkopp.net>
On Sat, Feb 2, 2019 at 9:15 AM Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>
> Hi all,
>
> On 02.02.19 16:34, Deepa Dinamani wrote:
> > Add new socket timeout options that are y2038 safe.
> (..)
> >
> > diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/uapi/asm/socket.h
> > index 9826d1db71d0..0d0fddb7e738 100644
> > --- a/arch/alpha/include/uapi/asm/socket.h
> > +++ b/arch/alpha/include/uapi/asm/socket.h
> > @@ -119,19 +119,25 @@
> > #define SO_TIMESTAMPNS_NEW 64
> > #define SO_TIMESTAMPING_NEW 65
> >
> > -#if !defined(__KERNEL__)
> > +#define SO_RCVTIMEO_NEW 66
> > +#define SO_SNDTIMEO_NEW 67
> >
> > -#define SO_RCVTIMEO SO_RCVTIMEO_OLD
> > -#define SO_SNDTIMEO SO_SNDTIMEO_OLD
> > +#if !defined(__KERNEL__)
> >
> > #if __BITS_PER_LONG == 64
> > #define SO_TIMESTAMP SO_TIMESTAMP_OLD
> > #define SO_TIMESTAMPNS SO_TIMESTAMPNS_OLD
> > #define SO_TIMESTAMPING SO_TIMESTAMPING_OLD
> > +
> > +#define SO_RCVTIMEO SO_RCVTIMEO_OLD
> > +#define SO_SNDTIMEO SO_SNDTIMEO_OLD
>
> Maybe I'm a bit late in this discussion as you are already in v5 ...
>
> I can see patches making the transition in different steps where it
> might be helpful to name them *_OLD and *_NEW to understand the patches.
>
> But in the end the naming stays in the kernel for a very long time and I
> remember myself (in early years) to name things 'new', 'new2', 'new3'.
>
> In fact SO_TIMESTAMP_OLD should be named SO_TIMESTAMP32 and
> SO_TIMESTAMP_NEW should be named SO_TIMESTAMP64.
Hmm. SO_TIMESTAMP_OLD uses 64-bit time_t on a 64 bit machine. In fact,
there is no difference between the two options on a 64 bit machine. So
using SO_TIMESTAMP_32 is just wrong.
Likewise, SO_TIMESTAMP_64 naming somehow indicates that the existing
one was not, and that is also not true on a 64-bit machine.
Further, userspace will still continue to use SO_TIMESTAMP and the
macros take care of which option to select internally.
Moreover, these macros have been there for more than ten years
(introduced before 2.4) and there has been no change. I doubt you will
ever have NEW2.
I think this argument is similar to saying don’t name these macros
SO_TIMESTAMP because there might be SO_TIMESTAMP1 some day. There is
never a perfect name. SO_TIMESTAMPING is also not really descriptive.
> Especially as it tells you what is 'inside', the naming of these new introduced constants should be replaced with *32 and *64 names.
> The documentation and the other comments still fit perfectly then.
I would prefer not to do this, for reasons mentioned above. Since you
point out that it is easier to use this naming for intermediate steps,
I suggest that we leave the series as it is.
If you feel strongly to post a follow-on renaming patch, you could
discuss it with the subsystem maintainers, if you think there is a
correct but more descriptive naming.
-Deepa
> Regards,
> Oliver
^ permalink raw reply
* Re: [PATCH] ipmr: ip6mr: Create new sockopt to clear mfc cache only
From: David Miller @ 2019-02-03 3:42 UTC (permalink / raw)
To: callum.sinclair; +Cc: kuznet, yoshfuji, nikolay, netdev, linux-kernel
In-Reply-To: <20190130205209.18183-2-callum.sinclair@alliedtelesis.co.nz>
From: Callum Sinclair <callum.sinclair@alliedtelesis.co.nz>
Date: Thu, 31 Jan 2019 09:52:09 +1300
>
> -/* Close the multicast socket, and clear the vif tables etc */
> -static void mroute_clean_tables(struct mr_table *mrt, bool all)
> +/* Clear the vif tables */
> +static void mroute_clean_cache(struct mr_table *mrt, bool all)
> {
> - struct net *net = read_pnet(&mrt->net);
> struct mr_mfc *c, *tmp;
> struct mfc_cache *cache;
> - LIST_HEAD(list);
> - int i;
> -
> - /* Shut down all active vif entries */
> - for (i = 0; i < mrt->maxvif; i++) {
> - if (!all && (mrt->vif_table[i].flags & VIFF_STATIC))
> - continue;
> - vif_delete(mrt, i, 0, &list);
> - }
> - unregister_netdevice_many(&list);
> + struct net *net = read_pnet(&mrt->net);
Please do not change the order of local variables like this, you're breaking
the correct reverse christmas tree ordering of longest to shortest line for
local variable declarations.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] Revert "net: phy: marvell: avoid pause mode on SGMII-to-Copper for 88e151x"
From: David Miller @ 2019-02-03 3:44 UTC (permalink / raw)
To: rmk+kernel; +Cc: andrew, f.fainelli, hkallweit1, netdev
In-Reply-To: <E1gpFgo-0000gO-A6@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Thu, 31 Jan 2019 16:59:46 +0000
> This reverts commit 6623c0fba10ef45b64ca213ad5dec926f37fa9a0.
>
> The original diagnosis was incorrect: it appears that the NIC had
> PHY polling mode enabled, which meant that it overwrote the PHYs
> advertisement register during negotiation.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> v2: respun on top of net-next, but I've not yet been able to boot
> test this - which is unlikely to be for a while yet.
This looks like a fix so I have applied it to 'net' and queued it up for
-stable.
^ permalink raw reply
* Re: [PATCH net-next] r8169: remove rtl_wol_pll_power_down
From: David Miller @ 2019-02-03 3:46 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <8fbc37cf-c719-1b2e-12c9-ec98c414a130@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Thu, 31 Jan 2019 22:03:48 +0100
> rtl_wol_pll_power_down() is used in only one place and removing it
> makes the code simpler and better readable.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied, thanks Heiner.
^ permalink raw reply
* [PATCH] netdevice.h: Add __cold to netdev_<level> logging functions
From: Joe Perches @ 2019-02-03 3:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev, LKML
Add __cold to the netdev_<level> logging functions similar to
the use of __cold in the generic printk function.
Using __cold moves all the netdev_<level> logging functions
out-of-line possibly improving code locality and runtime
performance.
Signed-off-by: Joe Perches <joe@perches.com>
---
include/linux/netdevice.h | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 579d132a75ff..b6c6d2fe17b0 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -4671,22 +4671,22 @@ static inline const char *netdev_reg_state(const struct net_device *dev)
return " (unknown)";
}
-__printf(3, 4)
+__printf(3, 4) __cold
void netdev_printk(const char *level, const struct net_device *dev,
const char *format, ...);
-__printf(2, 3)
+__printf(2, 3) __cold
void netdev_emerg(const struct net_device *dev, const char *format, ...);
-__printf(2, 3)
+__printf(2, 3) __cold
void netdev_alert(const struct net_device *dev, const char *format, ...);
-__printf(2, 3)
+__printf(2, 3) __cold
void netdev_crit(const struct net_device *dev, const char *format, ...);
-__printf(2, 3)
+__printf(2, 3) __cold
void netdev_err(const struct net_device *dev, const char *format, ...);
-__printf(2, 3)
+__printf(2, 3) __cold
void netdev_warn(const struct net_device *dev, const char *format, ...);
-__printf(2, 3)
+__printf(2, 3) __cold
void netdev_notice(const struct net_device *dev, const char *format, ...);
-__printf(2, 3)
+__printf(2, 3) __cold
void netdev_info(const struct net_device *dev, const char *format, ...);
#define netdev_level_once(level, dev, fmt, ...) \
^ permalink raw reply related
* Do the work
From: Grace @ 2019-02-02 15:05 UTC (permalink / raw)
To: netdev
Want to retouch your photos? we can help you.
Deep etching or masking for your photos, or even adding clipping path.
Retouching also if needed.
Hopefully to start something for you soon.
Thanks,
Grace
Wedmar
Memmingen
^ permalink raw reply
* Re: [PATCH v2 net-next 1/2] net: nixge: Separate ctrl and dma resources
From: David Miller @ 2019-02-03 4:10 UTC (permalink / raw)
To: alex.williams
Cc: robh+dt, mark.rutland, mdf, mcgrof, keescook, netdev, devicetree,
linux-kernel, alex.williams
In-Reply-To: <20190131213328.11236-1-alex.williams@ettus.com>
From: alex.williams@ettus.com
Date: Thu, 31 Jan 2019 13:33:27 -0800
> From: Alex Williams <alex.williams@ni.com>
>
> The DMA engine is a separate entity altogether, and this allows the DMA
> controller's address to float elsewhere in the FPGA's map.
>
> Signed-off-by: Alex Williams <alex.williams@ni.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 net-next 2/2] net: nixge: Update device-tree bindings with v3.00
From: David Miller @ 2019-02-03 4:10 UTC (permalink / raw)
To: alex.williams
Cc: robh+dt, mark.rutland, mdf, mcgrof, keescook, netdev, devicetree,
linux-kernel, alex.williams
In-Reply-To: <20190131213328.11236-2-alex.williams@ettus.com>
From: alex.williams@ettus.com
Date: Thu, 31 Jan 2019 13:33:28 -0800
> From: Alex Williams <alex.williams@ni.com>
>
> Now the DMA engine is free to float elsewhere in the system map.
>
> Signed-off-by: Alex Williams <alex.williams@ni.com>
Applied.
^ permalink raw reply
* Re: [PATCH] chelsio: clean up indentation issue
From: David Miller @ 2019-02-03 4:14 UTC (permalink / raw)
To: colin.king; +Cc: netdev, kernel-janitors, linux-kernel
In-Reply-To: <20190202113351.17803-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Sat, 2 Feb 2019 11:33:51 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> The assignment to size is indented too far, fix this and join
> two lines into one.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH] bna: fix indentation issue on call to bfa_ioc_pf_failed
From: David Miller @ 2019-02-03 4:14 UTC (permalink / raw)
To: colin.king
Cc: rmody, skalluru, GR-Linux-NIC-Dev, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20190202113707.18005-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Sat, 2 Feb 2019 11:37:07 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> The call to bfa_ioc_pf_failed is indented too far, fix this by
> removing a tab.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH] atl1c: fix indentation issue on an if statement
From: David Miller @ 2019-02-03 4:15 UTC (permalink / raw)
To: colin.king; +Cc: jcliburn, chris.snook, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20190202114129.18275-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Sat, 2 Feb 2019 11:41:29 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> An if statement is indented one level too deep, fix this by removing
> the extra tabs. Also add some spaces to the dev_warn arguments to clean
> up checkpatch warnings.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH] atheros: atl2: fix an indentaion issue on a return statement
From: David Miller @ 2019-02-03 4:15 UTC (permalink / raw)
To: colin.king; +Cc: jcliburn, chris.snook, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20190202114526.18510-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Sat, 2 Feb 2019 11:45:26 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> A return statment is not indented correctly, fix this by adding an
> extra tab.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] bonding: check slave set command firstly
From: Tonghao Zhang @ 2019-02-03 4:59 UTC (permalink / raw)
To: David Miller; +Cc: Linux Kernel Network Developers
In-Reply-To: <201902022228.HQ81QiaI%fengguang.wu@intel.com>
On Sat, Feb 2, 2019 at 10:38 PM kbuild test robot <lkp@intel.com> wrote:
>
> Hi Tonghao,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on net-next/master]
>
> url: https://github.com/0day-ci/linux/commits/xiangxia-m-yue-gmail-com/bonding-check-slave-set-command-firstly/20190202-215305
> config: xtensa-allyesconfig (attached as .config)
> compiler: xtensa-linux-gcc (GCC) 8.2.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=8.2.0 make.cross ARCH=xtensa
>
> Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
> http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
>
> All warnings (new ones prefixed by >>):
>
> drivers/net/bonding/bond_options.c: In function 'bond_option_slaves_set':
> >> drivers/net/bonding/bond_options.c:1403:9: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
> return ret;
> ^~~
the 'ret' is initialized actually before returning
> vim +/ret +1403 drivers/net/bonding/bond_options.c
>
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1366
> f3253339 stephen hemminger 2014-03-04 1367 static int bond_option_slaves_set(struct bonding *bond,
> 28f084cc stephen hemminger 2014-03-06 1368 const struct bond_opt_value *newval)
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1369 {
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1370 char command[IFNAMSIZ + 1] = { 0, };
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1371 struct net_device *dev;
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1372 char *ifname;
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1373 int ret;
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1374
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1375 sscanf(newval->string, "%16s", command); /* IFNAMSIZ*/
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1376 ifname = command + 1;
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1377 if ((strlen(command) <= 1) ||
> c9914772 Tonghao Zhang 2019-02-01 1378 (command[0] != '+' && command[0] != '-') ||
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1379 !dev_valid_name(ifname))
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1380 goto err_no_cmd;
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1381
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1382 dev = __dev_get_by_name(dev_net(bond->dev), ifname);
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1383 if (!dev) {
> eac306b4 Michael Dilmore 2017-06-26 1384 netdev_dbg(bond->dev, "interface %s does not exist!\n",
> 2de390ba Veaceslav Falico 2014-07-15 1385 ifname);
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1386 ret = -ENODEV;
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1387 goto out;
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1388 }
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1389
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1390 switch (command[0]) {
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1391 case '+':
> eac306b4 Michael Dilmore 2017-06-26 1392 netdev_dbg(bond->dev, "Adding slave %s\n", dev->name);
> 33eaf2a6 David Ahern 2017-10-04 1393 ret = bond_enslave(bond->dev, dev, NULL);
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1394 break;
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1395
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1396 case '-':
> eac306b4 Michael Dilmore 2017-06-26 1397 netdev_dbg(bond->dev, "Removing slave %s\n", dev->name);
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1398 ret = bond_release(bond->dev, dev);
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1399 break;
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1400 }
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1401
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1402 out:
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 @1403 return ret;
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1404
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1405 err_no_cmd:
> 2de390ba Veaceslav Falico 2014-07-15 1406 netdev_err(bond->dev, "no command found in slaves file - use +ifname or -ifname\n");
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1407 ret = -EPERM;
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1408 goto out;
> 0e2e5b66 Nikolay Aleksandrov 2014-01-22 1409 }
> e9f0fb88 Mahesh Bandewar 2014-04-22 1410
>
> :::::: The code at line 1403 was first introduced by commit
> :::::: 0e2e5b66e9de377d69f50a456fdd60462889c64f bonding: convert slaves to use the new option API
>
> :::::: TO: Nikolay Aleksandrov <nikolay@redhat.com>
> :::::: CC: David S. Miller <davem@davemloft.net>
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH] net: dsa: slave: Don't propagate flag changes on down slave interfaces
From: 戈润栋 @ 2019-02-03 5:34 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, vivien.didelot, davem, netdev
In-Reply-To: <20190202171636.GB3398@lunn.ch>
Hi Andrew
Sorry for the previous mails due to my error mail format setting on browser.
I have reproduced the tcpdump issue in my env, but not sure if it is the
same issue as you mentioned.
Ifdown a slave interface which is under tcpdump capturing will also decrease
the master's promiscuous twice.
So when I do:
a) tcpdump -i ethx
b) ifdown ethx
c) ifup ethx
d) goto a
for several times the promiscuous count of master will go negative.
Raydon
Andrew Lunn <andrew@lunn.ch> 于2019年2月3日周日 上午1:16写道：
>
> On Sat, Feb 02, 2019 at 09:05:11AM -0800, Florian Fainelli wrote:
> > Le 2/2/19 à 6:29 AM, Rundong Ge a écrit :
> > > The unbalance of master's promiscuity or allmulti will happen after ifdown
> > > and ifup a slave interface which is in a bridge.
> > >
> > > When we ifdown a slave interface , both the 'dsa_slave_close' and
> > > 'dsa_slave_change_rx_flags' will clear the master's flags. The flags
> > > of master will be decrease twice.
> > > In the other hand, if we ifup the slave interface again, since the
> > > slave's flags were cleared the 'dsa_slave_open' won't set the master's
> > > flag, only 'dsa_slave_change_rx_flags' that triggered by 'br_add_if'
> > > will set the master's flags. The flags of master is increase once.
> > >
> > > Only propagating flag changes when a slave interface is up makes
> > > sure this does not happen. The 'vlan_dev_change_rx_flags' had the
> > > same problem and was fixed, and changes here follows that fix.
> >
> > VLAN code under net/8021q/vlan_dev.c::vlan_dev_change_rx_flags() appears
> > to do the same thing that you are proposing, so this looks fine to me.
> > Since that is a bugfix, we should probably add:
>
> Hi Rundong, Florian
>
> I've seen issues with tcpdump causing the promiscuous count to go
> negative. I wounder if this will fix that at well?
>
> Andrew
^ permalink raw reply
* Did you send the images?
From: Grace @ 2019-02-02 14:43 UTC (permalink / raw)
To: netdev
Want to retouch your photos? we can help you.
Deep etching or masking for your photos, or even adding clipping path.
Retouching also if needed.
Hopefully to start something for you soon.
Thanks,
Grace
Hedten
Memmingen
^ permalink raw reply
* [PATCH] net: fix IPv6 prefix route residue
From: Zhiqiang Liu @ 2019-02-03 6:10 UTC (permalink / raw)
To: davem, kuznet, yoshfuji, 0xeffeff, edumazet
Cc: netdev, mingfangsen, zhangwenhao8, wangxiaogang3, zhoukang7
From: Zhiqiang Liu <liuzhiqiang26@huawei.com>
Follow those steps:
# ip addr add 2001:123::1/32 dev eth0
# ip addr add 2001:123:456::2/64 dev eth0
# ip addr del 2001:123::1/32 dev eth0
# ip addr del 2001:123:456::2/64 dev eth0
and then prefix route of 2001:123::1/32 will still exist.
This is because ipv6_prefix_equal in check_cleanup_prefix_route
func does not check whether two IPv6 addresses have the same
prefix length. If the prefix of one address starts with another
shorter address prefix, even through their prefix lengths are
different, the return value of ipv6_prefix_equal is true.
Here I add a check of whether two addresses have the same prefix
to decide whether their prefixes are equal.
Signed-off-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
Reported-by: Wenhao Zhang <zhangwenhao8@huawei.com>
---
net/ipv6/addrconf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 84c3588..5742443 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1165,7 +1165,8 @@ enum cleanup_prefix_rt_t {
list_for_each_entry(ifa, &idev->addr_list, if_list) {
if (ifa == ifp)
continue;
- if (!ipv6_prefix_equal(&ifa->addr, &ifp->addr,
+ if (ifa->prefix_len != ifp->prefix_len ||
+ !ipv6_prefix_equal(&ifa->addr, &ifp->addr,
ifp->prefix_len))
continue;
if (ifa->flags & (IFA_F_PERMANENT | IFA_F_NOPREFIXROUTE))
--
1.8.3.1
^ permalink raw reply related
* Did you send the images?
From: Grace @ 2019-02-02 14:32 UTC (permalink / raw)
To: netdev
Want to retouch your photos? we can help you.
Deep etching or masking for your photos, or even adding clipping path.
Retouching also if needed.
Hopefully to start something for you soon.
Thanks,
Grace
Wedmar
Heindberg
^ permalink raw reply
* Did you send the images?
From: Grace @ 2019-02-02 11:39 UTC (permalink / raw)
To: netdev
Want to retouch your photos? we can help you.
Deep etching or masking for your photos, or even adding clipping path.
Retouching also if needed.
Hopefully to start something for you soon.
Thanks,
Grace
Redmscheid
Hemerd
^ permalink raw reply
* Re: [PATCH net-next 10/12] net: hns3: don't allow user to change vlan filter state
From: Sergei Shtylyov @ 2019-02-03 7:42 UTC (permalink / raw)
To: Huazhong Tan, davem
Cc: netdev, linux-kernel, huangdaode, yisen.zhuang, salil.mehta,
linuxarm, Jian Shen, Peng Li
In-Reply-To: <20190202143937.8924-11-tanhuazhong@huawei.com>
Hello!
On 02.02.2019 17:39, Huazhong Tan wrote:
> From: Jian Shen <shenjian15@huawei.com>
>
> When user disables vlan filter, and adds vlan device, it won't
> notify the driver the update the vlan filter. In this case, when
To update, perhaps?
> user enables vlan filter again, the packets with new vlan tag
> will be filtered by vlan filter.
>
> Signed-off-by: Jian Shen <shenjian15@huawei.com>
> Signed-off-by: Peng Li <lipeng321@huawei.com>
> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH bpf-next] bpf: support SO_DEBUG in bpf_setsockopt()
From: Yafang Shao @ 2019-02-03 8:15 UTC (permalink / raw)
To: kafai, brakmo, ast, daniel; +Cc: netdev, shaoyafang, Yafang Shao
Then we can enable/disable socket debugging without modifying user code.
That is more convenient for debugging.
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
---
include/net/sock.h | 8 ++++++++
net/core/filter.c | 3 +++
net/core/sock.c | 8 --------
3 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 2b229f7..8decee9 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1935,6 +1935,14 @@ static inline void sock_confirm_neigh(struct sk_buff *skb, struct neighbour *n)
}
}
+static inline void sock_valbool_flag(struct sock *sk, int bit, int valbool)
+{
+ if (valbool)
+ sock_set_flag(sk, bit);
+ else
+ sock_reset_flag(sk, bit);
+}
+
bool sk_mc_loop(struct sock *sk);
static inline bool sk_can_gso(const struct sock *sk)
diff --git a/net/core/filter.c b/net/core/filter.c
index 3a49f68..ce5da57 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -4111,6 +4111,9 @@ static unsigned long bpf_xdp_copy(void *dst_buff, const void *src_buff,
/* Only some socketops are supported */
switch (optname) {
+ case SO_DEBUG:
+ sock_valbool_flag(sk, SOCK_DBG, val);
+ break;
case SO_RCVBUF:
sk->sk_userlocks |= SOCK_RCVBUF_LOCK;
sk->sk_rcvbuf = max_t(int, val * 2, SOCK_MIN_RCVBUF);
diff --git a/net/core/sock.c b/net/core/sock.c
index 900e8a9..5ef6daa 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -638,14 +638,6 @@ static int sock_getbindtodevice(struct sock *sk, char __user *optval,
return ret;
}
-static inline void sock_valbool_flag(struct sock *sk, int bit, int valbool)
-{
- if (valbool)
- sock_set_flag(sk, bit);
- else
- sock_reset_flag(sk, bit);
-}
-
bool sk_mc_loop(struct sock *sk)
{
if (dev_recursion_level())
--
1.8.3.1
^ permalink raw reply related
* Re: [RFC PATCH net-next 1/6 v2] net/sched: Introduce act_ct
From: Paul Blakey @ 2019-02-03 8:26 UTC (permalink / raw)
To: Marcelo Leitner
Cc: Paul Blakey, Guy Shattah, Aaron Conole, John Hurley, Simon Horman,
Justin Pettit, Gregory Rose, Eelco Chaudron, Flavio Leitner,
Florian Westphal, Jiri Pirko, Rashid Khan, Sushil Kulkarni,
Andy Gospodarek, Roi Dayan, Yossi Kuperman, Or Gerlitz,
Rony Efraim, davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <20190201132335.GP10660@localhost.localdomain>
On 01/02/2019 15:23, Marcelo Leitner wrote:
> On Tue, Jan 29, 2019 at 10:02:01AM +0200, Paul Blakey wrote:
> ...
>> diff --git a/include/uapi/linux/tc_act/tc_ct.h b/include/uapi/linux/tc_act/tc_ct.h
>> new file mode 100644
>> index 0000000..6dbd771
>> --- /dev/null
>> +++ b/include/uapi/linux/tc_act/tc_ct.h
>> @@ -0,0 +1,29 @@
>> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
>> +#ifndef __UAPI_TC_CT_H
>> +#define __UAPI_TC_CT_H
>> +
>> +#include <linux/types.h>
>> +#include <linux/pkt_cls.h>
>> +
>> +#define TCA_ACT_CT 18
>> +
>> +struct tc_ct {
>> + tc_gen;
>> + __u16 zone;
>> + __u32 labels[4];
>> + __u32 labels_mask[4];
>> + __u32 mark;
>> + __u32 mark_mask;
>> + bool commit;
>
> This is one of the points that our implementations differs. You used a
> struct and wrapped it into TCA_CT_PARMS attribute, while I broke it up
> into several attributes.
>
> cls_flower and act_bpf, for example, doesn't use structs, but others
> do.
>
> Both have pros and cons and I imagine this topic probably was already
> discussed but I'm not aware of a recommendation. Do we have one?
I guess flower uses a netlink attribute per key attribute because
a lot of time, most of them won't be used, and you would send less.
we can have ct, ct + snat, ct + dnat, zone and mark.... a lot of this
won't be used sometimes.
Also you can't add nested attributes to the struct easily.
Also netlink attributes can be tested for existence, while a struct
would need a special non valid value, or another field to specify which
fields are used.
both are hard to test if a requested attribute was ignored, besides
checking the netlink echo or dumping the action back. if for example a
older kernel module and newer userspace uses a attribute above
enum TCA_CT_MAX (struct attributes also don't have max len, in nla_parse).
All in all, I think mostly netlink attributes would be better.
>
>> +};
>> +
>> +enum {
>> + TCA_CT_UNSPEC,
>> + TCA_CT_PARMS,
>> + TCA_CT_TM,
>> + TCA_CT_PAD,
>> + __TCA_CT_MAX
>> +};
>> +#define TCA_CT_MAX (__TCA_CT_MAX - 1)
>> +
>> +#endif /* __UAPI_TC_CT_H */
> ...
>
^ permalink raw reply
* Re: [PATCH mlx5-next 12/12] net/mlx5: Set ODP SRQ support in firmware
From: Leon Romanovsky @ 2019-02-03 9:03 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, RDMA mailing list, Majd Dibbiny, Moni Shoua,
Saeed Mahameed, linux-netdev
In-Reply-To: <20190131232843.GA15062@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]
On Thu, Jan 31, 2019 at 04:28:44PM -0700, Jason Gunthorpe wrote:
> On Tue, Jan 22, 2019 at 08:48:51AM +0200, Leon Romanovsky wrote:
> > From: Moni Shoua <monis@mellanox.com>
> >
> > To avoid compatibility issue with older kernels the firmware doesn't
> > allow SRQ to work with ODP unless kernel asks for it.
> >
> > Signed-off-by: Moni Shoua <monis@mellanox.com>
> > Reviewed-by: Majd Dibbiny <majd@mellanox.com>
> > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > .../net/ethernet/mellanox/mlx5/core/main.c | 53 +++++++++++++++++++
> > include/linux/mlx5/device.h | 3 ++
> > include/linux/mlx5/mlx5_ifc.h | 1 +
> > 3 files changed, 57 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
> > index be81b319b0dc..b3a76df0cf6c 100644
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
> > @@ -459,6 +459,53 @@ static int handle_hca_cap_atomic(struct mlx5_core_dev *dev)
> > return err;
> > }
> >
> > +static int handle_hca_cap_odp(struct mlx5_core_dev *dev)
> > +{
> > + void *set_ctx;
> > + void *set_hca_cap;
> > + int set_sz = MLX5_ST_SZ_BYTES(set_hca_cap_in);
> > + int err;
> > +
> > + if (!MLX5_CAP_GEN(dev, pg))
> > + return 0;
>
> Should a
>
> if (IS_ENABLED(CONFIG_INFINIBAND_ON_DEMAND_PAGING))
> return 0;
>
> Be here?
We had similar discussion in mlx5_ib main.c, but here we are talking
about mlx5_core code, which from my point of view should represent the
real HW capabilities without relation to kernel compilation mode.
Thanks
>
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH net-next V2 1/1] openvswitch: Declare ovs key structures using macros
From: Eli Britstein @ 2019-02-03 9:12 UTC (permalink / raw)
To: Pravin B Shelar
Cc: netdev, dev, Simon Horman, David S. Miller, Ben Pfaff, Roi Dayan,
Eli Britstein
Declare ovs key structures using macros as a pre-step towards to
enable retrieving fields information, as a work done in proposed
commit in the OVS tree https://patchwork.ozlabs.org/patch/1023406/
("odp-util: Do not rewrite fields with the same values as matched"),
with no functional change.
Signed-off-by: Eli Britstein <elibr@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
---
include/uapi/linux/openvswitch.h | 102 ++++++++++++++++++++++++++-------------
1 file changed, 69 insertions(+), 33 deletions(-)
diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
index dbe0cbe4f1b7..dc8246f871fd 100644
--- a/include/uapi/linux/openvswitch.h
+++ b/include/uapi/linux/openvswitch.h
@@ -387,73 +387,109 @@ enum ovs_frag_type {
#define OVS_FRAG_TYPE_MAX (__OVS_FRAG_TYPE_MAX - 1)
+#define OVS_KEY_FIELD_ARR(type, name, elements) type name[elements];
+#define OVS_KEY_FIELD(type, name) type name;
+
+#define OVS_KEY_ETHERNET_FIELDS \
+ OVS_KEY_FIELD_ARR(__u8, eth_src, ETH_ALEN) \
+ OVS_KEY_FIELD_ARR(__u8, eth_dst, ETH_ALEN)
+
struct ovs_key_ethernet {
- __u8 eth_src[ETH_ALEN];
- __u8 eth_dst[ETH_ALEN];
+ OVS_KEY_ETHERNET_FIELDS
};
struct ovs_key_mpls {
__be32 mpls_lse;
};
+#define OVS_KEY_IPV4_FIELDS \
+ OVS_KEY_FIELD(__be32, ipv4_src) \
+ OVS_KEY_FIELD(__be32, ipv4_dst) \
+ OVS_KEY_FIELD(__u8, ipv4_proto) \
+ OVS_KEY_FIELD(__u8, ipv4_tos) \
+ OVS_KEY_FIELD(__u8, ipv4_ttl) \
+ OVS_KEY_FIELD(__u8, ipv4_frag /* One of OVS_FRAG_TYPE_*. */)
+
struct ovs_key_ipv4 {
- __be32 ipv4_src;
- __be32 ipv4_dst;
- __u8 ipv4_proto;
- __u8 ipv4_tos;
- __u8 ipv4_ttl;
- __u8 ipv4_frag; /* One of OVS_FRAG_TYPE_*. */
+ OVS_KEY_IPV4_FIELDS
};
+#define OVS_KEY_IPV6_FIELDS \
+ OVS_KEY_FIELD_ARR(__be32, ipv6_src, 4) \
+ OVS_KEY_FIELD_ARR(__be32, ipv6_dst, 4) \
+ OVS_KEY_FIELD(__be32, ipv6_label /* 20-bits in least-significant bits. */) \
+ OVS_KEY_FIELD(__u8, ipv6_proto) \
+ OVS_KEY_FIELD(__u8, ipv6_tclass) \
+ OVS_KEY_FIELD(__u8, ipv6_hlimit) \
+ OVS_KEY_FIELD(__u8, ipv6_frag /* One of OVS_FRAG_TYPE_*. */)
+
struct ovs_key_ipv6 {
- __be32 ipv6_src[4];
- __be32 ipv6_dst[4];
- __be32 ipv6_label; /* 20-bits in least-significant bits. */
- __u8 ipv6_proto;
- __u8 ipv6_tclass;
- __u8 ipv6_hlimit;
- __u8 ipv6_frag; /* One of OVS_FRAG_TYPE_*. */
+ OVS_KEY_IPV6_FIELDS
};
+#define OVS_KEY_TCP_FIELDS \
+ OVS_KEY_FIELD(__be16, tcp_src) \
+ OVS_KEY_FIELD(__be16, tcp_dst)
+
struct ovs_key_tcp {
- __be16 tcp_src;
- __be16 tcp_dst;
+ OVS_KEY_TCP_FIELDS
};
+#define OVS_KEY_UDP_FIELDS \
+ OVS_KEY_FIELD(__be16, udp_src) \
+ OVS_KEY_FIELD(__be16, udp_dst)
+
struct ovs_key_udp {
- __be16 udp_src;
- __be16 udp_dst;
+ OVS_KEY_UDP_FIELDS
};
+#define OVS_KEY_SCTP_FIELDS \
+ OVS_KEY_FIELD(__be16, sctp_src) \
+ OVS_KEY_FIELD(__be16, sctp_dst)
+
struct ovs_key_sctp {
- __be16 sctp_src;
- __be16 sctp_dst;
+ OVS_KEY_SCTP_FIELDS
};
+#define OVS_KEY_ICMP_FIELDS \
+ OVS_KEY_FIELD(__u8, icmp_type) \
+ OVS_KEY_FIELD(__u8, icmp_code)
+
struct ovs_key_icmp {
- __u8 icmp_type;
- __u8 icmp_code;
+ OVS_KEY_ICMP_FIELDS
};
+#define OVS_KEY_ICMPV6_FIELDS \
+ OVS_KEY_FIELD(__u8, icmpv6_type) \
+ OVS_KEY_FIELD(__u8, icmpv6_code)
+
struct ovs_key_icmpv6 {
- __u8 icmpv6_type;
- __u8 icmpv6_code;
+ OVS_KEY_ICMPV6_FIELDS
};
+#define OVS_KEY_ARP_FIELDS \
+ OVS_KEY_FIELD(__be32, arp_sip) \
+ OVS_KEY_FIELD(__be32, arp_tip) \
+ OVS_KEY_FIELD(__be16, arp_op) \
+ OVS_KEY_FIELD_ARR(__u8, arp_sha, ETH_ALEN) \
+ OVS_KEY_FIELD_ARR(__u8, arp_tha, ETH_ALEN)
+
struct ovs_key_arp {
- __be32 arp_sip;
- __be32 arp_tip;
- __be16 arp_op;
- __u8 arp_sha[ETH_ALEN];
- __u8 arp_tha[ETH_ALEN];
+ OVS_KEY_ARP_FIELDS
};
+#define OVS_KEY_ND_FIELDS \
+ OVS_KEY_FIELD_ARR(__be32, nd_target, 4) \
+ OVS_KEY_FIELD_ARR(__u8, nd_sll, ETH_ALEN) \
+ OVS_KEY_FIELD_ARR(__u8, nd_tll, ETH_ALEN)
+
struct ovs_key_nd {
- __be32 nd_target[4];
- __u8 nd_sll[ETH_ALEN];
- __u8 nd_tll[ETH_ALEN];
+ OVS_KEY_ND_FIELDS
};
+#undef OVS_KEY_FIELD_ARR
+#undef OVS_KEY_FIELD
+
#define OVS_CT_LABELS_LEN_32 4
#define OVS_CT_LABELS_LEN (OVS_CT_LABELS_LEN_32 * sizeof(__u32))
struct ovs_key_ct_labels {
--
2.14.5
^ permalink raw reply related
* Re: [PATCH rdma-next 00/12] Add SRQ and XRC support for ODP MRs
From: Leon Romanovsky @ 2019-02-03 10:54 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, RDMA mailing list, Majd Dibbiny, Moni Shoua,
Saeed Mahameed, linux-netdev
In-Reply-To: <20190131232739.GA13446@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]
On Thu, Jan 31, 2019 at 04:27:39PM -0700, Jason Gunthorpe wrote:
> On Tue, Jan 22, 2019 at 08:48:39AM +0200, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@mellanox.com>
> >
> > Hi,
> >
> > This series extend ODP to work with SRQ and XRC. Being both per-operation
> > (e.g. RDMA write, RDMA read and atomic) and per-transport (e.g. RC, UD and XRC),
> > we extend IB/core and mlx5 driver to provide needed information to user space.
> >
> > Thanks
> >
> > Moni Shoua (12):
> > IB/mlx5: Fix locking SRQ object in ODP event
> > IB/core: Allocate bit for SRQ ODP support
> > IB/uverbs: Expose XRC ODP device capabilities
> > IB/mlx5: Remove useless check in ODP handler
> > IB/mlx5: Clean mlx5_ib_mr_responder_pfault_handler() signature
> > IB/mlx5: Add XRC initiator ODP support
> > IB/mlx5: Let read user wqe also from SRQ buffer
> > IB/mlx5: Add ODP SRQ support
> > IB/mlx5: Advertise SRQ ODP support for supported transports
>
> I applied these patches to for-next
>
> > net/mlx5: Add XRC transport to ODP device capabilities layout
> > IB/mlx5: Advertise XRC ODP support
> > net/mlx5: Set ODP SRQ support in firmware
>
> This might need some re-organizing - the last patch could be split
> (possibly merge with the first) so the header changes can go to the
> shared branch, but the handle_hca_cap_odp() stuff must only be applied
> to the rdma tree.
>
> I'm fine either way, if you don't want to split it send a commit ID
> for the first patch on mlx5-next.
I applied two following patches,
46861e3e88be net/mlx5: Set ODP SRQ support in firmware
dda7a817f287 net/mlx5: Add XRC transport to ODP device capabilities layout
Thanks
>
> Thanks,
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH iproute2-next] devlink: add info subcommand
From: Jiri Pirko @ 2019-02-03 11:04 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: dsahern, stephen, netdev, oss-drivers
In-Reply-To: <20190202140608.27691bbc@cakuba.hsd1.ca.comcast.net>
Sat, Feb 02, 2019 at 11:06:08PM CET, jakub.kicinski@netronome.com wrote:
>On Sat, 2 Feb 2019 16:59:38 +0100, Jiri Pirko wrote:
>> Sat, Feb 02, 2019 at 01:03:38AM CET, jakub.kicinski@netronome.com wrote:
>> >Add support for reading the device serial number and versions
>> >from the kernel.
>> >
>> >RFCv2:
>> > - make info subcommand of dev.
>>
>> Please add some examples of inputs and outputs.
>
>Sorry, yes, will do.
>
>> >Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>> >---
>> > devlink/devlink.c | 207 +++++++++++++++++++++++++++++++++++++++++
>> > man/man8/devlink-dev.8 | 36 +++++++
>> > 2 files changed, 243 insertions(+)
>> >
>> >diff --git a/devlink/devlink.c b/devlink/devlink.c
>> >index 3651e90c1159..3ab046ace8f8 100644
>> >--- a/devlink/devlink.c
>> >+++ b/devlink/devlink.c
>> >@@ -199,6 +199,7 @@ static void ifname_map_free(struct ifname_map *ifname_map)
>> > #define DL_OPT_REGION_SNAPSHOT_ID BIT(22)
>> > #define DL_OPT_REGION_ADDRESS BIT(23)
>> > #define DL_OPT_REGION_LENGTH BIT(24)
>> >+#define DL_OPT_VERSIONS_TYPE BIT(25)
>>
>> Why "type"? Confusing.
>
>Right, I think this dates back to day 1 when the whole thing was called
>versions not info. How about DL_OPT_INFO_VERSION_TYPE?
>
>> >
>> > struct dl_opts {
>> > uint32_t present; /* flags of present items */
>
>> >@@ -943,6 +952,21 @@ static int param_cmode_get(const char *cmodestr,
>> > return 0;
>> > }
>> >
>> >+static int versions_type_get(const char *typestr, int *p_attr)
>> >+{
>> >+ if (strcmp(typestr, "fixed") == 0) {
>> >+ *p_attr = DEVLINK_ATTR_INFO_VERSION_FIXED;
>> >+ } else if (strcmp(typestr, "stored") == 0) {
>> >+ *p_attr = DEVLINK_ATTR_INFO_VERSION_STORED;
>> >+ } else if (strcmp(typestr, "running") == 0) {
>> >+ *p_attr = DEVLINK_ATTR_INFO_VERSION_RUNNING;
>> >+ } else {
>> >+ pr_err("Unknown versions type \"%s\"\n", typestr);
>> >+ return -EINVAL;
>> >+ }
>> >+ return 0;
>> >+}
>> >+
>> > static int dl_argv_parse(struct dl *dl, uint32_t o_required,
>> > uint32_t o_optional)
>> > {
>> >@@ -1178,6 +1202,19 @@ static int dl_argv_parse(struct dl *dl, uint32_t o_required,
>> > if (err)
>> > return err;
>> > o_found |= DL_OPT_REGION_LENGTH;
>> >+ } else if (dl_argv_match(dl, "versions") &&
>> >+ (o_all & DL_OPT_VERSIONS_TYPE)) {
>> >+ const char *versionstr;
>> >+
>> >+ dl_arg_inc(dl);
>> >+ err = dl_argv_str(dl, &versionstr);
>> >+ if (err)
>> >+ return err;
>> >+ err = versions_type_get(versionstr,
>> >+ &opts->versions_attr);
>> >+ if (err)
>> >+ return err;
>> >+ o_found |= DL_OPT_VERSIONS_TYPE;
>> > } else {
>> > pr_err("Unknown option \"%s\"\n", dl_argv(dl));
>> > return -EINVAL;
>> >@@ -1443,6 +1480,9 @@ static void cmd_dev_help(void)
>> > pr_err(" devlink dev param set DEV name PARAMETER value VALUE cmode { permanent | driverinit | runtime }\n");
>> > pr_err(" devlink dev param show [DEV name PARAMETER]\n");
>> > pr_err(" devlink dev reload DEV\n");
>> >+ pr_err(" devlink dev info [ DEV [ { versions [ VTYPE ] } ] ]\n");
>> >+ pr_err("\n");
>> >+ pr_err(" VTYPE := { fixed | running | stored }\n");
>>
>> So you would like to filter according to the version type? Why?
>
>if devlink dev info bus/train versions stored != devlink ... running
>then reboot is needed. That one of main uses for reporting running vs
>stored in sections, it's nice to be able to just compare the outputs.
I don't know. In the "info", there are more things than versions. Also,
I believe in near future there are going to be even more things there.
Providing a filtering option for one item and not for other seems
incorrect. I think that devlink should not filter in this case. Let it
dump the whole output and let the user take care of it by other tools.
Each tool should do one thing.
^ 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