On 5/15/19 9:15 PM, Yuval Shaia wrote:
> On Wed, May 15, 2019 at 07:36:26PM +0300, Leon Romanovsky wrote:
>> On Wed, May 15, 2019 at 06:30:51PM +0300, Yuval Shaia wrote:
>>> On Tue, May 14, 2019 at 03:23:21PM +0300, Leon Romanovsky wrote:
This is a call for proposals for the 4th RDMA mini-s
This patch series fixes all the sparse warnings.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
As cmpxchg is a non-RCU mechanism it will cause sparse warnings
when we use it for RCU. This patch adds explicit casts to silence
those warnings. This should probably be moved to RCU itself in
future.
Signed-off-by: Herbert Xu
---
lib/rhashtable.c |5 +++--
1 file changed, 3 insertions(
The opaque type rhash_lock_head should not be marked with __rcu
because it can never be dereferenced. We should apply the RCU
marking when we turn it into a pointer which can be dereferenced.
This patch does exactly that. This fixes a number of sparse
warnings as well as getting rid of some unne
On 2019/5/15 下午11:23, Stephen Hemminger wrote:
On Wed, 15 May 2019 16:12:42 +0800
Jason Wang wrote:
On 2019/5/15 下午4:03, Stephen Hemminger wrote:
XDP generic does not work correctly with the Hyper-V/Azure netvsc
device because of packet processing order. Only packets on the
synthetic path g
We have 3 laptops which connect the wifi by the same RTL8723BU.
The PCI VID/PID of the wifi chip is 10EC:B720 which is supported.
They have the same problem with the in-kernel rtl8xxxu driver, the
iperf (as a client to an ethernet-connected server) gets ~1Mbps.
Nevertheless, the signal strength is
On Thu, May 16, 2019 at 10:08:32AM +0300, Kamal Heib wrote:
>
>
> On 5/15/19 9:15 PM, Yuval Shaia wrote:
> > On Wed, May 15, 2019 at 07:36:26PM +0300, Leon Romanovsky wrote:
> >> On Wed, May 15, 2019 at 06:30:51PM +0300, Yuval Shaia wrote:
> >>> On Tue, May 14, 2019 at 03:23:21PM +0300, Leon Romano
From: Corentin Labbe
Date: Wed, May 15, 2019 at 18:29:22
> I will try to investigate the MMC failure. Does -1 (vs other -E) is the
> right error code to return from the driver ?
Thank you for testing!
Yes, I will fix to return a valid error code.
As per MMC failure this can be due to your
On Wed, 15 May 2019 at 18:16, Joe Stringer wrote:
>
> On Wed, May 15, 2019 at 8:11 AM Lorenz Bauer wrote:
> >
> > In the BPF-based TPROXY session with Joe Stringer [1], I mentioned
> > that the sk_lookup_* helpers currently return inconsistent results if
> > SK_REUSEPORT programs are in play.
> >
On 5/14/2019 3:07 PM, Jiri Pirko wrote:
> Sun, May 12, 2019 at 10:37:35AM CEST, a...@mellanox.com wrote:
>>
>>
>> On 5/9/2019 11:23 AM, Jiri Pirko wrote:
>>> Tue, May 07, 2019 at 02:58:32PM CEST, a...@mellanox.com wrote:
On 5/7/2019 3:41 PM, Jiri Pirko wrote:
> Mon, Apr 29, 201
Hi Jakub,
Thanks for submitting this.
On 5/15/2019 11:41 PM, Jakub Kicinski wrote:
> Describe existing kernel TLS offload (added back in Linux 4.19) -
> the mechanism, the expected behavior and the notable corner cases.
>
> This documentation is mostly targeting hardware vendors who want
> to im
From: Herbert Xu
> Sent: 16 May 2019 08:20
> As cmpxchg is a non-RCU mechanism it will cause sparse warnings
> when we use it for RCU. This patch adds explicit casts to silence
> those warnings. This should probably be moved to RCU itself in
> future.
>
...
> - if (cmpxchg(prev, NULL, ntbl)
On Wed, May 15, 2019 at 11:46 PM Jakub Kicinski
wrote:
>
> On Wed, 15 May 2019 15:47:27 +0200, Krzesimir Nowak wrote:
> > This prints a message when the error is about program type being not
> > supported by the test runner or because of permissions problem. This
> > is to see if the program we ex
On Wed, May 15, 2019 at 11:51 PM Jakub Kicinski
wrote:
>
> On Wed, 15 May 2019 15:47:28 +0200, Krzesimir Nowak wrote:
> > Save errno right after bpf_prog_test_run returns, so we later check
> > the error code actually set by bpf_prog_test_run, not by some libcap
> > function.
> >
> > Cc: Jakub Kic
This resurrects commit 8742dc86d0c7a9628
("xfrm4: Fix uninitialized memory read in _decode_session4"),
which got lost during a merge conflict resolution between ipsec-next
and net-next tree.
c53ac41e3720 ("xfrm: remove decode_session indirection from afinfo_policy")
in ipsec-next moved the (buggy)
This patch is to add get_ts_info interface for ethtool
to support getting timestamping capability.
Signed-off-by: Yangbo Lu
---
drivers/net/ethernet/freescale/enetc/enetc.h | 3 ++
.../ethernet/freescale/enetc/enetc_ethtool.c | 31 +++
.../net/ethernet/freescale/enetc/enetc_pt
This patch is to add hardware timestamping support
for ENETC. On Rx, timestamping is enabled for all
frames. On Tx, we only instruct the hardware to
timestamp the frames marked accordingly by the stack.
Because the RX BD ring dynamic allocation hasn't been
supported and it's too expensive to use e
This patch-set is to support hardware timestamping for ENETC
and also to add 1588 timer device tree node for ls1028a.
Because ENETC RX BD ring dynamic allocation hasn't been
supported and it's too expensive to use extended RX BDs
if timestamping isn't used, we have to use a Kconfig
option to enabl
Add ENETC 1588 timer node which is ENETC PF 4 (Physiscal Function 4).
Signed-off-by: Yangbo Lu
---
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1028a.d
Hi Robert, Eric,
In commit 5a9ab0176198 ("mpls: Prevent use of implicit NULL label as outgoing
label") I saw we disabled setting label 3. Is there a reason that why we did
not disable other reserved values(0-15)?
I saw function mpls_label_ok() checks the index and reject all reserved values.
With
Hello,
syzbot found the following crash on:
HEAD commit:3b0f31f2 genetlink: make policy common to family
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12a319df20
kernel config: https://syzkaller.appspot.com/x/.config?x=f05902bca21d8935
dashboard link
Hello,
syzbot found the following crash on:
HEAD commit:601e6bcc Merge git://git.kernel.org/pub/scm/linux/kernel/g..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1534f3d0a0
kernel config: https://syzkaller.appspot.com/x/.config?x=4005028a9d5ddac8
da
This series of patches move the commonly used bpf_printk macro to
bpf_helpers.h which is already included in all BPF programs which
defined that macro on their own.
Michal Rostecki (2):
selftests: bpf: Move bpf_printk to bpf_helpers.h
samples: bpf: Do not define bpf_printk macro
samples/bpf/
The bpf_printk macro was moved to bpf_helpers.h which is included in all
example programs.
Signed-off-by: Michal Rostecki
---
samples/bpf/hbm_kern.h | 12 +++-
samples/bpf/hbm_out_kern.c | 2 ++
samples/bpf/tcp_basertt_kern.c | 7 ---
samples/bpf/tcp_bufs_ke
bpf_printk is a macro which is commonly used to print out debug messages
in BPF programs and it was copied in many selftests and samples. Since
all of them include bpf_helpers.h, this change moves the macro there.
Signed-off-by: Michal Rostecki
---
tools/testing/selftests/bpf/bpf_helpers.h
From: Jeremy Sowden
[ Upstream commit 5483844c3fc18474de29f5d6733003526e0a9f78 ]
If tunnel registration failed during module initialization, the module
would fail to deregister the IPPROTO_COMP protocol and would attempt to
deregister the tunnel.
The tunnel was not deregistered during module-ex
From: YueHaibing
[ Upstream commit b805d78d300bcf2c83d6df7da0c818b0fee41427 ]
UBSAN report this:
UBSAN: Undefined behaviour in net/xfrm/xfrm_policy.c:1289:24
index 6 is out of range for type 'unsigned int [6]'
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.162-514.55.6.9.x86_64+ #13
Hardware nam
From: Alban Crequy
[ Upstream commit 8694d8c1f82cccec9380e0d3720b84eee315dfb7 ]
"bpftool map create" has an infinite loop on "while (argc)". The error
case is missing.
Symptoms: when forgetting to type the keyword 'type' in front of 'hash':
$ sudo bpftool map create /sys/fs/bpf/dir/foobar hash
From: Steffen Klassert
[ Upstream commit 8742dc86d0c7a9628117a989c11f04a9b6b898f3 ]
We currently don't reload pointers pointing into skb header
after doing pskb_may_pull() in _decode_session4(). So in case
pskb_may_pull() changed the pointers, we read from random
memory. Fix this by putting all
From: Sabrina Dubroca
[ Upstream commit 8dfb4eba4100e7cdd161a8baef2d8d61b7a7e62e ]
esp_output_udp_encap can produce a length that doesn't fit in the 16
bits of a UDP header's length field. In that case, we'll send a
fragmented packet whose length is larger than IP_MAX_MTU (resulting in
"Oversize
From: Peter Zijlstra
[ Upstream commit 0edd6b64d1939e9e9168ff27947995bb7751db5d ]
Unless the very next line is schedule(), or implies it, one must not use
preempt_enable_no_resched(). It can cause a preemption to go missing and
thereby cause arbitrary delays, breaking the PREEMPT=y invariant.
C
From: Bjørn Mork
[ Upstream commit 88ef66a28391ea7b624bfb7508a5b015c13b28f3 ]
Adding device entries found in vendor modified versions of this
driver. Function maps for some of the devices follow:
WNC D16Q1, D16Q5, D18Q1 LTE CAT3 module (1435:0918)
MI_00 Qualcomm HS-USB Diagnostics
MI_01 Andro
From: Su Yanjun
[ Upstream commit 6ee02a54ef990a71bf542b6f0a4e3321de9d9c66 ]
When unloading xfrm6_tunnel module, xfrm6_tunnel_fini directly
frees the xfrm6_tunnel_spi_kmem. Maybe someone has gotten the
xfrm6_tunnel_spi, so need to wait it.
Fixes: 91cc3bb0b04ff("xfrm6_tunnel: RCU conversion")
Si
From: Kangjie Lu
[ Upstream commit 22e8860cf8f777fbf6a83f2fb7127f682a8e9de4 ]
regmap_update_bits could fail and deserves a check.
The patch adds the checks and if it fails, returns its error
code upstream.
Signed-off-by: Kangjie Lu
Reviewed-by: Mukesh Ojha
Signed-off-by: Stefan Schmidt
Sign
From: Peter Zijlstra
[ Upstream commit 0edd6b64d1939e9e9168ff27947995bb7751db5d ]
Unless the very next line is schedule(), or implies it, one must not use
preempt_enable_no_resched(). It can cause a preemption to go missing and
thereby cause arbitrary delays, breaking the PREEMPT=y invariant.
C
From: Cong Wang
[ Upstream commit dbb2483b2a46fbaf833cfb5deb5ed9cace9c7399 ]
In commit 6a53b7593233 ("xfrm: check id proto in validate_tmpl()")
I introduced a check for xfrm protocol, but according to Herbert
IPSEC_PROTO_ANY should only be used as a wildcard for lookup, so
it should be removed f
From: Steffen Klassert
[ Upstream commit 8742dc86d0c7a9628117a989c11f04a9b6b898f3 ]
We currently don't reload pointers pointing into skb header
after doing pskb_may_pull() in _decode_session4(). So in case
pskb_may_pull() changed the pointers, we read from random
memory. Fix this by putting all
From: Luca Coelho
[ Upstream commit de1887c064b9996ac03120d90d0a909a3f678f98 ]
We don't check for the validity of the lengths in the packet received
from the firmware. If the MPDU length received in the rx descriptor
is too short to contain the header length and the crypt length
together, we ma
From: Jeremy Sowden
[ Upstream commit 5483844c3fc18474de29f5d6733003526e0a9f78 ]
If tunnel registration failed during module initialization, the module
would fail to deregister the IPPROTO_COMP protocol and would attempt to
deregister the tunnel.
The tunnel was not deregistered during module-ex
From: Steffen Klassert
[ Upstream commit 8742dc86d0c7a9628117a989c11f04a9b6b898f3 ]
We currently don't reload pointers pointing into skb header
after doing pskb_may_pull() in _decode_session4(). So in case
pskb_may_pull() changed the pointers, we read from random
memory. Fix this by putting all
From: Su Yanjun
[ Upstream commit 6ee02a54ef990a71bf542b6f0a4e3321de9d9c66 ]
When unloading xfrm6_tunnel module, xfrm6_tunnel_fini directly
frees the xfrm6_tunnel_spi_kmem. Maybe someone has gotten the
xfrm6_tunnel_spi, so need to wait it.
Fixes: 91cc3bb0b04ff("xfrm6_tunnel: RCU conversion")
Si
From: Bhagavathi Perumal S
[ Upstream commit f1267cf3c01b12e0f843fb6a7450a7f0b2efab8a ]
The txq of vif is added to active_txqs list for ATF TXQ scheduling
in the function ieee80211_queue_skb(), but it was not properly removed
before freeing the txq object. It was causing use after free of the tx
From: Jeremy Sowden
[ Upstream commit 5483844c3fc18474de29f5d6733003526e0a9f78 ]
If tunnel registration failed during module initialization, the module
would fail to deregister the IPPROTO_COMP protocol and would attempt to
deregister the tunnel.
The tunnel was not deregistered during module-ex
From: YueHaibing
[ Upstream commit b805d78d300bcf2c83d6df7da0c818b0fee41427 ]
UBSAN report this:
UBSAN: Undefined behaviour in net/xfrm/xfrm_policy.c:1289:24
index 6 is out of range for type 'unsigned int [6]'
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.162-514.55.6.9.x86_64+ #13
Hardware nam
From: Bhagavathi Perumal S
[ Upstream commit f1267cf3c01b12e0f843fb6a7450a7f0b2efab8a ]
The txq of vif is added to active_txqs list for ATF TXQ scheduling
in the function ieee80211_queue_skb(), but it was not properly removed
before freeing the txq object. It was causing use after free of the tx
From: Jeremy Sowden
[ Upstream commit 5483844c3fc18474de29f5d6733003526e0a9f78 ]
If tunnel registration failed during module initialization, the module
would fail to deregister the IPPROTO_COMP protocol and would attempt to
deregister the tunnel.
The tunnel was not deregistered during module-ex
From: Su Yanjun
[ Upstream commit 6ee02a54ef990a71bf542b6f0a4e3321de9d9c66 ]
When unloading xfrm6_tunnel module, xfrm6_tunnel_fini directly
frees the xfrm6_tunnel_spi_kmem. Maybe someone has gotten the
xfrm6_tunnel_spi, so need to wait it.
Fixes: 91cc3bb0b04ff("xfrm6_tunnel: RCU conversion")
Si
From: YueHaibing
[ Upstream commit b805d78d300bcf2c83d6df7da0c818b0fee41427 ]
UBSAN report this:
UBSAN: Undefined behaviour in net/xfrm/xfrm_policy.c:1289:24
index 6 is out of range for type 'unsigned int [6]'
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.162-514.55.6.9.x86_64+ #13
Hardware nam
From: YueHaibing
[ Upstream commit b805d78d300bcf2c83d6df7da0c818b0fee41427 ]
UBSAN report this:
UBSAN: Undefined behaviour in net/xfrm/xfrm_policy.c:1289:24
index 6 is out of range for type 'unsigned int [6]'
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.162-514.55.6.9.x86_64+ #13
Hardware nam
From: Su Yanjun
[ Upstream commit 6ee02a54ef990a71bf542b6f0a4e3321de9d9c66 ]
When unloading xfrm6_tunnel module, xfrm6_tunnel_fini directly
frees the xfrm6_tunnel_spi_kmem. Maybe someone has gotten the
xfrm6_tunnel_spi, so need to wait it.
Fixes: 91cc3bb0b04ff("xfrm6_tunnel: RCU conversion")
Si
From: Steffen Klassert
[ Upstream commit 8742dc86d0c7a9628117a989c11f04a9b6b898f3 ]
We currently don't reload pointers pointing into skb header
after doing pskb_may_pull() in _decode_session4(). So in case
pskb_may_pull() changed the pointers, we read from random
memory. Fix this by putting all
From: Jeremy Sowden
[ Upstream commit 5483844c3fc18474de29f5d6733003526e0a9f78 ]
If tunnel registration failed during module initialization, the module
would fail to deregister the IPPROTO_COMP protocol and would attempt to
deregister the tunnel.
The tunnel was not deregistered during module-ex
From: Bhagavathi Perumal S
[ Upstream commit f1267cf3c01b12e0f843fb6a7450a7f0b2efab8a ]
The txq of vif is added to active_txqs list for ATF TXQ scheduling
in the function ieee80211_queue_skb(), but it was not properly removed
before freeing the txq object. It was causing use after free of the tx
From: Steffen Klassert
[ Upstream commit 8742dc86d0c7a9628117a989c11f04a9b6b898f3 ]
We currently don't reload pointers pointing into skb header
after doing pskb_may_pull() in _decode_session4(). So in case
pskb_may_pull() changed the pointers, we read from random
memory. Fix this by putting all
From: Luca Coelho
[ Upstream commit de1887c064b9996ac03120d90d0a909a3f678f98 ]
We don't check for the validity of the lengths in the packet received
from the firmware. If the MPDU length received in the rx descriptor
is too short to contain the header length and the crypt length
together, we ma
From: Sabrina Dubroca
[ Upstream commit 8dfb4eba4100e7cdd161a8baef2d8d61b7a7e62e ]
esp_output_udp_encap can produce a length that doesn't fit in the 16
bits of a UDP header's length field. In that case, we'll send a
fragmented packet whose length is larger than IP_MAX_MTU (resulting in
"Oversize
From: YueHaibing
[ Upstream commit b805d78d300bcf2c83d6df7da0c818b0fee41427 ]
UBSAN report this:
UBSAN: Undefined behaviour in net/xfrm/xfrm_policy.c:1289:24
index 6 is out of range for type 'unsigned int [6]'
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.162-514.55.6.9.x86_64+ #13
Hardware nam
From: Bjørn Mork
[ Upstream commit 88ef66a28391ea7b624bfb7508a5b015c13b28f3 ]
Adding device entries found in vendor modified versions of this
driver. Function maps for some of the devices follow:
WNC D16Q1, D16Q5, D18Q1 LTE CAT3 module (1435:0918)
MI_00 Qualcomm HS-USB Diagnostics
MI_01 Andro
From: Su Yanjun
[ Upstream commit 6ee02a54ef990a71bf542b6f0a4e3321de9d9c66 ]
When unloading xfrm6_tunnel module, xfrm6_tunnel_fini directly
frees the xfrm6_tunnel_spi_kmem. Maybe someone has gotten the
xfrm6_tunnel_spi, so need to wait it.
Fixes: 91cc3bb0b04ff("xfrm6_tunnel: RCU conversion")
Si
From: Bhagavathi Perumal S
[ Upstream commit f1267cf3c01b12e0f843fb6a7450a7f0b2efab8a ]
The txq of vif is added to active_txqs list for ATF TXQ scheduling
in the function ieee80211_queue_skb(), but it was not properly removed
before freeing the txq object. It was causing use after free of the tx
From: Kangjie Lu
[ Upstream commit 22e8860cf8f777fbf6a83f2fb7127f682a8e9de4 ]
regmap_update_bits could fail and deserves a check.
The patch adds the checks and if it fails, returns its error
code upstream.
Signed-off-by: Kangjie Lu
Reviewed-by: Mukesh Ojha
Signed-off-by: Stefan Schmidt
Sign
From: Martin Willi
[ Upstream commit 025c65e119bf58b610549ca359c9ecc5dee6a8d2 ]
If an xfrmi is associated to a vrf layer 3 master device,
xfrm_policy_check() fails after traffic decapsulation. The input
interface is replaced by the layer 3 master device, and hence
xfrmi_decode_session() can't ma
From: Sabrina Dubroca
[ Upstream commit 8dfb4eba4100e7cdd161a8baef2d8d61b7a7e62e ]
esp_output_udp_encap can produce a length that doesn't fit in the 16
bits of a UDP header's length field. In that case, we'll send a
fragmented packet whose length is larger than IP_MAX_MTU (resulting in
"Oversize
From: YueHaibing
[ Upstream commit b805d78d300bcf2c83d6df7da0c818b0fee41427 ]
UBSAN report this:
UBSAN: Undefined behaviour in net/xfrm/xfrm_policy.c:1289:24
index 6 is out of range for type 'unsigned int [6]'
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.162-514.55.6.9.x86_64+ #13
Hardware nam
From: Jeremy Sowden
[ Upstream commit 5483844c3fc18474de29f5d6733003526e0a9f78 ]
If tunnel registration failed during module initialization, the module
would fail to deregister the IPPROTO_COMP protocol and would attempt to
deregister the tunnel.
The tunnel was not deregistered during module-ex
From: Luca Coelho
[ Upstream commit de1887c064b9996ac03120d90d0a909a3f678f98 ]
We don't check for the validity of the lengths in the packet received
from the firmware. If the MPDU length received in the rx descriptor
is too short to contain the header length and the crypt length
together, we ma
From: Bhagavathi Perumal S
[ Upstream commit f1267cf3c01b12e0f843fb6a7450a7f0b2efab8a ]
The txq of vif is added to active_txqs list for ATF TXQ scheduling
in the function ieee80211_queue_skb(), but it was not properly removed
before freeing the txq object. It was causing use after free of the tx
From: Martin Willi
[ Upstream commit 025c65e119bf58b610549ca359c9ecc5dee6a8d2 ]
If an xfrmi is associated to a vrf layer 3 master device,
xfrm_policy_check() fails after traffic decapsulation. The input
interface is replaced by the layer 3 master device, and hence
xfrmi_decode_session() can't ma
From: Cong Wang
[ Upstream commit dbb2483b2a46fbaf833cfb5deb5ed9cace9c7399 ]
In commit 6a53b7593233 ("xfrm: check id proto in validate_tmpl()")
I introduced a check for xfrm protocol, but according to Herbert
IPSEC_PROTO_ANY should only be used as a wildcard for lookup, so
it should be removed f
From: Myungho Jung
[ Upstream commit 6ed69184ed9c43873b8a1ee721e3bf3c08c2c6be ]
In esp4_gro_receive() and esp6_gro_receive(), secpath can be allocated
without adding xfrm state to xvec. Then, sp->xvec[sp->len - 1] would
fail and result in dereferencing invalid pointer in esp4_gso_segment()
and e
From: Su Yanjun
[ Upstream commit 6ee02a54ef990a71bf542b6f0a4e3321de9d9c66 ]
When unloading xfrm6_tunnel module, xfrm6_tunnel_fini directly
frees the xfrm6_tunnel_spi_kmem. Maybe someone has gotten the
xfrm6_tunnel_spi, so need to wait it.
Fixes: 91cc3bb0b04ff("xfrm6_tunnel: RCU conversion")
Si
Thu, May 16, 2019 at 10:49:54AM CEST, a...@mellanox.com wrote:
>
>
>On 5/14/2019 3:07 PM, Jiri Pirko wrote:
>> Sun, May 12, 2019 at 10:37:35AM CEST, a...@mellanox.com wrote:
>>>
>>>
>>> On 5/9/2019 11:23 AM, Jiri Pirko wrote:
Tue, May 07, 2019 at 02:58:32PM CEST, a...@mellanox.com wrote:
>
On 5/16/2019 2:53 PM, Jiri Pirko wrote:
> Thu, May 16, 2019 at 10:49:54AM CEST, a...@mellanox.com wrote:
>>
>>
>> On 5/14/2019 3:07 PM, Jiri Pirko wrote:
>>> Sun, May 12, 2019 at 10:37:35AM CEST, a...@mellanox.com wrote:
On 5/9/2019 11:23 AM, Jiri Pirko wrote:
> Tue, May 07, 20
On Wed, May 8, 2019 at 2:10 PM Magnus Karlsson
wrote:
>
> On Tue, May 7, 2019 at 8:24 PM Alexei Starovoitov
> wrote:
> >
> > On Tue, May 07, 2019 at 01:51:45PM +0200, Magnus Karlsson wrote:
> > > On Mon, May 6, 2019 at 6:33 PM Alexei Starovoitov
> > > wrote:
> > > >
> > > > On Thu, May 02, 2019
On Thu, May 16, 2019 at 09:20:36AM +, David Laight wrote:
>
> I presume these casts remove an 'rcu' marker on the variable.
> Is there a way of marking such casts as 'for sparse only' so
> that the compiler does proper type checking.
> (Clearly this isn't that relevant here as the cast could be
On Mon, May 13, 2019 at 09:55:21PM -0300, Jason Gunthorpe wrote:
> gcc 9 now does allocation size tracking and thinks that passing the member
> of a union and then accessing beyond that member's bounds is an overflow.
>
> Instead of using the union member, use the entire union with a cast to
> get
> My basic idea is to interface a Raspberry Pi-like board to a dumb
> "switch evaluation board" which has only the Ethernet ports and the
> SPI/whatever control interface exposed. The DSA CPU/master port combo
> in this case would go through a Cat5 cable, which is not going to pan
> out very well c
After some putzing around in kernel and edk2 sources, I stumbled on this
magic one-liner for kernel/mvpp2 that fixes the crashing with a
controller already initialized by uboot/mvpp2
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -530
>-Original Message-
>From: Y.b. Lu
[...]
>Subject: [PATCH 1/3] enetc: add hardware timestamping support
>
[...]
Hi Yangbo,
These enetc patches targeting net-next will have to be rebased on
the latest enetc net.git commits, otherwise there will be some merge
conflicts for enetc.c and enetc
On Thu, May 16, 2019 at 09:59:08AM +, Y.b. Lu wrote:
> +config FSL_ENETC_HW_TIMESTAMPING
> + bool "ENETC hardware timestamping support"
> + depends on FSL_ENETC || FSL_ENETC_VF
> + help
> + Enable hardware timestamping support on the Ethernet packets
> + using the SO_TI
This patch add error path for can_init to
avoid possible crash if some error occurs.
Fixes: 0d66548a10cb ("[CAN]: Add PF_CAN core module")
Signed-off-by: YueHaibing
---
net/can/af_can.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/net/can/af_can.c
On Wed, May 15, 2019 at 3:57 PM Adam Urban wrote:
>
> We have an application where we are use sendmsg() to send (lots of)
> UDP packets to multiple destinations over a single socket, repeatedly,
> and at a pretty constant rate using IPv4.
>
> In some cases, some of these destinations are no longer
Original fix b8b277525e9d was done under impression that invalid data
could be written for mtu configuration higher that 16334.
But the high limit will anyway be rejected my max_mtu check in caller.
Thus, make the code cleaner and allow it doing the configuration without
checking for maximum mtu v
This reverts commit 369b46e9fbcfa5136f2cb5f486c90e5f7fa92630.
The required temporary storage is already done inside of write32/16
helpers.
Signed-off-by: Igor Russkikh
---
drivers/net/usb/aqc111.c | 23 ++-
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git a/drive
Hello!
This reverts no-op commits as it was discussed:
https://lore.kernel.org/netdev/1557839644.11261.4.ca...@suse.com/
First and second original patches are already dropped from stable,
No need to stable-queue the third patch as it has no functional impact,
just a logic cleanup.
Igor Russkikh
This reverts commit 2cf672709beb005f6e90cb4edbed6f2218ba953e.
The required temporary storage is already done inside of write32/16
helpers.
Signed-off-by: Igor Russkikh
---
drivers/net/usb/aqc111.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/aqc111.c
On 5/15/19 8:39 PM, Eric Dumazet wrote:
> At ipv6 route dismantle, fib6_drop_pcpu_from() is responsible
> for finding all percpu routes and set their ->from pointer
> to NULL, so that fib6_ref can reach its expected value (1).
>
> The problem right now is that other cpus can still catch the
> rout
When host is under high stress, it is very possible thread
running netdev_wait_allrefs() returns from msleep(250)
10 seconds late.
This leads to these messages in the syslog :
[...] unregister_netdevice: waiting for syz_tun to become free. Usage count = 0
If the device refcount is zero, the wait
On Thu, 16 May 2019 13:16:23 +0800, Herbert Xu wrote:
> On Wed, May 15, 2019 at 01:55:01PM -0700, Jakub Kicinski wrote:
> > Since the bit_spin_lock() operations don't actually dereference
> > the pointer, it's fine to forcefully drop the RCU annotation.
> > This fixes 7 sparse warnings per include
On Thu, May 16, 2019 at 02:44:28PM +0200, Simon Horman wrote:
> On Mon, May 13, 2019 at 09:55:21PM -0300, Jason Gunthorpe wrote:
> > gcc 9 now does allocation size tracking and thinks that passing the member
> > of a union and then accessing beyond that member's bounds is an overflow.
> >
> > Inst
Unwind net_sysctl_init error exit goto spaghetti code
Suggested-by: Joshua Frkuska
Signed-off-by: George G. Davis
---
net/sysctl_net.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/net/sysctl_net.c b/net/sysctl_net.c
index 9aed6fe1bf1a..7710a2d7f79a 100644
--- a
>-Original Message-
>From: Richard Cochran
>Sent: Thursday, May 16, 2019 5:33 PM
>To: Y.b. Lu
>Cc: netdev@vger.kernel.org; David Miller ; Claudiu
>Manoil ; Shawn Guo ; Rob
>Herring ; devicet...@vger.kernel.org; linux-arm-
>ker...@lists.infradead.org; linux-ker...@vger.kernel.org
>Subjec
/proc/net/stat/ndisc_cache show unresolved_discards appears to show 0
unresolved_discards:
entries,allocs,destroys,hash_grows,lookups,hits,res_failed,rcv_probes_mcast,rcv_probes_ucast,periodic_gc_runs,forced_gc_runs,unresolved_discards,table_fulls
0005,0005,,,,0
On Thu, 16 May 2019 11:29:39 +0200, Krzesimir Nowak wrote:
> > > diff --git a/tools/testing/selftests/bpf/test_verifier.c
> > > b/tools/testing/selftests/bpf/test_verifier.c
> > > index ccd896b98cac..bf0da03f593b 100644
> > > --- a/tools/testing/selftests/bpf/test_verifier.c
> > > +++ b/tools/test
This patch fix error path for cgw_module_init
to avoid possible crash if some error occurs.
Fixes: c1aabdf379bc ("can-gw: add netlink based CAN routing")
Signed-off-by: YueHaibing
---
net/can/gw.c | 46 +++---
1 file changed, 31 insertions(+), 15 deletions
On 5/16/19 7:47 AM, Willem de Bruijn wrote:
> On Wed, May 15, 2019 at 3:57 PM Adam Urban wrote:
>>
>> We have an application where we are use sendmsg() to send (lots of)
>> UDP packets to multiple destinations over a single socket, repeatedly,
>> and at a pretty constant rate using IPv4.
>>
>>
On 5/16/19 9:05 AM, Eric Dumazet wrote:
> We probably should add a ttl on arp queues.
>
> neigh_probe() could do that quite easily.
>
Adam, all you need to do is to increase UDP socket sndbuf.
Either by increasing /proc/sys/net/core/wmem_default
or using setsockopt( ... SO_SNDBUF ... )
On Thu, May 16, 2019 at 5:51 PM Jakub Kicinski
wrote:
>
> On Thu, 16 May 2019 11:29:39 +0200, Krzesimir Nowak wrote:
> > > > diff --git a/tools/testing/selftests/bpf/test_verifier.c
> > > > b/tools/testing/selftests/bpf/test_verifier.c
> > > > index ccd896b98cac..bf0da03f593b 100644
> > > > --- a
When increases the headroom, skb's pointer might get re-allocated.
Fix it by moving skb_cow_head before accessing the skb->data pointer.
Fixes: 01b8d064d58b4 ("net: ip6_gre: Request headroom in __gre6_xmit()")
Reported-by: Haichao Ma
Signed-off-by: William Tu
---
net/ipv6/ip6_gre.c | 6 +++---
On 16.05.19 16:36, YueHaibing wrote:
This patch add error path for can_init to
avoid possible crash if some error occurs.
Fixes: 0d66548a10cb ("[CAN]: Add PF_CAN core module")
Signed-off-by: YueHaibing
Acked-by: Oliver Hartkopp
Thanks!
---
net/can/af_can.c | 24 +---
1 - 100 of 194 matches
Mail list logo
