Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH iproute2] etf: make printing of variable JSON friendly
From: Patel, Vedang @ 2019-07-23 21:34 UTC (permalink / raw)
  To: David Ahern
  Cc: netdev@vger.kernel.org, Jamal Hadi Salim, Cong Wang, Jiri Pirko,
	Stephen Hemminger, Gomes, Vinicius, Dorileo, Leandro
In-Reply-To: <0e5fc2fe-dc83-b876-40ac-3b6f3f47bb29@gmail.com>



> On Jul 22, 2019, at 5:11 PM, David Ahern <dsahern@gmail.com> wrote:
> 
> On 7/22/19 1:11 PM, Patel, Vedang wrote:
>> 
>> 
>>> On Jul 22, 2019, at 11:21 AM, David Ahern <dsahern@gmail.com> wrote:
>>> 
>>> On 7/19/19 3:40 PM, Vedang Patel wrote:
>>>> In iproute2 txtime-assist series, it was pointed out that print_bool()
>>>> should be used to print binary values. This is to make it JSON friendly.
>>>> 
>>>> So, make the corresponding changes in ETF.
>>>> 
>>>> Fixes: 8ccd49383cdc ("etf: Add skip_sock_check")
>>>> Reported-by: Stephen Hemminger <stephen@networkplumber.org>
>>>> Signed-off-by: Vedang Patel <vedang.patel@intel.com>
>>>> ---
>>>> tc/q_etf.c | 12 ++++++------
>>>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>>> 
>>>> diff --git a/tc/q_etf.c b/tc/q_etf.c
>>>> index c2090589bc64..307c50eed48b 100644
>>>> --- a/tc/q_etf.c
>>>> +++ b/tc/q_etf.c
>>>> @@ -176,12 +176,12 @@ static int etf_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
>>>> 		     get_clock_name(qopt->clockid));
>>>> 
>>>> 	print_uint(PRINT_ANY, "delta", "delta %d ", qopt->delta);
>>>> -	print_string(PRINT_ANY, "offload", "offload %s ",
>>>> -				(qopt->flags & TC_ETF_OFFLOAD_ON) ? "on" : "off");
>>>> -	print_string(PRINT_ANY, "deadline_mode", "deadline_mode %s ",
>>>> -				(qopt->flags & TC_ETF_DEADLINE_MODE_ON) ? "on" : "off");
>>>> -	print_string(PRINT_ANY, "skip_sock_check", "skip_sock_check %s",
>>>> -				(qopt->flags & TC_ETF_SKIP_SOCK_CHECK) ? "on" : "off");
>>>> +	if (qopt->flags & TC_ETF_OFFLOAD_ON)
>>>> +		print_bool(PRINT_ANY, "offload", "offload ", true);
>>>> +	if (qopt->flags & TC_ETF_DEADLINE_MODE_ON)
>>>> +		print_bool(PRINT_ANY, "deadline_mode", "deadline_mode ", true);
>>>> +	if (qopt->flags & TC_ETF_SKIP_SOCK_CHECK)
>>>> +		print_bool(PRINT_ANY, "skip_sock_check", "skip_sock_check", true);
>>>> 
>>>> 	return 0;
>>>> }
>>>> 
>>> 
>>> This changes existing output for TC_ETF_OFFLOAD_ON and
>>> TC_ETF_DEADLINE_MODE_ON which were added a year ago.
>> Yes, this is a good point. I missed that. 
>> 
>> Another idea is to use is_json_context() and call print_bool() there. But, that will still change values corresponding to the json output for the above flags from “on”/“off” to “true”/“false”. I am not sure if this is a big issue. 
>> 
>> My suggestion is to keep the code as is. what do you think?
>> 
> 
> I think we need automated checkers for new code. ;-)
> 
> The first 2 should not change for backward compatibility - unless there
> is agreement that this feature is too new and long term it is better to
> print as above.
> 
> Then the new one should follow context of the other 2 - consistency IMHO
> takes precedence.
Thanks for the inputs. 

Let’s keep whatever is currently present upstream and you can ignore this patch.

Thanks,
Vedang

^ permalink raw reply

* Re: [PATCH v4 net-next 11/19] ionic: Add Rx filter and rx_mode ndo support
From: David Miller @ 2019-07-23 21:33 UTC (permalink / raw)
  To: snelson; +Cc: netdev
In-Reply-To: <20190722214023.9513-12-snelson@pensando.io>

From: Shannon Nelson <snelson@pensando.io>
Date: Mon, 22 Jul 2019 14:40:15 -0700

> +	if (in_interrupt()) {
> +		work = kzalloc(sizeof(*work), GFP_ATOMIC);
> +		if (!work) {
> +			netdev_err(lif->netdev, "%s OOM\n", __func__);
> +			return -ENOMEM;
> +		}
> +		work->type = add ? DW_TYPE_RX_ADDR_ADD : DW_TYPE_RX_ADDR_DEL;
> +		memcpy(work->addr, addr, ETH_ALEN);
> +		netdev_dbg(lif->netdev, "deferred: rx_filter %s %pM\n",
> +			   add ? "add" : "del", addr);
> +		ionic_lif_deferred_enqueue(&lif->deferred, work);
> +	} else {
> +		netdev_dbg(lif->netdev, "rx_filter %s %pM\n",
> +			   add ? "add" : "del", addr);
> +		if (add)
> +			return ionic_lif_addr_add(lif, addr);
> +		else
> +			return ionic_lif_addr_del(lif, addr);
> +	}

I don't know about this.

Generally interface address changes are expected to be synchronous.

^ permalink raw reply

* Re: [PATCH v4 net-next 06/19] ionic: Add basic adminq support
From: David Miller @ 2019-07-23 21:27 UTC (permalink / raw)
  To: snelson; +Cc: netdev
