* Re: [PATCH 0/4] irda: move it to drivers/staging so we can delete it
From: Greg Kroah-Hartman @ 2017-08-29 14:48 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: driverdevel, Samuel Ortiz, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Stefano Brivio, David S. Miller
In-Reply-To: <CAMuHMdVb-oygJkkHwBOfSmNECAfF72QruJSmVTpqdUW+RNJbrg@mail.gmail.com>
On Tue, Aug 29, 2017 at 02:11:39PM +0200, Geert Uytterhoeven wrote:
> Hi Greg,
>
> On Tue, Aug 29, 2017 at 1:28 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Tue, Aug 29, 2017 at 01:11:31PM +0200, Stefano Brivio wrote:
> >> On Tue, 29 Aug 2017 12:59:00 +0200
> >> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >> > On Sun, Aug 27, 2017 at 5:03 PM, Greg Kroah-Hartman
> >> > <gregkh@linuxfoundation.org> wrote:
> >> > > The IRDA code has long been obsolete and broken. So, to keep people
> >> > > from trying to use it, and to prevent people from having to maintain it,
> >> > > let's move it to drivers/staging/ so that we can delete it entirely from
> >> > > the kernel in a few releases.
> >> >
> >> > (diving into an early boot crash)
> >> >
> >> > Have you tried running this? ;-)
> >> >
> >> > irda_init() and net_dev_init() are both subsys_initcall()s.
> >> > But the former now runs before the latter, leading to:
> >> >
> >> > Unable to handle kernel NULL pointer dereference at virtual address 00000004
> >>
> >> Should be fixed by https://patchwork.ozlabs.org/patch/807006/
> >> ("[net-next] staging: irda: force to be a kernel module") I guess...
> >
> > Yup, that's the fix for this issue.
> >
> > Geert, does that fix the problem for you?
>
> Thanks, that patch fixes the crash, obviously.
>
> It does mean you can no longer have IrDA in a non-modular kernel.
Given that irda doesn't really work, I doubt anyone is going to care
about it :)
thanks,
greg k-h
^ permalink raw reply
* Re: net.ipv4.tcp_max_syn_backlog implementation
From: Harsha Chenji @ 2017-08-29 15:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1503980243.11498.69.camel@edumazet-glaptop3.roam.corp.google.com>
According to the man:
The behavior of the backlog argument on TCP sockets changed with Linux
2.2. Now it specifies the queue length for *completely established
sockets waiting to be accepted*, instead of the number of incomplete
connection requests. The maximum length of the queue for incomplete
sockets can be set using /proc/sys/net/ipv4/tcp_max_syn_backlog. When
syncookies are enabled there is no logical maximum length and this
setting is ignored. See tcp(7) for more information.
On Tue, Aug 29, 2017 at 12:17 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2017-08-28 at 23:47 -0400, Harsha Chenji wrote:
>> So I have ubuntu 12.04 x32 in a VM with syncookies turned off. I tried
>> to do a syn flood (with netwox) on 3 different processes. Each of them
>> returns a different value with netstat -na | grep -c RECV :
>>
>> nc -l 5555 returns 16 (netcat-traditional)
>> apache2 port 80 returns 256
>> vsftpd on 21 returns 64.
>> net.ipv4.tcp_max_syn_backlog is 512.
>>
>> Why do these different processes on different ports have different
>> queue lengths for incomplete connections? Where exactly in the kernel
>> is this decided?
>
> See 2nd argument in listen() system call, ie backlog
>
> man listen
>
> Without a synflood, just look at "ss -t state listening"
>
> The backlog is the 2nd column (Send)
>
>
>
^ permalink raw reply
* [iproute PATCH] lib/bpf: Fix bytecode-file parsing
From: Phil Sutter @ 2017-08-29 15:09 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Daniel Borkmann
The signedness of char type is implementation dependent, and there are
architectures on which it is unsigned by default. In that case, the
check whether fgetc() returned EOF failed because the return value was
assigned an (unsigned) char variable prior to comparison with EOF (which
is defined to -1). Fix this by using int as type for 'c' variable, which
also matches the declaration of fgetc().
While being at it, fix the parser logic to correctly handle multiple
empty lines and consecutive whitespace and tab characters to further
improve the parser's robustness. Note that this will still detect double
separator characters, so doesn't soften up the parser too much.
Fixes: 3da3ebfca85b8 ("bpf: Make bytecode-file reading a little more robust")
Cc: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
lib/bpf.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/bpf.c b/lib/bpf.c
index 0bd0a95eafe6c..77eb8ee27114f 100644
--- a/lib/bpf.c
+++ b/lib/bpf.c
@@ -208,8 +208,9 @@ static int bpf_parse_string(char *arg, bool from_file, __u16 *bpf_len,
if (from_file) {
size_t tmp_len, op_len = sizeof("65535 255 255 4294967295,");
- char *tmp_string, *pos, c, c_prev = ' ';
+ char *tmp_string, *pos, c_prev = ' ';
FILE *fp;
+ int c;
tmp_len = sizeof("4096,") + BPF_MAXINSNS * op_len;
tmp_string = pos = calloc(1, tmp_len);
@@ -228,18 +229,20 @@ static int bpf_parse_string(char *arg, bool from_file, __u16 *bpf_len,
case '\n':
if (c_prev != ',')
*(pos++) = ',';
+ c_prev = ',';
break;
case ' ':
case '\t':
if (c_prev != ' ')
*(pos++) = c;
+ c_prev = ' ';
break;
default:
*(pos++) = c;
+ c_prev = c;
}
if (pos - tmp_string == tmp_len)
break;
- c_prev = c;
}
if (!feof(fp)) {
--
2.13.1
^ permalink raw reply related
* Re: [PATCH net-next] Revert "ipv4: make net_protocol const"
From: Stephen Hemminger @ 2017-08-29 15:14 UTC (permalink / raw)
To: Bhumika Goyal; +Cc: David Ahern, netdev, David Miller
In-Reply-To: <CAOH+1jF3G+Yo30Tk=cgnAPfD8UNe+FkkLjC1uGUd9eeG-ce5KA@mail.gmail.com>
On Tue, 29 Aug 2017 12:16:23 +0530
Bhumika Goyal <bhumirks@gmail.com> wrote:
> On Tue, Aug 29, 2017 at 1:53 AM, David Ahern <dsahern@gmail.com> wrote:
> > This reverts commit aa8db499ea67cff1f5f049033810ffede2fe5ae4.
> >
> > Early demux structs can not be made const. Doing so results in:
> > [ 84.967355] BUG: unable to handle kernel paging request at ffffffff81684b10
> > [ 84.969272] IP: proc_configure_early_demux+0x1e/0x3d
> > [ 84.970544] PGD 1a0a067
> > [ 84.970546] P4D 1a0a067
> > [ 84.971212] PUD 1a0b063
> > [ 84.971733] PMD 80000000016001e1
> >
> > [ 84.972669] Oops: 0003 [#1] SMP
> > [ 84.973065] Modules linked in: ip6table_filter ip6_tables veth vrf
> > [ 84.973833] CPU: 0 PID: 955 Comm: sysctl Not tainted 4.13.0-rc6+ #22
> > [ 84.974612] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
> > [ 84.975855] task: ffff88003854ce00 task.stack: ffffc900005a4000
> > [ 84.976580] RIP: 0010:proc_configure_early_demux+0x1e/0x3d
> > [ 84.977253] RSP: 0018:ffffc900005a7dd0 EFLAGS: 00010246
> > [ 84.977891] RAX: ffffffff81684b10 RBX: 0000000000000001 RCX: 0000000000000000
> > [ 84.978759] RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000000000000
> > [ 84.979628] RBP: ffffc900005a7dd0 R08: 0000000000000000 R09: 0000000000000000
> > [ 84.980501] R10: 0000000000000001 R11: 0000000000000008 R12: 0000000000000001
> > [ 84.981373] R13: ffffffffffffffea R14: ffffffff81a9b4c0 R15: 0000000000000002
> > [ 84.982249] FS: 00007feb237b7700(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
> > [ 84.983231] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 84.983941] CR2: ffffffff81684b10 CR3: 0000000038492000 CR4: 00000000000406f0
> > [ 84.984817] Call Trace:
> > [ 84.985133] proc_tcp_early_demux+0x29/0x30
> >
> > I think this is the second time such a patch has been reverted.
> >
> > Cc: Bhumika Goyal <bhumirks@gmail.com>
> > Signed-off-by: David Ahern <dsahern@gmail.com>
> > ---
> > Bhumika: How are you testing these constify changes? In this case a simple
> > sysctl -w net.ipv4.tcp_early_demux=1 would have shown the problem
> >
>
> I am compile testing them. In this case I did: make
> net/ipv4/af_inet.o and it compiled. Is this error because of
> typecasting net_protocol inside inet_add_protocol function?
>
> Thanks,
> Bhumika
>
>
> > net/ipv4/af_inet.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> > index 19aee073ba29..d678820e4306 100644
> > --- a/net/ipv4/af_inet.c
> > +++ b/net/ipv4/af_inet.c
> > @@ -1596,7 +1596,7 @@ static const struct net_protocol igmp_protocol = {
> > };
> > #endif
> >
> > -static const struct net_protocol tcp_protocol = {
> > +static struct net_protocol tcp_protocol = {
> > .early_demux = tcp_v4_early_demux,
> > .early_demux_handler = tcp_v4_early_demux,
> > .handler = tcp_v4_rcv,
> > @@ -1606,7 +1606,7 @@ static const struct net_protocol tcp_protocol = {
> > .icmp_strict_tag_validation = 1,
> > };
> >
> > -static const struct net_protocol udp_protocol = {
> > +static struct net_protocol udp_protocol = {
> > .early_demux = udp_v4_early_demux,
> > .early_demux_handler = udp_v4_early_demux,
> > .handler = udp_rcv,
> > --
> > 2.1.4
> >
You need to change inet_proto datastructure first.
^ permalink raw reply
* Re: Fwd: DA850-evm MAC Address is random
From: Sekhar Nori @ 2017-08-29 15:16 UTC (permalink / raw)
To: Adam Ford; +Cc: Tony Lindgren, Grygorii Strashko, linux-omap, netdev
In-Reply-To: <CAHCN7xK2=PN5MOr48HOkZnwKwkM4ypcvQct+Ko+ChNFG3Pv62w@mail.gmail.com>
On Tuesday 29 August 2017 05:32 PM, Adam Ford wrote:
> On Tue, Aug 29, 2017 at 6:42 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>> On Tuesday 29 August 2017 03:53 PM, Adam Ford wrote:
>>> On Tue, Aug 29, 2017 at 3:23 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>> On Tuesday 29 August 2017 02:42 AM, Tony Lindgren wrote:
>>>>> * Adam Ford <aford173@gmail.com> [170828 13:33]:
>>>>>> On Mon, Aug 28, 2017 at 1:54 PM, Grygorii Strashko
>>>>>> <grygorii.strashko@ti.com> wrote:
>>>>>>> Cc: Sekhar
>>>>>>>
>>>>>>> On 08/28/2017 10:32 AM, Adam Ford wrote:
>>>>>>>>
>>>>>>>> The davinvi_emac MAC address seems to attempt a call to
>>>>>>>> ti_cm_get_macid in cpsw-common.c but it returns the message
>>>>>>>> 'davinci_emac davinci_emac.1: incompatible machine/device type for
>>>>>>>> reading mac address ' and then generates a random MAC address.
>>>>>>>>
>>>>>>>> The function appears to lookup varions boards using
>>>>>>>> 'of_machine_is_compaible' and supports dm8148, am33xx, am3517, dm816,
>>>>>>>> am4372 and dra7. I don't see the ti,davinci-dm6467-emac which is
>>>>>>>> what's shown in the da850 device tree.
>>>>>>>>
>>>>>>>> Is there a patch somewhere for supporting the da850-evm?
>>>>>>>
>>>>>>>
>>>>>>> Not sure if MAC address can be read from Control module.
>>>>>>> May be Sekhar can say more?
>>>>>>
>>>>>> My understanding is that the MAC address is programmed by Logic PD
>>>>>> into the SPI flash. The Bootloader reads this from either SPI or its
>>>>>> env variables. Looking at the partition info listed in the
>>>>>> da850-evm.dts file, it appears as if they've reserved space for it.
>>>>>> Unfortunately, I don't see any code that reads it out. I was hoping
>>>>
>>>> This code is present in U-Boot sources at
>>>> board/davinci/da8xxevm/da850evm.c. See the function get_mac_addr() and
>>>> its usage in misc_init_r().
>>>>
>>>>>> there might be a way to just pass cmdline parameter from the
>>>>>> bootloader to the kernel to accept the MAC address.
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> If not, is there a way to pass the MAC address from U-Boot to the
>>>>>>>> driver so it doesn't generate a random MAC?
>>>>>>>
>>>>>>>
>>>>>>> "local-mac-address" dt porp
>>>>>>
>>>>>> The downside here, is that we'd have to have the Bootloader modify the
>>>>>> device tree.
>>>>>
>>>>> That piece of code exists somewhere in u-boot already. Note how
>>>>
>>>> Yes, it is fdt_fixup_ethernet() and its usage is in common/image-fdt.c.
>>>>
>>>>> we are populating the mac address for USB Ethernet drivers in
>>>>> u-boot and then the Ethernet driver code parses it. See commit
>>>>> 055d31de7158 ("ARM: omap3: beagleboard-xm: dt: Add ethernet to
>>>>> the device tree") for some more information.
>>>>>
>>>>> I think u-boot needs the ethernet alias for finding the interface.
>>>>
>>>> That's exactly what was missing. I have sent a patch for fixing that and
>>>> copied you there.
>>>
>>> Thanks for doing that.
>>>
>>>>
>>>> Adam, if I can get your Tested-by, I will make an attempt to send it for
>>>> v4.13 itself.
>>>
>>> I will test it. Do need to run some instruction or do something
>>> special in U-Boot to pass this in the proper place for the kernel to
>>> pull it? Tony's patch reference showed
>>> command for fdt set, but I am not sure I fully understand the
>>> parameters that went along with that.
>>
>> Nope, just applying the patch and booting the with the new dtb should
>> result in the random mac address going away.
>
> Unfortunately, I am not seeing any change with the patch (at least
> with Kernel 4.12.9 from stable).
>
> netconsole: network logging started
> davinci_emac davinci_emac.1: incompatible machine/device type for
> reading mac address
> davinci_emac davinci_emac.1: using random MAC addr: ee:74:c3:3a:15:be
>
> Looking at the source for cpsw-common.c function ti_cm_get_macid()
> doesn't have a case for the ti,davinci-dm6467-emac so I wonder if
> there might be more to it.
Hmm, it did solve the issue for me when I tried latest -next. And
reverting the patch brought back the random mac address usage. Could you
try latest mainline or -next?
Meanwhile let me see whats going on with the observations you have.
Thanks,
Sekhar
^ permalink raw reply
* Re: Fwd: DA850-evm MAC Address is random
From: Adam Ford @ 2017-08-29 15:20 UTC (permalink / raw)
To: Sekhar Nori; +Cc: Tony Lindgren, Grygorii Strashko, linux-omap, netdev
In-Reply-To: <955b0b1b-9bb7-ad25-4d6c-676be1efb943@ti.com>
On Tue, Aug 29, 2017 at 10:16 AM, Sekhar Nori <nsekhar@ti.com> wrote:
> On Tuesday 29 August 2017 05:32 PM, Adam Ford wrote:
>> On Tue, Aug 29, 2017 at 6:42 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>>> On Tuesday 29 August 2017 03:53 PM, Adam Ford wrote:
>>>> On Tue, Aug 29, 2017 at 3:23 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>>> On Tuesday 29 August 2017 02:42 AM, Tony Lindgren wrote:
>>>>>> * Adam Ford <aford173@gmail.com> [170828 13:33]:
>>>>>>> On Mon, Aug 28, 2017 at 1:54 PM, Grygorii Strashko
>>>>>>> <grygorii.strashko@ti.com> wrote:
>>>>>>>> Cc: Sekhar
>>>>>>>>
>>>>>>>> On 08/28/2017 10:32 AM, Adam Ford wrote:
>>>>>>>>>
>>>>>>>>> The davinvi_emac MAC address seems to attempt a call to
>>>>>>>>> ti_cm_get_macid in cpsw-common.c but it returns the message
>>>>>>>>> 'davinci_emac davinci_emac.1: incompatible machine/device type for
>>>>>>>>> reading mac address ' and then generates a random MAC address.
>>>>>>>>>
>>>>>>>>> The function appears to lookup varions boards using
>>>>>>>>> 'of_machine_is_compaible' and supports dm8148, am33xx, am3517, dm816,
>>>>>>>>> am4372 and dra7. I don't see the ti,davinci-dm6467-emac which is
>>>>>>>>> what's shown in the da850 device tree.
>>>>>>>>>
>>>>>>>>> Is there a patch somewhere for supporting the da850-evm?
>>>>>>>>
>>>>>>>>
>>>>>>>> Not sure if MAC address can be read from Control module.
>>>>>>>> May be Sekhar can say more?
>>>>>>>
>>>>>>> My understanding is that the MAC address is programmed by Logic PD
>>>>>>> into the SPI flash. The Bootloader reads this from either SPI or its
>>>>>>> env variables. Looking at the partition info listed in the
>>>>>>> da850-evm.dts file, it appears as if they've reserved space for it.
>>>>>>> Unfortunately, I don't see any code that reads it out. I was hoping
>>>>>
>>>>> This code is present in U-Boot sources at
>>>>> board/davinci/da8xxevm/da850evm.c. See the function get_mac_addr() and
>>>>> its usage in misc_init_r().
>>>>>
>>>>>>> there might be a way to just pass cmdline parameter from the
>>>>>>> bootloader to the kernel to accept the MAC address.
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> If not, is there a way to pass the MAC address from U-Boot to the
>>>>>>>>> driver so it doesn't generate a random MAC?
>>>>>>>>
>>>>>>>>
>>>>>>>> "local-mac-address" dt porp
>>>>>>>
>>>>>>> The downside here, is that we'd have to have the Bootloader modify the
>>>>>>> device tree.
>>>>>>
>>>>>> That piece of code exists somewhere in u-boot already. Note how
>>>>>
>>>>> Yes, it is fdt_fixup_ethernet() and its usage is in common/image-fdt.c.
>>>>>
>>>>>> we are populating the mac address for USB Ethernet drivers in
>>>>>> u-boot and then the Ethernet driver code parses it. See commit
>>>>>> 055d31de7158 ("ARM: omap3: beagleboard-xm: dt: Add ethernet to
>>>>>> the device tree") for some more information.
>>>>>>
>>>>>> I think u-boot needs the ethernet alias for finding the interface.
>>>>>
>>>>> That's exactly what was missing. I have sent a patch for fixing that and
>>>>> copied you there.
>>>>
>>>> Thanks for doing that.
>>>>
>>>>>
>>>>> Adam, if I can get your Tested-by, I will make an attempt to send it for
>>>>> v4.13 itself.
>>>>
>>>> I will test it. Do need to run some instruction or do something
>>>> special in U-Boot to pass this in the proper place for the kernel to
>>>> pull it? Tony's patch reference showed
>>>> command for fdt set, but I am not sure I fully understand the
>>>> parameters that went along with that.
>>>
>>> Nope, just applying the patch and booting the with the new dtb should
>>> result in the random mac address going away.
>>
>> Unfortunately, I am not seeing any change with the patch (at least
>> with Kernel 4.12.9 from stable).
>>
>> netconsole: network logging started
>> davinci_emac davinci_emac.1: incompatible machine/device type for
>> reading mac address
>> davinci_emac davinci_emac.1: using random MAC addr: ee:74:c3:3a:15:be
>>
>> Looking at the source for cpsw-common.c function ti_cm_get_macid()
>> doesn't have a case for the ti,davinci-dm6467-emac so I wonder if
>> there might be more to it.
>
> Hmm, it did solve the issue for me when I tried latest -next. And
> reverting the patch brought back the random mac address usage. Could you
> try latest mainline or -next?
>
> Meanwhile let me see whats going on with the observations you have.
I will try again with -next this afternoon and see what I can find.
Can you tell me which U-Boot version you're using? I want to match
your setup. I want to see if something is missing during the hand-off
between the Bootloader and Linux.
>
> Thanks,
> Sekhar
^ permalink raw reply
* Re: [PATCH] DSA support for Micrel KSZ8895
From: kbuild test robot @ 2017-08-29 15:33 UTC (permalink / raw)
To: Pavel Machek
Cc: kbuild-all, Woojung.Huh, nathan.leigh.conrad, vivien.didelot,
f.fainelli, netdev, linux-kernel, Tristram.Ha, andrew, pavel
In-Reply-To: <20170827123658.GA727@amd>
[-- Attachment #1: Type: text/plain, Size: 4778 bytes --]
Hi Pavel,
[auto build test ERROR on net-next/master]
[also build test ERROR on v4.13-rc7 next-20170829]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Pavel-Machek/DSA-support-for-Micrel-KSZ8895/20170829-220156
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa
All error/warnings (new ones prefixed by >>):
In file included from drivers/net/dsa/microchip/ksz_common.c:31:0:
>> drivers/net/dsa/microchip/ksz_9477_reg.h:19:2: error: #error This is not switch we have
#error This is not switch we have
^
--
drivers/net/dsa/microchip/ksz_8895.c: In function 'ksz_reset_switch':
drivers/net/dsa/microchip/ksz_8895.c:109:21: warning: unused variable 'dev' [-Wunused-variable]
struct ksz_device *dev = ds->priv;
^
drivers/net/dsa/microchip/ksz_8895.c: In function 'ksz_br_join':
drivers/net/dsa/microchip/ksz_8895.c:262:21: warning: unused variable 'dev' [-Wunused-variable]
struct ksz_device *dev = ds->priv;
^
drivers/net/dsa/microchip/ksz_8895.c: In function 'ksz_br_leave':
drivers/net/dsa/microchip/ksz_8895.c:270:21: warning: unused variable 'dev' [-Wunused-variable]
struct ksz_device *dev = ds->priv;
^
drivers/net/dsa/microchip/ksz_8895.c: At top level:
>> drivers/net/dsa/microchip/ksz_8895.c:469:12: warning: 'struct switchdev_obj_port_fdb' declared inside parameter list
struct switchdev_trans *trans)
^
>> drivers/net/dsa/microchip/ksz_8895.c:469:12: warning: its scope is only this definition or declaration, which is probably not what you want
drivers/net/dsa/microchip/ksz_8895.c:497:16: warning: 'struct switchdev_obj_port_fdb' declared inside parameter list
struct switchdev_trans *trans)
^
drivers/net/dsa/microchip/ksz_8895.c:503:21: warning: 'struct switchdev_obj_port_fdb' declared inside parameter list
const struct switchdev_obj_port_fdb *fdb)
^
drivers/net/dsa/microchip/ksz_8895.c:510:9: warning: 'struct switchdev_obj_port_fdb' declared inside parameter list
switchdev_obj_dump_cb_t *cb)
^
>> drivers/net/dsa/microchip/ksz_8895.c:576:2: error: unknown field 'port_vlan_dump' specified in initializer
.port_vlan_dump = ksz_port_vlan_dump,
^
>> drivers/net/dsa/microchip/ksz_8895.c:576:2: warning: initialization from incompatible pointer type
drivers/net/dsa/microchip/ksz_8895.c:576:2: warning: (near initialization for 'ksz_switch_ops.port_fdb_add')
>> drivers/net/dsa/microchip/ksz_8895.c:577:2: error: unknown field 'port_fdb_prepare' specified in initializer
.port_fdb_prepare = ksz_port_fdb_prepare,
^
drivers/net/dsa/microchip/ksz_8895.c:577:2: warning: initialization from incompatible pointer type
drivers/net/dsa/microchip/ksz_8895.c:577:2: warning: (near initialization for 'ksz_switch_ops.port_fdb_del')
drivers/net/dsa/microchip/ksz_8895.c:578:2: warning: initialization from incompatible pointer type
.port_fdb_dump = ksz_port_fdb_dump,
^
drivers/net/dsa/microchip/ksz_8895.c:578:2: warning: (near initialization for 'ksz_switch_ops.port_fdb_dump')
drivers/net/dsa/microchip/ksz_8895.c:579:2: warning: initialization from incompatible pointer type
.port_fdb_add = ksz_port_fdb_add,
^
drivers/net/dsa/microchip/ksz_8895.c:579:2: warning: (near initialization for 'ksz_switch_ops.port_fdb_add')
drivers/net/dsa/microchip/ksz_8895.c:580:2: warning: initialization from incompatible pointer type
.port_fdb_del = ksz_port_fdb_del,
^
drivers/net/dsa/microchip/ksz_8895.c:580:2: warning: (near initialization for 'ksz_switch_ops.port_fdb_del')
>> drivers/net/dsa/microchip/ksz_8895.c:584:2: error: unknown field 'port_mdb_dump' specified in initializer
.port_mdb_dump = ksz_port_mdb_dump,
^
drivers/net/dsa/microchip/ksz_8895.c:584:2: warning: initialization from incompatible pointer type
drivers/net/dsa/microchip/ksz_8895.c:584:2: warning: (near initialization for 'ksz_switch_ops.get_rxnfc')
vim +19 drivers/net/dsa/microchip/ksz_9477_reg.h
> 19 #error This is not switch we have
20 #ifndef __KSZ9477_REGS_H
21 #define __KSZ9477_REGS_H
22
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 50969 bytes --]
^ permalink raw reply
* Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default
From: Jorgen S. Hansen @ 2017-08-29 15:37 UTC (permalink / raw)
To: Dexuan Cui
Cc: Stefan Hajnoczi, davem@davemloft.net, netdev@vger.kernel.org,
gregkh@linuxfoundation.org, devel@linuxdriverproject.org,
KY Srinivasan, Haiyang Zhang, Stephen Hemminger, George Zhang,
Michal Kubecek, Asias He, Vitaly Kuznetsov, Cathy Avery,
jasowang@redhat.com, Rolf Neugebauer, Dave Scott, Marcelo Cerri,
apw@canonical.com
In-Reply-To: <KL1P15301MB0008087A3EF0A8D037CC4D52BF9F0@KL1P15301MB0008.APCP153.PROD.OUTLOOK.COM>
> On Aug 29, 2017, at 4:36 AM, Dexuan Cui <decui@microsoft.com> wrote:
>
>> From: Dexuan Cui
>> Sent: Tuesday, August 22, 2017 21:21
>>> ...
>>> ...
>>> The only problem here would be the potential for a guest and a host app
>> to
>>> have a conflict wrt port numbers, even though they would be able to
>>> operate fine, if restricted to their appropriate transport.
>>>
>>> Thanks,
>>> Jorgen
>>
>> Hi Jorgen, Stefan,
>> Thank you for the detailed analysis!
>> You have a much better understanding than me about the complex
>> scenarios. Can you please work out a patch? :-)
>
> Hi Jorgen, Stefan,
> May I know your plan for this?
I’d be happy to discuss this now, but I don’t have time to work on the
actual implementation in the next couple of weeks.
For the guest, we agree that registering a guest transport should be
tied to either the hypervisor running the guest, or the existence of
the appropriate virtual hardware.
My main concern is that our existing software relies on the current
behavior of auto-loading the VMCI transport on the host side. So
changing that behavior could cause trouble for our existing Linux
users.
I’m wondering whether it would be possible to support multiple host
side transports. Since it is theoretically possible to run multiple
hypervisors at the same time, there would even be a use case for this.
If the assignment of CIDs is made unique across all transports, a
connection initiated by the host side will get directed to the
appropriate transport based on the CID. Any traffic coming from a guest
will naturally be using the appropriate transport. Host side applications
will have to share the port space as well. This would require tracking
CIDs as a common resource across all transports, but make CIDs
unique VM addresses on a given host.
If we allow multiple host side transports, virtio host side support and
vmci should be able to coexist regardless of the order of initialization.
Thanks,
Jorgen
^ permalink raw reply
* Re: [PATCH net-next v2 00/10] net: dsa: add generic debugfs interface
From: Vivien Didelot @ 2017-08-29 15:57 UTC (permalink / raw)
To: Jiri Pirko, David Miller
Cc: netdev, linux-kernel, kernel, f.fainelli, andrew, privat, john,
Woojung.Huh, sean.wang, nikita.yoush, cphealy
In-Reply-To: <20170829062931.GB1977@nanopsycho.orion>
Hi David, Jiri,
Jiri Pirko <jiri@resnulli.us> writes:
> Tue, Aug 29, 2017 at 06:38:37AM CEST, davem@davemloft.net wrote:
>>From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
>>Date: Mon, 28 Aug 2017 15:17:38 -0400
>>
>>> This patch series adds a generic debugfs interface for the DSA
>>> framework, so that all switch devices benefit from it, e.g. Marvell,
>>> Broadcom, Microchip or any other DSA driver.
>>
>>I've been thinking this over and I agree with the feedback given that
>>debugfs really isn't appropriate for this.
>>
>>Please create a DSA device class, and hang these values under
>>appropriate sysfs device nodes that can be easily found via
>>/sys/class/dsa/ just as easily as they would be /sys/kernel/debug/dsa/
>>
>>You really intend these values to be consistent across DSA devices,
>>and you don't intend to go willy-nilly changig these exported values
>>arbitrarily over time. That's what debugfs is for, throw-away
>>stuff.
>>
>>So please make these proper device sysfs attributes rather than
>>debugfs.
>
> As I wrote, I believe that there is a big overlap with devlink and its
> dpipe subset. I think that primary we should focus on extending whatever
> is needed for dsa there. The iface should be generic for all drivers,
> not only dsa. dsa-specific sysfs attributes should be last-resort solution,
> I believe we can avoid them.
Please note that this interface is only meant to provide a _debug_ and
_development_ interface to DSA users. It is enableable at compile time
and can be ditched anytime we want, in contrary to other interfaces
which cannot be broken or changed because they are part of the ABI.
I see sysfs as a script-friendly way to access and configure kernel
structures, so I agree with Jiri that it doesn't seem appropriate.
Extending devlink is a good option for long term, but it'll take a bit
of time to extend data structures and not duplicate stats and regs
accesses for ports which have a net device attached to it or not.
In the meantime, I didn't find anything more useful and easier to debug
a switch fabric than dumping side-by-side stats of all ports part of the
data plane, for example like this:
# watch -n1 pr -mt {switch0/port5,switch0/port6,switch1/port5,switch1/port3}/stats
where ports 5 and 6 of both switches are DSA/CPU ports (without net
devices attached to them) and port3 is a user port. This way one can
easily see where and why packets get dropped.
We could keep this interface and simply ditch net/dsa/debugfs.c when a
convenient devlink alternative is in place.
Thanks,
Vivien
^ permalink raw reply
* Re: net.ipv4.tcp_max_syn_backlog implementation
From: Eric Dumazet @ 2017-08-29 16:17 UTC (permalink / raw)
To: Harsha Chenji; +Cc: netdev
In-Reply-To: <CAMB9WxJ_QHJr1pHKFO0YcYdQhHBL2Ch7ugccmf9gztALiY5f-w@mail.gmail.com>
On Tue, 2017-08-29 at 11:05 -0400, Harsha Chenji wrote:
> According to the man:
>
> The behavior of the backlog argument on TCP sockets changed with Linux
> 2.2. Now it specifies the queue length for *completely established
> sockets waiting to be accepted*, instead of the number of incomplete
> connection requests. The maximum length of the queue for incomplete
> sockets can be set using /proc/sys/net/ipv4/tcp_max_syn_backlog. When
> syncookies are enabled there is no logical maximum length and this
> setting is ignored. See tcp(7) for more information.
>
>
The sysctl was simply there to make sure that someone would not :
listen(fd, 0x40000000);
It served to cap the 2nd argument of listen() to something that the
admin considered as acceptable.
This was particularly important few years back when handling of SYN_RECV
sockets involved O(N) behavior for SYNACK retransmits.
Nowadays, a backlog of 10,000,000 is okay, if you have ram to spend on
it.
> On Tue, Aug 29, 2017 at 12:17 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > On Mon, 2017-08-28 at 23:47 -0400, Harsha Chenji wrote:
> >> So I have ubuntu 12.04 x32 in a VM with syncookies turned off. I tried
> >> to do a syn flood (with netwox) on 3 different processes. Each of them
> >> returns a different value with netstat -na | grep -c RECV :
> >>
> >> nc -l 5555 returns 16 (netcat-traditional)
> >> apache2 port 80 returns 256
> >> vsftpd on 21 returns 64.
> >> net.ipv4.tcp_max_syn_backlog is 512.
> >>
> >> Why do these different processes on different ports have different
> >> queue lengths for incomplete connections? Where exactly in the kernel
> >> is this decided?
> >
> > See 2nd argument in listen() system call, ie backlog
> >
> > man listen
> >
> > Without a synflood, just look at "ss -t state listening"
> >
> > The backlog is the 2nd column (Send)
> >
> >
> >
^ permalink raw reply
* Re: XDP redirect measurements, gotchas and tracepoints
From: Alexander Duyck @ 2017-08-29 16:23 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Andy Gospodarek, Michael Chan, John Fastabend, Duyck, Alexander H,
pstaszewski@itcare.pl, netdev@vger.kernel.org,
xdp-newbies@vger.kernel.org, borkmann@iogearbox.net
In-Reply-To: <20170829152601.02fdb8a3@redhat.com>
On Tue, Aug 29, 2017 at 6:26 AM, Jesper Dangaard Brouer
<brouer@redhat.com> wrote:
>
> On Mon, 28 Aug 2017 09:11:25 -0700 Alexander Duyck <alexander.duyck@gmail.com> wrote:
>
>> My advice would be to not over complicate this. My big concern with
>> all this buffer recycling is what happens the first time somebody
>> introduces something like mirroring? Are you going to copy the data to
>> a new page which would be quite expensive or just have to introduce
>> reference counts? You are going to have to deal with stuff like
>> reference counts eventually so you might as well bite that bullet now.
>> My advice would be to not bother with optimizing for performance right
>> now and instead focus on just getting functionality. The approach we
>> took in ixgbe for the transmit path should work for almost any other
>> driver since all you are looking at is having to free the page
>> reference which takes care of reference counting already.
>
> This return API is not about optimizing performance right now. It is
> actually about allowing us to change the underlying memory model per RX
> queue for XDP.
I would disagree. To me this is a obvious case of premature optimization.
> If a RX-ring is use for both SKBs and XDP, then the refcnt model is
> still enforced. Although a driver using the 1-packet-per-page model,
> should be able to reuse refcnt==1 pages when returned from XDP.
Isn't this the case for all Rx on XDP enabled rings. Last I knew there
was an option to pass packets up via an SKB if XDP_PASS is returned.
Are you saying we need to do a special allocation path if an XDP
program doesn't make use of XDP_PASS?
> If a RX-ring is _ONLY_ used for XDP, then the driver have freedom to
> implement another memory model, with the return-API. We need to
> experiment with the most optimal memory model. The 1-packet-per-page
> model is actually not the fastest, because of PCI-e bottlenecks. With
> HW support for packing descriptors and packets over the PCI-e bus, much
> higher rates can be achieved. Mellanox mlx5-Lx already have the needed HW
> support. And companies like NetCope also have 100G HW that does
> similar tricks, and they even have a whitepaper[1][2] how they are
> faster than DPDK with their NDP (Netcope Data Plane) API.
>
> We do need the ability/flexibility to change the RX memory model, to
> take advantage of this new NIC hardware.
Looking over the white paper I see nothing that prevents us from using
the same memory model we do with the Intel NICs. If anything I think
the Intel drivers in "legacy-rx" mode could support something like
this now, even if the hardware doesn't simply because we can get away
with keeping the memory pseudo-pinned. My bigger concern is that we
keep coming back to this idea that we need to have the network stack
taking care of the 1 page per packet recycling when I really think it
has no business being there. We either need to look at implementing
this in the way we did in the Intel drivers where we use the reference
counts or implement our own memory handling API like SLUB or something
similar based on compound page destructors. I would much rather see us
focus on getting this going with an agnostic memory model where we
don't have to make the stack aware of where the memory came from or
where it has to be returned to.
> [1] https://www.netcope.com/en/resources/improving-dpdk-performance
> [2] https://www.netcope.com/en/company/press-center/press-releases/read-new-netcope-whitepaper-on-dpdk-acceleration
My only concern with something like this is the fact that it is
optimized for a setup where the data is left in place and nothing
extra is added. Trying to work with something like this gets more
expensive when you have to deal with the full stack as you have to
copy out the headers and still deal with all the skb metadata. I fully
agree with the basic premise that writing in large blocks provides
significant gains in throughput, specifically with small packets. The
only gotcha you would have to deal with is SKB allocation and data
copying overhead to make room and fill in metadata for the frame and
any extra headers needed.
- Alex
^ permalink raw reply
* Re: [PATCH net-next] bnxt_en: add a dummy definition for bnxt_vf_rep_get_fid()
From: David Miller @ 2017-08-29 16:28 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <1503987303-12392-1-git-send-email-sathya.perla@broadcom.com>
From: Sathya Perla <sathya.perla@broadcom.com>
Date: Tue, 29 Aug 2017 11:45:03 +0530
> When bnxt VF-reps are not compiled in (CONFIG_BNXT_SRIOV is off)
> bnxt_tc.c needs a dummy definition of the routine bnxt_vf_rep_get_fid().
>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Fixes: 2ae7408fedfe ("bnxt_en: bnxt: add TC flower filter offload support")
> Signed-off-by: Sathya Perla <sathya.perla@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] staging: irda: update MAINTAINERS
From: David Miller @ 2017-08-29 16:30 UTC (permalink / raw)
To: gregkh; +Cc: devel, netdev, samuel, joe, linux-kernel
In-Reply-To: <20170829070929.GA15824@kroah.com>
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Tue, 29 Aug 2017 09:09:29 +0200
> Now that the IRDA code has moved under drivers/staging/irda/, update the
> MAINTAINERS file with the new location.
>
> Reported-by: Joe Perches <joe@perches.com>
> Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
Applied.
^ permalink raw reply
* Re: [PATCH net-next] staging: irda: force to be a kernel module
From: David Miller @ 2017-08-29 16:35 UTC (permalink / raw)
To: gregkh; +Cc: devel, netdev, samuel, linux-kernel
In-Reply-To: <20170829091417.GA9481@kroah.com>
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Tue, 29 Aug 2017 11:14:17 +0200
> Now that the IRDA networking code has moved into drivers/staging/, the
> link order is changed for when it is initialized if built into the
> system. This can cause a crash when initializing as the netfilter core
> hasn't been initialized yet.
>
> So force the IRDA code to be built as a module, preventing the crash.
>
> Reported-by: kernel test robot <fengguang.wu@intel.com>
> Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
I don't think this is reasonable.
IRDA being built in was broken by moving it to staging, so it's a
regression and we should find a way to fix it.
It's one thing if IRDA on it's own has deteriorated and broken in some
ways over time due to lack of maintainence, it's another to knowingly
do something to it that causes a regression which is what happened
here.
Thanks.
^ permalink raw reply
* Re: pull request (net): ipsec 2017-08-29
From: David Miller @ 2017-08-29 16:37 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <1504002694-1931-1-git-send-email-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Tue, 29 Aug 2017 12:31:27 +0200
> 1) Fix dst_entry refcount imbalance when using socket policies.
> From Lorenzo Colitti.
>
> 2) Fix locking when adding the ESP trailers.
>
> 3) Fix tailroom calculation for the ESP trailer by using
> skb_tailroom instead of skb_availroom.
>
> 4) Fix some info leaks in xfrm_user.
> From Mathias Krause.
>
> Please pull or let me know if there are problems.
Pulled, thank you.
^ permalink raw reply
* Re: [PATCH 0/4] irda: move it to drivers/staging so we can delete it
From: David Miller @ 2017-08-29 16:38 UTC (permalink / raw)
To: geert; +Cc: gregkh, samuel, netdev, linux-kernel, devel
In-Reply-To: <CAMuHMdUefXtqv9bFfgrkbu8NZRXeTD6qR-nErf6TCDz4L+OAWw@mail.gmail.com>
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Tue, 29 Aug 2017 12:59:00 +0200
> Hi Greg,
>
> On Sun, Aug 27, 2017 at 5:03 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
>> The IRDA code has long been obsolete and broken. So, to keep people
>> from trying to use it, and to prevent people from having to maintain it,
>> let's move it to drivers/staging/ so that we can delete it entirely from
>> the kernel in a few releases.
>
> (diving into an early boot crash)
>
> Have you tried running this? ;-)
>
> irda_init() and net_dev_init() are both subsys_initcall()s.
> But the former now runs before the latter, leading to:
We must find a way to make the ordering proper again when both are
built-in.
^ permalink raw reply
* Re: [PATCH net-next 0/2] addrlabel: don't use rtnl locking
From: David Miller @ 2017-08-29 16:42 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <20170829112942.4791-1-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Tue, 29 Aug 2017 13:29:40 +0200
> addrlabel doesn't appear to require rtnl lock as the addrlabel
> table uses a spinlock to serialize add/delete operations.
>
> Also, entries are reference counted so it should be safe
> to call the rtnl ops without the rtnl mutex.
Series applied.
^ permalink raw reply
* Re: [PATCH net-next 1/4] net: Add SRIOV VGT+ support
From: Sabrina Dubroca @ 2017-08-29 16:43 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Saeed Mahameed, David S. Miller, Linux Netdev List,
Eugenia Emantayev, Mohamad Haj Yahia, Hannes Frederic Sowa
In-Reply-To: <CALzJLG8EqGLw66bzBdor629mvJdcN+YOAesTxW8_QYt_teUMiA@mail.gmail.com>
2017-08-29, 13:13:09 +0300, Saeed Mahameed wrote:
> On Mon, Aug 28, 2017 at 6:52 PM, Sabrina Dubroca <sd@queasysnail.net> wrote:
> > 2017-08-27, 14:06:15 +0300, Saeed Mahameed wrote:
> > [...]
> >> +#define VF_VLAN_BITMAP DIV_ROUND_UP(VF_VLAN_N_VID, sizeof(__u64) * BITS_PER_BYTE)
> >> +struct ifla_vf_vlan_trunk {
> >> + __u32 vf;
> >> + __u64 allowed_vlans_8021q_bm[VF_VLAN_BITMAP];
> >> + __u64 allowed_vlans_8021ad_bm[VF_VLAN_BITMAP];
> >> +};
> >
> > This is huge (1032B). And you put one of these in the netlink message
> > for each VF. This means that with 51 VF (at least in my environment,
> > where each VF takes 1296B), you're going to overflow the u16 size of a
> > single attribute (IFLA_VFINFO_LIST), and you cannot dump the device
> > anymore. I'm afraid this is going to break existing setups.
> >
>
> Yes ! We will fix this,
> we are considering to report only a boolean in VFINFO which indecates
> if VGT+ is enable or not
> and provide a new attribute per VF to report only the vlan list of specific VF.
I don't see what this is going to look like. Maybe you can describe
more precisely what you want to add to the netlink message? (otherwise
I'll wait for the patches)
If you add large attributes for each VF, this is still going to break.
Thanks.
--
Sabrina
^ permalink raw reply
* Re: [PATCH net-next 0/7] rxrpc: Miscellany
From: David Miller @ 2017-08-29 16:44 UTC (permalink / raw)
To: dhowells; +Cc: netdev, linux-afs, linux-kernel
In-Reply-To: <150400960745.21371.15455867950162722742.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Tue, 29 Aug 2017 13:26:47 +0100
>
> Here are a number of patches that make some changes/fixes and add a couple
> of extensions to AF_RXRPC for kernel services to use. The changes and
> fixes are:
...
> Tagged thusly:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
> rxrpc-next-20170829
Pulled, thanks David.
^ permalink raw reply
* Re: [PATCH net-next v2] bridge: fdb add and delete tracepoints
From: Florian Fainelli @ 2017-08-29 16:46 UTC (permalink / raw)
To: Roopa Prabhu, davem; +Cc: netdev, nikolay, bridge
In-Reply-To: <1503980568-35240-1-git-send-email-roopa@cumulusnetworks.com>
On 08/28/2017 09:22 PM, Roopa Prabhu wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> A few useful tracepoints to trace bridge forwarding
> database updates.
>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Small nit below, but probably not a candidate for a v3
> ---
> +
> + TP_printk("dev %s addr %02x:%02x:%02x:%02x:%02x:%02x vid %u nlh_flags %04x ndm_flags = %02x",
Small nit, any particular reason why ndm_flags got a special treatment
with an equal character and not the other?
> + __get_str(dev), __entry->addr[0], __entry->addr[1],
> + __entry->addr[2], __entry->addr[3], __entry->addr[4],
> + __entry->addr[5], __entry->vid,
> + __entry->nlh_flags, __entry->ndm_flags)
--
Florian
^ permalink raw reply
* Re: [PATCH net-next] Revert "ipv4: make net_protocol const"
From: David Ahern @ 2017-08-29 16:47 UTC (permalink / raw)
To: Bhumika Goyal; +Cc: netdev, David Miller
In-Reply-To: <CAOH+1jF3G+Yo30Tk=cgnAPfD8UNe+FkkLjC1uGUd9eeG-ce5KA@mail.gmail.com>
On 8/29/17 12:46 AM, Bhumika Goyal wrote:
> I am compile testing them. In this case I did: make
> net/ipv4/af_inet.o and it compiled. Is this error because of
> typecasting net_protocol inside inet_add_protocol function?
Compile testing is not sufficient. Marking data structures read-only
leaves potential land mines for others to trip over at run-time.
You are making these changes based on a code analysis. Extend the
analysis to elements of the structure. In this case early_demux is the
first element. There are only 9 references to early_demux and cscope
very quickly tells you it can be changed:
7 sysctl_net_ipv4.c proc_configure_early_demux 312 ipprot->early_demux
= enabled ? ipprot->early_demux_handler :
8 sysctl_net_ipv4.c proc_configure_early_demux 318 ip6prot->early_demux
= enabled ? ip6prot->early_demux_handler :
^ permalink raw reply
* [PATCH] net: dsa: make some structures const
From: Bhumika Goyal @ 2017-08-29 16:47 UTC (permalink / raw)
To: julia.lawall, andrew, vivien.didelot, f.fainelli, netdev,
linux-kernel
Cc: Bhumika Goyal
Make these const as they are not modified anywhere.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
---
drivers/net/dsa/bcm_sf2.c | 2 +-
drivers/net/dsa/qca8k.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index bbcb405..8492c9d 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -983,7 +983,7 @@ static int bcm_sf2_core_write64(struct b53_device *dev, u8 page, u8 reg,
return 0;
}
-static struct b53_io_ops bcm_sf2_io_ops = {
+static const struct b53_io_ops bcm_sf2_io_ops = {
.read8 = bcm_sf2_core_read8,
.read16 = bcm_sf2_core_read16,
.read32 = bcm_sf2_core_read32,
diff --git a/drivers/net/dsa/qca8k.c b/drivers/net/dsa/qca8k.c
index 17977f0..5ada7a41 100644
--- a/drivers/net/dsa/qca8k.c
+++ b/drivers/net/dsa/qca8k.c
@@ -250,7 +250,7 @@
};
-static struct regmap_access_table qca8k_readable_table = {
+static const struct regmap_access_table qca8k_readable_table = {
.yes_ranges = qca8k_readable_ranges,
.n_yes_ranges = ARRAY_SIZE(qca8k_readable_ranges),
};
--
1.9.1
^ permalink raw reply related
* [patch v1 2/2] mlxsw: core: add support for the external thermal zone setting (by DTS)
From: Vadim Pasternak @ 2017-08-29 18:45 UTC (permalink / raw)
To: robh+dt, davem; +Cc: jiri, ivecera, devicetree, netdev, Vadim Pasternak
In-Reply-To: <1504032311-195988-1-git-send-email-vadimp@mellanox.com>
It allows:
- thermal zone setting for mlxsw based HW and from DTS file;
- binding ASIC temperature sensor to cooling devices.
It requires setting of CONFIG_OF.
Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/core_thermal.c | 107 ++++++++++++++++++++-
drivers/net/ethernet/mellanox/mlxsw/minimal.c | 6 ++
2 files changed, 109 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
index d866c98..c30783e 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
@@ -34,6 +34,7 @@
#include <linux/kernel.h>
#include <linux/types.h>
#include <linux/device.h>
+#include <linux/of_platform.h>
#include <linux/sysfs.h>
#include <linux/thermal.h>
#include <linux/err.h>
@@ -44,6 +45,7 @@
#define MLXSW_THERMAL_MAX_TEMP 110000 /* 110C */
#define MLXSW_THERMAL_MAX_STATE 10
#define MLXSW_THERMAL_MAX_DUTY 255
+#define MLXSW_THERMAL_TRIP_ELEM 4
struct mlxsw_thermal_trip {
int type;
@@ -98,6 +100,8 @@ struct mlxsw_thermal {
struct thermal_cooling_device *cdevs[MLXSW_MFCR_PWMS_MAX];
struct mlxsw_thermal_trip trips[MLXSW_THERMAL_NUM_TRIPS];
enum thermal_device_mode mode;
+ int ntrips;
+ bool cooling_external;
};
static inline u8 mlxsw_state_to_duty(int state)
@@ -121,6 +125,10 @@ static int mlxsw_get_cooling_device_idx(struct mlxsw_thermal *thermal,
if (thermal->cdevs[i] == cdev)
return i;
+ /* Allow external cooling binding if theres is no local. */
+ if (thermal->cooling_external)
+ return 0;
+
return -ENODEV;
}
@@ -334,6 +342,83 @@ static const struct thermal_cooling_device_ops mlxsw_cooling_ops = {
.set_cur_state = mlxsw_thermal_set_cur_state,
};
+#ifdef CONFIG_OF
+static int
+mlxsw_thermal_of_init(struct device *dev, struct mlxsw_thermal *thermal)
+{
+ struct device_node *np = dev->of_node;
+ u32 trip[MLXSW_THERMAL_TRIP_ELEM];
+ struct platform_device *pdev;
+ struct device_node *phandle;
+ struct device_node *gchild;
+ struct device_node *child;
+ int ntrips;
+ int i;
+ int ret;
+
+ /* trips */
+ child = of_get_child_by_name(np, "trips");
+
+ /* No trips provided */
+ if (!child) {
+ of_node_put(child);
+ return -EINVAL;
+ }
+
+ /* Cooling device is optional parameter. If it is not defined, driver
+ * will try to connect PWM which is owned, if any.
+ */
+ phandle = of_parse_phandle(child, "cooling-phandle", 0);
+ if (phandle) {
+ pdev = of_find_device_by_node(phandle);
+ of_node_put(phandle);
+ if (!pdev) {
+ ret = -ENODEV;
+ goto put_child;
+ }
+
+ thermal->cooling_external = true;
+ }
+
+ ntrips = of_get_child_count(child);
+ if (ntrips == 0) {
+ /* should have at least one child */
+ ret = 0;
+ goto put_child;
+ }
+
+ i = 0;
+ for_each_child_of_node(child, gchild) {
+ ret = of_property_count_u32_elems(gchild, "trip");
+ if (ret != MLXSW_THERMAL_TRIP_ELEM) {
+ ret = -EINVAL;
+ goto put_child;
+ }
+
+ ret = of_property_read_u32_array(gchild, "trip",
+ trip, ret);
+ if (ret)
+ goto put_gchild;
+
+ memcpy(&thermal->trips[i++], trip, sizeof(trip));
+ }
+ ret = ntrips;
+
+put_gchild:
+ of_node_put(gchild);
+put_child:
+ of_node_put(child);
+
+ return ret;
+}
+#else
+static int
+mlxsw_thermal_of_init(struct device *dev, struct mlxsw_thermal *thermal)
+{
+ return 0;
+}
+#endif
+
int mlxsw_thermal_init(struct mlxsw_core *core,
const struct mlxsw_bus_info *bus_info,
struct mlxsw_thermal **p_thermal)
@@ -344,7 +429,9 @@ int mlxsw_thermal_init(struct mlxsw_core *core,
struct mlxsw_thermal *thermal;
u16 tacho_active;
u8 pwm_active;
- int err, i;
+ int ntrips;
+ int i;
+ int err;
thermal = devm_kzalloc(dev, sizeof(*thermal),
GFP_KERNEL);
@@ -353,7 +440,19 @@ int mlxsw_thermal_init(struct mlxsw_core *core,
thermal->core = core;
thermal->bus_info = bus_info;
- memcpy(thermal->trips, default_thermal_trips, sizeof(thermal->trips));
+
+ if (dev->of_node) {
+ ntrips = mlxsw_thermal_of_init(dev, thermal);
+ if (ntrips > 0)
+ thermal->ntrips = ntrips;
+ }
+
+ if (!dev->of_node || ntrips <= 0) {
+ /* Use default if the external setting is not available */
+ memcpy(thermal->trips, default_thermal_trips,
+ sizeof(thermal->trips));
+ thermal->ntrips = MLXSW_THERMAL_NUM_TRIPS;
+ }
err = mlxsw_reg_query(thermal->core, MLXSW_REG(mfcr), mfcr_pl);
if (err) {
@@ -398,8 +497,8 @@ int mlxsw_thermal_init(struct mlxsw_core *core,
}
thermal->tzdev = thermal_zone_device_register("mlxsw",
- MLXSW_THERMAL_NUM_TRIPS,
- MLXSW_THERMAL_TRIP_MASK,
+ thermal->ntrips,
+ BIT(thermal->ntrips) - 1,
thermal,
&mlxsw_thermal_ops,
NULL, 0,
diff --git a/drivers/net/ethernet/mellanox/mlxsw/minimal.c b/drivers/net/ethernet/mellanox/mlxsw/minimal.c
index 3dd1626..8e3cc13 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/minimal.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/minimal.c
@@ -56,8 +56,14 @@ static const struct i2c_device_id mlxsw_minimal_i2c_id[] = {
{ },
};
+static const struct of_device_id mlxsw_minimal_dt_match[] = {
+ { .compatible = "mellanox,mlxsw_minimal" },
+ { },
+};
+
static struct i2c_driver mlxsw_minimal_i2c_driver = {
.driver.name = "mlxsw_minimal",
+ .driver.of_match_table = of_match_ptr(mlxsw_minimal_dt_match),
.class = I2C_CLASS_HWMON,
.id_table = mlxsw_minimal_i2c_id,
};
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 0/4] irda: move it to drivers/staging so we can delete it
From: David Miller @ 2017-08-29 16:49 UTC (permalink / raw)
To: gregkh; +Cc: devel, samuel, netdev, linux-kernel, sbrivio, geert
In-Reply-To: <20170829144850.GC22532@kroah.com>
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Tue, 29 Aug 2017 16:48:50 +0200
> On Tue, Aug 29, 2017 at 02:11:39PM +0200, Geert Uytterhoeven wrote:
>> Hi Greg,
>>
>> On Tue, Aug 29, 2017 at 1:28 PM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>> > On Tue, Aug 29, 2017 at 01:11:31PM +0200, Stefano Brivio wrote:
>> >> On Tue, 29 Aug 2017 12:59:00 +0200
>> >> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> >> > On Sun, Aug 27, 2017 at 5:03 PM, Greg Kroah-Hartman
>> >> > <gregkh@linuxfoundation.org> wrote:
>> >> > > The IRDA code has long been obsolete and broken. So, to keep people
>> >> > > from trying to use it, and to prevent people from having to maintain it,
>> >> > > let's move it to drivers/staging/ so that we can delete it entirely from
>> >> > > the kernel in a few releases.
>> >> >
>> >> > (diving into an early boot crash)
>> >> >
>> >> > Have you tried running this? ;-)
>> >> >
>> >> > irda_init() and net_dev_init() are both subsys_initcall()s.
>> >> > But the former now runs before the latter, leading to:
>> >> >
>> >> > Unable to handle kernel NULL pointer dereference at virtual address 00000004
>> >>
>> >> Should be fixed by https://patchwork.ozlabs.org/patch/807006/
>> >> ("[net-next] staging: irda: force to be a kernel module") I guess...
>> >
>> > Yup, that's the fix for this issue.
>> >
>> > Geert, does that fix the problem for you?
>>
>> Thanks, that patch fixes the crash, obviously.
>>
>> It does mean you can no longer have IrDA in a non-modular kernel.
>
> Given that irda doesn't really work, I doubt anyone is going to care
> about it :)
The initialization with everything built-in worked fine before your
changes.
^ permalink raw reply
* Re: [PATCH net-next 4/7] xdp: separate xdp_redirect tracepoint in error case
From: Alexei Starovoitov @ 2017-08-29 17:02 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: netdev, John Fastabend
In-Reply-To: <150401747611.16384.8021135230122395742.stgit@firesoul>
On Tue, Aug 29, 2017 at 04:37:56PM +0200, Jesper Dangaard Brouer wrote:
> There is a need to separate the xdp_redirect tracepoint into two
> tracepoints, for separating the error case from the normal forward
> case.
>
> Due to the extreme speeds XDP is operating at, loading a tracepoint
> have a measurable impact. Single core XDP REDIRECT (ethtool tuned
> rx-usecs 25) can do 13.7 Mpps forwarding, but loading a simple
> bpf_prog at the tracepoint (with a return 0) reduce perf to 10.2 Mpps
> (CPU E5-1650 v4 @ 3.60GHz, driver: ixgbe)
>
> The overhead of loading a bpf-based tracepoint can be calculated to
> cost 25 nanosec ((1/13782002-1/10267937)*10^9 = -24.83 ns).
>
> Using perf record on the tracepoint event, with a non-matching --filter
> expression, the overhead is much larger. Performance drops to 8.3 Mpps,
> cost 48 nanosec ((1/13782002-1/8312497)*10^9 = -47.74))
>
> Having a separate tracepoint for err cases, which should be less
> frequent, allow running a continuous monitor for errors while not
> affecting the redirect forward performance (this have also been
> verified by measurements).
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
thanks for detailed analysis of performance impact of the changes.
looks great to me.
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ 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