Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 08 5月, 2020 23 次提交
  3. 07 5月, 2020 17 次提交
    • P
      net: flow_offload: skip hw stats check for FLOW_ACTION_HW_STATS_DONT_CARE · 16f80360
      由 Pablo Neira Ayuso 提交于 
      This patch adds FLOW_ACTION_HW_STATS_DONT_CARE which tells the driver
that the frontend does not need counters, this hw stats type request
never fails. The FLOW_ACTION_HW_STATS_DISABLED type explicitly requests
the driver to disable the stats, however, if the driver cannot disable
counters, it bails out.

TCA_ACT_HW_STATS_* maintains the 1:1 mapping with FLOW_ACTION_HW_STATS_*
except by disabled which is mapped to FLOW_ACTION_HW_STATS_DISABLED
(this is 0 in tc). Add tc_act_hw_stats() to perform the mapping between
TCA_ACT_HW_STATS_* and FLOW_ACTION_HW_STATS_*.

Fixes: 319a1d19 ("flow_offload: check for basic action hw stats type")
Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      16f80360
    • J
      wireguard: send/receive: use explicit unlikely branch instead of implicit coalescing · 243f2148
      由 Jason A. Donenfeld 提交于 
      It's very unlikely that send will become true. It's nearly always false
between 0 and 120 seconds of a session, and in most cases becomes true
only between 120 and 121 seconds before becoming false again. So,
unlikely(send) is clearly the right option here.

What happened before was that we had this complex boolean expression
with multiple likely and unlikely clauses nested. Since this is
evaluated left-to-right anyway, the whole thing got converted to
unlikely. So, we can clean this up to better represent what's going on.

The generated code is the same.
Suggested-by: NSultan Alsawaf <sultan@kerneltoast.com>
Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      243f2148
    • J
      wireguard: selftests: initalize ipv6 members to NULL to squelch clang warning · 4fed818e
      由 Jason A. Donenfeld 提交于 
      Without setting these to NULL, clang complains in certain
configurations that have CONFIG_IPV6=n:

In file included from drivers/net/wireguard/ratelimiter.c:223:
drivers/net/wireguard/selftest/ratelimiter.c:173:34: error: variable 'skb6' is uninitialized when used here [-Werror,-Wuninitialized]
                ret = timings_test(skb4, hdr4, skb6, hdr6, &test_count);
                                               ^~~~
drivers/net/wireguard/selftest/ratelimiter.c:123:29: note: initialize the variable 'skb6' to silence this warning
        struct sk_buff *skb4, *skb6;
                                   ^
                                    = NULL
drivers/net/wireguard/selftest/ratelimiter.c:173:40: error: variable 'hdr6' is uninitialized when used here [-Werror,-Wuninitialized]
                ret = timings_test(skb4, hdr4, skb6, hdr6, &test_count);
                                                     ^~~~
drivers/net/wireguard/selftest/ratelimiter.c:125:22: note: initialize the variable 'hdr6' to silence this warning
        struct ipv6hdr *hdr6;
                            ^

We silence this warning by setting the variables to NULL as the warning
suggests.
Reported-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4fed818e
    • J
      wireguard: send/receive: cond_resched() when processing worker ringbuffers · 4005f5c3
      由 Jason A. Donenfeld 提交于 
      Users with pathological hardware reported CPU stalls on CONFIG_
PREEMPT_VOLUNTARY=y, because the ringbuffers would stay full, meaning
these workers would never terminate. That turned out not to be okay on
systems without forced preemption, which Sultan observed. This commit
adds a cond_resched() to the bottom of each loop iteration, so that
these workers don't hog the core. Note that we don't need this on the
napi poll worker, since that terminates after its budget is expended.
Suggested-by: NSultan Alsawaf <sultan@kerneltoast.com>
Reported-by: NWang Jian <larkwang@gmail.com>
Fixes: e7096c13 ("net: WireGuard secure network tunnel")
Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4005f5c3
    • J
      wireguard: socket: remove errant restriction on looping to self · b673e24a
      由 Jason A. Donenfeld 提交于 
      It's already possible to create two different interfaces and loop
