* [PATCH 73/87] ethernet: freescale: Remove memset after dma_alloc_coherent
From: Fuqian Huang @ 2019-06-27 17:46 UTC (permalink / raw)
Cc: Fuqian Huang, Fugang Duan, David S. Miller, netdev, linux-kernel
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
drivers/net/ethernet/freescale/fec_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 38f10f7dcbc3..ec87b8b78d21 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -3143,8 +3143,6 @@ static int fec_enet_init(struct net_device *ndev)
return -ENOMEM;
}
- memset(cbd_base, 0, bd_size);
-
/* Get the Ethernet address */
fec_get_mac(ndev);
/* make sure MAC we just acquired is programmed into the hw */
--
2.11.0
^ permalink raw reply related
* [PATCH 75/87] ethernet: marvell: remove memset after pci_alloc_consistent
From: Fuqian Huang @ 2019-06-27 17:46 UTC (permalink / raw)
Cc: Fuqian Huang, Mirko Lindner, Stephen Hemminger, David S. Miller,
netdev, linux-kernel
pci_alloc_consistent calls dma_alloc_coherent directly.
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
drivers/net/ethernet/marvell/skge.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/skge.c b/drivers/net/ethernet/marvell/skge.c
index 35a92fd2cf39..9ac854c2b371 100644
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -2558,8 +2558,6 @@ static int skge_up(struct net_device *dev)
goto free_pci_mem;
}
- memset(skge->mem, 0, skge->mem_size);
-
err = skge_ring_alloc(&skge->rx_ring, skge->mem, skge->dma);
if (err)
goto free_pci_mem;
--
2.11.0
^ permalink raw reply related
* [PATCH 74/87] ethernet: jme.c: remove memset after dma_alloc_coherent
From: Fuqian Huang @ 2019-06-27 17:46 UTC (permalink / raw)
Cc: Fuqian Huang, Guo-Fu Tseng, David S. Miller, netdev, linux-kernel
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
drivers/net/ethernet/jme.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/net/ethernet/jme.c b/drivers/net/ethernet/jme.c
index 76b7b7b85e35..0b668357db4d 100644
--- a/drivers/net/ethernet/jme.c
+++ b/drivers/net/ethernet/jme.c
@@ -582,11 +582,6 @@ jme_setup_tx_resources(struct jme_adapter *jme)
if (unlikely(!(txring->bufinf)))
goto err_free_txring;
- /*
- * Initialize Transmit Descriptors
- */
- memset(txring->alloc, 0, TX_RING_ALLOC_SIZE(jme->tx_ring_size));
-
return 0;
err_free_txring:
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 79/87] net: vmxnet3: remove memset after dma_alloc_coherent
From: David Miller @ 2019-06-27 17:47 UTC (permalink / raw)
To: huangfq.daxian; +Cc: doshir, pv-drivers, netdev, linux-kernel
In-Reply-To: <20190627174509.5829-1-huangfq.daxian@gmail.com>
I'd kindly request that you separate these sets of changes into one
set per subsystem and submit them properly that way.
I'm really not going to sift through 87 patches and pull out the ones
individually that got to my tree(s). That's your job to collect them
into appropriate groups properly.
Thank you.
^ permalink raw reply
* Re: [PATCH bpf-next 1/3] libbpf: capture value in BTF type info for BTF-defined map defs
From: Andrii Nakryiko @ 2019-06-27 17:47 UTC (permalink / raw)
To: Song Liu
Cc: Andrii Nakryiko, Alexei Starovoitov, daniel@iogearbox.net,
Kernel Team, bpf@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <E28D922F-9D97-4836-B687-B4CBC3549AE1@fb.com>
On Thu, Jun 27, 2019 at 10:27 AM Song Liu <songliubraving@fb.com> wrote:
>
>
>
> > On Jun 26, 2019, at 4:21 PM, Andrii Nakryiko <andriin@fb.com> wrote:
> >
> > Change BTF-defined map definitions to capture compile-time integer
> > values as part of BTF type definition, to avoid split of key/value type
> > information and actual type/size/flags initialization for maps.
>
> If I have an old bpf program and compiled it with new llvm, will it
> work with new libbpf?
You mean BPF programs that used previous incarnation of BTF-defined
maps? No, they won't work. But we never released them, so I think it's
ok to change them. Nothing should be using that except for selftests,
which I fixed.
>
>
> >
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > ---
<snip>
> > diff --git a/tools/testing/selftests/bpf/bpf_helpers.h b/tools/testing/selftests/bpf/bpf_helpers.h
> > index 1a5b1accf091..aa5ddf58c088 100644
> > --- a/tools/testing/selftests/bpf/bpf_helpers.h
> > +++ b/tools/testing/selftests/bpf/bpf_helpers.h
> > @@ -8,6 +8,9 @@
> > */
> > #define SEC(NAME) __attribute__((section(NAME), used))
> >
> > +#define __int(name, val) int (*name)[val]
> > +#define __type(name, val) val *name
> > +
>
> I think we need these two in libbpf.
Yes, but it's another story for another set of patches. We'll need to
provide bpf_helpers as part of libbpf for inclusion into BPF programs,
but there are a bunch of problems right now with existing
bpf_heplers.h that prevents us from just copying it into libbpf. We'll
need to resolve those first.
But then again, there is no use of __int and __type for user-space
programs, so for now it's ok.
>
> Thanks,
> Song
>
> > /* helper macro to print out debug messages */
> > #define bpf_printk(fmt, ...) \
> > ({ \
> > --
> > 2.17.1
> >
>
^ permalink raw reply
* Re: [RFC] longer netdev names proposal
From: Jakub Kicinski @ 2019-06-27 17:48 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, sthemmin, dsahern, mlxsw
In-Reply-To: <20190627094327.GF2424@nanopsycho>
On Thu, 27 Jun 2019 11:43:27 +0200, Jiri Pirko wrote:
> Hi all.
>
> In the past, there was repeatedly discussed the IFNAMSIZ (16) limit for
> netdevice name length. Now when we have PF and VF representors
> with port names like "pfXvfY", it became quite common to hit this limit:
> 0123456789012345
> enp131s0f1npf0vf6
> enp131s0f1npf0vf22
>
> Since IFLA_NAME is just a string, I though it might be possible to use
> it to carry longer names as it is. However, the userspace tools, like
> iproute2, are doing checks before print out. So for example in output of
> "ip addr" when IFLA_NAME is longer than IFNAMSIZE, the netdevice is
> completely avoided.
>
> So here is a proposal that might work:
> 1) Add a new attribute IFLA_NAME_EXT that could carry names longer than
> IFNAMSIZE, say 64 bytes. The max size should be only defined in kernel,
> user should be prepared for any string size.
> 2) Add a file in sysfs that would indicate that NAME_EXT is supported by
> the kernel.
> 3) Udev is going to look for the sysfs indication file. In case when
> kernel supports long names, it will do rename to longer name, setting
> IFLA_NAME_EXT. If not, it does what it does now - fail.
> 4) There are two cases that can happen during rename:
> A) The name is shorter than IFNAMSIZ
> -> both IFLA_NAME and IFLA_NAME_EXT would contain the same string:
> original IFLA_NAME = eth0
> original IFLA_NAME_EXT = eth0
> renamed IFLA_NAME = enp5s0f1npf0vf1
> renamed IFLA_NAME_EXT = enp5s0f1npf0vf1
> B) The name is longer tha IFNAMSIZ
> -> IFLA_NAME would contain the original one, IFLA_NAME_EXT would
> contain the new one:
> original IFLA_NAME = eth0
> original IFLA_NAME_EXT = eth0
> renamed IFLA_NAME = eth0
> renamed IFLA_NAME_EXT = enp131s0f1npf0vf22
I think B is the only way, A risks duplicate IFLA_NAMEs over ioctl,
right? And maybe there is some crazy application out there which
mixes netlink and ioctl.
I guess it's not worse than status quo, given that today renames
will fail and we will either get truncated names or eth0s..
> This would allow the old tools to work with "eth0" and the new
> tools would work with "enp131s0f1npf0vf22". In sysfs, there would
> be symlink from one name to another.
>
> Also, there might be a warning added to kernel if someone works
> with IFLA_NAME that the userspace tool should be upgraded.
>
> Eventually, only IFLA_NAME_EXT is going to be used by everyone.
>
> I'm aware there are other places where similar new attribute
> would have to be introduced too (ip rule for example).
> I'm not saying this is a simple work.
>
> Question is what to do with the ioctl api (get ifindex etc). I would
> probably leave it as is and push tools to use rtnetlink instead.
>
> Any ideas why this would not work? Any ideas how to solve this
> differently?
Since we'd have to update all user space to make use of the new names
I'd be tempted to move to a more structured device identification.
5: enp131s0f1npf0vf6: <BROADCAST,MULTICAST> ...
vs:
5: eth5 (parent enp131s0f1 pf 0 vf 6 peer X*): <BROADCAST,MULTICAST> ...
* ;)
And allow filtering/selection of device based on more attributes than
just name and ifindex. In practice in container workloads, for example,
the names are already very much insufficient to identify the device.
Refocusing on attributes is probably a big effort and not that practical
for traditional CLI users? IDK
Anyway, IMHO your scheme is strictly better than status quo.
^ permalink raw reply
* Re: [net-next 00/10][pull request] Intel Wired LAN Driver Updates 2019-06-26
From: David Miller @ 2019-06-27 17:49 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann
In-Reply-To: <20190626193103.2169-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 26 Jun 2019 12:30:53 -0700
> This series contains updates to ixgbe and i40e only.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [RFC] longer netdev names proposal
From: Stephen Hemminger @ 2019-06-27 17:56 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Jiri Pirko, netdev, davem, sthemmin, dsahern, mlxsw
In-Reply-To: <20190627104808.1404049a@cakuba.netronome.com>
On Thu, 27 Jun 2019 10:48:08 -0700
Jakub Kicinski <jakub.kicinski@netronome.com> wrote:
> On Thu, 27 Jun 2019 11:43:27 +0200, Jiri Pirko wrote:
> > Hi all.
> >
> > In the past, there was repeatedly discussed the IFNAMSIZ (16) limit for
> > netdevice name length. Now when we have PF and VF representors
> > with port names like "pfXvfY", it became quite common to hit this limit:
> > 0123456789012345
> > enp131s0f1npf0vf6
> > enp131s0f1npf0vf22
> >
> > Since IFLA_NAME is just a string, I though it might be possible to use
> > it to carry longer names as it is. However, the userspace tools, like
> > iproute2, are doing checks before print out. So for example in output of
> > "ip addr" when IFLA_NAME is longer than IFNAMSIZE, the netdevice is
> > completely avoided.
> >
> > So here is a proposal that might work:
> > 1) Add a new attribute IFLA_NAME_EXT that could carry names longer than
> > IFNAMSIZE, say 64 bytes. The max size should be only defined in kernel,
> > user should be prepared for any string size.
> > 2) Add a file in sysfs that would indicate that NAME_EXT is supported by
> > the kernel.
> > 3) Udev is going to look for the sysfs indication file. In case when
> > kernel supports long names, it will do rename to longer name, setting
> > IFLA_NAME_EXT. If not, it does what it does now - fail.
> > 4) There are two cases that can happen during rename:
> > A) The name is shorter than IFNAMSIZ
> > -> both IFLA_NAME and IFLA_NAME_EXT would contain the same string:
> > original IFLA_NAME = eth0
> > original IFLA_NAME_EXT = eth0
> > renamed IFLA_NAME = enp5s0f1npf0vf1
> > renamed IFLA_NAME_EXT = enp5s0f1npf0vf1
> > B) The name is longer tha IFNAMSIZ
> > -> IFLA_NAME would contain the original one, IFLA_NAME_EXT would
> > contain the new one:
> > original IFLA_NAME = eth0
> > original IFLA_NAME_EXT = eth0
> > renamed IFLA_NAME = eth0
> > renamed IFLA_NAME_EXT = enp131s0f1npf0vf22
>
> I think B is the only way, A risks duplicate IFLA_NAMEs over ioctl,
> right? And maybe there is some crazy application out there which
> mixes netlink and ioctl.
>
> I guess it's not worse than status quo, given that today renames
> will fail and we will either get truncated names or eth0s..
>
> > This would allow the old tools to work with "eth0" and the new
> > tools would work with "enp131s0f1npf0vf22". In sysfs, there would
> > be symlink from one name to another.
> >
> > Also, there might be a warning added to kernel if someone works
> > with IFLA_NAME that the userspace tool should be upgraded.
> >
> > Eventually, only IFLA_NAME_EXT is going to be used by everyone.
> >
> > I'm aware there are other places where similar new attribute
> > would have to be introduced too (ip rule for example).
> > I'm not saying this is a simple work.
> >
> > Question is what to do with the ioctl api (get ifindex etc). I would
> > probably leave it as is and push tools to use rtnetlink instead.
> >
> > Any ideas why this would not work? Any ideas how to solve this
> > differently?
>
> Since we'd have to update all user space to make use of the new names
> I'd be tempted to move to a more structured device identification.
>
> 5: enp131s0f1npf0vf6: <BROADCAST,MULTICAST> ...
>
> vs:
>
> 5: eth5 (parent enp131s0f1 pf 0 vf 6 peer X*): <BROADCAST,MULTICAST> ...
>
> * ;)
>
> And allow filtering/selection of device based on more attributes than
> just name and ifindex. In practice in container workloads, for example,
> the names are already very much insufficient to identify the device.
> Refocusing on attributes is probably a big effort and not that practical
> for traditional CLI users? IDK
>
> Anyway, IMHO your scheme is strictly better than status quo.
Or Cisco style naming ;-) Ethernet0/0
There is a better solution for human use already.
the field ifalias allows arbitrary values and hooked into SNMP.
Why not have userspace fill in this field with something by default?
^ permalink raw reply
* Re: [PATCH bpf-next 1/3] libbpf: capture value in BTF type info for BTF-defined map defs
From: Song Liu @ 2019-06-27 17:55 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Andrii Nakryiko, Alexei Starovoitov, daniel@iogearbox.net,
Kernel Team, bpf@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <CAEf4Bza1p4ozVV-Vn8ibV6JRtGc_voh-Mkx51eWvuVi1P8ogSA@mail.gmail.com>
> On Jun 27, 2019, at 10:47 AM, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>
> On Thu, Jun 27, 2019 at 10:27 AM Song Liu <songliubraving@fb.com> wrote:
>>
>>
>>
>>> On Jun 26, 2019, at 4:21 PM, Andrii Nakryiko <andriin@fb.com> wrote:
>>>
>>> Change BTF-defined map definitions to capture compile-time integer
>>> values as part of BTF type definition, to avoid split of key/value type
>>> information and actual type/size/flags initialization for maps.
>>
>> If I have an old bpf program and compiled it with new llvm, will it
>> work with new libbpf?
>
> You mean BPF programs that used previous incarnation of BTF-defined
> maps? No, they won't work. But we never released them, so I think it's
> ok to change them. Nothing should be using that except for selftests,
> which I fixed.
I see. This makes sense.
>
>>
>>
>>>
>>> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
>>> ---
>
> <snip>
>
>>> diff --git a/tools/testing/selftests/bpf/bpf_helpers.h b/tools/testing/selftests/bpf/bpf_helpers.h
>>> index 1a5b1accf091..aa5ddf58c088 100644
>>> --- a/tools/testing/selftests/bpf/bpf_helpers.h
>>> +++ b/tools/testing/selftests/bpf/bpf_helpers.h
>>> @@ -8,6 +8,9 @@
>>> */
>>> #define SEC(NAME) __attribute__((section(NAME), used))
>>>
>>> +#define __int(name, val) int (*name)[val]
>>> +#define __type(name, val) val *name
>>> +
>>
>> I think we need these two in libbpf.
>
> Yes, but it's another story for another set of patches. We'll need to
> provide bpf_helpers as part of libbpf for inclusion into BPF programs,
> but there are a bunch of problems right now with existing
> bpf_heplers.h that prevents us from just copying it into libbpf. We'll
> need to resolve those first.
>
> But then again, there is no use of __int and __type for user-space
> programs, so for now it's ok.
OK. How about we put these two lines in an separate patch?
Thanks,
Song
^ permalink raw reply
* Re: [PATCH net-next 12/16] mlxsw: spectrum: PTP: Support timestamping on Spectrum-1
From: Petr Machata @ 2019-06-27 17:57 UTC (permalink / raw)
To: David Miller
Cc: idosch@idosch.org, netdev@vger.kernel.org, Jiri Pirko, mlxsw,
Ido Schimmel
In-Reply-To: <20190627.100427.16208207750306183.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Ido Schimmel <idosch@idosch.org>
> Date: Thu, 27 Jun 2019 16:52:55 +0300
>
>> + for (i = 0; i < num_rec; ++i) {
>
> Please use the more canonical "i++" here, thank you.
OK.
^ permalink raw reply
* Re: [PATCH net] net/ibmvnic: Report last valid speed and duplex values to ethtool
From: Andrew Lunn @ 2019-06-27 17:57 UTC (permalink / raw)
To: Thomas Falcon; +Cc: netdev, linuxppc-dev, bjking1, pradeep, dnbanerg
In-Reply-To: <1561655353-17114-1-git-send-email-tlfalcon@linux.ibm.com>
On Thu, Jun 27, 2019 at 12:09:13PM -0500, Thomas Falcon wrote:
> This patch resolves an issue with sensitive bonding modes
> that require valid speed and duplex settings to function
> properly. Currently, the adapter will report that device
> speed and duplex is unknown if the communication link
> with firmware is unavailable.
Dumb question. If you cannot communicate with the firmware, isn't the
device FUBAR? So setting the LACP port to disabled is the correct
things to do.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v3 0/8] net: aquantia: implement vlan offloads
From: David Miller @ 2019-06-27 17:58 UTC (permalink / raw)
To: Igor.Russkikh; +Cc: netdev
In-Reply-To: <cover.1561552290.git.igor.russkikh@aquantia.com>
From: Igor Russkikh <Igor.Russkikh@aquantia.com>
Date: Wed, 26 Jun 2019 12:35:30 +0000
> This patchset introduces hardware VLAN offload support and also does some
> maintenance: we replace driver version with uts version string, add
> documentation file for atlantic driver, and update maintainers
> adding Igor as a maintainer.
>
> v3: shuffle doc sections, per Andrew's comments
>
> v2: updates in doc, gpl spdx tag cleanup
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH V4 00/10] net: dsa: microchip: Convert to regmap
From: David Miller @ 2019-06-27 18:00 UTC (permalink / raw)
To: marex; +Cc: netdev, andrew, f.fainelli, Tristram.Ha, Woojung.Huh
In-Reply-To: <20190625234348.16246-1-marex@denx.de>
From: Marek Vasut <marex@denx.de>
Date: Wed, 26 Jun 2019 01:43:38 +0200
> This patchset converts KSZ9477 switch driver to regmap.
>
> This was tested with extra patches on KSZ8795. This was also tested
> on KSZ9477 on Microchip KSZ9477EVB board, which I now have.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 00/10] FDB, VLAN and PTP fixes for SJA1105 DSA
From: David Miller @ 2019-06-27 18:04 UTC (permalink / raw)
To: olteanv; +Cc: f.fainelli, vivien.didelot, andrew, netdev
In-Reply-To: <20190625233942.1946-1-olteanv@gmail.com>
From: Vladimir Oltean <olteanv@gmail.com>
Date: Wed, 26 Jun 2019 02:39:32 +0300
> This patchset is an assortment of fixes for the net-next version of the
> sja1105 DSA driver:
> - Avoid a kernel panic when the driver fails to probe or unregisters
> - Finish Arnd Bermann's idea of compiling PTP support as part of the
> main DSA driver and not separately
> - Better handling of initial port-based VLAN as well as VLANs for
> dsa_8021q FDB entries
> - Fix address learning for the SJA1105 P/Q/R/S family
> - Make static FDB entries persistent across switch resets
> - Fix reporting of statically-added FDB entries in 'bridge fdb show'
Series applied, thanks.
^ permalink raw reply
* Re: [RFC] longer netdev names proposal
From: Michal Kubecek @ 2019-06-27 18:08 UTC (permalink / raw)
To: netdev; +Cc: David Ahern, Jiri Pirko, davem, jakub.kicinski, sthemmin, mlxsw
In-Reply-To: <26b73332-9ea0-9d2c-9185-9de522c72bb9@gmail.com>
On Thu, Jun 27, 2019 at 11:14:31AM -0600, David Ahern wrote:
> > 4) There are two cases that can happen during rename:
> > A) The name is shorter than IFNAMSIZ
> > -> both IFLA_NAME and IFLA_NAME_EXT would contain the same string:
> > original IFLA_NAME = eth0
> > original IFLA_NAME_EXT = eth0
> > renamed IFLA_NAME = enp5s0f1npf0vf1
> > renamed IFLA_NAME_EXT = enp5s0f1npf0vf1
> > B) The name is longer tha IFNAMSIZ
> > -> IFLA_NAME would contain the original one, IFLA_NAME_EXT would
> > contain the new one:
> > original IFLA_NAME = eth0
> > original IFLA_NAME_EXT = eth0
> > renamed IFLA_NAME = eth0
> > renamed IFLA_NAME_EXT = enp131s0f1npf0vf22
>
> so kernel side there will be 2 names for the same net_device?
It often feels as a deficiency that unlike block devices where we can
keep one name and create multiple symlinks based on different naming
schemes, network devices can have only one name. There are aliases but
AFAIK they are only used (and can be only used) for SNMP. IMHO this
limitation is part of the mess that left us with so-called "predictable
names" which are in practice neither persistent nor predictable.
So perhaps we could introduce actual aliases (or altnames or whatever we
would call them) for network devices that could be used to identify
a network device whenever both kernel and userspace tool supports them.
Old (and ancient) tools would have to use the one canonical name limited
to current IFNAMSIZ, new tools would allow using any alias which could
be longer.
Michal
^ permalink raw reply
* Re: [PATCH V33 24/30] bpf: Restrict bpf when kernel lockdown is in confidentiality mode
From: James Morris @ 2019-06-27 18:06 UTC (permalink / raw)
To: Stephen Smalley
Cc: Andy Lutomirski, Andy Lutomirski, Matthew Garrett, linux-security,
LKML, Linux API, David Howells, Alexei Starovoitov,
Matthew Garrett, Network Development, Chun-Yi Lee,
Daniel Borkmann, linux-security-module
In-Reply-To: <bce70c8b-9efd-6362-d536-cfbbcf70b0b7@tycho.nsa.gov>
On Thu, 27 Jun 2019, Stephen Smalley wrote:
> There are two scenarios where finer-grained distinctions make sense:
>
> - Users may need to enable specific functionality that falls under the
> umbrella of "confidentiality" or "integrity" lockdown. Finer-grained lockdown
> reasons free them from having to make an all-or-nothing choice between lost
> functionality or no lockdown at all.
Agreed. This will be used for more than just UEFI secure boot on desktops,
e.g. embedded systems using verified boot, where finer grained policy will
be needed for what are sometimes very specific use-cases (which may be
also covered by other mitigations).
> This can be supported directly by the
> lockdown module without any help from SELinux or other security modules; we
> just need the ability to specify these finer-grained lockdown levels via the
> boot parameters and securityfs nodes.
If the lockdown LSM implements fine grained policy (rather than the simple
coarse grained policy), I'd suggest adding a new lockdown level of
'custom' which by default enables all hooks but allows selective
disablement via params/sysfs.
This would be simpler than telling users to use a different lockdown LSM
for this.
> - Different processes/programs may need to use different sets of functionality
> restricted via lockdown confidentiality or integrity categories. If we have
> to allow all-or-none for the set of interfaces/functionality covered by the
> generic confidentiality or integrity categories, then we'll end up having to
> choose between lost functionality or overprivileged processes, neither of
> which is optimal.
>
> Is it truly the case that everything under the "confidentiality" category
> poses the same level of risk to kernel confidentiality, and similarly for
> everything under the "integrity" category? If not, then being able to
> distinguish them definitely has benefit.
Good question. We can't know the answer to this unless we know how an
attacker might leverage access.
The value here IMHO is more in allowing tradeoffs to be made by system
designers vs. disabling lockdown entirely.
> I'm still not clear though on how/if this will compose with or be overridden
> by other security modules. We would need some means for another security
> module to take over lockdown decisions once it has initialized (including
> policy load), and to be able to access state that is currently private to the
> lockdown module, like the level.
Why not utilize stacking (restrictively), similarly to capabilities?
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH next 3/3] blackhole_dev: add a selftest
From: David Miller @ 2019-06-27 18:08 UTC (permalink / raw)
To: maheshb; +Cc: netdev, edumazet, michael.chan, dja, mahesh
In-Reply-To: <20190622004539.92199-1-maheshb@google.com>
From: Mahesh Bandewar <maheshb@google.com>
Date: Fri, 21 Jun 2019 17:45:39 -0700
> --- a/tools/testing/selftests/net/Makefile
> +++ b/tools/testing/selftests/net/Makefile
> @@ -4,8 +4,9 @@
> CFLAGS = -Wall -Wl,--no-as-needed -O2 -g
> CFLAGS += -I../../../../usr/include/
>
> +<<<<<<< HEAD
> TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh \
Ummm... yeah... might want to resolve this conflict...
:-)
^ permalink raw reply
* Re: [PATCH v2 net-next] ipv6: Convert gateway validation to use fib6_info
From: David Miller @ 2019-06-27 18:11 UTC (permalink / raw)
To: dsahern; +Cc: netdev, kafai, weiwan, dsahern
In-Reply-To: <20190624204451.10929-1-dsahern@kernel.org>
From: David Ahern <dsahern@kernel.org>
Date: Mon, 24 Jun 2019 13:44:51 -0700
> From: David Ahern <dsahern@gmail.com>
>
> Gateway validation does not need a dst_entry, it only needs the fib
> entry to validate the gateway resolution and egress device. So,
> convert ip6_nh_lookup_table from ip6_pol_route to fib6_table_lookup
> and ip6_route_check_nh to use fib6_lookup over rt6_lookup.
>
> ip6_pol_route is a call to fib6_table_lookup and if successful a call
> to fib6_select_path. From there the exception cache is searched for an
> entry or a dst_entry is created to return to the caller. The exception
> entry is not relevant for gateway validation, so what matters are the
> calls to fib6_table_lookup and then fib6_select_path.
>
> Similarly, rt6_lookup can be replaced with a call to fib6_lookup with
> RT6_LOOKUP_F_IFACE set in flags. Again, the exception cache search is
> not relevant, only the lookup with path selection. The primary difference
> in the lookup paths is the use of rt6_select with fib6_lookup versus
> rt6_device_match with rt6_lookup. When you remove complexities in the
> rt6_select path, e.g.,
> 1. saddr is not set for gateway validation, so RT6_LOOKUP_F_HAS_SADDR
> is not relevant
> 2. rt6_check_neigh is not called so that removes the RT6_NUD_FAIL_DO_RR
> return and round-robin logic.
>
> the code paths are believed to be equivalent for the given use case -
> validate the gateway and optionally given the device. Furthermore, it
> aligns the validation with onlink code path and the lookup path actually
> used for rx and tx.
>
> Adjust the users, ip6_route_check_nh_onlink and ip6_route_check_nh to
> handle a fib6_info vs a rt6_info when performing validation checks.
>
> Existing selftests fib-onlink-tests.sh and fib_tests.sh are used to
> verify the changes.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
> ---
> v2
> - use in6_dev_get versus __in6_dev_get + in6_dev_hold (comment from Wei)
> - updated commit message
Applied, thanks.
^ permalink raw reply
* RE: [PATCH 0/2] tls, add unhash callback
From: John Fastabend @ 2019-06-27 18:16 UTC (permalink / raw)
To: John Fastabend, daniel, jakub.kicinski, ast
Cc: netdev, edumazet, john.fastabend, bpf
In-Reply-To: <156165697019.32598.7171757081688035707.stgit@john-XPS-13-9370>
John Fastabend wrote:
> Resolve a series of splats discovered by syzbot and noted by
> Eric Dumazet. The primary problem here is we resolved an issue on
> the BPF sockmap side by adding an unhash callback. This is
> required to ensure sockmap sockets do not transition out of
> ESTABLISHED state into a LISTEN state. When we did this it
> created a case where the interaction between callbacks in TLS
> and sockmap when used together could break. This resulted in
> leaking TLS memory and potential to build loops of callbacks
> where sockmap called into TLS and TLS called back into BPF.
>
> Additionally, TLS was releasing the sock lock and then
> reaquiring it during the tear down process which could hang
> if another sock operation happened while the lock was not
> held.
>
> To fix this first refactor TLS code so lock is held for the
> entire teardown operation. Then add an unhash callback to ensure
> TLS can not transition from ESTABLISHED to LISTEN state. This
> transition is a similar bug to the one found and fixed previously
> in sockmap. And cleans up the callbacks to fix the syzbot
> errors.
>
> ---
>
Jakub,
If you could test this for the offload case that would
be helpful. I don't have any hardware here. We will still need
a few fixes in the unhash/hardware case but would be good to
know we don't cause any regressions here.
Thanks,
John
^ permalink raw reply
* Re: [PATCH net-next] net: link_watch: prevent starvation when processing linkwatch wq
From: David Miller @ 2019-06-27 18:17 UTC (permalink / raw)
To: linyunsheng
Cc: hkallweit1, f.fainelli, netdev, linux-kernel, linuxarm, pbonzini,
rkrcmar, kvm, xuwei5
In-Reply-To: <5c06e5dd-cfb1-870c-a0a3-42397b59c734@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
Date: Tue, 25 Jun 2019 10:28:04 +0800
> So It is ok for me to fall back to reschedule the link watch wq
> every 100 items, or is there a better way to fix it properly?
Yes, that is fine for now.
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: net: dsa: qca8k: document reset-gpios property
From: David Miller @ 2019-06-27 18:17 UTC (permalink / raw)
To: chunkeey
Cc: netdev, mark.rutland, robh+dt, f.fainelli, vivien.didelot, andrew
In-Reply-To: <08e0fd513620f03a2207b9f32637cdb434ed8def.1561452044.git.chunkeey@gmail.com>
From: Christian Lamparter <chunkeey@gmail.com>
Date: Tue, 25 Jun 2019 10:41:50 +0200
> This patch documents the qca8k's reset-gpios property that
> can be used if the QCA8337N ends up in a bad state during
> reset.
>
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v1 2/2] net: dsa: qca8k: introduce reset via gpio feature
From: David Miller @ 2019-06-27 18:17 UTC (permalink / raw)
To: chunkeey
Cc: netdev, mark.rutland, robh+dt, f.fainelli, vivien.didelot, andrew
In-Reply-To: <36b1e912b47bc079a78e06e05a33213833715314.1561452044.git.chunkeey@gmail.com>
From: Christian Lamparter <chunkeey@gmail.com>
Date: Tue, 25 Jun 2019 10:41:51 +0200
> The QCA8337(N) has a RESETn signal on Pin B42 that
> triggers a chip reset if the line is pulled low.
> The datasheet says that: "The active low duration
> must be greater than 10 ms".
>
> This can hopefully fix some of the issues related
> to pin strapping in OpenWrt for the EA8500 which
> suffers from detection issues after a SoC reset.
>
> Please note that the qca8k_probe() function does
> currently require to read the chip's revision
> register for identification purposes.
>
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Applied.
^ permalink raw reply
* [PATCH v2] net: dsa: mv88e6xxx: wait after reset deactivation
From: Baruch Siach @ 2019-06-27 18:17 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot; +Cc: netdev, Baruch Siach
Add a 1ms delay after reset deactivation. Otherwise the chip returns
bogus ID value. This is observed with 88E6390 (Peridot) chip.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
v2: Address Andrew Lunn's comments:
Use usleep_range.
Delay only when reset line is valid.
---
drivers/net/dsa/mv88e6xxx/chip.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index ae750ab9a4d7..5f81d9a3a2a6 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -4910,6 +4910,8 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
err = PTR_ERR(chip->reset);
goto out;
}
+ if (chip->reset)
+ usleep_range(1000, 2000);
err = mv88e6xxx_detect(chip);
if (err)
--
2.20.1
^ permalink raw reply related
* Re: [PATCH next 3/3] blackhole_dev: add a selftest
From: Mahesh Bandewar (महेश बंडेवार) @ 2019-06-27 18:19 UTC (permalink / raw)
To: David Miller; +Cc: linux-netdev, Eric Dumazet, michael.chan, dja, mahesh
In-Reply-To: <20190627.110852.372215308913618999.davem@davemloft.net>
On Thu, Jun 27, 2019 at 11:08 AM David Miller <davem@davemloft.net> wrote:
>
> From: Mahesh Bandewar <maheshb@google.com>
> Date: Fri, 21 Jun 2019 17:45:39 -0700
>
> > --- a/tools/testing/selftests/net/Makefile
> > +++ b/tools/testing/selftests/net/Makefile
> > @@ -4,8 +4,9 @@
> > CFLAGS = -Wall -Wl,--no-as-needed -O2 -g
> > CFLAGS += -I../../../../usr/include/
> >
> > +<<<<<<< HEAD
> > TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh \
>
> Ummm... yeah... might want to resolve this conflict...
>
oops, my bad! Let me send v2
> :-)
^ permalink raw reply
* RE: [net/tls] Re: KMSAN: uninit-value in aesti_encrypt
From: John Fastabend @ 2019-06-27 18:19 UTC (permalink / raw)
To: Eric Biggers, Boris Pismenny, Aviad Yehezkel, Dave Watson,
John Fastabend, Daniel Borkmann, netdev
Cc: davem, glider, herbert, linux-crypto, linux-kernel,
syzkaller-bugs, syzbot
In-Reply-To: <20190627164627.GF686@sol.localdomain>
Eric Biggers wrote:
> [+TLS maintainers]
>
> Very likely a net/tls bug, not a crypto bug.
>
> Possibly a duplicate of other reports such as "KMSAN: uninit-value in gf128mul_4k_lle (3)"
>
> See https://lore.kernel.org/netdev/20190625055019.GD17703@sol.localdomain/ for
> the list of 17 other open syzbot bugs I've assigned to the TLS subsystem. TLS
> maintainers, when are you planning to look into these?
>
> On Thu, Jun 27, 2019 at 09:37:05AM -0700, syzbot wrote:
I'm looking at this issue now. There is a series on bpf list now to address
many of those 17 open issues but this is a separate issue. I can reproduce
it locally so should have a fix soon.
Thanks,
John
^ 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