In-Reply-To: <20190722214023.9513-7-snelson@pensando.io>

From: Shannon Nelson <snelson@pensando.io>
Date: Mon, 22 Jul 2019 14:40:10 -0700

> +struct queue {
 ...
> +struct cq {
 ...
> +struct napi_stats {
 ...
> +struct q_stats {
 ...
> +struct qcq {

Using names like these and "dev_queue" are just asking for conflicts with the
global datastructure namespace both now and in the future.

Please put ionic_ or similar as a prefix to these data structure names.

Thank you.

^ permalink raw reply

* Re: [PATCH v4 net-next 05/19] ionic: Add interrupts and doorbells
From: David Miller @ 2019-07-23 21:24 UTC (permalink / raw)
  To: snelson; +Cc: netdev
In-Reply-To: <20190722214023.9513-6-snelson@pensando.io>

From: Shannon Nelson <snelson@pensando.io>
Date: Mon, 22 Jul 2019 14:40:09 -0700

> The ionic interrupt model is based on interrupt control blocks
> accessed through the PCI BAR.  Doorbell registers are used by
> the driver to signal to the NIC that requests are waiting on
> the message queues.  Interrupts are used by the NIC to signal
> to the driver that answers are waiting on the completion queues.
> 
> Signed-off-by: Shannon Nelson <snelson@pensando.io>

After applying this patch we get a warning:

drivers/net/ethernet/pensando/ionic/ionic_lif.c:33:13: warning: ‘ionic_intr_free’ defined but not used [-Wunused-function]
 static void ionic_intr_free(struct lif *lif, int index)
             ^~~~~~~~~~~~~~~
drivers/net/ethernet/pensando/ionic/ionic_lif.c:15:12: warning: ‘ionic_intr_alloc’ defined but not used [-Wunused-function]
 static int ionic_intr_alloc(struct lif *lif, struct intr *intr)
            ^~~~~~~~~~~~~~~~

Also:

> +	lif->dbid_inuse = kzalloc(BITS_TO_LONGS(lif->dbid_count) * sizeof(long),
> +				  GFP_KERNEL);

You can use bitmap_alloc() and friends from linux/bitmap.h for this kind of stuff.

^ permalink raw reply

* Re: [PATCH v4 net-next 02/19] ionic: Add hardware init and device commands
From: David Miller @ 2019-07-23 21:18 UTC (permalink / raw)
  To: snelson; +Cc: netdev
In-Reply-To: <20190722214023.9513-3-snelson@pensando.io>

From: Shannon Nelson <snelson@pensando.io>
Date: Mon, 22 Jul 2019 14:40:06 -0700

> +void ionic_init_devinfo(struct ionic_dev *idev)
> +{
> +	idev->dev_info.asic_type = ioread8(&idev->dev_info_regs->asic_type);
> +	idev->dev_info.asic_rev = ioread8(&idev->dev_info_regs->asic_rev);
> +
> +	memcpy_fromio(idev->dev_info.fw_version,
> +		      idev->dev_info_regs->fw_version,
> +		      IONIC_DEVINFO_FWVERS_BUFLEN);
> +
> +	memcpy_fromio(idev->dev_info.serial_num,
> +		      idev->dev_info_regs->serial_num,
> +		      IONIC_DEVINFO_SERIAL_BUFLEN);
 ...
> +	sig = ioread32(&idev->dev_info_regs->signature);

I think if you are going to use the io{read,write}{8,16,32,64}()
interfaces then you should use io{read,write}{8,16,32,64}_rep()
instead of memcpy_{to,from}io().


^ permalink raw reply

* Re: [net-next 0/6][pull request] 1GbE Intel Wired LAN Driver Updates 2019-07-23
From: Saeed Mahameed @ 2019-07-23 21:16 UTC (permalink / raw)
  To: jeffrey.t.kirsher@intel.com, davem@davemloft.net
  Cc: nhorman@redhat.com, sassmann@redhat.com, netdev@vger.kernel.org
In-Reply-To: <20190723173650.23276-1-jeffrey.t.kirsher@intel.com>

On Tue, 2019-07-23 at 10:36 -0700, Jeff Kirsher wrote:
> This series contains updates to igc and e1000e client drivers only.
> 
> Sasha provides a couple of cleanups to remove code that is not needed
> and reduce structure sizes.  Updated the MAC reset flow to use the
> device reset flow instead of a port reset flow.  Added addition
> device
> id's that will be supported.
> 
> Kai-Heng Feng provides a workaround for a possible stalled packet
> issue
> in our ICH devices due to a clock recovery from the PCH being too
> slow.
> Also provided a fix where the MAC & PHY may become de-sync'd causing
> a
> miss detection of link up events.

For what it's worth, Series LGTM.


^ permalink raw reply

* Re: [PATCH bpf 0/2] bpf: gso_segs fixes
From: Alexei Starovoitov @ 2019-07-23 21:15 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: Alexei Starovoitov, Daniel Borkmann, David S . Miller, netdev,
	Eric Dumazet, Stanislav Fomichev, bpf
In-Reply-To: <20190723101538.136328-1-edumazet@google.com>

On Tue, Jul 23, 2019 at 3:15 AM Eric Dumazet <edumazet@google.com> wrote:
>
> First patch changes the kernel, second patch
> adds a new test.
>
> Note that other patches might be needed to take
> care of similar issues in sock_ops_convert_ctx_access()
> and SOCK_OPS_GET_FIELD()

Nice catch!
Applied to bpf tree. Thanks

^ permalink raw reply

* [PATCH v2 bpf-next] libbpf: provide more helpful message on uninitialized global var
From: Andrii Nakryiko @ 2019-07-23 21:11 UTC (permalink / raw)
  To: bpf, netdev, ast, daniel, songliubraving
  Cc: andrii.nakryiko, kernel-team, Andrii Nakryiko

When BPF program defines uninitialized global variable, it's put into
a special COMMON section. Libbpf will reject such programs, but will
provide very unhelpful message with garbage-looking section index.

This patch detects special section cases and gives more explicit error
message.

Signed-off-by: Andrii Nakryiko <andriin@fb.com>
---
 tools/lib/bpf/libbpf.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 794dd5064ae8..8741c39adb1c 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -1760,15 +1760,22 @@ bpf_program__collect_reloc(struct bpf_program *prog, GElf_Shdr *shdr,
 			 (long long) sym.st_value, sym.st_name, name);
 
 		shdr_idx = sym.st_shndx;
+		insn_idx = rel.r_offset / sizeof(struct bpf_insn);
+		pr_debug("relocation: insn_idx=%u, shdr_idx=%u\n",
+			 insn_idx, shdr_idx);
+
+		if (shdr_idx >= SHN_LORESERVE) {
+			pr_warning("relocation: not yet supported relo for non-static global \'%s\' variable in special section (0x%x) found in insns[%d].code 0x%x\n",
+				   name, shdr_idx, insn_idx,
+				   insns[insn_idx].code);
+			return -LIBBPF_ERRNO__RELOC;
+		}
 		if (!bpf_object__relo_in_known_section(obj, shdr_idx)) {
 			pr_warning("Program '%s' contains unrecognized relo data pointing to section %u\n",
 				   prog->section_name, shdr_idx);
 			return -LIBBPF_ERRNO__RELOC;
 		}
 
-		insn_idx = rel.r_offset / sizeof(struct bpf_insn);
-		pr_debug("relocation: insn_idx=%u\n", insn_idx);
-
 		if (insns[insn_idx].code == (BPF_JMP | BPF_CALL)) {
 			if (insns[insn_idx].src_reg != BPF_PSEUDO_CALL) {
 				pr_warning("incorrect bpf_call opcode\n");
-- 
2.17.1


^ permalink raw reply related

* Re: [PATCH v1] net: thunderx: Use fwnode_get_mac_address()
From: David Miller @ 2019-07-23 21:09 UTC (permalink / raw)
  To: andriy.shevchenko; +Cc: sgoutham, rric, linux-arm-kernel, netdev
In-Reply-To: <20190723200344.69864-1-andriy.shevchenko@linux.intel.com>

From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Tue, 23 Jul 2019 23:03:43 +0300

> Replace the custom implementation with fwnode_get_mac_address,
> which works on both DT and ACPI platforms.
> 
> While here, replace memcpy() by ether_addr_copy().
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next 1/1] tc-testing: added tdc tests for [b|p]fifo qdisc
From: David Miller @ 2019-07-23 21:08 UTC (permalink / raw)
  To: mrv; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri
In-Reply-To: <1563908519-30111-1-git-send-email-mrv@mojatatu.com>

From: Roman Mashak <mrv@mojatatu.com>
Date: Tue, 23 Jul 2019 15:01:59 -0400

> Signed-off-by: Roman Mashak <mrv@mojatatu.com>

Always love to see new tests...  Applied.

^ permalink raw reply

* Re: [PATCH v2 00/10] XDP unaligned chunk placement support
From: Alexei Starovoitov @ 2019-07-23 21:08 UTC (permalink / raw)
  To: Kevin Laatz
  Cc: Network Development, Alexei Starovoitov, Daniel Borkmann,
	Björn Töpel, Karlsson, Magnus, Jakub Kicinski,
	Jonathan Lemon, bruce.richardson, ciara.loftus, bpf,
	intel-wired-lan
In-Reply-To: <20190716030637.5634-1-kevin.laatz@intel.com>

Johnathan, Bjorn, Jakub,
Please review!
The patch set has been pending for a week.

On Tue, Jul 16, 2019 at 4:21 AM Kevin Laatz <kevin.laatz@intel.com> wrote:
>
> This patch set adds the ability to use unaligned chunks in the XDP umem.
>
> Currently, all chunk addresses passed to the umem are masked to be chunk
> size aligned (default is 2k, max is PAGE_SIZE). This limits where we can
> place chunks within the umem as well as limiting the packet sizes that are
> supported.
>
> The changes in this patch set removes these restrictions, allowing XDP to
> be more flexible in where it can place a chunk within a umem. By relaxing
> where the chunks can be placed, it allows us to use an arbitrary buffer
> size and place that wherever we have a free address in the umem. These
> changes add the ability to support arbitrary frame sizes up to 4k
> (PAGE_SIZE) and make it easy to integrate with other existing frameworks
> that have their own memory management systems, such as DPDK.
>
> Since we are now dealing with arbitrary frame sizes, we need also need to
> update how we pass around addresses. Currently, the addresses can simply be
> masked to 2k to get back to the original address. This becomes less trivial
> when using frame sizes that are not a 'power of 2' size. This patch set
> modifies the Rx/Tx descriptor format to use the upper 16-bits of the addr
> field for an offset value, leaving the lower 48-bits for the address (this
> leaves us with 256 Terabytes, which should be enough!). We only need to use
> the upper 16-bits to store the offset when running in unaligned mode.
> Rather than adding the offset (headroom etc) to the address, we will store
> it in the upper 16-bits of the address field. This way, we can easily add
> the offset to the address where we need it, using some bit manipulation and
> addition, and we can also easily get the original address wherever we need
> it (for example in i40e_zca_free) by simply masking to get the lower
> 48-bits of the address field.
>
> The numbers below were recorded with the following set up:
>   - Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz
>   - Intel Corporation Ethernet Controller XXV710 for 25GbE SFP28 (rev 02)
>   - Driver: i40e
>   - Application: xdpsock with l2fwd (single interface)
>
> These are solely for comparing performance with and without the patches.
> The largest drop was ~1% (in zero-copy mode).
>
> +-------------------------+------------+-----------------+-------------+
> | Buffer size: 2048       | SKB mode   | Zero-copy       | Copy        |
> +-------------------------+------------+-----------------+-------------+
> | Aligned (baseline)      | 1.7 Mpps   | 15.3 Mpps       | 2.08 Mpps   |
> +-------------------------+------------+-----------------+-------------+
> | Aligned (with patches)  | 1.7 Mpps   | 15.1 Mpps       | 2.08 Mpps   |
> +-------------------------+------------+-----------------+-------------+
> | Unaligned               | 1.7 Mpps   | 14.5 Mpps       | 2.08 Mpps   |
> +-------------------------+------------+-----------------+-------------+
>
> NOTE: We are currently working on the changes required in the Mellanox
> driver. We will include these in the v3.
>
> Structure of the patchset:
> Patch 1:
>   - Remove unnecessary masking and headroom addition during zero-copy Rx
>     buffer recycling in i40e. This change is required in order for the
>     buffer recycling to work in the unaligned chunk mode.
>
> Patch 2:
>   - Remove unnecessary masking and headroom addition during
>     zero-copy Rx buffer recycling in ixgbe. This change is required in
>     order for the  buffer recycling to work in the unaligned chunk mode.
>
> Patch 3:
>   - Add infrastructure for unaligned chunks. Since we are dealing with
>     unaligned chunks that could potentially cross a physical page boundary,
>     we add checks to keep track of that information. We can later use this
>     information to correctly handle buffers that are placed at an address
>     where they cross a page boundary.  This patch also modifies the
>     existing Rx and Tx functions to use the new descriptor format. To
>     handle addresses correctly, we need to mask appropriately based on
>     whether we are in aligned or unaligned mode.
>
> Patch 4:
>   - This patch updates the i40e driver to make use of the new descriptor
>     format. The new format is particularly useful here since we can now
>     retrieve the original address in places like i40e_zca_free with ease.
>     This saves us doing various calculations to get the original address
>     back.
>
> Patch 5:
>   - This patch updates the ixgbe driver to make use of the new descriptor
>     format. The new format is particularly useful here since we can now
>     retrieve the original address in places like ixgbe_zca_free with ease.
>     This saves us doing various calculations to get the original address
>     back.
>
> Patch 6:
>   - Add flags for umem configuration to libbpf
>
> Patch 7:
>   - Modify xdpsock application to add a command line option for
>     unaligned chunks
>
> Patch 8:
>   - Since we can now run the application in unaligned chunk mode, we need
>     to make sure we recycle the buffers appropriately.
>
> Patch 9:
>   - Adds hugepage support to the xdpsock application
>
> Patch 10:
>   - Documentation update to include the unaligned chunk scenario. We need
>     to explicitly state that the incoming addresses are only masked in the
>     aligned chunk mode and not the unaligned chunk mode.
>
> ---
> v2:
>   - fixed checkpatch issues
>   - fixed Rx buffer recycling for unaligned chunks in xdpsock
>   - removed unused defines
>   - fixed how chunk_size is calculated in xsk_diag.c
>   - added some performance numbers to cover letter
>   - modified descriptor format to make it easier to retrieve original
>     address
>   - removed patch adding off_t off to the zero copy allocator. This is no
>     longer needed with the new descriptor format.
>
> Kevin Laatz (10):
>   i40e: simplify Rx buffer recycle
>   ixgbe: simplify Rx buffer recycle
>   xsk: add support to allow unaligned chunk placement
>   i40e: modify driver for handling offsets
>   ixgbe: modify driver for handling offsets
>   libbpf: add flags to umem config
>   samples/bpf: add unaligned chunks mode support to xdpsock
>   samples/bpf: add buffer recycling for unaligned chunks to xdpsock
>   samples/bpf: use hugepages in xdpsock app
>   doc/af_xdp: include unaligned chunk case
>
>  Documentation/networking/af_xdp.rst          | 10 ++-
>  drivers/net/ethernet/intel/i40e/i40e_xsk.c   | 39 +++++----
>  drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 39 +++++----
>  include/net/xdp_sock.h                       |  2 +
>  include/uapi/linux/if_xdp.h                  |  9 ++
>  net/xdp/xdp_umem.c                           | 17 ++--
>  net/xdp/xsk.c                                | 89 ++++++++++++++++----
>  net/xdp/xsk_diag.c                           |  2 +-
>  net/xdp/xsk_queue.h                          | 70 +++++++++++++--
>  samples/bpf/xdpsock_user.c                   | 61 ++++++++++----
>  tools/include/uapi/linux/if_xdp.h            |  4 +
>  tools/lib/bpf/xsk.c                          |  3 +
>  tools/lib/bpf/xsk.h                          |  2 +
>  13 files changed, 266 insertions(+), 81 deletions(-)
>
> --
> 2.17.1
>

^ permalink raw reply

* Re: [PATCH v2] drivers: net: xgene: Remove acpi_has_method() calls
From: David Miller @ 2019-07-23 21:07 UTC (permalink / raw)
  To: skunberg.kelsey
  Cc: iyappan, keyur, quan, netdev, linux-kernel, bjorn, skhan,
	linux-kernel-mentees
In-Reply-To: <20190723.140646.505566792140054611.davem@davemloft.net>

From: David Miller <davem@davemloft.net>
Date: Tue, 23 Jul 2019 14:06:46 -0700 (PDT)

> From: Kelsey Skunberg <skunberg.kelsey@gmail.com>
> Date: Tue, 23 Jul 2019 12:58:11 -0600
> 
>> acpi_evaluate_object will already return an error if the needed method
>> does not exist. Remove unnecessary acpi_has_method() calls and check the
>> returned acpi_status for failure instead.
>> 
>> Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com>
>> ---
>> Changes in v2:
>> 	- Fixed white space warnings and errors
> 
> Applied to net-next.

Wow did you even build test this?   Reverted...

drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c: In function ‘xgene_enet_reset’:
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:480:13: error: invalid storage class for function ‘xgene_enet_cle_bypass’
 static void xgene_enet_cle_bypass(struct xgene_enet_pdata *p,
             ^~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:480:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
 static void xgene_enet_cle_bypass(struct xgene_enet_pdata *p,
 ^~~~~~
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:506:13: error: invalid storage class for function ‘xgene_enet_clear’
 static void xgene_enet_clear(struct xgene_enet_pdata *pdata,
             ^~~~~~~~~~~~~~~~
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:522:13: error: invalid storage class for function ‘xgene_enet_shutdown’
 static void xgene_enet_shutdown(struct xgene_enet_pdata *p)
             ^~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:532:13: error: invalid storage class for function ‘xgene_enet_link_state’
 static void xgene_enet_link_state(struct work_struct *work)
             ^~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:563:13: error: invalid storage class for function ‘xgene_sgmac_enable_tx_pause’
 static void xgene_sgmac_enable_tx_pause(struct xgene_enet_pdata *p, bool enable)
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:604:1: error: expected declaration or statement at end of input
 };
 ^
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:599:29: warning: unused variable ‘xgene_sgport_ops’ [-Wunused-variable]
 const struct xgene_port_ops xgene_sgport_ops = {
                             ^~~~~~~~~~~~~~~~
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:582:28: warning: unused variable ‘xgene_sgmac_ops’ [-Wunused-variable]
 const struct xgene_mac_ops xgene_sgmac_ops = {
                            ^~~~~~~~~~~~~~~
At top level:
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:437:12: warning: ‘xgene_enet_reset’ defined but not used [-Wunused-function]
 static int xgene_enet_reset(struct xgene_enet_pdata *p)
            ^~~~~~~~~~~~~~~~

^ permalink raw reply

* Re: [PATCH v2] drivers: net: xgene: Remove acpi_has_method() calls
From: David Miller @ 2019-07-23 21:06 UTC (permalink / raw)
  To: skunberg.kelsey
  Cc: iyappan, keyur, quan, netdev, linux-kernel, bjorn, skhan,
	linux-kernel-mentees
In-Reply-To: <20190723185811.8548-1-skunberg.kelsey@gmail.com>

From: Kelsey Skunberg <skunberg.kelsey@gmail.com>
Date: Tue, 23 Jul 2019 12:58:11 -0600

> acpi_evaluate_object will already return an error if the needed method
> does not exist. Remove unnecessary acpi_has_method() calls and check the
> returned acpi_status for failure instead.
> 
> Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com>
> ---
> Changes in v2:
> 	- Fixed white space warnings and errors

Applied to net-next.

^ permalink raw reply

* Re: [PATCH bpf v3] bpf: fix narrower loads on s390
From: Alexei Starovoitov @ 2019-07-23 21:04 UTC (permalink / raw)
  To: Ilya Leoshkevich; +Cc: bpf, Network Development, Y Song, gor, Heiko Carstens
In-Reply-To: <20190719091815.92181-1-iii@linux.ibm.com>

On Fri, Jul 19, 2019 at 2:18 AM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
>
> The very first check in test_pkt_md_access is failing on s390, which
> happens because loading a part of a struct __sk_buff field produces
> an incorrect result.
>
> The preprocessed code of the check is:
>
> {
>         __u8 tmp = *((volatile __u8 *)&skb->len +
>                 ((sizeof(skb->len) - sizeof(__u8)) / sizeof(__u8)));
>         if (tmp != ((*(volatile __u32 *)&skb->len) & 0xFF)) return 2;
> };
>
> clang generates the following code for it:
>
>       0:        71 21 00 03 00 00 00 00 r2 = *(u8 *)(r1 + 3)
>       1:        61 31 00 00 00 00 00 00 r3 = *(u32 *)(r1 + 0)
>       2:        57 30 00 00 00 00 00 ff r3 &= 255
>       3:        5d 23 00 1d 00 00 00 00 if r2 != r3 goto +29 <LBB0_10>
>
> Finally, verifier transforms it to:
>
>   0: (61) r2 = *(u32 *)(r1 +104)
>   1: (bc) w2 = w2
>   2: (74) w2 >>= 24
>   3: (bc) w2 = w2
>   4: (54) w2 &= 255
>   5: (bc) w2 = w2
>
> The problem is that when verifier emits the code to replace a partial
> load of a struct __sk_buff field (*(u8 *)(r1 + 3)) with a full load of
> struct sk_buff field (*(u32 *)(r1 + 104)), an optional shift and a
> bitwise AND, it assumes that the machine is little endian and
> incorrectly decides to use a shift.
>
> Adjust shift count calculation to account for endianness.
>
> Fixes: 31fd85816dbe ("bpf: permits narrower load from bpf program context fields")
> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>

Applied to bpf tree. Thanks

^ permalink raw reply

* Re: [net-next 6/6] e1000e: disable force K1-off feature
From: David Miller @ 2019-07-23 21:04 UTC (permalink / raw)
  To: jeffrey.t.kirsher; +Cc: kai.heng.feng, netdev, nhorman, sassmann, aaron.f.brown
In-Reply-To: <20190723173650.23276-7-jeffrey.t.kirsher@intel.com>

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 23 Jul 2019 10:36:50 -0700

> diff --git a/drivers/net/ethernet/intel/e1000e/hw.h b/drivers/net/ethernet/intel/e1000e/hw.h
> index eff75bd8a8f0..e3c71fd093ee 100644
> --- a/drivers/net/ethernet/intel/e1000e/hw.h
> +++ b/drivers/net/ethernet/intel/e1000e/hw.h
> @@ -662,6 +662,7 @@ struct e1000_dev_spec_ich8lan {
>  	bool kmrn_lock_loss_workaround_enabled;
>  	struct e1000_shadow_ram shadow_ram[E1000_ICH8_SHADOW_RAM_WORDS];
>  	bool nvm_k1_enabled;
> +	bool disable_k1_off;
>  	bool eee_disable;

I don't see any code actually setting this boolean, how does it work?

^ permalink raw reply

* Re: [PATCH net-next] dpaa2-eth: Don't use netif_receive_skb_list for TCP frames
From: David Miller @ 2019-07-23 21:02 UTC (permalink / raw)
  To: ruxandra.radulescu; +Cc: netdev, ioana.ciornei, vladimir.oltean
In-Reply-To: <1563902923-26178-1-git-send-email-ruxandra.radulescu@nxp.com>

From: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Date: Tue, 23 Jul 2019 20:28:43 +0300

> Using Rx skb bulking for all frames may negatively impact the
> performance in some TCP termination scenarios, as it effectively
> bypasses GRO.

"may"?

Please provide numbers so that we know exactly whether it actually
hurts performance one way or another.

Thank you.

^ permalink raw reply

* Re: [PATCH v1] hv_sock: Use consistent types for UUIDs
From: David Miller @ 2019-07-23 20:58 UTC (permalink / raw)
  To: andriy.shevchenko; +Cc: haiyangz, kys, sthemmin, sashal, linux-hyperv, netdev
In-Reply-To: <20190723163943.65991-1-andriy.shevchenko@linux.intel.com>

From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Tue, 23 Jul 2019 19:39:43 +0300

> The rest of Hyper-V code is using new types for UUID handling.
> Convert hv_sock as well.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Applied to net-next.

^ permalink raw reply

* Re: [PATCH] sky2: Disable MSI on ASUS P6T
From: David Miller @ 2019-07-23 20:55 UTC (permalink / raw)
  To: tiwai; +Cc: netdev, mlindner, stephen, m.seyfarth
In-Reply-To: <20190723151525.6526-1-tiwai@suse.de>

From: Takashi Iwai <tiwai@suse.de>
Date: Tue, 23 Jul 2019 17:15:25 +0200

> The onboard sky2 NIC on ASUS P6T WS PRO doesn't work after PM resume
> due to the infamous IRQ problem.  Disabling MSI works around it, so
> let's add it to the blacklist.
> 
> Unfortunately the BIOS on the machine doesn't fill the standard
> DMI_SYS_* entry, so we pick up DMI_BOARD_* entries instead.
> 
> BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1142496
> Reported-and-tested-by: Marcus Seyfarth <m.seyfarth@gmail.com>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>

Applied and queued up for -stable, thanks.

^ permalink raw reply

* Re: [PATCH net-next 0/4] nfp: Offload MPLS actions
From: David Miller @ 2019-07-23 20:53 UTC (permalink / raw)
  To: john.hurley; +Cc: netdev, simon.horman, jakub.kicinski, oss-drivers
In-Reply-To: <1563892442-4654-1-git-send-email-john.hurley@netronome.com>

From: John Hurley <john.hurley@netronome.com>
Date: Tue, 23 Jul 2019 15:33:58 +0100

> The module act_mpls has recently been added to the kernel. This allows the
> manipulation of MPLS headers on packets including push, pop and modify.
> Add these new actions and parameters to the intermediate representation
> API for hardware offload. Follow this by implementing the offload of these
> MPLS actions in the NFP driver.

Looks nice, clean, and straightforward.

Applied, thanks.

^ permalink raw reply

* Re: [PATCH net-next 1/3] enetc: Add mdio bus driver for the PCIe MDIO endpoint
From: Saeed Mahameed @ 2019-07-23 20:49 UTC (permalink / raw)
  To: claudiu.manoil@nxp.com, davem@davemloft.net
  Cc: linux-arm-kernel@lists.infradead.org, leoyang.li@nxp.com,
	devicetree@vger.kernel.org, netdev@vger.kernel.org,
	alexandru.marginean@nxp.com, robh+dt@kernel.org,
	linux-kernel@vger.kernel.org
In-Reply-To: <1563894955-545-2-git-send-email-claudiu.manoil@nxp.com>

On Tue, 2019-07-23 at 18:15 +0300, Claudiu Manoil wrote:
> ENETC ports can manage the MDIO bus via local register
> interface.  However there's also a centralized way
> to manage the MDIO bus, via the MDIO PCIe endpoint
> device integrated by the same root complex that also
> integrates the ENETC ports (eth controllers).
> 
> Depending on board design and use case, centralized
> access to MDIO may be better than using local ENETC
> port registers.  For instance, on the LS1028A QDS board
> where MDIO muxing is requiered.  Also, the LS1028A on-chip
> switch doesn't have a local MDIO register interface.
> 
> The current patch registers the above PCIe enpoint as a
> separate MDIO bus and provides a driver for it by re-using
> the code used for local MDIO access.  It also allows the
> ENETC port PHYs to be managed by this driver if the local
> "mdio" node is missing from the ENETC port node.
> 
> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
> ---
>  .../net/ethernet/freescale/enetc/enetc_mdio.c | 90
> +++++++++++++++++++
>  .../net/ethernet/freescale/enetc/enetc_pf.c   |  5 +-
>  2 files changed, 94 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> index 77b9cd10ba2b..efa8a29f463d 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> @@ -197,3 +197,93 @@ void enetc_mdio_remove(struct enetc_pf *pf)
>  		mdiobus_free(pf->mdio);
>  	}
>  }
> +
> +#define ENETC_MDIO_DEV_ID	0xee01
> +#define ENETC_MDIO_DEV_NAME	"FSL PCIe IE Central MDIO"
> +#define ENETC_MDIO_BUS_NAME	ENETC_MDIO_DEV_NAME " Bus"
> +#define ENETC_MDIO_DRV_NAME	ENETC_MDIO_DEV_NAME " driver"
> +#define ENETC_MDIO_DRV_ID	"fsl_enetc_mdio"
> +
> +static int enetc_pci_mdio_probe(struct pci_dev *pdev,
> +				const struct pci_device_id *ent)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct mii_bus *bus;
> +	int err;
> +
> +	bus = mdiobus_alloc_size(sizeof(u32 *));
> +	if (!bus)
> +		return -ENOMEM;
> +
> +	bus->name = ENETC_MDIO_BUS_NAME;
> +	bus->read = enetc_mdio_read;
> +	bus->write = enetc_mdio_write;
> +	bus->parent = dev;
> +	snprintf(bus->id, MII_BUS_ID_SIZE, "%s", dev_name(dev));
> +
> +	pcie_flr(pdev);
> +	err = pci_enable_device_mem(pdev);
> +	if (err) {
> +		dev_err(dev, "device enable failed\n");

mdiobus_free(bus) is missing here and in every error path.

> +		return err;
> +	}
> +
> +	err = pci_request_mem_regions(pdev, ENETC_MDIO_DRV_ID);
> +	if (err) {
> +		dev_err(dev, "pci_request_regions failed\n");
> +		goto err_pci_mem_reg;
> +	}
> +
> +	bus->priv = pci_iomap_range(pdev, 0, ENETC_MDIO_REG_OFFSET, 0);
> +	if (!bus->priv) {
> +		err = -ENXIO;
> +		dev_err(dev, "ioremap failed\n");
> +		goto err_ioremap;
> +	}
> +
> +	err = of_mdiobus_register(bus, dev->of_node);
> +	if (err)
> +		goto err_mdiobus_reg;
> +
> +	pci_set_drvdata(pdev, bus);
> +
> +	return 0;
> +
> +err_mdiobus_reg:
> +	iounmap(bus->priv);
> +err_ioremap:
> +	pci_release_mem_regions(pdev);
> +err_pci_mem_reg:
> +	pci_disable_device(pdev);
> +
> +	return err;
> +}
> +
> +static void enetc_pci_mdio_remove(struct pci_dev *pdev)
> +{
> +	struct mii_bus *bus = pci_get_drvdata(pdev);
> +
> +	mdiobus_unregister(bus);
> +	iounmap(bus->priv);
> +	mdiobus_free(bus);
> +

this should come last to be symmetrical with probe flow.

> +	pci_release_mem_regions(pdev);
> +	pci_disable_device(pdev);
> +}
> +
> +static const struct pci_device_id enetc_pci_mdio_id_table[] = {
> +	{ PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, ENETC_MDIO_DEV_ID) },
> +	{ 0, } /* End of table. */
> +};
> +MODULE_DEVICE_TABLE(pci, enetc_mdio_id_table);
> +
> +static struct pci_driver enetc_pci_mdio_driver = {
> +	.name = ENETC_MDIO_DRV_ID,
> +	.id_table = enetc_pci_mdio_id_table,
> +	.probe = enetc_pci_mdio_probe,
> +	.remove = enetc_pci_mdio_remove,
> +};
> +module_pci_driver(enetc_pci_mdio_driver);
> +
> +MODULE_DESCRIPTION(ENETC_MDIO_DRV_NAME);
> +MODULE_LICENSE("Dual BSD/GPL");
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> index 258b3cb38a6f..7d6513ff8507 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> @@ -750,6 +750,7 @@ static int enetc_of_get_phy(struct
> enetc_ndev_priv *priv)
>  {
>  	struct enetc_pf *pf = enetc_si_priv(priv->si);
>  	struct device_node *np = priv->dev->of_node;
> +	struct device_node *mdio_np;
>  	int err;
>  
>  	if (!np) {
> @@ -773,7 +774,9 @@ static int enetc_of_get_phy(struct
> enetc_ndev_priv *priv)
>  		priv->phy_node = of_node_get(np);
>  	}
>  
> -	if (!of_phy_is_fixed_link(np)) {
> +	mdio_np = of_get_child_by_name(np, "mdio");
> +	if (mdio_np) {
> +		of_node_put(mdio_np);
>  		err = enetc_mdio_probe(pf);
>  		if (err) {
>  			of_node_put(priv->phy_node);

^ permalink raw reply

* Re: [bpf-next 6/6] selftests/bpf: add test for bpf_tcp_gen_syncookie
From: Alexei Starovoitov @ 2019-07-23 20:46 UTC (permalink / raw)
  To: Lorenz Bauer
  Cc: Petar Penkov, Networking, bpf, davem, Alexei Starovoitov,
	Daniel Borkmann, Eric Dumazet, Stanislav Fomichev, Petar Penkov,
	yhs
In-Reply-To: <CACAyw9-qQ8KbQk6Q6dg0+A337ZbSpot-sHpH_tSxFaQmUfhLyQ@mail.gmail.com>

On Tue, Jul 23, 2019 at 10:37:29AM +0100, Lorenz Bauer wrote:
> On Tue, 23 Jul 2019 at 01:20, Petar Penkov <ppenkov.kernel@gmail.com> wrote:
> > +static __always_inline __s64 gen_syncookie(void *data_end, struct bpf_sock *sk,
> > +                                          void *iph, __u32 ip_size,
> > +                                          struct tcphdr *tcph)
> > +{
> > +       __u32 thlen = tcph->doff * 4;
> > +
> > +       if (tcph->syn && !tcph->ack) {
> > +               // packet should only have an MSS option
> > +               if (thlen != 24)
> > +                       return 0;
> 
> Just for my own understanding: without this the verifier complains since
> thlen is not a known value, even though it is in bounds due to the check below?

the verifier understands only constant part of the packet pointer.
Without additional 'if' above the statement:
if ((void *)tcph + thlen > data_end)
will add variables length 'thlen' to pkt pointer which will become
another pkt pointer (with different id).
That pointer would need 'pkt + const_range > data_end' to have valid access.

We hit this issue in the past when folks wanted to use bpf_csum_diff() helper
with variable size.
It's possible to extend the verifier to support that but it's intrusive,
since variable part would need to passed around to a bunch of check* functions.
I think it's tricky, but doable. Looking forward to patches :)

> > +
> > +               if ((void *)tcph + thlen > data_end)
> > +                       return 0;
> > +
> > +               return bpf_tcp_gen_syncookie(sk, iph, ip_size, tcph, thlen);
> > +       }
> > +       return 0;
> > +}
> > +
> 
> -- 
> Lorenz Bauer  |  Systems Engineer
> 6th Floor, County Hall/The Riverside Building, SE1 7PB, UK
> 
> www.cloudflare.com

^ permalink raw reply

* Re: [PATCH net-next v2] net/mlx5e: xsk: dynamically allocate mlx5e_channel_param
From: David Miller @ 2019-07-23 20:39 UTC (permalink / raw)
  To: maximmi
  Cc: arnd, ast, daniel, bpf, netdev, saeedm, leon, jakub.kicinski,
	hawk, john.fastabend, tariqt
In-Reply-To: <20190723120208.27423-1-maximmi@mellanox.com>

From: Maxim Mikityanskiy <maximmi@mellanox.com>
Date: Tue, 23 Jul 2019 12:02:26 +0000

> From: Arnd Bergmann <arnd@arndb.de>
> 
> The structure is too large to put on the stack, resulting in a
> warning on 32-bit ARM:
> 
> drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c:59:5: error: stack frame size of 1344 bytes in function
>       'mlx5e_open_xsk' [-Werror,-Wframe-larger-than=]
> 
> Use kvzalloc() instead.
> 
> Fixes: a038e9794541 ("net/mlx5e: Add XSK zero-copy support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
> ---
> v2 changes: use kvzalloc/kvfree and fix a memory leak.

I'll apply this directly to net-next.

Thanks Maxim.

^ permalink raw reply

* Re: [PATCH] net: dsa: sja1105: sja1105_main: Add of_node_put()
From: David Miller @ 2019-07-23 20:38 UTC (permalink / raw)
  To: nishkadg.linux
  Cc: olteanv, andrew, vivien.didelot, f.fainelli, netdev, linux-kernel
In-Reply-To: <20190723104448.8125-1-nishkadg.linux@gmail.com>

From: Nishka Dasgupta <nishkadg.linux@gmail.com>
Date: Tue, 23 Jul 2019 16:14:48 +0530

> Each iteration of for_each_child_of_node puts the previous node, but in
> the case of a return from the middle of the loop, there is no put, thus
> causing a memory leak. Hence add an of_node_put before the return.
> Issue found with Coccinelle.
> 
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>

Applied.

Again, the semantics of these looping constructs are terrible.

^ permalink raw reply

* Re: [PATCH] net: dsa: mv88e6xxx: chip: Add of_node_put() before return
From: David Miller @ 2019-07-23 20:38 UTC (permalink / raw)
  To: nishkadg.linux; +Cc: andrew, vivien.didelot, f.fainelli, netdev
In-Reply-To: <20190723104307.8068-1-nishkadg.linux@gmail.com>

From: Nishka Dasgupta <nishkadg.linux@gmail.com>
Date: Tue, 23 Jul 2019 16:13:07 +0530

> Each iteration of for_each_available_child_of_node puts the previous
> node, but in the case of a return from the middle of the loop, there is
> no put, thus causing a memory leak. Hence add an of_node_put before the
> return.
> Issue found with Coccinelle.
> 
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>

Applied, but as I've repeatedly stated these OF node looping constructs
are EXTREMELY ERROR PRONE.

We must fix these kinds of interfaces so that they are easier to use
correctly.

^ permalink raw reply

* Re: [PATCH mlx5-next] net/mlx5: Fix modify_cq_in alignment
From: Saeed Mahameed @ 2019-07-23 20:34 UTC (permalink / raw)
  To: davem@davemloft.net, leon@kernel.org
  Cc: Jason Gunthorpe, Yishai Hadas, netdev@vger.kernel.org,
	linux-rdma@vger.kernel.org, dledford@redhat.com, Edward Srouji
In-Reply-To: <20190723.130211.1967999203654051483.davem@davemloft.net>

On Tue, 2019-07-23 at 13:02 -0700, David Miller wrote:
> From: Leon Romanovsky <leon@kernel.org>
> Date: Tue, 23 Jul 2019 22:04:14 +0300
> 
> > The intention was to have this patch in shared mlx5 branch, which
> > is
> > picked by RDMA too. This "Cc: stable@..." together with merge
> > through
> > RDMA will ensure that such patch will be part of stable
> > automatically.
> 
> Why wouldn't it come via Saeed's usual mlx5 bug fix pull requests to
> me?

That should have been the plan in first place, i will handle this,
thanks Dave and sorry for any inconvenience.

I will apply this patch to my (mlx5) net queue, will submit to net
shortly.

Leon can merge the next -rc when this patch lands there.
meanwhile, Leon can also merge my (mlx5) net queue which is always
based on latest -rc.
https://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git/log/?h=net-mlx5



^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox