* [PATCH net v2 0/2] net: dsa: Fix tag_ksz.c
From: Florian Fainelli @ 2017-08-22 22:12 UTC (permalink / raw)
To: netdev; +Cc: davem, vivien.didelot, Woojung.Huh, UNGLinuxDriver,
Florian Fainelli
This implements David's suggestion of providing low-level functions
to control whether skb_pad() and skb_put_padto() should be freeing
the passed skb.
We make use of it to fix a double free in net/dsa/tag_ksz.c that would
occur if we kept using skb_put_padto() in both places.
Florian Fainelli (2):
net: core: Specify skb_pad()/skb_put_padto() SKB freeing
net: dsa: skb_put_padto() already frees nskb
include/linux/skbuff.h | 41 +++++++++++++++++++++++++++++++++++++----
net/core/skbuff.c | 13 ++++++++-----
net/dsa/tag_ksz.c | 10 ++++++----
3 files changed, 51 insertions(+), 13 deletions(-)
--
2.9.3
^ permalink raw reply
* Re: [PATCH v12 7/8] wireless: ipw2200: Replace PCI pool old API
From: Stanislav Yakovlev @ 2017-08-22 22:11 UTC (permalink / raw)
To: Romain Perier, Kalle Valo
Cc: Dan Williams, Doug Ledford, Sean Hefty, Hal Rosenstock,
jeffrey.t.kirsher, David S. Miller, linux-rdma, netdev,
linux-kernel, Greg Kroah-Hartman
On 22 August 2017 at 07:47, Romain Perier <romain.perier@collabora.com> wrote:
> The PCI pool API is deprecated. This commit replaces the PCI pool old
> API by the appropriate function with the DMA pool API.
>
> Signed-off-by: Romain Perier <romain.perier@collabora.com>
> Reviewed-by: Peter Senna Tschudin <peter.senna@collabora.com>
> ---
> drivers/net/wireless/intel/ipw2x00/ipw2200.c | 13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
Acked-by: Stanislav Yakovlev <stas.yakovlev@gmail.com>
Thanks, and sorry for the long review.
Kalle, could you please apply it to the wireless-drivers-next tree?
Thanks,
Stanislav.
^ permalink raw reply
* [PATCH net] bpf: fix map value attribute for hash of maps
From: Daniel Borkmann @ 2017-08-22 22:06 UTC (permalink / raw)
To: davem; +Cc: ast, kafai, netdev, Daniel Borkmann
Currently, iproute2's BPF ELF loader works fine with array of maps
when retrieving the fd from a pinned node and doing a selfcheck
against the provided map attributes from the object file, but we
fail to do the same for hash of maps and thus refuse to get the
map from pinned node.
Reason is that when allocating hash of maps, fd_htab_map_alloc() will
set the value size to sizeof(void *), and any user space map creation
requests are forced to set 4 bytes as value size. Thus, selfcheck
will complain about exposed 8 bytes on 64 bit archs vs. 4 bytes from
object file as value size. Contract is that fdinfo or BPF_MAP_GET_FD_BY_ID
returns the value size used to create the map.
Fix it by handling it the same way as we do for array of maps, which
means that we leave value size at 4 bytes and in the allocation phase
round up value size to 8 bytes. alloc_htab_elem() needs an adjustment
in order to copy rounded up 8 bytes due to bpf_fd_htab_map_update_elem()
calling into htab_map_update_elem() with the pointer of the map
pointer as value. Unlike array of maps where we just xchg(), we're
using the generic htab_map_update_elem() callback also used from helper
calls, which published the key/value already on return, so we need
to ensure to memcpy() the right size.
Fixes: bcc6b1b7ebf8 ("bpf: Add hash of maps support")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
kernel/bpf/hashtab.c | 30 +++++++++++++++++-------------
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
index 4fb4631..d11c818 100644
--- a/kernel/bpf/hashtab.c
+++ b/kernel/bpf/hashtab.c
@@ -652,12 +652,27 @@ static void pcpu_copy_value(struct bpf_htab *htab, void __percpu *pptr,
}
}
+static bool fd_htab_map_needs_adjust(const struct bpf_htab *htab)
+{
+ return htab->map.map_type == BPF_MAP_TYPE_HASH_OF_MAPS &&
+ BITS_PER_LONG == 64;
+}
+
+static u32 htab_size_value(const struct bpf_htab *htab, bool percpu)
+{
+ u32 size = htab->map.value_size;
+
+ if (percpu || fd_htab_map_needs_adjust(htab))
+ size = round_up(size, 8);
+ return size;
+}
+
static struct htab_elem *alloc_htab_elem(struct bpf_htab *htab, void *key,
void *value, u32 key_size, u32 hash,
bool percpu, bool onallcpus,
struct htab_elem *old_elem)
{
- u32 size = htab->map.value_size;
+ u32 size = htab_size_value(htab, percpu);
bool prealloc = htab_is_prealloc(htab);
struct htab_elem *l_new, **pl_new;
void __percpu *pptr;
@@ -696,9 +711,6 @@ static struct htab_elem *alloc_htab_elem(struct bpf_htab *htab, void *key,
memcpy(l_new->key, key, key_size);
if (percpu) {
- /* round up value_size to 8 bytes */
- size = round_up(size, 8);
-
if (prealloc) {
pptr = htab_elem_get_ptr(l_new, key_size);
} else {
@@ -1209,17 +1221,9 @@ int bpf_percpu_hash_update(struct bpf_map *map, void *key, void *value,
static struct bpf_map *fd_htab_map_alloc(union bpf_attr *attr)
{
- struct bpf_map *map;
-
if (attr->value_size != sizeof(u32))
return ERR_PTR(-EINVAL);
-
- /* pointer is stored internally */
- attr->value_size = sizeof(void *);
- map = htab_map_alloc(attr);
- attr->value_size = sizeof(u32);
-
- return map;
+ return htab_map_alloc(attr);
}
static void fd_htab_map_free(struct bpf_map *map)
--
1.9.3
^ permalink raw reply related
* Re: [PATCH net-next v7 05/10] landlock: Add LSM hooks related to filesystem
From: Mickaël Salaün @ 2017-08-22 21:59 UTC (permalink / raw)
To: linux-kernel
Cc: Alexei Starovoitov, Andy Lutomirski, Arnaldo Carvalho de Melo,
Casey Schaufler, Daniel Borkmann, David Drysdale,
David S . Miller, Eric W . Biederman, James Morris, Jann Horn,
Jonathan Corbet, Matthew Garrett, Michael Kerrisk, Kees Cook,
Paul Moore, Sargun Dhillon, Serge E . Hallyn, Shuah Khan,
Tejun Heo, Thomas Graf, Will Drewry
In-Reply-To: <20170821000933.13024-6-mic@digikod.net>
[-- Attachment #1.1: Type: text/plain, Size: 3970 bytes --]
On 21/08/2017 02:09, Mickaël Salaün wrote:
> Handle 33 filesystem-related LSM hooks for the Landlock filesystem
> event: LANDLOCK_SUBTYPE_EVENT_FS.
>
> A Landlock event wrap LSM hooks for similar kernel object types (e.g.
> struct file, struct path...). Multiple LSM hooks can trigger the same
> Landlock event.
>
> Landlock handle nine coarse-grained actions: read, write, execute, new,
> get, remove, ioctl, lock and fcntl. Each of them abstract LSM hook
> access control in a way that can be extended in the future.
>
> The Landlock LSM hook registration is done after other LSM to only run
> actions from user-space, via eBPF programs, if the access was granted by
> major (privileged) LSMs.
>
> Signed-off-by: Mickaël Salaün <mic@digikod.net>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: James Morris <james.l.morris@oracle.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Serge E. Hallyn <serge@hallyn.com>
> ---
>
> Changes since v6:
> * add 3 more sub-events: IOCTL, LOCK, FCNTL
> https://lkml.kernel.org/r/2fbc99a6-f190-f335-bd14-04bdeed35571@digikod.net
> * use the new security_add_hooks()
> * explain the -Werror=unused-function
> * constify pointers
> * cleanup headers
>
> Changes since v5:
> * split hooks.[ch] into hooks.[ch] and hooks_fs.[ch]
> * add more documentation
> * cosmetic fixes
> * rebase (SCALAR_VALUE)
>
> Changes since v4:
> * add LSM hook abstraction called Landlock event
> * use the compiler type checking to verify hooks use by an event
> * handle all filesystem related LSM hooks (e.g. file_permission,
> mmap_file, sb_mount...)
> * register BPF programs for Landlock just after LSM hooks registration
> * move hooks registration after other LSMs
> * add failsafes to check if a hook is not used by the kernel
> * allow partial raw value access form the context (needed for programs
> generated by LLVM)
>
> Changes since v3:
> * split commit
> * add hooks dealing with struct inode and struct path pointers:
> inode_permission and inode_getattr
> * add abstraction over eBPF helper arguments thanks to wrapping structs
> ---
> include/linux/lsm_hooks.h | 5 +
> security/landlock/Makefile | 7 +-
> security/landlock/common.h | 2 +
> security/landlock/hooks.c | 83 ++++++
> security/landlock/hooks.h | 177 +++++++++++++
> security/landlock/hooks_fs.c | 586 +++++++++++++++++++++++++++++++++++++++++++
> security/landlock/hooks_fs.h | 19 ++
> security/landlock/init.c | 10 +
> security/security.c | 12 +-
> 9 files changed, 899 insertions(+), 2 deletions(-)
> create mode 100644 security/landlock/hooks.c
> create mode 100644 security/landlock/hooks.h
> create mode 100644 security/landlock/hooks_fs.c
> create mode 100644 security/landlock/hooks_fs.h
> diff --git a/security/landlock/init.c b/security/landlock/init.c
> index 09acbc74abd6..1e6660fed697 100644
> --- a/security/landlock/init.c
> +++ b/security/landlock/init.c
> @@ -10,8 +10,10 @@
>
> #include <linux/bpf.h> /* enum bpf_access_type */
> #include <linux/capability.h> /* capable */
> +#include <linux/lsm_hooks.h>
>
> #include "common.h" /* LANDLOCK_* */
> +#include "hooks_fs.h"
>
>
> static inline bool bpf_landlock_is_valid_access(int off, int size,
> @@ -23,6 +25,8 @@ static inline bool bpf_landlock_is_valid_access(int off, int size,
>
> switch (prog_subtype->landlock_rule.event) {
> case LANDLOCK_SUBTYPE_EVENT_FS:
> + return landlock_is_valid_access_event_FS(off, size, type,
> + &info->reg_type, prog_subtype);
I forgot to handle LANDLOCK_SUBTYPE_EVENT_FS_{IOCTL,LOCK_FCNTL} here and
I included some hunks in the wrong patches. I will fix this in the next
series and add tests for those anyway. :)
Regards,
Mickaël
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] net: phy: Deal with unbound PHY driver in phy_attached_print()
From: David Miller @ 2017-08-22 21:49 UTC (permalink / raw)
To: f.fainelli
Cc: netdev, romain.perier, alexandre.torgue, peppe.cavallaro, plaes,
andrew, linux-kernel
In-Reply-To: <24d4774e-1b1b-fe8b-5d25-dcd7f7aae757@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 22 Aug 2017 14:45:44 -0700
> On 08/22/2017 02:44 PM, David Miller wrote:
>> From: Florian Fainelli <f.fainelli@gmail.com>
>> Date: Tue, 22 Aug 2017 14:26:47 -0700
>>
>>> Priit reported that stmmac was crashing with the trace below. This is because
>>> phy_attached_print() is called too early right after the PHY device has been
>>> found, but before it has a driver attached, since that is only done in
>>> phy_probe() which occurs later.
>>>
>>> Fix this by dealing with a possibly NULL phydev->drv point since that can
>>> happen here, but could also happen if we voluntarily did an unbind of the
>>> PHY device with the PHY driver.
>> ...
>>> Tested-By: Priit Laes <plaes@plaes.org>
>>> Fixes: fbca164776e4 ("net: stmmac: Use the right logging function in stmmac_mdio_register")
>>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>>
>> "net-next"? The commit which introduced this problem is in 'net', don't we want
>> to fix it there?
>
> Oh yes we do, somehow I thought the commit was just in "net-next" hence
> the subject, the patch applies cleanly to "net" as well.
I thought so, thanks for clarifying.
Applied.
^ permalink raw reply
* RE: [PATCH v2] i40e/i40evf: fix out-of-bounds read of cpumask
From: Keller, Jacob E @ 2017-08-22 21:48 UTC (permalink / raw)
To: Stefano Brivio
Cc: Intel Wired LAN, netdev@vger.kernel.org, stable@vger.kernel.org,
Juergen Gross
In-Reply-To: <20170822232349.52b9ad06@elisabeth>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
> Behalf Of Stefano Brivio
> Sent: Tuesday, August 22, 2017 2:24 PM
> To: Keller, Jacob E <jacob.e.keller@intel.com>
> Cc: Intel Wired LAN <intel-wired-lan@lists.osuosl.org>; netdev@vger.kernel.org;
> stable@vger.kernel.org; Juergen Gross <jgross@suse.com>
> Subject: Re: [PATCH v2] i40e/i40evf: fix out-of-bounds read of cpumask
>
> [Fixed Cc: address for stable, Cc'ed Juergen]
>
> On Tue, 22 Aug 2017 14:04:42 -0700
> Jacob Keller <jacob.e.keller@intel.com> wrote:
>
> > When responding to an affinity hint we directly copied a cpumask value,
> > intsead of using cpumask_copy. According to cpumask.h this is not
> > correct because cpumask_t is only guaranteed to have enough space for
> > the number of CPUs in the system, and may not be as big as we expect.
> > Thus a direct copy results in an out-of-bound read and potentially
> > a crash if the pages are aligned just right. This will be easily
> > detected on a kernel with KASAN enabled:
>
> I still think commit message of my patch
> (ae9c9586f61e914dc1c6fe2e6ac1fb2bf07283bc.1502792828.git.sbrivio@redhat.co
> m)
> was perhaps a bit clearer, but okay, this is also clear, fair enough.
>
> > KASAN reports:
> > [ 25.242312] BUG: KASAN: slab-out-of-bounds in
> i40e_irq_affinity_notify+0x30/0x50 [i40e] at addr ffff880462eea960
> [...]
> > [ 25.242597]
> ==================================================================
>
> This is also taken from my message, not terribly happy about it
> (and still happier with it than without). Fair enough, whatever it
> takes to get this applied as soon as possible...
>
> > Fixes: 96db776a3682 ("i40e/i40evf: fix interrupt affinity bug", 2016-09-14)
> > Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> > Cc: stable@vger.kernel.org # 4.10+
>
> FWIW,
>
> Acked-by: Stefano Brivio <sbrivio@redhat.com>
>
I don't really care which message gets applied either, as long as we get it fixed. Either patch is fine with me.
Thanks,
Jake
>
> --
> Stefano
^ permalink raw reply
* Re: [PATCH net-next] net: phy: Deal with unbound PHY driver in phy_attached_print()
From: Florian Fainelli @ 2017-08-22 21:45 UTC (permalink / raw)
To: David Miller
Cc: netdev, romain.perier, alexandre.torgue, peppe.cavallaro, plaes,
andrew, linux-kernel
In-Reply-To: <20170822.144414.545771080170074088.davem@davemloft.net>
On 08/22/2017 02:44 PM, David Miller wrote:
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Tue, 22 Aug 2017 14:26:47 -0700
>
>> Priit reported that stmmac was crashing with the trace below. This is because
>> phy_attached_print() is called too early right after the PHY device has been
>> found, but before it has a driver attached, since that is only done in
>> phy_probe() which occurs later.
>>
>> Fix this by dealing with a possibly NULL phydev->drv point since that can
>> happen here, but could also happen if we voluntarily did an unbind of the
>> PHY device with the PHY driver.
> ...
>> Tested-By: Priit Laes <plaes@plaes.org>
>> Fixes: fbca164776e4 ("net: stmmac: Use the right logging function in stmmac_mdio_register")
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>
> "net-next"? The commit which introduced this problem is in 'net', don't we want
> to fix it there?
Oh yes we do, somehow I thought the commit was just in "net-next" hence
the subject, the patch applies cleanly to "net" as well.
Thanks!
--
Florian
^ permalink raw reply
* Re: [PATCH net-next] net: phy: Deal with unbound PHY driver in phy_attached_print()
From: David Miller @ 2017-08-22 21:44 UTC (permalink / raw)
To: f.fainelli
Cc: netdev, romain.perier, alexandre.torgue, peppe.cavallaro, plaes,
andrew, linux-kernel
In-Reply-To: <20170822212647.11520-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 22 Aug 2017 14:26:47 -0700
> Priit reported that stmmac was crashing with the trace below. This is because
> phy_attached_print() is called too early right after the PHY device has been
> found, but before it has a driver attached, since that is only done in
> phy_probe() which occurs later.
>
> Fix this by dealing with a possibly NULL phydev->drv point since that can
> happen here, but could also happen if we voluntarily did an unbind of the
> PHY device with the PHY driver.
...
> Tested-By: Priit Laes <plaes@plaes.org>
> Fixes: fbca164776e4 ("net: stmmac: Use the right logging function in stmmac_mdio_register")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
"net-next"? The commit which introduced this problem is in 'net', don't we want
to fix it there?
^ permalink raw reply
* Re: [patch net 0/2] net: sched: couple of chain fixes
From: David Miller @ 2017-08-22 21:40 UTC (permalink / raw)
To: jiri; +Cc: netdev, jhs, xiyou.wangcong, mlxsw
In-Reply-To: <20170822204650.7016-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 22 Aug 2017 22:46:48 +0200
> From: Jiri Pirko <jiri@mellanox.com>
>
> Jiri Pirko (2):
> net: sched: fix use after free when tcf_chain_destroy is called
> multiple times
> net: sched: don't do tcf_chain_flush from tcf_chain_destroy
Series applied, thanks Jiri.
^ permalink raw reply
* RE: [PATCH net-next 3/3] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)
From: Dexuan Cui @ 2017-08-22 21:40 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: davem@davemloft.net, netdev@vger.kernel.org,
devel@linuxdriverproject.org, KY Srinivasan, Haiyang Zhang,
Stephen Hemminger, George Zhang, Jorgen Hansen, Michal Kubecek,
Vitaly Kuznetsov, Cathy Avery, jasowang@redhat.com,
Rolf Neugebauer, Dave Scott, Marcelo Cerri, apw@canonical.com,
olaf@aepfle.de, joe@perches.com, "lin
In-Reply-To: <20170822101433.GC16799@stefanha-x1.localdomain>
> From: Stefan Hajnoczi [mailto:stefanha@redhat.com]
> On Fri, Aug 18, 2017 at 10:23:54PM +0000, Dexuan Cui wrote:
> > > > +static bool hvs_stream_allow(u32 cid, u32 port)
> > > > +{
> > > > + static const u32 valid_cids[] = {
> > > > + VMADDR_CID_ANY,
> > >
> > > Is this for loopback?
> >
> > No, we don't support lookback in Linux VM, at least for now.
> > In our Linux implementation, Linux VM can only connect to the host, and
> > here when Linux VM calls connect(), I treat VMADDR_CID_ANY
> > the same as VMADDR_CID_HOST.
>
> VMCI and virtio-vsock do not treat connect(VMADDR_CID_ANY) the same as
> connect(VMADDR_CID_HOST). It is an error to connect to VMADDR_CID_ANY.
Ok. Then I'll only allow VMADDR_CID_HOST as the destination CID, since
we don't support loopback mode.
> > > > + /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0xFFFFFFFF)
> > > is
> > > > + * reserved as ephemeral ports, which are used as the host's ports
> > > > + * when the host initiates connections.
> > > > + */
> > > > + if (port > MAX_HOST_LISTEN_PORT)
> > > > + return false;
> > >
> > > Without this if statement the guest will attempt to connect. I guess
> > > there will be no listen sockets above MAX_HOST_LISTEN_PORT, so the
> > > connection attempt will fail.
> >
> > You're correct.
> > To use the vsock common infrastructure, we have to map Hyper-V's
> > GUID <VM_ID, Service_ID> to int <cid, port>, and hence we must limit
> > the port range we can listen() on to [0, MAX_LISTEN_PORT], i.e.
> > we can only use half of the whole 32-bit port space for listen().
> > This is detailed in the long comments starting at about Line 100.
> >
> > > ...but hardcode this knowledge into the guest driver?
> > I'd like the guest's connect() to fail immediately here.
> > IMO this is better than a connect timeout. :-)
>
> Thanks for explaining. Perhaps the comment could be updated:
>
> /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0xFFFFFFFF) is
> * reserved as ephemeral ports, which are used as the host's ports when
> * the host initiates connections.
> *
> * Perform this check in the guest so an immediate error is produced
> * instead of a timeout.
> */
>
> Stefan
Thank you, Stefan!
Please see the below for the updated version of the function:
static bool hvs_stream_allow(u32 cid, u32 port)
{
/* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0xFFFFFFFF) is
* reserved as ephemeral ports, which are used as the host's ports
* when the host initiates connections.
*
* Perform this check in the guest so an immediate error is produced
* instead of a timeout.
*/
if (port > MAX_HOST_LISTEN_PORT)
return false;
if (cid == VMADDR_CID_HOST)
return true;
return false;
}
I'll send a v2 of the patch later today.
-- Dexuan
^ permalink raw reply
* Re: [PATCH v2 net-next 2/2] selftests/net: Add a test to validate behavior of rx timestamps
From: Willem de Bruijn @ 2017-08-22 21:39 UTC (permalink / raw)
To: Mike Maloney
Cc: Network Development, David Miller, Soheil Hassas Yeganeh,
Mike Maloney
In-Reply-To: <20170822210849.23162-3-maloneykernel@gmail.com>
On Tue, Aug 22, 2017 at 5:08 PM, Mike Maloney <maloneykernel@gmail.com> wrote:
> From: Mike Maloney <maloney@google.com>
>
> Validate the behavior of the combination of various timestamp socket
> options, and ensure consistency across ip, udp, and tcp.
>
> Signed-off-by: Mike Maloney <maloney@google.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Thanks for adding these tests.
For tcp, it may be useful to eventually also add packetdrill tests
to validate the more subtle semantics, such as that the timestamp is
returned only when reading the last byte of the skb.
> + do_send(src);
> +
> + if (s.type == SOCK_RAW)
> + read_size += 20; /* for IP header */
No need to revise just for this, but if submitting a v3:
please use sizeof(struct iphdr). And maybe test PF_INET6, too.
^ permalink raw reply
* Re: [PATCH net-next] net: sched: use kvmalloc() for class hash tables
From: David Miller @ 2017-08-22 21:38 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, jhs, xiyou.wangcong, jiri
In-Reply-To: <1503430006.2499.55.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 22 Aug 2017 12:26:46 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> High order GFP_KERNEL allocations can stress the host badly.
>
> Use modern kvmalloc_array()/kvfree() instead of custom
> allocations.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] net: amd: constify zorro_device_id
From: David Miller @ 2017-08-22 21:35 UTC (permalink / raw)
To: arvind.yadav.cs; +Cc: jarod, linux-kernel, netdev
In-Reply-To: <1503425472-24469-1-git-send-email-arvind.yadav.cs@gmail.com>
From: Arvind Yadav <arvind.yadav.cs@gmail.com>
Date: Tue, 22 Aug 2017 23:41:12 +0530
> zorro_device_id are not supposed to change at runtime. All functions
> working with zorro_device_id provided by <linux/zorro.h> work with
> const zorro_device_id. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 1/6] fsl/fman: enable FMan Keygen
From: David Miller @ 2017-08-22 21:35 UTC (permalink / raw)
To: madalin.bucur; +Cc: netdev, linuxppc-dev, linux-kernel
In-Reply-To: <1503423066-15420-2-git-send-email-madalin.bucur@nxp.com>
From: Madalin Bucur <madalin.bucur@nxp.com>
Date: Tue, 22 Aug 2017 20:31:01 +0300
> /**
> + * fman_get_keygen
> + *
> + * @fman: A Pointer to FMan device
> + *
> + * Get the handle to KeyGen module part of FM driver
> + *
> + * Return: Handle to KeyGen
> + */
> +struct fman_keygen *fman_get_keygen(struct fman *fman)
> +{
> + return fman->keygen;
> +}
> +EXPORT_SYMBOL(fman_get_keygen);
Please don't do this.
Just directly derefence the pointer in the source code to
get the keygen.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next v2 00/10] net: mvpp2: MAC/GoP configuration
From: David Miller @ 2017-08-22 21:32 UTC (permalink / raw)
To: antoine.tenart
Cc: jason, andrew, gregory.clement, sebastian.hesselbarth,
thomas.petazzoni, nadavh, linux, mw, stefanc, netdev,
linux-arm-kernel
In-Reply-To: <20170822170830.32413-1-antoine.tenart@free-electrons.com>
From: Antoine Tenart <antoine.tenart@free-electrons.com>
Date: Tue, 22 Aug 2017 19:08:20 +0200
> This is based on net-next (e2a7c34fb285).
>
> I removed the GoP interrupt and PHY optional parts in this v2 to ease
> the review process as the MAC/GoP initialization seemed to start less
> discussions :)
>
> This series now only aims at making the PPv2 driver less depending on
> the firmware/bootloader initialization. Some patches cleanup some parts
> as well, and add new interface descriptions in the dt.
...
> @Dave: patches 9 and 10 should go through the mvebu tree. Thanks!
Patches 1-8 applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH v2 net-next 1/2] tcp: Extend SOF_TIMESTAMPING_RX_SOFTWARE to TCP recvmsg
From: Willem de Bruijn @ 2017-08-22 21:32 UTC (permalink / raw)
To: Mike Maloney
Cc: Network Development, David Miller, Soheil Hassas Yeganeh,
Mike Maloney
In-Reply-To: <20170822210849.23162-2-maloneykernel@gmail.com>
On Tue, Aug 22, 2017 at 5:08 PM, Mike Maloney <maloneykernel@gmail.com> wrote:
> From: Mike Maloney <maloney@google.com>
>
> When SOF_TIMESTAMPING_RX_SOFTWARE is enabled for tcp sockets, return the
> timestamp corresponding to the highest sequence number data returned.
>
> Previously the skb->tstamp is overwritten when a TCP packet is placed
> in the out of order queue. While the packet is in the ooo queue, save the
> timestamp in the TCB_SKB_CB. This space is shared with the gso_*
> options which are only used on the tx path, and a previously unused 4
> byte hole.
>
> When skbs are coalesced either in the sk_receive_queue or the
> out_of_order_queue always choose the timestamp of the appended skb to
> maintain the invariant of returning the timestamp of the last byte in
> the recvmsg buffer.
>
> Signed-off-by: Mike Maloney <maloney@google.com>
Acked-by: Willem de Bruijn <willemb@google.com>
^ permalink raw reply
* Re: [PATCH net-next 5/5] xdp: get tracepoints xdp_exception and xdp_redirect in sync
From: Daniel Borkmann @ 2017-08-22 21:30 UTC (permalink / raw)
To: Jesper Dangaard Brouer, netdev; +Cc: John Fastabend
In-Reply-To: <150343485998.31091.4036615069956176401.stgit@firesoul>
On 08/22/2017 10:47 PM, Jesper Dangaard Brouer wrote:
> Remove the net_device string name from the xdp_exception tracepoint,
> like the xdp_redirect tracepoint.
>
> Align the TP_STRUCT to have common entries between these two
> tracepoint.
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> ---
> include/trace/events/xdp.h | 24 ++++++++++++------------
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/include/trace/events/xdp.h b/include/trace/events/xdp.h
> index 7511bed80558..6495b0d9d5c7 100644
> --- a/include/trace/events/xdp.h
> +++ b/include/trace/events/xdp.h
> @@ -31,22 +31,22 @@ TRACE_EVENT(xdp_exception,
> TP_ARGS(dev, xdp, act),
>
> TP_STRUCT__entry(
> - __string(name, dev->name)
> __array(u8, prog_tag, 8)
> __field(u32, act)
> + __field(int, ifindex)
> ),
>
> TP_fast_assign(
> BUILD_BUG_ON(sizeof(__entry->prog_tag) != sizeof(xdp->tag));
> memcpy(__entry->prog_tag, xdp->tag, sizeof(xdp->tag));
> - __assign_str(name, dev->name);
> - __entry->act = act;
> + __entry->act = act;
> + __entry->ifindex = dev->ifindex;
> ),
>
[...]
> TRACE_EVENT(xdp_redirect,
> @@ -57,26 +57,26 @@ TRACE_EVENT(xdp_redirect,
> TP_ARGS(from_index, to_index, xdp, act, err),
>
> TP_STRUCT__entry(
> - __field(int, from_index)
> - __field(int, to_index)
> __array(u8, prog_tag, 8)
> __field(u32, act)
> + __field(int, from_index)
> + __field(int, to_index)
> __field(int, err)
> ),
>
> TP_fast_assign(
> BUILD_BUG_ON(sizeof(__entry->prog_tag) != sizeof(xdp->tag));
> memcpy(__entry->prog_tag, xdp->tag, sizeof(xdp->tag));
> + __entry->act = act;
> __entry->from_index = from_index;
> __entry->to_index = to_index;
> - __entry->act = act;
If you already get them in sync, could you also make it consistent
that for both tracepoints in TP_ARGS() we use either ifindex
directly or device pointer and extract it from TP_fast_assign().
Right now, it's mixed.
^ permalink raw reply
* Re: [PATCHv4 net-next] gre: introduce native tunnel support for ERSPAN
From: David Miller @ 2017-08-22 21:29 UTC (permalink / raw)
To: u9012063; +Cc: netdev, mvohra, kuznet, yoshfuji
In-Reply-To: <1503420028-10791-1-git-send-email-u9012063@gmail.com>
From: William Tu <u9012063@gmail.com>
Date: Tue, 22 Aug 2017 09:40:28 -0700
> The patch adds ERSPAN type II tunnel support. The implementation
> is based on the draft at [1]. One of the purposes is for Linux
> box to be able to receive ERSPAN monitoring traffic sent from
> the Cisco switch, by creating a ERSPAN tunnel device.
> In addition, the patch also adds ERSPAN TX, so Linux virtual
> switch can redirect monitored traffic to the ERSPAN tunnel device.
> The traffic will be encapsulated into ERSPAN and sent out.
>
> The implementation reuses tunnel key as ERSPAN session ID, and
> field 'erspan' as ERSPAN Index fields:
> ./ip link add dev ers11 type erspan seq key 100 erspan 123 \
> local 172.16.1.200 remote 172.16.1.100
>
> To use the above device as ERSPAN receiver, configure
> Nexus 5000 switch as below:
>
> monitor session 100 type erspan-source
> erspan-id 123
> vrf default
> destination ip 172.16.1.200
> source interface Ethernet1/11 both
> source interface Ethernet1/12 both
> no shut
> monitor erspan origin ip-address 172.16.1.100 global
>
> [1] https://tools.ietf.org/html/draft-foschiano-erspan-01
> [2] iproute2 patch: http://marc.info/?l=linux-netdev&m=150306086924951&w=2
> [3] test script: http://marc.info/?l=linux-netdev&m=150231021807304&w=2
>
> Signed-off-by: William Tu <u9012063@gmail.com>
> Signed-off-by: Meenakshi Vohra <mvohra@vmware.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH v2 net] udp: on peeking bad csum, drop packets even if not at head
From: David Miller @ 2017-08-22 21:28 UTC (permalink / raw)
To: eric.dumazet; +Cc: pabeni, willemb, netdev
In-Reply-To: <1503419968.2499.33.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 22 Aug 2017 09:39:28 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> When peeking, if a bad csum is discovered, the skb is unlinked from
> the queue with __sk_queue_drop_skb and the peek operation restarted.
>
> __sk_queue_drop_skb only drops packets that match the queue head.
>
> This fails if the skb was found after the head, using SO_PEEK_OFF
> socket option. This causes an infinite loop.
>
> We MUST drop this problematic skb, and we can simply check if skb was
> already removed by another thread, by looking at skb->next :
>
> This pointer is set to NULL by the __skb_unlink() operation, that might
> have happened only under the spinlock protection.
>
> Many thanks to syzkaller team (and particularly Dmitry Vyukov who
> provided us nice C reproducers exhibiting the lockup) and Willem de
> Bruijn who provided first version for this patch and a test program.
>
> Fixes: 627d2d6b5500 ("udp: enable MSG_PEEK at non-zero offset")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next] udp: remove unreachable ufo branches
From: David Miller @ 2017-08-22 21:27 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: netdev, willemb
In-Reply-To: <20170822153957.99341-1-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Tue, 22 Aug 2017 11:39:57 -0400
> From: Willem de Bruijn <willemb@google.com>
>
> Remove two references to ufo in the udp send path that are no longer
> reachable now that ufo has been removed.
>
> Commit 85f1bd9a7b5a ("udp: consistently apply ufo or fragmentation")
> is a fix to ufo. It is safe to revert what remains of it.
>
> Also, no skb can enter ip_append_page with skb_is_gso true now that
> skb_shinfo(skb)->gso_type is no longer set in ip_append_page/_data.
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Applied, thanks for sorting this out.
^ permalink raw reply
* [PATCH net-next] net: phy: Deal with unbound PHY driver in phy_attached_print()
From: Florian Fainelli @ 2017-08-22 21:26 UTC (permalink / raw)
To: netdev
Cc: romain.perier, alexandre.torgue, peppe.cavallaro, plaes,
Florian Fainelli, Andrew Lunn, open list
Priit reported that stmmac was crashing with the trace below. This is because
phy_attached_print() is called too early right after the PHY device has been
found, but before it has a driver attached, since that is only done in
phy_probe() which occurs later.
Fix this by dealing with a possibly NULL phydev->drv point since that can
happen here, but could also happen if we voluntarily did an unbind of the
PHY device with the PHY driver.
sun7i-dwmac 1c50000.ethernet: PTP uses main clock
sun7i-dwmac 1c50000.ethernet: no reset control found
sun7i-dwmac 1c50000.ethernet: no regulator found
sun7i-dwmac 1c50000.ethernet: Ring mode enabled
sun7i-dwmac 1c50000.ethernet: DMA HW capability register supported
sun7i-dwmac 1c50000.ethernet: Normal descriptors
libphy: stmmac: probed
Unable to handle kernel NULL pointer dereference at virtual address 00000048
pgd = c0004000
[00000048] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.13.0-rc6-00318-g0065bd7fa384 #1
Hardware name: Allwinner sun7i (A20) Family
task: ee868000 task.stack: ee85c000
PC is at phy_attached_print+0x1c/0x8c
LR is at stmmac_mdio_register+0x12c/0x200
pc : [<c04510ac>] lr : [<c045e6b4>] psr: 60000013
sp : ee85ddc8 ip : 00000000 fp : c07dfb5c
r10: ee981210 r9 : 00000001 r8 : eea73000
r7 : eeaa6dd0 r6 : eeb49800 r5 : 00000000 r4 : 00000000
r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : eeb49800
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 4000406a DAC: 00000051
Process swapper/0 (pid: 1, stack limit = 0xee85c210)
Stack: (0xee85ddc8 to 0xee85e000)
ddc0: 00000000 00000002 eeb49400 eea72000 00000000 eeb49400
dde0: c045e6b4 00000000 ffffffff eeab0810 00000000 c08051f8 ee9292c0 c016d480
de00: eea725c0 eea73000 eea72000 00000001 eea726c0 c0457d0c 00000040 00000020
de20: 00000000 c045b850 00000001 00000000 ee981200 eeab0810 eeaa6ed0 ee981210
de40: 00000000 c094a4a0 00000000 c0465180 eeaa7550 f08d0000 c9ffb90c 00000032
de60: fffffffa 00000032 ee981210 ffffffed c0a46620 fffffdfb c0a46620 c03f7be8
de80: ee981210 c0a9a388 00000000 00000000 c0a46620 c03f63e0 ee981210 c0a46620
dea0: ee981244 00000000 00000007 000000c6 c094a4a0 c03f6534 00000000 c0a46620
dec0: c03f6490 c03f49ec ee828a58 ee9217b4 c0a46620 eeaa4b00 c0a43230 c03f59fc
dee0: c08051f8 c094a49c c0a46620 c0a46620 00000000 c091c668 c093783c c03f6dfc
df00: ffffe000 00000000 c091c668 c010177c eefe0938 eefe0935 c085e200 000000c6
df20: 00000005 c0136bc8 60000013 c080b3a4 00000006 00000006 c07ce7b4 00000000
df40: c07d7ddc c07cef28 eefe0938 eefe093e c0a0b2f0 c0a641c0 c0a641c0 c0a641c0
df60: c0937834 00000007 000000c6 c094a4a0 00000000 c0900d88 00000006 00000006
df80: 00000000 c09005a8 00000000 c060ecf4 00000000 00000000 00000000 00000000
dfa0: 00000000 c060ecfc 00000000 c0107738 00000000 00000000 00000000 00000000
dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffdeffff ffffffff
[<c04510ac>] (phy_attached_print) from [<c045e6b4>] (stmmac_mdio_register+0x12c/0x200)
[<c045e6b4>] (stmmac_mdio_register) from [<c045b850>] (stmmac_dvr_probe+0x850/0x96c)
[<c045b850>] (stmmac_dvr_probe) from [<c0465180>] (sun7i_gmac_probe+0x120/0x180)
[<c0465180>] (sun7i_gmac_probe) from [<c03f7be8>] (platform_drv_probe+0x50/0xac)
[<c03f7be8>] (platform_drv_probe) from [<c03f63e0>] (driver_probe_device+0x234/0x2e4)
[<c03f63e0>] (driver_probe_device) from [<c03f6534>] (__driver_attach+0xa4/0xa8)
[<c03f6534>] (__driver_attach) from [<c03f49ec>] (bus_for_each_dev+0x4c/0x9c)
[<c03f49ec>] (bus_for_each_dev) from [<c03f59fc>] (bus_add_driver+0x190/0x214)
[<c03f59fc>] (bus_add_driver) from [<c03f6dfc>] (driver_register+0x78/0xf4)
[<c03f6dfc>] (driver_register) from [<c010177c>] (do_one_initcall+0x44/0x168)
[<c010177c>] (do_one_initcall) from [<c0900d88>] (kernel_init_freeable+0x144/0x1d0)
[<c0900d88>] (kernel_init_freeable) from [<c060ecfc>] (kernel_init+0x8/0x110)
[<c060ecfc>] (kernel_init) from [<c0107738>] (ret_from_fork+0x14/0x3c)
Code: e59021c8 e59d401c e590302c e3540000 (e5922048)
---[ end trace 39ae87c7923562d0 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Tested-By: Priit Laes <plaes@plaes.org>
Fixes: fbca164776e4 ("net: stmmac: Use the right logging function in stmmac_mdio_register")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/phy/phy_device.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 9493fb369682..810f6fd2f639 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -877,15 +877,17 @@ EXPORT_SYMBOL(phy_attached_info);
#define ATTACHED_FMT "attached PHY driver [%s] (mii_bus:phy_addr=%s, irq=%d)"
void phy_attached_print(struct phy_device *phydev, const char *fmt, ...)
{
+ const char *drv_name = phydev->drv ? phydev->drv->name : "unbound";
+
if (!fmt) {
dev_info(&phydev->mdio.dev, ATTACHED_FMT "\n",
- phydev->drv->name, phydev_name(phydev),
+ drv_name, phydev_name(phydev),
phydev->irq);
} else {
va_list ap;
dev_info(&phydev->mdio.dev, ATTACHED_FMT,
- phydev->drv->name, phydev_name(phydev),
+ drv_name, phydev_name(phydev),
phydev->irq);
va_start(ap, fmt);
--
2.9.3
^ permalink raw reply related
* Re: [PATCH net] macsec: add genl family module alias
From: David Miller @ 2017-08-22 21:26 UTC (permalink / raw)
To: sd; +Cc: netdev
In-Reply-To: <dde846e6ac5c2bc4189c240be6ccaa54d3b60d5e.1503406499.git.sd@queasysnail.net>
From: Sabrina Dubroca <sd@queasysnail.net>
Date: Tue, 22 Aug 2017 15:36:08 +0200
> This helps tools such as wpa_supplicant can start even if the macsec
> module isn't loaded yet.
>
> Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver")
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net v1 0/2] tipc: topology server fixes
From: David Miller @ 2017-08-22 21:25 UTC (permalink / raw)
To: parthasarathy.bhuvaragan
Cc: netdev, tipc-discussion, jon.maloy, maloy, ying.xue
In-Reply-To: <1503397721-19682-1-git-send-email-parthasarathy.bhuvaragan@ericsson.com>
From: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
Date: Tue, 22 Aug 2017 12:28:39 +0200
> The following commits fixes two race conditions causing general
> protection faults.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH v2] i40e/i40evf: fix out-of-bounds read of cpumask
From: Stefano Brivio @ 2017-08-22 21:23 UTC (permalink / raw)
To: Jacob Keller; +Cc: Intel Wired LAN, netdev, stable, Juergen Gross
In-Reply-To: <20170822210442.18006-1-jacob.e.keller@intel.com>
[Fixed Cc: address for stable, Cc'ed Juergen]
On Tue, 22 Aug 2017 14:04:42 -0700
Jacob Keller <jacob.e.keller@intel.com> wrote:
> When responding to an affinity hint we directly copied a cpumask value,
> intsead of using cpumask_copy. According to cpumask.h this is not
> correct because cpumask_t is only guaranteed to have enough space for
> the number of CPUs in the system, and may not be as big as we expect.
> Thus a direct copy results in an out-of-bound read and potentially
> a crash if the pages are aligned just right. This will be easily
> detected on a kernel with KASAN enabled:
I still think commit message of my patch
(ae9c9586f61e914dc1c6fe2e6ac1fb2bf07283bc.1502792828.git.sbrivio@redhat.com)
was perhaps a bit clearer, but okay, this is also clear, fair enough.
> KASAN reports:
> [ 25.242312] BUG: KASAN: slab-out-of-bounds in i40e_irq_affinity_notify+0x30/0x50 [i40e] at addr ffff880462eea960
[...]
> [ 25.242597] ==================================================================
This is also taken from my message, not terribly happy about it
(and still happier with it than without). Fair enough, whatever it
takes to get this applied as soon as possible...
> Fixes: 96db776a3682 ("i40e/i40evf: fix interrupt affinity bug", 2016-09-14)
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Cc: stable@vger.kernel.org # 4.10+
FWIW,
Acked-by: Stefano Brivio <sbrivio@redhat.com>
^ permalink raw reply
* Re: [patch net] mlxsw: spectrum_switchdev: Fix mrouter flag update
From: David Miller @ 2017-08-22 21:23 UTC (permalink / raw)
To: jiri; +Cc: netdev, nogahf, idosch, mlxsw
In-Reply-To: <20170822082811.1356-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 22 Aug 2017 10:28:11 +0200
> From: Nogah Frankel <nogahf@mellanox.com>
>
> Update the value of the mrouter flag in struct mlxsw_sp_bridge_port when
> it is being changed.
>
> Fixes: c57529e1d5d8 ("mlxsw: spectrum: Replace vPorts with Port-VLAN")
> Signed-off-by: Nogah Frankel <nogahf@mellanox.com>
> Reviewed-by: Ido Schimmel <idosch@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied.
^ 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