On Fri, 22 Jun 2018 17:31:37 -0700, Shannon Nelson wrote:
> Implement the IPsec/XFRM offload API for testing.
>
> Signed-off-by: Shannon Nelson
Thanks for the patch! Just a number of stylistic nit picks.
> diff --git a/drivers/net/netdevsim/ipsec.c b/drivers/net/netdevsim/ipsec.c
> new file mo
The pch_gbe driver currently presumes that the PHY is connected using
RGMII, and would need further work to support other buses. It includes a
define which is always set that conditionalises some of the
RGMII-specific code regardless. Remove it. If we do ever support
different MII buses then prepro
For some reason the pch_gbe driver contains a struct pch_gbe_functions
with pointers used by a HAL abstraction layer, even though there is only
one implementation of each function.
This patch removes the get_bus_info abstraction. Its single
implementation (pch_gbe_plat_get_bus_info) only sets valu
The pch_gbe driver includes some code which appears to be an attempt to
work around a problem with the pch_gbe_free_rx_resources &
pch_gbe_free_tx_resources functions that no longer exists. Remove the
code guarded by the never-defined RINGFREE preprocessor macro.
Signed-off-by: Paul Burton
---
For some reason the pch_gbe driver contains a struct pch_gbe_functions
with pointers used by a HAL abstraction layer, even though there is only
one implementation of each function.
This patch removes the power_up_phy & power_down_phy abstractions in
favor of calling pch_phy_power_up & pch_phy_powe
The pch_gbe driver calls a pch_gbe_hal_setup_init_funcs function which
ultimately sets the value of one field in struct pch_gbe_phy_info in a
convoluted way.
This patch removes pch_gbe_hal_setup_init_funcs in favor of inlining it,
and in turn its callee pch_gbe_plat_init_function_pointers, into th
For some reason the pch_gbe driver contains a struct pch_gbe_functions
with pointers used by a HAL abstraction layer, even though there is only
one implementation of each function.
This patch removes the init_hw abstraction in favor of inlining its
single implementation (pch_gbe_plat_init_hw) into
For some reason the pch_gbe driver contains a struct pch_gbe_functions
with pointers used by a HAL abstraction layer, even though there is only
one implementation of each function.
This patch removes the read_mac_addr abstraction in favor of calling
pch_gbe_mac_read_mac_addr directly. Since this i
Refactor pch_gbe_set_multi in order to avoid unnecessary indentation &
make it clearer what the code is doing.
The one behavioral change from this patch is that we'll no longer
configure the MAC address registers for multicast addresses when the
IFF_PROMISC or IFF_ALLMULTI flags are set. In these
The pch_gbe driver sets up multicast address filters using a convoluted
mechanism by which pch_gbe_set_multi allocates an array to hold
multicast addresses, copies desired addresses into that array, calls a
pch_gbe_mac_mc_addr_list_update function which copies addresses out of
that array into MAC r
For some reason the pch_gbe driver contains a struct pch_gbe_functions
with pointers used by a HAL abstraction layer, even though there is only
one implementation of each function.
This patch removes the sw_reset_phy abstraction, which it turns out is
never even used. Its one implementation, which
Make use of the module_pci_driver() macro to remove some needless
boilerplate code from the pch_gbe driver. This does have the side effect
of removing the print of the driver's version during probe, but this is
pretty useless information anyway - the version has changed only once
whilst the driver
For some reason the pch_gbe driver contains a struct pch_gbe_functions
with pointers used by a HAL abstraction layer, even though there is only
one implementation of each function.
This patch removes the reset_phy abstraction in favor of calling
pch_gbe_phy_hw_reset directly.
Signed-off-by: Paul
The pch_gbe driver includes a 'copybreak' parameter which appears to
have been copied from the e1000e driver but is entirely unused. Remove
the dead code.
Signed-off-by: Paul Burton
---
.../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 15 ---
1 file changed, 15 deletions(-)
diff
This series begins the process of cleaning up the pch_gbe network
driver. Whilst my ultimate goal is to add support for using this driver
on the MIPS Boston development board, this series sets that aside in
favor of making some more general cleanups. My hope is that this will
both make the driver a
For some reason the pch_gbe driver contains a struct pch_gbe_functions
with pointers used by a HAL abstraction layer, even though there is only
one implementation of each function.
This patch removes the read_phy_reg & write_phy_reg abstractions in
favor of calling pch_gbe_phy_read_reg_miic & pch_
From: Eric Dumazet
Date: Fri, 22 Jun 2018 16:27:47 -0700
> struct net are effectively allocated from order-1 pages on x86,
> with one object per slab, meaning that the 13 low order bits
> of their addresses are zero.
>
> Once shifted by L1_CACHE_SHIFT, this leaves 7 zero-bits,
> meaning that net
From: Cong Wang
Date: Fri, 22 Jun 2018 14:33:16 -0700
> In update_vf():
>
> cftree_remove(cl);
> update_cfmin(cl->cl_parent);
>
> the cl_cfmin of cl->cl_parent is intentionally updated to 0
> when that parent only has one child. And if this parent is
> root qdisc, we could end up, in hfsc_s
From: Eric Dumazet
Date: Fri, 22 Jun 2018 06:44:13 -0700
> This patch series fix some issues with rx_tstamp_last_feedback.
>
> - Switch to monotonic clock.
> - Avoid potential overflows on fast hosts/networks.
Series applied and queued up for -stable.
Thank you.
From: Hangbin Liu
Date: Thu, 21 Jun 2018 19:49:36 +0800
> After recieving MLD querys, we update idev->mc_maxdelay with max_delay
> from query header. This make the later unsolicited reports have the same
> interval with mc_maxdelay, which means we may send unsolicited reports with
> long interval
From: Bas Vermeulen
Date: Thu, 21 Jun 2018 13:42:22 +0200
> Setting dev->node to the mac_node in dpaa_eth_add_device during probe
> causes the mac_probe to be called again for the dpaa-ethernet.* device
> that was just added.
>
> Fix this by not setting dev->node, as it is not needed.
>
> Signe
Implement the IPsec/XFRM offload API for testing.
Signed-off-by: Shannon Nelson
---
drivers/net/netdevsim/Makefile| 4 +
drivers/net/netdevsim/ipsec.c | 345 ++
drivers/net/netdevsim/netdev.c| 7 +
drivers/net/netdevsim/netdevsim.h | 37
Fix up the existing ipsec selftest and add tests for
the ipsec offload driver API.
Shannon Nelson (4):
selftests: rtnetlink: clear the return code at start of ipsec test
selftests: rtnetlink: use dummydev as a test device
netdevsim: add ipsec offload testing
selftests: rtnetlink: add ipsec
Using the netdevsim as a device for testing, try out the XFRM commands
for setting up IPsec hardware offloads.
Signed-off-by: Shannon Nelson
---
tools/testing/selftests/net/rtnetlink.sh | 114 +++
1 file changed, 114 insertions(+)
diff --git a/tools/testing/selftests
We really shouldn't mess with local system settings, so let's
use the already created dummy device instead for ipsec testing.
Oh, and let's put the temp file into a proper directory.
Signed-off-by: Shannon Nelson
---
tools/testing/selftests/net/rtnetlink.sh | 15 +++
1 file changed,
Following the custom from the other functions, clear the global
ret code before starting the test so as to not have previously
failed tests cause us to think this test has failed.
Reported-by: Anders Roxell
Signed-off-by: Shannon Nelson
---
tools/testing/selftests/net/rtnetlink.sh | 2 ++
1 fil
struct net are effectively allocated from order-1 pages on x86,
with one object per slab, meaning that the 13 low order bits
of their addresses are zero.
Once shifted by L1_CACHE_SHIFT, this leaves 7 zero-bits,
meaning that net_hash_mix() does not help spreading
objects on various hash tables.
Fo
Hi,
While debugging a NAPI related issue (calling napi_disable() twice
leading to deadlock),
I have come across below query. The issue is not documented anywhere
(except for Ben grear's ath10k patch)
Below are my expectations:
napi_disable(): waits for SCHED (ignoring other flags)
napi_enable()
In update_vf():
cftree_remove(cl);
update_cfmin(cl->cl_parent);
the cl_cfmin of cl->cl_parent is intentionally updated to 0
when that parent only has one child. And if this parent is
root qdisc, we could end up, in hfsc_schedule_watchdog(),
that we can't decide the next schedule time for qdis
Hi Steffen,
While adding the ipsec-offload API to netdevsim I ran across an issue
with the use of x->xso.offload_handle that I think needs attention, and
would like your opinion before I try to address it.
The offload_handle is essentially an opaque magic cookie to be used by
the driver to h
Stopping offload completely if replace of program failed dates
back to days of transparent offload. Back then we wanted to
silently fall back to the in-driver processing. Today we mark
programs for offload when they are loaded into the kernel, so
the transparent offload is no longer a reality.
F
The patch below worked for me (on 4.14.51 LTS kernel):
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
index 1e33abd..2b3863a 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
+++ b/drivers/net/ethernet/broadcom
Begin forwarded message:
Date: Fri, 22 Jun 2018 15:20:06 +
From: bugzilla-dae...@bugzilla.kernel.org
To: step...@networkplumber.org
Subject: [Bug 200191] New: UBSAN: Undefined behaviour in
./include/net/xfrm.h:894
https://bugzilla.kernel.org/show_bug.cgi?id=200191
Bug ID: 20
On 06/22/2018 07:01 AM, Ursula Braun wrote:
> The recent poll change may lead to stalls for non-blocking connecting
> SMC sockets, since sock_poll_wait is no longer performed on the
> internal CLC socket, but on the outer SMC socket. kernel_connect() on
> the internal CLC socket returns with -E
On Thu, 21 Jun 2018 10:09:36 -0700
Martin KaFai Lau wrote:
> On Wed, Jun 20, 2018 at 08:00:11PM -0700, dsah...@kernel.org wrote:
> > From: David Ahern
> >
> > For ACLs implemented using either FIB rules or FIB entries, the BPF
> > program needs the FIB lookup status to be able to drop the packe
Ah, that is great! I will test it out on my machine and let you know.
Thanks,
Vishwanath
On 06/22/2018 10:21 AM, Kalluru, Sudarsana wrote:
> Hi Vishwanath,
> The config will be cached in the device structure
> (bp->rss_conf_obj.udp_rss_v4) in this scenario, and will be applied in the
> load
Add map_release_uref pointer to hashmap ops. This was dropped when
original sockhash code was ported into bpf-next before initial
commit.
Fixes: 81110384441a ("bpf: sockmap, add hash map support")
Acked-by: Martin KaFai Lau
Signed-off-by: John Fastabend
---
kernel/bpf/sockmap.c |1 +
1 file
This addresses two syzbot issues that lead to identifying (by Eric and
Wei) a class of bugs where we don't correctly check for IPv4/v6
sockets and their associated state. The second issue was a locking
omission in sockhash.
The first patch addresses IPv6 socks and fixing an error where
sockhash wo
This fixes a crash where we assign tcp_prot to IPv6 sockets instead
of tcpv6_prot.
Previously we overwrote the sk->prot field with tcp_prot even in the
AF_INET6 case. This patch ensures the correct tcp_prot and tcpv6_prot
are used.
Tested with 'netserver -6' and 'netperf -H [IPv6]' as well as
'ne
If a hashmap is free'd with open socks it removes the reference to
the hash entry from the psock. If that is the last reference to the
psock then it will also be free'd by the reference counting logic.
However the current logic that removes the hash reference from the
list of references is broken.
First in tcp_close, reduce scope of sk_callback_lock() the lock is
only needed for protecting maps list the ingress and cork
lists are protected by sock lock. Having the lock in wider scope is
harmless but may confuse the reader who may infer it is in fact
needed.
Next, in sock_hash_delete_elem()
On Thu, Jun 21, 2018 at 03:37:54PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Hi,
>
> This series exposes RoCE ICRC counter through existing RDMA hw_counters
> sysfs interface.
>
> First patch has all HW definitions in mlx5_ifc.h file and second patch is
> actual counter implemen
Hi Vishwanath,
The config will be cached in the device structure
(bp->rss_conf_obj.udp_rss_v4) in this scenario, and will be applied in the load
path (bnx2x_nic_load() --> bnx2x_init_rss()). Have unit tested the change on my
setup.
Thanks,
Sudarsana
-Original Message-
From: Vishwan
The recent poll change may lead to stalls for non-blocking connecting
SMC sockets, since sock_poll_wait is no longer performed on the
internal CLC socket, but on the outer SMC socket. kernel_connect() on
the internal CLC socket returns with -EINPROGRESS, but the wake up
logic does not work in all
To compute delays, better not use time of the day which can
be changed by admins or malicious programs.
Also change ccid3_first_li() to use s64 type for delta variable
to avoid potential overflows.
Signed-off-by: Eric Dumazet
Cc: Gerrit Renker
Cc: d...@vger.kernel.org
---
net/dccp/ccids/ccid3.
On fast hosts or malicious bots, we trigger a DCCP_BUG() which
seems excessive.
syzbot reported :
BUG: delta (-6195) <= 0 at
net/dccp/ccids/ccid3.c:628/ccid3_hc_rx_send_feedback()
CPU: 1 PID: 18 Comm: ksoftirqd/1 Not tainted 4.18.0-rc1+ #112
Hardware name: Google Google Compute Engine/Google Com
This patch series fix some issues with rx_tstamp_last_feedback.
- Switch to monotonic clock.
- Avoid potential overflows on fast hosts/networks.
Eric Dumazet (2):
net: dccp: avoid crash in ccid3_hc_rx_send_feedback()
net: dccp: switch rx_tstamp_last_feedback to monotonic clock
net/dccp/ccid
Hi Sudarsana,
Thanks for taking a look at my email. The fix you suggested would
definitely fix the kernel panic, but at the same time wouldn't it also
silently ignore the request by ethtool to set rx-flow-hash?
Thanks,
Vishwanath
On 06/22/2018 06:20 AM, Kalluru, Sudarsana wrote:
> Hi Vishwanath,
On 06/22/2018 04:19 AM, Peter Robinson wrote:
> Hi All,
>
> I'm seeing this netlink/sk_filter_trim_cap crash on ARMv7 across quite
> a few ARMv7 platforms on Fedora with 4.18rc1. I've tested RPi2/RPi3
> (doesn't happen on aarch64), AllWinner H3, BeagleBone and a few
> others, both LPAE/normal k
Hi All,
I'm seeing this netlink/sk_filter_trim_cap crash on ARMv7 across quite
a few ARMv7 platforms on Fedora with 4.18rc1. I've tested RPi2/RPi3
(doesn't happen on aarch64), AllWinner H3, BeagleBone and a few
others, both LPAE/normal kernels.
I'm a bit out of my depth in this part of the kernel
> Il 21 giugno 2018 alle 1.00 Cong Wang ha scritto:
> Please also test HFSC_RSC ("rt") if possible.
Hi Cong,
sorry for the delayed response.
I have tested this hfsc rt setup:
tc class add dev eth2 parent 1:2 classid 1:16 hfsc rt m2 500kbit
and
tc class add dev eth2 parent 1:2 classid 1:16 hfsc
Hi Vishwanath,
Thanks for your mail, and the analysis.
The fix would be to invoke bnx2x_rss() only when the device is opened,
if (bp->state == BNX2X_STATE_OPEN)
return bnx2x_rss(bp, &bp->rss_conf_obj, false, true);
else
return 0;
Ariel,
Could y
> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: Friday, June 22, 2018 1:07 AM
> To: Andrew Lunn
> Cc: Vadim Pasternak ; da...@davemloft.net;
> netdev@vger.kernel.org; j...@resnulli.us
> Subject: Re: [PATCH v0 03/12] mlxsw: core: Add core environment module
On 21.06.2018 18:28, David Ahern wrote:
> On 6/21/18 4:03 AM, Kirill Tkhai wrote:
>>> This patch does not remove the BUG, so does not really solve the
>>> problem. ie., it is fairly trivial to write a script (32k dev%d named
>>> devices in init_net) that triggers it again, so your commit subject an
On Thu, Jun 21, 2018 at 05:31:31PM +0200, Arnd Bergmann wrote:
> On Thu, Jun 21, 2018 at 2:45 PM, Ilias Apalodimas
> wrote:
> > On Thu, Jun 21, 2018 at 02:19:55PM +0200, Ivan Vecera wrote:
>
> > The driver is currently widely used and that's the reason we tried to avoid
> > rewriting it. The curr
> Got it. I'm targeting a different market, with a different
> architecture. In this architecture it makes more sense to separate the
> EEPROM access from the IO pins control.
The fact you are targeting a different architecture is why you are
getting no traction. The closer you stick to the kern
From: Shannon Nelson
Date: Thu, 21 Jun 2018 23:50:36 -0700
> For that matter, if you want to cut down on patch thrash, just drop
> patch 2.
Too late, already in my tree :)
Don't worry about it for now.
57 matches
Mail list logo
