* [PATCH v3 3/3] net: fddi: skfp: Remove unused private PCI definitions
From: Puranjay Mohan @ 2019-06-21 9:46 UTC (permalink / raw)
To: Shuah Khan
Cc: Puranjay Mohan, Bjorn Helgaas, netdev, Linux Kernel Mailing List,
linux-kernel-mentees, linux-pci
In-Reply-To: <20190621094607.15011-1-puranjay12@gmail.com>
Remove unused private PCI definitions from skfbi.h because generic PCI
symbols are already included from pci_regs.h.
Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
---
drivers/net/fddi/skfp/h/skfbi.h | 76 ---------------------------------
1 file changed, 76 deletions(-)
diff --git a/drivers/net/fddi/skfp/h/skfbi.h b/drivers/net/fddi/skfp/h/skfbi.h
index 5f9b631e7515..0b5bd2e170a7 100644
--- a/drivers/net/fddi/skfp/h/skfbi.h
+++ b/drivers/net/fddi/skfp/h/skfbi.h
@@ -24,49 +24,6 @@
* (ML) = only defined for Monalisa
*/
-/*
- * Configuration Space header
- */
-#define PCI_VENDOR_ID 0x00 /* 16 bit Vendor ID */
-#define PCI_DEVICE_ID 0x02 /* 16 bit Device ID */
-#define PCI_COMMAND 0x04 /* 16 bit Command */
-#define PCI_STATUS 0x06 /* 16 bit Status */
-#define PCI_REVISION_ID 0x08 /* 8 bit Revision ID */
-#define PCI_CLASS_CODE 0x09 /* 24 bit Class Code */
-#define PCI_CACHE_LSZ 0x0c /* 8 bit Cache Line Size */
-#define PCI_LAT_TIM 0x0d /* 8 bit Latency Timer */
-#define PCI_HEADER_T 0x0e /* 8 bit Header Type */
-#define PCI_BIST 0x0f /* 8 bit Built-in selftest */
-#define PCI_BASE_1ST 0x10 /* 32 bit 1st Base address */
-#define PCI_BASE_2ND 0x14 /* 32 bit 2nd Base address */
-/* Byte 18..2b: Reserved */
-#define PCI_SUB_VID 0x2c /* 16 bit Subsystem Vendor ID */
-#define PCI_SUB_ID 0x2e /* 16 bit Subsystem ID */
-#define PCI_BASE_ROM 0x30 /* 32 bit Expansion ROM Base Address */
-/* Byte 34..33: Reserved */
-#define PCI_CAP_PTR 0x34 /* 8 bit (ML) Capabilities Ptr */
-/* Byte 35..3b: Reserved */
-#define PCI_IRQ_LINE 0x3c /* 8 bit Interrupt Line */
-#define PCI_IRQ_PIN 0x3d /* 8 bit Interrupt Pin */
-#define PCI_MIN_GNT 0x3e /* 8 bit Min_Gnt */
-#define PCI_MAX_LAT 0x3f /* 8 bit Max_Lat */
-/* Device Dependent Region */
-#define PCI_OUR_REG 0x40 /* 32 bit (DV) Our Register */
-#define PCI_OUR_REG_1 0x40 /* 32 bit (ML) Our Register 1 */
-#define PCI_OUR_REG_2 0x44 /* 32 bit (ML) Our Register 2 */
-/* Power Management Region */
-#define PCI_PM_CAP_ID 0x48 /* 8 bit (ML) Power Management Cap. ID */
-#define PCI_PM_NITEM 0x49 /* 8 bit (ML) Next Item Ptr */
-#define PCI_PM_CAP_REG 0x4a /* 16 bit (ML) Power Management Capabilities */
-#define PCI_PM_CTL_STS 0x4c /* 16 bit (ML) Power Manag. Control/Status */
-/* Byte 0x4e: Reserved */
-#define PCI_PM_DAT_REG 0x4f /* 8 bit (ML) Power Manag. Data Register */
-/* VPD Region */
-#define PCI_VPD_CAP_ID 0x50 /* 8 bit (ML) VPD Cap. ID */
-#define PCI_VPD_NITEM 0x51 /* 8 bit (ML) Next Item Ptr */
-#define PCI_VPD_ADR_REG 0x52 /* 16 bit (ML) VPD Address Register */
-#define PCI_VPD_DAT_REG 0x54 /* 32 bit (ML) VPD Data Register */
-/* Byte 58..ff: Reserved */
/*
* I2C Address (PCI Config)
@@ -76,39 +33,6 @@
*/
#define I2C_ADDR_VPD 0xA0 /* I2C address for the VPD EEPROM */
-/*
- * Define Bits and Values of the registers
- */
-/* PCI_VENDOR_ID 16 bit Vendor ID */
-/* PCI_DEVICE_ID 16 bit Device ID */
-/* Values for Vendor ID and Device ID shall be patched into the code */
-/* PCI_COMMAND 16 bit Command */
-#define PCI_FBTEN 0x0200 /* Bit 9: Fast Back-To-Back enable */
-#define PCI_SERREN 0x0100 /* Bit 8: SERR enable */
-#define PCI_ADSTEP 0x0080 /* Bit 7: Address Stepping */
-#define PCI_PERREN 0x0040 /* Bit 6: Parity Report Response enable */
-#define PCI_VGA_SNOOP 0x0020 /* Bit 5: VGA palette snoop */
-#define PCI_MWIEN 0x0010 /* Bit 4: Memory write an inv cycl ena */
-#define PCI_SCYCEN 0x0008 /* Bit 3: Special Cycle enable */
-#define PCI_BMEN 0x0004 /* Bit 2: Bus Master enable */
-#define PCI_MEMEN 0x0002 /* Bit 1: Memory Space Access enable */
-#define PCI_IOEN 0x0001 /* Bit 0: IO Space Access enable */
-
-/* PCI_STATUS 16 bit Status */
-#define PCI_PERR 0x8000 /* Bit 15: Parity Error */
-#define PCI_SERR 0x4000 /* Bit 14: Signaled SERR */
-#define PCI_RMABORT 0x2000 /* Bit 13: Received Master Abort */
-#define PCI_RTABORT 0x1000 /* Bit 12: Received Target Abort */
-#define PCI_STABORT 0x0800 /* Bit 11: Sent Target Abort */
-#define PCI_DEVSEL 0x0600 /* Bit 10..9: DEVSEL Timing */
-#define PCI_DEV_FAST (0<<9) /* fast */
-#define PCI_DEV_MEDIUM (1<<9) /* medium */
-#define PCI_DEV_SLOW (2<<9) /* slow */
-#define PCI_DATAPERR 0x0100 /* Bit 8: DATA Parity error detected */
-#define PCI_FB2BCAP 0x0080 /* Bit 7: Fast Back-to-Back Capability */
-#define PCI_UDF 0x0040 /* Bit 6: User Defined Features */
-#define PCI_66MHZCAP 0x0020 /* Bit 5: 66 MHz PCI bus clock capable */
-#define PCI_NEWCAP 0x0010 /* Bit 4: New cap. list implemented */
#define PCI_ERRBITS (PCI_STATUS_DETECTED_PARITY | PCI_STATUS_SIG_SYSTEM_ERROR | PCI_STATUS_REC_MASTER_ABORT | PCI_STATUS_SIG_TARGET_ABORT | PCI_STATUS_PARITY)
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v2 bpf-next 00/11] BTF-defined BPF map definitions
From: Lorenz Bauer @ 2019-06-21 10:29 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Daniel Borkmann, Andrii Nakryiko, Alexei Starovoitov, Networking,
bpf, Kernel Team, Jakub Kicinski, Joe Stringer
In-Reply-To: <CAEf4BzYaHG9Z_eFQCtwxA7t5GwQq2wr=AEeFWZpqx9vdQqKv1g@mail.gmail.com>
On Fri, 21 Jun 2019 at 05:20, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>
> On Thu, Jun 20, 2019 at 7:49 AM Lorenz Bauer <lmb@cloudflare.com> wrote:
> >
> > On Tue, 18 Jun 2019 at 22:37, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
> >
> > > > I would just drop the object-scope pinning. We avoided using it and I'm not
> > > > aware if anyone else make use. It also has the ugly side-effect that this
> > > > relies on AF_ALG which e.g. on some cloud provider shipped kernels is disabled.
> > > > The pinning attribute should be part of the standard set of map attributes for
> > > > libbpf though as it's generally useful for networking applications.
> > >
> > > Sounds good. I'll do some more surveying of use cases inside FB to see
> > > if anyone needs object-scope pinning, just to be sure we are not
> > > short-cutting anyone.
> >
> > I'm also curious what the use cases for declarative pinning are. From my
> > limited POV it doesn't seem that useful? There are a couple of factors:
>
> Cilium is using it pretty extensively, so there are clearly use cases.
> The most straigtforward use case is using a map created and shared by
> another BPF program (to communicate, read stats, what have you).
I think Cilium is in the quirky position that it has a persistent daemon, but
shells out to tc for loading programs. They are probably also the most
advanced (open-source) users of BPF out there. If I understood their comments
correctly they want to move to using a library for loading their ELF. At that
point whether something is possible in a declarative way is less important,
because you have the much more powerful APIs at your disposal.
Maybe Daniel or someone else from the Cilium team can chime in here?
> > * Systemd mounts the default location only accessible to root, so I have to
> > used my own bpffs mount.
> > * Since I don't want to hard code that, I put it in a config file.
> > * After loading the ELF we pin maps from the daemon managing the XDP.
>
> So mounting root would be specified per bpf_object, before maps are
> created, so user-land driving application will have an opportunity to
> tune everything. Declarative is only the per-map decision of whether
> that map should be exposed to outer world (for sharing) or not.
So `tc filter add bpf obj foo.elf pin-root /gobbledygook`?
> Then check tools/testing/selftests/bpf/progs/btf_dump_test_case_syntax.c
> for more crazy syntax ;)
>
> typedef char * (* const (* const fn_ptr_arr2_t[5])())(char * (*)(int));
Not on a Friday ;P
> > What if this did
> >
> > __type(value, struct my_value)[1000];
> > struct my_value __member(value)[1000]; // alternative
> >
> > instead, and skipped max_entries?
>
> I considered that, but decided for now to keep all those attributes
> orthogonal for more flexibility and uniformity. This syntax might be
> considered a nice "syntax sugar" and can be added in the future, if
> necessary.
Ack.
> > At that point you have to understand that value is a pointer so all of
> > our efforts
> > are for naught. I suspect there is other weirdness like this, but I need to play
> > with it a little bit more.
>
> Yes, C can let you do crazy stuff, if you wish, but I think that
> shouldn't be a blocker for this proposal. I haven't seen any BPF
> program doing that, usually you duplicate the type of inner value
> inside your function anyway, so there is no point in taking
> sizeof(map.value) from BPF program side. From outside, though, all the
> types will make sense, as expected.
Right, but in my mind that is a bit of a cop out. I like BTF map definitions,
and I want them to be as unsurprising as possible, so that they are
easy to use and adopt.
If a type encodes all the information we need via the array dimension hack,
couldn't we make the map variable itself a pointer, and drop the inner pointers?
struct my_map_def {
int type[BPF_MAP_TYPE_HASH];
int value;
struct foo key;
...
}
struct my_map_def *my_map;
--
Lorenz Bauer | Systems Engineer
6th Floor, County Hall/The Riverside Building, SE1 7PB, UK
www.cloudflare.com
^ permalink raw reply
* Re: [PATCH iproute2-next v2 1/2] ipaddress: correctly print a VF hw address in the IPoIB case
From: Denis Kirjanov @ 2019-06-21 10:30 UTC (permalink / raw)
To: stephen; +Cc: netdev, linux-rdma, dledford, mkubecek, Denis Kirjanov
In-Reply-To: <20190620090249.106704-1-dkirjanov@suse.com>
On 6/20/19, Denis Kirjanov <kda@linux-powerpc.org> wrote:
> Current code assumes that we print Etheret mac and
> that doesn't work in IPoIB case with SRIOV-enabled hardware
>
> Before:
> 11: ib1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast
> state UP mode DEFAULT group default qlen 256
> link/infiniband
> 80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd
> 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
> vf 0 MAC 14:80:00:00:66:fe, spoof checking off, link-state disable,
> trust off, query_rss off
> ...
>
> After:
> 11: ib1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast
> state UP mode DEFAULT group default qlen 256
> link/infiniband
> 80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd
> 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
> vf 0 link/infiniband
> 80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd
> 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff, spoof
> checking off, link-state disable, trust off, query_rss off
>
> v1->v2: updated kernel headers to uapi commit
>
> Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
Hi Stephen,
are you going to take the patches?
Thanks!
> ---
> ip/ipaddress.c | 42 +++++++++++++++++++++++++++++++++++++-----
> 1 file changed, 37 insertions(+), 5 deletions(-)
>
> diff --git a/ip/ipaddress.c b/ip/ipaddress.c
> index b504200b..13ad76dd 100644
> --- a/ip/ipaddress.c
> +++ b/ip/ipaddress.c
> @@ -26,6 +26,7 @@
>
> #include <linux/netdevice.h>
> #include <linux/if_arp.h>
> +#include <linux/if_infiniband.h>
> #include <linux/sockios.h>
> #include <linux/net_namespace.h>
>
> @@ -349,9 +350,10 @@ static void print_af_spec(FILE *fp, struct rtattr
> *af_spec_attr)
>
> static void print_vf_stats64(FILE *fp, struct rtattr *vfstats);
>
> -static void print_vfinfo(FILE *fp, struct rtattr *vfinfo)
> +static void print_vfinfo(struct ifinfomsg *ifi, FILE *fp, struct rtattr
> *vfinfo)
> {
> struct ifla_vf_mac *vf_mac;
> + struct ifla_vf_broadcast *vf_broadcast;
> struct ifla_vf_tx_rate *vf_tx_rate;
> struct rtattr *vf[IFLA_VF_MAX + 1] = {};
>
> @@ -365,13 +367,43 @@ static void print_vfinfo(FILE *fp, struct rtattr
> *vfinfo)
> parse_rtattr_nested(vf, IFLA_VF_MAX, vfinfo);
>
> vf_mac = RTA_DATA(vf[IFLA_VF_MAC]);
> + vf_broadcast = RTA_DATA(vf[IFLA_VF_BROADCAST]);
> vf_tx_rate = RTA_DATA(vf[IFLA_VF_TX_RATE]);
>
> print_string(PRINT_FP, NULL, "%s ", _SL_);
> print_int(PRINT_ANY, "vf", "vf %d ", vf_mac->vf);
> - print_string(PRINT_ANY, "mac", "MAC %s",
> - ll_addr_n2a((unsigned char *) &vf_mac->mac,
> - ETH_ALEN, 0, b1, sizeof(b1)));
> +
> + print_string(PRINT_ANY,
> + "link_type",
> + " link/%s ",
> + ll_type_n2a(ifi->ifi_type, b1, sizeof(b1)));
> +
> + print_color_string(PRINT_ANY,
> + COLOR_MAC,
> + "address",
> + "%s",
> + ll_addr_n2a((unsigned char *) &vf_mac->mac,
> + ifi->ifi_type == ARPHRD_ETHER ? ETH_ALEN : INFINIBAND_ALEN,
> + ifi->ifi_type,
> + b1, sizeof(b1)));
> +
> + if (vf[IFLA_VF_BROADCAST]) {
> + if (ifi->ifi_flags&IFF_POINTOPOINT) {
> + print_string(PRINT_FP, NULL, " peer ", NULL);
> + print_bool(PRINT_JSON,
> + "link_pointtopoint", NULL, true);
> + } else {
> + print_string(PRINT_FP, NULL, " brd ", NULL);
> + }
> + print_color_string(PRINT_ANY,
> + COLOR_MAC,
> + "broadcast",
> + "%s",
> + ll_addr_n2a((unsigned char *)
> &vf_broadcast->broadcast,
> + ifi->ifi_type ==
> ARPHRD_ETHER ? ETH_ALEN : INFINIBAND_ALEN,
> + ifi->ifi_type,
> + b1, sizeof(b1)));
> + }
>
> if (vf[IFLA_VF_VLAN_LIST]) {
> struct rtattr *i, *vfvlanlist = vf[IFLA_VF_VLAN_LIST];
> @@ -1102,7 +1134,7 @@ int print_linkinfo(struct nlmsghdr *n, void *arg)
> open_json_array(PRINT_JSON, "vfinfo_list");
> for (i = RTA_DATA(vflist); RTA_OK(i, rem); i = RTA_NEXT(i, rem)) {
> open_json_object(NULL);
> - print_vfinfo(fp, i);
> + print_vfinfo(ifi, fp, i);
> close_json_object();
> }
> close_json_array(PRINT_JSON, NULL);
> --
> 2.12.3
>
>
^ permalink raw reply
* [PATCH] ionic: fix semicolon.cocci warnings
From: kbuild test robot @ 2019-06-21 10:30 UTC (permalink / raw)
To: Shannon Nelson; +Cc: kbuild-all, snelson, netdev
In-Reply-To: <20190620202424.23215-12-snelson@pensando.io>
From: kbuild test robot <lkp@intel.com>
drivers/net/ethernet/pensando/ionic/ionic_lif.c:48:3-4: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
Fixes: 311c0c084b51 ("ionic: Add Rx filter and rx_mode nod support")
CC: Shannon Nelson <snelson@pensando.io>
Signed-off-by: kbuild test robot <lkp@intel.com>
---
url: https://github.com/0day-ci/linux/commits/Shannon-Nelson/ionic-Add-basic-framework-for-IONIC-Network-device-driver/20190621-110046
ionic_lif.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/pensando/ionic/ionic_lif.c
+++ b/drivers/net/ethernet/pensando/ionic/ionic_lif.c
@@ -45,7 +45,7 @@ static void ionic_lif_deferred_work(stru
break;
default:
break;
- };
+ }
kfree(w);
schedule_work(&def->work);
}
^ permalink raw reply
* Re: [PATCH net-next 11/18] ionic: Add Rx filter and rx_mode nod support
From: kbuild test robot @ 2019-06-21 10:30 UTC (permalink / raw)
To: Shannon Nelson; +Cc: kbuild-all, snelson, netdev
In-Reply-To: <20190620202424.23215-12-snelson@pensando.io>
Hi Shannon,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Shannon-Nelson/ionic-Add-basic-framework-for-IONIC-Network-device-driver/20190621-110046
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
coccinelle warnings: (new ones prefixed by >>)
>> drivers/net/ethernet/pensando/ionic/ionic_lif.c:48:3-4: Unneeded semicolon
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH v7 0/6] Add support for Orange Pi 3
From: Ondřej Jirman @ 2019-06-21 10:44 UTC (permalink / raw)
To: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Jernej Škrabec
Cc: Mark Rutland, Alexandre Torgue, devicetree, David Airlie, netdev,
linux-kernel, dri-devel, linux-stm32, Jose Abreu,
linux-arm-kernel, Daniel Vetter, Giuseppe Cavallaro,
David S. Miller, Maxime Coquelin
In-Reply-To: <20190620134748.17866-1-megous@megous.com>
On Thu, Jun 20, 2019 at 03:47:42PM +0200, verejna wrote:
> From: Ondrej Jirman <megous@megous.com>
>
> This series implements support for Xunlong Orange Pi 3 board.
>
> - ethernet support (patches 1-3)
> - HDMI support (patches 4-6)
>
> For some people, ethernet doesn't work after reboot (but works on cold
> boot), when the stmmac driver is built into the kernel. It works when
> the driver is built as a module. It's either some timing issue, or power
> supply issue or a combination of both. Module build induces a power
> cycling of the phy.
>
> I encourage people with this issue, to build the driver into the kernel,
> and try to alter the reset timings for the phy in DTS or
> startup-delay-us and report the findings.
Other theory to test is that the PHY requires two power supplies to be
enabled at the same time, and during reboot one of them (one controlled
via GPIO) may be turned off, and ALDO2 controlled by AXP805 may not.
It should be possible to turn off ALDO2 in u-boot via CONFIG_AXP_ALDO2_VOLT=0
(You may need to enable CONFIG_AXP809_POWER and other options too, since
it seems AXP805 support is not enabled for orange pi 3 in u-boot)
regards,
o.
>
> Please take a look.
>
> thank you and regards,
> Ondrej Jirman
>
>
> Changes in v7:
> - dropped stored reference to connector_pdev as suggested by Jernej
> - added forgotten dt-bindings reviewed-by tag
>
> Changes in v6:
> - added dt-bindings reviewed-by tag
> - fix wording in stmmac commit (as suggested by Sergei)
>
> Changes in v5:
> - dropped already applied patches (pinctrl patches, mmc1 pinconf patch)
> - rename GMAC-3V3 -> GMAC-3V to match the schematic (Jagan)
> - changed hdmi-connector's ddc-supply property to ddc-en-gpios
> (Rob Herring)
>
> Changes in v4:
> - fix checkpatch warnings/style issues
> - use enum in struct sunxi_desc_function for io_bias_cfg_variant
> - collected acked-by's
> - fix compile error in drivers/pinctrl/sunxi/pinctrl-sun9i-a80-r.c:156
> caused by missing conversion from has_io_bias_cfg struct member
> (I've kept the acked-by, because it's a trivial change, but feel free
> to object.) (reported by Martin A. on github)
> I did not have A80 pinctrl enabled for some reason, so I did not catch
> this sooner.
> - dropped brcm firmware patch (was already applied)
> - dropped the wifi dts patch (will re-send after H6 RTC gets merged,
> along with bluetooth support, in a separate series)
>
> Changes in v3:
> - dropped already applied patches
> - changed pinctrl I/O bias selection constants to enum and renamed
> - added /omit-if-no-ref/ to mmc1_pins
> - made mmc1_pins default pinconf for mmc1 in H6 dtsi
> - move ddc-supply to HDMI connector node, updated patch descriptions,
> changed dt-bindings docs
>
> Changes in v2:
> - added dt-bindings documentation for the board's compatible string
> (suggested by Clement)
> - addressed checkpatch warnings and code formatting issues (on Maxime's
> suggestions)
> - stmmac: dropped useless parenthesis, reworded description of the patch
> (suggested by Sergei)
> - drop useles dev_info() about the selected io bias voltage
> - docummented io voltage bias selection variant macros
> - wifi: marked WiFi DTS patch and realted mmc1_pins as "DO NOT MERGE",
> because wifi depends on H6 RTC support that's not merged yet (suggested
> by Clement)
> - added missing signed-of-bys
> - changed &usb2otg dr_mode to otg, and added a note about VBUS
> - improved wording of HDMI driver's DDC power supply patch
>
> Icenowy Zheng (2):
> net: stmmac: sun8i: add support for Allwinner H6 EMAC
> net: stmmac: sun8i: force select external PHY when no internal one
>
> Ondrej Jirman (4):
> arm64: dts: allwinner: orange-pi-3: Enable ethernet
> dt-bindings: display: hdmi-connector: Support DDC bus enable
> drm: sun4i: Add support for enabling DDC I2C bus to sun8i_dw_hdmi glue
> arm64: dts: allwinner: orange-pi-3: Enable HDMI output
>
> .../display/connector/hdmi-connector.txt | 1 +
> .../dts/allwinner/sun50i-h6-orangepi-3.dts | 70 +++++++++++++++++++
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 54 ++++++++++++--
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 +
> .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 21 ++++++
> 5 files changed, 144 insertions(+), 4 deletions(-)
>
> --
> 2.22.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 20/29] docs: leds: convert to ReST
From: Pavel Machek @ 2019-06-21 10:59 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Vadim Pasternak, Jacek Anaszewski, Dan Murphy,
Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
David S. Miller, linux-leds, netfilter-devel, coreteam, netdev
In-Reply-To: <b8185b2d816810281a2b712c70518159516785b6.1560890801.git.mchehab+samsung@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 608 bytes --]
On Tue 2019-06-18 17:53:38, Mauro Carvalho Chehab wrote:
> Rename the leds documentation files to ReST, add an
> index for them and adjust in order to produce a nice html
> output via the Sphinx build system.
>
> At its new index.rst, let's add a :orphan: while this is not linked to
> the main index.rst file, in order to avoid build warnings.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] rt2x00: fix rx queue hang
From: Soeren Moch @ 2019-06-21 11:30 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Helmut Schaa, Kalle Valo, David S. Miller, linux-wireless, netdev,
linux-kernel, stable
In-Reply-To: <20190618093431.GA2577@redhat.com>
Hi!
On 18.06.19 11:34, Stanislaw Gruszka wrote:
> Hi
>
> On Mon, Jun 17, 2019 at 11:46:56AM +0200, Soeren Moch wrote:
>> Since commit ed194d136769 ("usb: core: remove local_irq_save() around
>> ->complete() handler") the handlers rt2x00usb_interrupt_rxdone() and
>> rt2x00usb_interrupt_txdone() are not running with interrupts disabled
>> anymore. So these handlers are not guaranteed to run completely before
>> workqueue processing starts. So only mark entries ready for workqueue
>> processing after proper accounting in the dma done queue.
> It was always the case on SMP machines that rt2x00usb_interrupt_{tx/rx}done
> can run concurrently with rt2x00_work_{rx,tx}done, so I do not
> understand how removing local_irq_save() around complete handler broke
> things.
I think because completion handlers can be interrupted now and scheduled
away
in the middle of processing.
> Have you reverted commit ed194d136769 and the revert does solve the problem ?
Yes, I already sent a patch for this, see [1]. But this was not considered
an acceptablesolution. Especially RT folks do not like code running with
interrupts disabled,particularly when trying to acquire spinlocks then.
[1] https://lkml.org/lkml/2019/5/31/863
> Between 4.19 and 4.20 we have some quite big changes in rt2x00 driver:
>
> 0240564430c0 rt2800: flush and txstatus rework for rt2800mmio
> adf26a356f13 rt2x00: use different txstatus timeouts when flushing
> 5022efb50f62 rt2x00: do not check for txstatus timeout every time on tasklet
> 0b0d556e0ebb rt2800mmio: use txdone/txstatus routines from lib
> 5c656c71b1bf rt2800: move usb specific txdone/txstatus routines to rt2800lib
>
> so I'm a bit afraid that one of those changes is real cause of
> the issue not ed194d136769 .
I tested 4.20 and 5.1 and see the exact same behavior. Reverting this
usb core patchsolves the problem.
4.19.x (before this usb core patch) is running fine.
>> Note that rt2x00usb_work_rxdone() processes all available entries, not
>> only such for which queue_work() was called.
>>
>> This fixes a regression on a RT5370 based wifi stick in AP mode, which
>> suddenly stopped data transmission after some period of heavy load. Also
>> stopping the hanging hostapd resulted in the error message "ieee80211
>> phy0: rt2x00queue_flush_queue: Warning - Queue 14 failed to flush".
>> Other operation modes are probably affected as well, this just was
>> the used testcase.
> Do you know what actually make the traffic stop,
> TX queue hung or RX queue hung?
I think RX queue hang, as stated in the patch title. "Queue 14" means QID_RX
(rt2x00queue.h, enum data_queue_qid).
I also tried to re-add local_irq_save() in only one of the handlers. Adding
this tort2x00usb_interrupt_rxdone() alone solved the issue, while doing so
for tx alonedid not.
Note that this doesn't mean there is no problem for tx, that's maybe
just more
difficult to trigger.
>> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
>> index 1b08b01db27b..9c102a501ee6 100644
>> --- a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
>> +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
>> @@ -263,9 +263,9 @@ EXPORT_SYMBOL_GPL(rt2x00lib_dmastart);
>>
>> void rt2x00lib_dmadone(struct queue_entry *entry)
>> {
>> - set_bit(ENTRY_DATA_STATUS_PENDING, &entry->flags);
>> clear_bit(ENTRY_OWNER_DEVICE_DATA, &entry->flags);
>> rt2x00queue_index_inc(entry, Q_INDEX_DMA_DONE);
>> + set_bit(ENTRY_DATA_STATUS_PENDING, &entry->flags);
> Unfortunately I do not understand how this suppose to fix the problem,
> could you elaborate more about this change?
>
Re-adding local_irq_save() around thisrt2x00lib_dmadone()solved
the issue. So I also tried to reverse the order of these calls.
It seems totally plausible to me, that the correct sequence is to
first clear the device assignment, then to set the status to dma_done,
then to trigger the workqueue processing for this entry. When the handler
is scheduled away in the middle of this sequence, now there is no
strange state where the entry can be processed by the workqueue while
not declared dma_done for it.
With this changed sequence there is no need anymore to disable interrupts
for solving the hang issue.
Regards,
Soeren
^ permalink raw reply
* Re: [PATCH] mm: mempolicy: handle vma with unmovable pages mapped correctly in mbind
From: Vlastimil Babka @ 2019-06-21 11:33 UTC (permalink / raw)
To: Yang Shi, Michal Hocko
Cc: akpm, mgorman, linux-mm, linux-kernel, Eric Dumazet,
David S. Miller, netdev
In-Reply-To: <d185f277-85ed-4dc1-8ff2-2984b54a0d64@linux.alibaba.com>
On 6/20/19 6:08 PM, Yang Shi wrote:
>
>
> On 6/20/19 12:18 AM, Vlastimil Babka wrote:
>> On 6/19/19 8:19 PM, Yang Shi wrote:
>>>>>> This is getting even more muddy TBH. Is there any reason that we
>>>>>> have to
>>>>>> handle this problem during the isolation phase rather the migration?
>>>>> I think it was already said that if pages can't be isolated, then
>>>>> migration phase won't process them, so they're just ignored.
>>>> Yes，exactly.
>>>>
>>>>> However I think the patch is wrong to abort immediately when
>>>>> encountering such page that cannot be isolated (AFAICS). IMHO it should
>>>>> still try to migrate everything it can, and only then return -EIO.
>>>> It is fine too. I don't see mbind semantics define how to handle such
>>>> case other than returning -EIO.
>> I think it does. There's:
>> If MPOL_MF_MOVE is specified in flags, then the kernel *will attempt to
>> move all the existing pages* ... If MPOL_MF_STRICT is also specified,
>> then the call fails with the error *EIO if some pages could not be moved*
>>
>> Aborting immediately would be against the attempt to move all.
>>
>>> By looking into the code, it looks not that easy as what I thought.
>>> do_mbind() would check the return value of queue_pages_range(), it just
>>> applies the policy and manipulates vmas as long as the return value is 0
>>> (success), then migrate pages on the list. We could put the movable
>>> pages on the list by not breaking immediately, but they will be ignored.
>>> If we migrate the pages regardless of the return value, it may break the
>>> policy since the policy will *not* be applied at all.
>> I think we just need to remember if there was at least one page that
>> failed isolation or migration, but keep working, and in the end return
>> EIO if there was such page(s). I don't think it breaks the policy. Once
>> pages are allocated in a mapping, changing the policy is a best effort
>> thing anyway.
>
> The current behavior is:
> If queue_pages_range() return -EIO (vma is not migratable, ignore other
> conditions since we just focus on page migration), the policy won't be
> set and no page will be migrated.
Ah, I see. IIUC the current behavior is due to your recent commit
a7f40cfe3b7a ("mm: mempolicy: make mbind() return -EIO when
MPOL_MF_STRICT is specified") in order to fix commit 6f4576e3687b
("mempolicy: apply page table walker on queue_pages_range()"), which
caused -EIO to be not returned enough. But I think you went too far and
instead return -EIO too much. If I look at the code in parent commit of
6f4576e3687b, I can see in queue_pages_range():
if ((flags & MPOL_MF_STRICT) ||
((flags & (MPOL_MF_MOVE | MPOL_MF_MOVE_ALL)) &&
vma_migratable(vma))) {
err = queue_pages_pgd_range(vma, start, endvma, nodes,
flags, private);
if (err)
break;
}
and in queue_pages_pte_range():
if (flags & (MPOL_MF_MOVE | MPOL_MF_MOVE_ALL))
migrate_page_add(page, private, flags);
else
break;
So originally, there was no returning of -EIO due to !vma_migratable() -
as long as MPOL_MF_STRICT and MPOL_MF_MOVE* was specified, the code
tried to queue for migration everything it could and didn't ever abort,
AFAICS. And I still think that's the best possible behavior.
> However, the problem here is the vma might look migratable, but some or
> all the underlying pages are unmovable. So, my patch assumes the vma is
> *not* migratable if at least one page is unmovable. I'm not sure if it
> is possible to have both movable and unmovable pages for the same
> mapping or not, I'm supposed the vma would be split much earlier.
>
> If we don't abort immediately, then we record if there is unmovable
> page, then we could do:
> #1. Still follows the current behavior (then why not abort immediately?)
See above how the current behavior differs from the original one.
> #2. Set mempolicy then migrate all the migratable pages. But, we may end
> up with the pages on node A, but the policy says node B. Doesn't it
> break the policy?
The policy can already be "broken" (violated is probably better word) by
migrate_pages() failing. If that happens, we don't rollback the migrated
pages and reset the policy back, right? I think the manpage is clear
that MPOL_MF_MOVE is a best-effort. Userspace will know that not
everything was successfully migrated (via -EIO), and can take whatever
steps it deems necessary - attempt rollback, determine which exact
page(s) are violating the policy, etc.
>>
>>>>
>
^ permalink raw reply
* Re: bonded active-backup ethernet-wifi drops packets
From: Brian J. Murrell @ 2019-06-21 12:30 UTC (permalink / raw)
To: netdev
In-Reply-To: <0292e9eefb12f1b1e493f5af8ab78fa00744ed20.camel@interlinx.bc.ca>
[-- Attachment #1: Type: text/plain, Size: 4060 bytes --]
On Tue, 2019-06-18 at 14:57 -0400, Brian J. Murrell wrote:
> Hi.
An update...
I have another machine with the same ethernet-wifi bonded connection
and it behaves perfectly but only when disconnected from the wired-
ethernet and therefore on the bonded-wifi. The ping -f occasionally
bursts out a few '.'s but it quickly catches up and removes them (i.e.
very momentary delay -- to be expected for wifi I suppose).
But when I do plug it into wired, it drops packets like the other
machine. Which is really odd. I'd think wired should be much more
reliable than wifi.
So why does this machine behave (but only on wifi) and the other one
doesn't. To compare them...
> I have an active-backup bonded connection on a 5.1.6 kernel
Working machine has a 5.0.16 kernel.
> My bonding config:
>
> $ cat /proc/net/bonding/bond0
> Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
>
> Bonding Mode: fault-tolerance (active-backup)
> Primary Slave: enp0s31f6 (primary_reselect always)
> Currently Active Slave: enp0s31f6
> MII Status: up
> MII Polling Interval (ms): 100
> Up Delay (ms): 0
> Down Delay (ms): 0
>
> Slave Interface: enp0s31f6
> MII Status: up
> Speed: 1000 Mbps
> Duplex: full
> Link Failure Count: 0
> Permanent HW addr: 0c:54:15:4a:b2:0d
> Slave queue ID: 0
>
> Slave Interface: wlp2s0
> MII Status: up
> Speed: Unknown
> Duplex: Unknown
> Link Failure Count: 1
> Permanent HW addr: 0c:54:15:4a:b2:0d
> Slave queue ID: 0
Working machine:
$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: enp0s25 (primary_reselect always)
Currently Active Slave: enp0s25
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Slave Interface: wlp3s0
MII Status: up
Speed: Unknown
Duplex: Unknown
Link Failure Count: 1
Permanent HW addr: 00:24:d7:7b:1f:24
Slave queue ID: 0
Slave Interface: enp0s25
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:24:d7:7b:1f:24
Slave queue ID: 0
> Current interface config/stats:
>
> $ ifconfig bond0
> bond0: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST> mtu 1500
> inet 10.75.22.245 netmask 255.255.255.0 broadcast
> 10.75.22.255
> inet6 fe80::ee66:b8c9:d55:a28f prefixlen 64 scopeid
> 0x20<link>
> inet6 2001:123:ab:123:d36d:5e5d:acc8:e9bc prefixlen
> 64 scopeid 0x0<global>
> ether 0c:54:15:4a:b2:0d txqueuelen 1000 (Ethernet)
> RX packets 1596206 bytes 165221404 (157.5 MiB)
> RX errors 0 dropped 0 overruns 0 frame 0
> TX packets 1590552 bytes 162689350 (155.1 MiB)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Working machine:
$ ifconfig bond0
bond0: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST> mtu 1500
inet 10.75.22.130 netmask 255.255.255.0 broadcast 10.75.22.255
inet6 2001:470:1d:6f8:b12f:e840:c6a9:8480 prefixlen 64 scopeid 0x0<global>
inet6 fd31:aeb1:48df:0:2374:a2d1:e1b7:89a3 prefixlen 64 scopeid 0x0<global>
inet6 fe80::3dac:5dd4:3c21:421b prefixlen 64 scopeid 0x20<link>
ether 00:24:d7:7b:1f:24 txqueuelen 1000 (Ethernet)
RX packets 40416877 bytes 10615841459 (9.8 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 9040319 bytes 1493391347 (1.3 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
> Devices:
> 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection
> (2) I219-LM (rev 31)
> 02:00.0 Network controller: Intel Corporation Wireless 8265 / 8275
> (rev 78)
Working machine:
00:19.0 Ethernet controller: Intel Corporation 82577LM Gigabit Network Connection (rev 06)
03:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35)
The only real difference I can see is hardware and kernel version. Or
was there something I missed?
Cheers,
b.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 net-next 0/5] ipv6: avoid taking refcnt on dst during route lookup
From: Eric Dumazet @ 2019-06-21 12:33 UTC (permalink / raw)
To: David Ahern
Cc: Wei Wang, David Miller, netdev, Martin KaFai Lau, Mahesh Bandewar,
Wei Wang
In-Reply-To: <b7e58c88-a1d8-323d-caa2-99360ca5144e@gmail.com>
On Thu, Jun 20, 2019 at 8:50 PM David Ahern <dsahern@gmail.com> wrote:
>
> On 6/20/19 6:36 PM, Wei Wang wrote:
> > From: Wei Wang <weiwan@google.com>
> >
> > Ipv6 route lookup code always grabs refcnt on the dst for the caller.
> > But for certain cases, grabbing refcnt is not always necessary if the
> > call path is rcu protected and the caller does not cache the dst.
> > Another issue in the route lookup logic is:
> > When there are multiple custom rules, we have to do the lookup into
> > each table associated to each rule individually. And when we can't
> > find the route in one table, we grab and release refcnt on
> > net->ipv6.ip6_null_entry before going to the next table.
> > This operation is completely redundant, and causes false issue because
> > net->ipv6.ip6_null_entry is a shared object.
> >
> > This patch set introduces a new flag RT6_LOOKUP_F_DST_NOREF for route
> > lookup callers to set, to avoid any manipulation on the dst refcnt. And
> > it converts the major input and output path to use it.
> >
> > The performance gain is noticable.
> > I ran synflood tests between 2 hosts under the same switch. Both hosts
> > have 20G mlx NIC, and 8 tx/rx queues.
> > Sender sends pure SYN flood with random src IPs and ports using trafgen.
> > Receiver has a simple TCP listener on the target port.
> > Both hosts have multiple custom rules:
> > - For incoming packets, only local table is traversed.
> > - For outgoing packets, 3 tables are traversed to find the route.
> > The packet processing rate on the receiver is as follows:
> > - Before the fix: 3.78Mpps
> > - After the fix: 5.50Mpps
> >
>
> LGTM. Thanks for doing this - big improvement.
>
> Reviewed-by: David Ahern <dsahern@gmail.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [RFC bpf-next 0/7] Programming socket lookup with BPF
From: Florian Westphal @ 2019-06-21 12:51 UTC (permalink / raw)
To: Jakub Sitnicki; +Cc: Florian Westphal, netdev, bpf, kernel-team
In-Reply-To: <87sgs6ey43.fsf@cloudflare.com>
Jakub Sitnicki <jakub@cloudflare.com> wrote:
> > So, at least for this part I don't see a technical reason why this
> > has to grab a reference for listener socket.
>
> That's helpful, thanks! We rely on TPROXY, so I would like to help with
> that. Let me see if I can get time to work on it.
AFAICS so far this would be enough:
1. remove the BUG_ON() in skb_orphan, letting it clear skb->sk instead
2. in nf_queue_entry_get_refs(), if skb->sk and no destructor:
call nf_tproxy_assign_sock() so a reference gets taken.
3. change skb_steal_sock:
static inline struct sock *skb_steal_sock(struct sk_buff *skb, bool *refcounted)
[..]
*refcounted = skb->destructor != NULL;
4. make tproxy sk assign elide the destructor assigment in case of
a listening sk.
This should work because TPROXY target is restricted to PRE_ROUTING, and
__netif_receive_skb_core runs with rcu readlock already held.
On a side note, it would also be interesting to see what breaks if the
nf_tproxy_sk_is_transparent() check in the tprox eval function is
removed -- if we need the transparent:1 marker only for output, i think
it would be ok to raise the bit transparently in the kernel in case
we assign skb->sk = found_sk; i.e.
if (unlikely(!sk_is_transparent(sk))
make_sk_transparent(sk);
I don't see a reason why we need the explicit setsockopt(IP_TRANSPARENT)
from userspace.
^ permalink raw reply
* memory leak in llc_ui_create (2)
From: syzbot @ 2019-06-21 12:57 UTC (permalink / raw)
To: davem, linux-kernel, netdev, syzkaller-bugs, xiyou.wangcong
Hello,
syzbot found the following crash on:
HEAD commit: abf02e29 Merge tag 'pm-5.2-rc6' of git://git.kernel.org/pu..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14cc10b1a00000
kernel config: https://syzkaller.appspot.com/x/.config?x=56f1da14935c3cce
dashboard link: https://syzkaller.appspot.com/bug?extid=6bf095f9becf5efef645
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1698d45ea00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+6bf095f9becf5efef645@syzkaller.appspotmail.com
85.529503][ T7031] 8021q: adding VLAN 0 to HW filter on device batadv0
2019/06/20 19:36:46 executed programs: 1
2019/06/20 19:36:51 executed programs: 3
BUG: memory leak
unreferenced object 0xffff888118b8d800 (size 2048):
comm "syz-executor.0", pid 7054, jiffies 4295036362 (age 12.560s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
1a 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............
backtrace:
[<000000004a3a66c0>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000004a3a66c0>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<000000004a3a66c0>] slab_alloc mm/slab.c:3326 [inline]
[<000000004a3a66c0>] __do_kmalloc mm/slab.c:3658 [inline]
[<000000004a3a66c0>] __kmalloc+0x161/0x2c0 mm/slab.c:3669
[<00000000cc5a7d28>] kmalloc include/linux/slab.h:552 [inline]
[<00000000cc5a7d28>] sk_prot_alloc+0xd6/0x170 net/core/sock.c:1602
[<000000000c449f88>] sk_alloc+0x35/0x2f0 net/core/sock.c:1656
[<0000000008b99378>] llc_sk_alloc+0x35/0x170 net/llc/llc_conn.c:950
[<00000000d4e72aed>] llc_ui_create+0x7b/0x140 net/llc/af_llc.c:173
[<00000000d0bfef06>] __sock_create+0x164/0x250 net/socket.c:1424
[<0000000058cf7a3c>] sock_create net/socket.c:1475 [inline]
[<0000000058cf7a3c>] __sys_socket+0x69/0x110 net/socket.c:1517
[<000000003ce548ba>] __do_sys_socket net/socket.c:1526 [inline]
[<000000003ce548ba>] __se_sys_socket net/socket.c:1524 [inline]
[<000000003ce548ba>] __x64_sys_socket+0x1e/0x30 net/socket.c:1524
[<0000000029c8eba9>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<00000000dba589d4>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888120dd7a00 (size 224):
comm "syz-executor.0", pid 7054, jiffies 4295036362 (age 12.560s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 10 0c 24 81 88 ff ff 00 d8 b8 18 81 88 ff ff ...$............
backtrace:
[<00000000b6c096c6>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000b6c096c6>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<00000000b6c096c6>] slab_alloc_node mm/slab.c:3269 [inline]
[<00000000b6c096c6>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<00000000556a01d4>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<0000000085622924>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<0000000085622924>] alloc_skb_with_frags+0x5f/0x250
net/core/skbuff.c:5328
[<00000000ca5b438b>] sock_alloc_send_pskb+0x269/0x2a0
net/core/sock.c:2222
[<0000000044a5b8c6>] sock_alloc_send_skb+0x32/0x40 net/core/sock.c:2239
[<00000000b19d8ca2>] llc_ui_sendmsg+0x10a/0x540 net/llc/af_llc.c:933
[<00000000aaeaeaf3>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<00000000aaeaeaf3>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<000000009ae2ec20>] ___sys_sendmsg+0x393/0x3c0 net/socket.c:2286
[<000000003ac4094d>] __sys_sendmsg+0x80/0xf0 net/socket.c:2324
[<00000000d3b808ba>] __do_sys_sendmsg net/socket.c:2333 [inline]
[<00000000d3b808ba>] __se_sys_sendmsg net/socket.c:2331 [inline]
[<00000000d3b808ba>] __x64_sys_sendmsg+0x23/0x30 net/socket.c:2331
[<0000000029c8eba9>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<00000000dba589d4>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881178e3800 (size 512):
comm "syz-executor.0", pid 7054, jiffies 4295036362 (age 12.560s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 ad ad f3 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000baa5fe0c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000baa5fe0c>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<00000000baa5fe0c>] slab_alloc_node mm/slab.c:3269 [inline]
[<00000000baa5fe0c>] kmem_cache_alloc_node_trace+0x15b/0x2a0
mm/slab.c:3597
[<00000000ef42ca2e>] __do_kmalloc_node mm/slab.c:3619 [inline]
[<00000000ef42ca2e>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3634
[<00000000792340d3>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:138
[<000000003b989a40>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:206
[<0000000085622924>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<0000000085622924>] alloc_skb_with_frags+0x5f/0x250
net/core/skbuff.c:5328
[<00000000ca5b438b>] sock_alloc_send_pskb+0x269/0x2a0
net/core/sock.c:2222
[<0000000044a5b8c6>] sock_alloc_send_skb+0x32/0x40 net/core/sock.c:2239
[<00000000b19d8ca2>] llc_ui_sendmsg+0x10a/0x540 net/llc/af_llc.c:933
[<00000000aaeaeaf3>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<00000000aaeaeaf3>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<000000009ae2ec20>] ___sys_sendmsg+0x393/0x3c0 net/socket.c:2286
[<000000003ac4094d>] __sys_sendmsg+0x80/0xf0 net/socket.c:2324
[<00000000d3b808ba>] __do_sys_sendmsg net/socket.c:2333 [inline]
[<00000000d3b808ba>] __se_sys_sendmsg net/socket.c:2331 [inline]
[<00000000d3b808ba>] __x64_sys_sendmsg+0x23/0x30 net/socket.c:2331
[<0000000029c8eba9>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<00000000dba589d4>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
---
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#status 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
* WARNING in is_bpf_text_address
From: syzbot @ 2019-06-21 12:57 UTC (permalink / raw)
To: ast, bpf, daniel, davem, hawk, jakub.kicinski, john.fastabend,
kafai, linux-kernel, netdev, songliubraving, syzkaller-bugs,
xdp-newbies, yhs
Hello,
syzbot found the following crash on:
HEAD commit: abf02e29 Merge tag 'pm-5.2-rc6' of git://git.kernel.org/pu..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15336041a00000
kernel config: https://syzkaller.appspot.com/x/.config?x=28ec3437a5394ee0
dashboard link: https://syzkaller.appspot.com/bug?extid=bd3bba6ff3fcea7a6ec6
compiler: clang version 9.0.0 (/home/glider/llvm/clang
80fee25776c2fb61e74c1ecb1a523375c2500b69)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14ae828aa00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+bd3bba6ff3fcea7a6ec6@syzkaller.appspotmail.com
WARNING: CPU: 1 PID: 8444 at kernel/bpf/core.c:851 bpf_jit_free+0x1a8/0x1f0
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 8444 Comm: kworker/1:5 Not tainted 5.2.0-rc5+ #4
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1d8/0x2f8 lib/dump_stack.c:113
panic+0x28a/0x7c9 kernel/panic.c:219
BUG: unable to handle page fault for address: fffffbfff400c000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 21ffee067 P4D 21ffee067 PUD 21ffed067 PMD a3fe2067 PTE 0
Oops: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8444 Comm: kworker/1:5 Not tainted 5.2.0-rc5+ #4
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:537 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:600 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find kernel/bpf/core.c:674 [inline]
RIP: 0010:is_bpf_text_address+0x201/0x3b0 kernel/bpf/core.c:709
Code: 25 81 f5 ff 4d 39 f4 76 10 e8 1b 7f f5 ff 49 83 c7 10 eb 46 0f 1f 44
00 00 4c 89 e0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <0f> b6 04 08 84
c0 75 7d 41 8b 1c 24 48 c1 e3 0c 4c 01 e3 48 89 df
RSP: 0018:ffff88808886f758 EFLAGS: 00010806
RAX: 1ffffffff400c000 RBX: 0000000000000001 RCX: dffffc0000000000
RDX: ffff8880961b8680 RSI: ffffffffffffffff RDI: ffffffffa0060000
RBP: ffff88808886f790 R08: ffffffff818032cb R09: ffffed1015d66bf8
R10: ffffed1015d66bf8 R11: 1ffff11015d66bf7 R12: ffffffffa0060000
R13: 0000000000000000 R14: ffffffffffffffff R15: ffff88808914cab8
FS: 0000000000000000(0000) GS:ffff8880aeb00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff400c000 CR3: 00000000a3ba4000 CR4: 00000000001406e0
Call Trace:
BUG: unable to handle page fault for address: fffffbfff400c000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 21ffee067 P4D 21ffee067 PUD 21ffed067 PMD a3fe2067 PTE 0
Oops: 0000 [#2] PREEMPT SMP KASAN
CPU: 1 PID: 8444 Comm: kworker/1:5 Not tainted 5.2.0-rc5+ #4
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:537 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:600 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find kernel/bpf/core.c:674 [inline]
RIP: 0010:is_bpf_text_address+0x201/0x3b0 kernel/bpf/core.c:709
Code: 25 81 f5 ff 4d 39 f4 76 10 e8 1b 7f f5 ff 49 83 c7 10 eb 46 0f 1f 44
00 00 4c 89 e0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <0f> b6 04 08 84
c0 75 7d 41 8b 1c 24 48 c1 e3 0c 4c 01 e3 48 89 df
RSP: 0018:ffff88808886f2e0 EFLAGS: 00010806
RAX: 1ffffffff400c000 RBX: 0000000000000001 RCX: dffffc0000000000
RDX: ffff8880961b8680 RSI: ffffffffffffffff RDI: ffffffffa0060000
RBP: ffff88808886f318 R08: ffffffff818032cb R09: 0000000000000001
R10: ffffffff81811539 R11: 1ffff11015d66bf7 R12: ffffffffa0060000
R13: 0000000000000000 R14: ffffffffffffffff R15: ffff88808914cab8
FS: 0000000000000000(0000) GS:ffff8880aeb00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff400c000 CR3: 00000000a3ba4000 CR4: 00000000001406e0
Call Trace:
BUG: unable to handle page fault for address: fffffbfff400c000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 21ffee067 P4D 21ffee067 PUD 21ffed067 PMD a3fe2067 PTE 0
Oops: 0000 [#3] PREEMPT SMP KASAN
CPU: 1 PID: 8444 Comm: kworker/1:5 Not tainted 5.2.0-rc5+ #4
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:537 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:600 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find kernel/bpf/core.c:674 [inline]
RIP: 0010:is_bpf_text_address+0x201/0x3b0 kernel/bpf/core.c:709
Code: 25 81 f5 ff 4d 39 f4 76 10 e8 1b 7f f5 ff 49 83 c7 10 eb 46 0f 1f 44
00 00 4c 89 e0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <0f> b6 04 08 84
c0 75 7d 41 8b 1c 24 48 c1 e3 0c 4c 01 e3 48 89 df
RSP: 0018:ffff88808886ee60 EFLAGS: 00010806
RAX: 1ffffffff400c000 RBX: 0000000000000001 RCX: dffffc0000000000
RDX: ffff8880961b8680 RSI: ffffffffffffffff RDI: ffffffffa0060000
RBP: ffff88808886ee98 R08: ffffffff818032cb R09: 0000000000000001
R10: ffffffff81811539 R11: 1ffff11015d66bf7 R12: ffffffffa0060000
R13: 0000000000000000 R14: ffffffffffffffff R15: ffff88808914cab8
FS: 0000000000000000(0000) GS:ffff8880aeb00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff400c000 CR3: 00000000a3ba4000 CR4: 00000000001406e0
Call Trace:
BUG: unable to handle page fault for address: fffffbfff400c000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 21ffee067 P4D 21ffee067 PUD 21ffed067 PMD a3fe2067 PTE 0
Oops: 0000 [#4] PREEMPT SMP KASAN
CPU: 1 PID: 8444 Comm: kworker/1:5 Not tainted 5.2.0-rc5+ #4
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:537 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:600 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find kernel/bpf/core.c:674 [inline]
RIP: 0010:is_bpf_text_address+0x201/0x3b0 kernel/bpf/core.c:709
Code: 25 81 f5 ff 4d 39 f4 76 10 e8 1b 7f f5 ff 49 83 c7 10 eb 46 0f 1f 44
00 00 4c 89 e0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <0f> b6 04 08 84
c0 75 7d 41 8b 1c 24 48 c1 e3 0c 4c 01 e3 48 89 df
RSP: 0018:ffff88808886e9e0 EFLAGS: 00010806
RAX: 1ffffffff400c000 RBX: 0000000000000001 RCX: dffffc0000000000
RDX: ffff8880961b8680 RSI: ffffffffffffffff RDI: ffffffffa0060000
RBP: ffff88808886ea18 R08: ffffffff818032cb R09: 0000000000000001
R10: ffffffff81811539 R11: 1ffff11015d66bf7 R12: ffffffffa0060000
R13: 0000000000000000 R14: ffffffffffffffff R15: ffff88808914cab8
FS: 0000000000000000(0000) GS:ffff8880aeb00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff400c000 CR3: 00000000a3ba4000 CR4: 00000000001406e0
Call Trace:
BUG: unable to handle page fault for address: fffffbfff400c000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 21ffee067 P4D 21ffee067 PUD 21ffed067 PMD a3fe2067 PTE 0
Oops: 0000 [#5] PREEMPT SMP KASAN
CPU: 1 PID: 8444 Comm: kworker/1:5 Not tainted 5.2.0-rc5+ #4
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:537 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:600 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find kernel/bpf/core.c:674 [inline]
RIP: 0010:is_bpf_text_address+0x201/0x3b0 kernel/bpf/core.c:709
Code: 25 81 f5 ff 4d 39 f4 76 10 e8 1b 7f f5 ff 49 83 c7 10 eb 46 0f 1f 44
00 00 4c 89 e0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <0f> b6 04 08 84
c0 75 7d 41 8b 1c 24 48 c1 e3 0c 4c 01 e3 48 89 df
RSP: 0018:ffff88808886e560 EFLAGS: 00010806
RAX: 1ffffffff400c000 RBX: 0000000000000001 RCX: dffffc0000000000
RDX: ffff8880961b8680 RSI: ffffffffffffffff RDI: ffffffffa0060000
RBP: ffff88808886e598 R08: ffffffff818032cb R09: 0000000000000001
R10: ffffffff81811539 R11: 1ffff11015d66bf7 R12: ffffffffa0060000
R13: 0000000000000000 R14: ffffffffffffffff R15: ffff88808914cab8
FS: 0000000000000000(0000) GS:ffff8880aeb00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff400c000 CR3: 00000000a3ba4000 CR4: 00000000001406e0
Call Trace:
BUG: unable to handle page fault for address: fffffbfff400c000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 21ffee067 P4D 21ffee067 PUD 21ffed067 PMD a3fe2067 PTE 0
Oops: 0000 [#6] PREEMPT SMP KASAN
CPU: 1 PID: 8444 Comm: kworker/1:5 Not tainted 5.2.0-rc5+ #4
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:537 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:600 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find kernel/bpf/core.c:674 [inline]
RIP: 0010:is_bpf_text_address+0x201/0x3b0 kernel/bpf/core.c:709
Code: 25 81 f5 ff 4d 39 f4 76 10 e8 1b 7f f5 ff 49 83 c7 10 eb 46 0f 1f 44
00 00 4c 89 e0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <0f> b6 04 08 84
c0 75 7d 41 8b 1c 24 48 c1 e3 0c 4c 01 e3 48 89 df
RSP: 0018:ffff88808886e0e0 EFLAGS: 00010806
RAX: 1ffffffff400c000 RBX: 0000000000000001 RCX: dffffc0000000000
RDX: ffff8880961b8680 RSI: ffffffffffffffff RDI: ffffffffa0060000
RBP: ffff88808886e118 R08: ffffffff818032cb R09: 0000000000000001
R10: ffffffff81811539 R11: 1ffff11015d66bf7 R12: ffffffffa0060000
R13: 0000000000000000 R14: ffffffffffffffff R15: ffff88808914cab8
FS: 0000000000000000(0000) GS:ffff8880aeb00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff400c000 CR3: 00000000a3ba4000 CR4: 00000000001406e0
Call Trace:
BUG: unable to handle page fault for address: fffffbfff400c000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 21ffee067 P4D 21ffee067 PUD 21ffed067 PMD a3fe2067 PTE 0
Oops: 0000 [#7] PREEMPT SMP KASAN
CPU: 1 PID: 8444 Comm: kworker/1:5 Not tainted 5.2.0-rc5+ #4
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:537 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:600 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find kernel/bpf/core.c:674 [inline]
RIP: 0010:is_bpf_text_address+0x201/0x3b0 kernel/bpf/core.c:709
Code: 25 81 f5 ff 4d 39 f4 76 10 e8 1b 7f f5 ff 49 83 c7 10 eb 46 0f 1f 44
00 00 4c 89 e0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <0f> b6 04 08 84
c0 75 7d 41 8b 1c 24 48 c1 e3 0c 4c 01 e3 48 89 df
RSP: 0018:ffff88808886dc60 EFLAGS: 00010806
RAX: 1ffffffff400c000 RBX: 0000000000000001 RCX: dffffc0000000000
RDX: ffff8880961b8680 RSI: ffffffffffffffff RDI: ffffffffa0060000
RBP: ffff88808886dc98 R08: ffffffff818032cb R09: 0000000000000001
R10: ffffffff81811539 R11: 1ffff11015d66bf7 R12: ffffffffa0060000
R13: 0000000000000000 R14: ffffffffffffffff R15: ffff88808914cab8
FS: 0000000000000000(0000) GS:ffff8880aeb00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff400c000 CR3: 00000000a3ba4000 CR4: 00000000001406e0
Call Trace:
BUG: unable to handle page fault for address: fffffbfff400c000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 21ffee067 P4D 21ffee067 PUD 21ffed067 PMD a3fe2067 PTE 0
Oops: 0000 [#8] PREEMPT SMP KASAN
CPU: 1 PID: 8444 Comm: kworker/1:5 Not tainted 5.2.0-rc5+ #4
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:537 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:600 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find kernel/bpf/core.c:674 [inline]
RIP: 0010:is_bpf_text_address+0x201/0x3b0 kernel/bpf/core.c:709
Code: 25 81 f5 ff 4d 39 f4 76 10 e8 1b 7f f5 ff 49 83 c7 10 eb 46 0f 1f 44
00 00 4c 89 e0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <0f> b6 04 08 84
c0 75 7d 41 8b 1c 24 48 c1 e3 0c 4c 01 e3 48 89 df
RSP: 0018:ffff88808886d7e0 EFLAGS: 00010806
RAX: 1ffffffff400c000 RBX: 0000000000000001 RCX: dffffc0000000000
RDX: ffff8880961b8680 RSI: ffffffffffffffff RDI: ffffffffa0060000
RBP: ffff88808886d818 R08: ffffffff818032cb R09: 0000000000000001
R10: ffffffff81811539 R11: 1ffff11015d66bf7 R12: ffffffffa0060000
R13: 0000000000000000 R14: ffffffffffffffff R15: ffff88808914cab8
FS: 0000000000000000(0000) GS:ffff8880aeb00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff400c000 CR3: 00000000a3ba4000 CR4: 00000000001406e0
Call Trace:
BUG: unable to handle page fault for address: fffffbfff400c000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 21ffee067 P4D 21ffee067 PUD 21ffed067 PMD a3fe2067 PTE 0
Oops: 0000 [#9] PREEMPT SMP KASAN
CPU: 1 PID: 8444 Comm: kworker/1:5 Not tainted 5.2.0-rc5+ #4
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:537 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:600 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find kernel/bpf/core.c:674 [inline]
RIP: 0010:is_bpf_text_address+0x201/0x3b0 kernel/bpf/core.c:709
Code: 25 81 f5 ff 4d 39 f4 76 10 e8 1b 7f f5 ff 49 83 c7 10 eb 46 0f 1f 44
00 00 4c 89 e0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <0f> b6 04 08 84
c0 75 7d 41 8b 1c 24 48 c1 e3 0c 4c 01 e3 48 89 df
RSP: 0018:ffff88808886d360 EFLAGS: 00010806
RAX: 1ffffffff400c000 RBX: 0000000000000001 RCX: dffffc0000000000
RDX: ffff8880961b8680 RSI: ffffffffffffffff RDI: ffffffffa0060000
RBP: ffff88808886d398 R08: ffffffff818032cb R09: 0000000000000001
R10: ffffffff81811539 R11: 1ffff11015d66bf7 R12: ffffffffa0060000
R13: 0000000000000000 R14: ffffffffffffffff R15: ffff88808914cab8
FS: 0000000000000000(0000) GS:ffff8880aeb00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff400c000 CR3: 00000000a3ba4000 CR4: 00000000001406e0
Call Trace:
BUG: unable to handle page fault for address: fffffbfff400c000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 21ffee067 P4D 21ffee067 PUD 21ffed067 PMD a3fe2067 PTE 0
Oops: 0000 [#10] PREEMPT SMP KASAN
CPU: 1 PID: 8444 Comm: kworker/1:5 Not tainted 5.2.0-rc5+ #4
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:537 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:600 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find kernel/bpf/core.c:674 [inline]
RIP: 0010:is_bpf_text_address+0x201/0x3b0 kernel/bpf/core.c:709
Code: 25 81 f5 ff 4d 39 f4 76 10 e8 1b 7f f5 ff 49 83 c7 10 eb 46 0f 1f 44
00 00 4c 89 e0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <0f> b6 04 08 84
c0 75 7d 41 8b 1c 24 48 c1 e3 0c 4c 01 e3 48 89 df
RSP: 0018:ffff88808886cee0 EFLAGS: 00010806
RAX: 1ffffffff400c000 RBX: 0000000000000001 RCX: dffffc0000000000
RDX: ffff8880961b8680 RSI: ffffffffffffffff RDI: ffffffffa0060000
RBP: ffff88808886cf18 R08: ffffffff818032cb R09: 0000000000000001
R10: ffffffff81811539 R11: 1ffff11015d66bf7 R12: ffffffffa0060000
R13: 0000000000000000 R14: ffffffffffffffff R15: ffff88808914cab8
FS: 0000000000000000(0000) GS:ffff8880aeb00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff400c000 CR3: 00000000a3ba4000 CR4: 00000000001406e0
Call Trace:
BUG: unable to handle page fault for address: fffffbfff400c000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 21ffee067 P4D 21ffee067 PUD 21ffed067 PMD a3fe2067 PTE 0
Oops: 0000 [#11] PREEMPT SMP KASAN
CPU: 1 PID: 8444 Comm: kworker/1:5 Not tainted 5.2.0-rc5+ #4
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:537 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:600 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find kernel/bpf/core.c:674 [inline]
RIP: 0010:is_bpf_text_address+0x201/0x3b0 kernel/bpf/core.c:709
Code: 25 81 f5 ff 4d 39 f4 76 10 e8 1b 7f f5 ff 49 83 c7 10 eb 46 0f 1f 44
00 00 4c 89 e0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <0f> b6 04 08 84
c0 75 7d 41 8b 1c 24 48 c1 e3 0c 4c 01 e3 48 89 df
RSP: 0018:ffff88808886ca60 EFLAGS: 00010806
RAX: 1ffffffff400c000 RBX: 0000000000000001 RCX: dffffc0000000000
RDX: ffff8880961b8680 RSI: ffffffffffffffff RDI: ffffffffa0060000
RBP: ffff88808886ca98 R08: ffffffff818032cb R09: 0000000000000001
R10: ffffffff81811539 R11: 1ffff11015d66bf7 R12: ffffffffa0060000
R13: 0000000000000000 R14: ffffffffffffffff R15: ffff88808914cab8
FS: 0000000000000000(0000) GS:ffff8880aeb00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff400c000 CR3: 00000000a3ba4000 CR4: 00000000001406e0
Call Trace:
BUG: unable to handle page fault for address: fffffbfff400c000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 21ffee067 P4D 21ffee067 PUD 21ffed067 PMD a3fe2067 PTE 0
Oops: 0000 [#12] PREEMPT SMP KASAN
CPU: 1 PID: 8444 Comm: kworker/1:5 Not tainted 5.2.0-rc5+ #4
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events bpf_prog_free_deferred
RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:537 [inline]
RIP: 0010:bpf_tree_comp kernel/bpf/core.c:600 [inline]
RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
RIP: 0010:bpf_prog_kallsyms_find kernel/bpf/core.c:674 [inline]
RIP: 0010:is_bpf_text_address+0x201/0x3b0 kernel/bpf/core.c:709
Code: 25 81 f5 ff 4d 39 f4 76 10 e8 1b 7f f5 ff 49 83 c7 10 eb 46 0f 1f 44
00 00 4c 89 e0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <0f> b6 04 08 84
c0 75 7d 41 8b 1c 24 48 c1 e3 0c 4c 01 e3 48 89 df
RSP: 0018:ffff88808886c5e0 EFLAGS: 00010806
RAX: 1ffffffff400c000 RBX: 0000000000000001 RCX: dffffc0000000000
RDX: ffff8880961b8680 RSI: ffffffffffffffff RDI: ffffffffa0060000
RBP: ffff88808886c618 R08: ffffffff818032cb R09: 0000000000000001
R10: ffffffff81811539 R11: 1ffff11015d66bf7 R12: ffffffffa0060000
R13: 0000000000000000 R14: ffffffffffffffff R15: ffff88808914cab8
FS: 0000000000000000(0000) GS:ffff8880aeb00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff400c000 CR3: 00000000a3ba4000 CR4: 00000000001406e0
Call Trace:
BUG: unable to handle page
---
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#status 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 02/18] ionic: Add hardware init and device commands
From: kbuild test robot @ 2019-06-21 13:03 UTC (permalink / raw)
To: Shannon Nelson; +Cc: kbuild-all, snelson, netdev
In-Reply-To: <20190620202424.23215-3-snelson@pensando.io>
[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]
Hi Shannon,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Shannon-Nelson/ionic-Add-basic-framework-for-IONIC-Network-device-driver/20190621-110046
config: arm-allyesconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
In file included from drivers/net/ethernet/pensando/ionic/ionic_dev.h:11:0,
from drivers/net/ethernet/pensando/ionic/ionic.h:8,
from drivers/net/ethernet/pensando/ionic/ionic_main.c:9:
drivers/net/ethernet/pensando/ionic/ionic_regs.h: In function 'ionic_dbell_ring':
>> drivers/net/ethernet/pensando/ionic/ionic_regs.h:130:2: error: implicit declaration of function 'writeq'; did you mean 'writeb'? [-Werror=implicit-function-declaration]
writeq(val, &db_page[qtype]);
^~~~~~
writeb
cc1: some warnings being treated as errors
vim +130 drivers/net/ethernet/pensando/ionic/ionic_regs.h
127
128 static inline void ionic_dbell_ring(u64 __iomem *db_page, int qtype, u64 val)
129 {
> 130 writeq(val, &db_page[qtype]);
131 }
132
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 70125 bytes --]
^ permalink raw reply
* [PATCH net] tcp: refine memory limit test in tcp_fragment()
From: Eric Dumazet @ 2019-06-21 13:09 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet, Christoph Paasch
tcp_fragment() might be called for skbs in the write queue.
Memory limits might have been exceeded because tcp_sendmsg() only
checks limits at full skb (64KB) boundaries.
Therefore, we need to make sure tcp_fragment() wont punish applications
that might have setup very low SO_SNDBUF values.
Fixes: f070ef2ac667 ("tcp: tcp_fragment() should apply sane memory limits")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Christoph Paasch <cpaasch@apple.com>
---
net/ipv4/tcp_output.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 00c01a01b547ec67c971dc25a74c9258563cf871..0ebc33d1c9e5099d163a234930e213ee35e9fbd1 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1296,7 +1296,8 @@ int tcp_fragment(struct sock *sk, enum tcp_queue tcp_queue,
if (nsize < 0)
nsize = 0;
- if (unlikely((sk->sk_wmem_queued >> 1) > sk->sk_sndbuf)) {
+ if (unlikely((sk->sk_wmem_queued >> 1) > sk->sk_sndbuf &&
+ tcp_queue != TCP_FRAG_IN_WRITE_QUEUE)) {
NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPWQUEUETOOBIG);
return -ENOMEM;
}
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* Re: [PATCH v3 0/5] net: macb: cover letter
From: Andrew Lunn @ 2019-06-21 13:16 UTC (permalink / raw)
To: Parshuram Thombare
Cc: nicolas.ferre, davem, f.fainelli, linux, netdev, hkallweit1,
linux-kernel, rafalc, aniljoy, piotrs
In-Reply-To: <1561106037-6859-1-git-send-email-pthombar@cadence.com>
On Fri, Jun 21, 2019 at 09:33:57AM +0100, Parshuram Thombare wrote:
> Hello !
>
> 2. 0002-net-macb-add-support-for-sgmii-MAC-PHY-interface.patch
> This patch add support for SGMII mode.
Hi Parshuram
What PHYs are using to test this? You mention TI PHY DP83867, but that
seems to be a plain old 10/100/1000 RGMII PHY.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH v3 3/5] net: macb: add support for c45 PHY
From: Andrew Lunn @ 2019-06-21 13:17 UTC (permalink / raw)
To: Parshuram Thombare
Cc: nicolas.ferre, davem, f.fainelli, linux, netdev, hkallweit1,
linux-kernel, rafalc, aniljoy, piotrs
In-Reply-To: <1561106099-8803-1-git-send-email-pthombar@cadence.com>
On Fri, Jun 21, 2019 at 09:34:59AM +0100, Parshuram Thombare wrote:
> This patch modify MDIO read/write functions to support
> communication with C45 PHY.
>
> Signed-off-by: Parshuram Thombare <pthombar@cadence.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v3 1/5] net: macb: add phylink support
From: Russell King - ARM Linux admin @ 2019-06-21 13:29 UTC (permalink / raw)
To: Parshuram Thombare
Cc: andrew, nicolas.ferre, davem, f.fainelli, netdev, hkallweit1,
linux-kernel, rafalc, aniljoy, piotrs
In-Reply-To: <1561106084-8241-1-git-send-email-pthombar@cadence.com>
On Fri, Jun 21, 2019 at 09:34:44AM +0100, Parshuram Thombare wrote:
> @@ -438,115 +439,145 @@ static void macb_set_tx_clk(struct clk *clk, int speed, struct net_device *dev)
> netdev_err(dev, "adjusting tx_clk failed.\n");
> }
>
> -static void macb_handle_link_change(struct net_device *dev)
> +static void gem_phylink_validate(struct phylink_config *pl_config,
> + unsigned long *supported,
> + struct phylink_link_state *state)
> {
> - struct macb *bp = netdev_priv(dev);
> - struct phy_device *phydev = dev->phydev;
> - unsigned long flags;
> - int status_change = 0;
> + struct net_device *netdev = to_net_dev(pl_config->dev);
> + struct macb *bp = netdev_priv(netdev);
> + __ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
> +
> + switch (state->interface) {
> + case PHY_INTERFACE_MODE_GMII:
> + case PHY_INTERFACE_MODE_RGMII:
> + if (bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE) {
> + phylink_set(mask, 1000baseT_Full);
> + phylink_set(mask, 1000baseX_Full);
> + if (!(bp->caps & MACB_CAPS_NO_GIGABIT_HALF)) {
> + phylink_set(mask, 1000baseT_Half);
> + phylink_set(mask, 1000baseT_Half);
> + }
> + }
> + /* fallthrough */
> + case PHY_INTERFACE_MODE_MII:
> + case PHY_INTERFACE_MODE_RMII:
> + phylink_set(mask, 10baseT_Half);
> + phylink_set(mask, 10baseT_Full);
> + phylink_set(mask, 100baseT_Half);
> + phylink_set(mask, 100baseT_Full);
> + break;
> + default:
> + break;
PHY_INTERFACE_MODE_NA is used to ascertain the _full_ set of support
from the MAC irrespective of interface mode, so that (eg) SFPs can
select an appropriate interface mode from the subset of capabililties
supported by the SFP and MAC.
Also note this behaviour for MACs that support switching between
2500BASE-X and 1000BASE-X (which are fixed speed BASE-X):
static void mvneta_validate(struct net_device *ndev, unsigned long *supported,
struct phylink_link_state *state)
{
...
/* Half-duplex at speeds higher than 100Mbit is unsupported */
if (pp->comphy || state->interface != PHY_INTERFACE_MODE_2500BASEX) {
phylink_set(mask, 1000baseT_Full);
phylink_set(mask, 1000baseX_Full);
}
if (pp->comphy || state->interface == PHY_INTERFACE_MODE_2500BASEX) {
phylink_set(mask, 2500baseT_Full);
phylink_set(mask, 2500baseX_Full);
}
The idea here is that _if_ we have a comphy, we can reprogram the comphy
to select between 1G and 2.5G speeds. So we offer both 1G and 2.5G
capabilities irrespective of interface mode.
When the interface type is set in mvneta_mac_config(), the comphy is
configured for the link mode, including setting the link speed to either
1.25Gbaud or 3.125Gbaud.
So, the speed of the serdes lane is determined by the selected
PHY_INTERFACE_MODE.
There is additional logic in the mvneta_validate() method to deal with
the selection of 1G and 2.5G modes for BASE-X:
/* We can only operate at 2500BaseX or 1000BaseX. If requested
* to advertise both, only report advertising at 2500BaseX.
*/
phylink_helper_basex_speed(state);
What this does is clear state->advertising, ensuring that only one of
2500BASE_X or 1000BASE_X is shown, and also sets state->interface in
the validate callback accordingly to select the interface mode.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* [PATCH] net/sched: cbs: Fix error path of cbs_module_init
From: YueHaibing @ 2019-06-21 13:44 UTC (permalink / raw)
To: jhs, xiyou.wangcong, jiri, davem; +Cc: linux-kernel, netdev, YueHaibing
If register_qdisc fails, we should unregister
netdevice notifier.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: e0a7683d30e9 ("net/sched: cbs: fix port_rate miscalculation")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
net/sched/sch_cbs.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/net/sched/sch_cbs.c b/net/sched/sch_cbs.c
index e16a3d3..4e1a878 100644
--- a/net/sched/sch_cbs.c
+++ b/net/sched/sch_cbs.c
@@ -549,12 +549,17 @@ static struct notifier_block cbs_device_notifier = {
static int __init cbs_module_init(void)
{
- int err = register_netdevice_notifier(&cbs_device_notifier);
+ int err;
+ err = register_netdevice_notifier(&cbs_device_notifier);
if (err)
return err;
- return register_qdisc(&cbs_qdisc_ops);
+ err = register_qdisc(&cbs_qdisc_ops);
+ if (err)
+ unregister_netdevice_notifier(&cbs_device_notifier);
+
+ return err;
}
static void __exit cbs_module_exit(void)
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 09/29] docs: driver-model: convert docs to ReST and rename to *.rst
From: Greg Kroah-Hartman @ 2019-06-21 13:47 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Linus Walleij, Bartosz Golaszewski, Jean Delvare,
Guenter Roeck, Rafael J. Wysocki, Jeff Kirsher, David S. Miller,
Julia Lawall, Gilles Muller, Nicolas Palix, Michal Marek,
linux-gpio, linux-hwmon, intel-wired-lan, netdev, cocci
In-Reply-To: <0ac41c7d682452cdbd867c4ae7729b6b34d79c0b.1560890800.git.mchehab+samsung@kernel.org>
On Tue, Jun 18, 2019 at 05:53:27PM -0300, Mauro Carvalho Chehab wrote:
> Convert the various documents at the driver-model, preparing
> them to be part of the driver-api book.
>
> The conversion is actually:
> - add blank lines and identation in order to identify paragraphs;
> - fix tables markups;
> - add some lists markups;
> - mark literal blocks;
> - adjust title markups.
>
> At its new index.rst, let's add a :orphan: while this is not linked to
> the main index.rst file, in order to avoid build warnings.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> # ice
Now applied, thanks.
greg k-h
^ permalink raw reply
* Re: Stats for XDP actions
From: Toke Høiland-Jørgensen @ 2019-06-21 13:57 UTC (permalink / raw)
To: David Ahern, Jesper Dangaard Brouer
Cc: David Miller, mst, makita.toshiaki, jasowang, netdev,
virtualization, hawk, Jakub Kicinski, John Fastabend,
Daniel Borkmann, Saeed Mahameed, Tariq Toukan
In-Reply-To: <cd9136ff-4127-72a5-0857-2e5641ba5252@gmail.com>
David Ahern <dsahern@gmail.com> writes:
> On 6/20/19 2:42 PM, Toke Høiland-Jørgensen wrote:
>>>> I don't recall seeing any follow-up on this. Did you have a chance to
>>>> formulate your ideas? :)
>>>>
>>>
>>> Not yet. Almost done with the nexthop changes. Once that is out of the
>>> way I can come back to this.
>>
>> Ping? :)
>>
>
> Definitely back to this after the July 4th holiday.
Awesome! I'll wait until then before bugging you again... ;)
-Toke
^ permalink raw reply
* Re: [PATCH v3 0/3] net: fddi: skfp: Use PCI generic definitions instead of private duplicates
From: Bjorn Helgaas @ 2019-06-21 14:05 UTC (permalink / raw)
To: Puranjay Mohan
Cc: Shuah Khan, Bjorn Helgaas, netdev, Linux Kernel Mailing List,
linux-kernel-mentees, linux-pci, Stephen Hemminger
In-Reply-To: <20190621094607.15011-1-puranjay12@gmail.com>
[+cc Stephen]
On Fri, Jun 21, 2019 at 03:16:04PM +0530, Puranjay Mohan wrote:
> This patch series removes the private duplicates of PCI definitions in
> favour of generic definitions defined in pci_regs.h.
>
> This driver only uses some of the generic PCI definitons,
> which are included from pci_regs.h and thier private versions
> are removed from skfbi.h with all other private defines.
>
> The skfbi.h defines PCI_REV_ID and other private defines with different
> names, these are renamed to Generic PCI names to make them
> compatible with defines in pci_regs.h.
>
> All unused defines are removed from skfbi.h.
>
> Puranjay Mohan (3):
> net: fddi: skfp: Rename local PCI defines to match generic PCI defines
> net: fddi: skfp: Include generic PCI definitions
> net: fddi: skfp: Remove unused private PCI definitions
>
> drivers/net/fddi/skfp/drvfbi.c | 3 +-
> drivers/net/fddi/skfp/h/skfbi.h | 80 +--------------------------------
> 2 files changed, 4 insertions(+), 79 deletions(-)
It's good form to CC people who have commented on previous versions of
your series, so I added Stephen.
FWIW,
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
^ permalink raw reply
* Re: [RFC bpf-next 0/7] Programming socket lookup with BPF
From: Eric Dumazet @ 2019-06-21 14:33 UTC (permalink / raw)
To: Florian Westphal, Jakub Sitnicki; +Cc: netdev, bpf, kernel-team
In-Reply-To: <20190621125155.2sdw7pugepj3ityx@breakpoint.cc>
On 6/21/19 5:51 AM, Florian Westphal wrote:
> Jakub Sitnicki <jakub@cloudflare.com> wrote:
>>> So, at least for this part I don't see a technical reason why this
>>> has to grab a reference for listener socket.
>>
>> That's helpful, thanks! We rely on TPROXY, so I would like to help with
>> that. Let me see if I can get time to work on it.
>
> AFAICS so far this would be enough:
>
> 1. remove the BUG_ON() in skb_orphan, letting it clear skb->sk instead
> 2. in nf_queue_entry_get_refs(), if skb->sk and no destructor:
> call nf_tproxy_assign_sock() so a reference gets taken.
> 3. change skb_steal_sock:
> static inline struct sock *skb_steal_sock(struct sk_buff *skb, bool *refcounted)
> [..]
> *refcounted = skb->destructor != NULL;
> 4. make tproxy sk assign elide the destructor assigment in case of
> a listening sk.
>
Okay, but how do we make sure the skb->sk association does not leak from rcu section ?
Note we have the noref/refcounted magic for skb_dst(), we might try to use something similar
for skb->sk
> This should work because TPROXY target is restricted to PRE_ROUTING, and
> __netif_receive_skb_core runs with rcu readlock already held.
>
> On a side note, it would also be interesting to see what breaks if the
> nf_tproxy_sk_is_transparent() check in the tprox eval function is
> removed -- if we need the transparent:1 marker only for output, i think
> it would be ok to raise the bit transparently in the kernel in case
> we assign skb->sk = found_sk; i.e.
> if (unlikely(!sk_is_transparent(sk))
> make_sk_transparent(sk);
>
> I don't see a reason why we need the explicit setsockopt(IP_TRANSPARENT)
> from userspace.
>
^ permalink raw reply
* [PATCH net-next 1/4] cxgb4: Re-work the logic for mps refcounting
From: Raju Rangoju @ 2019-06-21 14:36 UTC (permalink / raw)
To: netdev, davem; +Cc: nirranjan, dt, rajur
In-Reply-To: <20190621143636.20422-1-rajur@chelsio.com>
Remove existing mps refcounting code which was
added only for encap filters and add necessary
data structures/functions to support mps reference
counting for all the mac filters. Also add wrapper
functions for allocating and freeing encap mac
filters.
Signed-off-by: Raju Rangoju <rajur@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/Makefile | 2 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 24 ++++-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c | 8 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 14 +--
drivers/net/ethernet/chelsio/cxgb4/cxgb4_mps.c | 109 ++++++++++++++++++++++
5 files changed, 135 insertions(+), 22 deletions(-)
create mode 100644 drivers/net/ethernet/chelsio/cxgb4/cxgb4_mps.c
diff --git a/drivers/net/ethernet/chelsio/cxgb4/Makefile b/drivers/net/ethernet/chelsio/cxgb4/Makefile
index 91d8a88..20390f6 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/Makefile
+++ b/drivers/net/ethernet/chelsio/cxgb4/Makefile
@@ -7,7 +7,7 @@ obj-$(CONFIG_CHELSIO_T4) += cxgb4.o
cxgb4-objs := cxgb4_main.o l2t.o smt.o t4_hw.o sge.o clip_tbl.o cxgb4_ethtool.o \
cxgb4_uld.o srq.o sched.o cxgb4_filter.o cxgb4_tc_u32.o \
- cxgb4_ptp.o cxgb4_tc_flower.o cxgb4_cudbg.o \
+ cxgb4_ptp.o cxgb4_tc_flower.o cxgb4_cudbg.o cxgb4_mps.o \
cudbg_common.o cudbg_lib.o cudbg_zlib.o
cxgb4-$(CONFIG_CHELSIO_T4_DCB) += cxgb4_dcb.o
cxgb4-$(CONFIG_CHELSIO_T4_FCOE) += cxgb4_fcoe.o
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index db2ec46..937815d 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -905,10 +905,6 @@ struct mbox_list {
struct list_head list;
};
-struct mps_encap_entry {
- atomic_t refcnt;
-};
-
#if IS_ENABLED(CONFIG_THERMAL)
struct ch_thermal {
struct thermal_zone_device *tzdev;
@@ -917,6 +913,14 @@ struct ch_thermal {
};
#endif
+struct mps_entries_ref {
+ struct list_head list;
+ u8 addr[ETH_ALEN];
+ u8 mask[ETH_ALEN];
+ u16 idx;
+ atomic_t refcnt;
+};
+
struct adapter {
void __iomem *regs;
void __iomem *bar2;
@@ -969,7 +973,6 @@ struct adapter {
unsigned int rawf_start;
unsigned int rawf_cnt;
struct smt_data *smt;
- struct mps_encap_entry *mps_encap;
struct cxgb4_uld_info *uld;
void *uld_handle[CXGB4_ULD_MAX];
unsigned int num_uld;
@@ -977,6 +980,8 @@ struct adapter {
struct list_head list_node;
struct list_head rcu_node;
struct list_head mac_hlist; /* list of MAC addresses in MPS Hash */
+ struct list_head mps_ref;
+ spinlock_t mps_ref_lock; /* lock for syncing mps ref/def activities */
void *iscsi_ppm;
@@ -1906,4 +1911,13 @@ int cxgb4_set_msix_aff(struct adapter *adap, unsigned short vec,
cpumask_var_t *aff_mask, int idx);
void cxgb4_clear_msix_aff(unsigned short vec, cpumask_var_t aff_mask);
+int cxgb4_init_mps_ref_entries(struct adapter *adap);
+void cxgb4_free_mps_ref_entries(struct adapter *adap);
+int cxgb4_alloc_encap_mac_filt(struct adapter *adap, unsigned int viid,
+ const u8 *addr, const u8 *mask,
+ unsigned int vni, unsigned int vni_mask,
+ u8 dip_hit, u8 lookup_type, bool sleep_ok);
+int cxgb4_free_encap_mac_filt(struct adapter *adap, unsigned int viid,
+ int idx, bool sleep_ok);
+
#endif /* __CXGB4_H__ */
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
index 6232236..43b0f8c 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
@@ -727,10 +727,8 @@ void clear_filter(struct adapter *adap, struct filter_entry *f)
cxgb4_smt_release(f->smt);
if (f->fs.val.encap_vld && f->fs.val.ovlan_vld)
- if (atomic_dec_and_test(&adap->mps_encap[f->fs.val.ovlan &
- 0x1ff].refcnt))
- t4_free_encap_mac_filt(adap, pi->viid,
- f->fs.val.ovlan & 0x1ff, 0);
+ t4_free_encap_mac_filt(adap, pi->viid,
+ f->fs.val.ovlan & 0x1ff, 0);
if ((f->fs.hash || is_t6(adap->params.chip)) && f->fs.type)
cxgb4_clip_release(f->dev, (const u32 *)&f->fs.val.lip, 1);
@@ -1177,7 +1175,6 @@ static int cxgb4_set_hash_filter(struct net_device *dev,
if (ret < 0)
goto free_atid;
- atomic_inc(&adapter->mps_encap[ret].refcnt);
f->fs.val.ovlan = ret;
f->fs.mask.ovlan = 0xffff;
f->fs.val.ovlan_vld = 1;
@@ -1420,7 +1417,6 @@ int __cxgb4_set_filter(struct net_device *dev, int filter_id,
if (ret < 0)
goto free_clip;
- atomic_inc(&adapter->mps_encap[ret].refcnt);
f->fs.val.ovlan = ret;
f->fs.mask.ovlan = 0x1ff;
f->fs.val.ovlan_vld = 1;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 5490800..4632827 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -3273,8 +3273,6 @@ static void cxgb_del_udp_tunnel(struct net_device *netdev,
i);
return;
}
- atomic_dec(&adapter->mps_encap[adapter->rawf_start +
- pi->port_id].refcnt);
}
}
@@ -3363,7 +3361,6 @@ static void cxgb_add_udp_tunnel(struct net_device *netdev,
cxgb_del_udp_tunnel(netdev, ti);
return;
}
- atomic_inc(&adapter->mps_encap[ret].refcnt);
}
}
@@ -5446,7 +5443,6 @@ static void free_some_resources(struct adapter *adapter)
{
unsigned int i;
- kvfree(adapter->mps_encap);
kvfree(adapter->smt);
kvfree(adapter->l2t);
kvfree(adapter->srq);
@@ -5972,12 +5968,6 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
adapter->params.offload = 0;
}
- adapter->mps_encap = kvcalloc(adapter->params.arch.mps_tcam_size,
- sizeof(struct mps_encap_entry),
- GFP_KERNEL);
- if (!adapter->mps_encap)
- dev_warn(&pdev->dev, "could not allocate MPS Encap entries, continuing\n");
-
#if IS_ENABLED(CONFIG_IPV6)
if (chip_ver <= CHELSIO_T5 &&
(!(t4_read_reg(adapter, LE_DB_CONFIG_A) & ASLIPCOMPEN_F))) {
@@ -6053,6 +6043,8 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
/* check for PCI Express bandwidth capabiltites */
pcie_print_link_status(pdev);
+ cxgb4_init_mps_ref_entries(adapter);
+
err = init_rss(adapter);
if (err)
goto out_free_dev;
@@ -6179,6 +6171,8 @@ static void remove_one(struct pci_dev *pdev)
disable_interrupts(adapter);
+ cxgb4_free_mps_ref_entries(adapter);
+
for_each_port(adapter, i)
if (adapter->port[i]->reg_state == NETREG_REGISTERED)
unregister_netdev(adapter->port[i]);
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_mps.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_mps.c
new file mode 100644
index 0000000..8b3a61a
--- /dev/null
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_mps.c
@@ -0,0 +1,109 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2019 Chelsio Communications, Inc. All rights reserved. */
+
+#include "cxgb4.h"
+
+static int cxgb4_mps_ref_dec(struct adapter *adap, u16 idx)
+{
+ struct mps_entries_ref *mps_entry, *tmp;
+ int ret = -EINVAL;
+
+ spin_lock(&adap->mps_ref_lock);
+ list_for_each_entry_safe(mps_entry, tmp, &adap->mps_ref, list) {
+ if (mps_entry->idx == idx) {
+ if (!atomic_dec_and_test(&mps_entry->refcnt)) {
+ spin_unlock(&adap->mps_ref_lock);
+ return -EBUSY;
+ }
+ list_del(&mps_entry->list);
+ kfree(mps_entry);
+ ret = 0;
+ break;
+ }
+ }
+ spin_unlock(&adap->mps_ref_lock);
+ return ret;
+}
+
+static int cxgb4_mps_ref_inc(struct adapter *adap, const u8 *mac_addr,
+ u16 idx, const u8 *mask)
+{
+ u8 bitmask[] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
+ struct mps_entries_ref *mps_entry;
+ int ret = 0;
+
+ spin_lock_bh(&adap->mps_ref_lock);
+ list_for_each_entry(mps_entry, &adap->mps_ref, list) {
+ if (mps_entry->idx == idx) {
+ atomic_inc(&mps_entry->refcnt);
+ goto unlock;
+ }
+ }
+ mps_entry = kzalloc(sizeof(*mps_entry), GFP_ATOMIC);
+ if (!mps_entry) {
+ ret = -ENOMEM;
+ goto unlock;
+ }
+ ether_addr_copy(mps_entry->mask, mask ? mask : bitmask);
+ ether_addr_copy(mps_entry->addr, mac_addr);
+ mps_entry->idx = idx;
+ atomic_inc(&mps_entry->refcnt);
+ list_add_tail(&mps_entry->list, &adap->mps_ref);
+unlock:
+ spin_unlock_bh(&adap->mps_ref_lock);
+ return ret;
+}
+
+int cxgb4_free_encap_mac_filt(struct adapter *adap, unsigned int viid,
+ int idx, bool sleep_ok)
+{
+ int ret = 0;
+
+ if (!cxgb4_mps_ref_dec(adap, idx))
+ ret = t4_free_encap_mac_filt(adap, viid, idx, sleep_ok);
+
+ return ret;
+}
+
+int cxgb4_alloc_encap_mac_filt(struct adapter *adap, unsigned int viid,
+ const u8 *addr, const u8 *mask,
+ unsigned int vni, unsigned int vni_mask,
+ u8 dip_hit, u8 lookup_type, bool sleep_ok)
+{
+ int ret;
+
+ ret = t4_alloc_encap_mac_filt(adap, viid, addr, mask, vni, vni_mask,
+ dip_hit, lookup_type, sleep_ok);
+ if (ret < 0)
+ return ret;
+
+ if (cxgb4_mps_ref_inc(adap, addr, ret, mask)) {
+ ret = -ENOMEM;
+ t4_free_encap_mac_filt(adap, viid, ret, sleep_ok);
+ }
+ return ret;
+}
+
+int cxgb4_init_mps_ref_entries(struct adapter *adap)
+{
+ spin_lock_init(&adap->mps_ref_lock);
+ INIT_LIST_HEAD(&adap->mps_ref);
+
+ return 0;
+}
+
+void cxgb4_free_mps_ref_entries(struct adapter *adap)
+{
+ struct mps_entries_ref *mps_entry, *tmp;
+
+ if (!list_empty(&adap->mps_ref))
+ return;
+
+ spin_lock(&adap->mps_ref_lock);
+ list_for_each_entry_safe(mps_entry, tmp, &adap->mps_ref, list) {
+ list_del(&mps_entry->list);
+ kfree(mps_entry);
+ }
+ spin_unlock(&adap->mps_ref_lock);
+}
+
--
1.8.3.1
^ permalink raw reply related
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