packets between them. This has always been possible with tunnels in the
kernel, and isn't specific to wireguard. Therefore, the networking stack
already needs to deal with that. At the very least, the packet winds up
exceeding the MTU and is discarded at that point. So, since this is
already something that happens, there's no need to forbid the not very
exceptional case of routing a packet back to the same interface; this
loop is no different than others, and we shouldn't special case it, but
rather rely on generic handling of loops in general. This also makes it
easier to do interesting things with wireguard such as onion routing.

At the same time, we add a selftest for this, ensuring that both onion
routing works and infinite routing loops do not crash the kernel. We
also add a test case for wireguard interfaces nesting packets and
sending traffic between each other, as well as the loop in this case
too. We make sure to send some throughput-heavy traffic for this use
case, to stress out any possible recursion issues with the locks around
workqueues.

Fixes: e7096c13 ("net: WireGuard secure network tunnel")
Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b673e24a
    • G
      net: ethernet: ti: am65-cpsw-nuss: fix irqs type · 6f5c27f9
      由 Grygorii Strashko 提交于 
      The K3 INTA driver, which is source TX/RX IRQs for CPSW NUSS, defines IRQs
triggering type as EDGE by default, but triggering type for CPSW NUSS TX/RX
IRQs has to be LEVEL as the EDGE triggering type may cause unnecessary IRQs
triggering and NAPI scheduling for empty queues. It was discovered with
RT-kernel.

Fix it by explicitly specifying CPSW NUSS TX/RX IRQ type as
IRQF_TRIGGER_HIGH.

Fixes: 93a76530 ("net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver")
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6f5c27f9
    • A
      dsa: sja1105: dynamically allocate stats structure · ae1804de
      由 Arnd Bergmann 提交于 
      The addition of sja1105_port_status_ether structure into the
statistics causes the frame size to go over the warning limit:

drivers/net/dsa/sja1105/sja1105_ethtool.c:421:6: error: stack frame size of 1104 bytes in function 'sja1105_get_ethtool_stats' [-Werror,-Wframe-larger-than=]

Use dynamic allocation to avoid this.

Fixes: 336aa67b ("net: dsa: sja1105: show more ethtool statistics counters for P/Q/R/S")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ae1804de
    • G
      ionic: Use debugfs_create_bool() to export bool · 0735ccc9
      由 Geert Uytterhoeven 提交于 
      Currently bool ionic_cq.done_color is exported using
debugfs_create_u8(), which requires a cast, preventing further compiler
checks.

Fix this by switching to debugfs_create_bool(), and dropping the cast.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NShannon Nelson <snelson@pensando.io>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0735ccc9
    • O
      net: phy: tja11xx: add support for master-slave configuration · b883e47b
      由 Oleksij Rempel 提交于 
      The TJA11xx PHYs have a vendor specific Master/Slave configuration bit,
which is not compatible with IEEE 803.2-2018 spec for 100Base-T1
devices. So, provide a custom config_ange call back to solve this
problem.
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b883e47b
    • O
      ethtool: provide UAPI for PHY master/slave configuration. · bdbdac76
      由 Oleksij Rempel 提交于 
      This UAPI is needed for BroadR-Reach 100BASE-T1 devices. Due to lack of
auto-negotiation support, we needed to be able to configure the
MASTER-SLAVE role of the port manually or from an application in user
space.

The same UAPI can be used for 1000BASE-T or MultiGBASE-T devices to
force MASTER or SLAVE role. See IEEE 802.3-2018:
22.2.4.3.7 MASTER-SLAVE control register (Register 9)
22.2.4.3.8 MASTER-SLAVE status register (Register 10)
40.5.2 MASTER-SLAVE configuration resolution
45.2.1.185.1 MASTER-SLAVE config value (1.2100.14)
45.2.7.10 MultiGBASE-T AN control 1 register (Register 7.32)

The MASTER-SLAVE role affects the clock configuration:

-------------------------------------------------------------------------------
When the  PHY is configured as MASTER, the PMA Transmit function shall
source TX_TCLK from a local clock source. When configured as SLAVE, the
PMA Transmit function shall source TX_TCLK from the clock recovered from
data stream provided by MASTER.

iMX6Q                     KSZ9031                XXX
------\                /-----------\        /------------\
      |                |           |        |            |
 MAC  |<----RGMII----->| PHY Slave |<------>| PHY Master |
      |<--- 125 MHz ---+-<------/  |        | \          |
------/                \-----------/        \------------/
                                               ^
                                                \-TX_TCLK

