* Re: [PATCH iproute2-next] ip: Add support for nexthop objects
From: Stephen Hemminger @ 2018-09-01 20:37 UTC (permalink / raw)
To: dsahern; +Cc: netdev, roopa, sharpd, idosch, davem, David Ahern
In-Reply-To: <20180901004954.7145-20-dsahern@kernel.org>
On Fri, 31 Aug 2018 17:49:54 -0700
dsahern@kernel.org wrote:
> From: David Ahern <dsahern@gmail.com>
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
> ---
> include/uapi/linux/nexthop.h | 56 ++++
> include/uapi/linux/rtnetlink.h | 8 +
> ip/Makefile | 3 +-
> ip/ip.c | 3 +-
> ip/ip_common.h | 7 +-
> ip/ipmonitor.c | 6 +
> ip/ipnexthop.c | 652 +++++++++++++++++++++++++++++++++++++++++
> ip/iproute.c | 19 +-
> 8 files changed, 747 insertions(+), 7 deletions(-)
> create mode 100644 include/uapi/linux/nexthop.h
> create mode 100644 ip/ipnexthop.c
>
> diff --git a/include/uapi/linux/nexthop.h b/include/uapi/linux/nexthop.h
> new file mode 100644
> index 000000000000..335182e8229a
> --- /dev/null
> +++ b/include/uapi/linux/nexthop.h
> @@ -0,0 +1,56 @@
> +#ifndef __LINUX_NEXTHOP_H
> +#define __LINUX_NEXTHOP_H
> +
> +#include <linux/types.h>
> +
> +struct nhmsg {
> + unsigned char nh_family;
> + unsigned char nh_scope; /* one of RT_SCOPE */
> + unsigned char nh_protocol; /* Routing protocol that installed nh */
> + unsigned char resvd;
> + unsigned int nh_flags; /* RTNH_F flags */
> +};
Why not use __u8 and __u32 for these?
> +struct nexthop_grp {
> + __u32 id;
> + __u32 weight;
> +};
> +
> +enum {
> + NEXTHOP_GRP_TYPE_MPATH, /* default type if not specified */
> + __NEXTHOP_GRP_TYPE_MAX,
> +};
> +
> +#define NEXTHOP_GRP_TYPE_MAX (__NEXTHOP_GRP_TYPE_MAX - 1)
> +
> +
> +/* NHA_ID 32-bit id for nexthop. id must be greater than 0.
> + * id == 0 means assign an unused id.
> + */
Don't use dave's preferred comment style in this file.
The reset of the file uses standard comments.
...
> diff --git a/ip/ip_common.h b/ip/ip_common.h
> index 200be5e23dd1..2971c1586c4e 100644
> --- a/ip/ip_common.h
> +++ b/ip/ip_common.h
> @@ -56,6 +56,8 @@ int print_rule(const struct sockaddr_nl *who,
> int print_netconf(const struct sockaddr_nl *who,
> struct rtnl_ctrl_data *ctrl,
> struct nlmsghdr *n, void *arg);
> +int print_nexthop(const struct sockaddr_nl *who,
> + struct nlmsghdr *n, void *arg);
> void netns_map_init(void);
> void netns_nsid_socket_init(void);
> int print_nsid(const struct sockaddr_nl *who,
> @@ -90,6 +92,7 @@ int do_ipvrf(int argc, char **argv);
> void vrf_reset(void);
> int netns_identify_pid(const char *pidstr, char *name, int len);
> int do_seg6(int argc, char **argv);
> +int do_ipnh(int argc, char **argv);
>
> int iplink_get(unsigned int flags, char *name, __u32 filt_mask);
> int iplink_ifla_xstats(int argc, char **argv);
> @@ -165,5 +168,7 @@ int name_is_vrf(const char *name);
> #endif
>
> void print_num(FILE *fp, unsigned int width, uint64_t count);
> -
> +void print_rta_flow(FILE *fp, const struct rtattr *rta);
> +void print_rt_flags(FILE *fp, unsigned int flags);
> +void print_rta_if(FILE *fp, const struct rtattr *rta, const char *prefix);
> #endif /* _IP_COMMON_H_ */
> diff --git a/ip/ipmonitor.c b/ip/ipmonitor.c
> index a93b62cd6624..de129626683b 100644
> --- a/ip/ipmonitor.c
> +++ b/ip/ipmonitor.c
> @@ -84,6 +84,12 @@ static int accept_msg(const struct sockaddr_nl *who,
> }
> }
>
> + case RTM_NEWNEXTHOP:
> + case RTM_DELNEXTHOP:
> + print_headers(fp, "[NEXTHOP]", ctrl);
> + print_nexthop(who, n, arg);
> + return 0;
> +
> case RTM_NEWLINK:
> case RTM_DELLINK:
> ll_remember_index(who, n, NULL);
> diff --git a/ip/ipnexthop.c b/ip/ipnexthop.c
> new file mode 100644
> index 000000000000..9fa4b7292426
> --- /dev/null
> +++ b/ip/ipnexthop.c
> @@ -0,0 +1,652 @@
> +/*
> + * ip nexthop
> + *
> + * Copyright (C) 2017 Cumulus Networks
> + * Copyright (c) 2017 David Ahern <dsa@cumulusnetworks.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
>
Please use SPDX and not GPL boilerplate in new files.
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <unistd.h>
> +#include <string.h>
> +#include <sys/socket.h>
> +#include <netinet/in.h>
> +#include <netinet/ip.h>
> +#include <errno.h>
> +#include <linux/nexthop.h>
> +#include <libmnl/libmnl.h>
Is this code really using libmnl?
> +#include <rt_names.h>
> +
> +#include "utils.h"
> +#include "ip_common.h"
> +
> +static struct
> +{
> + unsigned int flushed;
> + unsigned int groups;
> + char *flushb;
> + int flushp;
> + int flushe;
> +} filter;
> +
> +enum {
> + IPNH_LIST,
> + IPNH_FLUSH,
> +};
> +
> +#define RTM_NHA(h) ((struct rtattr *)(((char *)(h)) + \
> + NLMSG_ALIGN(sizeof(struct nhmsg))))
> +
> +static void usage(void) __attribute__((noreturn));
> +
> +static void usage(void)
> +{
> + fprintf(stderr, "Usage: ip nexthop { list | flush } SELECTOR\n");
> + fprintf(stderr, " ip nexthop get [ id ID ]\n");
> + fprintf(stderr, " ip nexthop { add | del | change | replace } NH\n");
> + fprintf(stderr, "SELECTOR := [ id ID ] [ dev DEV ] [ table TABLE ] [ vrf NAME ]\n");
> + fprintf(stderr, "NH := [ encap ENCAPTYPE ENCAPHDR ] [ via [ FAMILY ] ADDRESS ]\n");
> + fprintf(stderr, " [ id ID ] [ dev STRING ] [ weight NUMBER ]\n");
> + fprintf(stderr, " [ table TABLE ] [ vrf VRF ] NHFLAGS\n");
> + fprintf(stderr, "NHFLAGS := [ onlink | pervasive ]\n");
> + fprintf(stderr, "ENCAPTYPE := [ mpls | ip | ip6 ]\n");
> + fprintf(stderr, "ENCAPHDR := [ MPLSLABEL ]\n");
> + exit(-1);
> +}
> +
> +static int delete_nexthop(__u32 id)
> +{
> + struct {
> + struct nlmsghdr n;
> + struct nhmsg nhm;
> + char buf[64];
> + } req = {
> + .n.nlmsg_len = NLMSG_LENGTH(sizeof(struct nhmsg)),
> + .n.nlmsg_flags = NLM_F_REQUEST,
> + .n.nlmsg_type = RTM_DELNEXTHOP,
> + .nhm.nh_family = AF_UNSPEC,
> + };
> +
> + req.n.nlmsg_seq = ++rth.seq;
> +
> + addattr32(&req.n, sizeof(req), NHA_ID, id);
> +
> + if (rtnl_talk(&rth, &req.n, NULL) < 0)
> + return -1;
> +
> + filter.flushed++;
> + return 0;
> +}
> +
> +struct nh_entry {
> + __u32 id;
> + unsigned int group;
> + struct nh_entry *next;
> +};
> +
> +struct nh_entry *first, *last;
> +
> +static int flush_nexthop(const struct sockaddr_nl *who,
> + struct nlmsghdr *nlh, void *arg)
> +{
> + struct nhmsg *nhm = NLMSG_DATA(nlh);
> + struct rtattr *tb[NHA_MAX+1];
> + struct nh_entry *nh;
> + __u32 id = 0;
> + int len;
> +
> + len = nlh->nlmsg_len - NLMSG_SPACE(sizeof(*nhm));
> + if (len < 0) {
> + fprintf(stderr, "BUG: wrong nlmsg len %d\n", len);
> + return -1;
> + }
> +
> + parse_rtattr(tb, NHA_MAX, RTM_NHA(nhm), len);
> + if (tb[NHA_ID])
> + id = rta_getattr_u32(tb[NHA_ID]);
> +
> + if (!id)
> + return 0;
> +
> + nh = malloc(sizeof(*nh));
> + if (!nh)
> + return -1;
> +
> + nh->id = id;
> + nh->group = tb[NHA_GROUP] != NULL;
> + nh->next = NULL;
> + if (!first)
> + first = nh;
> + else
> + last->next = nh;
> +
> + last = nh;
> + return 0;
> +}
> +
> +static int ipnh_flush(void *req, __u32 len, unsigned int all)
> +{
> + struct nh_entry *nh;
> +
> + if (send(rth.fd, req, len, 0) < 0) {
> + perror("Cannot send dump request");
> + return -2;
> + }
> +
> + if (rtnl_dump_filter(&rth, flush_nexthop, stdout) < 0) {
> + fprintf(stderr, "Dump terminated\n");
> + return -2;
> + }
> +
> + /* if deleting all, then remove groups first */
> + if (all) {
> + nh = first;
> + while (nh) {
> + if (nh->group)
> + delete_nexthop(nh->id);
> + nh = nh->next;
> + }
> + }
> +
> + nh = first;
> + while (nh) {
> + if (!all || !nh->group)
> + delete_nexthop(nh->id);
> + nh = nh->next;
> + }
> +
> + if (!filter.flushed)
> + printf("Nothing to flush\n");
> + else
> + printf("Flushed %d nexthops\n", filter.flushed);
> +
> + return 0;
> +}
> +
> +static char *nh_group_type_to_str(__u16 group_type, char *buf, size_t len)
> +{
> + static const char *typestr[NEXTHOP_GRP_TYPE_MAX + 1] = {
> + "multipath", /* NEXTHOP_GRP_TYPE_MPATH */
> + };
> +
> + if (group_type < ARRAY_SIZE(typestr))
> + snprintf(buf, len-1, "%s", typestr[group_type]);
> + else
> + snprintf(buf, len-1, "<%u>", group_type);
> +
> + buf[len-1] = '\0';
> +
> + return buf;
> +}
> +
> +static void print_nh_group(FILE *fp, const struct rtattr *grps_attr,
> + const struct rtattr *gtype)
> +{
> + struct nexthop_grp *nhg = RTA_DATA(grps_attr);
> + int num = RTA_PAYLOAD(grps_attr) / sizeof(*nhg);
> + __u16 group_type = NEXTHOP_GRP_TYPE_MPATH;
> + int i;
> +
> + SPRINT_BUF(b1);
> +
> + if (!num || num * sizeof(*nhg) != RTA_PAYLOAD(grps_attr)) {
> + fprintf(fp, "<invalid nexthop group>");
> + return;
> + }
> +
> + if (gtype)
> + group_type = rta_getattr_u16(gtype);
> +
> + if (is_json_context()) {
> + open_json_array(PRINT_JSON, "group");
> + for (i = 0; i < num; ++i) {
> + open_json_object(NULL);
> + print_uint(PRINT_ANY, "id", "id %u ", nhg[i].id);
> + print_uint(PRINT_ANY, "weight", "weight %u ", nhg[i].weight);
> + close_json_object();
> + }
> + close_json_array(PRINT_JSON, NULL);
> + print_string(PRINT_ANY, "type", "type %s ",
> + nh_group_type_to_str(group_type, b1, sizeof(b1)));
> + } else {
> + fprintf(fp, "group ");
> + for (i = 0; i < num; ++i) {
> + if (i)
> + fprintf(fp, "/");
> + fprintf(fp, "%u", nhg[i].id);
> + if (num > 1 && nhg[i].weight > 1)
> + fprintf(fp, ",%u", nhg[i].weight);
> + }
> + }
> +}
I think this could be done by using json_print cleverly rather than having
to use is_json_contex(). That would avoid repeating code.
You are only decoding group type in the json version, why not both?
^ permalink raw reply
* Re: [PATCH RFC net-next 18/18] net/ipv4: Optimization for fib_info lookup
From: Stephen Hemminger @ 2018-09-01 20:43 UTC (permalink / raw)
To: dsahern; +Cc: netdev, roopa, sharpd, idosch, davem, David Ahern
In-Reply-To: <20180901004954.7145-19-dsahern@kernel.org>
On Fri, 31 Aug 2018 17:49:53 -0700
dsahern@kernel.org wrote:
> +static inline unsigned int fib_info_hashfn_cfg(const struct fib_config *cfg)
> +{
> + unsigned int mask = (fib_info_hash_size - 1);
> + unsigned int val = 0;
> +
> + val ^= (cfg->fc_protocol << 8) | cfg->fc_scope;
Why do assignment to 0 than do initial xor?
Why not instead just do assignment in the first statement which would be clearer.
^ permalink raw reply
* [PATCH] uapi: Fix linux/rds.h userspace compilation errors.
From: Vinson Lee @ 2018-09-01 21:20 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <65dc4fe6-5363-3456-994e-166cb77a90cd@oracle.com>
Include linux/in6.h for struct in6_addr.
/usr/include/linux/rds.h:156:18: error: field ‘laddr’ has incomplete type
struct in6_addr laddr;
^~~~~
/usr/include/linux/rds.h:157:18: error: field ‘faddr’ has incomplete type
struct in6_addr faddr;
^~~~~
/usr/include/linux/rds.h:178:18: error: field ‘laddr’ has incomplete type
struct in6_addr laddr;
^~~~~
/usr/include/linux/rds.h:179:18: error: field ‘faddr’ has incomplete type
struct in6_addr faddr;
^~~~~
/usr/include/linux/rds.h:198:18: error: field ‘bound_addr’ has incomplete type
struct in6_addr bound_addr;
^~~~~~~~~~
/usr/include/linux/rds.h:199:18: error: field ‘connected_addr’ has incomplete type
struct in6_addr connected_addr;
^~~~~~~~~~~~~~
/usr/include/linux/rds.h:219:18: error: field ‘local_addr’ has incomplete type
struct in6_addr local_addr;
^~~~~~~~~~
/usr/include/linux/rds.h:221:18: error: field ‘peer_addr’ has incomplete type
struct in6_addr peer_addr;
^~~~~~~~~
/usr/include/linux/rds.h:245:18: error: field ‘src_addr’ has incomplete type
struct in6_addr src_addr;
^~~~~~~~
/usr/include/linux/rds.h:246:18: error: field ‘dst_addr’ has incomplete type
struct in6_addr dst_addr;
^~~~~~~~
Fixes: b7ff8b1036f0 ("rds: Extend RDS API for IPv6 support")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
---
include/uapi/linux/rds.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/rds.h b/include/uapi/linux/rds.h
index dc520e1a4123..8b73cb603c5f 100644
--- a/include/uapi/linux/rds.h
+++ b/include/uapi/linux/rds.h
@@ -37,6 +37,7 @@
#include <linux/types.h>
#include <linux/socket.h> /* For __kernel_sockaddr_storage. */
+#include <linux/in6.h> /* For struct in6_addr. */
#define RDS_IB_ABI_VERSION 0x301
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2 net-next 1/7] MIPS: lantiq: dma: add dev pointer
From: Hauke Mehrtens @ 2018-09-01 21:39 UTC (permalink / raw)
To: Andrew Lunn
Cc: davem, netdev, vivien.didelot, f.fainelli, john, linux-mips, dev,
hauke.mehrtens, devicetree
In-Reply-To: <20180901145700.GB6305@lunn.ch>
[-- Attachment #1.1: Type: text/plain, Size: 757 bytes --]
On 09/01/2018 04:57 PM, Andrew Lunn wrote:
> On Sat, Sep 01, 2018 at 01:45:29PM +0200, Hauke Mehrtens wrote:
>> dma_zalloc_coherent() now crashes if no dev pointer is given.
>> Add a dev pointer to the ltq_dma_channel structure and fill it in the
>> driver using it.
>>
>> This fixes a bug introduced in kernel 4.19.
>
> Hi Hauke
>
> Should this be added to stable so that it appears in 4.19-rcX? If so,
> please send it to net, not net-next.
Hi Andrew,
Thanks for the review.
Yes this should go into 4.19-rcX.
The "lantiq: Add Lantiq / Intel VRX200 Ethernet driver" patch has a
compile dependency on this patch. Should I send "MIPS: lantiq: dma: add
dev pointer" separately or just mark it as 4.19-rcX in this series?
Hauke
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 net-next 7/7] net: dsa: Add Lantiq / Intel DSA driver for vrx200
From: Hauke Mehrtens @ 2018-09-01 21:44 UTC (permalink / raw)
To: davem
Cc: netdev, andrew, vivien.didelot, f.fainelli, john, linux-mips, dev,
hauke.mehrtens, devicetree
In-Reply-To: <20180901120511.10112-1-hauke@hauke-m.de>
[-- Attachment #1.1: Type: text/plain, Size: 3337 bytes --]
On 09/01/2018 02:05 PM, Hauke Mehrtens wrote:
> This adds the DSA driver for the GSWIP Switch found in the VRX200 SoC.
> This switch is integrated in the DSL SoC, this SoC uses a GSWIP version
> 2.1, there are other SoCs using different versions of this IP block, but
> this driver was only tested with the version found in the VRX200.
> Currently only the basic features are implemented which will forward all
> packages to the CPU and let the CPU do the forwarding. The hardware also
> support Layer 2 offloading which is not yet implemented in this driver.
>
> The GPHY FW loaded is now done by this driver and not any more by the
> separate driver in drivers/soc/lantiq/gphy.c, I will remove this driver
> is a separate patch. to make use of the GPHY this switch driver is
> needed anyway. Other SoCs have more embedded GPHYs so this driver should
> support a variable number of GPHYs. After the firmware was loaded the
> GPHY can be probed on the MDIO bus and it behaves like an external GPHY,
> without the firmware it can not be probed on the MDIO bus.
>
> Currently this depends on SOC_TYPE_XWAY because the SoC revision
> detection function ltq_soc_type() is used to load the correct GPHY
> firmware on the VRX200 SoCs.
>
> The clock names in the sysctrl.c file have to be changed because the
> clocks are now used by a different driver. This should be cleaned up and
> a real common clock driver should provide the clocks instead.
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
> ---
> MAINTAINERS | 2 +
> arch/mips/lantiq/xway/sysctrl.c | 8 +-
> drivers/net/dsa/Kconfig | 8 +
> drivers/net/dsa/Makefile | 1 +
> drivers/net/dsa/lantiq_gswip.c | 1018 +++++++++++++++++++++++++++++++++++++++
> drivers/net/dsa/lantiq_pce.h | 153 ++++++
> 6 files changed, 1186 insertions(+), 4 deletions(-)
> create mode 100644 drivers/net/dsa/lantiq_gswip.c
> create mode 100644 drivers/net/dsa/lantiq_pce.h
>
.....
> +
> +static int gswip_gphy_fw_list(struct gswip_priv *priv,
> + struct device_node *gphy_fw_list_np)
> +{
> + struct device *dev = priv->dev;
> + struct device_node *gphy_fw_np;
> + const struct of_device_id *match;
> + int err;
> + int i = 0;
> +
> + if (of_device_is_compatible(dev->of_node, "lantiq,xrx200-gphy-fw")) {
> + switch (ltq_soc_type()) {
I just found out that the older revision of the xrx200 SoC uses also an
older GSWIP version, so we do not have to call ltq_soc_type() here, but
can use the GSWIP version register.
xRX200 rev 1.1 uses GSWIP 2.0, xrx200 rev 1.2 uses GSWIP 2.1.
1e10804c: 00000100 on xRX200 rev 1.1
1e10804c: 00000021 on xRX200 rev 1.2
Then I can also remove the compile dependency on the Lantiq arch code.
> + case SOC_TYPE_VR9:
> + priv->gphy_fw_name_cfg = &xrx200a1x_gphy_data;
> + break;
> + case SOC_TYPE_VR9_2:
> + priv->gphy_fw_name_cfg = &xrx200a2x_gphy_data;
> + break;
> + }
> + }
> +
.....
> +
> + platform_set_drvdata(pdev, priv);
> +
> + version = gswip_switch_r(priv, GSWIP_VERSION);
> + dev_info(dev, "probed GSWIP version %lx mod %lx\n",
> + (version & GSWIP_VERSION_REV_MASK) >> GSWIP_VERSION_REV_SHIFT,
> + (version & GSWIP_VERSION_MOD_MASK) >> GSWIP_VERSION_MOD_SHIFT);
> + return 0;
> +
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] net: mvpp2: avoid bouncing buffers
From: Brian Brooks @ 2018-09-02 2:10 UTC (permalink / raw)
To: Christoph Hellwig
Cc: David Miller, antoine.tenart, maxime.chevallier, ymarkman,
stefanc, netdev, linux-kernel, bjorn.topel, brian.brooks
In-Reply-To: <20180827154843.GA25821@infradead.org>
On 08/27 08:48:43, Christoph Hellwig wrote:
> WE should basically never have dev->dma_mask = &dev->coherent_dma_mask,
> so until that is the case you are doctoring around the symptoms and
> not the problem.
>
> Does the patch below help your case?
Yes. Just tested it. Works great.
I see how this patch addresses the issue in the platform code instead of
the driver code. Thanks.
> ----
> From 6294e0e330851ee06e66ab85b348f1d92d375d7a Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig <hch@lst.de>
> Date: Mon, 27 Aug 2018 17:23:24 +0200
> Subject: driver core: initialize a default DMA mask for platform device
>
> We still treat devices without a DMA mask as defaulting to 32-bits for
> both mask, but a few releases ago we've started warning about such
> cases, as they require special cases to work around this sloppyness.
> Add a dma_mask field to struct platform_object so that we can initialize
> the dma_mask pointer in struct device and initialize both masks to
> 32-bits by default. Architectures can still override this in
> arch_setup_pdev_archdata if needed.
>
> Note that the code looks a little odd with the various conditionals
> because we have to support platform_device structures that are
> statically allocated.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/base/platform.c | 15 +++++++++++++--
> include/linux/platform_device.h | 1 +
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index dff82a3c2caa..baf4b06cf2d9 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -225,6 +225,17 @@ struct platform_object {
> char name[];
> };
>
> +static void setup_pdev_archdata(struct platform_device *pdev)
> +{
> + if (!pdev->dev.coherent_dma_mask)
> + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + if (!pdev->dma_mask)
> + pdev->dma_mask = DMA_BIT_MASK(32);
> + if (!pdev->dev.dma_mask)
> + pdev->dev.dma_mask = &pdev->dma_mask;
> + arch_setup_pdev_archdata(pdev);
> +};
> +
> /**
> * platform_device_put - destroy a platform device
> * @pdev: platform device to free
> @@ -271,7 +282,7 @@ struct platform_device *platform_device_alloc(const char *name, int id)
> pa->pdev.id = id;
> device_initialize(&pa->pdev.dev);
> pa->pdev.dev.release = platform_device_release;
> - arch_setup_pdev_archdata(&pa->pdev);
> + setup_pdev_archdata(&pa->pdev);
> }
>
> return pa ? &pa->pdev : NULL;
> @@ -472,7 +483,7 @@ EXPORT_SYMBOL_GPL(platform_device_del);
> int platform_device_register(struct platform_device *pdev)
> {
> device_initialize(&pdev->dev);
> - arch_setup_pdev_archdata(pdev);
> + setup_pdev_archdata(pdev);
> return platform_device_add(pdev);
> }
> EXPORT_SYMBOL_GPL(platform_device_register);
> diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
> index 1a9f38f27f65..d84ec1de6022 100644
> --- a/include/linux/platform_device.h
> +++ b/include/linux/platform_device.h
> @@ -25,6 +25,7 @@ struct platform_device {
> int id;
> bool id_auto;
> struct device dev;
> + dma_addr_t dma_mask;
Hmm.. should struct device use dma_addr_t instead of u64 for masks too?
> u32 num_resources;
> struct resource *resource;
>
> --
> 2.18.0
>
^ permalink raw reply
* Re: [PATCH net-next] veth: report NEWLINK event when moving the peer device in a new namespace
From: David Ahern @ 2018-09-01 23:45 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: David S. Miller, Network Development, Thomas Haller
In-Reply-To: <CAJ0CqmV5+qG_L57UC47cUfAuvrnDesk0uhYbsEYy8F7zJ0869A@mail.gmail.com>
On 9/1/18 3:05 AM, Lorenzo Bianconi wrote:
>
> I was thinking about the commit 38e01b30563a and then I realized I
> misread the code
> yesterday. The commit 38e01b30563a provides all relevant info but it
> emits the event
> for veth1 (the device moved in the new namespace).
> An userspace application will not receive that message if it filters
> events for just
> a specific device (veth0 in this case) despite that some device
> properties have changed
> (since veth0 and veth1 are paired devices). To fix that behavior in
> veth_notify routine
> I emits a RTM_NEWLINK event for veth0.
Userspace is managing a veth a pair. It moves one of them to a new
namespace and decides to filter messages related to that device before
the move. If it did not filter the DELLINK message it would get the
information you want. That to me is a userspace problem. What am I missing?
Fundamentally, your proposal means 3 messages when moving a device to a
new namespace which is what I think is unnecessary.
^ permalink raw reply
* Re: [PATCH] neighbour: confirm neigh entries when ARP packet is received
From: David Miller @ 2018-09-01 23:51 UTC (permalink / raw)
To: vasilykh
Cc: ihrachys, roopa, adobriyan, jwestfall, stephen, anarsoul,
keescook, w.bumiller, edumazet, netdev
In-Reply-To: <20180829024825.3808-1-vasilykh@arista.com>
From: Vasily Khoruzhick <vasilykh@arista.com>
Date: Tue, 28 Aug 2018 19:48:25 -0700
> Update 'confirmed' timestamp when ARP packet is received. It shouldn't
> affect locktime logic and anyway entry can be confirmed by any higher-layer
> protocol. Thus it makes no sense not to confirm it when ARP packet is
> received.
>
> Fixes: 77d7123342 ("neighbour: update neigh timestamps iff update is
> effective")
>
> Signed-off-by: Vasily Khoruzhick <vasilykh@arista.com>
I'm not so sure.
The comment above the code you are moving explains that the current
behavior is intention, and it explains why too.
Even if your change is correct, you're now making that comment
inaccuratte, so you'd have to update it to match the new code.
But I still think the current code is intentionally behaving that
way, and for good reason.
^ permalink raw reply
* Re: [PATCH] net: ipv6: route: Fix a sleep-in-atomic-context bug in ip6_convert_metrics()
From: David Ahern @ 2018-09-02 4:25 UTC (permalink / raw)
To: Jia-Ju Bai, davem, kuznet, yoshfuji; +Cc: netdev, linux-kernel
In-Reply-To: <20180901111958.26529-1-baijiaju1990@gmail.com>
On 9/1/18 5:19 AM, Jia-Ju Bai wrote:
> The kernel module may sleep with holding a spinlock.
...
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index ec18b3ce8b6d..d15e72def7c1 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -2742,7 +2742,7 @@ static int ip6_convert_metrics(struct net *net, struct fib6_info *rt,
> if (!cfg->fc_mx)
> return 0;
>
> - p = kzalloc(sizeof(*rt->fib6_metrics), GFP_KERNEL);
> + p = kzalloc(sizeof(*rt->fib6_metrics), GFP_ATOMIC);
> if (unlikely(!p))
> return -ENOMEM;
>
>
This is the wrong solution. I'll take care of it next week after the
holiday weekend.
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in _decode_session6
From: Dmitry Vyukov @ 2018-09-02 4:45 UTC (permalink / raw)
To: syzbot, Alexei Starovoitov, Daniel Borkmann
Cc: David Miller, Herbert Xu, Alexey Kuznetsov, LKML, netdev,
Steffen Klassert, syzkaller-bugs, Hideaki YOSHIFUJI
In-Reply-To: <0000000000003658b00574dc08cc@google.com>
On Sun, Sep 2, 2018 at 6:41 AM, syzbot
<syzbot+acffccec848dc13fe459@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 93ee30f3e8b4 xsk: i40e: get rid of useless struct xdp_umem..
> git tree: bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=11f2115a400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=531a917630d2a492
> dashboard link: https://syzkaller.appspot.com/bug?extid=acffccec848dc13fe459
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=116b3492400000
Potentially this is bpf-related because the repro just runs a bpf
program. +bpf maintainers.
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+acffccec848dc13fe459@syzkaller.appspotmail.com
>
> 8021q: adding VLAN 0 to HW filter on device team0
> 8021q: adding VLAN 0 to HW filter on device team0
> 8021q: adding VLAN 0 to HW filter on device team0
> 8021q: adding VLAN 0 to HW filter on device team0
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in _decode_session6+0x1331/0x14e0
> net/ipv6/xfrm6_policy.c:161
> Read of size 1 at addr ffff8801d882eec7 by task syz-executor1/6667
>
> CPU: 0 PID: 6667 Comm: syz-executor1 Not tainted 4.19.0-rc1+ #86
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
> print_address_description+0x6c/0x20b mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.7+0x242/0x30d mm/kasan/report.c:412
> __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430
> _decode_session6+0x1331/0x14e0 net/ipv6/xfrm6_policy.c:161
> __xfrm_decode_session+0x71/0x140 net/xfrm/xfrm_policy.c:2299
> xfrm_decode_session include/net/xfrm.h:1232 [inline]
> vti6_tnl_xmit+0x3c3/0x1bc1 net/ipv6/ip6_vti.c:542
> __netdev_start_xmit include/linux/netdevice.h:4313 [inline]
> netdev_start_xmit include/linux/netdevice.h:4322 [inline]
> xmit_one net/core/dev.c:3217 [inline]
> dev_hard_start_xmit+0x272/0xc10 net/core/dev.c:3233
> __dev_queue_xmit+0x2ab2/0x3870 net/core/dev.c:3803
> dev_queue_xmit+0x17/0x20 net/core/dev.c:3836
> __bpf_tx_skb net/core/filter.c:2012 [inline]
> __bpf_redirect_common net/core/filter.c:2050 [inline]
> __bpf_redirect+0x5b7/0xae0 net/core/filter.c:2057
> ____bpf_clone_redirect net/core/filter.c:2090 [inline]
> bpf_clone_redirect+0x2f6/0x490 net/core/filter.c:2062
> bpf_prog_c39d1ba309a769f7+0x749/0x1000
>
> Allocated by task 6667:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
> __do_kmalloc_node mm/slab.c:3682 [inline]
> __kmalloc_node_track_caller+0x47/0x70 mm/slab.c:3696
> __kmalloc_reserve.isra.41+0x3a/0xe0 net/core/skbuff.c:137
> pskb_expand_head+0x230/0x10e0 net/core/skbuff.c:1463
> skb_ensure_writable+0x3dd/0x640 net/core/skbuff.c:5129
> __bpf_try_make_writable net/core/filter.c:1633 [inline]
> bpf_try_make_writable net/core/filter.c:1639 [inline]
> bpf_try_make_head_writable net/core/filter.c:1647 [inline]
> ____bpf_clone_redirect net/core/filter.c:2084 [inline]
> bpf_clone_redirect+0x14a/0x490 net/core/filter.c:2062
> bpf_prog_c39d1ba309a769f7+0x749/0x1000
>
> Freed by task 5493:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
> kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
> __cache_free mm/slab.c:3498 [inline]
> kfree+0xd9/0x210 mm/slab.c:3813
> skb_free_head+0x99/0xc0 net/core/skbuff.c:550
> skb_release_data+0x6a4/0x880 net/core/skbuff.c:570
> skb_release_all+0x4a/0x60 net/core/skbuff.c:627
> __kfree_skb net/core/skbuff.c:641 [inline]
> consume_skb+0x190/0x4e0 net/core/skbuff.c:701
> netlink_dump+0xb14/0xd50 net/netlink/af_netlink.c:2269
> netlink_recvmsg+0xf84/0x1490 net/netlink/af_netlink.c:1991
> sock_recvmsg_nosec net/socket.c:794 [inline]
> sock_recvmsg+0xd0/0x110 net/socket.c:801
> ___sys_recvmsg+0x2b6/0x680 net/socket.c:2276
> __sys_recvmsg+0x11a/0x290 net/socket.c:2325
> __do_sys_recvmsg net/socket.c:2335 [inline]
> __se_sys_recvmsg net/socket.c:2332 [inline]
> __x64_sys_recvmsg+0x78/0xb0 net/socket.c:2332
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The buggy address belongs to the object at ffff8801d882ecc0
> which belongs to the cache kmalloc-512 of size 512
> The buggy address is located 7 bytes to the right of
> 512-byte region [ffff8801d882ecc0, ffff8801d882eec0)
> The buggy address belongs to the page:
> page:ffffea0007620b80 count:1 mapcount:0 mapping:ffff8801dac00940 index:0x0
> flags: 0x2fffc0000000100(slab)
> raw: 02fffc0000000100 ffffea00070fc048 ffffea00075f9c08 ffff8801dac00940
> raw: 0000000000000000 ffff8801d882e040 0000000100000006 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801d882ed80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff8801d882ee00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>
>> ffff8801d882ee80: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
>
> ^
> ffff8801d882ef00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801d882ef80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ==================================================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/0000000000003658b00574dc08cc%40google.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: Add CBS support in XGMAC2
From: David Miller @ 2018-09-02 0:40 UTC (permalink / raw)
To: Jose.Abreu; +Cc: netdev, Joao.Pinto, peppe.cavallaro, alexandre.torgue
In-Reply-To: <e3dfc2d9404ad517b09956cb68a7ab0664a8eec1.1535638116.git.joabreu@synopsys.com>
From: Jose Abreu <Jose.Abreu@synopsys.com>
Date: Thu, 30 Aug 2018 15:09:48 +0100
> XGMAC2 uses the same CBS mechanism as GMAC5, only registers offset
> changes. Lets use the same TC callbacks and implement the .config_cbs
> callback in XGMAC2 core.
>
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] ipv6: don't get lwtstate twice in ip6_rt_copy_init()
From: David Miller @ 2018-09-02 0:43 UTC (permalink / raw)
To: alexey.kodanev; +Cc: netdev, dsahern
In-Reply-To: <1535645484-30629-1-git-send-email-alexey.kodanev@oracle.com>
From: Alexey Kodanev <alexey.kodanev@oracle.com>
Date: Thu, 30 Aug 2018 19:11:24 +0300
> Commit 80f1a0f4e0cd ("net/ipv6: Put lwtstate when destroying fib6_info")
> partially fixed the kmemleak [1], lwtstate can be copied from fib6_info,
> with ip6_rt_copy_init(), and it should be done only once there.
>
> rt->dst.lwtstate is set by ip6_rt_init_dst(), at the start of the function
> ip6_rt_copy_init(), so there is no need to get it again at the end.
>
> With this patch, lwtstate also isn't copied from RTF_REJECT routes.
...
> Fixes: 6edb3c96a5f0 ("net/ipv6: Defer initialization of dst to data path")
> Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: remove duplicated include from net_failover.c
From: David Miller @ 2018-09-02 0:45 UTC (permalink / raw)
To: yuehaibing
Cc: sridhar.samudrala, stephen, dan.carpenter, alexander.h.duyck,
jeffrey.t.kirsher, liran.alon, joao.m.martins, netdev,
kernel-janitors
In-Reply-To: <1535687067-23044-1-git-send-email-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Fri, 31 Aug 2018 03:44:27 +0000
> Remove duplicated include.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied, thanks.
^ permalink raw reply
* general protection fault in rhashtable_walk_start_check
From: syzbot @ 2018-09-02 5:11 UTC (permalink / raw)
To: davem, jon.maloy, linux-kernel, netdev, syzkaller-bugs,
tipc-discussion, ying.xue
Hello,
syzbot found the following crash on:
HEAD commit: f611a5b4a51f ibmvnic: Include missing return code checks i..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=15ecaa46400000
kernel config: https://syzkaller.appspot.com/x/.config?x=531a917630d2a492
dashboard link: https://syzkaller.appspot.com/bug?extid=e93a2c41f91b8e2c7d9b
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15cb3cb2400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12d56e3e400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+e93a2c41f91b8e2c7d9b@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
CPU: 0 PID: 4663 Comm: syz-executor272 Not tainted 4.19.0-rc1+ #78
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:rhashtable_walk_start_check+0xd3/0x1400 lib/rhashtable.c:717
Code: f2 c7 40 30 f2 f2 f2 f2 c7 40 34 00 f2 f2 f2 65 48 8b 04 25 28 00 00
00 48 89 45 d0 31 c0 e8 94 9e 0b fe 4c 89 e8 48 c1 e8 03 <80> 3c 18 00 0f
85 a4 0f 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b
RSP: 0018:ffff8801ba726ee8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: dffffc0000000000 RCX: ffffffff852abf68
RDX: 0000000000000000 RSI: ffffffff837121ec RDI: 0000000000000000
RBP: ffff8801ba727130 R08: ffff8801ba750780 R09: ffffed00374fcf3c
R10: ffffed00374fcf3c R11: ffff8801ba7e79e3 R12: 0000000000000000
R13: 0000000000000000 R14: ffff8801ba727270 R15: fffffffffffff000
FS: 0000000001b0b880(0000) GS:ffff8801db000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000100 CR3: 00000001bbf40000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
rhashtable_walk_start include/linux/rhashtable.h:244 [inline]
tipc_nl_sk_walk+0x52/0x1d0 net/tipc/socket.c:3236
tipc_nl_sk_dump+0x24/0x30 net/tipc/socket.c:3366
__tipc_nl_compat_dumpit.isra.11+0x20b/0xad0 net/tipc/netlink_compat.c:192
tipc_nl_compat_dumpit+0x1f4/0x440 net/tipc/netlink_compat.c:265
tipc_nl_compat_handle net/tipc/netlink_compat.c:1142 [inline]
tipc_nl_compat_recv+0x12b3/0x19a0 net/tipc/netlink_compat.c:1205
genl_family_rcv_msg+0x8a3/0x1140 net/netlink/genetlink.c:601
genl_rcv_msg+0xc6/0x168 net/netlink/genetlink.c:626
netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454
genl_rcv+0x28/0x40 net/netlink/genetlink.c:637
netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343
netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:631
___sys_sendmsg+0x7fd/0x930 net/socket.c:2114
__sys_sendmsg+0x11d/0x290 net/socket.c:2152
__do_sys_sendmsg net/socket.c:2161 [inline]
__se_sys_sendmsg net/socket.c:2159 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2159
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4400e9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffe84ec3538 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004400e9
RDX: 0000000000000000 RSI: 0000000020000100 RDI: 0000000000000003
RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
R10: 0000000000000000 R11: 0000000000000213 R12: 0000000000401970
R13: 0000000000401a00 R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
Dumping ftrace buffer:
(ftrace buffer empty)
---[ end trace c8a9aaea5d0de646 ]---
RIP: 0010:rhashtable_walk_start_check+0xd3/0x1400 lib/rhashtable.c:717
Code: f2 c7 40 30 f2 f2 f2 f2 c7 40 34 00 f2 f2 f2 65 48 8b 04 25 28 00 00
00 48 89 45 d0 31 c0 e8 94 9e 0b fe 4c 89 e8 48 c1 e8 03 <80> 3c 18 00 0f
85 a4 0f 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b
RSP: 0018:ffff8801ba726ee8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: dffffc0000000000 RCX: ffffffff852abf68
RDX: 0000000000000000 RSI: ffffffff837121ec RDI: 0000000000000000
RBP: ffff8801ba727130 R08: ffff8801ba750780 R09: ffffed00374fcf3c
R10: ffffed00374fcf3c R11: ffff8801ba7e79e3 R12: 0000000000000000
R13: 0000000000000000 R14: ffff8801ba727270 R15: fffffffffffff000
FS: 0000000001b0b880(0000) GS:ffff8801db000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000100 CR3: 00000001bbf40000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH] net: qca_spi: Fix race condition in spi transfers
From: David Miller @ 2018-09-02 5:27 UTC (permalink / raw)
To: stefan.wahren; +Cc: netdev, linux-kernel
In-Reply-To: <1535719981-20812-1-git-send-email-stefan.wahren@i2se.com>
From: Stefan Wahren <stefan.wahren@i2se.com>
Date: Fri, 31 Aug 2018 14:53:01 +0200
> The performance optimization with the prepared spi messages
> also introduced a race condition between the kernel thread
> and the register dump. This could make spi_sync hang forever.
>
> So revert the optimization completely.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Please resubmit this patch with a better commit message, explaining in
more detail what the race is exactly.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: b53: Provide sensible defaults
From: David Miller @ 2018-09-02 5:28 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, linux-kernel
In-Reply-To: <20180831192949.13195-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Fri, 31 Aug 2018 12:29:49 -0700
> The SRAB driver is the default way to communicate with the integrated
> switch on iProc platforms and the MMAP driver is the way to communicate
> with the integrated switch on DSL BCM63xx and CM BCM33xx.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: bgmac: remove set but not used variable 'err'
From: David Miller @ 2018-09-02 5:31 UTC (permalink / raw)
To: yuehaibing
Cc: f.fainelli, andrew, colin.king, netdev, linux-kernel,
kernel-janitors
In-Reply-To: <1535771590-158413-1-git-send-email-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Sat, 1 Sep 2018 03:13:10 +0000
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/broadcom/bgmac.c: In function 'bgmac_dma_alloc':
> drivers/net/ethernet/broadcom/bgmac.c:619:6: warning:
> variable 'err' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 net-next 1/7] MIPS: lantiq: dma: add dev pointer
From: Andrew Lunn @ 2018-09-02 1:26 UTC (permalink / raw)
To: Hauke Mehrtens
Cc: davem, netdev, vivien.didelot, f.fainelli, john, linux-mips, dev,
hauke.mehrtens, devicetree
In-Reply-To: <6674a5ca-2a9f-b2cf-6127-2dea5ca24ab0@hauke-m.de>
> Hi Andrew,
>
> Thanks for the review.
>
> Yes this should go into 4.19-rcX.
> The "lantiq: Add Lantiq / Intel VRX200 Ethernet driver" patch has a
> compile dependency on this patch. Should I send "MIPS: lantiq: dma: add
> dev pointer" separately or just mark it as 4.19-rcX in this series?
Hi Hauke
Please send it separately. DaveM will merge net in net-next every so
often, at which point your patches which depend on it can be include.
Andrew
^ permalink raw reply
* RE: [PATCH net-next v2] net/tls: Add support for async decryption of tls records
From: Vakul Garg @ 2018-09-02 2:28 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, borisp@mellanox.com, aviadye@mellanox.com,
davejwatson@fb.com
In-Reply-To: <20180831.180052.1973952115883483635.davem@davemloft.net>
> -----Original Message-----
> From: David Miller <davem@davemloft.net>
> Sent: Saturday, September 1, 2018 6:31 AM
> To: Vakul Garg <vakul.garg@nxp.com>
> Cc: netdev@vger.kernel.org; borisp@mellanox.com;
> aviadye@mellanox.com; davejwatson@fb.com
> Subject: Re: [PATCH net-next v2] net/tls: Add support for async decryption of
> tls records
>
> From: Vakul Garg <vakul.garg@nxp.com>
> Date: Wed, 29 Aug 2018 15:26:55 +0530
>
> > When tls records are decrypted using asynchronous acclerators such as
> > NXP CAAM engine, the crypto apis return -EINPROGRESS. Presently, on
> > getting -EINPROGRESS, the tls record processing stops till the time
> > the crypto accelerator finishes off and returns the result. This
> > incurs a context switch and is not an efficient way of accessing the
> > crypto accelerators. Crypto accelerators work efficient when they are
> > queued with multiple crypto jobs without having to wait for the
> > previous ones to complete.
> >
> > The patch submits multiple crypto requests without having to wait for
> > for previous ones to complete. This has been implemented for records
> > which are decrypted in zero-copy mode. At the end of recvmsg(), we
> > wait for all the asynchronous decryption requests to complete.
> >
> > The references to records which have been sent for async decryption
> > are dropped. For cases where record decryption is not possible in
> > zero-copy mode, asynchronous decryption is not used and we wait for
> > decryption crypto api to complete.
> >
> > For crypto requests executing in async fashion, the memory for
> > aead_request, sglists and skb etc is freed from the decryption
> > completion handler. The decryption completion handler wakesup the
> > sleeping user context when recvmsg() flags that it has done sending
> > all the decryption requests and there are no more decryption requests
> > pending to be completed.
> >
> > Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
> > Reviewed-by: Dave Watson <davejwatson@fb.com>
> > ---
> >
> > Changes since v1:
> > - Simplified recvmsg() so to drop reference to skb in case it
> > was submimtted for async decryption.
> > - Modified tls_sw_advance_skb() to handle case when input skb is
> > NULL.
>
> Applied.
I do not find this patch in tree yet.
Can you please check? Thanks and Regards.
^ permalink raw reply
* Re: [PATCH net-next v2] net/tls: Add support for async decryption of tls records
From: David Miller @ 2018-09-02 2:53 UTC (permalink / raw)
To: vakul.garg; +Cc: netdev, borisp, aviadye, davejwatson
In-Reply-To: <DB7PR04MB425234183E9EE101711403008B0D0@DB7PR04MB4252.eurprd04.prod.outlook.com>
From: Vakul Garg <vakul.garg@nxp.com>
Date: Sun, 2 Sep 2018 02:28:00 +0000
> I do not find this patch in tree yet.
> Can you please check? Thanks and Regards.
The perils of working on two different machines :-)
It should be there now, sorry about that.
^ permalink raw reply
* KASAN: slab-out-of-bounds Read in _decode_session6
From: syzbot @ 2018-09-02 4:41 UTC (permalink / raw)
To: davem, herbert, kuznet, linux-kernel, netdev, steffen.klassert,
syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 93ee30f3e8b4 xsk: i40e: get rid of useless struct xdp_umem..
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=11f2115a400000
kernel config: https://syzkaller.appspot.com/x/.config?x=531a917630d2a492
dashboard link: https://syzkaller.appspot.com/bug?extid=acffccec848dc13fe459
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=116b3492400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+acffccec848dc13fe459@syzkaller.appspotmail.com
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
==================================================================
BUG: KASAN: slab-out-of-bounds in _decode_session6+0x1331/0x14e0
net/ipv6/xfrm6_policy.c:161
Read of size 1 at addr ffff8801d882eec7 by task syz-executor1/6667
CPU: 0 PID: 6667 Comm: syz-executor1 Not tainted 4.19.0-rc1+ #86
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x30d mm/kasan/report.c:412
__asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430
_decode_session6+0x1331/0x14e0 net/ipv6/xfrm6_policy.c:161
__xfrm_decode_session+0x71/0x140 net/xfrm/xfrm_policy.c:2299
xfrm_decode_session include/net/xfrm.h:1232 [inline]
vti6_tnl_xmit+0x3c3/0x1bc1 net/ipv6/ip6_vti.c:542
__netdev_start_xmit include/linux/netdevice.h:4313 [inline]
netdev_start_xmit include/linux/netdevice.h:4322 [inline]
xmit_one net/core/dev.c:3217 [inline]
dev_hard_start_xmit+0x272/0xc10 net/core/dev.c:3233
__dev_queue_xmit+0x2ab2/0x3870 net/core/dev.c:3803
dev_queue_xmit+0x17/0x20 net/core/dev.c:3836
__bpf_tx_skb net/core/filter.c:2012 [inline]
__bpf_redirect_common net/core/filter.c:2050 [inline]
__bpf_redirect+0x5b7/0xae0 net/core/filter.c:2057
____bpf_clone_redirect net/core/filter.c:2090 [inline]
bpf_clone_redirect+0x2f6/0x490 net/core/filter.c:2062
bpf_prog_c39d1ba309a769f7+0x749/0x1000
Allocated by task 6667:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
__do_kmalloc_node mm/slab.c:3682 [inline]
__kmalloc_node_track_caller+0x47/0x70 mm/slab.c:3696
__kmalloc_reserve.isra.41+0x3a/0xe0 net/core/skbuff.c:137
pskb_expand_head+0x230/0x10e0 net/core/skbuff.c:1463
skb_ensure_writable+0x3dd/0x640 net/core/skbuff.c:5129
__bpf_try_make_writable net/core/filter.c:1633 [inline]
bpf_try_make_writable net/core/filter.c:1639 [inline]
bpf_try_make_head_writable net/core/filter.c:1647 [inline]
____bpf_clone_redirect net/core/filter.c:2084 [inline]
bpf_clone_redirect+0x14a/0x490 net/core/filter.c:2062
bpf_prog_c39d1ba309a769f7+0x749/0x1000
Freed by task 5493:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xd9/0x210 mm/slab.c:3813
skb_free_head+0x99/0xc0 net/core/skbuff.c:550
skb_release_data+0x6a4/0x880 net/core/skbuff.c:570
skb_release_all+0x4a/0x60 net/core/skbuff.c:627
__kfree_skb net/core/skbuff.c:641 [inline]
consume_skb+0x190/0x4e0 net/core/skbuff.c:701
netlink_dump+0xb14/0xd50 net/netlink/af_netlink.c:2269
netlink_recvmsg+0xf84/0x1490 net/netlink/af_netlink.c:1991
sock_recvmsg_nosec net/socket.c:794 [inline]
sock_recvmsg+0xd0/0x110 net/socket.c:801
___sys_recvmsg+0x2b6/0x680 net/socket.c:2276
__sys_recvmsg+0x11a/0x290 net/socket.c:2325
__do_sys_recvmsg net/socket.c:2335 [inline]
__se_sys_recvmsg net/socket.c:2332 [inline]
__x64_sys_recvmsg+0x78/0xb0 net/socket.c:2332
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8801d882ecc0
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 7 bytes to the right of
512-byte region [ffff8801d882ecc0, ffff8801d882eec0)
The buggy address belongs to the page:
page:ffffea0007620b80 count:1 mapcount:0 mapping:ffff8801dac00940 index:0x0
flags: 0x2fffc0000000100(slab)
raw: 02fffc0000000100 ffffea00070fc048 ffffea00075f9c08 ffff8801dac00940
raw: 0000000000000000 ffff8801d882e040 0000000100000006 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801d882ed80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8801d882ee00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff8801d882ee80: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
^
ffff8801d882ef00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8801d882ef80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH net-next 1/1] qed: Lower the severity of a dcbx log message.
From: David Miller @ 2018-09-02 5:22 UTC (permalink / raw)
To: sudarsana.kalluru; +Cc: netdev, Michal.Kalderon
In-Reply-To: <20180831111017.15747-1-sudarsana.kalluru@cavium.com>
From: Sudarsana Reddy Kalluru <sudarsana.kalluru@cavium.com>
Date: Fri, 31 Aug 2018 04:10:17 -0700
> Driver displays an error message for each unrecognized dcbx TLV that's
> received from the peer or configured on the device. It is observed that
> syslog will be flooded with such messages in certain scenarios e.g.,
> frequent link-flaps/lldp-transactions. Changing the severity of this
> message to verbose level as it's not an error scenario/message.
>
> Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 net-next] liquidio: remove set but not used variable 'irh'
From: David Miller @ 2018-09-02 5:25 UTC (permalink / raw)
To: yuehaibing
Cc: derek.chickles, satananda.burla, felix.manlunas, raghu.vatsavayi,
netdev, kernel-janitors
In-Reply-To: <1535717036-88514-1-git-send-email-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Fri, 31 Aug 2018 12:03:56 +0000
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/cavium/liquidio/request_manager.c: In function 'lio_process_iq_request_list':
> drivers/net/ethernet/cavium/liquidio/request_manager.c:383:27: warning:
> variable 'irh' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> v2: fix patch description,remove 'cHECK-'
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: collect hardware queue descriptors
From: David Miller @ 2018-09-02 5:26 UTC (permalink / raw)
To: rahul.lakkireddy; +Cc: netdev, ganeshgr, nirranjan, indranil
In-Reply-To: <1535719594-15086-1-git-send-email-rahul.lakkireddy@chelsio.com>
From: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Date: Fri, 31 Aug 2018 18:16:34 +0530
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c b/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c
> index d97e0d7e541a..02fc350f81c9 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c
...
> +static inline u32 cudbg_uld_txq_to_qtype(u32 uld)
Do not use inline in foo.c files, let the compiler decide.
^ permalink raw reply
* Re: [PATCH] cxgb4: fix abort_req_rss6 struct
From: David Miller @ 2018-09-02 5:28 UTC (permalink / raw)
To: swise; +Cc: netdev, jgg, dledford, linux-rdma
In-Reply-To: <1e9f55943699dcc2bc921000ee7ee5353cbf7480.1535742195.git.swise@opengridcomputing.com>
From: Steve Wise <swise@opengridcomputing.com>
Date: Fri, 31 Aug 2018 11:52:00 -0700
> Remove the incorrect WR_HDR field which can cause a misinterpretation
> of this CPL by ULDs.
>
> Fixes: a3cdaa69e4ae ("cxgb4: Adds CPL support for Shared Receive Queues")
> Signed-off-by: Steve Wise <swise@opengridcomputing.com>
> ---
>
> Dave, Doug, and Jason,
>
> I request this merge through the rdma repo since the only user of this
> structure is iw_cxgb4.
No objections from me.
^ 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