I'm working with Aquantia to add a new 2.5/5 Gbps driver to the kernel.
It looks like it's going to one of the biggest drivers in
drivers/net/ethernet. The team that developed the driver is new to
kernel development processes, but are working to make it
checkpatch-clean and addressing sparse issues
We recently encountered a bug where a few customers using ibmveth on the
same LPAR hit an issue where a TCP session hung when large receive was
enabled. Closer analysis revealed that the session was stuck because the
one side was advertising a zero window repeatedly.
We narrowed this down to the
Just a leftover from the last development cycle.
1) Remove some unused code, from Florian Westphal.
Please pull or let me know if there are problems.
Thanks!
The following changes since commit 31fbe81fe3426dfb7f8056a7f5106c6b1841a9aa:
Merge branch 'qcom-emac-acpi' (2016-09-29 01:50:20 -0400)
From: Florian Westphal
Not used anymore since 2009 (9e0d57fd6dad37,
'xfrm: SAD entries do not expire correctly after suspend-resume').
Signed-off-by: Florian Westphal
Signed-off-by: Steffen Klassert
---
net/xfrm/xfrm_state.c | 8
1 file changed, 8 deletions(-)
diff --git a/net/xfrm/
On Mon, Oct 24, 2016 at 02:42:26PM +0200, Stefan Richter wrote:
> Fixes: d894be57ca92('ethernet: use net core MTU range checking in more
> drivers')
> CC: Jarod Wilson
> CC: Thomas Falcon
> Signed-off-by: Stefan Richter
Wuf. Thank you, Stefan. Way too many bleeding eyeball hours staring at all
On Mon, Oct 24, 2016 at 02:26:13PM +0200, Stefan Richter wrote:
> firewire-net, like the older eth1394 driver, reduced the initial MTU to
> less than 1500 octets if the local link layer controller's asynchronous
> packet reception limit was lower.
>
> This is bogus, since this reception limit does
From: Vidya Sagar Ravipati
Forward Error Correction (FEC) modes i.e Base-R
and Reed-Solomon modes are introduced in 25G/40G/100G standards
for providing good BER at high speeds.
Various networking devices which support 25G/40G/100G provides ability
to manage supported FEC modes and the lack of FE
From: Manfred Schlaegl Sent: Monday, October
24, 2016 10:43 PM
> To: Andy Duan
> Cc: netdev@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH] net: fec: hard phy reset on open
>
> On 2016-10-24 16:03, Andy Duan wrote:
> > From: manfred.schla...@gmx.at Sent:
> Monday,
> > Oct
No one can see these events, because a network namespace can not be
destroyed, if it has sockets.
Unlike other devices, uevent-s for network devices are generated
only inside their network namespaces. They are filtered in
kobj_bcast_filter()
My experiments shows that net namespaces are destroyed
From: Andrey Vagin
Each socket operates in a network namespace where it has been created,
so if we want to dump and restore a socket, we have to know its network
namespace.
We have a socket_diag to get information about sockets, it doesn't
report sockets which are not bound or connected.
This p
Hi Andrew,
On 2016/10/24 23:32, Andrew Lunn wrote:
> On Mon, Oct 24, 2016 at 07:50:12PM +0800, Dongpo Li wrote:
>> Hello
>>
>> We encountered a multicast problem when two set-top box(STB) join the same
>> multicast group and leave.
>> The two boxes can join the same multicast group
>> but only on
On Sun, Oct 23, 2016 at 06:51:53PM -0700, Shrijeet Mukherjee wrote:
>
> The main goal of this patch was to start that discussion. My v2 patch
> rejects the ndo op if neither of rx_mergeable or big_buffers are set.
> Does that sound like a good tradeoff ? Don't know enough about who
> turns these f
From: Jamal Hadi Salim
Daniel says:
While trying out [1][2], I noticed that tc monitor doesn't show the
correct handle on delete:
$ tc monitor
qdisc clsact : dev eno1 parent :fff1
filter dev eno1 ingress protocol all pref 49152 bpf handle 0x2a [...]
deleted filter dev eno1 ingress proto
From: Colin Ian King
trivial fix to spelling mistake in dev_err message
Signed-off-by: Colin Ian King
---
drivers/net/ethernet/broadcom/bgmac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac.c
b/drivers/net/ethernet/broadcom/bgmac.c
ind
gcc warns about an uninitialized pointer dereference in the vlan
priority handling:
net/core/flow_dissector.c: In function '__skb_flow_dissect':
net/core/flow_dissector.c:281:61: error: 'vlan' may be used uninitialized in
this function [-Werror=maybe-uninitialized]
As pointed out by Jiri Pirko,
On Monday, October 24, 2016 10:47:54 PM CEST Julian Anastasov wrote:
> > diff --git a/net/netfilter/ipvs/ip_vs_sync.c
> > b/net/netfilter/ipvs/ip_vs_sync.c
> > index 1b07578bedf3..9350530c16c1 100644
> > --- a/net/netfilter/ipvs/ip_vs_sync.c
> > +++ b/net/netfilter/ipvs/ip_vs_sync.c
> > @@ -283,6
On Mon, Oct 24, 2016 at 1:10 PM, Cong Wang wrote:
> On Mon, Oct 24, 2016 at 12:11 PM, Oliver Hartkopp
> wrote:
>> if (proc_dir) {
>> /* unique socket address as filename */
>> sprintf(bo->procname, "%lu", sock_i_ino(sk));
>> bo->bcm_proc_rea
On Mon, Oct 24, 2016 at 12:11 PM, Oliver Hartkopp
wrote:
> if (proc_dir) {
> /* unique socket address as filename */
> sprintf(bo->procname, "%lu", sock_i_ino(sk));
> bo->bcm_proc_read = proc_create_data(bo->procname, 0644,
>
Hello,
On Mon, 24 Oct 2016, Arnd Bergmann wrote:
> Building the ip_vs_sync code with CONFIG_OPTIMIZE_INLINING on x86
> confuses the compiler to the point where it produces a rather
> dubious warning message:
>
> net/netfilter/ipvs/ip_vs_sync.c:1073:33: error: ‘opt.init_seq’ may be used
Hi Andrey,
On Mon, Oct 24, 2016 at 05:30:04PM +0200, Andrey Konovalov wrote:
> The problem is that sctp_walk_errors walks the chunk before its length
> is checked for overflow.
Exactly. The check is done too late, for the 2nd and subsequent chunks
only.
Please try the following patch, thanks. Not
On Mon, Oct 24, 2016 at 11:27 AM, David Miller wrote:
> From: Alexander Duyck
> Date: Mon, 24 Oct 2016 08:06:07 -0400
>
>> This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
>> avoid invoking cache line invalidation if the driver will just handle it
>> via a sync_for_cpu or s
Similar to IPv4, do not consider link state when validating next hops.
Currently, if the link is down default routes can fail to insert:
$ ip -6 ro add vrf blue default via 2100:2::64 dev eth2
RTNETLINK answers: No route to host
With this patch the command succeeds.
Fixes: 8c14586fc320 ("net:
On Mon, Oct 24, 2016 at 11:09 AM, Konrad Rzeszutek Wilk
wrote:
> On Mon, Oct 24, 2016 at 08:04:37AM -0400, Alexander Duyck wrote:
>> As a first step to making DMA_ATTR_SKIP_CPU_SYNC apply to architectures
>> beyond just ARM I need to make it so that the swiotlb will respect the
>> flag. In order
Andrey Konovalov reported an issue with proc_register in bcm.c.
As suggested by Cong Wang this patch adds a lock_sock() protection and
a check for unsuccessful proc_create_data() in bcm_connect().
Reference: http://marc.info/?l=linux-netdev&m=147732648731237
Reported-by: Andrey Konovalov
Suggest
Around Mon 24 Oct 2016 08:04:53 -0400 or thereabout, Alexander Duyck wrote:
> The use of DMA_ATTR_SKIP_CPU_SYNC was not consistent across all of the DMA
> APIs in the arch/arm folder. This change is meant to correct that so that
> we get consistent behavior.
Looks good (-:
> Cc: Haavard Skinnemo
From: Alexander Duyck
Date: Mon, 24 Oct 2016 08:06:07 -0400
> This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
> avoid invoking cache line invalidation if the driver will just handle it
> via a sync_for_cpu or sync_for_device call.
>
> Cc: "David S. Miller"
> Cc: sparcli.
Hello Andrey, hello Cong,
thanks for catching this issue.
I added lock_sock() and a check for a failing proc_create_data() below.
Can you please check if it solved the issue?
I tested the patched version with the stress tool as advised by Andrey
and did not see any problems in dmesg anymore.
This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
via a sync_for_cpu or sync_for_device call.
Cc: "David S. Miller"
Cc: sparcli...@vger.kernel.org
Signed-off-by: Alexander Duyck
---
arch/sparc/kernel/
This patch adds a function that allows us to batch free a page that has
multiple references outstanding. Specifically this function can be used to
drop a page being used in the page frag alloc cache. With this drivers can
make use of functionality similar to the page frag alloc cache without
havi
On Mon, Oct 24, 2016 at 08:04:31AM -0400, Alexander Duyck wrote:
> There are no users for swiotlb_map_sg so we might as well just drop it.
>
> Cc: Konrad Rzeszutek Wilk
Acked-by: Konrad Rzeszutek Wilk
Thought I swear I saw a familiar patch by Christopher Hellwig at some point..
but maybe that
This reverts commit f9d40f6a9921 ("igb: Revert support for build_skb in
igb") and adds a few changes to update it to work with the latest version
of igb. We are now able to revert the removal of this due to the fact
that with the recent changes to the page count and the use of
DMA_ATTR_SKIP_CPU_SYN
Add support for mapping and unmapping a page with attributes. The primary
use for this is currently to allow for us to pass the
DMA_ATTR_SKIP_CPU_SYNC attribute when mapping and unmapping a page. On
some architectures such as ARM the synchronization has significant overhead
and if we are already
This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
via a sync_for_cpu or sync_for_device call.
Cc: Chris Metcalf
Signed-off-by: Alexander Duyck
---
arch/tile/kernel/pci-dma.c | 12 ++--
1 fil
The ARM architecture provides a mechanism for deferring cache line
invalidation in the case of map/unmap. This patch makes use of this
mechanism to avoid unnecessary synchronization.
A secondary effect of this change is that the portion of the page that has
been synchronized for use by the CPU sh
This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
via a sync_for_cpu or sync_for_device call.
Cc: Jonas Bonn
Signed-off-by: Alexander Duyck
---
arch/openrisc/kernel/dma.c |3 +++
1 file changed, 3
This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
later via a sync_for_cpu or sync_for_device call.
Cc: Richard Kuo
Cc: linux-hexa...@vger.kernel.org
Signed-off-by: Alexander Duyck
---
arch/hexagon/ke
The use of DMA_ATTR_SKIP_CPU_SYNC was not consistent across all of the DMA
APIs in the arch/arm folder. This change is meant to correct that so that
we get consistent behavior.
Signed-off-by: Alexander Duyck
---
arch/frv/mb93090-mb00/pci-dma-nommu.c | 16 +++-
arch/frv/mb93090-mb0
This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
via a sync_for_cpu or sync_for_device call.
Cc: Max Filippov
Signed-off-by: Alexander Duyck
---
arch/xtensa/kernel/pci-dma.c |7 +--
1 file ch
This patch updates the driver code so that we do bulk updates of the page
reference count instead of just incrementing it by one reference at a time.
The advantage to doing this is that we cut down on atomic operations and
this in turn should give us a slight improvement in cycles per packet. In
a
On Mon, Oct 24, 2016 at 08:04:37AM -0400, Alexander Duyck wrote:
> As a first step to making DMA_ATTR_SKIP_CPU_SYNC apply to architectures
> beyond just ARM I need to make it so that the swiotlb will respect the
> flag. In order to do that I also need to update the swiotlb-xen since it
> heavily m
The first 21 patches in the set add support for the DMA attribute
DMA_ATTR_SKIP_CPU_SYNC on multiple platforms/architectures. This is needed
so that we can flag the calls to dma_map/unmap_page so that we do not
invalidate cache lines that do not currently belong to the device. Instead
we have to
As a first step to making DMA_ATTR_SKIP_CPU_SYNC apply to architectures
beyond just ARM I need to make it so that the swiotlb will respect the
flag. In order to do that I also need to update the swiotlb-xen since it
heavily makes use of the functionality.
Cc: Konrad Rzeszutek Wilk
Signed-off-by:
This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
via a sync_for_cpu or sync_for_device call.
Cc: Ralf Baechle
Cc: Keguang Zhang
Cc: linux-m...@linux-mips.org
Signed-off-by: Alexander Duyck
---
arch/
There are no users for swiotlb_map_sg so we might as well just drop it.
Cc: Konrad Rzeszutek Wilk
Signed-off-by: Alexander Duyck
---
include/linux/swiotlb.h |4
lib/swiotlb.c |8
2 files changed, 12 deletions(-)
diff --git a/include/linux/swiotlb.h b/include/lin
This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
later via a sync_for_cpu or sync_for_device call.
Cc: Geert Uytterhoeven
Cc: linux-m...@lists.linux-m68k.org
Signed-off-by: Alexander Duyck
---
arch/m
This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
later via a sync_for_cpu or sync_for_device call.
Cc: Mark Salter
Cc: Aurelien Jacquiot
Cc: linux-c6x-...@linux-c6x.org
Signed-off-by: Alexander Duyck
The use of DMA_ATTR_SKIP_CPU_SYNC was not consistent across all of the DMA
APIs in the arch/arm folder. This change is meant to correct that so that
we get consistent behavior.
Cc: Steven Miao
Signed-off-by: Alexander Duyck
---
arch/blackfin/kernel/dma-mapping.c |7 ++-
1 file changed,
The use of DMA_ATTR_SKIP_CPU_SYNC was not consistent across all of the DMA
APIs in the arch/arm folder. This change is meant to correct that so that
we get consistent behavior.
Cc: Haavard Skinnemoen
Cc: Hans-Christian Egtvedt
Signed-off-by: Alexander Duyck
---
arch/avr32/mm/dma-coherent.c |
This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
later via a sync_for_cpu or sync_for_device call.
Cc: Vineet Gupta
Cc: linux-snps-...@lists.infradead.org
Signed-off-by: Alexander Duyck
---
arch/arc/
This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
via a sync_for_cpu or sync_for_device call.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linuxppc-...@lists.ozlabs.org
Signe
This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
via a sync_for_cpu or sync_for_device call.
Cc: Michal Simek
Signed-off-by: Alexander Duyck
---
arch/microblaze/kernel/dma.c | 10 --
1 file
This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
via a sync_for_cpu or sync_for_device call.
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc: linux-par...@vger.kernel.org
Signed-off-by: Alexander Duyck
This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
via a sync_for_cpu or sync_for_device call.
Cc: James Hogan
Cc: linux-me...@vger.kernel.org
Signed-off-by: Alexander Duyck
---
arch/metag/kernel/dma.c
This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
via a sync_for_cpu or sync_for_device call.
Cc: Ley Foon Tan
Signed-off-by: Alexander Duyck
---
arch/nios2/mm/dma-mapping.c | 14 +++---
1 f
The use of DMA_ATTR_SKIP_CPU_SYNC was not consistent across all of the DMA
APIs in the arch/arm folder. This change is meant to correct that so that
we get consistent behavior.
Cc: Russell King
Signed-off-by: Alexander Duyck
---
arch/arm/common/dmabounce.c | 16 ++--
1 file chang
This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
via a sync_for_cpu or sync_for_device call.
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: linux...@vger.kernel.org
Signed-off-by: Alexander Duyck
---
arch/s
Introduce function mwifiex_probe_of() to parse common properties.
Since the interface drivers get to decide whether or not the device
tree node was a valid one (depending on the compatible property),
let the interface drivers pass a flag to indicate whether the device
tree node was a valid one.
Th
Today all the interface drivers (usb/pcie/sdio) assign the
adapter->dev in the register_dev() callback, although they
have this piece of info well before hand.
This patch makes the device structure available for mwifiex
right at the beginning, so that it can be used for early
initialization if nee
Commit ce4f6f0c353b ("mwifiex: add platform specific wakeup interrupt
support") added WoWLAN feature only for sdio. This patch moves that
code to the common module so that all the interface drivers can use
it for free. It enables pcie and sdio for its use currently.
Signed-off-by: Rajat Jain
---
I have a Marvell card on the PCIe bus that needs to support
WoWLAN (wake-on-wireless-LAN) feature. This is a feature offered
by the "core" mwifiex card and is not specific to an interface
(pcie/sdio/usb).
Currently the code to parse the WowLAN pin, and activate it
resides only in sdio.c [mostly co
On Sat, Oct 22, 2016 at 12:29 PM, Paul Moore wrote:
> On Fri, Oct 21, 2016 at 11:38 PM, Cong Wang wrote:
>> On Fri, Oct 21, 2016 at 6:49 PM, Paul Moore wrote:
>>> Eventually we should be able to reintroduce this code once we have
>>> rewritten the audit multicast code to queue messages much the
rt6_add_route_info and rt6_add_dflt_router were updated to pull the FIB
table from the device index, but the corresponding rt6_get_route_info
and rt6_get_dflt_router functions were not leading to the failure to
process RA's:
ICMPv6: RA: ndisc_router_discovery failed to add default route
Fix t
rt6_add_route_info and rt6_add_dflt_router were updated to pull the FIB
table from the device index, but the corresponding rt6_get_route_info
and rt6_get_dflt_router functions were not leading to the failure to
process RA's:
ICMPv6: RA: ndisc_router_discovery failed to add default route
Fix t
Hi Cong,
I'm able to reproduce it by running
https://gist.github.com/xairy/33f2eb6bf807b004e643bae36c3d02d7 in a
tight parallel loop with stress
(https://godoc.org/golang.org/x/tools/cmd/stress):
$ gcc -lpthread tmp.c
$ ./stress ./a.out
The C program was generated from the following syzkaller pro
On Sat, Oct 22, 2016 at 12:37 AM, Andrey Vagin wrote:
> Hi Cong,
>
> On Thu, Oct 20, 2016 at 10:25 PM, Andrey Vagin wrote:
>> On Thu, Oct 20, 2016 at 8:10 PM, Cong Wang wrote:
>>> On Thu, Oct 20, 2016 at 7:46 PM, Andrei Vagin wrote:
No one can see these events, because a network namespace
On Sun, Oct 23, 2016 at 8:35 AM, Jamal Hadi Salim wrote:
> From: Jamal Hadi Salim
>
> Signed-off-by: Jamal Hadi Salim
We definitely need a serious changelog, even just a short one. ;)
Other than this,
Acked-by: Cong Wang
We can address the "if (RTM_DELTFILTER != event)" in a separated patch
On Mon, Oct 24, 2016 at 9:21 AM, Andrey Konovalov wrote:
> Hi,
>
> I've got the following error report while running the syzkaller fuzzer:
>
> WARNING: CPU: 0 PID: 32451 at fs/proc/generic.c:345 proc_register+0x25e/0x300
> proc_dir_entry 'can-bcm/249757' already registered
> Kernel panic - not syn
On 10/20/2016 01:08 PM, Murali Karicheri wrote:
> David,
>
> On 10/10/2016 02:34 PM, Murali Karicheri wrote:
>> All,
>>
>> Wondering if there plan to add PRP driver support, like HSR in Linux? AFAIK,
>> PRP
>> adds trailor to Ethernet frame and is used for Redundancy management like
>> HSR.
>> S
Hi,
I've got the following error report while running the syzkaller fuzzer:
WARNING: CPU: 0 PID: 32451 at fs/proc/generic.c:345 proc_register+0x25e/0x300
proc_dir_entry 'can-bcm/249757' already registered
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 32451 Comm: syz-executor Not
On Monday, October 24, 2016 10:17:36 AM CEST Jiri Pirko wrote:
> Sat, Oct 22, 2016 at 10:30:08PM CEST, a...@arndb.de wrote:
> >diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
> >index 44e6ba9d3a6b..17be1b66cc41 100644
> >--- a/net/core/flow_dissector.c
> >+++ b/net/core/flow_diss
The kalmia_send_init_packet() returns zero or a negative return
code, but gcc has no way of knowing that there cannot be a
positive return code, so it determines that copying the ethernet
address at the end of kalmia_bind() will access uninitialized
data:
drivers/net/usb/kalmia.c: In function ‘kal
On x86, the cw1200 driver produces a rather silly warning about the
possible use of the 'ret' variable without an initialization
presumably after being confused by the architecture specific definition
of WARN_ON:
drivers/net/wireless/st/cw1200/wsm.c: In function ‘wsm_handle_rx’:
drivers/net/wirele
Hi,
I've got the following error report while running the syzkaller fuzzer:
[ cut here ]
WARNING: CPU: 1 PID: 0 at net/ipv4/af_inet.c:153[] inet_sock_destruct+0x64d/0x810 net/ipv4/af_inet.c:153
Modules linked in:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.9
The hostap_80211_rx() function is supposed to set up the mac addresses
for four possible cases, based on two bits of input data. For
some reason, gcc decides that it's possible that none of the these
four cases apply and the addresses remain uninitialized:
drivers/net/wireless/intersil/hostap/host
On Mon, 2016-10-24 at 14:18 +0100, Rafal Ozieblo wrote:
> New Cadence GEM hardware support Large Segment Offload (LSO):
> TCP segmentation offload (TSO) as well as UDP fragmentation
> offload (UFO). Support for those features was added to the driver.
>
> Signed-off-by: Rafal Ozieblo
...
>
> +s
The rtllib_rx_extract_addr() is supposed to set up the mac addresses
for four possible cases, based on two bits of input data. For
some reason, gcc decides that it's possible that none of the these
four cases apply and the addresses remain uninitialized:
drivers/staging/rtl8192e/rtllib_rx.c: In fu
Hi,
I've got the following error report while running the syzkaller fuzzer:
==
BUG: KASAN: slab-out-of-bounds in sctp_sf_ootb+0x634/0x6c0 at addr
88006bc1f210
Read of size 2 by task syz-executor/13493
CPU: 3 PID: 13493 Comm: syz-
From: manfred.schla...@gmx.at Sent: Monday, October
24, 2016 5:26 PM
> To: Andy Duan
> Cc: netdev@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: [PATCH] net: fec: hard phy reset on open
>
> We have seen some problems with auto negotiation on i.MX6 using LAN8720,
> after interface dow
Building the ip_vs_sync code with CONFIG_OPTIMIZE_INLINING on x86
confuses the compiler to the point where it produces a rather
dubious warning message:
net/netfilter/ipvs/ip_vs_sync.c:1073:33: error: ‘opt.init_seq’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
struct
On Mon, Oct 24, 2016 at 07:50:12PM +0800, Dongpo Li wrote:
> Hello
>
> We encountered a multicast problem when two set-top box(STB) join the same
> multicast group and leave.
> The two boxes can join the same multicast group
> but only one box can send the IGMP leave group message when leave,
> t
skb->cb may contain data from previous layers, as shown in 5146d1f1511
("tunnel: Clear IPCB(skb)->opt before dst_link_failure called").
However, for ipip6 tunnels, clearing IPCB(skb)->opt alone is not enough,
because skb->cb is later misinterpreted as IP6CB(skb)->frag_max_size.
In the observed sce
For single items being collected this should be preferred as being more
typesafe (as the compiler can check format string and to-be-written-to
variable match) and more efficient (requiring one less parameter to be
passed).
Signed-off-by: Jan Beulich
---
v2: Avoid commit message to continue from s
2016-10-24, 15:44:26 +0200, Tobias Brunner wrote:
> Even if sending SCIs is explicitly disabled, the code that creates the
> Security Tag might still decide to add it (e.g. if multiple RX SCs are
> defined on the MACsec interface).
> But because the header length so far only depended on the configu
On 2016-10-24 16:03, Andy Duan wrote:
> From: manfred.schla...@gmx.at Sent: Monday,
> October 24, 2016 5:26 PM
>> To: Andy Duan
>> Cc: netdev@vger.kernel.org; linux-ker...@vger.kernel.org
>> Subject: [PATCH] net: fec: hard phy reset on open
>>
>> We have seen some problems with auto negotiation
On 10/24/2016, 03:03 PM, Eric Dumazet wrote:
> On Mon, 2016-10-24 at 14:54 +0200, Jiri Slaby wrote:
>> Hello,
>>
>> as per man 7 udp:
>> In order to receive packets, the socket can be bound to
>> a local address first by using bind(2). Otherwise,
>> the socket layer will automatically assi
+a...@redhat.com
Hi,
I've got the following error report while running the syzkaller fuzzer:
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: [#1] SMP KASAN
Modules linked in:
CPU: 0 PID: 3953 Comm: syz-executor
On Mon, Oct 24, 2016 at 01:01:09AM +0800, Xin Long wrote:
> Commit 7303a1475008 ("sctp: identify chunks that need to be fragmented
> at IP level") made the chunk be fragmented at IP level in the next round
> if it's size exceed PMTU.
>
> But there still is another case, PMTU can be updated if tran
New Cadence GEM hardware support Large Segment Offload (LSO):
TCP segmentation offload (TSO) as well as UDP fragmentation
offload (UFO). Support for those features was added to the driver.
Signed-off-by: Rafal Ozieblo
---
drivers/net/ethernet/cadence/macb.c | 141
Even if sending SCIs is explicitly disabled, the code that creates the
Security Tag might still decide to add it (e.g. if multiple RX SCs are
defined on the MACsec interface).
But because the header length so far only depended on the configuration
option the SCI overwrote the original frame's conte
Hi Eric,
I can confirm that with your patch the warning goes away.
Tested-by: Andrey Konovalov
On Mon, Oct 24, 2016 at 2:52 PM, Eric Dumazet wrote:
> On Mon, 2016-10-24 at 05:47 -0700, Eric Dumazet wrote:
>> On Mon, 2016-10-24 at 14:23 +0200, Andrey Konovalov wrote:
>> > Hi,
>> >
>> > I've got
2016-10-24, 15:32:40 +0200, Tobias Brunner wrote:
> > [snip]
> >> @@ -440,12 +448,12 @@ static void macsec_fill_sectag(struct
> >> macsec_eth_header *h,
> >> const struct macsec_secy *secy, u32 pn)
> >> {
> >>const struct macsec_tx_sc *tx_sc = &secy->tx_sc;
> >> + b
> [snip]
>> @@ -440,12 +448,12 @@ static void macsec_fill_sectag(struct
>> macsec_eth_header *h,
>> const struct macsec_secy *secy, u32 pn)
>> {
>> const struct macsec_tx_sc *tx_sc = &secy->tx_sc;
>> +bool sci_present = send_sci(secy);
>
> You're already comp
On Mon, 2016-10-24 at 14:54 +0200, Jiri Slaby wrote:
> Hello,
>
> as per man 7 udp:
> In order to receive packets, the socket can be bound to
> a local address first by using bind(2). Otherwise,
> the socket layer will automatically assign a free local
> port out of the range defined by
On Mon, 2016-10-24 at 14:40 +0200, Johannes Berg wrote:
> From: Johannes Berg
>
> Instead of providing macros/inline functions to initialize
> the families, make all users initialize them statically and
> get rid of the macros.
>
> This reduces the kernel code size by about 1.6k on x86-64
> (wit
Hello,
as per man 7 udp:
In order to receive packets, the socket can be bound to
a local address first by using bind(2). Otherwise,
the socket layer will automatically assign a free local
port out of the range defined by /proc/sys/net/ipv4
/ip_local_port_range and bind the socket to I
I tested this patchset with my AR8161 ethernet card in different situations:
- After two weeks of daily use I observed no regression with this patchset.
- I manually tested the new error paths in the __alx-open function and in
the other newly added device bringup functions.
- iperf udp
On Mon, 2016-10-24 at 05:47 -0700, Eric Dumazet wrote:
> On Mon, 2016-10-24 at 14:23 +0200, Andrey Konovalov wrote:
> > Hi,
> >
> > I've got the following error report while running the syzkaller fuzzer:
> >
> > WARNING: CPU: 1 PID: 21072 at net/dccp/proto.c:83 dccp_set_state+0x229/0x290
> > Kern
The user may want to use only some bits of the skb mark in
his skbedit rules because the remaining part might be used by
something else.
Introduce the "mask" parameter to the skbedit actor in order
to implement such functionality.
When the mask is specified, only those bits selected by the
latter
On Mon, 2016-10-24 at 14:23 +0200, Andrey Konovalov wrote:
> Hi,
>
> I've got the following error report while running the syzkaller fuzzer:
>
> WARNING: CPU: 1 PID: 21072 at net/dccp/proto.c:83 dccp_set_state+0x229/0x290
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 1 PID: 21072
Fixes: d894be57ca92('ethernet: use net core MTU range checking in more drivers')
CC: Jarod Wilson
CC: Thomas Falcon
Signed-off-by: Stefan Richter
---
drivers/net/ethernet/broadcom/sb1250-mac.c | 2 +-
drivers/net/ethernet/ibm/ibmveth.c | 2 +-
2 files changed, 2 insertions(+), 2 deletio
1 - 100 of 139 matches
Mail list logo
