* 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
* [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: [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
* 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
* 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
* [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: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
* 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
* 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] 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] 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] 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] 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 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 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
* 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
* [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
* 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
* 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] 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 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
* Still need this?
From: Grace @ 2019-02-02 11:16 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
Wordms
Ansbadch
^ permalink raw reply
* [PATCH] Bluetooth: Fix decrementing reference count twice in releasing socket
From: Myungho Jung @ 2019-02-03 0:56 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, David S. Miller
Cc: linux-bluetooth, netdev, linux-kernel
When releasing socket, it is possible to enter hci_sock_release() and
hci_sock_dev_event(HCI_DEV_UNREG) at the same time in different thread.
The reference count of hdev should be decremented only once from one of
them but if storing hdev to local variable in hci_sock_release() before
detached from socket and setting to NULL in hci_sock_dev_event(),
hci_dev_put(hdev) is unexpectedly called twice. This is resolved by
referencing hdev from socket after bt_sock_unlink() in
hci_sock_release().
Reported-by: syzbot+fdc00003f4efff43bc5b@syzkaller.appspotmail.com
Signed-off-by: Myungho Jung <mhjungk@gmail.com>
---
net/bluetooth/hci_sock.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
index 1506e1632394..d4e2a166ae17 100644
--- a/net/bluetooth/hci_sock.c
+++ b/net/bluetooth/hci_sock.c
@@ -831,8 +831,6 @@ static int hci_sock_release(struct socket *sock)
if (!sk)
return 0;
- hdev = hci_pi(sk)->hdev;
-
switch (hci_pi(sk)->channel) {
case HCI_CHANNEL_MONITOR:
atomic_dec(&monitor_promisc);
@@ -854,6 +852,7 @@ static int hci_sock_release(struct socket *sock)
bt_sock_unlink(&hci_sk_list, sk);
+ hdev = hci_pi(sk)->hdev;
if (hdev) {
if (hci_pi(sk)->channel == HCI_CHANNEL_USER) {
/* When releasing a user channel exclusive access,
--
2.17.1
^ permalink raw reply related
* Re: [RFC 00/14] netlink/hierarchical stats
From: Roopa Prabhu @ 2019-02-02 23:14 UTC (permalink / raw)
To: Jakub Kicinski
Cc: David Miller, oss-drivers, netdev, Jiří Pírko,
Florian Fainelli, Andrew Lunn, Michal Kubecek, David Ahern,
Simon Horman, Brandeburg, Jesse, Maciek Fijałkowski,
vasundhara-v.volam, Michael Chan, shalomt, Ido Schimmel
In-Reply-To: <20190131113048.45bd149a@cakuba.hsd1.ca.comcast.net>
On Thu, Jan 31, 2019 at 11:31 AM Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
>
> On Thu, 31 Jan 2019 08:31:51 -0800, Roopa Prabhu wrote:
> > On Thu, Jan 31, 2019 at 8:16 AM Roopa Prabhu wrote:
> > > On Wed, Jan 30, 2019 at 4:24 PM Jakub Kicinski wrote:
> > > > On Wed, 30 Jan 2019 14:14:34 -0800, Roopa Prabhu wrote:
> > > >
> > > > My thinking was that we should leave truly custom/strange stats to
> > > > ethtool API which works quite well for that and at the same time be
> > > > very accepting of people adding new IDs to HSTAT (only requirement is
> > > > basically defining the meaning very clearly).
> > >
> > > that sounds reasonable. But the 'defining meaning clearly' gets tricky
> > > sometimes.
> > > The vendor who gets their ID or meaning first wins :) and the rest
> > > will have to live with
> > > ethtool and explain to rest of the world that ethtool is more reliable
> > > for their hardware :)
>
> Right, that's the trade off inherent to standardization. I don't see
> any way to work around the fact that the definition may not fit all.
>
> What I want as a end user and what I want for my customers is the
> ability to switch the NIC on their system and not spend two months
> "integrating" into their automation :( If the definition of statistics
> is not solid we're back to square one.
agree. And I am with you on standardizing them.
>
> > > I am also concerned that this getting the ID into common HSTAT ID
> > > space will slow down the process of adding new counters
> > > for vendors. Which will lead to vendors sticking with ethtool API.
>
> I feel like whatever we did here will end up looking much like the
> ethtool interface, which is why I decided to leave that part out.
> Ethtool -S works pretty well for custom stats. Standard and structured
> stats don't fit with it in any way, the two seem best left separate.
understand the fear. My only point was getting them together in a
single API is better so that they don't get developed separately and
we don't end up with duplicate stats code.
>
> > > It would be great if people can get all stats in one place and not
> > > rely on another API for 'more'.
>
> One place in the driver or for the user? I'm happy to add the code to
> ethtool to also dump hstats and render them in a standard way. In fact
> the tool I have for testing has a "simplified" output format which
> looks exactly like ethtool -S.
>
> One place for the driver to report is hard, as I said I think the
> custom stats are best left with ethtool. Adding an extra incentive to
> standardize.
>
> > > > For the first stab I looked at two drivers and added all the stats that
> > > > were common.
> > > >
> > > > Given this set is identifying statistics by ID - how would we make that
> > > > extensible to drivers? Would we go back to strings or have some
> > > > "driver specific" ID space?
> > >
> > > I was looking for ideas from you really, to see if you had considered
> > > this. agree per driver ID space seems ugly.
> > > ethtool strings are great today...if we can control the duplication.
> > > But thinking some more..., i did see some
> > > patches recently for vendor specific parameter (with ID) space in
> > > devlink. maybe something like that will be
> > > reasonable ?
>
> I thought about this for a year and I basically came to the conclusion
> I can't find any perfect solution, if there is one.
>
> The devlink parameters are useful, but as anticipated they became the
> laziest excuse of an ABI... Don't get me started ;)
>
> > > > Is there any particular type of statistic you'd expect drivers to want
> > > > to add? For NICs I think IEEE/RMON should pretty much cover the
> > > > silicon ones, but I don't know much about switches :)
> > >
> > > I will have to go through the list. But switch asics do support
> > > flexible stats/counters that can be attached at various points.
> > > And new chip versions come with more support. Having that flexibility
> > > to expose/extend such stats incrementally is very valuable on a per
> > > hardware/vendor basis.
>
> Yes, I'm not too familiar with those counters. Do they need to be
> enabled to start counting?
yes correct.
> Do they have performance impact?
I have not heard of any performance impact...but they are not enabled
by default because of limited counter resource pool.
> Can the
> "sample" events perf-style?
I don't think so
> How is the condition on which they trigger
> defined? Is it maybe just "match a packet and increment a counter"?
yes, something like that.
> Would such counters benefit from hierarchical structure?
hmm not sure.
One thing though, for most of these flexible counters and their
attachment points in hardware, we can count them on logical devices or
other objects in software like per vlan, vni, route stats etc.
>
> I was trying to cover the long standing use cases - namely the
> IEEE/RMON stats which all MAC have had for years and per queue stats
> which all drivers have had for years. But if we can cater to more
> cases I'm open.
>
> > Just want to clarify that I am suggesting a nested HSTATS extension
> > infra for drivers (just like ethtool).
> > 'Common stats' stays at the top-level.
>
> I got a concept of groups here. The dump generally looks like this:
>
> [root group A (say MAC stats)]
> [sub group RX]
> [sub group TX]
> [root group B (say PCIe stats)]
> [sub group RX]
> [sub group TX]
> [root group C (say per-q driver stats]
> [sub group RX]
> [q1 group]
> [q2 group]
> [q3 group]
> [sub group TX]
> [q1 group]
> [q2 group]
> [q3 group]
>
> Each root group representing a "point in the pipeline".
>
> So it's not too hard to add a root group with whatever, the questions
> are move how would it benefit over existing ethtool if the stats are
> custom anyway? Hm..
It wouldn't. I am only saying that the netlink stats API is the new
place to move stats.
Ethtool stats will have to move to netlink some day and I don't see a
need to draw a hardline on saying no to ethtool custom stats moving to
the netlink based common stats API. And unless there is a good
migration path for a new hardware stats API that is all inclusive,
there is a higher chance of continued development on the older
hardware stats API.
I have no objections to having a standard set of stats (this is
essentially what we have for software stats too).
I don't want to block your series from going forward without HW custom
stats extensions. And IIUC your API is extensible and does not
preclude anyone from adding the ability to include HW custom stats
extensions in the future with enough justification. That is good for
me.
To take a random example, we expose the following stats on our
switches via ethtool. I have not used them personally but they
correspond to respective hardware counters. Is there any room for such
stats in the new HSTATS netlink API or they will have to stick to
ethtool ?
I believe people will need per-queue counters for this.
HwIfOutWredDrops: 0
HwIfOutQ0WredDrops: 0
HwIfOutQ1WredDrops: 0
HwIfOutQ2WredDrops: 0
HwIfOutQ3WredDrops: 0
HwIfOutQ4WredDrops: 0
HwIfOutQ5WredDrops: 0
HwIfOutQ6WredDrops: 0
HwIfOutQ7WredDrops: 0
HwIfOutQ8WredDrops: 0
HwIfOutQ9WredDrops: 0
^ permalink raw reply
* Re: Bluetooth: hci0: last event is not cmd complete (0x0f) with LG TV
From: Paul Menzel @ 2019-02-02 22:31 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg
Cc: David S. Miller, linux-bluetooth, netdev, LKML
In-Reply-To: <f2384806-ad02-4a6d-895c-9e07c4add513@molgen.mpg.de>
[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]
Dear Linux folks,
On 01.02.19 22:34, Paul Menzel wrote:
> [attaching Linux messages, lspci and lsusb output]
>
> On 01.02.19 22:20, Paul Menzel wrote:
>> When trying to pair a Dell Latitude E7250 running Debian Sid/unstable
>> with Linux 4.20 and GNOME 3.30 with an LG TV, after starting the
>> pairing process the TV is listed. in Bluetooth dialog of GNOME setting.
>>
>> The TV displays the instructions below.
>>
>>> Complete the next three steps on your mobile device:
>>> 1. Turn ON Bluetooth.
>>> 2. Select the TV name from the list of available devices.
>>> • TV Name : 679
>>> 3. Confirm the connection request.
>>
>> Selecting the TV in the GNOME dialog, a dialog is shown on my system
>> with a PIN consisting of six numbers. With the dialog, Linux logs the
>> message below.
>>
>> Bluetooth: hci0: last event is not cmd complete (0x0f)
>>
>> But, the TV does not show any PIN. Confirming it anyway, nothing is
>> happening further.
>>
>> Is that supposed to work? It’d be great if you helped me to set this up.
Please find a trace attached. This time Linux 4.19.16 was running.
sudo tcpdump -i bluetooth0 -w bluetooth0_capture.pcap
Kind regards,
Paul
[-- Attachment #2: bluetooth0_capture.pcap --]
[-- Type: application/vnd.tcpdump.pcap, Size: 33808 bytes --]
^ 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