> -Original Message-
> From: Tariq Toukan
> Sent: Sunday, June 30, 2019 10:57
> To: David Miller ; f...@strlen.de
> Cc: netdev@vger.kernel.org; Ran Rozenstein ; Tariq
> Toukan
> Subject: Re: [PATCH net-next 0/2] net: ipv4: fix circular-list infinite loop
>
>
>
> On 6/27/2019 7:54 PM,
On 01.07.2019 00:21, Karsten Wiborg wrote:
> Hi Heiner,
>
> On 30/06/2019 23:55, Heiner Kallweit wrote:
>> This one shows that the vendor driver (r8168) uses a random MAC address.
>> Means the driver can't read a valid MAC address from the chip, maybe due
>> to a broken BIOS.
>> Alternatively you
On Sun, Jun 30, 2019 at 4:48 PM Andreas Steinmetz wrote:
>
> At this point, skb could only be a valid pointer, so this patch does
> not introduce any functional change.
Previously, macsec_post_decrypt could be called on the original skb if
the initial condition was false and macsec_decrypt is ski
Hi Catherine,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Catherine-Sullivan/gve-Add-basic-driver-framework-for-Compute-Engine-Virtual-NIC/20190629-161725
config: i386-allyesconfig (attached as .config)
On Sun, Jun 30, 2019 at 4:48 PM Andreas Steinmetz wrote:
>
> Remove superfluous zeroing of skb pointer for the RX_HANDLER_CONSUMED
> case, since in that case, __netif_receive_skb_core will simply ignore
> the value.
>
> Signed-off-by: Andreas Steinmetz
Acked-by: Willem de Bruijn
On Sun, Jun 30, 2019 at 4:48 PM Andreas Steinmetz wrote:
>
> Remove superfluous skb_share_check() and skb_unshare().
> macsec_decrypt is only called by macsec_handle_frame which
> already does a skb_unshare().
There is a subtle difference. skb_unshare() acts on cloned skbs, not
shared skbs.
It c
On Sun, Jun 30, 2019 at 4:48 PM Andreas Steinmetz wrote:
>
> Fix checksumming after decryption.
>
> Signed-off-by: Andreas Steinmetz
>
> --- a/drivers/net/macsec.c 2019-06-30 22:14:10.250285314 +0200
> +++ b/drivers/net/macsec.c 2019-06-30 22:15:11.931230417 +0200
> @@ -869,6 +869,7 @@
From: John Hurley
Date: Thu, 27 Jun 2019 14:37:30 +0100
> Skbs may have their checksum value populated by HW. If this is a checksum
> calculated over the entire packet then the CHECKSUM_COMPLETE field is
> marked. Changes to the data pointer on the skb throughout the network
> stack still try to
From: Saeed Mahameed
Date: Fri, 28 Jun 2019 23:18:18 +
> This series adds misc updates to mlx5e driver.
> For more information please see tag log below.
>
> Please pull and let me know if there is any problem.
>
> Please note that the series starts with a merge of mlx5-next branch,
> to res
Hi Catherine,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Catherine-Sullivan/gve-Add-basic-driver-framework-for-Compute-Engine-Virtual-NIC/20190629-161725
config: i386-allyesconfig (attached as .config)
On Sun, Jun 30, 2019 at 4:48 PM Andreas Steinmetz wrote:
>
> Fix use-after-free of skb when rx_handler returns RX_HANDLER_PASS.
>
> Signed-off-by: Andreas Steinmetz
Acked-by: Willem de Bruijn
This is for fixing bug KMSAN: uninit-value in ax88772_bind
Tested by
https://groups.google.com/d/msg/syzkaller-bugs/aFQurGotng4/cFe9nxMCCwAJ
Reported-by: syzbot+8a3fc6674bbc3978e...@syzkaller.appspotmail.com
syzbot found the following crash on:
HEAD commit:f75e4cfe kmsan: use kmsan_handle_u
From: Jeff Kirsher
Date: Fri, 28 Jun 2019 15:49:17 -0700
> This series contains a smorgasbord of updates to many of the Intel
> drivers.
...
Pulled, thanks Jeff.
Please respond to Joe Perches's feedback on the debug macros.
Thanks.
From: Michael Chan
Date: Sat, 29 Jun 2019 11:16:43 -0400
> Miscellaneous bug fix patches, including two resource handling fixes for
> the RDMA driver, a PCI shutdown patch to add pci_disable_device(), a patch
> to fix ethtool selftest crash, and the last one suppresses an unnecessry
> error messa
Hi Heiner,
On 30/06/2019 23:55, Heiner Kallweit wrote:
> This one shows that the vendor driver (r8168) uses a random MAC address.
> Means the driver can't read a valid MAC address from the chip, maybe due
> to a broken BIOS.
> Alternatively you could use r8169 and set a MAC address manually with
>
On 30.06.2019 23:29, Karsten Wiborg wrote:
> Hi Heiner,
>
> On 30/06/2019 19:42, Heiner Kallweit wrote:
>> Vendor driver uses this code, do you see the related messages in syslog?
>>
>> if (!is_valid_ether_addr(mac_addr)) {
>> netif_err(tp, probe, dev, "Invalid ether addr %
Hi Andrew,
On 30/06/2019 19:56, Andrew Lunn wrote:
> 0x6e = 0110 1110b. Bit 1 is the Locally Administered bit. Meaning this
> is not an MAC address from a vendor pool, but one generated locally.
>
> http://www.noah.org/wiki/MAC_address
Didn't know that. Thanks for pointing that out.
> If linux w
Hi Heiner,
On 30/06/2019 19:42, Heiner Kallweit wrote:
> Vendor driver uses this code, do you see the related messages in syslog?
>
> if (!is_valid_ether_addr(mac_addr)) {
> netif_err(tp, probe, dev, "Invalid ether addr %pM\n",
> mac_addr);
>
Fix checksumming after decryption.
Signed-off-by: Andreas Steinmetz
--- a/drivers/net/macsec.c 2019-06-30 22:14:10.250285314 +0200
+++ b/drivers/net/macsec.c 2019-06-30 22:15:11.931230417 +0200
@@ -869,6 +869,7 @@
static void macsec_finalize_skb(struct sk_buff *skb, u8 icv_len, u8 h
Fix use-after-free of skb when rx_handler returns RX_HANDLER_PASS.
Signed-off-by: Andreas Steinmetz
--- a/drivers/net/macsec.c 2019-06-05 20:23:27.640154747 +0200
+++ b/drivers/net/macsec.c 2019-06-05 20:23:46.791565816 +0200
@@ -1103,10 +1103,9 @@ static rx_handler_result_t macsec_han
This patchset removes some unnecessary code in the receive path of the
macsec driver, and re-indents the error handling after calling
macsec_decrypt to make the post-processing clearer.
This is a combined effort of Sabrina Dubroca and me.
At this point, skb could only be a valid pointer, so this patch does
not introduce any functional change.
Signed-off-by: Andreas Steinmetz
--- a/drivers/net/macsec.c 2019-06-30 22:05:17.785683634 +0200
+++ b/drivers/net/macsec.c 2019-06-30 22:05:20.526171178 +0200
@@ -1205,21 +1205,22
Remove superfluous zeroing of skb pointer for the RX_HANDLER_CONSUMED
case, since in that case, __netif_receive_skb_core will simply ignore
the value.
Signed-off-by: Andreas Steinmetz
--- a/drivers/net/macsec.c 2019-06-30 22:04:10.003613880 +0200
+++ b/drivers/net/macsec.c 2019-06-30 2
This series fixes some bugs in the receive path of macsec. The first
is a use after free when processing macsec frames with a SecTAG that
has the TCI E bit set but the C bit clear. In the 2nd bug, the driver
leaves an invalid checksumming state after decrypting the packet.
This is a combined effor
Remove superfluous skb_share_check() and skb_unshare().
macsec_decrypt is only called by macsec_handle_frame which
already does a skb_unshare().
Signed-off-by: Andreas Steinmetz
--- a/drivers/net/macsec.c 2019-06-30 22:02:54.906908179 +0200
+++ b/drivers/net/macsec.c 2019-06-30 22:03:0
Hello,
On Tue, 25 Jun 2019, Vadim Fedorenko wrote:
> windows real servers can handle gre tunnels, this patch allows
> gre encapsulation with the tunneling method, thereby letting ipvs
> be load balancer for windows-based services
>
> Signed-off-by: Vadim Fedorenko
Looks like
When ip creates a netns, there is a small time interval between the
placeholder file creation in NETNS_RUN_DIR and the bind mount from /proc.
Add a temporary file named .mounting-$netns which gets deleted after the
bind mount, so watching for delete event matching the .mounting-* name
will notify
Currently, gratuitous ARP/ND packets are sent every `miimon'
milliseconds. This commit allows a user to specify a custom delay
through a new option, `peer_notif_delay'.
Like for `updelay' and `downdelay', this delay should be a multiple of
`miimon' to avoid managing an additional work queue. The c
> The vendor part of my MAC is 6e:69:73 which is interesting because
> according to some Vendor-Lookup-pages the vendor is unknown.
0x6e = 0110 1110b. Bit 1 is the Locally Administered bit. Meaning this
is not an MAC address from a vendor pool, but one generated locally.
http://www.noah.org/wiki/
On 30.06.2019 18:03, Karsten Wiborg wrote:
> Hi Andrew,
>
> On 30/06/2019 16:55, Andrew Lunn wrote:
>> Hi Karsten
>>
>> What MAC address do you get with the vendor driver? Is it the same MAC
>> address every time you reboot, or does it look random.
>>
>> The BIOS is expected to program the MAC add
On Sun, Jun 30, 2019 at 07:47:45PM +0300, Ilias Apalodimas wrote:
On Sun, Jun 30, 2019 at 07:41:28PM +0300, Ivan Khoronzhuk wrote:
On Sun, Jun 30, 2019 at 07:32:14PM +0300, Ilias Apalodimas wrote:
>On Sun, Jun 30, 2019 at 07:25:53PM +0300, Ivan Khoronzhuk wrote:
>>On Sat, Jun 29, 2019 at 08:23:2
On Sun, Jun 30, 2019 at 07:47:45PM +0300, Ilias Apalodimas wrote:
On Sun, Jun 30, 2019 at 07:41:28PM +0300, Ivan Khoronzhuk wrote:
On Sun, Jun 30, 2019 at 07:32:14PM +0300, Ilias Apalodimas wrote:
>On Sun, Jun 30, 2019 at 07:25:53PM +0300, Ivan Khoronzhuk wrote:
>>On Sat, Jun 29, 2019 at 08:23:2
On Sun, Jun 30, 2019 at 07:45:13PM +0300, Ivan Khoronzhuk wrote:
> On Sun, Jun 30, 2019 at 07:34:17PM +0300, Ilias Apalodimas wrote:
> >Hi Ivan,
> >>
> >>[...]
> >>
> >>>+
> >>>+static int netsec_xdp(struct net_device *ndev, struct netdev_bpf *xdp)
> >>>+{
> >>>+ struct netsec_priv *priv = netdev_
On Sun, Jun 30, 2019 at 07:41:28PM +0300, Ivan Khoronzhuk wrote:
> On Sun, Jun 30, 2019 at 07:32:14PM +0300, Ilias Apalodimas wrote:
> >On Sun, Jun 30, 2019 at 07:25:53PM +0300, Ivan Khoronzhuk wrote:
> >>On Sat, Jun 29, 2019 at 08:23:25AM +0300, Ilias Apalodimas wrote:
> >>>The interface only supp
On Sun, Jun 30, 2019 at 07:34:17PM +0300, Ilias Apalodimas wrote:
Hi Ivan,
[...]
>+
>+static int netsec_xdp(struct net_device *ndev, struct netdev_bpf *xdp)
>+{
>+ struct netsec_priv *priv = netdev_priv(ndev);
>+
>+ switch (xdp->command) {
>+ case XDP_SETUP_PROG:
>+ return nets
On Sun, Jun 30, 2019 at 07:32:14PM +0300, Ilias Apalodimas wrote:
On Sun, Jun 30, 2019 at 07:25:53PM +0300, Ivan Khoronzhuk wrote:
On Sat, Jun 29, 2019 at 08:23:25AM +0300, Ilias Apalodimas wrote:
>The interface only supports 1 Tx queue so locking is introduced on
>the Tx queue if XDP is enabled
On Thu, Jun 27, 2019 at 10:07 PM Taehee Yoo wrote:
>
> __vxlan_dev_create() destroys FDB using specific pointer which indicates
> a fdb when error occurs.
> But that pointer should not be used when register_netdevice() fails because
> register_netdevice() internally destroys fdb when error occurs.
Hi Ivan,
>
> [...]
>
> >+
> >+static int netsec_xdp(struct net_device *ndev, struct netdev_bpf *xdp)
> >+{
> >+struct netsec_priv *priv = netdev_priv(ndev);
> >+
> >+switch (xdp->command) {
> >+case XDP_SETUP_PROG:
> >+return netsec_xdp_setup(priv, xdp->prog, xdp->extack);
On Sun, Jun 30, 2019 at 07:25:53PM +0300, Ivan Khoronzhuk wrote:
> On Sat, Jun 29, 2019 at 08:23:25AM +0300, Ilias Apalodimas wrote:
> >The interface only supports 1 Tx queue so locking is introduced on
> >the Tx queue if XDP is enabled to make sure .ndo_start_xmit and
> >.ndo_xdp_xmit won't corrup
On Sat, Jun 29, 2019 at 08:23:25AM +0300, Ilias Apalodimas wrote:
The interface only supports 1 Tx queue so locking is introduced on
the Tx queue if XDP is enabled to make sure .ndo_start_xmit and
.ndo_xdp_xmit won't corrupt Tx ring
- Performance (SMMU off)
Benchmark XDP_SKB XDP_DRV
xdp1
From: Yishai Hadas
No need any more to hold mlx5_core_dev on the devx_object, it can be
accessed from ib_dev.
Signed-off-by: Yishai Hadas
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/hw/mlx5/devx.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git
From: Yishai Hadas
Add DEVX support for CQ events by creating and destroying the CQ via
mlx5_core and set an handler to manage its completions.
Signed-off-by: Yishai Hadas
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/hw/mlx5/devx.c | 39 +++
1 file changed
From: Yishai Hadas
Enable subscription for device events over DEVX.
Each subscription is added to the two level XA data structure according
to its event number and the DEVX object information in case was given
with the given target fd.
Those events will be reported over the given fd once will o
From: Yishai Hadas
Register DEVX with with mlx5_core to get async events. This will enable
to dispatch the applicable events to its consumers in down stream
patches.
Signed-off-by: Yishai Hadas
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/hw/mlx5/devx.c| 30 +
From: Yishai Hadas
Use the reported device capabilities for the supported user events (i.e.
affiliated and un-affiliated) to set the EQ mask.
As the event mask can be up to 256 defined by 4 entries of u64 change
the applicable code to work accordingly.
Signed-off-by: Yishai Hadas
Acked-by: Sae
From: Yishai Hadas
Implement DEVX dispatching event by looking up for the applicable
subscriptions for the reported event and using their target fd to
signal/set the event.
Signed-off-by: Yishai Hadas
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/hw/mlx5/devx.c | 303 +
From: Yishai Hadas
Report EQE data upon CQ completion to let upper layers use this data.
Signed-off-by: Yishai Hadas
Acked-by: Saeed Mahameed
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/hw/mlx5/cq.c | 2 +-
drivers/infiniband/hw/mlx5/main.c | 2
From: Yishai Hadas
Introduce MLX5_IB_OBJECT_DEVX_ASYNC_EVENT_FD and its initial
implementation.
This object is from type class FD and will be used to read DEVX
async events.
Signed-off-by: Yishai Hadas
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/hw/mlx5/devx.c | 95
From: Yishai Hadas
The firmware command to destroy a CQ might fail when the object is
referenced by other object and the ref count is managed by the firmware.
To enable a second successful destruction post the first failure need to
change mlx5_eq_del_cq() to be a void function.
As an error in
From: Yishai Hadas
Expose an extra device definitions for objects events.
It includes: object_type values for legacy objects and generic data
header for any other object.
Signed-off-by: Yishai Hadas
Acked-by: Saeed Mahameed
Signed-off-by: Leon Romanovsky
---
include/linux/mlx5/mlx5_ifc.h |
From: Yishai Hadas
Report a CQ error event only when a handler was set.
This enables mlx5_ib to not set a handler upon CQ creation and use some
other mechanism to get this event as of other events by the
mlx5_eq_notifier_register API.
Signed-off-by: Yishai Hadas
Acked-by: Saeed Mahameed
Signe
From: Yishai Hadas
Expose the API to register for ANY event, mlx5_ib will be able to use
this functionality for its needs.
Signed-off-by: Yishai Hadas
Acked-by: Saeed Mahameed
Signed-off-by: Leon Romanovsky
---
drivers/net/ethernet/mellanox/mlx5/core/eq.c | 2 ++
drivers/net/ethernet/mel
From: Leon Romanovsky
Changelog:
v1 -> v2:
* Added Saeed's ack to net patches
* Patch #2:
* Fix to gather user asynchronous events on top of kernel events.
* Patch #7:
* Fix obj_id to be 32 bits.
* Patch #8:
* Inline async_event_queue applicable fields into devx_async_event_file.
* M
From: Yishai Hadas
Enhance mlx5_core_create_cq() to get the command out buffer from the
callers to let them use the output.
Signed-off-by: Yishai Hadas
Acked-by: Saeed Mahameed
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/hw/mlx5/cq.c | 3 ++-
drivers/net/etherne
On Sat, Jun 29, 2019 at 08:23:25AM +0300, Ilias Apalodimas wrote:
[...]
+
+static int netsec_xdp(struct net_device *ndev, struct netdev_bpf *xdp)
+{
+ struct netsec_priv *priv = netdev_priv(ndev);
+
+ switch (xdp->command) {
+ case XDP_SETUP_PROG:
+ return netsec
Hi Andrew,
On 30/06/2019 16:55, Andrew Lunn wrote:
> Hi Karsten
>
> What MAC address do you get with the vendor driver? Is it the same MAC
> address every time you reboot, or does it look random.
>
> The BIOS is expected to program the MAC address into the hardware. It
> could be that the vendor
On Sun, Jun 30, 2019 at 02:40:14PM +0200, Karsten Wiborg wrote:
> Hi Heiner,
>
> On 30/06/2019 11:12, Heiner Kallweit wrote:
> > Indeed the MAC is missing:
> > [2.839776] r8169 :02:00.0 eth0: RTL8168h/8111h,
> > 00:00:00:00:00:00, XID 541, IRQ 126
> >
> > This works with RTL8168h in other
Hi Heiner,
On 30/06/2019 11:12, Heiner Kallweit wrote:
> Indeed the MAC is missing:
> [2.839776] r8169 :02:00.0 eth0: RTL8168h/8111h,
> 00:00:00:00:00:00, XID 541, IRQ 126
>
> This works with RTL8168h in other systems, so I'd say you should
> check with the vendor. Maybe it's a BIOS issue.
On 30.06.2019 02:14, Karsten Wiborg wrote:
> Hi Heiner,
>
> thanks for the speedy reply.
>
> On 6/30/19 12:09 AM, Heiner Kallweit wrote:
>> If r8169 (the mainline driver) is running, why do you want to switch
>> to r8168 (the Realtek vendor driver)? The latter is not supported by
>> the kernel co
On Mon, Jun 24, 2019 at 09:57:05PM +, Saeed Mahameed wrote:
> On Wed, 2019-06-19 at 07:45 +0300, Leon Romanovsky wrote:
> > On Tue, Jun 18, 2019 at 06:51:45PM +, Saeed Mahameed wrote:
> > > On Tue, 2019-06-18 at 20:15 +0300, Leon Romanovsky wrote:
> > > > From: Leon Romanovsky
> > > >
> >
On 6/24/2019 8:59 PM, Cong Wang wrote:
> On Thu, Jun 20, 2019 at 6:43 AM Paul Blakey wrote:
>> Hi,
>>
>> This patch series add connection tracking capabilities in tc sw datapath.
>> It does so via a new tc action, called act_ct, and new tc flower classifier
>> matching
>> on conntrack state, mar
On 6/27/2019 10:53 PM, David Miller wrote:
> From: Paul Blakey
> Date: Thu, 20 Jun 2019 16:42:18 +0300
>
>> +struct tcf_ct_params {
> ...
>> +struct rcu_head rcu;
>> +
>> +};
> Please get ride of that empty line after the 'rcu' member.
>
>> +switch (skb->protocol) {
>> +case htons(E
On 6/27/2019 7:54 PM, David Miller wrote:
> From: Florian Westphal
> Date: Thu, 27 Jun 2019 14:03:31 +0200
>
>> Tariq and Ran reported a regression caused by net-next commit
>> 2638eb8b50cf ("net: ipv4: provide __rcu annotation for ifa_list").
>>
>> This happens when net.ipv4.conf.$dev.promote_
On 30/06/2019 03:13, vto...@gmail.com wrote:
> On 30/06/2019 02:37, vto...@gmail.com wrote:
>> On 30/06/2019 01:23, vto...@gmail.com wrote:
>>> On 30/06/2019 01:11, Andrew Lunn wrote:
On Sun, Jun 30, 2019 at 01:04:50AM +0200, vto...@googlemail.com wrote:
> On 30/06/2019 00:49, Andrew Lun
64 matches
Mail list logo
