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 memory. Additionally
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 +-
net/rds/tcp.c | 6 +-
net/rds/transport.c | 4 +---
4 files
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, na
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.
asoc->force
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
http://lkml.iu.edu/hypermail/linux/kernel/1702.1/053
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 fuzzer on
>>> linux-next/8813198236a044b76e251dcae937b180dd52799
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 cos
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 connect() with AF_UNSPEC to disconnect the
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 after null check").
>
>
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 ac
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 increases to 384 with a 128B cache
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 via ethtool.
Signed
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
Applied.
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
> Cc: Jarod Wilson
> Signed-off-by
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
>> ---
>> include/linux/virtio_vsock.h| 2 ++
>> ne
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 Salaün wrote:
>
> On 28/02/2
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
Reported-by: Brad Campbell
Cc:
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. An inherited rule t
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 Lutomirski wrote:
> On Wed, Mar 1, 2017 at
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 wrote:
> On Tue, Feb 21, 2017 at 5
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: Dexuan Cui
Applied.
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 the previous code (per David Miller)
> >>
> >>
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 KASAN, which produces
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
---
drivers/net/ethernet/netronome/nfp/nfp_net_common.c
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. Not
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
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 having a naturally aligned
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.
>
> Fixes: a1a22c1206 ("n
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 dea
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 dea
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 i
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
Fixes: 4e209001b86 ("bgmac: write mac ad
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 infrastructure in ocfs2 causes special warni
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 i
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 -
drivers/net/x
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 endian CPU, since the ethernet c
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
> take also even the merge
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: In function 'ocfs2
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.
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
>Signed-off-by: Cong Wang
>---
> drivers/net/bonding/bond
- 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: step...@networkplumber.org
>>
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
> platform_driver_probe() which spec
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 a long while, till b0691c8ee7c2 ("
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 callers, so introduce a routine to avo
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 following fixes are included in this driver update
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 releasing device interrupts so
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 a rewrite of the two macros, using a simpler impl
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
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.
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.
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.
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 init sequence patch to only remove the device res
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 ++
> net/vmw_vsock/virtio_transport_common.c | 7 +++
> 2 files cha
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
> MDIO requests issued by t
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 the
> missing clock if DT isn't u
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 that this code doesn't bea
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 this path since ip6_null_ent
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 [-Werror=fr
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 LIMI
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 changed, 18 insertions(+), 14 deletions(-)
diff
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
---
drivers/net/bonding/bond_main.c | 1 +
1 file change
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=]
drivers/gpu/drm/i915/gvt/
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 S
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.
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 a network
> nameservice in v
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 [-Werror=frame-larger-
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: KASAN: use-after-free in sctp_association_destr
À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, resets, ...).
>
> Signed-o
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, Andy Lutomirski
>>> wrote:
On Mon, Feb 27, 2017 at 10:57 AM, Michael
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 up as it fails when trying
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=]
drivers/mtd/chips/cfi_cmdset_
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 14:40:02 2016 +0200
>
> gen
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
Summary
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
https://bugzilla.kernel.org/show_bug.cgi?i
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
[ 174.5
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()
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 Vie
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 ou
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 stil
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
> [ 174
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 architectures) 8 byte obj
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 size
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
---
.../broadcom/brcm80
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
net/wir
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 [-Werror=fra
À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 easy for a sub-
> driv
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
tha
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: warning
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 -fsanitize-address-use
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 Cui
> Cc: "K. Y. Sri
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':
drivers/net/wi
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 a
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 th
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 2752
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
KASAN
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 s
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
[-Werror=frame-larger-than=
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=]
drivers/media/tuners/
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 'cfqg_
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 byte
1 - 100 of 155 matches
Mail list logo
