* Re: [PATCH net-next 0/2] net: bridge: MTU handling changes
From: David Miller @ 2018-04-01 2:05 UTC (permalink / raw)
To: nikolay; +Cc: netdev, roopa, makita.toshiaki, 3chas3, stephen, bridge
In-Reply-To: <20180330104619.31479-1-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Fri, 30 Mar 2018 13:46:17 +0300
> As previously discussed the recent changes break some setups and could lead
> to packet drops. Thus the first patch reverts the behaviour for the bridge
> to follow the minimum MTU but also keeps the ability to set the MTU to the
> maximum (out of all ports) if vlan filtering is enabled. Patch 02 is the
> bigger change in behaviour - we've always had trouble when configuring
> bridges and their MTU which is auto tuning on port events
> (add/del/changemtu), which means config software needs to chase it and fix
> it after each such event, after patch 02 we allow the user to configure any
> MTU (ETH_MIN/MAX limited) but once that is done the bridge stops auto
> tuning and relies on the user to keep the MTU correct.
> This should be compatible with cases that don't touch the MTU (or set it
> to the same value), while allowing to configure the MTU and not worry
> about it changing afterwards.
>
> The patches are intentionally split like this, so that if they get accepted
> and there are any complaints patch 02 can be reverted.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/4] Introduce adaptive TX interrupt moderation to net DIM
From: David Miller @ 2018-04-01 2:02 UTC (permalink / raw)
To: talgi; +Cc: netdev, tariqt, andrew.gospodarek, saeedm
In-Reply-To: <1522391853-37298-1-git-send-email-talgi@mellanox.com>
From: Tal Gilboa <talgi@mellanox.com>
Date: Fri, 30 Mar 2018 09:37:29 +0300
> Net DIM is a library designed for dynamic interrupt moderation. It was
> implemented and optimized with receive side interrupts in mind, since these
> are usually the CPU expensive ones. This patch-set introduces adaptive transmit
> interrupt moderation to net DIM, complete with a usage in the mlx5e driver.
> Using adaptive TX behavior would reduce interrupt rate for multiple scenarios.
> Furthermore, it is essential for increasing bandwidth on cases where payload
> aggregation is required.
Series applied.
^ permalink raw reply
* Re: [net-next v2 0/5] tipc: slim down name table
From: David Miller @ 2018-04-01 1:58 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, mohan.krishna.ghanta.krishnamurthy, tung.q.nguyen,
hoang.h.le, canh.d.luu, ying.xue, tipc-discussion
In-Reply-To: <1522358445-7444-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Thu, 29 Mar 2018 23:20:40 +0200
> We clean up and improve the name binding table:
>
> - Replace the memory consuming 'sub_sequence/service range' array with
> an RB tree.
> - Introduce support for overlapping service sequences/ranges
>
> v2: #1: Fixed a missing initialization reported by David Miller
> #4: Obsoleted and replaced a few more macros to get a consistent
> terminology in the API.
> #5: Added new commit to fix a potential string overflow bug (it
> is still only in net-next) reported by Arnd Bergmann
Series applied, thanks Jon.
^ permalink raw reply
* Re: [PATCH net-next v1 0/2] Meson8m2 support for dwmac-meson8b
From: David Miller @ 2018-04-01 1:57 UTC (permalink / raw)
To: martin.blumenstingl
Cc: robh+dt, mark.rutland, netdev, linux-amlogic, carlo, khilman
In-Reply-To: <20180329230035.20958-1-martin.blumenstingl@googlemail.com>
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date: Fri, 30 Mar 2018 01:00:33 +0200
> The Meson8m2 SoC is an updated version of the Meson8 SoC. Some of the
> peripherals are shared with Meson8b (for example the watchdog registers
> and the internal temperature sensor calibration procedure).
> Meson8m2 also seems to include the same Gigabit MAC register layout as
> Meson8b.
>
> The registers in the Amlogic dwmac "glue" seem identical between Meson8b
> and Meson8m2. Manual testing seems to confirm this.
>
> To be extra-safe a new compatible string is added because there's no
> (public) documentation on the Meson8m2 SoC. This will allow us to
> implement any SoC-specific variations later on (if needed).
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next 00/11] mlxsw: Various cleanups
From: David Miller @ 2018-04-01 1:54 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, petrm, mlxsw
In-Reply-To: <20180329203334.25575-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Thu, 29 Mar 2018 23:33:23 +0300
> The first 10 patches from Jiri perform small and unrelated cleanups. The
> largest being the conversion of the KVD linear partitions from a list to
> an array, which simplifies the code.
>
> The last patch from Petr is a bug fix for a recent net-next commit that
> prevented the "kvd" resource from being marked as the parent of its
> various child resources (e.g., "/kvd/linear").
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: phy: marvell10g: add thermal hwmon device
From: David Miller @ 2018-04-01 1:50 UTC (permalink / raw)
To: rmk+kernel; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <E1f18Bu-0005CL-O4@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Wed, 28 Mar 2018 11:20:26 +0100
> +
> /*
> * Resetting the MV88X3310 causes it to become non-responsive. Avoid
> * setting the reset bit(s).
This comment doesn't exist in the net-next copy of this file.
^ permalink raw reply
* [RFC PATCH] vmcore: __vmcore_add_device_dump() can be static
From: kbuild test robot @ 2018-04-01 0:32 UTC (permalink / raw)
To: Rahul Lakkireddy
Cc: kbuild-all, netdev, kexec, linux-fsdevel, linux-kernel, davem,
viro, ebiederm, stephen, akpm, torvalds, ganeshgr, nirranjan,
indranil, Rahul Lakkireddy
In-Reply-To: <194d1e289b385f2cbd4cb2c2569af93723a9cfb8.1522483891.git.rahul.lakkireddy@chelsio.com>
Fixes: 6bf7e2b7f850 ("vmcore: add API to collect hardware dump in second kernel")
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
vmcore.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index b53698f..fe788dd 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc/vmcore.c
@@ -1196,7 +1196,7 @@ static void vmcoredd_write_note(const char *name, void *buf, size_t size)
* Write Elf note at the beginning of the buffer to indicate vmcore device
* dump and add the dump to global list.
*/
-int __vmcore_add_device_dump(struct vmcoredd_data *data)
+static int __vmcore_add_device_dump(struct vmcoredd_data *data)
{
size_t note_size, data_size;
struct vmcoredd_node *dump;
^ permalink raw reply related
* Re: [PATCH net-next v3 1/3] vmcore: add API to collect hardware dump in second kernel
From: kbuild test robot @ 2018-04-01 0:32 UTC (permalink / raw)
To: Rahul Lakkireddy
Cc: kbuild-all, netdev, kexec, linux-fsdevel, linux-kernel, davem,
viro, ebiederm, stephen, akpm, torvalds, ganeshgr, nirranjan,
indranil, Rahul Lakkireddy
In-Reply-To: <194d1e289b385f2cbd4cb2c2569af93723a9cfb8.1522483891.git.rahul.lakkireddy@chelsio.com>
Hi Rahul,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Rahul-Lakkireddy/kernel-add-support-to-collect-hardware-logs-in-crash-recovery-kernel/20180401-060904
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> fs/proc/vmcore.c:1199:5: sparse: symbol '__vmcore_add_device_dump' was not declared. Should it be static?
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 net-next v3 3/3] cxgb4: collect hardware dump in second kernel
From: kbuild test robot @ 2018-04-01 0:19 UTC (permalink / raw)
To: Rahul Lakkireddy
Cc: kbuild-all, netdev, kexec, linux-fsdevel, linux-kernel, davem,
viro, ebiederm, stephen, akpm, torvalds, ganeshgr, nirranjan,
indranil, Rahul Lakkireddy
In-Reply-To: <302fb326d8d15d64b5ef85471df40635f25cc890.1522483891.git.rahul.lakkireddy@chelsio.com>
[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]
Hi Rahul,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Rahul-Lakkireddy/kernel-add-support-to-collect-hardware-logs-in-crash-recovery-kernel/20180401-060904
config: tile-allyesconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 7.2.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
make.cross ARCH=tile
All errors (new ones prefixed by >>):
`.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
`.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
`.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
`.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
`.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
`.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.o: In function `cxgb4_cudbg_vmcore_add_dump':
>> (.text+0xed0): undefined reference to `vmcore_add_device_dump'
drivers/net/wireless/mediatek/mt76/mac80211.o: In function `mt76_init_stream_cap.isra.1':
mac80211.c:(.text+0x8a8): undefined reference to `__sw_hweight8'
---
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: 51825 bytes --]
^ permalink raw reply
* Re: [PATCH 02/12] treewide/net: Rename eth_stp_addr to ether_stp_addr
From: kbuild test robot @ 2018-04-01 0:18 UTC (permalink / raw)
To: Joe Perches
Cc: kbuild-all, Andrew Lunn, Vivien Didelot, Florian Fainelli,
Stephen Hemminger, David S. Miller, netdev, linux-kernel, bridge
In-Reply-To: <a2d52bbcdcd36c5062bd4fa175df15acd5f8cb85.1522479607.git.joe@perches.com>
[-- Attachment #1: Type: text/plain, Size: 1434 bytes --]
Hi Joe,
I love your patch! Yet something to improve:
[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on v4.16-rc7 next-20180329]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Joe-Perches/Ethernet-Add-and-use-ether_-type-_addr-globals/20180401-072030
base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git master
config: i386-randconfig-x009-201813 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
In file included from include/linux/kernel.h:6:0,
from net//bridge/br_device.c:14:
>> /usr/lib/gcc/x86_64-linux-gnu/7/include/stdarg.h:40:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'typedef'
typedef __builtin_va_list __gnuc_va_list;
^~~~~~~
In file included from include/linux/kernel.h:6:0,
from net//bridge/br_device.c:14:
>> /usr/lib/gcc/x86_64-linux-gnu/7/include/stdarg.h:99:9: error: unknown type name '__gnuc_va_list'
typedef __gnuc_va_list va_list;
^~~~~~~~~~~~~~
---
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: 30019 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 3/3] cxgb4: collect hardware dump in second kernel
From: kbuild test robot @ 2018-04-01 0:15 UTC (permalink / raw)
To: Rahul Lakkireddy
Cc: kbuild-all, netdev, kexec, linux-fsdevel, linux-kernel, davem,
viro, ebiederm, stephen, akpm, torvalds, ganeshgr, nirranjan,
indranil, Rahul Lakkireddy
In-Reply-To: <302fb326d8d15d64b5ef85471df40635f25cc890.1522483891.git.rahul.lakkireddy@chelsio.com>
[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]
Hi Rahul,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Rahul-Lakkireddy/kernel-add-support-to-collect-hardware-logs-in-crash-recovery-kernel/20180401-060904
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.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
make.cross ARCH=sparc64
All errors (new ones prefixed by >>):
`.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
`.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
`.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
`.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.o: In function `cxgb4_cudbg_vmcore_add_dump':
>> cxgb4_cudbg.c:(.text+0x9ec): undefined reference to `vmcore_add_device_dump'
---
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: 53488 bytes --]
^ permalink raw reply
* Re: [PATCH] net: bond: skip vlan header when do layer 3+4 hash policy
From: kbuild test robot @ 2018-03-31 23:59 UTC (permalink / raw)
To: liujian56
Cc: kbuild-all, davem, j.vosburgh, vfalico, andy, netdev, weiyongjun1,
liujian56
In-Reply-To: <1522487670-15796-1-git-send-email-liujian56@huawei.com>
Hi liujian,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
[also build test WARNING on v4.16-rc7 next-20180329]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/liujian56-huawei-com/net-bond-skip-vlan-header-when-do-layer-3-4-hash-policy/20180401-045327
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/net/bonding/bond_main.c:2343:26: sparse: restricted __be16 degrades to integer
drivers/net/bonding/bond_main.c:2349:20: sparse: restricted __be16 degrades to integer
drivers/net/bonding/bond_main.c:2396:40: sparse: incorrect type in assignment (different base types) @@ expected restricted __be16 [usertype] vlan_proto @@ got e] vlan_proto @@
drivers/net/bonding/bond_main.c:2396:40: expected restricted __be16 [usertype] vlan_proto
drivers/net/bonding/bond_main.c:2396:40: got int
>> drivers/net/bonding/bond_main.c:3217:18: sparse: incorrect type in assignment (different base types) @@ expected int [signed] skbproto @@ got restricted __be1int [signed] skbproto @@
drivers/net/bonding/bond_main.c:3217:18: expected int [signed] skbproto
drivers/net/bonding/bond_main.c:3217:18: got restricted __be16 [usertype] protocol
>> drivers/net/bonding/bond_main.c:3219:26: sparse: incorrect type in assignment (different base types) @@ expected int [signed] skbproto @@ got restint [signed] skbproto @@
drivers/net/bonding/bond_main.c:3219:26: expected int [signed] skbproto
drivers/net/bonding/bond_main.c:3219:26: got restricted __be16
drivers/net/bonding/bond_main.c:3221:25: sparse: restricted __be16 degrades to integer
drivers/net/bonding/bond_main.c:3229:32: sparse: restricted __be16 degrades to integer
drivers/net/bonding/bond_main.c:3199:60: sparse: restricted __be16 degrades to integer
drivers/net/bonding/bond_main.c:3199:60: sparse: restricted __be16 degrades to integer
vim +3217 drivers/net/bonding/bond_main.c
3202
3203 /* Extract the appropriate headers based on bond's xmit policy */
3204 static bool bond_flow_dissect(struct bonding *bond, struct sk_buff *skb,
3205 struct flow_keys *fk)
3206 {
3207 const struct ipv6hdr *iph6;
3208 const struct iphdr *iph;
3209 int noff, proto = -1, skbproto;
3210
3211 if (bond->params.xmit_policy > BOND_XMIT_POLICY_LAYER23)
3212 return skb_flow_dissect_flow_keys(skb, fk, 0);
3213
3214 fk->ports.ports = 0;
3215 noff = skb_network_offset(skb);
3216
> 3217 skbproto = skb->protocol;
3218 if (bond->params.xmit_policy == BOND_XMIT_POLICY_LAYER34)
> 3219 skbproto = vlan_get_protocol(skb);
3220
3221 if (skbproto == htons(ETH_P_IP)) {
3222 if (unlikely(!pskb_may_pull(skb, noff + sizeof(*iph))))
3223 return false;
3224 iph = ip_hdr(skb);
3225 iph_to_flow_copy_v4addrs(fk, iph);
3226 noff += iph->ihl << 2;
3227 if (!ip_is_fragment(iph))
3228 proto = iph->protocol;
3229 } else if (skbproto == htons(ETH_P_IPV6)) {
3230 if (unlikely(!pskb_may_pull(skb, noff + sizeof(*iph6))))
3231 return false;
3232 iph6 = ipv6_hdr(skb);
3233 iph_to_flow_copy_v6addrs(fk, iph6);
3234 noff += sizeof(*iph6);
3235 proto = iph6->nexthdr;
3236 } else {
3237 return false;
3238 }
3239 if (bond->params.xmit_policy == BOND_XMIT_POLICY_LAYER34 && proto >= 0)
3240 fk->ports.ports = skb_flow_get_ports(skb, noff, proto);
3241
3242 return true;
3243 }
3244
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* pull-request: bpf-next 2018-03-31
From: Daniel Borkmann @ 2018-03-31 23:51 UTC (permalink / raw)
To: davem; +Cc: daniel, ast, netdev
Hi David,
The following pull-request contains BPF updates for your *net-next* tree.
The main changes are:
1) Add raw BPF tracepoint API in order to have a BPF program type that
can access kernel internal arguments of the tracepoints in their
raw form similar to kprobes based BPF programs. This infrastructure
also adds a new BPF_RAW_TRACEPOINT_OPEN command to BPF syscall which
returns an anon-inode backed fd for the tracepoint object that allows
for automatic detach of the BPF program resp. unregistering of the
tracepoint probe on fd release, from Alexei.
2) Add new BPF cgroup hooks at bind() and connect() entry in order to
allow BPF programs to reject, inspect or modify user space passed
struct sockaddr, and as well a hook at post bind time once the port
has been allocated. They are used in FB's container management engine
for implementing policy, replacing fragile LD_PRELOAD wrapper
intercepting bind() and connect() calls that only works in limited
scenarios like glibc based apps but not for other runtimes in
containerized applications, from Andrey.
3) BPF_F_INGRESS flag support has been added to sockmap programs for
their redirect helper call bringing it in line with cls_bpf based
programs. Support is added for both variants of sockmap programs,
meaning for tx ULP hooks as well as recv skb hooks, from John.
4) Various improvements on BPF side for the nfp driver, besides others
this work adds BPF map update and delete helper call support from
the datapath, JITing of 32 and 64 bit XADD instructions as well as
offload support of bpf_get_prandom_u32() call. Initial implementation
of nfp packet cache has been tackled that optimizes memory access
(see merge commit for further details), from Jakub and Jiong.
5) Removal of struct bpf_verifier_env argument from the print_bpf_insn()
API has been done in order to prepare to use print_bpf_insn() soon
out of perf tool directly. This makes the print_bpf_insn() API more
generic and pushes the env into private data. bpftool is adjusted
as well with the print_bpf_insn() argument removal, from Jiri.
6) Couple of cleanups and prep work for the upcoming BTF (BPF Type
Format). The latter will reuse the current BPF verifier log as
well, thus bpf_verifier_log() is further generalized, from Martin.
7) For bpf_getsockopt() and bpf_setsockopt() helpers, IPv4 IP_TOS read
and write support has been added in similar fashion to existing
IPv6 IPV6_TCLASS socket option we already have, from Nikita.
8) Fixes in recent sockmap scatterlist API usage, which did not use
sg_init_table() for initialization thus triggering a BUG_ON() in
scatterlist API when CONFIG_DEBUG_SG was enabled. This adds and
uses a small helper sg_init_marker() to properly handle the affected
cases, from Prashant.
9) Let the BPF core follow IDR code convention and therefore use the
idr_preload() and idr_preload_end() helpers, which would also help
idr_alloc_cyclic() under GFP_ATOMIC to better succeed under memory
pressure, from Shaohua.
10) Last but not least, a spelling fix in an error message for the
BPF cookie UID helper under BPF sample code, from Colin.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit ae06c70b135886d7d6252f3090146f01a3f3b80c:
intel: add SPDX identifiers to all the Intel drivers (2018-03-23 12:18:21 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
for you to fetch changes up to 7828f20e3779e4e85e55371e0e43f5006a15fb41:
Merge branch 'bpf-cgroup-bind-connect' (2018-03-31 02:18:07 +0200)
----------------------------------------------------------------
Alexei Starovoitov (10):
treewide: remove large struct-pass-by-value from tracepoint arguments
net/mediatek: disambiguate mt76 vs mt7601u trace events
net/mac802154: disambiguate mac80215 vs mac802154 trace events
net/wireless/iwlwifi: fix iwlwifi_dev_ucode_error tracepoint
macro: introduce COUNT_ARGS() macro
bpf: introduce BPF_RAW_TRACEPOINT
libbpf: add bpf_raw_tracepoint_open helper
samples/bpf: raw tracepoint test
selftests/bpf: test for bpf_get_stackid() from raw tracepoints
Merge branch 'nfp-bpf-updates'
Andrey Ignatov (9):
bpf: Check attach type at prog load time
libbpf: Support expected_attach_type at prog load
bpf: Hooks for sys_bind
selftests/bpf: Selftest for sys_bind hooks
net: Introduce __inet_bind() and __inet6_bind
bpf: Hooks for sys_connect
selftests/bpf: Selftest for sys_connect hooks
bpf: Post-hooks for sys_bind
selftests/bpf: Selftest for sys_bind post-hooks.
Colin Ian King (1):
samples/bpf: fix spelling mistake: "revieve" -> "receive"
Daniel Borkmann (6):
Merge branch 'bpf-print-insns-api'
Merge branch 'bpf-verifier-log-btf-prep'
Merge branch 'bpf-raw-tracepoints'
Merge branch 'bpf-sockmap-ingress'
Merge branch 'bpf-sockmap-sg-api-fixes'
Merge branch 'bpf-cgroup-bind-connect'
Jakub Kicinski (11):
nfp: bpf: rename map_lookup_stack() to map_call_stack_common()
nfp: bpf: add helper for validating stack pointers
nfp: bpf: add helper for basic map call checks
nfp: bpf: add map updates from the datapath
nfp: bpf: add map deletes from the datapath
bpf: add parenthesis around argument of BPF_LDST_BYTES()
nfp: bpf: add basic support for atomic adds
nfp: bpf: expose command delay slots
nfp: bpf: add support for atomic add of unknown values
nfp: bpf: add support for bpf_get_prandom_u32()
nfp: bpf: improve wrong FW response warnings
Jiong Wang (3):
nfp: bpf: read from packet data cache for PTR_TO_PACKET
nfp: bpf: support unaligned read offset
nfp: bpf: detect packet reads could be cached, enable the optimisation
Jiri Olsa (2):
bpf: Remove struct bpf_verifier_env argument from print_bpf_insn
bpftool: Adjust to new print_bpf_insn interface
John Fastabend (4):
bpf: sockmap redirect ingress support
bpf: sockmap, add BPF_F_INGRESS tests
bpf: sockmap, BPF_F_INGRESS flag for BPF_SK_SKB_STREAM_VERDICT:
bpf: sockmap, more BPF_SK_SKB_STREAM_VERDICT tests
Martin KaFai Lau (2):
bpf: Rename bpf_verifer_log
bpf: Add bpf_verifier_vlog() and bpf_verifier_log_needed()
Nikita V. Shirokov (1):
bpf: Add sock_ops R/W access to ipv4 tos
Prashant Bhole (2):
lib/scatterlist: add sg_init_marker() helper
bpf: sockmap: initialize sg table entries properly
Shaohua Li (1):
bpf: follow idr code convention
drivers/infiniband/hw/hfi1/file_ops.c | 2 +-
drivers/infiniband/hw/hfi1/trace_ctxts.h | 12 +-
drivers/net/ethernet/netronome/nfp/bpf/cmsg.c | 12 +-
drivers/net/ethernet/netronome/nfp/bpf/fw.h | 1 +
drivers/net/ethernet/netronome/nfp/bpf/jit.c | 462 ++++++++++++++--
drivers/net/ethernet/netronome/nfp/bpf/main.c | 18 +
drivers/net/ethernet/netronome/nfp/bpf/main.h | 85 ++-
drivers/net/ethernet/netronome/nfp/bpf/offload.c | 45 +-
drivers/net/ethernet/netronome/nfp/bpf/verifier.c | 217 ++++++--
drivers/net/ethernet/netronome/nfp/nfp_asm.c | 2 +
drivers/net/ethernet/netronome/nfp/nfp_asm.h | 7 +
drivers/net/wireless/intel/iwlwifi/dvm/main.c | 7 +-
.../wireless/intel/iwlwifi/iwl-devtrace-iwlwifi.h | 39 +-
drivers/net/wireless/intel/iwlwifi/iwl-devtrace.c | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 7 +-
drivers/net/wireless/mediatek/mt7601u/trace.h | 6 +-
include/asm-generic/vmlinux.lds.h | 10 +
include/linux/bpf-cgroup.h | 68 ++-
include/linux/bpf.h | 5 +-
include/linux/bpf_types.h | 2 +
include/linux/bpf_verifier.h | 13 +-
include/linux/filter.h | 15 +-
include/linux/kernel.h | 7 +
include/linux/scatterlist.h | 18 +
include/linux/trace_events.h | 42 ++
include/linux/tracepoint-defs.h | 6 +
include/net/addrconf.h | 7 +
include/net/inet_common.h | 2 +
include/net/ipv6.h | 2 +
include/net/sock.h | 4 +
include/net/udp.h | 1 +
include/trace/bpf_probe.h | 92 ++++
include/trace/define_trace.h | 1 +
include/trace/events/f2fs.h | 2 +-
include/uapi/linux/bpf.h | 62 ++-
kernel/bpf/cgroup.c | 39 +-
kernel/bpf/disasm.c | 52 +-
kernel/bpf/disasm.h | 5 +-
kernel/bpf/sockmap.c | 303 ++++++++++-
kernel/bpf/syscall.c | 184 ++++++-
kernel/bpf/verifier.c | 64 ++-
kernel/trace/bpf_trace.c | 206 +++++++-
lib/scatterlist.c | 9 +-
net/core/filter.c | 481 ++++++++++++++++-
net/ipv4/af_inet.c | 71 ++-
net/ipv4/tcp.c | 10 +-
net/ipv4/tcp_ipv4.c | 16 +
net/ipv4/udp.c | 14 +
net/ipv6/af_inet6.c | 66 ++-
net/ipv6/tcp_ipv6.c | 16 +
net/ipv6/udp.c | 20 +
net/mac802154/trace.h | 8 +-
net/wireless/trace.h | 2 +-
samples/bpf/Makefile | 1 +
samples/bpf/bpf_load.c | 14 +
samples/bpf/cookie_uid_helper_example.c | 2 +-
samples/bpf/test_overhead_raw_tp_kern.c | 17 +
samples/bpf/test_overhead_user.c | 12 +
samples/sockmap/sockmap_kern.c | 62 ++-
samples/sockmap/sockmap_test.sh | 40 +-
samples/sockmap/sockmap_user.c | 58 ++
security/apparmor/include/path.h | 7 +-
sound/firewire/amdtp-stream-trace.h | 2 +-
tools/bpf/bpftool/xlated_dumper.c | 12 +-
tools/include/uapi/linux/bpf.h | 62 ++-
tools/lib/bpf/bpf.c | 55 +-
tools/lib/bpf/bpf.h | 18 +-
tools/lib/bpf/libbpf.c | 113 +++-
tools/lib/bpf/libbpf.h | 8 +
tools/testing/selftests/bpf/Makefile | 10 +-
tools/testing/selftests/bpf/bpf_helpers.h | 2 +
tools/testing/selftests/bpf/connect4_prog.c | 45 ++
tools/testing/selftests/bpf/connect6_prog.c | 61 +++
tools/testing/selftests/bpf/test_progs.c | 91 +++-
tools/testing/selftests/bpf/test_sock.c | 479 +++++++++++++++++
tools/testing/selftests/bpf/test_sock_addr.c | 588 +++++++++++++++++++++
tools/testing/selftests/bpf/test_sock_addr.sh | 57 ++
77 files changed, 4265 insertions(+), 399 deletions(-)
create mode 100644 include/trace/bpf_probe.h
create mode 100644 samples/bpf/test_overhead_raw_tp_kern.c
create mode 100644 tools/testing/selftests/bpf/connect4_prog.c
create mode 100644 tools/testing/selftests/bpf/connect6_prog.c
create mode 100644 tools/testing/selftests/bpf/test_sock.c
create mode 100644 tools/testing/selftests/bpf/test_sock_addr.c
create mode 100755 tools/testing/selftests/bpf/test_sock_addr.sh
^ permalink raw reply
* 2CUkYn1U
From: Suzgl @ 2018-03-31 23:33 UTC (permalink / raw)
To: debian-bugs-rc; +Cc: kernel-svn-changes, netdev
[-- Attachment #1.1: Type: text/plain, Size: 15 bytes --]
182.105.98.67
[-- Attachment #1.2: Type: text/html, Size: 332 bytes --]
[-- Attachment #2: Type: text/plain, Size: 197 bytes --]
_______________________________________________
Kernel-svn-changes mailing list
Kernel-svn-changes@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/kernel-svn-changes
^ permalink raw reply
* Re:
From: Ms Gloria Chow @ 2018-03-31 13:54 UTC (permalink / raw)
To: Recipients
How are you? I would like to discuss a possible collaboration on my projects that I have been operating over some years, hence please advice.
I am Gloria Chow, the Head of Client Relationships of Standard Chartered Bank (Hong Kong) Ltd. I contacted you on LinkedIn with a disguise account, however I shall send you a detailed email for consideration.
Thank you and I look forward to hearing from you.
Kind Regards,
Gloria Chow.
^ permalink raw reply
* WARNING in refcount_inc (3)
From: syzbot @ 2018-03-31 23:01 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot hit the following crash on bpf-next commit
1379ef828a18d8f81c526b25e4d5685caa2cfd65 (Thu Mar 29 22:09:44 2018 +0000)
Merge branch 'bpf-sockmap-ingress'
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=6eaf536fd743f5e119c5
So far this crash happened 6 times on bpf-next.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6614614900998144
syzkaller reproducer:
https://syzkaller.appspot.com/x/repro.syz?id=5035340528091136
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=5063394046509056
Kernel config:
https://syzkaller.appspot.com/x/.config?id=-1280663959502969741
compiler: gcc (GCC) 7.1.1 20170620
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+6eaf536fd743f5e119c5@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.
R13: 0000000000000005 R14: 0000000000001380 R15: 00007ffd314c8768
------------[ cut here ]------------
------------[ cut here ]------------
refcount_t: increment on 0; use-after-free.
refcount_t: underflow; use-after-free.
WARNING: CPU: 1 PID: 4434 at lib/refcount.c:153 refcount_inc+0x47/0x50
lib/refcount.c:153
WARNING: CPU: 0 PID: 4437 at lib/refcount.c:187
refcount_sub_and_test+0x167/0x1b0 lib/refcount.c:187
Kernel panic - not syncing: panic_on_warn set ...
Modules linked in:
CPU: 1 PID: 4434 Comm: syzkaller349430 Not tainted 4.16.0-rc6+ #41
CPU: 0 PID: 4437 Comm: syzkaller349430 Not tainted 4.16.0-rc6+ #41
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:refcount_sub_and_test+0x167/0x1b0 lib/refcount.c:187
Call Trace:
RSP: 0018:ffff8801b061f728 EFLAGS: 00010286
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x24d lib/dump_stack.c:53
RAX: dffffc0000000008 RBX: 0000000000000000 RCX: ffffffff815ba4be
RDX: 0000000000000000 RSI: 1ffff100360c3e95 RDI: 1ffff100360c3e6a
RBP: ffff8801b061f7b8 R08: 0000000000000000 R09: 0000000000000000
R10: ffff8801b061f850 R11: 0000000000000000 R12: 1ffff100360c3ee6
panic+0x1e4/0x41c kernel/panic.c:183
R13: 00000000ffffffff R14: 0000000000000001 R15: ffff8801b1be4184
FS: 0000000001817880(0000) GS:ffff8801db200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffd314c9000 CR3: 00000001b04a1006 CR4: 00000000001606f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__warn+0x1dc/0x200 kernel/panic.c:547
report_bug+0x1f4/0x2b0 lib/bug.c:186
fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
fixup_bug arch/x86/kernel/traps.c:247 [inline]
do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
refcount_dec_and_test+0x1a/0x20 lib/refcount.c:212
put_net include/net/net_namespace.h:222 [inline]
__sk_destruct+0x560/0x920 net/core/sock.c:1592
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
invalid_op+0x1b/0x40 arch/x86/entry/entry_64.S:986
RIP: 0010:refcount_inc+0x47/0x50 lib/refcount.c:153
RSP: 0018:ffff8801b058f860 EFLAGS: 00010286
RAX: dffffc0000000008 RBX: ffff8801ab55a1c4 RCX: ffffffff815ba4be
RDX: 0000000000000000 RSI: 1ffff100360b1ebc RDI: 1ffff100360b1e91
RBP: ffff8801b058f868 R08: 0000000000000000 R09: 0000000000000000
sk_destruct+0x47/0x80 net/core/sock.c:1601
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801b058faf8
__sk_free+0xf1/0x2b0 net/core/sock.c:1612
R13: ffff8801af87b513 R14: ffff8801ab55a1c0 R15: ffff8801af87b501
sk_free+0x2a/0x40 net/core/sock.c:1623
sock_put include/net/sock.h:1661 [inline]
tcp_close+0x967/0x1190 net/ipv4/tcp.c:2329
get_net include/net/net_namespace.h:204 [inline]
sk_alloc+0x3f9/0x1440 net/core/sock.c:1540
inet_release+0xed/0x1c0 net/ipv4/af_inet.c:427
sock_release+0x8d/0x1e0 net/socket.c:594
sock_close+0x16/0x20 net/socket.c:1149
__fput+0x327/0x7e0 fs/file_table.c:209
____fput+0x15/0x20 fs/file_table.c:243
task_work_run+0x199/0x270 kernel/task_work.c:113
inet_create+0x47c/0xf50 net/ipv4/af_inet.c:320
tracehook_notify_resume include/linux/tracehook.h:191 [inline]
exit_to_usermode_loop+0x275/0x2f0 arch/x86/entry/common.c:166
__sock_create+0x4d4/0x850 net/socket.c:1285
prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
do_syscall_64+0x6ec/0x940 arch/x86/entry/common.c:292
sock_create net/socket.c:1325 [inline]
SYSC_socket net/socket.c:1355 [inline]
SyS_socket+0xeb/0x1d0 net/socket.c:1335
do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x402950
RSP: 002b:00007ffd314c8628 EFLAGS: 00000246
ORIG_RAX: 0000000000000003
RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000402950
RDX: 00000000000000e0 RSI: 00007ffd314c8f00 RDI: 0000000000000003
RBP: 00007ffd314c8740 R08: 00007ffd314c864c R09: 0000000000000001
R10: 00007ffd314c8740 R11: 0000000000000246 R12: 00000000006cf4c0
R13: 00000000006cee40 R14: 0000000000001380 R15: 00007ffd314c8768
Code:
entry_SYSCALL_64_after_hwframe+0x42/0xb7
5e
RIP: 0033:0x4456a7
41
RSP: 002b:00007ffd314c8628 EFLAGS: 00000202 ORIG_RAX: 0000000000000029
5f
RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00000000004456a7
5d
RDX: 0000000000000006 RSI: 0000000000000001 RDI: 0000000000000002
RBP: 00007ffd314c8740 R08: 0000000000000000 R09: 0000000000000001
c3
R10: 0000000000000006 R11: 0000000000000202 R12: 0000000000000003
e8
R13: 0000000000000003 R14: 0000000000006cc2 R15: 00007ffd314c8768
0a 0b be fe 80 3d 20 c9 84 05 00 75 1a e8 fc 0a be fe 48 c7 c7 e0 78 e5 86
c6 05 0b c9 84 05 01 e8 a9 16 8e fe <0f> 0b 31 db eb a3 e8 de 0a be fe 83
fb ff 0f 85 63 ff ff ff 31
---[ end trace dd327356f543ce46 ]---
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* general protection fault in __list_del_entry_valid (3)
From: syzbot @ 2018-03-31 23:01 UTC (permalink / raw)
To: davem, jon.maloy, linux-kernel, netdev, syzkaller-bugs,
tipc-discussion, ying.xue
Hello,
syzbot hit the following crash on net-next commit
c0b6edef0bf0e33c12eaf80c676ff09def011518 (Thu Mar 29 19:58:10 2018 +0000)
tc-testing: Add newline when writing test case files
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=0bb443b74ce09197e970
So far this crash happened 40 times on bpf-next, net-next, upstream.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5934690573746176
syzkaller reproducer:
https://syzkaller.appspot.com/x/repro.syz?id=5611083175821312
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=6249721593069568
Kernel config:
https://syzkaller.appspot.com/x/.config?id=3327544840960562528
compiler: gcc (GCC) 7.1.1 20170620
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+0bb443b74ce09197e970@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.
R13: ffffffffffffffff R14: 0000000000000000 R15: 0000000000000000
Name sequence creation failed, no memory
Failed to create subscription for {1020,0,4294967295}
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
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 4361 Comm: syzkaller865516 Not tainted 4.16.0-rc6+ #288
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:__list_del_entry_valid+0x7e/0x150 lib/list_debug.c:51
RSP: 0018:ffff8801ae29eec8 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 00000000000001f8 RCX: 0000000000000000
RDX: 000000000000003f RSI: ffff8801c9eb6cd8 RDI: ffff8801c9eb6ce0
RBP: ffff8801ae29eee0 R08: ffffffff86b2cc9f R09: 0000000000000000
R10: ffff8801ae29eda8 R11: ffff8801d08cf710 R12: 0000000000400040
R13: ffff8801ae29f080 R14: ffff8801c9eb6cd8 R15: ffff8801d08cf6c0
FS: 0000000000000000(0000) GS:ffff8801db000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020265000 CR3: 000000000846a004 CR4: 00000000001606f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__list_del_entry include/linux/list.h:117 [inline]
list_del_init include/linux/list.h:159 [inline]
tipc_nametbl_unsubscribe+0x337/0x990 net/tipc/name_table.c:808
tipc_sub_unsubscribe+0x6d/0x2e0 net/tipc/subscr.c:164
tipc_conn_delete_sub+0x324/0x4a0 net/tipc/topsrv.c:245
tipc_topsrv_kern_unsubscr+0x21d/0x350 net/tipc/topsrv.c:598
tipc_group_delete+0x2c0/0x3d0 net/tipc/group.c:231
tipc_sk_leave+0x10b/0x200 net/tipc/socket.c:2800
tipc_release+0x154/0xff0 net/tipc/socket.c:576
sock_release+0x8d/0x1e0 net/socket.c:594
sock_close+0x16/0x20 net/socket.c:1149
__fput+0x327/0x7e0 fs/file_table.c:209
____fput+0x15/0x20 fs/file_table.c:243
task_work_run+0x199/0x270 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x9bb/0x1ad0 kernel/exit.c:865
do_group_exit+0x149/0x400 kernel/exit.c:968
SYSC_exit_group kernel/exit.c:979 [inline]
SyS_exit_group+0x1d/0x20 kernel/exit.c:977
do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x43f0d8
RSP: 002b:00007ffca6e03198 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000000000043f0d8
RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
RBP: 00000000004bf1c8 R08: 00000000000000e7 R09: ffffffffffffffd0
R10: 0000000020265000 R11: 0000000000000246 R12: 0000000000000001
R13: 00000000006d1180 R14: 0000000000000000 R15: 0000000000000000
Code: 00 00 00 00 ad de 49 39 c4 74 66 48 b8 00 02 00 00 00 00 ad de 48 89
da 48 39 c3 74 65 48 c1 ea 03 48 b8 00 00 00 00 00 fc ff df <80> 3c 02 00
75 7b 48 8b 13 48 39 f2 75 57 49 8d 7c 24 08 48 b8
RIP: __list_del_entry_valid+0x7e/0x150 lib/list_debug.c:51 RSP:
ffff8801ae29eec8
---[ end trace 31f0221025ea0e3e ]---
---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* Re: [PATCH net-next 5/8] net: mscc: Add initial Ocelot switch support
From: Florian Fainelli @ 2018-03-31 22:47 UTC (permalink / raw)
To: Andrew Lunn, Alexandre Belloni
Cc: David S . Miller, Allan Nielsen, razvan.stefanescu, po.liu,
Thomas Petazzoni, netdev, devicetree, linux-kernel, linux-mips
In-Reply-To: <20180330145008.GE28244@lunn.ch>
Le 03/30/18 à 07:50, Andrew Lunn a écrit :
> On Fri, Mar 30, 2018 at 04:16:34PM +0200, Alexandre Belloni wrote:
>> On 30/03/2018 at 15:54:22 +0200, Andrew Lunn wrote:
>>>>> All of this sounds like it should be moved into the br_join/leave, this
>>>>> does not appear to be the right place to do that.
>>>>>
>>>>
>>>> No, I've triple checked because this is a comment that both Andrew and
>>>> you had. Once a port is added to the PGID MASK, it will start forwarding
>>>> frames so we really want that to happen only when the port is in
>>>> BR_STATE_FORWARDING state. Else, we may forward frames between the
>>>> addition of the port to the bridge and setting the port to the
>>>> BR_STATE_BLOCKING state.
>>>
>>> Hi Alexandre
>>>
>>> Interesting observation. I took a look at some of the other join
>>> implementations. mv88e6xxx does the join immediately. mt7539 does it
>>> immediately, if the port is enabled. lan9303 does it immediately.
>>> qca8k does it immediately. b53 does it immediately.
>>>
>>
>> I had a look at b53, my impression was that b53_br_join() adds the port
>> to the bridge but b53_br_set_stp_state() actually enables forwarding. So
>> as long as the default on the port is PORT_CTRL_DIS_STATE, the port will
>> not be forwarding frames. And this is the case because b53_enable_port()
>> does put 0 in B53_PORT_CTRL.
>
> https://elixir.bootlin.com/linux/latest/source/drivers/net/dsa/b53/b53_regs.h#L71
>
> It seems like, 0 means no STP at all. Which to me would mean, forward
> all packets. But i could be wrong. Florian?
Correct, 0 disables STP and therefore means forward all packets.
>
>> The fact is that ocelot doesn't have separate controls. The port is
>> either forwarding or not. If it is not forwarding, then there is nothing
>> to tell the HW to do.
>
> Think about the following sequence:
>
> ip link set lan0 up
>
> After this command, i expect to see packets on lan0 arrive at the
> host, tcpdump to work, etc. This probably means the port is in
> 'forwarding' mode, or for B53, STP is disabled.
In net/dsa/port.c::dsa_port_enable we have the following:
u8 stp_state = dp->bridge_dev ? BR_STATE_BLOCKING : BR_STATE_FORWARDING;
>
> ip link add name br0 type bridge
> ip link set dev br0 up
> ip link set dev lan0 master br0
>
> When the port is added to the bridge, there is a window of time
> between the join and the STP change to blocking/learning, when the
> port is in forwarding mode. You avoid this window. But the other
> drivers don't appear to.
>
> So i would like to fix this of every driver. I'm not sure how yet...
Agreed, there does appear to be a window like you outlined in your
example if the port was already UP where we may be in an inconsistent
STP state. This window does not appear to be existing in case the port
was not UP prior to joining the bridge though.
It seems to me like the most natural place where to fix this would be in
the bridge code, but this has the potential to break several drivers so
within the scope of DSA, it might be as simple as this:
diff --git a/net/dsa/port.c b/net/dsa/port.c
index 7acc1169d75e..e692b6f1a710 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -116,6 +116,8 @@ int dsa_port_bridge_join(struct dsa_port *dp, struct
net_device *br)
if (err)
dp->bridge_dev = NULL;
+ dsa_port_set_state_now(dp, BR_STATE_BLOCKING);
+
return err;
}
--
Florian
^ permalink raw reply related
* [PATCH net-next v1] ipvs: fix multiplicative hashing in sh/dh/lblc/lblcr algorithms
From: Vincent Bernat @ 2018-03-31 22:28 UTC (permalink / raw)
To: Wensong Zhang, Simon Horman, Julian Anastasov, David S. Miller,
netdev, lvs-devel
Cc: Vincent Bernat
The sh/dh/lblc/lblcr algorithms are using Knuth's multiplicative
hashing incorrectly. This results in uneven distribution.
To fix this, the result has to be shifted by a constant. In "Lecture
21: Hash functions" [1], it is said:
In the fixed-point version, The division by 2^q is crucial. The
common mistake when doing multiplicative hashing is to forget to do
it, and in fact you can find web pages highly ranked by Google that
explain multiplicative hashing without this step. Without this
division, there is little point to multiplying by a, because ka mod
m = (k mod m) * (a mod m) mod m . This is no better than modular
hashing with a modulus of m, and quite possibly worse.
Typing the 2654435761 constant in DuckDuckGo shows many other sources
to confirm this issue. Moreover, doing the multiplication in the 32bit
integer space is enough, hence the change from 2654435761UL to
2654435761U.
[1]: https://www.cs.cornell.edu/courses/cs3110/2008fa/lectures/lec21.html
The following Python program illustrates the bug and its fix:
import netaddr
import collections
import socket
import statistics
def run(buggy=False):
base = netaddr.IPAddress('203.0.113.0')
count = collections.defaultdict(int)
for offset in range(100):
for port in range(10000, 11000):
r = socket.ntohs(port) + socket.ntohl(int(base) + offset)
r *= 2654435761
if buggy:
r %= 1 << 64
else:
r %= 1 << 32
r >>= 24
r &= 255
count[r] += 1
print(buggy,
statistics.mean(count.values()),
statistics.stdev(count.values()))
run(True)
run(False)
Its output is:
True 25000 765.9416862050705
False 390.625 4.681209831891333
Signed-off-by: Vincent Bernat <vincent@bernat.im>
---
net/netfilter/ipvs/ip_vs_dh.c | 4 +++-
net/netfilter/ipvs/ip_vs_lblc.c | 4 +++-
net/netfilter/ipvs/ip_vs_lblcr.c | 4 +++-
net/netfilter/ipvs/ip_vs_sh.c | 3 ++-
4 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_dh.c b/net/netfilter/ipvs/ip_vs_dh.c
index 75f798f8e83b..5638e66dbdd1 100644
--- a/net/netfilter/ipvs/ip_vs_dh.c
+++ b/net/netfilter/ipvs/ip_vs_dh.c
@@ -81,7 +81,9 @@ static inline unsigned int ip_vs_dh_hashkey(int af, const union nf_inet_addr *ad
addr_fold = addr->ip6[0]^addr->ip6[1]^
addr->ip6[2]^addr->ip6[3];
#endif
- return (ntohl(addr_fold)*2654435761UL) & IP_VS_DH_TAB_MASK;
+ return ((ntohl(addr_fold)*2654435761U) >>
+ (32 - IP_VS_DH_TAB_BITS)) &
+ IP_VS_DH_TAB_MASK;
}
diff --git a/net/netfilter/ipvs/ip_vs_lblc.c b/net/netfilter/ipvs/ip_vs_lblc.c
index 3057e453bf31..df32022a2bc4 100644
--- a/net/netfilter/ipvs/ip_vs_lblc.c
+++ b/net/netfilter/ipvs/ip_vs_lblc.c
@@ -160,7 +160,9 @@ ip_vs_lblc_hashkey(int af, const union nf_inet_addr *addr)
addr_fold = addr->ip6[0]^addr->ip6[1]^
addr->ip6[2]^addr->ip6[3];
#endif
- return (ntohl(addr_fold)*2654435761UL) & IP_VS_LBLC_TAB_MASK;
+ return ((ntohl(addr_fold)*2654435761U) >>
+ (32 - IP_VS_LBLC_TAB_BITS)) &
+ IP_VS_LBLC_TAB_MASK;
}
diff --git a/net/netfilter/ipvs/ip_vs_lblcr.c b/net/netfilter/ipvs/ip_vs_lblcr.c
index 92adc04557ed..3d0d278d4901 100644
--- a/net/netfilter/ipvs/ip_vs_lblcr.c
+++ b/net/netfilter/ipvs/ip_vs_lblcr.c
@@ -323,7 +323,9 @@ ip_vs_lblcr_hashkey(int af, const union nf_inet_addr *addr)
addr_fold = addr->ip6[0]^addr->ip6[1]^
addr->ip6[2]^addr->ip6[3];
#endif
- return (ntohl(addr_fold)*2654435761UL) & IP_VS_LBLCR_TAB_MASK;
+ return ((ntohl(addr_fold)*2654435761U) >>
+ (32 - IP_VS_LBLCR_TAB_BITS)) &
+ IP_VS_LBLCR_TAB_MASK;
}
diff --git a/net/netfilter/ipvs/ip_vs_sh.c b/net/netfilter/ipvs/ip_vs_sh.c
index 16aaac6eedc9..d2d6cdfae86e 100644
--- a/net/netfilter/ipvs/ip_vs_sh.c
+++ b/net/netfilter/ipvs/ip_vs_sh.c
@@ -96,7 +96,8 @@ ip_vs_sh_hashkey(int af, const union nf_inet_addr *addr,
addr_fold = addr->ip6[0]^addr->ip6[1]^
addr->ip6[2]^addr->ip6[3];
#endif
- return (offset + (ntohs(port) + ntohl(addr_fold))*2654435761UL) &
+ return ((offset + (ntohs(port) + ntohl(addr_fold))*2654435761U) >>
+ (32 - IP_VS_SH_TAB_BITS)) &
IP_VS_SH_TAB_MASK;
}
--
2.16.3
^ permalink raw reply related
* Re: [PATCH net-next 1/2] sh_eth: add sh_eth_cpu_data::no_xdfar flag
From: Sergei Shtylyov @ 2018-03-31 21:28 UTC (permalink / raw)
To: netdev; +Cc: linux-renesas-soc, linux-sh
In-Reply-To: <233e32d1-947b-2377-3d1f-39d5d83bd3f7@cogentembedded.com>
On 04/01/2018 12:22 AM, Sergei Shtylyov wrote:
> The commit 6ded286555c2 ("sh_eth: Fix RX recovery on R-Car in case of RX
> ring underrun") added a check for an bad RDFAR offset in sh_eth_rx(), so
> that the code could work on the R-Car Ether controllers which don't have
> this register (and TDFAR), then the commit 3365711df02 ("sh_eth: WARN on
Oops, only 11 digits! Should have been 3365711df024. :-)
> access to a register not implemented in a particular chip") replaced
> offset 0 with 0xffff. Adding/checking the 'no_xdfar' bit field in the
> 'struct sh_eth_cpu_data' instead results in less object code...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH net-next 2/2] sh_eth: kill useless check in __sh_eth_get_regs()
From: Sergei Shtylyov @ 2018-03-31 21:23 UTC (permalink / raw)
To: netdev; +Cc: linux-renesas-soc, linux-sh
In-Reply-To: <998029b4-9400-ebc3-51c1-623c3f72b6cc@cogentembedded.com>
Iff TSU registers exist on a given [G]Ether controller, they always include
the CAM entry table registers (TSU_ADR{H|L}<n>), thus the check for invalid
TSU_ADRH0 offset in __sh_eth_get_regs() is useless...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 23 +++++++++--------------
1 file changed, 9 insertions(+), 14 deletions(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -2153,22 +2153,17 @@ static size_t __sh_eth_get_regs(struct n
add_tsu_reg(TSU_POST2);
add_tsu_reg(TSU_POST3);
add_tsu_reg(TSU_POST4);
- if (mdp->reg_offset[TSU_ADRH0] != SH_ETH_OFFSET_INVALID) {
- /* This is the start of a table, not just a single
- * register.
- */
- if (buf) {
- unsigned int i;
+ /* This is the start of a table, not just a single register. */
+ if (buf) {
+ unsigned int i;
- mark_reg_valid(TSU_ADRH0);
- for (i = 0; i < SH_ETH_TSU_CAM_ENTRIES * 2; i++)
- *buf++ = ioread32(
- mdp->tsu_addr +
- mdp->reg_offset[TSU_ADRH0] +
- i * 4);
- }
- len += SH_ETH_TSU_CAM_ENTRIES * 2;
+ mark_reg_valid(TSU_ADRH0);
+ for (i = 0; i < SH_ETH_TSU_CAM_ENTRIES * 2; i++)
+ *buf++ = ioread32(mdp->tsu_addr +
+ mdp->reg_offset[TSU_ADRH0] +
+ i * 4);
}
+ len += SH_ETH_TSU_CAM_ENTRIES * 2;
}
#undef mark_reg_valid
^ permalink raw reply
* Re: [PATCH v3 bpf-next 0/9] bpf: introduce cgroup-bpf bind, connect, post-bind hooks
From: Daniel Borkmann @ 2018-03-31 21:22 UTC (permalink / raw)
To: Alexei Starovoitov, davem; +Cc: netdev, kernel-team
In-Reply-To: <20180330220808.763556-1-ast@kernel.org>
On 03/31/2018 12:07 AM, Alexei Starovoitov wrote:
> v2->v3:
> - rebase due to conflicts
> - fix ipv6=m build
>
> v1->v2:
> - support expected_attach_type at prog load time so that prog (incl.
> context accesses and calls to helpers) can be validated with regard to
> specific attach point it is supposed to be attached to.
> Later, at attach time, attach type is checked so that it must be same as
> at load time if it was provided
> - reworked hooks to rely on expected_attach_type, and reduced number of new
> prog types from 6 to just 1: BPF_PROG_TYPE_CGROUP_SOCK_ADDR
> - reused BPF_PROG_TYPE_CGROUP_SOCK for sys_bind post-hooks
> - add selftests for post-sys_bind hook
[...]
Applied to bpf-next, thanks everyone!
^ permalink raw reply
* [PATCH net-next 1/2] sh_eth: add sh_eth_cpu_data::no_xdfar flag
From: Sergei Shtylyov @ 2018-03-31 21:22 UTC (permalink / raw)
To: netdev; +Cc: linux-renesas-soc, linux-sh
In-Reply-To: <998029b4-9400-ebc3-51c1-623c3f72b6cc@cogentembedded.com>
The commit 6ded286555c2 ("sh_eth: Fix RX recovery on R-Car in case of RX
ring underrun") added a check for an bad RDFAR offset in sh_eth_rx(), so
that the code could work on the R-Car Ether controllers which don't have
this register (and TDFAR), then the commit 3365711df02 ("sh_eth: WARN on
access to a register not implemented in a particular chip") replaced
offset 0 with 0xffff. Adding/checking the 'no_xdfar' bit field in the
'struct sh_eth_cpu_data' instead results in less object code...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 5 +++--
drivers/net/ethernet/renesas/sh_eth.h | 1 +
2 files changed, 4 insertions(+), 2 deletions(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -702,6 +702,7 @@ static struct sh_eth_cpu_data rcar_gen1_
.mpr = 1,
.tpauser = 1,
.hw_swap = 1,
+ .no_xdfar = 1,
};
/* R-Car Gen2 and RZ/G1 */
@@ -735,6 +736,7 @@ static struct sh_eth_cpu_data rcar_gen2_
.mpr = 1,
.tpauser = 1,
.hw_swap = 1,
+ .no_xdfar = 1,
.rmiimode = 1,
.magic = 1,
};
@@ -1615,8 +1617,7 @@ static int sh_eth_rx(struct net_device *
/* If we don't need to check status, don't. -KDU */
if (!(sh_eth_read(ndev, EDRRR) & EDRRR_R)) {
/* fix the values for the next receiving if RDE is set */
- if (intr_status & EESR_RDE &&
- mdp->reg_offset[RDFAR] != SH_ETH_OFFSET_INVALID) {
+ if (intr_status & EESR_RDE && !mdp->cd->no_xdfar) {
u32 count = (sh_eth_read(ndev, RDFAR) -
sh_eth_read(ndev, RDLAR)) >> 4;
Index: net-next/drivers/net/ethernet/renesas/sh_eth.h
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.h
+++ net-next/drivers/net/ethernet/renesas/sh_eth.h
@@ -508,6 +508,7 @@ struct sh_eth_cpu_data {
unsigned rpadir:1; /* E-DMAC have RPADIR */
unsigned no_trimd:1; /* E-DMAC DO NOT have TRIMD */
unsigned no_ade:1; /* E-DMAC DO NOT have ADE bit in EESR */
+ unsigned no_xdfar:1; /* E-DMAC DOES NOT have RDFAR/TDFAR */
unsigned xdfar_rw:1; /* E-DMAC has writeable RDFAR/TDFAR */
unsigned hw_checksum:1; /* E-DMAC has CSMR */
unsigned select_mii:1; /* EtherC have RMII_MII (MII select register) */
^ permalink raw reply
* [PATCH 0/2] sh_eth: remove SH_ETH_OFFSET_INVALID abuses
From: Sergei Shtylyov @ 2018-03-31 21:15 UTC (permalink / raw)
To: netdev; +Cc: linux-renesas-soc, linux-sh
Hello!
Here's a set of 2 patches against DaveM's 'net-next.git' repo. They get rid of
the abuse of SH_ETH_OFFSET_INVALID for the register existence checks, so that
only its necessary uses would remain...
[1/2] sh_eth: add sh_eth_cpu_data::no_xdfar flag
[2/2] sh_eth: kill useless check in __sh_eth_get_regs()
MBR, Sergei
^ permalink raw reply
* [PATCH net-next 2/2] ipv6: factorize sk_wmem_alloc updates done by __ip6_append_data()
From: Eric Dumazet @ 2018-03-31 20:16 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet
In-Reply-To: <20180331201626.186789-1-edumazet@google.com>
While testing my inet defrag changes, I found that the senders
could spend ~20% of cpu cycles in skb_set_owner_w() updating
sk->sk_wmem_alloc for every fragment they cook, competing
with TX completion of prior skbs possibly happening on another cpus.
The solution to this problem is to use alloc_skb() instead
of sock_wmalloc() and manually perform a single sk_wmem_alloc change.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv6/ip6_output.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 2c7f09c3c39ed8a1e85a967e105ff3cc30dce5b9..323d7a354ffb6f75e2a948dea63a8018ed0e057f 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1259,6 +1259,7 @@ static int __ip6_append_data(struct sock *sk,
struct ipv6_txoptions *opt = v6_cork->opt;
int csummode = CHECKSUM_NONE;
unsigned int maxnonfragsize, headersize;
+ unsigned int wmem_alloc_delta = 0;
skb = skb_peek_tail(queue);
if (!skb) {
@@ -1411,11 +1412,10 @@ static int __ip6_append_data(struct sock *sk,
(flags & MSG_DONTWAIT), &err);
} else {
skb = NULL;
- if (refcount_read(&sk->sk_wmem_alloc) <=
+ if (refcount_read(&sk->sk_wmem_alloc) + wmem_alloc_delta <=
2 * sk->sk_sndbuf)
- skb = sock_wmalloc(sk,
- alloclen + hh_len, 1,
- sk->sk_allocation);
+ skb = alloc_skb(alloclen + hh_len,
+ sk->sk_allocation);
if (unlikely(!skb))
err = -ENOBUFS;
}
@@ -1474,6 +1474,11 @@ static int __ip6_append_data(struct sock *sk,
/*
* Put the packet on the pending queue
*/
+ if (!skb->destructor) {
+ skb->destructor = sock_wfree;
+ skb->sk = sk;
+ wmem_alloc_delta += skb->truesize;
+ }
__skb_queue_tail(queue, skb);
continue;
}
@@ -1520,12 +1525,13 @@ static int __ip6_append_data(struct sock *sk,
skb->len += copy;
skb->data_len += copy;
skb->truesize += copy;
- refcount_add(copy, &sk->sk_wmem_alloc);
+ wmem_alloc_delta += copy;
}
offset += copy;
length -= copy;
}
+ refcount_add(wmem_alloc_delta, &sk->sk_wmem_alloc);
return 0;
error_efault:
@@ -1533,6 +1539,7 @@ static int __ip6_append_data(struct sock *sk,
error:
cork->length -= length;
IP6_INC_STATS(sock_net(sk), rt->rt6i_idev, IPSTATS_MIB_OUTDISCARDS);
+ refcount_add(wmem_alloc_delta, &sk->sk_wmem_alloc);
return err;
}
--
2.17.0.rc1.321.gba9d0f2565-goog
^ 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