* Re: [PATCH net-next 0/2] net: sched: act_ctinfo: fixes
From: Kevin 'ldir' Darbyshire-Bryant @ 2019-06-18 7:33 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20190617.140106.2136391777805798865.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 743 bytes --]
> On 17 Jun 2019, at 22:01, David Miller <davem@davemloft.net> wrote:
>
> From: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
> Date: Mon, 17 Jun 2019 11:03:25 +0100
>
>>
<snipped>
>> If I ever get to a developer conference please feel free to
>> tar/feather/apply cone of shame.
>
> :-) In kernel networking development we prefer brown paper bags over
> cones of shame, just FYI :) :) :)
LOL - I’ll bear that in mind :-) I thought fixing the code and admitting
my incompetence was the best policy…I’d be found out at some point anyway :-)
>
> Series applied, thanks.
Excellent. Hopefully that will be it.
Cheers,
Kevin D-B
gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: kernel/workqueue.c:3030 __flush_work+0x2c2/0x2d0
From: Naresh Kamboju @ 2019-06-18 7:39 UTC (permalink / raw)
To: Hillf Danton
Cc: Netdev, linux- stable, open list, David S. Miller, sgarzare,
Daniel Borkmann, kafai, jakub, lkft-triage,
open list:KERNEL SELFTEST FRAMEWORK, john.fastabend
In-Reply-To: <CA+G9fYsr_YW7PSoP+ew60TfNOj885y6j-e2weuWBuU1ccKcAAg@mail.gmail.com>
Hi Hillf,
On Tue, 18 Jun 2019 at 09:40, Hillf Danton <hdanton@sina.com> wrote:
>
>
> Hello
>
> On Sun, 16 Jun 2019 19:30:27 -0700 (PDT) Naresh Kamboju wrote:
> > Kernel warning while running kernel selftest bpf test_sockmap test case on
> > x86_64 and arm64.
> > The kernel warning log pops up continuously.
> >
> > Linux version 5.1.10-rc2
> >
> > Steps to reproduce:
> > Boot stable rc 5.1.10-rc2 kernel on x86_64 or arm64
> > cd selftests/bpf
> > ./test_sockmap
> >
> > [ 37.600406] WARNING: CPU: 3 PID: 57 at /usr/src/kernel/kernel/workqueue.c:3030 __flush_work+0x2c2/0x2d0
...
> >
> >
> Only find this; wish it may be paving a brick perhaps for those looking to fix the
> 3030 warning.
>
>
> Hillf
Thanks for looking into this problem,
There is a recent patch fixed this problem on 5.1.12 stable rc branch today
and AUTOSEL on current stable review.
bpf: sockmap, only stop/flush strp if it was enabled at some point
link: https://lore.kernel.org/lkml/20190604232212.6753-12-sashal@kernel.org/
Best regards
Naresh Kamboju
^ permalink raw reply
* Re: [PATCH] uapi: avoid namespace conflict in linux/posix_types.h
From: Florian Weimer @ 2019-06-18 7:44 UTC (permalink / raw)
To: Linus Torvalds
Cc: Joseph Myers, Arnd Bergmann, Linux API, linux-arch, Netdev,
Laura Abbott, Paul Burton, Deepa Dinamani,
Linux List Kernel Mailing
In-Reply-To: <CAHk-=wjF6ek4v04w2O3CuOaauDERfdyduW+h=u9uN5ja1ObLzQ@mail.gmail.com>
* Linus Torvalds:
> On Mon, Jun 17, 2019 at 11:19 AM Florian Weimer <fweimer@redhat.com> wrote:
>> >
>> > Unlike the "val[]" thing, I don't think anybody is supposed to access
>> > those fields directly.
>>
>> Well, glibc already calls it __val …
>
> Hmm. If user space already doesn't see the "val[]" array anyway, I
> guess we could just do that in the kernel too.
>
> Looking at the glibc headers I have for fds_bits, glibc seems to do
> *both* fds_bits[] and __fds_bits[] depending on __USE_XOPEN or not.
>
> Anyway, that all implies to me that we might as well just go the truly
> mindless way, and just do the double underscores and not bother with
> renaming any files.
>
> I thought people actually might care about the "val[]" name because I
> find that in documentation, but since apparently it's already not
> visible to user space anyway, that can't be true.
>
> I guess that makes the original patch acceptable, and we should just
> do the same thing to fds_bits..
Hah.
I think Arnd's original patch already had both. So it's ready to go in
after all?
Thanks,
Florian
^ permalink raw reply
* [PATCH v3 0/2] Add macb support for SiFive FU540-C000
From: Yash Shah @ 2019-06-18 7:56 UTC (permalink / raw)
To: davem, devicetree, netdev, linux-kernel, linux-riscv
Cc: robh+dt, mark.rutland, nicolas.ferre, palmer, aou, paul.walmsley,
ynezz, sachin.ghadi, Yash Shah
On FU540, the management IP block is tightly coupled with the Cadence
MACB IP block. It manages many of the boundary signals from the MACB IP
This patchset controls the tx_clk input signal to the MACB IP. It
switches between the local TX clock (125MHz) and PHY TX clocks. This
is necessary to toggle between 1Gb and 100/10Mb speeds.
Future patches may add support for monitoring or controlling other IP
boundary signals.
This patchset is mostly based on work done by
Wesley Terpstra <wesley@sifive.com>
This patchset is based on Linux v5.2-rc1 and tested on HiFive Unleashed
board with additional board related patches needed for testing can be
found at dev/yashs/ethernet_v3 branch of:
https://github.com/yashshah7/riscv-linux.git
Change History:
V3:
- Revert "MACB_SIFIVE_FU540" config changes in Kconfig and driver code.
The driver does not depend on SiFive GPIO driver.
V2:
- Change compatible string from "cdns,fu540-macb" to "sifive,fu540-macb"
- Add "MACB_SIFIVE_FU540" in Kconfig to support SiFive FU540 in macb
driver. This is needed because on FU540, the macb driver depends on
SiFive GPIO driver.
- Avoid writing the result of a comparison to a register.
- Fix the issue of probe fail on reloading the module reported by:
Andreas Schwab <schwab@suse.de>
Yash Shah (2):
macb: bindings doc: add sifive fu540-c000 binding
macb: Add support for SiFive FU540-C000
Documentation/devicetree/bindings/net/macb.txt | 3 +
drivers/net/ethernet/cadence/macb_main.c | 123 +++++++++++++++++++++++++
2 files changed, 126 insertions(+)
--
1.9.1
^ permalink raw reply
* [PATCH v3 1/2] macb: bindings doc: add sifive fu540-c000 binding
From: Yash Shah @ 2019-06-18 7:56 UTC (permalink / raw)
To: davem, devicetree, netdev, linux-kernel, linux-riscv
Cc: robh+dt, mark.rutland, nicolas.ferre, palmer, aou, paul.walmsley,
ynezz, sachin.ghadi, Yash Shah
In-Reply-To: <1560844568-4746-1-git-send-email-yash.shah@sifive.com>
Add the compatibility string documentation for SiFive FU540-C0000
interface.
On the FU540, this driver also needs to read and write registers in a
management IP block that monitors or drives boundary signals for the
GEMGXL IP block that are not directly mapped to GEMGXL registers.
Therefore, add additional range to "reg" property for SiFive GEMGXL
management IP registers.
Signed-off-by: Yash Shah <yash.shah@sifive.com>
Reviewed-by: Paul Walmsley <paul.walmsley@sifive.com>
---
Documentation/devicetree/bindings/net/macb.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
index 9c5e944..63c73fa 100644
--- a/Documentation/devicetree/bindings/net/macb.txt
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -15,8 +15,11 @@ Required properties:
Use "atmel,sama5d4-gem" for the GEM IP (10/100) available on Atmel sama5d4 SoCs.
Use "cdns,zynq-gem" Xilinx Zynq-7xxx SoC.
Use "cdns,zynqmp-gem" for Zynq Ultrascale+ MPSoC.
+ Use "sifive,fu540-macb" for SiFive FU540-C000 SoC.
Or the generic form: "cdns,emac".
- reg: Address and length of the register set for the device
+ For "sifive,fu540-macb", second range is required to specify the
+ address and length of the registers for GEMGXL Management block.
- interrupts: Should contain macb interrupt
- phy-mode: See ethernet.txt file in the same directory.
- clock-names: Tuple listing input clock names.
--
1.9.1
^ permalink raw reply related
* [PATCH v3 2/2] macb: Add support for SiFive FU540-C000
From: Yash Shah @ 2019-06-18 7:56 UTC (permalink / raw)
To: davem, devicetree, netdev, linux-kernel, linux-riscv
Cc: robh+dt, mark.rutland, nicolas.ferre, palmer, aou, paul.walmsley,
ynezz, sachin.ghadi, Yash Shah
In-Reply-To: <1560844568-4746-1-git-send-email-yash.shah@sifive.com>
The management IP block is tightly coupled with the Cadence MACB IP
block on the FU540, and manages many of the boundary signals from the
MACB IP. This patch only controls the tx_clk input signal to the MACB
IP. Future patches may add support for monitoring or controlling other
IP boundary signals.
Signed-off-by: Yash Shah <yash.shah@sifive.com>
---
drivers/net/ethernet/cadence/macb_main.c | 123 +++++++++++++++++++++++++++++++
1 file changed, 123 insertions(+)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index c049410..15d0737 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -10,6 +10,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/clk.h>
+#include <linux/clk-provider.h>
#include <linux/crc32.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
@@ -40,6 +41,15 @@
#include <linux/pm_runtime.h>
#include "macb.h"
+/* This structure is only used for MACB on SiFive FU540 devices */
+struct sifive_fu540_macb_mgmt {
+ void __iomem *reg;
+ unsigned long rate;
+ struct clk_hw hw;
+};
+
+static struct sifive_fu540_macb_mgmt *mgmt;
+
#define MACB_RX_BUFFER_SIZE 128
#define RX_BUFFER_MULTIPLE 64 /* bytes */
@@ -3903,6 +3913,116 @@ static int at91ether_init(struct platform_device *pdev)
return 0;
}
+static unsigned long fu540_macb_tx_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ return mgmt->rate;
+}
+
+static long fu540_macb_tx_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate)
+{
+ if (WARN_ON(rate < 2500000))
+ return 2500000;
+ else if (rate == 2500000)
+ return 2500000;
+ else if (WARN_ON(rate < 13750000))
+ return 2500000;
+ else if (WARN_ON(rate < 25000000))
+ return 25000000;
+ else if (rate == 25000000)
+ return 25000000;
+ else if (WARN_ON(rate < 75000000))
+ return 25000000;
+ else if (WARN_ON(rate < 125000000))
+ return 125000000;
+ else if (rate == 125000000)
+ return 125000000;
+
+ WARN_ON(rate > 125000000);
+
+ return 125000000;
+}
+
+static int fu540_macb_tx_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ rate = fu540_macb_tx_round_rate(hw, rate, &parent_rate);
+ if (rate != 125000000)
+ iowrite32(1, mgmt->reg);
+ else
+ iowrite32(0, mgmt->reg);
+ mgmt->rate = rate;
+
+ return 0;
+}
+
+static const struct clk_ops fu540_c000_ops = {
+ .recalc_rate = fu540_macb_tx_recalc_rate,
+ .round_rate = fu540_macb_tx_round_rate,
+ .set_rate = fu540_macb_tx_set_rate,
+};
+
+static int fu540_c000_clk_init(struct platform_device *pdev, struct clk **pclk,
+ struct clk **hclk, struct clk **tx_clk,
+ struct clk **rx_clk, struct clk **tsu_clk)
+{
+ struct clk_init_data init;
+ int err = 0;
+
+ err = macb_clk_init(pdev, pclk, hclk, tx_clk, rx_clk, tsu_clk);
+ if (err)
+ return err;
+
+ mgmt = devm_kzalloc(&pdev->dev, sizeof(*mgmt), GFP_KERNEL);
+ if (!mgmt)
+ return -ENOMEM;
+
+ init.name = "sifive-gemgxl-mgmt";
+ init.ops = &fu540_c000_ops;
+ init.flags = 0;
+ init.num_parents = 0;
+
+ mgmt->rate = 0;
+ mgmt->hw.init = &init;
+
+ *tx_clk = clk_register(NULL, &mgmt->hw);
+ if (IS_ERR(*tx_clk))
+ return PTR_ERR(*tx_clk);
+
+ err = clk_prepare_enable(*tx_clk);
+ if (err)
+ dev_err(&pdev->dev, "failed to enable tx_clk (%u)\n", err);
+ else
+ dev_info(&pdev->dev, "Registered clk switch '%s'\n", init.name);
+
+ return 0;
+}
+
+static int fu540_c000_init(struct platform_device *pdev)
+{
+ struct resource *res;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!res)
+ return -ENODEV;
+
+ mgmt->reg = ioremap(res->start, resource_size(res));
+ if (!mgmt->reg)
+ return -ENOMEM;
+
+ return macb_init(pdev);
+}
+
+static const struct macb_config fu540_c000_config = {
+ .caps = MACB_CAPS_GIGABIT_MODE_AVAILABLE | MACB_CAPS_JUMBO |
+ MACB_CAPS_GEM_HAS_PTP,
+ .dma_burst_length = 16,
+ .clk_init = fu540_c000_clk_init,
+ .init = fu540_c000_init,
+ .jumbo_max_len = 10240,
+};
+
static const struct macb_config at91sam9260_config = {
.caps = MACB_CAPS_USRIO_HAS_CLKEN | MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII,
.clk_init = macb_clk_init,
@@ -3992,6 +4112,7 @@ static int at91ether_init(struct platform_device *pdev)
{ .compatible = "cdns,emac", .data = &emac_config },
{ .compatible = "cdns,zynqmp-gem", .data = &zynqmp_config},
{ .compatible = "cdns,zynq-gem", .data = &zynq_config },
+ { .compatible = "sifive,fu540-macb", .data = &fu540_c000_config },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, macb_dt_ids);
@@ -4199,6 +4320,7 @@ static int macb_probe(struct platform_device *pdev)
err_disable_clocks:
clk_disable_unprepare(tx_clk);
+ clk_unregister(tx_clk);
clk_disable_unprepare(hclk);
clk_disable_unprepare(pclk);
clk_disable_unprepare(rx_clk);
@@ -4233,6 +4355,7 @@ static int macb_remove(struct platform_device *pdev)
pm_runtime_dont_use_autosuspend(&pdev->dev);
if (!pm_runtime_suspended(&pdev->dev)) {
clk_disable_unprepare(bp->tx_clk);
+ clk_unregister(bp->tx_clk);
clk_disable_unprepare(bp->hclk);
clk_disable_unprepare(bp->pclk);
clk_disable_unprepare(bp->rx_clk);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] ipsec: select CRYPTO_HASH for xfrm_algo
From: Herbert Xu @ 2019-06-18 8:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Steffen Klassert, David S. Miller, Florian Westphal, netdev,
linux-kernel
In-Reply-To: <20190618071514.2222319-1-arnd@arndb.de>
On Tue, Jun 18, 2019 at 09:14:51AM +0200, Arnd Bergmann wrote:
> kernelci.org reports failed builds on arc because of what looks
> like an old missed 'select' statement:
>
> net/xfrm/xfrm_algo.o: In function `xfrm_probe_algs':
> xfrm_algo.c:(.text+0x1e8): undefined reference to `crypto_has_ahash'
>
> I don't see this in randconfig builds on other architectures, but
> it's fairly clear we want to select the hash code for it, like we
> do for all its other users.
>
> Fixes: 17bc19702221 ("ipsec: Use skcipher and ahash when probing algorithms")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> net/xfrm/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/xfrm/Kconfig b/net/xfrm/Kconfig
> index c967fc3c38c8..a5c967efe5f4 100644
> --- a/net/xfrm/Kconfig
> +++ b/net/xfrm/Kconfig
> @@ -15,6 +15,7 @@ config XFRM_ALGO
> tristate
> select XFRM
> select CRYPTO
> + select CRYPTO_HASH
You should also select CRYPTO_BLKCIPHER.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] netfilter: nft_paylaod: add base type NFT_PAYLOAD_LL_HEADER_NO_TAG
From: wenxu @ 2019-06-18 8:26 UTC (permalink / raw)
To: Florian Westphal, Pablo Neira Ayuso; +Cc: netfilter-devel, netdev
In-Reply-To: <20190617224232.55hldt4bw2qcmnll@breakpoint.cc>
On 6/18/2019 6:42 AM, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
>>> Subject: Change bridge l3 dependency to meta protocol
>>>
>>> This examines skb->protocol instead of ethernet header type, which
>>> might be different when vlan is involved.
>>>
>>> + if (ctx->pctx.family == NFPROTO_BRIDGE && desc == &proto_eth) {
>>> + if (expr->payload.desc == &proto_ip ||
>>> + expr->payload.desc == &proto_ip6)
>>> + desc = &proto_metaeth;
>>> + }i
>> Is this sufficient to restrict the matching? Is this still buggy from
>> ingress?
> This is what netdev family uses as well (skb->protocol i mean).
> I'm not sure it will work for output however (haven't checked).
>
>> I wonder if an explicit NFT_PAYLOAD_CHECK_VLAN flag would be useful in
>> the kernel, if so we could rename NFTA_PAYLOAD_CSUM_FLAGS to
>> NFTA_PAYLOAD_FLAGS and place it there. Just an idea.
>
> Another unresolved issue is presence of multiple vlan tags, so we might
> have to add yet another meta key to retrieve the l3 protocol in use
Maybe add a l3proto meta key can handle the multiple vlan tags case with the l3proto dependency. It
should travese all the vlan tags and find the real l3 proto.
>
>
>
^ permalink raw reply
* Re: [PATCH net-next v1 09/11] xdp: force mem allocator removal and periodic warning
From: Jesper Dangaard Brouer @ 2019-06-18 8:37 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: netdev, Ilias Apalodimas, Toke Høiland-Jørgensen,
Tariq Toukan, toshiaki.makita1, grygorii.strashko, mcroce, brouer
In-Reply-To: <20190615085915.GA3771@khorivan>
On Sat, 15 Jun 2019 11:59:16 +0300
Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote:
> >@@ -388,10 +411,12 @@ static void __xdp_return(void *data, struct xdp_mem_info *mem, bool napi_direct,
> > /* mem->id is valid, checked in xdp_rxq_info_reg_mem_model() */
> > xa = rhashtable_lookup(mem_id_ht, &mem->id, mem_id_rht_params);
> > page = virt_to_head_page(data);
> >- if (xa) {
> >+ if (likely(xa)) {
> > napi_direct &= !xdp_return_frame_no_direct();
> > page_pool_put_page(xa->page_pool, page, napi_direct);
>
> Interesting if it's synced with device "unregistration".
> I mean page dma unmap is bind to device that doesn't exist anymore but pages
> from pool of the device are in flight, so pool is not destroyed but what about
> device?. smth like device unreq todo list. Just to be sure, is it synched?
I looked through the code, and you are right. We are actually missing
to hold a reference count on struct device (for which we use dev->dma_ops).
It looks like we can simply do a get_device() and put_device(). Thus,
fairly simple to fix.
I'll add this fix as a separate patch, as it is a separate issue/bug
that also needs correction... Thanks for catching this!
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* RE: [PATCH 2/6] net: macb: add support for sgmii MAC-PHY interface
From: Parshuram Raju Thombare @ 2019-06-18 8:37 UTC (permalink / raw)
To: Andrew Lunn
Cc: nicolas.ferre@microchip.com, davem@davemloft.net,
f.fainelli@gmail.com, netdev@vger.kernel.org,
hkallweit1@gmail.com, linux-kernel@vger.kernel.org,
Rafal Ciepiela, Anil Joy Varughese, Piotr Sroka
In-Reply-To: <20190617150145.GF25211@lunn.ch>
>> @@ -159,6 +160,9 @@
>> #define GEM_PEFTN 0x01f4 /* PTP Peer Event Frame Tx Ns */
>> #define GEM_PEFRSL 0x01f8 /* PTP Peer Event Frame Rx Sec Low */
>> #define GEM_PEFRN 0x01fc /* PTP Peer Event Frame Rx Ns */
>> +#define GEM_PCS_CTRL 0x0200 /* PCS Control */
>> +#define GEM_PCS_STATUS 0x0204 /* PCS Status */
>> +#define GEM_PCS_AN_LP_BASE 0x0214 /* PCS AN LP BASE*/
>
>It looks like there are some space vs tab issues here and else where.
Ok, I will fix space vs tab issue.
>
>> static int gem_phylink_mac_link_state(struct phylink_config *pl_config,
>> struct phylink_link_state *state) {
>> + u32 status;
>> struct net_device *netdev = to_net_dev(pl_config->dev);
>> struct macb *bp = netdev_priv(netdev);
>
>Reverse christmas tree please, here and everywhere you add new variables.
>
Yes, sure. I will make take change.
>>
>> - state->speed = bp->speed;
>> - state->duplex = bp->duplex;
>> - state->link = bp->link;
>> + if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII) {
>> + status = gem_readl(bp, PCS_STATUS);
>> + state->an_complete = GEM_BFEXT(PCS_STATUS_AN_DONE,
>status);
>> + status = gem_readl(bp, PCS_AN_LP_BASE);
>> + switch (GEM_BFEXT(PCS_AN_LP_BASE_SPEED, status)) {
>> + case 0:
>> + state->speed = 10;
>> + break;
>> + case 1:
>> + state->speed = 100;
>> + break;
>> + case 2:
>> + state->speed = 1000;
>> + break;
>> + default:
>> + break;
>
>It would be nice to use SPEED_10, SPEED_100, etc.
>
Yes, sure. I will make take change.
>> @@ -494,17 +551,23 @@ static void gem_mac_config(struct phylink_config
>*pl_config, unsigned int mode,
>> reg &= ~(MACB_BIT(SPD) | MACB_BIT(FD));
>> if (macb_is_gem(bp))
>> reg &= ~GEM_BIT(GBE);
>> -
>> if (state->duplex)
>> reg |= MACB_BIT(FD);
>> - if (state->speed == SPEED_100)
>> - reg |= MACB_BIT(SPD);
>> - if (state->speed == SPEED_1000 &&
>> - bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE)
>> - reg |= GEM_BIT(GBE);
>> -
>> macb_or_gem_writel(bp, NCFGR, reg);
>>
>> + if (state->speed == SPEED_2500) {
>> + gem_writel(bp, NCFGR, GEM_BIT(GBE) |
>> + gem_readl(bp, NCFGR));
>> + gem_writel(bp, NCR, GEM_BIT(TWO_PT_FIVE_GIG) |
>> + gem_readl(bp, NCR));
>> + } else if (state->speed == SPEED_1000) {
>> + gem_writel(bp, NCFGR, GEM_BIT(GBE) |
>> + gem_readl(bp, NCFGR));
>> + } else if (state->speed == SPEED_100) {
>> + macb_writel(bp, NCFGR, MACB_BIT(SPD) |
>> + macb_readl(bp, NCFGR));
>> + }
>
>Maybe a switch statement?
>
This suggested to be part of helper function in other patch.
I will add switch in helper inline function replacement of this code.
>> @@ -4232,11 +4327,37 @@ static int macb_probe(struct platform_device
>*pdev)
>> }
>>
>> err = of_get_phy_mode(np);
>
>The following code would be more readable if you replaced err with phy_mode,
>or interface.
>
Ok, sure.
>> - if (err < 0)
>> + if (err < 0) {
>> /* not found in DT, MII by default */
>> bp->phy_interface = PHY_INTERFACE_MODE_MII;
>> - else
>> + } else if (bp->caps & MACB_CAPS_MACB_IS_GEM_GXL) {
>> + u32 interface_supported = 1;
>> +
>> + if (err == PHY_INTERFACE_MODE_SGMII ||
>> + err == PHY_INTERFACE_MODE_1000BASEX ||
>> + err == PHY_INTERFACE_MODE_2500BASEX) {
>> + if (!(bp->caps & MACB_CAPS_PCS))
>> + interface_supported = 0;
>> + } else if (err == PHY_INTERFACE_MODE_GMII ||
>> + err == PHY_INTERFACE_MODE_RGMII) {
>> + if (!macb_is_gem(bp))
>> + interface_supported = 0;
>> + } else if (err != PHY_INTERFACE_MODE_RMII &&
>> + err != PHY_INTERFACE_MODE_MII) {
>> + /* Add new mode before this */
>> + interface_supported = 0;
>> + }
>> +
>> + if (!interface_supported) {
>> + netdev_err(dev, "Phy mode %s not supported",
>> + phy_modes(err));
>> + goto err_out_free_netdev;
>> + }
>> +
>> bp->phy_interface = err;
>> + } else {
>> + bp->phy_interface = err;
>> + }
>
> Andrew
Regards,
Parshuram Thombare
^ permalink raw reply
* Re: [RFC PATCH net-next 1/1] tc-testing: Restore original behaviour for namespaces in tdc
From: Nicolas Dichtel @ 2019-06-18 8:52 UTC (permalink / raw)
To: Lucas Bates
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
kernel, Cong Wang, Jiri Pirko, Marcelo Ricardo Leitner,
Vlad Buslov, Davide Caratti
In-Reply-To: <CAMDBHYJdeh_AO-FEunTuTNVFAEtixuniq1b6vRqa_oS_Ru5wjg@mail.gmail.com>
Le 17/06/2019 à 04:04, Lucas Bates a écrit :
> On Fri, Jun 14, 2019 at 5:37 AM Nicolas Dichtel
> <nicolas.dichtel@6wind.com> wrote:
[snip]
> The tests that make use of DEV2 are intended to be run with a physical
> NIC. This feature was originally submitted by Chris Mi from Mellanox
> back in 2017 (commit 31c2611b) to reproduce a kernel panic, with d052
> being the first test case submitted.
Ok.
>
> Originally they were silently skipped, but once I added TdcResults.py
> this changed so they would be tracked and reported as skipped.
>
>> From my point of view, if all tests are not successful by default, it scares
>> users and prevent them to use those tests suite to validate their patches.
>
> For me, explicitly telling the user that a test was skipped, and /why/
> it was skipped, is far better than excluding the test from the
> results: I don't want to waste someone's time with troubleshooting the
> script if they're expecting to see results for those tests when
> running tdc and nothing appears, or worse yet, stop using it because
> they think it doesn't work properly.
>
> I do believe the skip message should be improved so it better
> indicates why those tests are being skipped. And the '-d' feature
> should be documented. How do these changes sound?
If the error message is clear enough, I agree with you. The skip message should
not feel like an error message ;-)
Thank you,
Nicolas
^ permalink raw reply
* RE: [PATCH] qed: Fix -Wmaybe-uninitialized false positive
From: Michal Kalderon @ 2019-06-18 9:27 UTC (permalink / raw)
To: Arnd Bergmann, Ariel Elior, GR-everest-linux-l2, David S. Miller
Cc: Ariel Elior, Dan Carpenter, Denis Bolotin, Tomer Tayar,
Sudarsana Reddy Kalluru, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190617130504.1906523-1-arnd@arndb.de>
> From: Arnd Bergmann <arnd@arndb.de>
> Sent: Monday, June 17, 2019 4:05 PM
>
> A previous attempt to shut up the uninitialized variable use warning was
> apparently insufficient. When CONFIG_PROFILE_ANNOTATED_BRANCHES is
> set, gcc-8 still warns, because the unlikely() check in DP_NOTICE() causes it to
> no longer track the state of all variables correctly:
>
> drivers/net/ethernet/qlogic/qed/qed_dev.c: In function
> 'qed_llh_set_ppfid_affinity':
> drivers/net/ethernet/qlogic/qed/qed_dev.c:798:47: error: 'abs_ppfid' may
> be used uninitialized in this function [-Werror=maybe-uninitialized]
> addr = NIG_REG_PPF_TO_ENGINE_SEL + abs_ppfid * 0x4;
> ~~~~~~~~~~^~~~~
>
> This is not a nice workaround, but always initializing the output from
> qed_llh_abs_ppfid() at least shuts up the false positive reliably.
>
> Fixes: 79284adeb99e ("qed: Add llh ppfid interface and 100g support for
> offload protocols")
> Fixes: 8e2ea3ea9625 ("qed: Fix static checker warning")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/net/ethernet/qlogic/qed/qed_dev.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c
> b/drivers/net/ethernet/qlogic/qed/qed_dev.c
> index eec7cb65c7e6..a1ebc2b1ca0b 100644
> --- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
> +++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
> @@ -652,6 +652,7 @@ static int qed_llh_abs_ppfid(struct qed_dev *cdev, u8
> ppfid, u8 *p_abs_ppfid)
> DP_NOTICE(cdev,
> "ppfid %d is not valid, available indices are
> 0..%hhd\n",
> ppfid, p_llh_info->num_ppfid - 1);
> + *p_abs_ppfid = 0;
> return -EINVAL;
> }
>
> --
> 2.20.0
Thanks,
Acked-by: Michal Kalderon <michal.kalderon@marvell.com>
^ permalink raw reply
* Re: [PATCH net-next v3 2/6] etf: Add skip_sock_check
From: Sergei Shtylyov @ 2019-06-18 9:28 UTC (permalink / raw)
To: Vedang Patel, netdev
Cc: jeffrey.t.kirsher, davem, jhs, xiyou.wangcong, jiri,
intel-wired-lan, vinicius.gomes, l
In-Reply-To: <1560799870-18956-3-git-send-email-vedang.patel@intel.com>
Hello!
On 17.06.2019 22:31, Vedang Patel wrote:
> Currently, etf expects a socket with SO_TXTIME option set for each packet
> it encounters. So, it will drop all other packets. But, in the future
> commits we are planning to add functionality which where tstamp value will
> be set by another qdisc. Also, some packets which are generated from within
> the kernel (e.g. ICMP packets) do not have any socket associated with them.
>
> So, this commit adds support for skip_sock_check. When this option is set,
> etf will skip checking for a socket and other associated options for all
> skbs.
>
> Signed-off-by: Vedang Patel <vedang.patel@intel.com>
> ---
> include/uapi/linux/pkt_sched.h | 1 +
> net/sched/sch_etf.c | 10 ++++++++++
> 2 files changed, 11 insertions(+)
>
> diff --git a/include/uapi/linux/pkt_sched.h b/include/uapi/linux/pkt_sched.h
> index 8b2f993cbb77..69fc52e4d6bd 100644
> --- a/include/uapi/linux/pkt_sched.h
> +++ b/include/uapi/linux/pkt_sched.h
> @@ -990,6 +990,7 @@ struct tc_etf_qopt {
> __u32 flags;
> #define TC_ETF_DEADLINE_MODE_ON BIT(0)
> #define TC_ETF_OFFLOAD_ON BIT(1)
> +#define TC_ETF_SKIP_SOCK_CHECK BIT(2)
Please indent with a tab like above, not 2 spaces.
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: stmmac: Convert to phylink and remove phylib logic
From: Jon Hunter @ 2019-06-18 9:30 UTC (permalink / raw)
To: Jose Abreu, linux-kernel, netdev
Cc: Joao Pinto, David S . Miller, Giuseppe Cavallaro,
Alexandre Torgue, Russell King, Andrew Lunn, Florian Fainelli,
Heiner Kallweit, linux-tegra
In-Reply-To: <6226d6a0de5929ed07d64b20472c52a86e71383d.1560266175.git.joabreu@synopsys.com>
On 11/06/2019 16:18, Jose Abreu wrote:
> Convert everything to phylink.
>
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
> Cc: Joao Pinto <jpinto@synopsys.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Heiner Kallweit <hkallweit1@gmail.com>
I am seeing a boot regression on -next for some of our boards that have
a synopsys ethernet controller that uses the dwmac-dwc-qos-ethernet
driver. Git bisect is pointing to this commit, but unfortunately this
cannot be cleanly reverted on top of -next to confirm.
The bootlog shows the following bug is triggered ...
[ 10.784989] ------------[ cut here ]------------
[ 10.789597] kernel BUG at /home/jonathanh/workdir/tegra/mlt-linux_next/kernel/kernel/time/timer.c:952!
[ 10.798881] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 10.804351] Modules linked in:
[ 10.807400] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G S 5.2.0-rc3-00940-g425b0fad9c7e #9
[ 10.816682] Hardware name: NVIDIA Tegra186 P2771-0000 Development Board (DT)
[ 10.823712] pstate: 20000005 (nzCv daif -PAN -UAO)
[ 10.828496] pc : mod_timer+0x208/0x2d8
[ 10.832235] lr : stmmac_napi_poll_tx+0x524/0x5a0
[ 10.836839] sp : ffff000010003d00
[ 10.840141] x29: ffff000010003d00 x28: ffff8001f42887c0
[ 10.845438] x27: ffff8001f42887c0 x26: ffff8001f55b7100
[ 10.850735] x25: 0000000000000000 x24: 0000000000000000
[ 10.856033] x23: ffff0000112e9000 x22: 0000000000000000
[ 10.861330] x21: 0000000000000001 x20: ffff0000121ad000
[ 10.866626] x19: ffff8001f47da000 x18: 0000000000000000
[ 10.871922] x17: 0000000000000000 x16: 0000000000000001
[ 10.877218] x15: 0000000000000009 x14: 0000000000001000
[ 10.882515] x13: 0000000080000000 x12: 0000000000000001
[ 10.887811] x11: 000000000000000c x10: 0000000000000000
[ 10.893107] x9 : 0000000000000000 x8 : 00000000fffee49c
[ 10.898403] x7 : 000000000000002a x6 : 000000000000002a
[ 10.903699] x5 : ffff8001f4189c80 x4 : 0000000000290000
[ 10.908995] x3 : 0000000000000000 x2 : 0000000000000000
[ 10.914291] x1 : 00000000fffee596 x0 : ffff8001f428b160
[ 10.919587] Call trace:
[ 10.922024] mod_timer+0x208/0x2d8
[ 10.925415] stmmac_napi_poll_tx+0x524/0x5a0
[ 10.929674] net_rx_action+0x220/0x318
[ 10.933413] __do_softirq+0x110/0x23c
[ 10.937066] irq_exit+0xcc/0xd8
[ 10.940199] __handle_domain_irq+0x60/0xb8
[ 10.944282] gic_handle_irq+0x58/0xb0
[ 10.947931] el1_irq+0xb8/0x180
[ 10.951063] arch_cpu_idle+0x10/0x18
[ 10.954627] do_idle+0x1dc/0x2a8
[ 10.957845] cpu_startup_entry+0x24/0x28
[ 10.961758] rest_init+0xd4/0xe0
[ 10.964978] arch_call_rest_init+0xc/0x14
[ 10.968976] start_kernel+0x44c/0x478
[ 10.972626] Code: aa1503f4 aa1403f5 17ffffc5 d503201f (d4210000)
[ 10.978709] ---[ end trace 89626c50aaab321f ]---
I have not looked at this any further, but wanted to see if you have some
thoughts.
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH 0/2] net: fastopen: follow-up tweaks for SipHash switch
From: Ard Biesheuvel @ 2019-06-18 9:32 UTC (permalink / raw)
To: netdev
Cc: Ard Biesheuvel, Eric Biggers, linux-crypto, herbert, edumazet,
davem, kuznet, yoshfuji, jbaron, cpaasch, David.Laight, ycheng
A pair of tweaks for issues spotted by Eric Biggers. Patch #1 is
mostly cosmetic, since the error check it adds is unreachable in
practice, and the other changes are syntactic cleanups. Patch #2
adds endian swabbing of the SipHash output for big endian systems
so that the in-memory representation is the same as on little
endian systems.
cc: Eric Biggers <ebiggers@kernel.org>
cc: linux-crypto@vger.kernel.org
cc: herbert@gondor.apana.org.au
cc: edumazet@google.com
cc: davem@davemloft.net
cc: kuznet@ms2.inr.ac.ru
cc: yoshfuji@linux-ipv6.org
cc: jbaron@akamai.com
cc: cpaasch@apple.com
cc: David.Laight@aculab.com
cc: ycheng@google.com
Ard Biesheuvel (2):
net: fastopen: make key handling more robust against future changes
net: fastopen: use endianness agnostic representation of the cookie
include/linux/tcp.h | 2 +-
include/net/tcp.h | 5 +--
net/ipv4/tcp_fastopen.c | 34 +++++++++++---------
3 files changed, 23 insertions(+), 18 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH 1/2] net: fastopen: make key handling more robust against future changes
From: Ard Biesheuvel @ 2019-06-18 9:32 UTC (permalink / raw)
To: netdev
Cc: Ard Biesheuvel, Eric Biggers, linux-crypto, herbert, edumazet,
davem, kuznet, yoshfuji, jbaron, cpaasch, David.Laight, ycheng
In-Reply-To: <20190618093207.13436-1-ard.biesheuvel@linaro.org>
Some changes to the TCP fastopen code to make it more robust
against future changes in the choice of key/cookie size, etc.
- Instead of keeping the SipHash key in an untyped u8[] buffer
and casting it to the right type upon use, use the correct
siphash_key_t type directly. This ensures that the key will
appear at the correct alignment if we ever change the way
these data structures are allocated. (Currently, they are
only allocated via kmalloc so they always appear at the
correct alignment)
- Use DIV_ROUND_UP when sizing the u64[] array to hold the
cookie, so it is always of sufficient size, even when
TCP_FASTOPEN_COOKIE_MAX is no longer a multiple of 8.
- Add a key length check to tcp_fastopen_reset_cipher(). No
callers exist currently that fail this check (they all pass
compile constant values that equal TCP_FASTOPEN_KEY_LENGTH),
but future changes might create problems, e.g., by leaving part
of the key uninitialized, or overflowing the key buffers.
Note that none of these are functional changes wrt the current
state of the code.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
include/linux/tcp.h | 2 +-
include/net/tcp.h | 5 +++--
net/ipv4/tcp_fastopen.c | 22 ++++++++++++--------
3 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index 2689b0b0b68a..3d3659c638a6 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -58,7 +58,7 @@ static inline unsigned int tcp_optlen(const struct sk_buff *skb)
/* TCP Fast Open Cookie as stored in memory */
struct tcp_fastopen_cookie {
- u64 val[TCP_FASTOPEN_COOKIE_MAX / sizeof(u64)];
+ u64 val[DIV_ROUND_UP(TCP_FASTOPEN_COOKIE_MAX, sizeof(u64))];
s8 len;
bool exp; /* In RFC6994 experimental option format */
};
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 573c9e9b0d72..9456b0834e21 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -43,6 +43,7 @@
#include <linux/seq_file.h>
#include <linux/memcontrol.h>
#include <linux/bpf-cgroup.h>
+#include <linux/siphash.h>
extern struct inet_hashinfo tcp_hashinfo;
@@ -1623,14 +1624,14 @@ void tcp_fastopen_init_key_once(struct net *net);
bool tcp_fastopen_cookie_check(struct sock *sk, u16 *mss,
struct tcp_fastopen_cookie *cookie);
bool tcp_fastopen_defer_connect(struct sock *sk, int *err);
-#define TCP_FASTOPEN_KEY_LENGTH 16
+#define TCP_FASTOPEN_KEY_LENGTH sizeof(siphash_key_t)
#define TCP_FASTOPEN_KEY_MAX 2
#define TCP_FASTOPEN_KEY_BUF_LENGTH \
(TCP_FASTOPEN_KEY_LENGTH * TCP_FASTOPEN_KEY_MAX)
/* Fastopen key context */
struct tcp_fastopen_context {
- __u8 key[TCP_FASTOPEN_KEY_MAX][TCP_FASTOPEN_KEY_LENGTH];
+ siphash_key_t key[TCP_FASTOPEN_KEY_MAX];
int num;
struct rcu_head rcu;
};
diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
index 46b67128e1ca..61c15c3d3584 100644
--- a/net/ipv4/tcp_fastopen.c
+++ b/net/ipv4/tcp_fastopen.c
@@ -7,7 +7,6 @@
#include <linux/tcp.h>
#include <linux/rcupdate.h>
#include <linux/rculist.h>
-#include <linux/siphash.h>
#include <net/inetpeer.h>
#include <net/tcp.h>
@@ -81,9 +80,15 @@ int tcp_fastopen_reset_cipher(struct net *net, struct sock *sk,
goto out;
}
- memcpy(ctx->key[0], primary_key, len);
+ if (unlikely(len != TCP_FASTOPEN_KEY_LENGTH)) {
+ pr_err("TCP: TFO key length %u invalid\n", len);
+ err = -EINVAL;
+ goto out;
+ }
+
+ memcpy(&ctx->key[0], primary_key, len);
if (backup_key) {
- memcpy(ctx->key[1], backup_key, len);
+ memcpy(&ctx->key[1], backup_key, len);
ctx->num = 2;
} else {
ctx->num = 1;
@@ -110,10 +115,9 @@ int tcp_fastopen_reset_cipher(struct net *net, struct sock *sk,
static bool __tcp_fastopen_cookie_gen_cipher(struct request_sock *req,
struct sk_buff *syn,
- const u8 *key,
+ const siphash_key_t *key,
struct tcp_fastopen_cookie *foc)
{
- BUILD_BUG_ON(TCP_FASTOPEN_KEY_LENGTH != sizeof(siphash_key_t));
BUILD_BUG_ON(TCP_FASTOPEN_COOKIE_SIZE != sizeof(u64));
if (req->rsk_ops->family == AF_INET) {
@@ -122,7 +126,7 @@ static bool __tcp_fastopen_cookie_gen_cipher(struct request_sock *req,
foc->val[0] = siphash(&iph->saddr,
sizeof(iph->saddr) +
sizeof(iph->daddr),
- (const siphash_key_t *)key);
+ key);
foc->len = TCP_FASTOPEN_COOKIE_SIZE;
return true;
}
@@ -133,7 +137,7 @@ static bool __tcp_fastopen_cookie_gen_cipher(struct request_sock *req,
foc->val[0] = siphash(&ip6h->saddr,
sizeof(ip6h->saddr) +
sizeof(ip6h->daddr),
- (const siphash_key_t *)key);
+ key);
foc->len = TCP_FASTOPEN_COOKIE_SIZE;
return true;
}
@@ -154,7 +158,7 @@ static void tcp_fastopen_cookie_gen(struct sock *sk,
rcu_read_lock();
ctx = tcp_fastopen_get_ctx(sk);
if (ctx)
- __tcp_fastopen_cookie_gen_cipher(req, syn, ctx->key[0], foc);
+ __tcp_fastopen_cookie_gen_cipher(req, syn, &ctx->key[0], foc);
rcu_read_unlock();
}
@@ -218,7 +222,7 @@ static int tcp_fastopen_cookie_gen_check(struct sock *sk,
if (!ctx)
goto out;
for (i = 0; i < tcp_fastopen_context_len(ctx); i++) {
- __tcp_fastopen_cookie_gen_cipher(req, syn, ctx->key[i], foc);
+ __tcp_fastopen_cookie_gen_cipher(req, syn, &ctx->key[i], foc);
if (tcp_fastopen_cookie_match(foc, orig)) {
ret = i + 1;
goto out;
--
2.17.1
^ permalink raw reply related
* [PATCH 2/2] net: fastopen: use endianness agnostic representation of the cookie
From: Ard Biesheuvel @ 2019-06-18 9:32 UTC (permalink / raw)
To: netdev
Cc: Ard Biesheuvel, Eric Biggers, linux-crypto, herbert, edumazet,
davem, kuznet, yoshfuji, jbaron, cpaasch, David.Laight, ycheng
In-Reply-To: <20190618093207.13436-1-ard.biesheuvel@linaro.org>
Use an explicit little endian representation of the fastopen
cookie, so that the value no longer depends on the endianness
of the system. This fixes a theoretical issue only, since
fastopen keys are unlikely to be shared across load balancing
server farms that are mixed in endiannes, but it might pop up
in validation/selftests as well, so let's just settle on little
endian across the board.
Note that this change only affects big endian systems.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
include/linux/tcp.h | 2 +-
net/ipv4/tcp_fastopen.c | 16 ++++++++--------
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index 3d3659c638a6..f3a85a7fb4b1 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -58,7 +58,7 @@ static inline unsigned int tcp_optlen(const struct sk_buff *skb)
/* TCP Fast Open Cookie as stored in memory */
struct tcp_fastopen_cookie {
- u64 val[DIV_ROUND_UP(TCP_FASTOPEN_COOKIE_MAX, sizeof(u64))];
+ __le64 val[DIV_ROUND_UP(TCP_FASTOPEN_COOKIE_MAX, sizeof(u64))];
s8 len;
bool exp; /* In RFC6994 experimental option format */
};
diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
index 61c15c3d3584..2704441a0bb0 100644
--- a/net/ipv4/tcp_fastopen.c
+++ b/net/ipv4/tcp_fastopen.c
@@ -123,10 +123,10 @@ static bool __tcp_fastopen_cookie_gen_cipher(struct request_sock *req,
if (req->rsk_ops->family == AF_INET) {
const struct iphdr *iph = ip_hdr(syn);
- foc->val[0] = siphash(&iph->saddr,
- sizeof(iph->saddr) +
- sizeof(iph->daddr),
- key);
+ foc->val[0] = cpu_to_le64(siphash(&iph->saddr,
+ sizeof(iph->saddr) +
+ sizeof(iph->daddr),
+ key));
foc->len = TCP_FASTOPEN_COOKIE_SIZE;
return true;
}
@@ -134,10 +134,10 @@ static bool __tcp_fastopen_cookie_gen_cipher(struct request_sock *req,
if (req->rsk_ops->family == AF_INET6) {
const struct ipv6hdr *ip6h = ipv6_hdr(syn);
- foc->val[0] = siphash(&ip6h->saddr,
- sizeof(ip6h->saddr) +
- sizeof(ip6h->daddr),
- key);
+ foc->val[0] = cpu_to_le64(siphash(&ip6h->saddr,
+ sizeof(ip6h->saddr) +
+ sizeof(ip6h->daddr),
+ key));
foc->len = TCP_FASTOPEN_COOKIE_SIZE;
return true;
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2 0/2] Add macb support for SiFive FU540-C000
From: Anup Patel @ 2019-06-18 9:32 UTC (permalink / raw)
To: Paul Walmsley, palmer@sifive.com
Cc: Alistair Francis, troy.benjegerdes@sifive.com, jamez@wit.com,
linux-riscv@lists.infradead.org, davem@davemloft.net,
schwab@suse.de, nicolas.ferre@microchip.com, mark.rutland@arm.com,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
aou@eecs.berkeley.edu, sachin.ghadi@sifive.com,
netdev@vger.kernel.org, ynezz@true.cz, yash.shah@sifive.com,
robh+dt@kernel.org, Atish Patra, Bin Meng, Lukas Auer
In-Reply-To: <alpine.DEB.2.21.9999.1906172019040.15057@viisi.sifive.com>
On Tue, Jun 18, 2019 at 8:56 AM Paul Walmsley <paul.walmsley@sifive.com> wrote:
>
> On Mon, 17 Jun 2019, Alistair Francis wrote:
>
> > > The legacy M-mode U-boot handles the phy reset already, and I’ve been
> > > able to load upstream S-mode uboot as a payload via TFTP, and then
> > > load and boot a 4.19 kernel.
> > >
> > > It would be nice to get this all working with 5.x, however there are
> > > still
> > > several missing pieces to really have it work well.
> >
> > Let me know what is still missing/doesn't work and I can add it. At the
> > moment the only known issue I know of is a missing SD card driver in U-
> > Boot.
>
> The DT data has changed between the non-upstream data that people
> developed against previously, vs. the DT data that just went upstream
> here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=72296bde4f4207566872ee355950a59cbc29f852
>
> and
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c35f1b87fc595807ff15d2834d241f9771497205
>
> So Upstream U-Boot is going to need several patches to get things working
> again. Clock identifiers and Ethernet are two known areas.
Done.
I just send-out few patches to fix U-Boot SiFive Clock driver.
The U-Boot SiFive Clock driver fix series can be found in
riscv_unleashed_clk_sync_v1 branch of:
https://github.com/avpatel/u-boot.git
Users will also require OpenSBI DTB fix which can be found
in sifive_unleashed_dtb_fix_v1 branch of:
https://github.com/avpatel/opensbi.git
With above fixes, we can now use same DTB for both U-Boot
and Linux kernel (5.2-rc1). Although, users are free to pass a
different DTB to Linux kernel via TFTP.
I have tested SiFive serial and Cadance MACB ethernet on
both U-Boot and Linux (5.2-rc1)
Regards,
Anup
^ permalink raw reply
* Re: [PATCH] rt2x00: fix rx queue hang
From: Stanislaw Gruszka @ 2019-06-18 9:34 UTC (permalink / raw)
To: Soeren Moch
Cc: Helmut Schaa, Kalle Valo, David S. Miller, linux-wireless, netdev,
linux-kernel, stable
In-Reply-To: <20190617094656.3952-1-smoch@web.de>
Hi
On Mon, Jun 17, 2019 at 11:46:56AM +0200, Soeren Moch wrote:
> Since commit ed194d136769 ("usb: core: remove local_irq_save() around
> ->complete() handler") the handlers rt2x00usb_interrupt_rxdone() and
> rt2x00usb_interrupt_txdone() are not running with interrupts disabled
> anymore. So these handlers are not guaranteed to run completely before
> workqueue processing starts. So only mark entries ready for workqueue
> processing after proper accounting in the dma done queue.
It was always the case on SMP machines that rt2x00usb_interrupt_{tx/rx}done
can run concurrently with rt2x00_work_{rx,tx}done, so I do not
understand how removing local_irq_save() around complete handler broke
things.
Have you reverted commit ed194d136769 and the revert does solve the problem ?
Between 4.19 and 4.20 we have some quite big changes in rt2x00 driver:
0240564430c0 rt2800: flush and txstatus rework for rt2800mmio
adf26a356f13 rt2x00: use different txstatus timeouts when flushing
5022efb50f62 rt2x00: do not check for txstatus timeout every time on tasklet
0b0d556e0ebb rt2800mmio: use txdone/txstatus routines from lib
5c656c71b1bf rt2800: move usb specific txdone/txstatus routines to rt2800lib
so I'm a bit afraid that one of those changes is real cause of
the issue not ed194d136769 .
> Note that rt2x00usb_work_rxdone() processes all available entries, not
> only such for which queue_work() was called.
>
> This fixes a regression on a RT5370 based wifi stick in AP mode, which
> suddenly stopped data transmission after some period of heavy load. Also
> stopping the hanging hostapd resulted in the error message "ieee80211
> phy0: rt2x00queue_flush_queue: Warning - Queue 14 failed to flush".
> Other operation modes are probably affected as well, this just was
> the used testcase.
Do you know what actually make the traffic stop,
TX queue hung or RX queue hung?
> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
> index 1b08b01db27b..9c102a501ee6 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
> @@ -263,9 +263,9 @@ EXPORT_SYMBOL_GPL(rt2x00lib_dmastart);
>
> void rt2x00lib_dmadone(struct queue_entry *entry)
> {
> - set_bit(ENTRY_DATA_STATUS_PENDING, &entry->flags);
> clear_bit(ENTRY_OWNER_DEVICE_DATA, &entry->flags);
> rt2x00queue_index_inc(entry, Q_INDEX_DMA_DONE);
> + set_bit(ENTRY_DATA_STATUS_PENDING, &entry->flags);
Unfortunately I do not understand how this suppose to fix the problem,
could you elaborate more about this change?
Stanislaw
^ permalink raw reply
* Re: [PATCH] netfilter: nft_paylaod: add base type NFT_PAYLOAD_LL_HEADER_NO_TAG
From: Pablo Neira Ayuso @ 2019-06-18 9:35 UTC (permalink / raw)
To: Florian Westphal; +Cc: wenxu, netfilter-devel, netdev
In-Reply-To: <20190617224232.55hldt4bw2qcmnll@breakpoint.cc>
On Tue, Jun 18, 2019 at 12:42:32AM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > > Subject: Change bridge l3 dependency to meta protocol
> > >
> > > This examines skb->protocol instead of ethernet header type, which
> > > might be different when vlan is involved.
> > >
> > > + if (ctx->pctx.family == NFPROTO_BRIDGE && desc == &proto_eth) {
> > > + if (expr->payload.desc == &proto_ip ||
> > > + expr->payload.desc == &proto_ip6)
> > > + desc = &proto_metaeth;
> > > + }i
> >
> > Is this sufficient to restrict the matching? Is this still buggy from
> > ingress?
>
> This is what netdev family uses as well (skb->protocol i mean).
> I'm not sure it will work for output however (haven't checked).
You mean for locally generated traffic?
> > I wonder if an explicit NFT_PAYLOAD_CHECK_VLAN flag would be useful in
> > the kernel, if so we could rename NFTA_PAYLOAD_CSUM_FLAGS to
> > NFTA_PAYLOAD_FLAGS and place it there. Just an idea.
>
> What would NFT_PAYLOAD_CHECK_VLAN do?
Similar to the checksum approach, it provides a hint to the kernel to
say that "I want to look at the vlan header" from the link layer.
> You mean disable/enable the 'vlan is there' illusion that nft_payload
> provides? That would work as well of course, but I would prefer to
> switch to meta dependencies where possible so we don't rely on
> particular layout of a different header class (e.g. meta l4proto doesn't
> depend on ip version, and meta protocol won't depend on particular
> ethernet frame).
If we can fix all cases from userspace, that's fine.
> What might be useful is an nft switch to turn off dependeny
> insertion, this would also avoid the problem (if users restrict the
> matching properly...).
Hm. How does this toggle would look like?
> Another unresolved issue is presence of multiple vlan tags, so we might
> have to add yet another meta key to retrieve the l3 protocol in use
>
> (the problem at hand was 'ip protocol icmp' not matching traffic inside
> a vlan).
Could you describe this problem a bit more? Small example rule plus
scenario.
> The other issue is lack of vlan awareness in some bridge/netdev
> expressions, e.g. reject.
This needs to be fixed for bridge. There is no support for netdev yet,
IIRC.
> I think we could apply this patch to nft after making sure it works
> for output as thats probably the only solution that won't need
> changes in the kernel.
That's fine with me.
> If it doesn't, we will need to find a different solution in any case.
OK.
^ permalink raw reply
* RE: [PATCH net-next 3/3] net: stmmac: Convert to phylink and remove phylib logic
From: Jose Abreu @ 2019-06-18 9:35 UTC (permalink / raw)
To: Jon Hunter, Jose Abreu, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
Cc: Joao Pinto, David S . Miller, Giuseppe Cavallaro,
Alexandre Torgue, Russell King, Andrew Lunn, Florian Fainelli,
Heiner Kallweit, linux-tegra
In-Reply-To: <d9ffce3d-4827-fa4a-89e8-0492c4bc1848@nvidia.com>
From: Jon Hunter <jonathanh@nvidia.com>
> I am seeing a boot regression on -next for some of our boards that have
> a synopsys ethernet controller that uses the dwmac-dwc-qos-ethernet
> driver. Git bisect is pointing to this commit, but unfortunately this
> cannot be cleanly reverted on top of -next to confirm.
Thanks for reporting. Looks like the timer is not setup when
stmmac_tx_clean() is called. When do you see this stacktrace ? After
ifdown ?
Thanks,
Jose Miguel Abreu
^ permalink raw reply
* Re: [PATCH 0/2] net: fastopen: follow-up tweaks for SipHash switch
From: Eric Dumazet @ 2019-06-18 9:37 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: netdev, Eric Biggers, linux-crypto, Herbert Xu, David Miller,
Alexey Kuznetsov, Hideaki YOSHIFUJI, Jason Baron,
Christoph Paasch, David Laight, Yuchung Cheng
In-Reply-To: <20190618093207.13436-1-ard.biesheuvel@linaro.org>
On Tue, Jun 18, 2019 at 2:32 AM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
>
> A pair of tweaks for issues spotted by Eric Biggers. Patch #1 is
> mostly cosmetic, since the error check it adds is unreachable in
> practice, and the other changes are syntactic cleanups. Patch #2
> adds endian swabbing of the SipHash output for big endian systems
> so that the in-memory representation is the same as on little
> endian systems.
>
Please always add net or net-next in your patches for netdev@
( Documentation/networking/netdev-FAQ.rst )
Thanks.
^ permalink raw reply
* Re: [PATCH] netfilter: nft_paylaod: add base type NFT_PAYLOAD_LL_HEADER_NO_TAG
From: Florian Westphal @ 2019-06-18 9:37 UTC (permalink / raw)
To: wenxu; +Cc: Florian Westphal, Pablo Neira Ayuso, netfilter-devel, netdev
In-Reply-To: <22ab95cb-9dca-1e48-4ca0-965d340e7d32@ucloud.cn>
wenxu <wenxu@ucloud.cn> wrote:
> On 6/18/2019 6:42 AM, Florian Westphal wrote:
> > Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> >>> Subject: Change bridge l3 dependency to meta protocol
> >>>
> >>> This examines skb->protocol instead of ethernet header type, which
> >>> might be different when vlan is involved.
> >>>
> >>> + if (ctx->pctx.family == NFPROTO_BRIDGE && desc == &proto_eth) {
> >>> + if (expr->payload.desc == &proto_ip ||
> >>> + expr->payload.desc == &proto_ip6)
> >>> + desc = &proto_metaeth;
> >>> + }i
> >> Is this sufficient to restrict the matching? Is this still buggy from
> >> ingress?
> > This is what netdev family uses as well (skb->protocol i mean).
> > I'm not sure it will work for output however (haven't checked).
> >
> >> I wonder if an explicit NFT_PAYLOAD_CHECK_VLAN flag would be useful in
> >> the kernel, if so we could rename NFTA_PAYLOAD_CSUM_FLAGS to
> >> NFTA_PAYLOAD_FLAGS and place it there. Just an idea.
> >
> > Another unresolved issue is presence of multiple vlan tags, so we might
> > have to add yet another meta key to retrieve the l3 protocol in use
>
> Maybe add a l3proto meta key can handle the multiple vlan tags case with the l3proto dependency. It
> should travese all the vlan tags and find the real l3 proto.
Yes, something like this.
We also need to audit netdev and bridge expressions (reject is known broken)
to handle vlans properly.
Still, switching nft to prefer skb->protocol instead of eth_hdr->type
for dependencies would be good as this doesn't need kernel changes and solves
the immediate problem of 'ip ...' not matching in case of vlan.
If you have time, could you check if using skb->protocol works for nft
bridge in output, i.e. does 'nft ip protocol icmp' match when its used
from bridge output path with meta protocol dependency with and without
vlan in use?
^ permalink raw reply
* Re: [PATCH 0/2] net: fastopen: follow-up tweaks for SipHash switch
From: Ard Biesheuvel @ 2019-06-18 9:38 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, Eric Biggers,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE, Herbert Xu,
David Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI, Jason Baron,
Christoph Paasch, David Laight, Yuchung Cheng
In-Reply-To: <CANn89i+Hcp5nxteWHOq-Uv9VzneCemVEkyyZJD=UG9-wsrLAwQ@mail.gmail.com>
On Tue, 18 Jun 2019 at 11:37, Eric Dumazet <edumazet@google.com> wrote:
>
> On Tue, Jun 18, 2019 at 2:32 AM Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
> >
> > A pair of tweaks for issues spotted by Eric Biggers. Patch #1 is
> > mostly cosmetic, since the error check it adds is unreachable in
> > practice, and the other changes are syntactic cleanups. Patch #2
> > adds endian swabbing of the SipHash output for big endian systems
> > so that the in-memory representation is the same as on little
> > endian systems.
> >
>
> Please always add net or net-next in your patches for netdev@
>
> ( Documentation/networking/netdev-FAQ.rst )
>
Apologies. These patches are intended for net-next
^ permalink raw reply
* Re: [PATCH 1/2] net: fastopen: make key handling more robust against future changes
From: Eric Dumazet @ 2019-06-18 9:39 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: netdev, Eric Biggers, linux-crypto, Herbert Xu, David Miller,
Alexey Kuznetsov, Hideaki YOSHIFUJI, Jason Baron,
Christoph Paasch, David Laight, Yuchung Cheng
In-Reply-To: <20190618093207.13436-2-ard.biesheuvel@linaro.org>
On Tue, Jun 18, 2019 at 2:32 AM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
>
> Some changes to the TCP fastopen code to make it more robust
> against future changes in the choice of key/cookie size, etc.
>
> - Instead of keeping the SipHash key in an untyped u8[] buffer
> and casting it to the right type upon use, use the correct
> siphash_key_t type directly. This ensures that the key will
> appear at the correct alignment if we ever change the way
> these data structures are allocated. (Currently, they are
> only allocated via kmalloc so they always appear at the
> correct alignment)
>
> - Use DIV_ROUND_UP when sizing the u64[] array to hold the
> cookie, so it is always of sufficient size, even when
> TCP_FASTOPEN_COOKIE_MAX is no longer a multiple of 8.
>
> - Add a key length check to tcp_fastopen_reset_cipher(). No
> callers exist currently that fail this check (they all pass
> compile constant values that equal TCP_FASTOPEN_KEY_LENGTH),
> but future changes might create problems, e.g., by leaving part
> of the key uninitialized, or overflowing the key buffers.
>
> Note that none of these are functional changes wrt the current
> state of the code.
>
...
> - memcpy(ctx->key[0], primary_key, len);
> + if (unlikely(len != TCP_FASTOPEN_KEY_LENGTH)) {
> + pr_err("TCP: TFO key length %u invalid\n", len);
> + err = -EINVAL;
> + goto out;
> + }
Why a pr_err() is there ?
Can unpriv users flood the syslog ?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox