Re: ipv6 sysctl

Hey netdev guys, Any feedback on this? :-) thanks ani On Tue, Feb 28, 2017 at 11:22 AM, Ani Sinha wrote: > Hi guys, > > Commit a79ca223e029 ('ipv6: fix bad free of addrconf_init_net') > introduced in linux 3.9 tries to fix an issue involving free-ing > statically allocated

[PATCH 1/1] rds: remove unnecessary returned value check

The function rds_trans_register always returns 0. As such, it is not necessary to check the returned value. Cc: Joe Jin Cc: Junxiao Bi Signed-off-by: Zhu Yanjun --- net/rds/ib.c| 6 +- net/rds/rds.h | 2 +-

BUG due to "xen-netback: protect resource cleaning on XenBus disconnect"

With commits f16f1df65 and 9a6cdf52b we get in our Xen testing: [ 174.512861] switch: port 2(vif3.0) entered disabled state [ 174.522735] BUG: sleeping function called from invalid context at /home/build/linux-linus/mm/vmalloc.c:1441 [ 174.523451] in_atomic(): 1, irqs_disabled(): 0, pid: 28,

[PATCH net] sctp: change to save MSG_MORE flag into assoc

David Laight noticed the support for MSG_MORE with datamsg->force_day didn't really work as we expected, as the first msg with MSG_MORE set would always block the following chunks' dequeuing. This Patch is to rewrite it by saving the MSG_MORE flag into assoc as Divid Laight suggested.

[PATCH] can: m_can: support transmit frame in CAN FD format

Add support to transmit the frame in the CAN FD format and with the bit rate switching. Tested on SAMA5D2 Xplained board. Signed-off-by: Wenyou Yang --- The testing is based on [RESEND PATCH 1/1] can: m_can: fix bitrate setup on latest silicon

Re: net/sctp: use-after-free in sctp_association_put

On Fri, Mar 3, 2017 at 3:21 AM, Dmitry Vyukov wrote: > On Thu, Mar 2, 2017 at 9:06 AM, Xin Long wrote: >> On Thu, Mar 2, 2017 at 3:18 AM, Dmitry Vyukov wrote: >>> Hello, >>> >>> I've got the following report while running syzkaller

[PATCH net 0/2] nfp: RX and XDP buffer fixes

Hi! Two trivial fixes for code introduced with XDP support. First one corrects the buffer size we populate a register with. The register is designed to be used for scatter transfers which the driver (and most FWs) don't support so it's not critical. The other one for DMA direction is mostly

Re: [PATCH net] tcp: fix potential double free issue for fastopen_req

From: Wei Wang Date: Wed, 1 Mar 2017 13:29:48 -0800 > From: Wei Wang > > tp->fastopen_req could potentially be double freed if a malicious > user does the following: > 1. Enable TCP_FASTOPEN_CONNECT sockopt and do a connect() on the socket. > 2. Call

Re: [PATCH net] rxrpc: Fix potential NULL-pointer exception

David Howells wrote: > Fix a potential NULL-pointer exception in rxrpc_do_sendmsg(). The call > state check that I added should have gone into the else-body of the > if-statement where we actually have a call to check. > > Found by CoverityScan CID#1414316 ("Dereference

[net 0/2][pull request] Intel Wired LAN Driver Updates 2017-03-02

This series contains fixes to ixgbe only. Paolo fixes the driver so that you can actually update the RSS key value via ethtool. Alex fixes an issue on architectures that have a cache line size larger than 64 Bytes, where the amount of headroom for the frame starts shrinking. To take this into

[net 2/2] ixgbe: Limit use of 2K buffers on architectures with 256B or larger cache lines

From: Alexander Duyck On architectures that have a cache line size larger than 64 Bytes we start running into issues where the amount of headroom for the frame starts shrinking. The size of skb_shared_info on a system with a 64B L1 cache line size is 320. This

[net 1/2] ixgbe: update the rss key on h/w, when ethtool ask for it

From: Paolo Abeni Currently ixgbe_set_rxfh() updates the rss_key copy in the driver memory, but does not push the new value into the h/w. This commit add a new helper for the latter operation and call it in ixgbe_set_rxfh(), so that the h/w rss key value can be really updated

Re: [PATCH net] xen-netback: Use GFP_ATOMIC to allocate hash

From: Anoob Soman Date: Thu, 2 Mar 2017 10:50:20 + > Allocation of new_hash, inside xenvif_new_hash(), always happen > in softirq context, so use GFP_ATOMIC instead of GFP_KERNEL for new > hash allocation. > > Signed-off-by: Anoob Soman

Re: [Patch net] bonding: use ETH_MAX_MTU as max mtu

From: Cong Wang Date: Thu, 2 Mar 2017 12:24:36 -0800 > This restores the ability of setting bond device's mtu to 9000. > > Fixes: 91572088e3fd ("net: use core MTU range checking in core net infra") > Reported-by: daz...@gmail.com > Reported-by: Brad Campbell

Re: [PATCH-v4-RESEND 1/4] vsock: track pkt owner vsock

On Fri, Mar 3, 2017 at 5:13 AM, David Miller wrote: > From: Peng Tao > Date: Wed, 1 Mar 2017 11:56:24 +0800 > >> So that we can cancel a queued pkt later if necessary. >> >> Reviewed-by: Stefan Hajnoczi >> Signed-off-by: Peng Tao

Re: [PATCH v5 06/10] seccomp,landlock: Handle Landlock events per process hierarchy

On Thu, Mar 2, 2017 at 4:48 PM, Mickaël Salaün wrote: > > On 02/03/2017 17:36, Andy Lutomirski wrote: >> On Wed, Mar 1, 2017 at 3:28 PM, Mickaël Salaün wrote: >>> >>> >>> On 01/03/2017 23:20, Andy Lutomirski wrote: On Wed, Mar 1, 2017 at 2:14 PM, Mickaël

Re: [Patch net] bonding: use ETH_MAX_MTU as max mtu

On 03/03/17 06:43, David Miller wrote: From: Cong Wang Date: Thu, 2 Mar 2017 12:24:36 -0800 This restores the ability of setting bond device's mtu to 9000. Fixes: 91572088e3fd ("net: use core MTU range checking in core net infra") Reported-by: daz...@gmail.com

Re: [kernel-hardening] [PATCH v5 06/10] seccomp,landlock: Handle Landlock events per process hierarchy

On 02/03/2017 11:22, Djalal Harouni wrote: > On Wed, Feb 22, 2017 at 2:26 AM, Mickaël Salaün wrote: >> The seccomp(2) syscall can be use to apply a Landlock rule to the >> current process. As with a seccomp filter, the Landlock rule is enforced >> for all its future children.

Re: [PATCH v5 06/10] seccomp,landlock: Handle Landlock events per process hierarchy

On 03/03/2017 01:55, Andy Lutomirski wrote: > On Thu, Mar 2, 2017 at 4:48 PM, Mickaël Salaün wrote: >> >> On 02/03/2017 17:36, Andy Lutomirski wrote: >>> On Wed, Mar 1, 2017 at 3:28 PM, Mickaël Salaün wrote: On 01/03/2017 23:20, Andy

Re: [PATCH v5 06/10] seccomp,landlock: Handle Landlock events per process hierarchy

On 02/03/2017 17:36, Andy Lutomirski wrote: > On Wed, Mar 1, 2017 at 3:28 PM, Mickaël Salaün wrote: >> >> >> On 01/03/2017 23:20, Andy Lutomirski wrote: >>> On Wed, Mar 1, 2017 at 2:14 PM, Mickaël Salaün wrote: On 28/02/2017 21:01, Andy Lutomirski

Re: [PATCH] netvsc: fix use-after-free in netvsc_change_mtu()

From: Dexuan Cui Date: Thu, 2 Mar 2017 13:00:53 + > 'nvdev' is freed in rndis_filter_device_remove -> netvsc_device_remove -> > free_netvsc_device, so we mustn't access it, before it's re-created in > rndis_filter_device_add -> netvsc_device_add. > > Signed-off-by:

Re: [PATCH net v4 0/2] net: ethernet: bgmac: bug fixes

On Thu, Mar 02, 2017 at 12:56:05PM -0800, David Miller wrote: > From: David Miller > Date: Thu, 02 Mar 2017 12:50:15 -0800 (PST) > > > From: Jon Mason > > Date: Tue, 28 Feb 2017 13:41:49 -0500 > > > >> Changes in v4: > >> * Added the udelays from

Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN

On Thu, 2017-03-02 at 23:22 +0100, Arnd Bergmann wrote: > On Thu, Mar 2, 2017 at 6:46 PM, Joe Perches wrote: > > On Thu, 2017-03-02 at 17:38 +0100, Arnd Bergmann wrote: > > > The internal logging infrastructure in ocfs2 causes special warning code > > > to be > > > used with

[PATCH net 2/2] nfp: correct DMA direction in XDP DMA sync

dma_sync_single_for_*() takes the direction in which the buffer was mapped, not the direction of the sync. We should sync XDP buffers bidirectionally. Fixes: ecd63a0217d5 ("nfp: add XDP support in the driver") Signed-off-by: Jakub Kicinski ---

[PATCH net 1/2] nfp: don't tell FW about the reserved buffer space

Since commit c0f031bc8866 ("nfp_net: use alloc_frag() and build_skb()") we are allocating buffers which have to hold both the data and skb to be created in place by build_skb(). FW should only be told about the buffer space it can DMA to, that is without the build_skb() headroom and tailroom.

Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN

On Thu, 2017-03-02 at 23:59 +0100, Arnd Bergmann wrote: > KASAN decides that passing a pointer to _m into an extern function > (_mlog_printk) is potentially dangerous, as that function might > keep a reference to that pointer after it goes out of scope, > or it might not know the correct length of

Re: [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE

On 03/02/2017 06:55 PM, Arnd Bergmann wrote: > On Thu, Mar 2, 2017 at 5:51 PM, Christian Borntraeger > wrote: >> On 03/02/2017 05:38 PM, Arnd Bergmann wrote: >>> >>> This attempts a rewrite of the two macros, using a simpler implementation >>> for the most common case of

Re: [Patch net v2] ipv6: ignore null_entry in inet6_rtm_getroute() too

From: Cong Wang Date: Wed, 1 Mar 2017 20:48:39 -0800 > Like commit 1f17e2f2c8a8 ("net: ipv6: ignore null_entry on route dumps"), > we need to ignore null entry in inet6_rtm_getroute() too. > > Return -ENETUNREACH here to sync with IPv4 behavior, as suggested by David.

[PATCH net] rxrpc: Fix potential NULL-pointer exception

Fix a potential NULL-pointer exception in rxrpc_do_sendmsg(). The call state check that I added should have gone into the else-body of the if-statement where we actually have a call to check. Found by CoverityScan CID#1414316 ("Dereference after null check"). Fixes: 540b1c48c37a ("rxrpc: Fix

[PATCH net] rxrpc: Fix potential NULL-pointer exception

Fix a potential NULL-pointer exception in rxrpc_do_sendmsg(). The call state check that I added should have gone into the else-body of the if-statement where we actually have a call to check. Found by CoverityScan CID#1414316 ("Dereference after null check"). Fixes: 540b1c48c37a ("rxrpc: Fix

[PATCH net v5 1/2] net: ethernet: bgmac: init sequence bug

Fix a bug in the 'bgmac' driver init sequence that blind writes for init sequence where it should preserve most bits other than the ones it is deliberately manipulating. The code now checks to see if the adapter needs to be brought out of reset (where as before it was doing an IDM write to bring

[PATCH net v5 2/2] net: ethernet: bgmac: mac address change bug

From: Hari Vyas ndo_set_mac_address() passes struct sockaddr * as 2nd parameter to bgmac_set_mac_address() but code assumed u8 *. This caused two bytes chopping and the wrong mac address was configured. Signed-off-by: Hari Vyas Signed-off-by: Jon Mason

Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN

On Thu, Mar 2, 2017 at 11:40 PM, Joe Perches wrote: > On Thu, 2017-03-02 at 23:22 +0100, Arnd Bergmann wrote: >> On Thu, Mar 2, 2017 at 6:46 PM, Joe Perches wrote: >> > On Thu, 2017-03-02 at 17:38 +0100, Arnd Bergmann wrote: >> > > The internal logging

[PATCH net v5 0/2] net: ethernet: bgmac: bug fixes

Changes in v5: * Rebased to the latest code and fixed up a compile error due to the mac_addr struct going away (found by David Miller) Changes in v4: * Added the udelays from the previous code (per David Miller) Changes in v3: * Reworked the init sequence patch to only remove the device reset

[PATCH] xen-netback: fix race condition on XenBus disconnect

In some cases during XenBus disconnect event handling and subsequent queue resource release there may be some TX handlers active on other processors. Use RCU in order to synchronize with them. Signed-off-by: Igor Druzhinin --- drivers/net/xen-netback/interface.c | 13

Re: [PATCH v2] net: pch_gbe: Fix TX RX descriptor accesses for big endian systems

From: Hassan Naveed Date: Tue, 28 Feb 2017 18:13:22 -0800 > Fix pch_gbe driver for ethernet operations for a big endian CPU. > Values written to and read from transmit and receive descriptors > in the pch_gbe driver are byte swapped from the perspective of a > big

Re: pull-request: wireless-drivers 2017-03-02

From: Kalle Valo Date: Thu, 02 Mar 2017 11:15:42 +0200 > only one patch this time, the new version of ath10k patch we reverted > earlier. I was supposed to send you this earlier but it got delayed > because I'm on vacation, so sorry about that. I'm hoping this is ok to >

Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN

On Thu, Mar 2, 2017 at 6:46 PM, Joe Perches wrote: > On Thu, 2017-03-02 at 17:38 +0100, Arnd Bergmann wrote: >> The internal logging infrastructure in ocfs2 causes special warning code to >> be >> used with KASAN, which produces rather large stack frames: > >> fs/ocfs2/super.c:

Re: pull-request: mac80211 2017-03-02

From: Johannes Berg Date: Thu, 2 Mar 2017 11:34:42 +0100 > As I mentioned in my other pull request, here's the change > for the average.h to make the precision easier to use. > > Please pull and let me know if there's any problem. Pulled, thanks Johannes.

Re: [Patch net] bonding: use ETH_MAX_MTU as max mtu

Cong Wang wrote: >This restores the ability of setting bond device's mtu to 9000. > >Fixes: 91572088e3fd ("net: use core MTU range checking in core net infra") >Reported-by: daz...@gmail.com >Reported-by: Brad Campbell >Cc: Jarod Wilson

Re: [Bug 194749] New: kernel bonding does not work in a network nameservice in versions above 3.10.0-229.20.1

- On Mar 2, 2017, at 3:11 PM, Cong Wang xiyou.wangc...@gmail.com wrote > On Thu, Mar 2, 2017 at 10:32 AM, Stephen Hemminger > wrote: >> >> >> Begin forwarded message: >> >> Date: Wed, 01 Mar 2017 21:08:01 + >> From: bugzilla-dae...@bugzilla.kernel.org >> To:

Re: [PATCH] drivers: net: ethernet: remove incorrect __exit markups

From: Dmitry Torokhov Date: Wed, 1 Mar 2017 17:24:47 -0800 > Even if bus is not hot-pluggable, devices can be unbound from the > driver via sysfs, so we should not be using __exit annotations on > remove() methods. The only exception is drivers registered with >

Re: [PATCH 1/2] dccp: Unlock sock before calling sk_free()

From: Arnaldo Carvalho de Melo Date: Wed, 1 Mar 2017 16:35:07 -0300 > From: Arnaldo Carvalho de Melo > > The code where sk_clone() came from created a new socket and locked it, > but then, on the error path didn't unlock it. > > This problem stayed there for

Re: [PATCH 2/2] net: Introduce sk_clone_lock() error path routine

From: Arnaldo Carvalho de Melo Date: Wed, 1 Mar 2017 16:35:08 -0300 > From: Arnaldo Carvalho de Melo > > When handling problems in cloning a socket with the sk_clone_locked() > function we need to perform several steps that were open coded in it and > its

Re: [PATCH net v1 0/3] amd-xgbe: AMD XGBE driver fixes 2017-02-28

From: Tom Lendacky Date: Thu, 2 Mar 2017 15:32:29 -0600 > On 3/2/2017 3:02 PM, David Miller wrote: >> From: Tom Lendacky >> Date: Tue, 28 Feb 2017 15:02:42 -0600 >> >>> This patch series addresses some issues in the AMD XGBE driver. >>> >>> The

Re: [PATCH net v1 0/3] amd-xgbe: AMD XGBE driver fixes 2017-02-28

On 3/2/2017 3:02 PM, David Miller wrote: From: Tom Lendacky Date: Tue, 28 Feb 2017 15:02:42 -0600 This patch series addresses some issues in the AMD XGBE driver. The following fixes are included in this driver update series: - Stop the PHY before disabling and

Re: [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE

On Thu, Mar 2, 2017 at 8:00 PM, Christian Borntraeger wrote: > On 03/02/2017 06:55 PM, Arnd Bergmann wrote: >> On Thu, Mar 2, 2017 at 5:51 PM, Christian Borntraeger >> wrote: >>> On 03/02/2017 05:38 PM, Arnd Bergmann wrote: This attempts

Re: [net/bpf] 3051bf36c2 BUG: unable to handle kernel paging request at 0000a7cf

On 03/02/2017 09:23 PM, Fengguang Wu wrote: [...] I confirm that the below patch provided by Daniel fixes the above issues on mainline kernel, too. Where should this patch be sent to? If nobody objects, I could send it to -net tree via Dave due to being BPF related, but I don't mind sending it

Re: [PATCH] Net: openvswitch: actions: fixed a brace coding style warning

From: Peter Downs Date: Wed, 1 Mar 2017 01:01:17 -0800 > Fixed a brace coding style warning reported by checkpatch.pl > > Signed-off-by: Peter Downs Applied.

Re: [PATCH 0/2] pull request for net: batman-adv 2017-03-01

From: Simon Wunderlich Date: Wed, 1 Mar 2017 16:53:31 +0100 > here are two bugfixes which we would like to see integrated into net. > > Please pull or let me know of any problem! Pulled, thanks Simon.

Re: [PATCH net] cxgb4: update latest firmware version supported

From: Ganesh Goudar Date: Wed, 1 Mar 2017 11:18:53 +0530 > Change t4fw_version.h to update latest firmware version > number to 1.16.33.0. > > Signed-off-by: Ganesh Goudar Applied.

Re: [PATCH net v4 0/2] net: ethernet: bgmac: bug fixes

From: David Miller Date: Thu, 02 Mar 2017 12:50:15 -0800 (PST) > From: Jon Mason > Date: Tue, 28 Feb 2017 13:41:49 -0500 > >> Changes in v4: >> * Added the udelays from the previous code (per David Miller) >> >> Changes in v3: >> * Reworked the

Re: [PATCH-v4-RESEND 1/4] vsock: track pkt owner vsock

From: Peng Tao Date: Wed, 1 Mar 2017 11:56:24 +0800 > So that we can cancel a queued pkt later if necessary. > > Reviewed-by: Stefan Hajnoczi > Signed-off-by: Peng Tao > --- > include/linux/virtio_vsock.h| 2 ++ >

Re: [PATCH net v1 0/3] amd-xgbe: AMD XGBE driver fixes 2017-02-28

From: Tom Lendacky Date: Tue, 28 Feb 2017 15:02:42 -0600 > This patch series addresses some issues in the AMD XGBE driver. > > The following fixes are included in this driver update series: > > - Stop the PHY before disabling and releasing device interrupts so that >

Re: [PATCH] drivers: net: xgene: Fix crash on DT systems

From: Alban Bedel Date: Tue, 28 Feb 2017 18:08:55 +0100 > On DT systems the driver require a clock, but the probe just print a > warning and continue, leading to a crash when resetting the device. > To fix this crash and properly handle probe deferals only ignore

Re: [PATCH net v4 0/2] net: ethernet: bgmac: bug fixes

From: Jon Mason Date: Tue, 28 Feb 2017 13:41:49 -0500 > Changes in v4: > * Added the udelays from the previous code (per David Miller) > > Changes in v3: > * Reworked the init sequence patch to only remove the device reset if > the device is actually in reset. Given

Re: [Patch net v3] ipv6: check for ip6_null_entry in __ip6_del_rt_siblings()

From: David Ahern Date: Wed, 1 Mar 2017 15:03:45 -0800 > On 2/27/17 4:07 PM, Cong Wang wrote: >> Andrey reported a NULL pointer deref bug in ipv6_route_ioctl() >> -> ip6_route_del() -> __ip6_del_rt_siblings() code path. This is >> because ip6_null_entry is returned in

Re: [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE

On 03/02/2017 05:38 PM, Arnd Bergmann wrote: > When CONFIG_KASAN is enabled, the READ_ONCE/WRITE_ONCE macros cause > rather large kernel stacks, e.g.: > > mm/vmscan.c: In function 'shrink_page_list': > mm/vmscan.c:1333:1: error: the frame size of 3456 bytes is larger than 3072 > bytes

[PATCH] fjes: Do not load fjes driver if system does not have extended socket device.

The fjes driver is used only by FUJITSU servers and almost of all servers in the world never use it. But currently if ACPI PNP0C02 is defined in the ACPI table, the following message is always shown: "FUJITSU Extended Socket Network Device Driver - version 1.2 - Copyright (c) 2015 FUJITSU

[PATCH net 1/2] xen-netback: keep a local pointer for vif in backend_disconnect()

This patch replaces use of 'be->vif' with 'vif' and hence generally makes the function look tidier. No semantic change. Signed-off-by: Paul Durrant --- Cc: Wei Liu --- drivers/net/xen-netback/xenbus.c | 32 ++-- 1 file

[Patch net] bonding: use ETH_MAX_MTU as max mtu

This restores the ability of setting bond device's mtu to 9000. Fixes: 91572088e3fd ("net: use core MTU range checking in core net infra") Reported-by: daz...@gmail.com Reported-by: Brad Campbell Cc: Jarod Wilson Signed-off-by: Cong Wang

[PATCH 22/26] drm/i915/gvt: don't overflow the kernel stack with KASAN

Enabling CONFIG_KASAN can lead to an instant stack overflow: drivers/gpu/drm/i915/gvt/handlers.c: In function 'init_generic_mmio_info': drivers/gpu/drm/i915/gvt/handlers.c:2200:1: error: the frame size of 30464 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]

Re: [net/bpf] 3051bf36c2 BUG: unable to handle kernel paging request at 0000a7cf

On Wed, Mar 01, 2017 at 08:54:26PM +0800, Fengguang Wu wrote: Hi all, Is it BPF triggering BUGs all over the places? It looks so, and here is a fix. 1e74a2eb1f Merge tag 'gcc-plugins-v4.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux 005c3490e9 Revert "ath10k: Search

Re: [PATCH] iproute2: show network device dependency tree

On Wed, 2017-03-01 at 11:22 +0100, Jiri Benc wrote: > On Tue, 28 Feb 2017 20:07:37 +, Zaboj Campula wrote: > > Well it is impossible to draw a simple tree showing the configuration > > exactly with all details. May be it is too ambitious to draw a tree > > at all. > > I tried that and failed.

Re: Fw: [Bug 194749] New: kernel bonding does not work in a network nameservice in versions above 3.10.0-229.20.1

On Thu, Mar 2, 2017 at 10:32 AM, Stephen Hemminger wrote: > > > Begin forwarded message: > > Date: Wed, 01 Mar 2017 21:08:01 + > From: bugzilla-dae...@bugzilla.kernel.org > To: step...@networkplumber.org > Subject: [Bug 194749] New: kernel bonding does not work in

[PATCH 24/26] ocfs2: reduce stack size with KASAN

The internal logging infrastructure in ocfs2 causes special warning code to be used with KASAN, which produces rather large stack frames: fs/ocfs2/super.c: In function 'ocfs2_fill_super': fs/ocfs2/super.c:1219:1: error: the frame size of 3264 bytes is larger than 3072 bytes

Re: net/sctp: use-after-free in sctp_association_put

On Thu, Mar 2, 2017 at 9:06 AM, Xin Long wrote: > On Thu, Mar 2, 2017 at 3:18 AM, Dmitry Vyukov wrote: >> Hello, >> >> I've got the following report while running syzkaller fuzzer on >> linux-next/8813198236a044b76e251dcae937b180dd527999: >> >> BUG:

Re: [PATCH 7/7] net: stmmac: dwc-qos: Add Tegra186 support

Às 5:24 PM de 2/23/2017, Thierry Reding escreveu: > From: Thierry Reding > > The NVIDIA Tegra186 SoC contains an instance of the Synopsys DWC > ethernet QOS IP core. The binding that it uses is slightly different > from existing ones because of the integration (clocks,

Re: [PATCH RFC v2 00/12] socket sendmsg MSG_ZEROCOPY

On Tue, Feb 28, 2017 at 7:28 PM, David Miller wrote: > From: Andy Lutomirski > Date: Tue, 28 Feb 2017 13:06:49 -0800 > >> On Tue, Feb 28, 2017 at 12:43 PM, Willem de Bruijn >> wrote: >>> On Tue, Feb 28, 2017 at 2:46 PM,

Re: commit a52ad514fdf3b8a57ca4322c92d2d8d5c6182485 net: deprecate eth_change_mtu, remove usage breaks bonding on my machine

On Wed, Mar 1, 2017 at 8:11 AM, Brad Campbell wrote: > G'day Jarod, > > I have a pair of machines that are linked by a pair of quad port e1000 cards > with all 4 ports bonded. The network is configured with an mtu of 9000. > > Kernel 4.10 fails to bring these interfaces

[PATCH 23/26] mtd: cfi: reduce stack size with KASAN

When CONFIG_KASAN is used, we consume a lot of extra stack space: drivers/mtd/chips/cfi_cmdset_0020.c: In function 'do_write_buffer': drivers/mtd/chips/cfi_cmdset_0020.c:603:1: error: the frame size of 2080 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]

Re: Removing GENL_ID_GENERATE breaks userspace API

On Thu, 2017-03-02 at 17:50 +0100, Marcel Holtmann wrote: > Hi Johannes, > > you have removed GENL_ID_GENERATE in 4.10, but that is actually > breaking userspace API. > > commit a07ea4d9941af5a0c6f0be2a71b51ac9c083c5e5 > Author: Johannes Berg > Date:   Mon Oct 24

Fw: [Bug 194763] New: bond0 fails to accept MTU change.

Begin forwarded message: Date: Thu, 02 Mar 2017 11:22:24 + From: bugzilla-dae...@bugzilla.kernel.org To: step...@networkplumber.org Subject: [Bug 194763] New: bond0 fails to accept MTU change. https://bugzilla.kernel.org/show_bug.cgi?id=194763 Bug ID: 194763

Fw: [Bug 194749] New: kernel bonding does not work in a network nameservice in versions above 3.10.0-229.20.1

Begin forwarded message: Date: Wed, 01 Mar 2017 21:08:01 + From: bugzilla-dae...@bugzilla.kernel.org To: step...@networkplumber.org Subject: [Bug 194749] New: kernel bonding does not work in a network nameservice in versions above 3.10.0-229.20.1

[PATCH net 2/2] xen-netback: don't vfree() queues under spinlock

This leads to a BUG of the following form: [ 174.512861] switch: port 2(vif3.0) entered disabled state [ 174.522735] BUG: sleeping function called from invalid context at /home/build/linux-linus/mm/vmalloc.c:1441 [ 174.523451] in_atomic(): 1, irqs_disabled(): 0, pid: 28, name: xenwatch [

[PATCH net 0/2] xen-netback: update memory leak fix to avoid BUG

Commit 9a6cdf52b85e "xen-netback: fix memory leaks on XenBus disconnect" added missing code to fix a memory leak by calling vfree() in the appropriate place. Unfortunately subsequent commit f16f1df65f1c "xen-netback: protect resource cleaning on XenBus disconnect" then wrapped this call to vfree()

Fw: [Bug 194723] connect() to localhost stalls after 4.9 -> 4.10 upgrade

Begin forwarded message: Date: Wed, 01 Mar 2017 12:04:45 + From: bugzilla-dae...@bugzilla.kernel.org To: step...@networkplumber.org Subject: [Bug 194723] connect() to localhost stalls after 4.9 -> 4.10 upgrade https://bugzilla.kernel.org/show_bug.cgi?id=194723 --- Comment #2 from Lutz

[PATCH 20/26] [media] em28xx: split up em28xx_dvb_init to reduce stack size

With CONFIG_KASAN, the init function uses a large amount of kernel stack: drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init': drivers/media/usb/em28xx/em28xx-dvb.c:2069:1: error: the frame size of 4280 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] By splitting

[PATCH 18/26] [media] i2c: cx25840: avoid stack overflow with KASAN

With CONFIG_KASAN, this driver has shown a ridiculously large stack frame in one configuration: drivers/media/i2c/cx25840/cx25840-core.c:4960:1: error: the frame size of 94000 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] In most builds, it's only about 3300 bytes, but that's

Re: BUG due to "xen-netback: protect resource cleaning on XenBus disconnect"

On 03/02/2017 06:56 AM, Juergen Gross wrote: > With commits f16f1df65 and 9a6cdf52b we get in our Xen testing: > > [ 174.512861] switch: port 2(vif3.0) entered disabled state > [ 174.522735] BUG: sleeping function called from invalid context at > /home/build/linux-linus/mm/vmalloc.c:1441 > [

Re: [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE

On Thu, Mar 2, 2017 at 5:51 PM, Christian Borntraeger wrote: > On 03/02/2017 05:38 PM, Arnd Bergmann wrote: >> >> This attempts a rewrite of the two macros, using a simpler implementation >> for the most common case of having a naturally aligned 1, 2, 4, or (on >> 64-bit

Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN

On Thu, 2017-03-02 at 17:38 +0100, Arnd Bergmann wrote: > The internal logging infrastructure in ocfs2 causes special warning code to be > used with KASAN, which produces rather large stack frames: > fs/ocfs2/super.c: In function 'ocfs2_fill_super': > fs/ocfs2/super.c:1219:1: error: the frame

[PATCH 16/26] [media] i2c: adv7604: mark register access as noinline_for_kasan

When building with KASAN, we get a stack frame size warning about a function that could potentially cause a stack overflow: drivers/media/i2c/adv7604.c: In function 'adv76xx_log_status': drivers/media/i2c/adv7604.c:2615:1: error: the frame size of 3248 bytes is larger than 3072 bytes

[PATCH 10/26] brcmsmac: reindent split functions

In the previous commit I left the indentation alone to help reviewing the patch, this one now runs the three new functions through 'indent -kr -8' with some manual fixups to avoid silliness. No changes other than whitespace are intended here. Signed-off-by: Arnd Bergmann ---

[PATCH 11/26] rtlwifi: reduce stack usage for KASAN

When CONFIG_KASAN is set, we use a large amount of stack in the btcoexist code, presumably due to lots of inlining of functions that each add to the kernel stack. net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c:3762:1: error: the frame size of 4032 bytes is larger than 3072 bytes

Re: [PATCH 6/7] net: stmmac: dwc-qos: Split out ->probe() and ->remove()

Às 5:24 PM de 2/23/2017, Thierry Reding escreveu: > From: Thierry Reding > > Split out the binding specific parts of ->probe() and ->remove() to > enable the driver to support variants of the binding. This is useful in > order to keep backwards-compatibility while making it

[PATCH 04/26] tty: kbd: reduce stack size with KASAN

As reported by kernelci, some functions in the VT code use significant amounts of kernel stack when local variables get inlined into the caller multiple times: drivers/tty/vt/keyboard.c: In function 'kbd_keycode': drivers/tty/vt/keyboard.c:1452:1: error: the frame size of 2240 bytes is larger

[PATCH 08/26] brcmsmac: make some local variables 'static const' to reduce stack size

With KASAN and a couple of other patches applied, this driver is one of the few remaining ones that actually use more than 2048 bytes of kernel stack: broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy_gainctrl': broadcom/brcm80211/brcmsmac/phy/phy_n.c:16065:1:

[PATCH 00/26] bring back stack frame warning with KASAN

It took a long while to get this done, but I'm finally ready to send the first half of the KASAN stack size patches that I did in response to the kernelci.org warnings. As before, it's worth mentioning that things are generally worse with gcc-7.0.1 because of the addition of

Re: [PATCH] netvsc: fix use-after-free in netvsc_change_mtu()

On Thu, 2 Mar 2017 13:00:53 + Dexuan Cui wrote: > 'nvdev' is freed in rndis_filter_device_remove -> netvsc_device_remove -> > free_netvsc_device, so we mustn't access it, before it's re-created in > rndis_filter_device_add -> netvsc_device_add. > > Signed-off-by: Dexuan

[PATCH 07/26] brcmsmac: reduce stack size with KASAN

The wlc_phy_table_write_nphy/wlc_phy_table_read_nphy functions always put an object on the stack, which will each require a redzone with KASAN and lead to possible stack overflow: drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy':

[PATCH 12/26] wl3501_cs: reduce stack size for KASAN

Inlining functions with local variables can lead to excessive stack usage with KASAN: drivers/net/wireless/wl3501_cs.c: In function 'wl3501_rx_interrupt': drivers/net/wireless/wl3501_cs.c:1103:1: error: the frame size of 2232 bytes is larger than 1536 bytes [-Werror=frame-larger-than=] Marking

[PATCH 03/26] typecheck.h: avoid local variables in typecheck() macro

With KASAN enabled, the typecheck macro leads to some serious stack memory, as seen in the rt2xxx drivers: drivers/net/wireless/ralink/rt2x00/rt2800lib.c: In function 'rt2800_init_registers': drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5068:1: error: the frame size of 23768 bytes is larger

[PATCH 06/26] rocker: mark rocker_tlv_put_* functions as noinline_for_kasan

Inlining these functions creates lots of stack variables when KASAN is enabled, leading to this warning about potential stack overflow: drivers/net/ethernet/rocker/rocker_ofdpa.c: In function 'ofdpa_cmd_flow_tbl_add': drivers/net/ethernet/rocker/rocker_ofdpa.c:621:1: error: the frame size of

[PATCH 05/26] netlink: mark nla_put_{u8,u16,u32} noinline_for_kasan

When CONFIG_KASAN is enabled, the "--param asan-stack=1" causes rather large stack frames in some functions. This goes unnoticed normally because CONFIG_FRAME_WARN is disabled with CONFIG_KASAN by default as of commit 3f181b4d8652 ("lib/Kconfig.debug: disable -Wframe-larger-than warnings with

[PATCH 01/26] compiler: introduce noinline_for_kasan annotation

When CONFIG_KASAN is set, we can run into some code that uses incredible amounts of kernel stack: drivers/staging/dgnc/dgnc_neo.c:1056:1: error: the frame size of 2 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] drivers/media/i2c/cx25840/cx25840-core.c:4960:1: error: the frame

[PATCH 09/26] brcmsmac: split up wlc_phy_workarounds_nphy

The stack consumption in this driver is still relatively high, with one remaining warning if the warning level is lowered to 1536 bytes: drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:17135:1: error: the frame size of 1880 bytes is larger than 1536 bytes

[PATCH 15/26] [media] tuners: i2c: reduce stack usage for tuner_i2c_xfer_*

When CONFIG_KASAN is enabled, we see very large stack usage in some functions, e.g.: drivers/media/tuners/tda8290.c: In function 'tda8290_set_params': drivers/media/tuners/tda8290.c:310:1: warning: the frame size of 3184 bytes is larger than 1024 bytes [-Wframe-larger-than=]

[PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE

When CONFIG_KASAN is enabled, the READ_ONCE/WRITE_ONCE macros cause rather large kernel stacks, e.g.: mm/vmscan.c: In function 'shrink_page_list': mm/vmscan.c:1333:1: error: the frame size of 3456 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] block/cfq-iosched.c: In function

[PATCH 13/26] rtl8180: reduce stack size for KASAN

When CONFIG_KASAN is set, we see overly large stack frames from inlining functions with local variables: drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c: In function 'rtl8225se_rf_init': drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c:431:1: warning: the frame size of 4384

  1   2   >