* Re: bpfilter causes a leftover kernel process
From: Olivier Brunel @ 2018-08-27 16:31 UTC (permalink / raw)
To: netdev; +Cc: Olivier Brunel
In-Reply-To: <20180826180816.04ef7d16@jjacky.com>
Small addentum: Of course I failed to realize this bpfilter helper is
also mentioned in the kernel log:
kern.info: [ 8.997711] bpfilter: Loaded bpfilter_umh pid 920
It also seems to be absolutely required when CONFIG_BPFILTER is
enabled, that is I tried blacklisting the module bpfilter, but then
other things (e.g. iptables-restore) just fail to work.
So the process is required, never ends and prevents umouting the
rootfs on shutdown. Unless I'm missing something, there's definitely a
bug there?
Thanks,
^ permalink raw reply
* Re: [PATCH v2 iproute2-next 1/3] tc: support conversions to or from 64 bit nanosecond-based time
From: Dave Taht @ 2018-08-27 16:39 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Yousuk Seung, Linux Kernel Network Developers, David Ahern,
Michael McLennan, Priyaranjan Jha, Neal Cardwell
In-Reply-To: <20180827091156.46691f4f@shemminger-XPS-13-9360>
On Mon, Aug 27, 2018 at 9:11 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Sun, 26 Aug 2018 19:42:28 -0700
> Yousuk Seung <ysseung@google.com> wrote:
>
> > +int get_time(unsigned int *time, const char *str)
> > +{
> > + double t;
> > + char *p;
> > +
> > + t = strtod(str, &p);
> > + if (p == str)
> > + return -1;
> > +
> > + if (*p) {
> > + if (strcasecmp(p, "s") == 0 || strcasecmp(p, "sec") == 0 ||
> > + strcasecmp(p, "secs") == 0)
> > + t *= TIME_UNITS_PER_SEC;
> > + else if (strcasecmp(p, "ms") == 0 || strcasecmp(p, "msec") == 0 ||
> > + strcasecmp(p, "msecs") == 0)
> > + t *= TIME_UNITS_PER_SEC/1000;
> > + else if (strcasecmp(p, "us") == 0 || strcasecmp(p, "usec") == 0 ||
> > + strcasecmp(p, "usecs") == 0)
> > + t *= TIME_UNITS_PER_SEC/1000000;
> > + else
> > + return -1;
>
> Do we need to really support UPPER case.
But that's ALWAYS been the case in the 32 bit version of code above.
Imagine how many former VMS and MVS hackers you'd upset if they had to
turn caps-lock off!
> Isn't existing matches semantics good enough?
But that's the existing case for the 32 bit api, now replicated in the
64 bit api. ? I think the case-insensitive ship has sailed here. Can't
break userspace.
Well.. adding UTF-8 would be cool. We could start using the actual
greek symbols for delta (δ) and beta (β) in particular. It would
replace a lot of typing, with a whole bunch more shift keys on a
single letter, fit better into
80 column lines, and so on, and tc inputs and outputs are already
pretty greek to many.
^ permalink raw reply
* [PATCH 2/2] net/ibm/emac: deletion of unneeded macros definitions
From: Ivan Mikhaylov @ 2018-08-27 16:43 UTC (permalink / raw)
To: netdev; +Cc: David S . Miller, Christian Lamparter, linux-kernel
Signed-off-by: Ivan Mikhaylov <ivan@de.ibm.com>
---
drivers/net/ethernet/ibm/emac/emac.h | 7 -------
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/ibm/emac/emac.h b/drivers/net/ethernet/ibm/emac/emac.h
index e2f80cc..f541660 100644
--- a/drivers/net/ethernet/ibm/emac/emac.h
+++ b/drivers/net/ethernet/ibm/emac/emac.h
@@ -229,7 +229,6 @@ struct emac_regs {
#define EMAC_STACR_PHYD_SHIFT 16
#define EMAC_STACR_OC 0x00008000
#define EMAC_STACR_PHYE 0x00004000
-#define EMAC_STACR_STAC_MASK 0x00003000
#define EMAC_STACR_STAC_READ 0x00001000
#define EMAC_STACR_STAC_WRITE 0x00000800
#define EMAC_STACR_OPBC_MASK 0x00000C00
@@ -245,14 +244,8 @@ struct emac_regs {
#define EMAC_STACR_PCDA_MASK 0x1f
#define EMAC_STACR_PCDA_SHIFT 5
#define EMAC_STACR_PRA_MASK 0x1f
-#define EMACX_STACR_STAC_MASK 0x00003800
#define EMACX_STACR_STAC_READ 0x00001000
#define EMACX_STACR_STAC_WRITE 0x00000800
-#define EMACX_STACR_STAC_IND_ADDR 0x00002000
-#define EMACX_STACR_STAC_IND_READ 0x00003800
-#define EMACX_STACR_STAC_IND_READINC 0x00003000
-#define EMACX_STACR_STAC_IND_WRITE 0x00002800
-
/* EMACx_TRTR */
#define EMAC_TRTR_SHIFT_EMAC4 24
^ permalink raw reply related
* Re: any reason for "!!netif_carrier_ok" and "!!netif_dormant" in net-sysfs.c?
From: Eric Dumazet @ 2018-08-27 16:45 UTC (permalink / raw)
To: rpjday, David Miller; +Cc: netdev
In-Reply-To: <20180827121623.Horde.Jfv_6y4hNg2t7I9Trd8TLaD@crashcourse.ca>
On 08/27/2018 09:16 AM, rpjday@crashcourse.ca wrote:
>
> Quoting David Miller <davem@davemloft.net>:
>
>> From: "Robert P. J. Day" <rpjday@crashcourse.ca>
>> Date: Mon, 27 Aug 2018 04:55:29 -0400 (EDT)
>>
>>> another pedantic oddity -- is there a reason for these two double
>>> negations in net/core/net-sysfs.c?
>>
>> It turns an arbitrary integer into a boolean, this is a common
>> construct across the kernel tree so I'm surprised you've never seen
>> it before.
>>
>> Although, I don't know how much more hand holding we're willing to
>> tolerate continuing to give to you at this point.
>>
>> Thanks.
>
> I mentioned in my earlier email that I know what that construct is
> *typically* used for; I also pointed out that, AFAICT, it was totally
> unnecessary in the context of the two routines I mentioned, which
> would appear to ever return only one of two boolean values, 0 or 1.
>
> My experience with kernel code is that one should not introduce
> unnecessary complexities, which suggests (as I stated) that there
> seems to be no value in the "!!" construct *in those particular
> cases*, hence my curiosity.
Have you checked git history ?
My guess is that netif_carrier_ok() used to return an int, not a bool.
!!netif_carrier_ok() was not complexity, it was probably shorter than
the form used in
u32 ethtool_op_get_link(struct net_device *dev)
{
return netif_carrier_ok(dev) ? 1 : 0;
}
But really, this is really trivial stuff, we have more interesting stuff
to take care of these days.
^ permalink raw reply
* Re: any reason for "!!netif_carrier_ok" and "!!netif_dormant" in net-sysfs.c?
From: rpjday @ 2018-08-27 16:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <3b4857e3-f2a6-104a-0370-7c41e2f755e8@gmail.com>
Quoting Eric Dumazet <eric.dumazet@gmail.com>:
> On 08/27/2018 09:16 AM, rpjday@crashcourse.ca wrote:
>>
>> Quoting David Miller <davem@davemloft.net>:
>>
>>> From: "Robert P. J. Day" <rpjday@crashcourse.ca>
>>> Date: Mon, 27 Aug 2018 04:55:29 -0400 (EDT)
>>>
>>>> another pedantic oddity -- is there a reason for these two double
>>>> negations in net/core/net-sysfs.c?
>>>
>>> It turns an arbitrary integer into a boolean, this is a common
>>> construct across the kernel tree so I'm surprised you've never seen
>>> it before.
>>>
>>> Although, I don't know how much more hand holding we're willing to
>>> tolerate continuing to give to you at this point.
>>>
>>> Thanks.
>>
>> I mentioned in my earlier email that I know what that construct is
>> *typically* used for; I also pointed out that, AFAICT, it was totally
>> unnecessary in the context of the two routines I mentioned, which
>> would appear to ever return only one of two boolean values, 0 or 1.
>>
>> My experience with kernel code is that one should not introduce
>> unnecessary complexities, which suggests (as I stated) that there
>> seems to be no value in the "!!" construct *in those particular
>> cases*, hence my curiosity.
>
> Have you checked git history ?
>
> My guess is that netif_carrier_ok() used to return an int, not a bool.
>
> !!netif_carrier_ok() was not complexity, it was probably shorter than
> the form used in
>
> u32 ethtool_op_get_link(struct net_device *dev)
> {
> return netif_carrier_ok(dev) ? 1 : 0;
> }
>
> But really, this is really trivial stuff, we have more interesting stuff
> to take care of these days.
Point taken -- for trivialities like this, I'll check Git history, and
apologies for the noise on that one.
rday
^ permalink raw reply
* Re: any reason for "!!netif_carrier_ok" and "!!netif_dormant" in net-sysfs.c?
From: Joe Perches @ 2018-08-27 16:54 UTC (permalink / raw)
To: rpjday, David Miller; +Cc: netdev
In-Reply-To: <20180827121623.Horde.Jfv_6y4hNg2t7I9Trd8TLaD@crashcourse.ca>
On Mon, 2018-08-27 at 12:16 -0400, rpjday@crashcourse.ca wrote:
> Quoting David Miller <davem@davemloft.net>:
>
> > From: "Robert P. J. Day" <rpjday@crashcourse.ca>
> > Date: Mon, 27 Aug 2018 04:55:29 -0400 (EDT)
> >
> > > another pedantic oddity -- is there a reason for these two double
> > > negations in net/core/net-sysfs.c?
> >
> > It turns an arbitrary integer into a boolean, this is a common
> > construct across the kernel tree so I'm surprised you've never seen
> > it before.
> >
> > Although, I don't know how much more hand holding we're willing to
> > tolerate continuing to give to you at this point.
> >
> > Thanks.
>
> I mentioned in my earlier email that I know what that construct is
> *typically* used for; I also pointed out that, AFAICT, it was totally
> unnecessary in the context of the two routines I mentioned, which
> would appear to ever return only one of two boolean values, 0 or 1.
Both are bool functions, so it's guaranteed and the
!! uses are redundant.
include/linux/netdevice.h:static inline bool netif_carrier_ok(const struct net_device *dev)
include/linux/netdevice.h:static inline bool netif_dormant(const struct net_device *dev)
And there are 4 uses with !!
$ git grep -P '\!\s*\!\s*netif_(?:dormant|carrier_ok)\s*\('
drivers/net/team/team.c: __team_port_change_port_added(port, !!netif_carrier_ok(port_dev));
drivers/net/usb/r8152.c: bool sw_linking = !!netif_carrier_ok(tp->netdev);
net/core/net-sysfs.c: return sprintf(buf, fmt_dec, !!netif_carrier_ok(netdev));
net/core/net-sysfs.c: return sprintf(buf, fmt_dec, !!netif_dormant(netdev));
out of the ~400 or so treewide.
Only redeeming use of the !! is the fmt_dec expects
an int and this forces the type to int, though the
compiler would do that automatically anyway.
I'd suggest removing the fmt_<foo> uses for clarity.
---
net/core/net-sysfs.c | 49 ++++++++++++++++++++++---------------------------
1 file changed, 22 insertions(+), 27 deletions(-)
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index bd67c4d0fcfd..ecaa684f4b92 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -31,11 +31,6 @@
#include "net-sysfs.h"
#ifdef CONFIG_SYSFS
-static const char fmt_hex[] = "%#x\n";
-static const char fmt_dec[] = "%d\n";
-static const char fmt_ulong[] = "%lu\n";
-static const char fmt_u64[] = "%llu\n";
-
static inline int dev_isalive(const struct net_device *dev)
{
return dev->reg_state <= NETREG_REGISTERED;
@@ -107,26 +102,26 @@ static ssize_t netdev_store(struct device *dev, struct device_attribute *attr,
return ret;
}
-NETDEVICE_SHOW_RO(dev_id, fmt_hex);
-NETDEVICE_SHOW_RO(dev_port, fmt_dec);
-NETDEVICE_SHOW_RO(addr_assign_type, fmt_dec);
-NETDEVICE_SHOW_RO(addr_len, fmt_dec);
-NETDEVICE_SHOW_RO(ifindex, fmt_dec);
-NETDEVICE_SHOW_RO(type, fmt_dec);
-NETDEVICE_SHOW_RO(link_mode, fmt_dec);
+NETDEVICE_SHOW_RO(dev_id, "%#x\n");
+NETDEVICE_SHOW_RO(dev_port, "%d\n");
+NETDEVICE_SHOW_RO(addr_assign_type, "%d\n");
+NETDEVICE_SHOW_RO(addr_len, "%d\n");
+NETDEVICE_SHOW_RO(ifindex, "%d\n");
+NETDEVICE_SHOW_RO(type, "%d\n");
+NETDEVICE_SHOW_RO(link_mode, "%d\n");
static ssize_t iflink_show(struct device *dev, struct device_attribute *attr,
char *buf)
{
struct net_device *ndev = to_net_dev(dev);
- return sprintf(buf, fmt_dec, dev_get_iflink(ndev));
+ return sprintf(buf, "%d\n", dev_get_iflink(ndev));
}
static DEVICE_ATTR_RO(iflink);
static ssize_t format_name_assign_type(const struct net_device *dev, char *buf)
{
- return sprintf(buf, fmt_dec, dev->name_assign_type);
+ return sprintf(buf, "%d\n", dev->name_assign_type);
}
static ssize_t name_assign_type_show(struct device *dev,
@@ -188,7 +183,7 @@ static ssize_t carrier_show(struct device *dev,
struct net_device *netdev = to_net_dev(dev);
if (netif_running(netdev))
- return sprintf(buf, fmt_dec, !!netif_carrier_ok(netdev));
+ return sprintf(buf, "%d\n", !!netif_carrier_ok(netdev));
return -EINVAL;
}
@@ -207,7 +202,7 @@ static ssize_t speed_show(struct device *dev,
struct ethtool_link_ksettings cmd;
if (!__ethtool_get_link_ksettings(netdev, &cmd))
- ret = sprintf(buf, fmt_dec, cmd.base.speed);
+ ret = sprintf(buf, "%d\n", cmd.base.speed);
}
rtnl_unlock();
return ret;
@@ -254,7 +249,7 @@ static ssize_t dormant_show(struct device *dev,
struct net_device *netdev = to_net_dev(dev);
if (netif_running(netdev))
- return sprintf(buf, fmt_dec, !!netif_dormant(netdev));
+ return sprintf(buf, "%d\n", !!netif_dormant(netdev));
return -EINVAL;
}
@@ -295,7 +290,7 @@ static ssize_t carrier_changes_show(struct device *dev,
{
struct net_device *netdev = to_net_dev(dev);
- return sprintf(buf, fmt_dec,
+ return sprintf(buf, "%d\n",
atomic_read(&netdev->carrier_up_count) +
atomic_read(&netdev->carrier_down_count));
}
@@ -307,7 +302,7 @@ static ssize_t carrier_up_count_show(struct device *dev,
{
struct net_device *netdev = to_net_dev(dev);
- return sprintf(buf, fmt_dec, atomic_read(&netdev->carrier_up_count));
+ return sprintf(buf, "%d\n", atomic_read(&netdev->carrier_up_count));
}
static DEVICE_ATTR_RO(carrier_up_count);
@@ -317,7 +312,7 @@ static ssize_t carrier_down_count_show(struct device *dev,
{
struct net_device *netdev = to_net_dev(dev);
- return sprintf(buf, fmt_dec, atomic_read(&netdev->carrier_down_count));
+ return sprintf(buf, "%d\n", atomic_read(&netdev->carrier_down_count));
}
static DEVICE_ATTR_RO(carrier_down_count);
@@ -333,7 +328,7 @@ static ssize_t mtu_store(struct device *dev, struct device_attribute *attr,
{
return netdev_store(dev, attr, buf, len, change_mtu);
}
-NETDEVICE_SHOW_RW(mtu, fmt_dec);
+NETDEVICE_SHOW_RW(mtu, "%d\n");
static int change_flags(struct net_device *dev, unsigned long new_flags)
{
@@ -345,7 +340,7 @@ static ssize_t flags_store(struct device *dev, struct device_attribute *attr,
{
return netdev_store(dev, attr, buf, len, change_flags);
}
-NETDEVICE_SHOW_RW(flags, fmt_hex);
+NETDEVICE_SHOW_RW(flags, "%#x\n");
static ssize_t tx_queue_len_store(struct device *dev,
struct device_attribute *attr,
@@ -356,7 +351,7 @@ static ssize_t tx_queue_len_store(struct device *dev,
return netdev_store(dev, attr, buf, len, dev_change_tx_queue_len);
}
-NETDEVICE_SHOW_RW(tx_queue_len, fmt_dec);
+NETDEVICE_SHOW_RW(tx_queue_len, "%d\n");
static int change_gro_flush_timeout(struct net_device *dev, unsigned long val)
{
@@ -373,7 +368,7 @@ static ssize_t gro_flush_timeout_store(struct device *dev,
return netdev_store(dev, attr, buf, len, change_gro_flush_timeout);
}
-NETDEVICE_SHOW_RW(gro_flush_timeout, fmt_ulong);
+NETDEVICE_SHOW_RW(gro_flush_timeout, "%lu\n");
static ssize_t ifalias_store(struct device *dev, struct device_attribute *attr,
const char *buf, size_t len)
@@ -431,7 +426,7 @@ static ssize_t group_store(struct device *dev, struct device_attribute *attr,
{
return netdev_store(dev, attr, buf, len, change_group);
}
-NETDEVICE_SHOW(group, fmt_dec);
+NETDEVICE_SHOW(group, "%d\n");
static DEVICE_ATTR(netdev_group, 0644, group_show, group_store);
static int change_proto_down(struct net_device *dev, unsigned long proto_down)
@@ -445,7 +440,7 @@ static ssize_t proto_down_store(struct device *dev,
{
return netdev_store(dev, attr, buf, len, change_proto_down);
}
-NETDEVICE_SHOW_RW(proto_down, fmt_dec);
+NETDEVICE_SHOW_RW(proto_down, "%d\n");
static ssize_t phys_port_id_show(struct device *dev,
struct device_attribute *attr, char *buf)
@@ -568,7 +563,7 @@ static ssize_t netstat_show(const struct device *d,
struct rtnl_link_stats64 temp;
const struct rtnl_link_stats64 *stats = dev_get_stats(dev, &temp);
- ret = sprintf(buf, fmt_u64, *(u64 *)(((u8 *)stats) + offset));
+ ret = sprintf(buf, "%llu\n", *(u64 *)(((u8 *)stats) + offset));
}
read_unlock(&dev_base_lock);
return ret;
^ permalink raw reply related
* Re: [PATCH RFC net-next] net/fib: Poptrie based FIB lookup
From: David Ahern @ 2018-08-27 16:56 UTC (permalink / raw)
To: Stephen Hemminger, Md. Islam
Cc: Netdev, David Miller, Eric Dumazet, Alexey Kuznetsov,
makita.toshiaki, panda, yasuhiro.ohara, john.fastabend,
alexei.starovoitov
In-Reply-To: <20180827092420.791bb1ad@shemminger-XPS-13-9360>
On 8/27/18 10:24 AM, Stephen Hemminger wrote:
>
> Also, as Dave mentioned any implementation needs to handle multiple namespaces
> and routing tables.
>
> Could this alternative lookup be enabled via sysctl at runtime rather than kernel config?
>
I spent time a couple of years ago refactoring IPv4 fib lookups with the
intent of allowing different algorithms - for use cases like this:
https://github.com/dsahern/linux/commits/net/ipv4-fib-ops
(it is also another way to solve the API nightmare that ipv6 has become).
But the poptrie patches that have been sent so far have much bigger
problems that need to be addressed before anyone worries about how to
select poptrie vs lc-trie.
The patch does not handle errors (e.g., if attributes such as tos,
metric/priority and multipath are not allowed you need to fail the route
insert; further, what happens if someone creates > 255 netdevices?),
last patch has both fib tables populated (a no-go), does not handle
delete or dumps. In the current form, the poptrie algorithm can not be
taken for a test drive. My suggestion to make it a compile time
selection is just so people can actually try it out using current admin
tools.
^ permalink raw reply
* Re: [PATCH net] net: sungem: fix rx checksum support
From: Eric Dumazet @ 2018-08-27 16:57 UTC (permalink / raw)
To: Meelis Roos
Cc: Eric Dumazet, David Miller, netdev, Mathieu Malaterre,
Andreas Schwab
In-Reply-To: <alpine.LRH.2.21.1808261612040.22219@math.ut.ee>
On Sun, Aug 26, 2018 at 6:14 AM <mroos@linux.ee> wrote:
>
> > BTW, removing the FCS also means GRO is going to work, finally on this NIC ;)
> >
> > GRO does not like packets with padding.
>
> As a follow-up, I am seeing hw csum failures on Sun V440 that has
> onboard Sun Cassini with sungem driver. First tested version was 4.18
> (it happened there once) and now that I tried 4.18+git, it still
> happens:
>
> [ 21.563282] libphy: Fixed MDIO Bus: probed
> [ 21.617116] cassini: cassini.c:v1.6 (21 May 2008)
> [ 21.678962] cassini 0000:00:02.0: enabling device (0144 -> 0146)
> [ 21.761931] cassini 0000:00:02.0 eth0: Sun Cassini+ (64bit/66MHz PCI/Cu) Ethernet[6] 00:03:ba:6f:14:39
> [ 21.884952] cassini 0003:00:01.0: enabling device (0144 -> 0146)
> [ 21.967868] cassini 0003:00:01.0 eth1: Sun Cassini+ (64bit/66MHz PCI/Cu) Ethernet[29] 00:03:ba:6f:14:3a
> [...]
> [ 54.341212] eth0: hw csum failure
> [ 54.384725] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.18.0-12952-g2923b27 #1397
> [ 54.483167] Call Trace:
> [ 54.515209] [000000000077838c] __skb_checksum_complete+0xcc/0xe0
> [ 54.595272] [000000000080fc84] igmp_rcv+0x224/0x920
> [ 54.660475] [00000000007ca3d0] ip_local_deliver+0xb0/0x240
> [ 54.733675] [00000000007ca5c0] ip_rcv+0x60/0xa0
> [ 54.794304] [0000000000781a30] __netif_receive_skb_one_core+0x30/0x60
> [ 54.880094] [0000000000782914] process_backlog+0x94/0x140
> [ 54.952161] [0000000000788f6c] net_rx_action+0x1ec/0x320
> [ 55.023083] [0000000000870de8] __do_softirq+0xc8/0x200
> [ 55.091719] [000000000042c4cc] do_softirq_own_stack+0x2c/0x40
> [ 55.168362] [00000000004662d8] irq_exit+0xb8/0xe0
> [ 55.231266] [0000000000870ac0] handler_irq+0xc0/0x100
> [ 55.298756] [00000000004208b4] tl0_irq5+0x14/0x20
> [ 55.361670] [000000000042cafc] arch_cpu_idle+0x9c/0xa0
> [ 55.447055] [000000000048a254] cpu_startup_entry+0x14/0x40
> [ 55.536998] [000000000095f4b4] 0x95f4b4
> [ 55.588471] [0000000040000000] 0x40000000
> [ 179.780371] eth0: hw csum failure
> [ 179.823878] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.18.0-12952-g2923b27 #1397
> [ 179.922230] Call Trace:
> [ 179.954267] [000000000077838c] __skb_checksum_complete+0xcc/0xe0
> [ 180.034335] [000000000080fc84] igmp_rcv+0x224/0x920
> [ 180.099536] [00000000007ca3d0] ip_local_deliver+0xb0/0x240
> [ 180.172740] [00000000007ca5c0] ip_rcv+0x60/0xa0
> [ 180.233368] [0000000000781a30] __netif_receive_skb_one_core+0x30/0x60
> [ 180.319159] [0000000000782914] process_backlog+0x94/0x140
> [ 180.391225] [0000000000788f6c] net_rx_action+0x1ec/0x320
> [ 180.462148] [0000000000870de8] __do_softirq+0xc8/0x200
> [ 180.530782] [000000000042c4cc] do_softirq_own_stack+0x2c/0x40
> [ 180.607422] [00000000004662d8] irq_exit+0xb8/0xe0
> [ 180.670331] [0000000000870ac0] handler_irq+0xc0/0x100
> [ 180.737822] [00000000004208b4] tl0_irq5+0x14/0x20
> [ 180.800735] [000000000042caf8] arch_cpu_idle+0x98/0xa0
> [ 180.869373] [0000000000489f60] do_idle+0xe0/0x1c0
> [ 180.932281] [000000000048a25c] cpu_startup_entry+0x1c/0x40
> [ 181.005491] [000000000098e9b4] start_kernel+0x3b8/0x3c8
Note that these traces are for non TCP packets.
I suspect the driver should not provide CHECKSUM_COMPLETE for non TCP
packets, maybe the NIC is mishandling this case.
^ permalink raw reply
* Re: [PATCH net-next 02/10] dt-bindings: net: ocelot: remove hsio from the list of register address spaces
From: Alexandre Belloni @ 2018-08-27 20:57 UTC (permalink / raw)
To: Quentin Schulz
Cc: Rob Herring, ralf, paul.burton, jhogan, mark.rutland, davem,
kishon, andrew, f.fainelli, linux-mips, devicetree, linux-kernel,
netdev, allan.nielsen, thomas.petazzoni
In-Reply-To: <20180816142514.pf4eiqeditoy4uei@qschulz>
On 16/08/2018 16:25:14+0200, Quentin Schulz wrote:
> Hi Alexandre,
>
> On Tue, Aug 14, 2018 at 02:41:35PM +0200, Alexandre Belloni wrote:
> > On 14/08/2018 08:49:53+0200, Quentin Schulz wrote:
> > > Understood but it's an intermediate patch. Later (patch 8), the SerDes
> > > muxing "controller" is added as a child to this node. There most likely
> > > will be some others in the future (temperature sensor for example).
> > >
> > > Furthermore, there's already a simple-mfd without children in this file:
> > > https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/mips/mscc.txt#L19
> > >
> > > How should we handle this case?
> > >
> >
> > There were child nodes in previous version of the binding. You can
> > remove simple-mfd now. The useful registers that are not used by any
> > drivers are gpr and chipid.
> >
>
> And what about the use case I'm facing? I've got child nodes defined in
> it but with a later patch (but they actually haven't made it to the
> DT binding documentation, so that's for the next version of the patch
> series).
>
I guess you should keep simple-mfd for hsio because it will have child
nodes.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* KASAN: use-after-free Read in ccid_hc_tx_delete
From: syzbot @ 2018-08-27 17:10 UTC (permalink / raw)
To: davem, dccp, gerrit, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: aba16dc5cf93 Merge branch 'ida-4.19' of git://git.infradea..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1750d382400000
kernel config: https://syzkaller.appspot.com/x/.config?x=3b576e333ca31bb2
dashboard link: https://syzkaller.appspot.com/bug?extid=3967c1caf256f4d5aefe
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=119d007a400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+3967c1caf256f4d5aefe@syzkaller.appspotmail.com
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
hrtimer: interrupt took 33823 ns
==================================================================
BUG: KASAN: use-after-free in ccid_hc_tx_delete+0xe0/0x100
net/dccp/ccid.c:188
Read of size 8 at addr ffff8801b0726b40 by task syz-executor3/6567
CPU: 1 PID: 6567 Comm: syz-executor3 Not tainted 4.18.0+ #210
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x30d mm/kasan/report.c:412
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
ccid_hc_tx_delete+0xe0/0x100 net/dccp/ccid.c:188
dccp_sk_destruct+0x3c/0x80 net/dccp/proto.c:181
__sk_destruct+0x107/0xa60 net/core/sock.c:1560
__rcu_reclaim kernel/rcu/rcu.h:236 [inline]
rcu_do_batch kernel/rcu/tree.c:2576 [inline]
invoke_rcu_callbacks kernel/rcu/tree.c:2880 [inline]
__rcu_process_callbacks kernel/rcu/tree.c:2847 [inline]
rcu_process_callbacks+0xf78/0x27c0 kernel/rcu/tree.c:2864
__do_softirq+0x2eb/0xa74 kernel/softirq.c:292
invoke_softirq kernel/softirq.c:372 [inline]
irq_exit+0x1d6/0x210 kernel/softirq.c:412
exiting_irq arch/x86/include/asm/apic.h:536 [inline]
smp_apic_timer_interrupt+0x18e/0x6a0 arch/x86/kernel/apic/apic.c:1056
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:864
</IRQ>
RIP: 0010:memset_erms+0x9/0x10 arch/x86/lib/memset_64.S:65
Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48
ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 <f3> aa 4c 89 c8
c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01
RSP: 0018:ffff8801b2aa75b0 EFLAGS: 00010246 ORIG_RAX: ffffffffffffff13
RAX: 0000000000000000 RBX: 00000000006080c0 RCX: 0000000000000240
RDX: 0000000000000800 RSI: 0000000000000000 RDI: ffff8801addbc880
RBP: ffff8801b2aa7630 R08: ffff8801d7642a80 R09: ffff8801addbc2c0
R10: ffff8801d7642240 R11: 0000000000000000 R12: ffff8801addbc2c0
R13: ffff8801dac00c40 R14: ffff8801dac00c40 R15: 00000000006080c0
kmalloc include/linux/slab.h:513 [inline]
kzalloc include/linux/slab.h:707 [inline]
perf_event_alloc.part.93+0x1e2/0x33c0 kernel/events/core.c:9927
perf_event_alloc kernel/events/core.c:10399 [inline]
__do_sys_perf_event_open+0xa9c/0x2f30 kernel/events/core.c:10500
__se_sys_perf_event_open kernel/events/core.c:10389 [inline]
__x64_sys_perf_event_open+0xbe/0x150 kernel/events/core.c:10389
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457089
Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fc7df221c78 EFLAGS: 00000246 ORIG_RAX: 000000000000012a
RAX: ffffffffffffffda RBX: 00007fc7df2226d4 RCX: 0000000000457089
RDX: ffffffffffffffff RSI: 0000000000000000 RDI: 000000002001d000
RBP: 00000000009300a0 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffffffffffff R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000004d3300 R14: 00000000004c8290 R15: 0000000000000000
Allocated by task 6568:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
kmem_cache_alloc+0x12e/0x710 mm/slab.c:3554
ccid_new+0x25b/0x3e0 net/dccp/ccid.c:151
dccp_hdlr_ccid+0x27/0x150 net/dccp/feat.c:44
__dccp_feat_activate+0x184/0x270 net/dccp/feat.c:344
dccp_feat_activate_values+0x3b6/0x839 net/dccp/feat.c:1538
dccp_rcv_request_sent_state_process net/dccp/input.c:472 [inline]
dccp_rcv_state_process+0x11dc/0x1a30 net/dccp/input.c:678
dccp_v6_do_rcv+0x26f/0xb80 net/dccp/ipv6.c:638
sk_backlog_rcv include/net/sock.h:931 [inline]
__release_sock+0x12f/0x3a0 net/core/sock.c:2336
release_sock+0xad/0x2c0 net/core/sock.c:2849
inet_wait_for_connect net/ipv4/af_inet.c:588 [inline]
__inet_stream_connect+0x61f/0x1160 net/ipv4/af_inet.c:680
inet_stream_connect+0x58/0xa0 net/ipv4/af_inet.c:719
__sys_connect+0x37d/0x4c0 net/socket.c:1662
__do_sys_connect net/socket.c:1673 [inline]
__se_sys_connect net/socket.c:1670 [inline]
__x64_sys_connect+0x73/0xb0 net/socket.c:1670
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 6582:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kmem_cache_free+0x86/0x280 mm/slab.c:3756
ccid_hc_tx_delete+0xc3/0x100 net/dccp/ccid.c:190
dccp_hdlr_ccid+0x7d/0x150 net/dccp/feat.c:53
__dccp_feat_activate+0x184/0x270 net/dccp/feat.c:344
dccp_feat_activate_values+0x3b6/0x839 net/dccp/feat.c:1538
dccp_create_openreq_child+0x47a/0x620 net/dccp/minisocks.c:127
dccp_v6_request_recv_sock+0x253/0x2040 net/dccp/ipv6.c:466
dccp_check_req+0x46e/0x6c0 net/dccp/minisocks.c:196
dccp_v6_rcv+0x88e/0x1d9c net/dccp/ipv6.c:744
ip6_input_finish+0x407/0x1a40 net/ipv6/ip6_input.c:383
NF_HOOK include/linux/netfilter.h:287 [inline]
ip6_input+0xe9/0x600 net/ipv6/ip6_input.c:426
dst_input include/net/dst.h:450 [inline]
ip6_rcv_finish+0x17a/0x330 net/ipv6/ip6_input.c:76
NF_HOOK include/linux/netfilter.h:287 [inline]
ipv6_rcv+0x11e/0x650 net/ipv6/ip6_input.c:271
__netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4892
__netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5002
process_backlog+0x219/0x760 net/core/dev.c:5808
napi_poll net/core/dev.c:6228 [inline]
net_rx_action+0x799/0x1900 net/core/dev.c:6294
__do_softirq+0x2eb/0xa74 kernel/softirq.c:292
The buggy address belongs to the object at ffff8801b0726b40
which belongs to the cache ccid2_hc_tx_sock of size 1240
The buggy address is located 0 bytes inside of
1240-byte region [ffff8801b0726b40, ffff8801b0727018)
The buggy address belongs to the page:
page:ffffea0006c1c980 count:1 mapcount:0 mapping:ffff8801cd8b6680 index:0x0
compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffff8801cd8b3648 ffffea0006c1e308 ffff8801cd8b6680
raw: 0000000000000000 ffff8801b0726040 0000000100000005 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801b0726a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801b0726a80: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801b0726b00: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
ffff8801b0726b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801b0726c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Oops running iptables -F OUTPUT
From: Andreas Schwab @ 2018-08-27 17:11 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev
I'm getting this Oops when running iptables -F OUTPUT:
[ 91.139409] Unable to handle kernel paging request for data at address 0xd0000001fff12f34
[ 91.139414] Faulting instruction address: 0xd0000000016a5718
[ 91.139419] Oops: Kernel access of bad area, sig: 11 [#1]
[ 91.139426] BE SMP NR_CPUS=2 PowerMac
[ 91.139434] Modules linked in: iptable_filter ip_tables x_tables bpfilter nfsd auth_rpcgss lockd grace nfs_acl sunrpc tun af_packet snd_aoa_codec_tas snd_aoa_fabric_layout snd_aoa snd_aoa_i2sbus snd_aoa_soundbus snd_pcm_oss snd_pcm snd_seq snd_timer snd_seq_device snd_mixer_oss snd sungem sr_mod firewire_ohci cdrom sungem_phy soundcore firewire_core pata_macio crc_itu_t sg hid_generic usbhid linear md_mod ohci_pci ohci_hcd ehci_pci ehci_hcd usbcore usb_common dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_mod sata_svw
[ 91.139522] CPU: 1 PID: 3620 Comm: iptables Not tainted 4.19.0-rc1 #1
[ 91.139526] NIP: d0000000016a5718 LR: d0000000016a569c CTR: c0000000006f560c
[ 91.139531] REGS: c0000001fa577670 TRAP: 0300 Not tainted (4.19.0-rc1)
[ 91.139534] MSR: 900000000200b032 <SF,HV,VEC,EE,FP,ME,IR,DR,RI> CR: 84002484 XER: 20000000
[ 91.139553] DAR: d0000001fff12f34 DSISR: 40000000 IRQMASK: 0
GPR00: d0000000016a569c c0000001fa5778f0 d0000000016b0400 0000000000000000
GPR04: 0000000000000002 0000000000000000 80000001fa46418e c0000001fa0d05c8
GPR08: d0000000016b0400 d00037fffff13000 00000001ff3e7000 d0000000016a6fb8
GPR12: c0000000006f560c c00000000ffff780 0000000000000000 0000000000000000
GPR16: 0000000011635010 00003fffa1b7aa68 0000000000000000 0000000000000000
GPR20: 0000000000000003 0000000010013918 00000000116350c0 c000000000b88990
GPR24: c000000000b88ba4 0000000000000000 d0000001fff12f34 0000000000000000
GPR28: d0000000016b8000 c0000001fa20f400 c0000001fa20f440 0000000000000000
[ 91.139627] NIP [d0000000016a5718] .alloc_counters.isra.10+0xbc/0x140 [ip_tables]
[ 91.139634] LR [d0000000016a569c] .alloc_counters.isra.10+0x40/0x140 [ip_tables]
[ 91.139638] Call Trace:
[ 91.139645] [c0000001fa5778f0] [d0000000016a569c] .alloc_counters.isra.10+0x40/0x140 [ip_tables] (unreliable)
[ 91.139655] [c0000001fa5779b0] [d0000000016a5b54] .do_ipt_get_ctl+0x110/0x2ec [ip_tables]
[ 91.139666] [c0000001fa577aa0] [c0000000006233e0] .nf_getsockopt+0x68/0x88
[ 91.139674] [c0000001fa577b40] [c000000000631608] .ip_getsockopt+0xbc/0x128
[ 91.139682] [c0000001fa577bf0] [c00000000065adf4] .raw_getsockopt+0x18/0x5c
[ 91.139690] [c0000001fa577c60] [c0000000005b5f60] .sock_common_getsockopt+0x2c/0x40
[ 91.139697] [c0000001fa577cd0] [c0000000005b3394] .__sys_getsockopt+0xa4/0xd0
[ 91.139704] [c0000001fa577d80] [c0000000005b5ab0] .__se_sys_socketcall+0x238/0x2b4
[ 91.139712] [c0000001fa577e30] [c00000000000a31c] system_call+0x5c/0x70
[ 91.139716] Instruction dump:
[ 91.139721] 39290040 7d3d4a14 7fbe4840 409cff98 81380000 2b890001 419d000c 393e0060
[ 91.139736] 48000010 7d57c82a e93e0060 7d295214 <815a0000> 794807e1 41e20010 7c210b78
[ 91.139752] ---[ end trace f5d1d5431651845d ]---
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
* RE: [PATCH] sh_eth: Add R7S9210 support
From: Chris Brandt @ 2018-08-27 17:30 UTC (permalink / raw)
To: Sergei Shtylyov, David S . Miller, Rob Herring, Mark Rutland
Cc: netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Simon Horman
In-Reply-To: <8efee9e2-2c2c-b02b-db8d-a421a8928448@cogentembedded.com>
Hi Sergei,
On Friday, August 24, 2018 1, linux-renesas-soc-owner@vger.kernel.org wrote:
> On 08/22/2018 11:57 PM, Chris Brandt wrote:
> > +static const u16 sh_eth_offset_fast_rza2[SH_ETH_MAX_REGISTER_OFFSET] =
> {
> > + SH_ETH_OFFSET_DEFAULTS,
> > +
(snip)
> > + [RFCR] = 0x01f4,
> > + [MAFCR] = 0x01f8,
> > +};
> > +
>
> This array is absolutely the same as sh_eth_offset_fast_sh4[], except
> the latter
> is (more or less) sorted.
You're right. I'll just use sh_eth_offset_fast_sh4[].
> > +
> > + switch (mdp->speed) {
> > + case 10: /* 10BASE */
> > + sh_eth_modify(ndev, ECMR, RTM, 0);
> > + break;
> > + case 100:/* 100BASE */
> > + sh_eth_modify(ndev, ECMR, RTM, RTM);
> > + break;
> > + }
> > +}
> > +
>
> Seems the same as sh_eth_set_rate_rcar(), except for the bit name...
You're right.
I looked at the other sh_eth_set_rate_xxx() but didn't seem to find one
that matched.
But, sh_eth_set_rate_rcar() does match. I'll use that one.
Thanks,
Chris
^ permalink raw reply
* [PATCH v2] sh_eth: Add R7S9210 support
From: Chris Brandt @ 2018-08-27 17:42 UTC (permalink / raw)
To: Sergei Shtylyov, David S . Miller, Rob Herring, Mark Rutland
Cc: netdev, devicetree, linux-renesas-soc, Simon Horman, Chris Brandt
Add support for the R7S9210 which is part of the RZ/A2 series.
Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
---
v2:
* Use sh_eth_offset_fast_sh4 instead of sh_eth_offset_fast_rza2
* Use sh_eth_set_rate_rcar instead of sh_eth_set_rate_r7s9210()
* Removed enum SH_ETH_REG_FAST_RZA2
---
Documentation/devicetree/bindings/net/sh_eth.txt | 1 +
drivers/net/ethernet/renesas/sh_eth.c | 36 ++++++++++++++++++++++++
2 files changed, 37 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/sh_eth.txt b/Documentation/devicetree/bindings/net/sh_eth.txt
index 76db9f13ad96..abc36274227c 100644
--- a/Documentation/devicetree/bindings/net/sh_eth.txt
+++ b/Documentation/devicetree/bindings/net/sh_eth.txt
@@ -16,6 +16,7 @@ Required properties:
"renesas,ether-r8a7794" if the device is a part of R8A7794 SoC.
"renesas,gether-r8a77980" if the device is a part of R8A77980 SoC.
"renesas,ether-r7s72100" if the device is a part of R7S72100 SoC.
+ "renesas,ether-r7s9210" if the device is a part of R7S9210 SoC.
"renesas,rcar-gen1-ether" for a generic R-Car Gen1 device.
"renesas,rcar-gen2-ether" for a generic R-Car Gen2 or RZ/G1
device.
diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
index 5573199c4536..2b95f3b1b759 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -809,6 +809,41 @@ static struct sh_eth_cpu_data r8a77980_data = {
.magic = 1,
.cexcr = 1,
};
+
+/* R7S9210 */
+static struct sh_eth_cpu_data r7s9210_data = {
+ .soft_reset = sh_eth_soft_reset,
+
+ .set_duplex = sh_eth_set_duplex,
+ .set_rate = sh_eth_set_rate_rcar,
+
+ .register_type = SH_ETH_REG_FAST_SH4,
+
+ .edtrr_trns = EDTRR_TRNS_ETHER,
+ .ecsr_value = ECSR_ICD,
+ .ecsipr_value = ECSIPR_ICDIP,
+ .eesipr_value = EESIPR_TWBIP | EESIPR_TABTIP | EESIPR_RABTIP |
+ EESIPR_RFCOFIP | EESIPR_ECIIP | EESIPR_FTCIP |
+ EESIPR_TDEIP | EESIPR_TFUFIP | EESIPR_FRIP |
+ EESIPR_RDEIP | EESIPR_RFOFIP | EESIPR_CNDIP |
+ EESIPR_DLCIP | EESIPR_CDIP | EESIPR_TROIP |
+ EESIPR_RMAFIP | EESIPR_RRFIP | EESIPR_RTLFIP |
+ EESIPR_RTSFIP | EESIPR_PREIP | EESIPR_CERFIP,
+
+ .tx_check = EESR_FTC | EESR_CND | EESR_DLC | EESR_CD | EESR_TRO,
+ .eesr_err_check = EESR_TWB | EESR_TABT | EESR_RABT | EESR_RFE |
+ EESR_RDE | EESR_RFRMER | EESR_TFE | EESR_TDE,
+
+ .fdr_value = 0x0000070f,
+
+ .apr = 1,
+ .mpr = 1,
+ .tpauser = 1,
+ .hw_swap = 1,
+ .rpadir = 1,
+ .no_ade = 1,
+ .xdfar_rw = 1,
+};
#endif /* CONFIG_OF */
static void sh_eth_set_rate_sh7724(struct net_device *ndev)
@@ -3132,6 +3167,7 @@ static const struct of_device_id sh_eth_match_table[] = {
{ .compatible = "renesas,ether-r8a7794", .data = &rcar_gen2_data },
{ .compatible = "renesas,gether-r8a77980", .data = &r8a77980_data },
{ .compatible = "renesas,ether-r7s72100", .data = &r7s72100_data },
+ { .compatible = "renesas,ether-r7s9210", .data = &r7s9210_data },
{ .compatible = "renesas,rcar-gen1-ether", .data = &rcar_gen1_data },
{ .compatible = "renesas,rcar-gen2-ether", .data = &rcar_gen2_data },
{ }
--
2.16.1
^ permalink raw reply related
* YOUR PRODUCT
From: Rafaa Esawi @ 2018-08-27 17:26 UTC (permalink / raw)
Greetings,
We are rebuilding Iraq after years of conflicts and we are inviting you to
take up contracts. We are determined to purchase your products in large
quantities, for use in all over our 18 governorates(provinces) as the task
of re-building Iraq covers every single sectormand facet of our society.
We'll submit your products information to
the Iraqi Project and Contracting Office. They will examine the propriety
and necessity of your product and approve for bulk supply contracting
relationship.
I am currently on the board of the Iraqi Project and Contracting Office,
With my connections in the corridors of power, we are quite confident of
securing approval. Also of note is the issue of different financial
regulations between my country Iraq and your country. As such you will be
paid 100% through the Iraqi ministry of Finance
before you commence supplies. When you've received payment, we would be
expecting a monthly supply; as the sum budgeted for product may be quite
enormous as to outstrip your capacity and capability to supply.
A consideration also is that your quotation must be CIF Port of Umm Qasr.
Please send response so that I will reveal more procedural information to
you upon your re-confirmation.
Thany You.
Rafaa Esawi
^ permalink raw reply
* Re: [PATCH 0/2] staging: Fix some warnings from strncpy()
From: Greg KH @ 2018-08-27 17:48 UTC (permalink / raw)
To: Larry Finger; +Cc: devel, netdev
In-Reply-To: <20180820175124.23863-1-Larry.Finger@lwfinger.net>
On Mon, Aug 20, 2018 at 12:51:22PM -0500, Larry Finger wrote:
> When the size argument in a call to strncpy() is the size of the
> destimation, gcc8 issues a warning. These patches fix the potential
> problem by replacing the strncpy() with strlcpy().
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>
>
> Larry Finger (2):
> staging: rtl8192e: Fix compiler warning about strncpy
> staging: rtl8712u: Fix compiler warning about strncpy
>
> drivers/staging/rtl8192e/rtllib_softmac.c | 4 ++--
> drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
I'm guessing you will send a second set of this patch series, right?
This one is now dropped, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH] net: mvpp2: initialize port of_node pointer
From: Baruch Siach @ 2018-08-27 18:17 UTC (permalink / raw)
To: Andrew Lunn
Cc: Maxime Chevallier, Antoine Tenart, netdev, Russell King,
Ori Shem-Tov, Jason Cooper, Gregory Clement,
Sebastian Hesselbarth
In-Reply-To: <20180827134723.GD15473@lunn.ch>
Hi Andrew,
Thanks for reviewing.
On Mon, Aug 27, 2018 at 03:47:23PM +0200, Andrew Lunn wrote:
> On Mon, Aug 27, 2018 at 03:12:53PM +0300, Baruch Siach wrote:
> > Without a valid of_node in struct device we can't find the mvpp2 port
> > device by its DT node. Specifically, this breaks
> > of_find_net_device_by_node().
>
> We need to be a little bit careful here. I've seen this done wrongly
> before, breaking DSA support. Is you intention to use DSA? Can you
> quote a section of DT, and indicate which node is port_node.
Yes. This is for the Armada 8K based Clearfog GT-8K. The board has a Marvell
88E6141 switch connected to the &cp1_eth2 port.
Here are the relevant DT nodes:
&cp1_mdio {
...
switch0: switch0@4 {
compatible = "marvell,mv88e6085";
...
ports {
...
port@5 {
reg = <5>;
label = "cpu";
ethernet = <&cp1_eth2>;
};
};
Without this patch, dsa_register_switch() returns -EPROBE_DEFER because
of_find_net_device_by_node() can't find the device_node of the &cp1_eth2
device.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* Re: broken behaviour of TC filter delete
From: Cong Wang @ 2018-08-27 18:30 UTC (permalink / raw)
To: Jiri Pirko
Cc: Roman Mashak, Linux Kernel Network Developers, Jiri Pirko,
Jamal Hadi Salim
In-Reply-To: <20180825130243.GE2931@nanopsycho>
On Sat, Aug 25, 2018 at 6:06 AM Jiri Pirko <jiri@resnulli.us> wrote:
>
> Fri, Aug 24, 2018 at 08:11:07PM CEST, xiyou.wangcong@gmail.com wrote:
> >On Fri, Aug 24, 2018 at 9:21 AM Roman Mashak <mrv@mojatatu.com> wrote:
> >>
> >> So _before_ commit f71e0ca4db187af7c44987e9d21e9042c3046070 step 6 would
> >> return -ENOENT with "Error: Filter with specified priority/protocol not
> >> found." and _after_ the commit it returns -EINVAL (Error: Cannot find
> >> specified filter chain.)
> >>
> >> ENOENT seems to be more logical to return when there's no more filter to delete.
> >
> >Yeah, at least we should keep ENOENT for compatibility.
> >
> >The bug here is chain 0 is gone after the last filter is gone,
> >so when you delete the filter again, it treats it as you specify
> >chain 0 which does not exist, so it hits EINVAL before ENOENT.
>
> I understand. My concern is about consistency with other chains. Perhaps
> -ENOENT for all chains in this case would be doable. What do you think?
Yeah, I think -ENOENT makes more sense than EINVAL here too.
^ permalink raw reply
* Re: [V2][PATCH net] tipc: fix the big/little endian issue in tipc_dest
From: David Miller @ 2018-08-27 22:24 UTC (permalink / raw)
To: Haiqing.Bai; +Cc: netdev, jon.maloy, ying.xue, zhenbo.gao, linux-kernel
In-Reply-To: <1535333546-16753-1-git-send-email-Haiqing.Bai@windriver.com>
From: Haiqing Bai <Haiqing.Bai@windriver.com>
Date: Mon, 27 Aug 2018 09:32:26 +0800
> In function tipc_dest_push, the 32bit variables 'node' and 'port'
> are stored separately in uppper and lower part of 64bit 'value'.
> Then this value is assigned to dst->value which is a union like:
> union
> {
> struct {
> u32 port;
> u32 node;
> };
> u64 value;
> }
> This works on little-endian machines like x86 but fails on big-endian
> machines.
>
> The fix remove the 'value' stack parameter and even the 'value'
> member of the union in tipc_dest, assign the 'node' and 'port' member
> directly with the input parameter to avoid the endian issue.
>
> Fixes: a80ae5306a73 ("tipc: improve destination linked list")
>
> Signed-off-by: Zhenbo Gao <zhenbo.gao@windriver.com>
> Acked-by: Jon Maloy <jon.maloy@ericsson.com>
> Signed-off-by: Haiqing Bai <Haiqing.Bai@windriver.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH 1/4] clk: x86: add "ether_clk" alias for Bay Trail / Cherry Trail
From: Stephen Boyd @ 2018-08-27 18:43 UTC (permalink / raw)
To: David S . Miller, Andy Shevchenko, Hans de Goede, Heiner Kallweit,
Irina Tirdea, Michael Turquette
Cc: Hans de Goede, netdev, Johannes Stezenbach, Carlo Caione,
linux-clk
In-Reply-To: <20180827143200.8597-2-hdegoede@redhat.com>
Quoting Hans de Goede (2018-08-27 07:31:57)
> Commit d31fd43c0f9a ("clk: x86: Do not gate clocks enabled by the
> firmware") causes all unclaimed PMC clocks on Cherry Trail devices to be on
> all the time, resulting on the device not being able to reach S0i2 or S0i3
> when suspended.
>
> The reason for this commit is that on some Bay Trail / Cherry Trail devices
> the ethernet controller uses pmc_plt_clk_4. This commit adds an "ether_clk"
> alias, so that the relevant ethernet drivers can try to (optionally) use
> this, without needing X86 specific code / hacks, thus fixing ethernet on
> these devices without breaking S0i3 support.
>
> This commit uses clkdev_hw_create() to create the alias, mirroring the code
> for the already existing "mclk" alias for pmc_plt_clk_3.
>
> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=193891#c102
> Cc: Johannes Stezenbach <js@sig21.net>
> Cc: Carlo Caione <carlo@endlessm.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
Acked-by: Stephen Boyd <sboyd@kernel.org>
^ permalink raw reply
* Re: [PATCH] net: mvpp2: initialize port of_node pointer
From: Andrew Lunn @ 2018-08-27 18:44 UTC (permalink / raw)
To: Baruch Siach
Cc: Maxime Chevallier, Antoine Tenart, netdev, Russell King,
Ori Shem-Tov, Jason Cooper, Gregory Clement,
Sebastian Hesselbarth
In-Reply-To: <20180827181721.usbb2vvaenzxclkq@sapphire.tkos.co.il>
On Mon, Aug 27, 2018 at 09:17:21PM +0300, Baruch Siach wrote:
> Hi Andrew,
>
> Thanks for reviewing.
>
> On Mon, Aug 27, 2018 at 03:47:23PM +0200, Andrew Lunn wrote:
> > On Mon, Aug 27, 2018 at 03:12:53PM +0300, Baruch Siach wrote:
> > > Without a valid of_node in struct device we can't find the mvpp2 port
> > > device by its DT node. Specifically, this breaks
> > > of_find_net_device_by_node().
> >
> > We need to be a little bit careful here. I've seen this done wrongly
> > before, breaking DSA support. Is you intention to use DSA? Can you
> > quote a section of DT, and indicate which node is port_node.
>
> Yes. This is for the Armada 8K based Clearfog GT-8K. The board has a Marvell
> 88E6141 switch connected to the &cp1_eth2 port.
>
> Here are the relevant DT nodes:
>
> &cp1_mdio {
> ...
>
> switch0: switch0@4 {
> compatible = "marvell,mv88e6085";
> ...
>
> ports {
> ...
>
> port@5 {
> reg = <5>;
> label = "cpu";
> ethernet = <&cp1_eth2>;
> };
> };
>
> Without this patch, dsa_register_switch() returns -EPROBE_DEFER because
> of_find_net_device_by_node() can't find the device_node of the &cp1_eth2
> device.
O.K. This all looks correct.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH v2 0/2] staging: Fix some warnings from strncpy()
From: Larry Finger @ 2018-08-27 18:46 UTC (permalink / raw)
To: gregkh; +Cc: netdev, devel, Larry Finger
When the size argument in a call to strncpy() is the size of the
destimation, gcc8 issues a warning. These patches fix the potential
problem.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
v2 - The code is changed to implement the comments of David Laight.
Larry Finger (2):
staging: rtl8192e: Fix compiler warning about strncpy
staging: rtl8712u: Fix compiler warning about strncpy
drivers/staging/rtl8192e/rtllib_softmac.c | 4 ++--
drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--
2.18.0
^ permalink raw reply
* [PATCH v2 1/2] staging: rtl8192e: Fix compiler warning from strncpy()
From: Larry Finger @ 2018-08-27 18:46 UTC (permalink / raw)
To: gregkh; +Cc: netdev, devel, Larry Finger
In-Reply-To: <20180827184646.10276-1-Larry.Finger@lwfinger.net>
When strncpy() is called with source and destination strings the same
length, gcc 8 warns that there may be an unterminated string. This section
is completely reworked to use the known lengths of the strings.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
v2 - David Laight's comments are implemented.
---
drivers/staging/rtl8192e/rtllib_softmac.c | 18 ++++++++++--------
drivers/staging/rtl8192e/rtllib_softmac.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c b/drivers/staging/rtl8192e/rtllib_softmac.c
index 919231fec09c..287d0c11fa38 100644
--- a/drivers/staging/rtl8192e/rtllib_softmac.c
+++ b/drivers/staging/rtl8192e/rtllib_softmac.c
@@ -1680,19 +1680,19 @@ inline void rtllib_softmac_new_net(struct rtllib_device *ieee,
(ssidbroad && !ssidset) || (!ssidbroad && ssidset))) ||
(!apset && ssidset && ssidbroad && ssidmatch) ||
(ieee->is_roaming && ssidset && ssidbroad && ssidmatch)) {
- /* if the essid is hidden replace it with the
- * essid provided by the user.
+ /* Save the essid so that if it is hidden, it is
+ * replaced with the essid provided by the user.
*/
if (!ssidbroad) {
- strncpy(tmp_ssid, ieee->current_network.ssid,
- IW_ESSID_MAX_SIZE);
+ memcpy(tmp_ssid, ieee->current_network.ssid,
+ ieee->current_network.ssid_len);
tmp_ssid_len = ieee->current_network.ssid_len;
}
- memcpy(&ieee->current_network, net,
- sizeof(struct rtllib_network));
+ memcpy(&ieee->current_network, net,
+ sizeof(ieee->current_network));
if (!ssidbroad) {
- strncpy(ieee->current_network.ssid, tmp_ssid,
- IW_ESSID_MAX_SIZE);
+ memcpy(ieee->current_network.ssid, tmp_ssid,
+ tmp_ssid_len);
ieee->current_network.ssid_len = tmp_ssid_len;
}
netdev_info(ieee->dev,
--
2.18.0
^ permalink raw reply related
* [PATCH v2 2/2] staging: rtl8712u: Fix compiler warning about strncpy
From: Larry Finger @ 2018-08-27 18:46 UTC (permalink / raw)
To: gregkh; +Cc: netdev, devel, Larry Finger
In-Reply-To: <20180827184646.10276-1-Larry.Finger@lwfinger.net>
When strncpy() is called with source and destination strings the same
length, gcc 8 warns that there may be an unterminated string. Using
strlcpy() rather than strncpy() forces a null at the end and quiets the
warning.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
v2 - No changes.
---
drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index c3ff7c3e6681..08e1c0957a07 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -1789,7 +1789,7 @@ static int r871x_wx_set_enc_ext(struct net_device *dev,
return -ENOMEM;
param->cmd = IEEE_CMD_SET_ENCRYPTION;
eth_broadcast_addr(param->sta_addr);
- strncpy((char *)param->u.crypt.alg, alg_name, IEEE_CRYPT_ALG_NAME_LEN);
+ strlcpy((char *)param->u.crypt.alg, alg_name, IEEE_CRYPT_ALG_NAME_LEN);
if (pext->ext_flags & IW_ENCODE_EXT_GROUP_KEY)
param->u.crypt.set_tx = 0;
if (pext->ext_flags & IW_ENCODE_EXT_SET_TX_KEY)
--
2.18.0
^ permalink raw reply related
* Re: [PATCH 2/4] r8169: Get and enable optional ether_clk clock
From: Stephen Boyd @ 2018-08-27 18:47 UTC (permalink / raw)
To: David S . Miller, Andy Shevchenko, Hans de Goede, Heiner Kallweit,
Irina Tirdea, Michael Turquette
Cc: Hans de Goede, netdev, Johannes Stezenbach, Carlo Caione,
linux-clk
In-Reply-To: <20180827143200.8597-3-hdegoede@redhat.com>
Quoting Hans de Goede (2018-08-27 07:31:58)
> On some boards a platform clock is used as clock for the r8169 chip,
> this commit adds support for getting and enabling this clock (assuming
> it has an "ether_clk" alias set on it).
>
> This is related to commit d31fd43c0f9a ("clk: x86: Do not gate clocks
> enabled by the firmware") which is a previous attempt to fix this for some
> x86 boards, but this causes all Cherry Trail SoC using boards to not reach
> there lowest power states when suspending.
>
> This commit (together with an atom-pmc-clk driver commit adding the alias)
> fixes things properly by making the r8169 get the clock and enable it when
> it needs it.
>
> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=193891#c102
> Cc: Johannes Stezenbach <js@sig21.net>
> Cc: Carlo Caione <carlo@endlessm.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
> @@ -7614,6 +7616,11 @@ static void rtl_hw_initialize(struct rtl8169_private *tp)
> }
> }
>
> +static void rtl_disable_clk(void *data)
> +{
> + clk_disable_unprepare(data);
> +}
> +
> static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> {
> const struct rtl_cfg_info *cfg = rtl_cfg_infos + ent->driver_data;
> @@ -7647,6 +7654,32 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> mii->reg_num_mask = 0x1f;
> mii->supports_gmii = cfg->has_gmii;
>
> + /* Get the *optional* external "ether_clk" used on some boards */
> + tp->clk = devm_clk_get(&pdev->dev, "ether_clk");
An "optional" clk API is in flight, but it's easier to wait for that to
merge and then this to be updated, so just take that as an FYI. It would
be interesting to see how to support optional clks with clkdev lookups
though, which would be needed in this case.
How would you know that a clk device driver hasn't probed yet and isn't
the driver that's actually providing the clk to this device on x86
systems? With DT systems we can figure that out by looking at the DT and
seeing if the device driver requesting the clk has the clocks property.
On x86 systems it's all clkdev which doesn't really lend itself to
solving this problem.
> + if (IS_ERR(tp->clk)) {
> + rc = PTR_ERR(tp->clk);
^ permalink raw reply
* Re: KASAN: invalid-free in p9stat_free
From: Dominique Martinet @ 2018-08-27 22:40 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, David Miller, Eric Van Hensbergen, LKML, Latchesar Ionkov,
netdev, syzkaller-bugs, v9fs-developer
In-Reply-To: <CACT4Y+b1B5_Eg+j91GxaVbPk5sb8+SVOU_z5k9HYb4R716X9kQ@mail.gmail.com>
Dmitry Vyukov wrote on Mon, Aug 27, 2018:
> kfree and then null pointer is pretty common, try to run:
>
> find -name "*.c" -exec grep -A 1 "kfree(" {} \; | grep -B 1 " = NULL;"
Hmm, right, it looks like somewhere between 5 and 10% of the kfree()
calls are followed by NULL assignment, that's "common enough" - not
generalized but not rare either.
> Leaving dangling pointers behind is not the best idea.
> And from what I remember a bunch of similar double frees were fixed by
> nulling the pointer after the first kfree.
In this case it really is an error to call p9stat_free again, so let's
just do both.
Will send the patches shortly.
Thanks,
--
Dominique
^ 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