-------------------------------------------------------------------------------

Since some clock or link related issues are only reproducible in a
specific MASTER-SLAVE-role, MAC and PHY configuration, it is beneficial
to provide generic (not 100BASE-T1 specific) interface to the user space
for configuration flexibility and trouble shooting.
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bdbdac76
    • A
      net: ipa: kill ipa_cmd_dma_task_32b_addr_add() · da1a782a
      由 Alex Elder 提交于 
      A recent commit removed the only use of ipa_cmd_dma_task_32b_addr_add().
This function (and the IPA immediate command it implements) is no
longer needed, so get rid of it, along with all of the definitions
associated with it.  Isolate its removal in a commit so it can be
easily added back again if needed.
Signed-off-by: NAlex Elder <elder@linaro.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      da1a782a
    • A
      net: ipa: kill ipa_endpoint_stop() · f30dcb7d
      由 Alex Elder 提交于 
      The previous commit made ipa_endpoint_stop() be a trivial wrapper
around gsi_channel_stop().  Since it no longer does anything
special, just open-code it in the three places it's used.
Signed-off-by: NAlex Elder <elder@linaro.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f30dcb7d
    • A
      net: ipa: don't retry in ipa_endpoint_stop() · 9928fcc7
      由 Alex Elder 提交于 
      The only reason ipa_endpoint_stop() had a retry loop was that the
just-removed workaround required an IPA DMA command to occur between
attempts.  The gsi_channel_stop() call that implements the stop does
its own retry loop, to cover a channel's transition from started to
stop-in-progress to stopped state.

Get rid of the unnecessary retry loop in ipa_endpoint_stop().
Signed-off-by: NAlex Elder <elder@linaro.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9928fcc7
    • A
      net: ipa: get rid of workaround in ipa_endpoint_stop() · c72ddf0d
      由 Alex Elder 提交于 
      In ipa_endpoint_stop(), a workaround is used for IPA version 3.5.1
where a 1-byte DMA request is issued between GSI channel stop
retries.

It turns out that this workaround is only required for IPA versions
3.1 and 3.2, and we don't support those.  So remove the call to
ipa_endpoint_stop_rx_dma() in that function.  That leaves that
function unused, so get rid of it.
Signed-off-by: NAlex Elder <elder@linaro.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c72ddf0d
    • A
      net: ipa: fix a bug in ipa_endpoint_stop() · 97e4692d
      由 Alex Elder 提交于 
      In ipa_endpoint_stop(), for TX endpoints we set the number of retries
to 0.  When we break out of the loop, retries being 0 means we return
EIO rather than the value of ret (which should be 0).

Fix this by using a non-zero retry count for both RX and TX
channels, and just break out of the loop after calling
gsi_channel_stop() for TX channels.  This way only RX channels
will retry, and the retry count will be non-zero at the end
for TX channels (so the proper value gets returned).
Signed-off-by: NAlex Elder <elder@linaro.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
(cherry picked from commit 713b6ebb)
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      97e4692d
    • A
      net: ipa: remove endpoint delay mode feature · a4dcad34
      由 Alex Elder 提交于 
      A "delay mode" feature was put in place to work around a problem
that was observed during development of the upstream IPA driver.  It
used TX endpoint "delay mode" in order to prevent transmitting
packets toward the modem before it was ready.

A race condition that would explain the problem has long since been
fixed, and we have concluded that the "delay mode" feature is no
longer required.  So get rid of it.
Signed-off-by: NAlex Elder <elder@linaro.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a4dcad34
    • A
      net: ipa: introduce ipa_endpoint_program_suspend() · 4fa95248
      由 Alex Elder 提交于 
      Create a new helper function that encapsulates enabling or disabling
suspend on an RX endpoint.  It returns the previous state of the
endpoint (true means suspend mode was enabled).

Create another function that handles enabling or disabling delay mode
on a TX endpoint.  Delay mode does not work correctly on IPA version
4.2, so we don't currently use it (and shouldn't).

We only set delay mode in one case, and although we don't expect an
endpoint to already be in delay mode, it doesn't really matter if it
was.  So the delay function doesn't return a value.

Stop issuing warnings if the previous suspend or delay mode state
differs from what is expected.
Signed-off-by: NAlex Elder <elder@linaro.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4fa95248