* Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301
From: Mark Brown @ 2018-07-03 15:31 UTC (permalink / raw)
To: Andreas Färber
Cc: Steve deRosier, Matthias Brugger, Jiri Pirko, Ben Whitten, netdev,
Marcel Holtmann, Dollar Chen, linux-kernel, Michael Röder,
Janus Piwek, linux-spi, LoRa_Community_Support, Jian-Hong Pan,
Ken Yu, David S . Miller, linux-arm-kernel
In-Reply-To: <809fc546-6012-37f3-9485-cfd8eaf99488@suse.de>
[-- Attachment #1.1: Type: text/plain, Size: 2006 bytes --]
On Tue, Jul 03, 2018 at 05:09:38PM +0200, Andreas Färber wrote:
> Am 03.07.2018 um 16:50 schrieb Mark Brown:
> >> 2) This SPI device is in turn exposing the two SPI masters that you
> >> already found below, and I didn't see a sane way to split that code out
> >> into drivers/spi/, so it's in drivers/net/lora/ here - has there been
> >> any precedence either way?
> > A MFD?
> I know of mfd, but how would the the the net vs. spi pieces interact
> then? Some functions would need to be exported then or is there an
> easier way without needing to set a cross-module API in stone?
It's an in-kernel ABI it's not exactly set in stone but yeah, you'll
need some interface. A lot of devices work by having the children know
that they're part of a MFD and fish things out of the parent device,
either the pdata or (in the common case where the MFD bit mostly just
instantiates subdevices and holds a regmap) with dev_get_regmap().
> > A register map would work just as well here, we already have plenty of
> > devices that abstract at this level (most obviously the I2C/SPI devices
> > that use it to offer both interfaces with a single core driver).
> The address and data registers together form a two-byte SPI message!
> It is transmitted by writing to the CS register.
> The received data is afterwards available in another register.
Right, but it seems from the code that the hardware understands that
it's formatting register I/O and not just shifting in and out a byte
stream which is what a SPI controller does. I'd not be surprised to
learn that the register you're calling a chip select register is a
strobe that initiates the transfer (and that this may be some of the
difficulty you're having with handling it in the way the framework
expects), the pattern with writing 1 followed immediately by 0 is a bit
of a flag here.
I've seen such before hardware where I know it was intentionally
designed that way so it wouldn't be totally surprising.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: recvmsg bug not clear
From: Randy Dunlap @ 2018-07-03 16:18 UTC (permalink / raw)
To: 積丹尼 Dan Jacobson, linux-kernel,
netdev@vger.kernel.org, Eric Dumazet
In-Reply-To: <87601whg6r.fsf@jidanni.org>
[adding netdev]
On 07/03/18 01:33, 積丹尼 Dan Jacobson wrote:
> Most users won't even know what string from this to google on to find
> out what this is all about:
>
>
> Jul 03 13:57:20 jidanni7 kernel: ------------[ cut here ]------------
> Jul 03 13:57:20 jidanni7 kernel: recvmsg bug 2: copied 73BCB6CD seq 70F17CBE rcvnxt 73BCB9AA fl 0
> Jul 03 13:57:20 jidanni7 kernel: WARNING: CPU: 2 PID: 1501 at /build/linux-uwVqDp/linux-4.16.16/net/ipv4/tcp.c:1881 tcp_recvmsg+0x649/0xb90
> Jul 03 13:57:20 jidanni7 kernel: Modules linked in: nft_r...
>
>
> So please make clearer messages.
That's a message from net/ipv4/tcp.c
--
~Randy
^ permalink raw reply
* [PATCH net-next v3 2/2] tcp: ack immediately when a cwr packet arrives
From: Lawrence Brakmo @ 2018-07-03 16:26 UTC (permalink / raw)
To: netdev
Cc: Kernel Team, Blake Matheny, Alexei Starovoitov, Neal Cardwell,
Yuchung Cheng, Steve Ibanez, Eric Dumazet
In-Reply-To: <20180703162615.314231-1-brakmo@fb.com>
We observed high 99 and 99.9% latencies when doing RPCs with DCTCP. The
problem is triggered when the last packet of a request arrives CE
marked. The reply will carry the ECE mark causing TCP to shrink its cwnd
to 1 (because there are no packets in flight). When the 1st packet of
the next request arrives, the ACK was sometimes delayed even though it
is CWR marked, adding up to 40ms to the RPC latency.
This patch insures that CWR makred data packets arriving will be acked
immediately.
Modified based on comments by Neal Cardwell <ncardwell@google.com>
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
---
net/ipv4/tcp_input.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 2c5d70bc294e..23c2a43de8a4 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -246,8 +246,15 @@ static void tcp_ecn_queue_cwr(struct tcp_sock *tp)
static void tcp_ecn_accept_cwr(struct tcp_sock *tp, const struct sk_buff *skb)
{
- if (tcp_hdr(skb)->cwr)
+ if (tcp_hdr(skb)->cwr) {
tp->ecn_flags &= ~TCP_ECN_DEMAND_CWR;
+
+ /* If the sender is telling us it has entered CWR, then its
+ * cwnd may be very low (even just 1 packet), so we should ACK
+ * immediately.
+ */
+ tcp_enter_quickack_mode((struct sock *)tp, 2);
+ }
}
static void tcp_ecn_withdraw_cwr(struct tcp_sock *tp)
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v3 0/2] tcp: fix high tail latencies in DCTCP
From: Lawrence Brakmo @ 2018-07-03 16:26 UTC (permalink / raw)
To: netdev
Cc: Kernel Team, Blake Matheny, Alexei Starovoitov, Neal Cardwell,
Yuchung Cheng, Steve Ibanez, Eric Dumazet
When have observed high tail latencies when using DCTCP for RPCs as
compared to using Cubic. For example, in one setup there are 2 hosts
sending to a 3rd one, with each sender having 3 flows (1 stream,
1 1MB back-to-back RPCs and 1 10KB back-to-back RPCs). The following
table shows the 99% and 99.9% latencies for both Cubic and dctcp:
Cubic 99% Cubic 99.9% dctcp 99% dctcp 99.9%
1MB RPCs 2.6ms 5.5ms 43ms 208ms
10KB RPCs 1.1ms 1.3ms 53ms 212ms
Looking at tcpdump traces showed that there are two causes for the
latency.
1) RTOs caused by the receiver sending a dup ACK and not ACKing
the last (and only) packet sent.
2) Delaying ACKs when the sender has a cwnd of 1, so everything
pauses for the duration of the delayed ACK.
The first patch fixes the cause of the dup ACKs, not updating DCTCP
state when an ACK that was initially delayed has been sent with a
data packet.
The second patch insures that an ACK is sent immediately when a
CWR marked packet arrives.
With the patches the latencies for DCTCP now look like:
dctcp 99% dctcp 99.9%
1MB RPCs 5.8ms 6.9ms
10KB RPCs 146us 203us
Note that while the 1MB RPCs tail latencies are higher than Cubic's,
the 10KB latencies are much smaller than Cubic's. These patches fix
issues on the receiver, but tcpdump traces indicate there is an
opportunity to also fix an issue at the sender that adds about 3ms
to the tail latencies.
The following trace shows the issue that tiggers an RTO (fixed by these patches):
Host A sends the last packets of the request
Host B receives them, and the last packet is marked with congestion (CE)
Host B sends ACKs for packets not marked with congestion
Host B sends data packet with reply and ACK for packet marked with
congestion (TCP flag ECE)
Host A receives ACKs with no ECE flag
Host A receives data packet with ACK for the last packet of request
and which has TCP ECE bit set
Host A sends 1st data packet of the next request with TCP flag CWR
Host B receives the packet (as seen in tcpdump at B), no CE flag
Host B sends a dup ACK that also has the TCP ECE flag
Host A RTO timer fires!
Host A to send the next packet
Host A receives an ACK for everything it has sent (i.e. Host B
did receive 1st packet of request)
Host A send more packets…
v2: Removed call to tcp_ca_event from tcp_send_ack since I added one in
tcp_event_ack_sent. Based on Neal Cardwell <ncardwell@google.com>
feedback.
Modified tcp_ecn_check_ce (and renamed it tcp_ecn_check) instead of modifying
tcp_ack_send_check to insure an ACK when cwr is received.
v3: Handling cwr in tcp_ecn_accept_cwr instead of in tcp_ecn_check.
[PATCH net-next v3 1/2] tcp: notify when a delayed ack is sent
[PATCH net-next v3 2/2] tcp: ack immediately when a cwr packet
net/ipv4/tcp_input.c | 9 ++++++++-
net/ipv4/tcp_output.c | 4 ++--
2 files changed, 10 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH net-next v3 1/2] tcp: notify when a delayed ack is sent
From: Lawrence Brakmo @ 2018-07-03 16:26 UTC (permalink / raw)
To: netdev
Cc: Kernel Team, Blake Matheny, Alexei Starovoitov, Neal Cardwell,
Yuchung Cheng, Steve Ibanez, Eric Dumazet
In-Reply-To: <20180703162615.314231-1-brakmo@fb.com>
DCTCP depends on the CA_EVENT_NON_DELAYED_ACK and CA_EVENT_DELAYED_ACK
notifications to keep track if it needs to send an ACK for packets that
were received with a particular ECN state but whose ACK was delayed.
Under some circumstances, for example when a delayed ACK is sent with a
data packet, DCTCP state was not being updated due to a lack of
notification that the previously delayed ACK was sent. As a result, it
would sometimes send a duplicate ACK when a new data packet arrived.
This patch insures that DCTCP's state is correctly updated so it will
not send the duplicate ACK.
Improved based on comments from Neal Cardwell <ncardwell@google.com>.
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
---
net/ipv4/tcp_output.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index f8f6129160dd..acefb64e8280 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -172,6 +172,8 @@ static inline void tcp_event_ack_sent(struct sock *sk, unsigned int pkts)
__sock_put(sk);
}
tcp_dec_quickack_mode(sk, pkts);
+ if (inet_csk_ack_scheduled(sk))
+ tcp_ca_event(sk, CA_EVENT_NON_DELAYED_ACK);
inet_csk_clear_xmit_timer(sk, ICSK_TIME_DACK);
}
@@ -3567,8 +3569,6 @@ void tcp_send_ack(struct sock *sk)
if (sk->sk_state == TCP_CLOSE)
return;
- tcp_ca_event(sk, CA_EVENT_NON_DELAYED_ACK);
-
/* We are not putting this on the write queue, so
* tcp_transmit_skb() will set the ownership to this
* sock.
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v4 08/18] net: davinci_emac: potentially get the MAC address from MTD
From: Florian Fainelli @ 2018-07-03 16:39 UTC (permalink / raw)
To: Bartosz Golaszewski, Sekhar Nori, Kevin Hilman, Russell King,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla,
Lukas Wunner, Rob Herring, Dan Carpenter, Ivan Khoronzhuk,
David Lechner, Greg Kroah-Hartman, Andrew Lunn, Jonathan Corbet
Cc: linux-arm-kernel, linux-kernel, linux-omap, netdev,
Bartosz Golaszewski
In-Reply-To: <20180629094039.7543-9-brgl@bgdev.pl>
On 06/29/2018 02:40 AM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> On da850-evm board we can read the MAC address from MTD. It's currently
> done in the relevant board file, but we want to get rid of all the MAC
> reading callbacks from the board file (SPI and NAND). Move the reading
> of the MAC address from SPI to the emac driver's probe function.
This should be made something generic to all drivers, not just something
the davinci_emac driver does, something like this actually:
https://lkml.org/lkml/2018/3/24/312
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> drivers/net/ethernet/ti/davinci_emac.c | 20 ++++++++++++++++++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
> index a1a6445b5a7e..48e6a7755811 100644
> --- a/drivers/net/ethernet/ti/davinci_emac.c
> +++ b/drivers/net/ethernet/ti/davinci_emac.c
> @@ -67,7 +67,7 @@
> #include <linux/of_irq.h>
> #include <linux/of_net.h>
> #include <linux/mfd/syscon.h>
> -
> +#include <linux/mtd/mtd.h>
> #include <asm/irq.h>
> #include <asm/page.h>
>
> @@ -1783,7 +1783,10 @@ static int davinci_emac_probe(struct platform_device *pdev)
> struct cpdma_params dma_params;
> struct clk *emac_clk;
> unsigned long emac_bus_frequency;
> -
> +#ifdef CONFIG_MTD
> + size_t mac_addr_len;
> + struct mtd_info *mtd;
> +#endif /* CONFIG_MTD */
>
> /* obtain emac clock from kernel */
> emac_clk = devm_clk_get(&pdev->dev, NULL);
> @@ -1815,6 +1818,19 @@ static int davinci_emac_probe(struct platform_device *pdev)
> goto err_free_netdev;
> }
>
> +#ifdef CONFIG_MTD
> + mtd = get_mtd_device_nm("MAC-Address");
> + if (!IS_ERR(mtd)) {
> + rc = mtd_read(mtd, 0, ETH_ALEN,
> + &mac_addr_len, priv->mac_addr);
> + if (rc == 0)
> + dev_info(&pdev->dev,
> + "Read MAC addr from SPI Flash: %pM\n",
> + priv->mac_addr);
> + put_mtd_device(mtd);
> + }
> +#endif /* CONFIG_MTD */
> +
> /* MAC addr and PHY mask , RMII enable info from platform_data */
> memcpy(priv->mac_addr, pdata->mac_addr, ETH_ALEN);
> priv->phy_id = pdata->phy_id;
>
--
Florian
^ permalink raw reply
* Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301
From: Andreas Färber @ 2018-07-03 16:40 UTC (permalink / raw)
To: Mark Brown
Cc: netdev, linux-arm-kernel, linux-kernel, Jian-Hong Pan, Jiri Pirko,
Marcel Holtmann, David S . Miller, Matthias Brugger, Janus Piwek,
Michael Röder, Dollar Chen, Ken Yu, Ben Whitten,
Steve deRosier, linux-spi, LoRa_Community_Support, Hasnain Virk
In-Reply-To: <20180703153137.GB13744@sirena.org.uk>
Am 03.07.2018 um 17:31 schrieb Mark Brown:
> On Tue, Jul 03, 2018 at 05:09:38PM +0200, Andreas Färber wrote:
>> Am 03.07.2018 um 16:50 schrieb Mark Brown:
>>> A register map would work just as well here, we already have plenty of
>>> devices that abstract at this level (most obviously the I2C/SPI devices
>>> that use it to offer both interfaces with a single core driver).
>
>> The address and data registers together form a two-byte SPI message!
>
>> It is transmitted by writing to the CS register.
>
>> The received data is afterwards available in another register.
>
> Right, but it seems from the code that the hardware understands that
> it's formatting register I/O and not just shifting in and out a byte
> stream which is what a SPI controller does. I'd not be surprised to
> learn that the register you're calling a chip select register is a
> strobe that initiates the transfer (and that this may be some of the
> difficulty you're having with handling it in the way the framework
> expects), the pattern with writing 1 followed immediately by 0 is a bit
> of a flag here.
Yeah, the current implementation assumes exactly that. :)
> I've seen such before hardware where I know it was intentionally
> designed that way so it wouldn't be totally surprising.
If we don't implement a spi_controller here, then IIUC we can't have
multiple spi_device implementations for the devices on the receiving
end, as they rely on a spi_controller for their APIs.
Do you have an alternative solution for abstraction? A regmap would seem
to require putting everything into a monolithic SX1301 driver despite
those connected chipsets actually being regular, external SPI chips that
could also be attached to non-SX1301 SPI masters.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH net-next 01/10] r8169: add basic phylib support
From: Florian Fainelli @ 2018-07-03 16:42 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn
Cc: David Miller, Realtek linux nic maintainers,
netdev@vger.kernel.org
In-Reply-To: <238e0c62-7e95-df62-3837-5e8d1b7248f0@gmail.com>
On 07/02/2018 02:15 PM, Heiner Kallweit wrote:
> On 02.07.2018 23:02, Andrew Lunn wrote:
>>> +static int r8169_mdio_read_reg(struct mii_bus *mii_bus, int phyaddr, int phyreg)
>>> +{
>>> + struct rtl8169_private *tp = mii_bus->priv;
>>> +
>>> + return rtl_readphy(tp, phyreg);
>>
>> So there is no support for phyaddr?
>>
> Right, the chip can access only the one internal PHY, therefore it
> doesn't support phyaddr.
Then you might also want to set mii_bus->phy_mask accordingly such that
only the internal PHY address bit is cleared there?
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 02/10] r8169: use phy_resume/phy_suspend
From: Florian Fainelli @ 2018-07-03 16:44 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn
Cc: David Miller, Realtek linux nic maintainers,
netdev@vger.kernel.org
In-Reply-To: <8ef120d3-ac4a-7ffd-2104-76d6f1268105@gmail.com>
On 07/02/2018 02:24 PM, Heiner Kallweit wrote:
> On 02.07.2018 23:06, Andrew Lunn wrote:
>>> static void r8168_pll_power_down(struct rtl8169_private *tp)
>>> {
>>> if (r8168_check_dash(tp))
>>> @@ -4510,7 +4469,8 @@ static void r8168_pll_power_down(struct rtl8169_private *tp)
>>> if (rtl_wol_pll_power_down(tp))
>>> return;
>>>
>>> - r8168_phy_power_down(tp);
>>> + /* cover the case that PHY isn't connected */
>>> + phy_suspend(mdiobus_get_phy(tp->mii_bus, 0));
>>
>> This could do some more explanation. Why would it not be connected?
>>
> The PHY gets connected when the net_device is opened. If a network
> port isn't used then it will be runtime-suspended a few seconds after
> boot. In this case we call r8168_pll_power_down() with the PHY not
> being connected.
Would not the !netif_running() check in rtl8169_net_suspend() take care
of that though?
--
Florian
^ permalink raw reply
* Re: [PATCH v4 08/18] net: davinci_emac: potentially get the MAC address from MTD
From: David Lechner @ 2018-07-03 16:47 UTC (permalink / raw)
To: Florian Fainelli, Bartosz Golaszewski, Sekhar Nori, Kevin Hilman,
Russell King, Grygorii Strashko, David S . Miller,
Srinivas Kandagatla, Lukas Wunner, Rob Herring, Dan Carpenter,
Ivan Khoronzhuk, Greg Kroah-Hartman, Andrew Lunn, Jonathan Corbet
Cc: linux-arm-kernel, linux-kernel, linux-omap, netdev,
Bartosz Golaszewski
In-Reply-To: <03b77e24-9ab9-fa01-2387-9de0408a9942@gmail.com>
On 07/03/2018 11:39 AM, Florian Fainelli wrote:
>
>
> On 06/29/2018 02:40 AM, Bartosz Golaszewski wrote:
>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> On da850-evm board we can read the MAC address from MTD. It's currently
>> done in the relevant board file, but we want to get rid of all the MAC
>> reading callbacks from the board file (SPI and NAND). Move the reading
>> of the MAC address from SPI to the emac driver's probe function.
>
> This should be made something generic to all drivers, not just something
> the davinci_emac driver does, something like this actually:
>
> https://lkml.org/lkml/2018/3/24/312
>
I was thinking about suggesting adding a nvmem provider for MTD devices
as well. It would fix the kernel config dependency problems I was running
into since nvmem lookups can do -EPROBE_DEFER.
^ permalink raw reply
* Re: [PATCH net-next 07/10] r8169: migrate speed_down function to phylib
From: Florian Fainelli @ 2018-07-03 16:48 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn
Cc: David Miller, Realtek linux nic maintainers,
netdev@vger.kernel.org
In-Reply-To: <8d516fa8-30a5-df7e-737c-119d6e458d80@gmail.com>
On 07/02/2018 02:31 PM, Heiner Kallweit wrote:
> On 02.07.2018 23:20, Andrew Lunn wrote:
>> On Mon, Jul 02, 2018 at 09:37:08PM +0200, Heiner Kallweit wrote:
>>> Change rtl_speed_down() to use phylib.
>>>
>>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>>> ---
>>> drivers/net/ethernet/realtek/r8169.c | 33 +++++++++++++---------------
>>> 1 file changed, 15 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
>>> index 311321ee..807fbc75 100644
>>> --- a/drivers/net/ethernet/realtek/r8169.c
>>> +++ b/drivers/net/ethernet/realtek/r8169.c
>>> @@ -4240,6 +4240,10 @@ static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp)
>>> rtl_writephy(tp, 0x0b, 0x0000); //w 0x0b 15 0 0
>>> }
>>>
>>> + /* We may have called rtl_speed_down before */
>>> + dev->phydev->advertising = dev->phydev->supported;
>>> + genphy_config_aneg(dev->phydev);
>>> +
>>> genphy_soft_reset(dev->phydev);
>>>
>>> rtl8169_set_speed(dev, AUTONEG_ENABLE, SPEED_1000, DUPLEX_FULL,
>>> @@ -4323,28 +4327,21 @@ static void rtl_init_mdio_ops(struct rtl8169_private *tp)
>>> }
>>> }
>>>
>>> +#define BASET10 (ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full)
>>> +#define BASET100 (ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full)
>>> +#define BASET1000 (ADVERTISED_1000baseT_Half | ADVERTISED_1000baseT_Full)
>>> +
>>> static void rtl_speed_down(struct rtl8169_private *tp)
>>> {
>>> - u32 adv;
>>> - int lpa;
>>> + struct phy_device *phydev = tp->dev->phydev;
>>> + u32 adv = phydev->lp_advertising & phydev->supported;
>>>
>>> - rtl_writephy(tp, 0x1f, 0x0000);
>>> - lpa = rtl_readphy(tp, MII_LPA);
>>> + if (adv & BASET10)
>>> + phydev->advertising &= ~(BASET100 | BASET1000);
>>> + else if (adv & BASET100)
>>> + phydev->advertising &= ~BASET1000;
>>>
>>> - if (lpa & (LPA_10HALF | LPA_10FULL))
>>> - adv = ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full;
>>> - else if (lpa & (LPA_100HALF | LPA_100FULL))
>>> - adv = ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full |
>>> - ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full;
>>> - else
>>> - adv = ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full |
>>> - ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full |
>>> - (tp->mii.supports_gmii ?
>>> - ADVERTISED_1000baseT_Half |
>>> - ADVERTISED_1000baseT_Full : 0);
>>> -
>>> - rtl8169_set_speed(tp->dev, AUTONEG_ENABLE, SPEED_1000, DUPLEX_FULL,
>>> - adv);
>>> + genphy_config_aneg(phydev);
>>> }
>>
>> It probably it is me being too tired, but i don't get what this is
>> doing? Changing the local advertisement based on what the remote is
>> advertising. Why?
>>
> It also took me some time to understand what this speed_down is doing.
> If we suspend and wait for a WoL packet, then we don't have to burn all
> the energy for a GBit connection. Therefore we switch to the lowest
> speed supported by chip and link partner. This is done by removing
> higher speeds from the advertised modes and restarting an autonego.
This is something that the tg3 driver also does, we should probably
consider doing this as part of a generic PHY library helpers since I was
told by several HW engineers that usually 10Mbits for WoL is much more
energy efficient.
One thing that bothers me a bit is that this should ideally be offered
as both blocking and non-blocking options, because we might want to make
sure that at the time we suspend, and we already had a link established,
we successfully re-negotiate the link with the partner. I agree that
there could be any sort of link disruption happening at any point though..
--
Florian
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2018-07-03 17:03 UTC (permalink / raw)
To: Ursula Braun
Cc: David Miller, Andrew Morton, Network Development,
Linux Kernel Mailing List
In-Reply-To: <5b5509f1-9713-f1bc-cb33-18ebdb1cb8c5@linux.ibm.com>
On Tue, Jul 3, 2018 at 6:52 AM Ursula Braun <ubraun@linux.ibm.com> wrote:
>
> Thanks Linus for your revert. I run a test, and found it is almost fine.
> Just these 2 lines are missing:
I should have realized that. I actually looked at it and decided your
other changes made that unnecessary, but that was a thinko on my part.
Fixed up. Thanks,
Linus
^ permalink raw reply
* Re: [RFC PATCH 00/11] OVS eBPF datapath.
From: Alexei Starovoitov @ 2018-07-03 17:56 UTC (permalink / raw)
To: William Tu
Cc: <dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org>,
Tom Herbert via iovisor-dev, Linux Kernel Network Developers
In-Reply-To: <CALDO+SYzDDpTmJttghfjUYKbo3AHDaT4L154Acwn5BGqkytkHQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Jun 28, 2018 at 07:19:35AM -0700, William Tu wrote:
> Hi Alexei,
>
> Thanks a lot for the feedback!
>
> On Wed, Jun 27, 2018 at 8:00 PM, Alexei Starovoitov
> <alexei.starovoitov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Sat, Jun 23, 2018 at 05:16:32AM -0700, William Tu wrote:
> >>
> >> Discussion
> >> ==========
> >> We are still actively working on finishing the feature, currently
> >> the basic forwarding and tunnel feature work, but still under
> >> heavy debugging and development. The purpose of this RFC is to
> >> get some early feedbacks and direction for finishing the complete
> >> features in existing kernel's OVS datapath (the net/openvswitch/*).
> >
> > Thank you for sharing the patches.
> >
> >> Three major issues we are worried:
> >> a. Megaflow support in BPF.
> >> b. Connection Tracking support in BPF.
> >
> > my opinion on the above two didn't change.
> > To recap:
> > A. Non scalable megaflow map is no go. I'd like to see packet classification
> > algorithm like hicuts or efficuts to be implemented instead, since it can be
> > shared by generic bpf, bpftiler, ovs and likely others.
>
> We did try the decision tree approach using dpdk's acl lib. The lookup
> speed is 6 times faster than the magaflow using tuple space.
> However, the update/insertion requires rebuilding/re-balancing the decision
> tree so it's way too slow. I think hicuts or efficuts suffers the same issue.
> So decision tree algos are scalable only for lookup operation due to its
> optimization over tree depth, but not scalable under
> update/insert/delete operations.
>
> On customer's system we see megaflow update/insert rate around 10 rules/sec,
> this makes decision tree unusable, unless we invent something to optimize the
> update/insert time or incremental update of these decision tree algo.
is this a typo? you probably meant 10K rule updates a second ?
Last time I've dealt with these algorithms we had 100K acl updates a second.
It was an important metric that we were optimizing for.
I'm pretty sure '*cuts' algos do many thousands per second non optimized.
> >> c. Verifier limitation.
> >
> > Not sure what limitations you're concerned about.
> >
>
> Mostly related to stack. The flow key OVS uses (struct sw_flow_key)
> is 464 byte. We trim a lot, now around 300 byte, but still huge, considering
> the BPF's stack limit is 512 byte.
have you tried using per-cpu array of one element with large value
instead of stack?
In the latest verifier most of the operations that can be done with the stack
pointer can be done with pointer to map value too.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1358): https://lists.iovisor.org/g/iovisor-dev/message/1358
Mute This Topic: https://lists.iovisor.org/mt/22656941/1132507
Group Owner: iovisor-dev+owner-9jONkmmOlFHEE9lA1F8Ukti2O/JbrIOy@public.gmane.org
Unsubscribe: https://lists.iovisor.org/g/iovisor-dev/unsub [glki-iovisor-dev@m.gmane.org]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] tcp: notify when a delayed ack is sent
From: Lawrence Brakmo @ 2018-07-03 18:38 UTC (permalink / raw)
To: Neal Cardwell, Yuchung Cheng
Cc: Netdev, Kernel Team, Blake Matheny, Alexei Starovoitov,
Steve Ibanez, Eric Dumazet, Daniel Borkmann
In-Reply-To: <CADVnQykD8i68w8zySXv1tnVnrYYiGC9oVRMk70xeC9mE9PtnfQ@mail.gmail.com>
On 7/3/18, 6:15 AM, "Neal Cardwell" <ncardwell@google.com> wrote:
On Mon, Jul 2, 2018 at 7:49 PM Yuchung Cheng <ycheng@google.com> wrote:
>
> On Mon, Jul 2, 2018 at 2:39 PM, Lawrence Brakmo <brakmo@fb.com> wrote:
> >
> > DCTCP depends on the CA_EVENT_NON_DELAYED_ACK and CA_EVENT_DELAYED_ACK
> > notifications to keep track if it needs to send an ACK for packets that
> > were received with a particular ECN state but whose ACK was delayed.
> >
> > Under some circumstances, for example when a delayed ACK is sent with a
> > data packet, DCTCP state was not being updated due to a lack of
> > notification that the previously delayed ACK was sent. As a result, it
> > would sometimes send a duplicate ACK when a new data packet arrived.
> >
> > This patch insures that DCTCP's state is correctly updated so it will
> > not send the duplicate ACK.
> Sorry to chime-in late here (lame excuse: IETF deadline)
>
> IIRC this issue would exist prior to 4.11 kernel. While it'd be good
> to fix that, it's not clear which patch introduced the regression
> between 4.11 and 4.16? I assume you tested Eric's most recent quickack
> fix.
I don't think Larry is saying there's a regression between 4.11 and
4.16. His recent "tcp: force cwnd at least 2 in tcp_cwnd_reduction"
patch here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_935233_&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=pq_Mqvzfy-C8ltkgyx1u_g&m=7ko5C_ln2b7gZvz2A_UrZzz0AlcnhrW7-9KRahj_PEA&s=HcpZvo1TulN4-Y7Jhba5KM1MIaPwnBC95T8pLZfJESI&e=
said that 4.11 was bad (high tail latency and lots of RTOs) and 4.16
was still bad but with different netstat counters (no RTOs but still
high tail latency):
"""
On 4.11, pcap traces indicate that in some instances the 1st packet of
the RPC is received but no ACK is sent before the packet is
retransmitted. On 4.11 netstat shows TCP timeouts, with some of them
spurious.
On 4.16, we don't see retransmits in netstat but the high tail latencies
are still there.
"""
I suspect the RTOs disappeared but latencies remained too high because
between 4.11 and 4.16 we introduced:
tcp: allow TLP in ECN CWR
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=b4f70c3d4ec32a2ff4c62e1e2da0da5f55fe12bd
So the RTOs probably disappeared because this commit turned them into
TLPs. But the latencies remained high because the fundamental bug
remained throughout 4.11 and 4.16 and today: the DCTCP use of
tcp_send_ack() with an old rcv_nxt caused delayed ACKs to be cancelled
when they should not have been.
> In terms of the fix itself, it seems odd the tcp_send_ack() call in
> DCTCP generates NON_DELAYED_ACK event to toggle DCTCP's
> delayed_ack_reserved bit. Shouldn't the fix to have DCTCP send the
> "prior" ACK w/o cancelling delayed-ACK and mis-recording that it's
> cancelled, because that prior-ACK really is a supplementary old ACK.
This patch is fixing an issue that's orthogonal to the one you are
talking about. Using the taxonomy from our team's internal discussion
yesterday, the issue you mention where the DCTCP "prior" ACK is
cancelling delayed ACKs is issue (4); the issue that this particular
"tcp: notify when a delayed ack is sent" patch from Larry fixes is
issue (3). It's a bit tricky because both issues appeared in Larry's
trace summary and packetdrill script to reproduce the issue.
neal
I was able to track the patch that introduced the problem:
commit 3759824da87b30ce7a35b4873b62b0ba38905ef5
Author: Yuchung Cheng <ycheng@google.com>
Date: Wed Jul 1 14:11:15 2015 -0700
tcp: PRR uses CRB mode by default and SS mode conditionally
I tested a kernel which reverted the relevant change (see diff below) and the high tail latencies of more than 40ms disappeared. However, the 10KB high percentile latencies are 4ms vs. less than 200us with my patches. It looks like the patch above ended up reducing the cwnd to 1 in the scenarios that were triggering the high tail latencies. That is, it increased the likelihood of triggering actual bugs in the network stack code that my patch set fixes.
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 2c5d70bc294e..50fabb07d739 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2468,13 +2468,14 @@ void tcp_cwnd_reduction(struct sock *sk, int newly_acked_sacked, int flag)
u64 dividend = (u64)tp->snd_ssthresh * tp->prr_delivered +
tp->prior_cwnd - 1;
sndcnt = div_u64(dividend, tp->prior_cwnd) - tp->prr_out;
- } else if ((flag & FLAG_RETRANS_DATA_ACKED) &&
- !(flag & FLAG_LOST_RETRANS)) {
+ } else {
+// } else if ((flag & FLAG_RETRANS_DATA_ACKED) &&
+// !(flag & FLAG_LOST_RETRANS)) {
sndcnt = min_t(int, delta,
max_t(int, tp->prr_delivered - tp->prr_out,
newly_acked_sacked) + 1);
- } else {
- sndcnt = min(delta, newly_acked_sacked);
+// } else {
+// sndcnt = min(delta, newly_acked_sacked);
}
/* Force a fast retransmit upon entering fast recovery */
sndcnt = max(sndcnt, (tp->prr_out ? 0 : 1));
^ permalink raw reply related
* Re: [Intel-wired-lan] [jkirsher/next-queue PATCH v2 0/7] Add support for L2 Fwd Offload w/o ndo_select_queue
From: Jeff Kirsher @ 2018-07-03 18:42 UTC (permalink / raw)
To: Alexander Duyck; +Cc: intel-wired-lan, netdev
In-Reply-To: <20180612151322.86792.97587.stgit@ahduyck-green-test.jf.intel.com>
On Tue, Jun 12, 2018 at 8:18 AM, Alexander Duyck
<alexander.h.duyck@intel.com> wrote:
> This patch series is meant to allow support for the L2 forward offload, aka
> MACVLAN offload without the need for using ndo_select_queue.
>
> The existing solution currently requires that we use ndo_select_queue in
> the transmit path if we want to associate specific Tx queues with a given
> MACVLAN interface. In order to get away from this we need to repurpose the
> tc_to_txq array and XPS pointer for the MACVLAN interface and use those as
> a means of accessing the queues on the lower device. As a result we cannot
> offload a device that is configured as multiqueue, however it doesn't
> really make sense to configure a macvlan interfaced as being multiqueue
> anyway since it doesn't really have a qdisc of its own in the first place.
>
> I am submitting this as an RFC for the netdev mailing list, and officially
> submitting it for testing to Jeff Kirsher's next-queue in order to validate
> the ixgbe specific bits.
>
> The big changes in this set are:
> Allow lower device to update tc_to_txq and XPS map of offloaded MACVLAN
> Disable XPS for single queue devices
> Replace accel_priv with sb_dev in ndo_select_queue
> Add sb_dev parameter to fallback function for ndo_select_queue
> Consolidated ndo_select_queue functions that appeared to be duplicates
>
> v2: Implement generic "select_queue" functions instead of "fallback" functions.
> Tweak last two patches to account for changes in dev_pick_tx_xxx functions.
>
> ---
>
> Alexander Duyck (7):
> net-sysfs: Drop support for XPS and traffic_class on single queue device
> net: Add support for subordinate device traffic classes
> ixgbe: Add code to populate and use macvlan tc to Tx queue map
> net: Add support for subordinate traffic classes to netdev_pick_tx
> net: Add generic ndo_select_queue functions
> net: allow ndo_select_queue to pass netdev
> net: allow fallback function to pass netdev
>
Alex, there were recent changes to Dave's net-next which caused a
conflict with one or more of your patches. So I have removed this
series from my tree for now, and will work with you on updating the
series to work with the latest net-next tree.
^ permalink raw reply
* Re: [PATCHv2 net-next 2/2] selftests: add a selftest for directed broadcast forwarding
From: David Ahern @ 2018-07-03 19:23 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, davem, Davide Caratti, Ido Schimmel
In-Reply-To: <CADvbK_ciwsQuJ3Ep0_oFzmFSAPGMB9vjB=KXZ=feG5X1M=oZnw@mail.gmail.com>
On 7/3/18 5:36 AM, Xin Long wrote:
> On Mon, Jul 2, 2018 at 11:12 PM, David Ahern <dsahern@gmail.com> wrote:
>> On 7/2/18 12:30 AM, Xin Long wrote:
>>> +ping_ipv4()
>>> +{
>>> + sysctl_set net.ipv4.icmp_echo_ignore_broadcasts 0
>>> + bc_forwarding_disable
>>> + ping_test $h1 198.51.100.255
>>> +
>>> + iptables -A INPUT -i vrf-r1 -p icmp -j DROP
>>> + bc_forwarding_restore
>>> + bc_forwarding_enable
>>> + ping_test $h1 198.51.100.255
>>> +
>>> + bc_forwarding_restore
>>> + iptables -D INPUT -i vrf-r1 -p icmp -j DROP
>>> + sysctl_restore net.ipv4.icmp_echo_ignore_broadcasts
>>> +}
>>
>> Both tests fail for me:
>> TEST: ping [FAIL]
>> TEST: ping [FAIL]
> I think 'ip vrf exec ...' is not working in your env, while
> the testing is using "ip vrf exec vrf-h1 ping ..."
>
> You can test it by:
> # ip link add dev vrf-test type vrf table 1111
> # ip vrf exec vrf-test ls
well, that's embarrassing. yes, I updated ip and forgot to apply the bpf
workaround to define the syscall number (not defined in jessie).
>
>>
>> Why the need for the iptables rule?
> This iptables rule is to block the echo_request packet going to
> route's local_in.
> When bc_forwarding is NOT doing forwarding well but the packet
> goes to the route's local_in, it will fail.
>
> Without this rule, the 2nd ping will always succeed, we can't tell the
> echo_reply is from route or h2.
>
> Or you have a better way to test this?
your commands are not a proper test. The test should succeed and fail
based on the routing lookup, not iptables rules.
>
>>
>> And, PAUSE_ON_FAIL is not working to take a look at why tests are
>> failing. e.g.,
>>
>> PAUSE_ON_FAIL=yes ./router_broadcast.sh
>>
>> just continues on. Might be something with the infrastructure scripts.
> Yes, in ./router_broadcast.sh, it loads lib.sh where it loads forwarding.config
> where it has "PAUSE_ON_FAIL=no", which would override your
> "PAUSE_ON_FAIL=yes".
>
ack. bit by that as well.
^ permalink raw reply
* Re: [PATCH net-next 01/10] r8169: add basic phylib support
From: Heiner Kallweit @ 2018-07-03 19:48 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn
Cc: David Miller, Realtek linux nic maintainers,
netdev@vger.kernel.org
In-Reply-To: <143f31fa-e8ea-7e79-46a7-b9a6d3ac68ef@gmail.com>
On 03.07.2018 18:42, Florian Fainelli wrote:
>
>
> On 07/02/2018 02:15 PM, Heiner Kallweit wrote:
>> On 02.07.2018 23:02, Andrew Lunn wrote:
>>>> +static int r8169_mdio_read_reg(struct mii_bus *mii_bus, int phyaddr, int phyreg)
>>>> +{
>>>> + struct rtl8169_private *tp = mii_bus->priv;
>>>> +
>>>> + return rtl_readphy(tp, phyreg);
>>>
>>> So there is no support for phyaddr?
>>>
>> Right, the chip can access only the one internal PHY, therefore it
>> doesn't support phyaddr.
>
> Then you might also want to set mii_bus->phy_mask accordingly such that
> only the internal PHY address bit is cleared there?
>
That's something I'm doing already, see following line in r8169_mdio_register():
new_bus->phy_mask = ~1;
But thanks for the hint anyway.
^ permalink raw reply
* Re: [PATCH net-next 02/10] r8169: use phy_resume/phy_suspend
From: Heiner Kallweit @ 2018-07-03 19:54 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn
Cc: David Miller, Realtek linux nic maintainers,
netdev@vger.kernel.org
In-Reply-To: <e8a9e121-9b5d-2e45-2547-148a782e6751@gmail.com>
On 03.07.2018 18:44, Florian Fainelli wrote:
>
>
> On 07/02/2018 02:24 PM, Heiner Kallweit wrote:
>> On 02.07.2018 23:06, Andrew Lunn wrote:
>>>> static void r8168_pll_power_down(struct rtl8169_private *tp)
>>>> {
>>>> if (r8168_check_dash(tp))
>>>> @@ -4510,7 +4469,8 @@ static void r8168_pll_power_down(struct rtl8169_private *tp)
>>>> if (rtl_wol_pll_power_down(tp))
>>>> return;
>>>>
>>>> - r8168_phy_power_down(tp);
>>>> + /* cover the case that PHY isn't connected */
>>>> + phy_suspend(mdiobus_get_phy(tp->mii_bus, 0));
>>>
>>> This could do some more explanation. Why would it not be connected?
>>>
>> The PHY gets connected when the net_device is opened. If a network
>> port isn't used then it will be runtime-suspended a few seconds after
>> boot. In this case we call r8168_pll_power_down() with the PHY not
>> being connected.
>
> Would not the !netif_running() check in rtl8169_net_suspend() take care
> of that though?
>
We don't come that far ..
If the interface is down then tp->TxDescArray is NULL. Means we call
rtl_pll_power_down() in rtl8169_runtime_suspend() before reaching
rtl8169_net_suspend().
^ permalink raw reply
* Re: [PATCH net] net/ipv6: Revert attempt to simplify route replace and append
From: David Ahern @ 2018-07-03 20:02 UTC (permalink / raw)
To: Ido Schimmel, dsahern; +Cc: netdev, sharpd, Thomas.Winter, petrm
In-Reply-To: <20180703134302.GB15120@splinter.mtl.com>
On 7/3/18 7:43 AM, Ido Schimmel wrote:
> On Mon, Jul 02, 2018 at 03:03:12PM -0700, dsahern@kernel.org wrote:
>> From: David Ahern <dsahern@gmail.com>
>>
>> NetworkManager likes to manage linklocal prefix routes and does so with
>> the NLM_F_APPEND flag, breaking attempts to simplify the IPv6 route
>> code and by extension enable multipath routes with device only nexthops.
>>
>> Revert f34436a43092 and its followup
>> 6eba08c3626b ("ipv6: Only emit append events for appended routes").
>> Update the test cases to reflect the old behavior.
>>
>> Fixes: f34436a43092 ("net/ipv6: Simplify route replace and appending into multipath route")
>> Signed-off-by: David Ahern <dsahern@gmail.com>
>> ---
>> Ido: I left 5a15a1b07c51. FIB_EVENT_ENTRY_APPEND is not generated for
>> IPv6, so no harm in leaving it.
>
> OK, but I had a follow-up series that did further changes in mlxsw
> (merge commit eab9a2d5f323) to support the new behavior. You want to
> revert it and squash to v2 or I'll send another revert?
I'll squash. The ability to add dev only nexthops is clearly needed.
Reverting in 1 patch will help on the next attempt.
It is unfortunate that mlxsw has to replicate the node lookup code.
>
> Also, Petr added a multipath test that relies on IPv6 device only
> nexthops. See commit 54818c4c4b937.
>
ok. I'll remove the ipv6 mpath tests as well.
^ permalink raw reply
* Re: [PATCH bpf] bpf: hash_map: decrement counter on error
From: Alexei Starovoitov @ 2018-07-03 20:28 UTC (permalink / raw)
To: Mauricio Vasquez; +Cc: Daniel Borkmann, Alexei Starovoitov, netdev
In-Reply-To: <5fba5067-1ba0-6ab1-21fd-ad6945cb886d@polito.it>
On Sun, Jul 01, 2018 at 11:33:58AM -0500, Mauricio Vasquez wrote:
>
> On 06/30/2018 06:20 PM, Daniel Borkmann wrote:
> > On 06/29/2018 02:48 PM, Mauricio Vasquez B wrote:
> > > Decrement the number of elements in the map in case the allocation
> > > of a new node fails.
> > >
> > > Signed-off-by: Mauricio Vasquez B <mauricio.vasquez@polito.it>
> > Thanks for the fix, Mauricio!
> >
> > Could you reply with a Fixes: tag in order to track the commit originally
> > introducing this bug?
> >
> > Thanks,
> > Daniel
> >
>
> Sure Daniel,
>
> Fixes: 6c9059817432 ("bpf: pre-allocate hash map elements")
Good catch. Thanks for the fix.
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* [PATCH net] net: phy: fix flag masking in __set_phy_supported
From: Heiner Kallweit @ 2018-07-03 20:34 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
Currently also the pause flags are removed from phydev->supported because
they're not included in PHY_DEFAULT_FEATURES. I don't think this is
intended, especially when considering that this function can be called
via phy_set_max_speed() anywhere in a driver. Change the masking to mask
out only the values we're going to change. In addition remove the
misleading comment, job of this small function is just to adjust the
supported and advertised speeds.
Fixes: f3a6bd393c2c ("phylib: Add phy_set_max_speed helper")
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy_device.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index bd0f339f..b9f5f40a 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1724,11 +1724,8 @@ EXPORT_SYMBOL(genphy_loopback);
static int __set_phy_supported(struct phy_device *phydev, u32 max_speed)
{
- /* The default values for phydev->supported are provided by the PHY
- * driver "features" member, we want to reset to sane defaults first
- * before supporting higher speeds.
- */
- phydev->supported &= PHY_DEFAULT_FEATURES;
+ phydev->supported &= ~(PHY_1000BT_FEATURES | PHY_100BT_FEATURES |
+ PHY_10BT_FEATURES);
switch (max_speed) {
default:
--
2.18.0
^ permalink raw reply related
* [PATCH] isdn: mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2018-07-03 21:17 UTC (permalink / raw)
To: Paul Bolle, Karsten Keil
Cc: gigaset307x-common, netdev, linux-kernel, Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Warning level 2 was used: -Wimplicit-fallthrough=2
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/isdn/gigaset/bas-gigaset.c | 3 +++
drivers/isdn/hardware/mISDN/avmfritz.c | 1 +
drivers/isdn/hardware/mISDN/hfcpci.c | 1 +
drivers/isdn/hardware/mISDN/mISDNinfineon.c | 1 +
drivers/isdn/hardware/mISDN/mISDNisar.c | 4 ++++
drivers/isdn/hisax/avm_pci.c | 1 +
drivers/isdn/hisax/callc.c | 1 +
drivers/isdn/hisax/config.c | 1 +
drivers/isdn/hisax/gazel.c | 4 ++++
drivers/isdn/hisax/isar.c | 2 ++
drivers/isdn/hisax/l3_1tr6.c | 1 +
drivers/isdn/hisax/l3dss1.c | 1 +
drivers/isdn/hysdn/hysdn_boot.c | 2 ++
drivers/isdn/i4l/isdn_v110.c | 9 +++++++++
drivers/isdn/mISDN/stack.c | 1 +
15 files changed, 33 insertions(+)
diff --git a/drivers/isdn/gigaset/bas-gigaset.c b/drivers/isdn/gigaset/bas-gigaset.c
index 40c1411..ecdeb89 100644
--- a/drivers/isdn/gigaset/bas-gigaset.c
+++ b/drivers/isdn/gigaset/bas-gigaset.c
@@ -739,6 +739,7 @@ static void read_int_callback(struct urb *urb)
case HD_OPEN_B2CHANNEL_ACK:
++channel;
+ /* fall through */
case HD_OPEN_B1CHANNEL_ACK:
bcs = cs->bcs + channel;
update_basstate(ucs, BS_B1OPEN << channel, 0);
@@ -752,6 +753,7 @@ static void read_int_callback(struct urb *urb)
case HD_CLOSE_B2CHANNEL_ACK:
++channel;
+ /* fall through */
case HD_CLOSE_B1CHANNEL_ACK:
bcs = cs->bcs + channel;
update_basstate(ucs, 0, BS_B1OPEN << channel);
@@ -765,6 +767,7 @@ static void read_int_callback(struct urb *urb)
case HD_B2_FLOW_CONTROL:
++channel;
+ /* fall through */
case HD_B1_FLOW_CONTROL:
bcs = cs->bcs + channel;
atomic_add((l - BAS_NORMFRAME) * BAS_CORRFRAMES,
diff --git a/drivers/isdn/hardware/mISDN/avmfritz.c b/drivers/isdn/hardware/mISDN/avmfritz.c
index ae2b266..8eb28a8 100644
--- a/drivers/isdn/hardware/mISDN/avmfritz.c
+++ b/drivers/isdn/hardware/mISDN/avmfritz.c
@@ -361,6 +361,7 @@ modehdlc(struct bchannel *bch, int protocol)
switch (protocol) {
case -1: /* used for init */
bch->state = -1;
+ /* fall through */
case ISDN_P_NONE:
if (bch->state == ISDN_P_NONE)
break;
diff --git a/drivers/isdn/hardware/mISDN/hfcpci.c b/drivers/isdn/hardware/mISDN/hfcpci.c
index 34c9387..72a271b 100644
--- a/drivers/isdn/hardware/mISDN/hfcpci.c
+++ b/drivers/isdn/hardware/mISDN/hfcpci.c
@@ -1296,6 +1296,7 @@ mode_hfcpci(struct bchannel *bch, int bc, int protocol)
case (-1): /* used for init */
bch->state = -1;
bch->nr = bc;
+ /* fall through */
case (ISDN_P_NONE):
if (bch->state == ISDN_P_NONE)
return 0;
diff --git a/drivers/isdn/hardware/mISDN/mISDNinfineon.c b/drivers/isdn/hardware/mISDN/mISDNinfineon.c
index 1fc2906..3e01012 100644
--- a/drivers/isdn/hardware/mISDN/mISDNinfineon.c
+++ b/drivers/isdn/hardware/mISDN/mISDNinfineon.c
@@ -887,6 +887,7 @@ release_card(struct inf_hw *card) {
release_card(card->sc[i]);
card->sc[i] = NULL;
}
+ /* fall through */
default:
pci_disable_device(card->pdev);
pci_set_drvdata(card->pdev, NULL);
diff --git a/drivers/isdn/hardware/mISDN/mISDNisar.c b/drivers/isdn/hardware/mISDN/mISDNisar.c
index b791688..386731e 100644
--- a/drivers/isdn/hardware/mISDN/mISDNisar.c
+++ b/drivers/isdn/hardware/mISDN/mISDNisar.c
@@ -972,6 +972,7 @@ isar_pump_statev_fax(struct isar_ch *ch, u8 devt) {
break;
case PCTRL_CMD_FTM:
p1 = 2;
+ /* fall through */
case PCTRL_CMD_FTH:
send_mbox(ch->is, dps | ISAR_HIS_PUMPCTRL,
PCTRL_CMD_SILON, 1, &p1);
@@ -1177,6 +1178,7 @@ setup_pump(struct isar_ch *ch) {
send_mbox(ch->is, dps | ISAR_HIS_PUMPCFG,
PMOD_DTMF, 1, param);
}
+ /* fall through */
case ISDN_P_B_MODEM_ASYNC:
ctrl = PMOD_DATAMODEM;
if (test_bit(FLG_ORIGIN, &ch->bch.Flags)) {
@@ -1268,6 +1270,7 @@ setup_iom2(struct isar_ch *ch) {
case ISDN_P_B_MODEM_ASYNC:
case ISDN_P_B_T30_FAX:
cmsb |= IOM_CTRL_RCV;
+ /* fall through */
case ISDN_P_B_L2DTMF:
if (test_bit(FLG_DTMFSEND, &ch->bch.Flags))
cmsb |= IOM_CTRL_RCV;
@@ -1560,6 +1563,7 @@ isar_l2l1(struct mISDNchannel *ch, struct sk_buff *skb)
ich->is->name, hh->id);
ret = -EINVAL;
}
+ /* fall through */
default:
pr_info("%s: %s unknown prim(%x,%x)\n",
ich->is->name, __func__, hh->prim, hh->id);
diff --git a/drivers/isdn/hisax/avm_pci.c b/drivers/isdn/hisax/avm_pci.c
index a18b605..b161456 100644
--- a/drivers/isdn/hisax/avm_pci.c
+++ b/drivers/isdn/hisax/avm_pci.c
@@ -207,6 +207,7 @@ modehdlc(struct BCState *bcs, int mode, int bc)
bcs->mode = 1;
bcs->channel = bc;
bc = 0;
+ /* fall through */
case (L1_MODE_NULL):
if (bcs->mode == L1_MODE_NULL)
return;
diff --git a/drivers/isdn/hisax/callc.c b/drivers/isdn/hisax/callc.c
index ddec47a..5f43783 100644
--- a/drivers/isdn/hisax/callc.c
+++ b/drivers/isdn/hisax/callc.c
@@ -1369,6 +1369,7 @@ leased_l1l2(struct PStack *st, int pr, void *arg)
case (PH_ACTIVATE | INDICATION):
case (PH_ACTIVATE | CONFIRM):
event = EV_LEASED;
+ /* fall through */
case (PH_DEACTIVATE | INDICATION):
case (PH_DEACTIVATE | CONFIRM):
if (test_bit(FLG_TWO_DCHAN, &chanp->cs->HW_Flags))
diff --git a/drivers/isdn/hisax/config.c b/drivers/isdn/hisax/config.c
index 7108bdb8..fcc9c46 100644
--- a/drivers/isdn/hisax/config.c
+++ b/drivers/isdn/hisax/config.c
@@ -1843,6 +1843,7 @@ static void hisax_b_l2l1(struct PStack *st, int pr, void *arg)
case PH_DEACTIVATE | REQUEST:
test_and_clear_bit(BC_FLG_BUSY, &bcs->Flag);
skb_queue_purge(&bcs->squeue);
+ /* fall through */
default:
B_L2L1(b_if, pr, arg);
break;
diff --git a/drivers/isdn/hisax/gazel.c b/drivers/isdn/hisax/gazel.c
index 35c6df6..a6d8af0 100644
--- a/drivers/isdn/hisax/gazel.c
+++ b/drivers/isdn/hisax/gazel.c
@@ -108,6 +108,7 @@ ReadISAC(struct IsdnCardState *cs, u_char offset)
switch (cs->subtyp) {
case R647:
off2 = ((off2 << 8 & 0xf000) | (off2 & 0xf));
+ /* fall through */
case R685:
return (readreg(cs->hw.gazel.isac, off2));
case R753:
@@ -125,6 +126,7 @@ WriteISAC(struct IsdnCardState *cs, u_char offset, u_char value)
switch (cs->subtyp) {
case R647:
off2 = ((off2 << 8 & 0xf000) | (off2 & 0xf));
+ /* fall through */
case R685:
writereg(cs->hw.gazel.isac, off2, value);
break;
@@ -203,6 +205,7 @@ ReadHSCX(struct IsdnCardState *cs, int hscx, u_char offset)
switch (cs->subtyp) {
case R647:
off2 = ((off2 << 8 & 0xf000) | (off2 & 0xf));
+ /* fall through */
case R685:
return (readreg(cs->hw.gazel.hscx[hscx], off2));
case R753:
@@ -220,6 +223,7 @@ WriteHSCX(struct IsdnCardState *cs, int hscx, u_char offset, u_char value)
switch (cs->subtyp) {
case R647:
off2 = ((off2 << 8 & 0xf000) | (off2 & 0xf));
+ /* fall through */
case R685:
writereg(cs->hw.gazel.hscx[hscx], off2, value);
break;
diff --git a/drivers/isdn/hisax/isar.c b/drivers/isdn/hisax/isar.c
index d01ff11..82c1879 100644
--- a/drivers/isdn/hisax/isar.c
+++ b/drivers/isdn/hisax/isar.c
@@ -1089,6 +1089,7 @@ isar_pump_statev_fax(struct BCState *bcs, u_char devt) {
break;
case PCTRL_CMD_FTM:
p1 = 2;
+ /* fall through */
case PCTRL_CMD_FTH:
sendmsg(cs, dps | ISAR_HIS_PUMPCTRL,
PCTRL_CMD_SILON, 1, &p1);
@@ -1097,6 +1098,7 @@ isar_pump_statev_fax(struct BCState *bcs, u_char devt) {
case PCTRL_CMD_FRM:
if (frm_extra_delay)
mdelay(frm_extra_delay);
+ /* fall through */
case PCTRL_CMD_FRH:
p1 = bcs->hw.isar.mod = bcs->hw.isar.newmod;
bcs->hw.isar.newmod = 0;
diff --git a/drivers/isdn/hisax/l3_1tr6.c b/drivers/isdn/hisax/l3_1tr6.c
index da0a1c6..98f60d1 100644
--- a/drivers/isdn/hisax/l3_1tr6.c
+++ b/drivers/isdn/hisax/l3_1tr6.c
@@ -88,6 +88,7 @@ l3_1tr6_setup_req(struct l3_process *pc, u_char pr, void *arg)
break;
case 'C':
channel = 0x08;
+ /* fall through */
case 'P':
channel |= 0x80;
teln++;
diff --git a/drivers/isdn/hisax/l3dss1.c b/drivers/isdn/hisax/l3dss1.c
index 18a3484..368d152 100644
--- a/drivers/isdn/hisax/l3dss1.c
+++ b/drivers/isdn/hisax/l3dss1.c
@@ -1282,6 +1282,7 @@ l3dss1_setup_req(struct l3_process *pc, u_char pr,
switch (0x5f & *teln) {
case 'C':
channel = 0x08;
+ /* fall through */
case 'P':
channel |= 0x80;
teln++;
diff --git a/drivers/isdn/hysdn/hysdn_boot.c b/drivers/isdn/hysdn/hysdn_boot.c
index 4a04253..ba177c3 100644
--- a/drivers/isdn/hysdn/hysdn_boot.c
+++ b/drivers/isdn/hysdn/hysdn_boot.c
@@ -99,6 +99,7 @@ pof_handle_data(hysdn_card *card, int datlen)
case TAG_CBOOTDTA:
DecryptBuf(boot, datlen); /* we need to encrypt the buffer */
+ /* fall through */
case TAG_BOOTDTA:
if (card->debug_flags & LOG_POF_RECORD)
hysdn_addlog(card, "POF got %s len=%d offs=0x%lx",
@@ -137,6 +138,7 @@ pof_handle_data(hysdn_card *card, int datlen)
case TAG_CABSDATA:
DecryptBuf(boot, datlen); /* we need to encrypt the buffer */
+ /* fall through */
case TAG_ABSDATA:
if (card->debug_flags & LOG_POF_RECORD)
hysdn_addlog(card, "POF got %s len=%d offs=0x%lx",
diff --git a/drivers/isdn/i4l/isdn_v110.c b/drivers/isdn/i4l/isdn_v110.c
index 8b74ce4..2a5f666 100644
--- a/drivers/isdn/i4l/isdn_v110.c
+++ b/drivers/isdn/i4l/isdn_v110.c
@@ -354,6 +354,7 @@ EncodeMatrix(unsigned char *buf, int len, unsigned char *m, int mlen)
printk(KERN_WARNING "isdn_v110 (EncodeMatrix): buffer full!\n");
return line;
}
+ /* else: fall through */
case 128:
m[line] = 128; /* leftmost -> set byte to 1000000 */
mbit = 64; /* current bit in the matrix line */
@@ -386,20 +387,28 @@ EncodeMatrix(unsigned char *buf, int len, unsigned char *m, int mlen)
switch (++line % 10) {
case 1:
m[line++] = 0xfe;
+ /* fall through */
case 2:
m[line++] = 0xfe;
+ /* fall through */
case 3:
m[line++] = 0xfe;
+ /* fall through */
case 4:
m[line++] = 0xfe;
+ /* fall through */
case 5:
m[line++] = 0xbf;
+ /* fall through */
case 6:
m[line++] = 0xfe;
+ /* fall through */
case 7:
m[line++] = 0xfe;
+ /* fall through */
case 8:
m[line++] = 0xfe;
+ /* fall through */
case 9:
m[line++] = 0xfe;
}
diff --git a/drivers/isdn/mISDN/stack.c b/drivers/isdn/mISDN/stack.c
index 422dced..d97c6dd 100644
--- a/drivers/isdn/mISDN/stack.c
+++ b/drivers/isdn/mISDN/stack.c
@@ -539,6 +539,7 @@ create_l2entity(struct mISDNdevice *dev, struct mISDNchannel *ch,
rq.protocol = ISDN_P_NT_S0;
if (dev->Dprotocols & (1 << ISDN_P_NT_E1))
rq.protocol = ISDN_P_NT_E1;
+ /* fall through */
case ISDN_P_LAPD_TE:
ch->recv = mISDN_queue_message;
ch->peer = &dev->D.st->own;
--
2.7.4
^ permalink raw reply related
* pull-request: bpf-next 2018-07-03
From: Daniel Borkmann @ 2018-07-03 21:18 UTC (permalink / raw)
To: davem; +Cc: daniel, ast, netdev
Hi David,
The following pull-request contains BPF updates for your *net-next* tree.
The main changes are:
1) Various improvements to bpftool and libbpf, that is, bpftool build
speed improvements, missing BPF program types added for detection
by section name, ability to load programs from '.text' section is
made to work again, and better bash completion handling, from Jakub.
2) Improvements to nfp JIT's map read handling which allows for optimizing
memcpy from map to packet, from Jiong.
3) New BPF sample is added which demonstrates XDP in combination with
bpf_perf_event_output() helper to sample packets on all CPUs, from Toke.
4) Add a new BPF kselftest case for tracking connect(2) BPF hooks
infrastructure in combination with TFO, from Andrey.
5) Extend the XDP/BPF xdp_rxq_info sample code with a cmdline option to
read payload from packet data in order to use it for benchmarking.
Also for '--action XDP_TX' option implement swapping of MAC addresses
to avoid drops on some hardware seen during testing, from Jesper.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit b1a5046b2497e39cea9eb585358f3749442fb3f7:
Merge branch 'Multipath-tests-for-tunnel-devices' (2018-06-27 10:42:13 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
for you to fetch changes up to 0b9e3d543f9fa6a8abdac04f974176ee02312860:
Merge branch 'bpf-bpftool-libbpf-improvements' (2018-07-01 01:01:52 +0200)
----------------------------------------------------------------
Andrey Ignatov (1):
selftests/bpf: Test sys_connect BPF hooks with TFO
Daniel Borkmann (1):
Merge branch 'bpf-bpftool-libbpf-improvements'
Jakub Kicinski (8):
tools: bpftool: use correct make variable type to improve compilation time
tools: libbpf: add section names for missing program types
tools: libbpf: allow setting ifindex for programs and maps
tools: libbpf: restore the ability to load programs from .text section
tools: libbpf: don't return '.text' as a program for multi-function programs
tools: bpftool: drop unnecessary Author comments
tools: bpftool: add missing --bpffs to completions
tools: bpftool: deal with options upfront
Jesper Dangaard Brouer (2):
samples/bpf: extend xdp_rxq_info to read packet payload
samples/bpf: xdp_rxq_info action XDP_TX must adjust MAC-addrs
Jiong Wang (1):
nfp: bpf: allow source ptr type be map ptr in memcpy optimization
Toke Høiland-Jørgensen (2):
trace_helpers.c: Add helpers to poll multiple perf FDs for events
samples/bpf: Add xdp_sample_pkts example
drivers/net/ethernet/netronome/nfp/bpf/jit.c | 5 +-
samples/bpf/Makefile | 4 +
samples/bpf/xdp_rxq_info_kern.c | 43 +++++++
samples/bpf/xdp_rxq_info_user.c | 45 ++++++-
samples/bpf/xdp_sample_pkts_kern.c | 66 +++++++++++
samples/bpf/xdp_sample_pkts_user.c | 169 +++++++++++++++++++++++++++
tools/bpf/bpftool/Makefile | 2 +-
tools/bpf/bpftool/bash-completion/bpftool | 32 +++--
tools/bpf/bpftool/common.c | 2 -
tools/bpf/bpftool/main.c | 4 +-
tools/bpf/bpftool/main.h | 2 -
tools/bpf/bpftool/map.c | 2 -
tools/bpf/bpftool/prog.c | 4 +-
tools/lib/bpf/libbpf.c | 49 ++++++--
tools/lib/bpf/libbpf.h | 2 +
tools/testing/selftests/bpf/test_sock_addr.c | 37 +++++-
tools/testing/selftests/bpf/trace_helpers.c | 48 +++++++-
tools/testing/selftests/bpf/trace_helpers.h | 4 +
18 files changed, 471 insertions(+), 49 deletions(-)
create mode 100644 samples/bpf/xdp_sample_pkts_kern.c
create mode 100644 samples/bpf/xdp_sample_pkts_user.c
^ permalink raw reply
* Re: [PATCH bpf] bpf: hash_map: decrement counter on error
From: Daniel Borkmann @ 2018-07-03 21:28 UTC (permalink / raw)
To: Alexei Starovoitov, Mauricio Vasquez; +Cc: Alexei Starovoitov, netdev
In-Reply-To: <20180703202849.dydvuwcc6bcvy57i@ast-mbp.dhcp.thefacebook.com>
On 07/03/2018 10:28 PM, Alexei Starovoitov wrote:
> On Sun, Jul 01, 2018 at 11:33:58AM -0500, Mauricio Vasquez wrote:
>> On 06/30/2018 06:20 PM, Daniel Borkmann wrote:
>>> On 06/29/2018 02:48 PM, Mauricio Vasquez B wrote:
>>>> Decrement the number of elements in the map in case the allocation
>>>> of a new node fails.
>>>>
>>>> Signed-off-by: Mauricio Vasquez B <mauricio.vasquez@polito.it>
>>> Thanks for the fix, Mauricio!
>>>
>>> Could you reply with a Fixes: tag in order to track the commit originally
>>> introducing this bug?
>>
>> Sure Daniel,
>>
>> Fixes: 6c9059817432 ("bpf: pre-allocate hash map elements")
>
> Good catch. Thanks for the fix.
> Acked-by: Alexei Starovoitov <ast@kernel.org>
Applied to bpf, thanks Mauricio!
^ permalink raw reply
* Re: BUG: unable to handle kernel (3)
From: syzbot @ 2018-07-03 21:30 UTC (permalink / raw)
To: akpm, bridge, coreteam, davem, fw, gregkh, hmclauchlan, kadlec,
kstewart, linux-kernel, linux-mm, netdev, netfilter-devel, pablo,
pombredanne, stephen, syzkaller-bugs, tglx
In-Reply-To: <000000000000e46d0a056d4c70ce@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 4ca559bbdeaf kmsan: fix assertions in IRQ entry/exit hooks.
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=13dafb20400000
kernel config: https://syzkaller.appspot.com/x/.config?x=848e40757852af3e
dashboard link: https://syzkaller.appspot.com/bug?extid=adfeaaee641dd4fdac43
compiler: clang version 7.0.0 (trunk 334104)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=15497384400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=123a42a4400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+adfeaaee641dd4fdac43@syzkaller.appspotmail.com
RDX: 0000000020000140 RSI: 0000000020000100 RDI: 00000000200000c0
RBP: 0000000000000000 R08: 00000000fffffffc R09: 0000000000000039
R10: 0000000000000311 R11: 0000000000000246 R12: 00007f00bc56bd80
R13: 00000000006dbc38 R14: 0000000000000006 R15: 0079656b5f676962
CPU: 1 PID: 4528 Comm: syz-executor237 Not tainted 4.17.0+ #17
BUG: unable to handle kernel
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
NULL pointer dereference at 0000000000000008
Call Trace:
PGD 800000019f3d5067 P4D 800000019f3d5067
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:113
PUD 19ce9d067
fail_dump lib/fault-inject.c:51 [inline]
should_fail+0x87b/0xab0 lib/fault-inject.c:149
PMD 0
__should_failslab+0x278/0x2a0 mm/failslab.c:32
Oops: 0000 [#1] SMP PTI
should_failslab+0x29/0x70 mm/slab_common.c:1522
Dumping ftrace buffer:
slab_pre_alloc_hook mm/slab.h:423 [inline]
slab_alloc_node mm/slub.c:2679 [inline]
__kmalloc_node+0x22f/0x1200 mm/slub.c:3859
(ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 4533 Comm: syz-executor237 Not tainted 4.17.0+ #17
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:map_vm_area+0x69/0x1f0 mm/vmalloc.c:1353
RSP: 0018:ffff8801c07df8b8 EFLAGS: 00010046
kmalloc_node include/linux/slab.h:554 [inline]
alloc_vmap_area+0x1e6/0x15a0 mm/vmalloc.c:420
RAX: ffffffff81b1e4bc RBX: 0000000000000000 RCX: ffff8801a8e58000
RDX: 0000000000000000 RSI: 8000000000000063 RDI: 0000000000000000
__get_vm_area_node+0x3a6/0x810 mm/vmalloc.c:1410
RBP: ffff8801c07df930 R08: 0000000000000000 R09: 0000000000000000
R10: ffffc900019fffff R11: 0000000000000000 R12: ffffffff8b58d000
get_vm_area_caller+0xdb/0xf0 mm/vmalloc.c:1456
R13: 0000000000000000 R14: 0000000000000008 R15: 0000000000000000
FS: 00007f00bc56c700(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 000000019e7d2000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
kmsan_vmap+0x79/0x1e0 mm/kmsan/kmsan.c:875
Call Trace:
vmap+0x3b2/0x4b0 mm/vmalloc.c:1661
kmsan_vmap+0x137/0x1e0 mm/kmsan/kmsan.c:888
vmap+0x3b2/0x4b0 mm/vmalloc.c:1661
big_key_alloc_buffer+0x638/0xa30 security/keys/big_key.c:188
big_key_preparse+0x20a/0xed0 security/keys/big_key.c:228
big_key_alloc_buffer+0x638/0xa30 security/keys/big_key.c:188
big_key_preparse+0x20a/0xed0 security/keys/big_key.c:228
key_create_or_update+0x7a6/0x1a80 security/keys/key.c:849
__do_sys_add_key security/keys/keyctl.c:122 [inline]
__se_sys_add_key+0x741/0x980 security/keys/keyctl.c:62
key_create_or_update+0x7a6/0x1a80 security/keys/key.c:849
__do_sys_add_key security/keys/keyctl.c:122 [inline]
__se_sys_add_key+0x741/0x980 security/keys/keyctl.c:62
__x64_sys_add_key+0x15d/0x1b0 security/keys/keyctl.c:62
__x64_sys_add_key+0x15d/0x1b0 security/keys/keyctl.c:62
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x63/0xe7
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:287
RIP: 0033:0x445dc9
entry_SYSCALL_64_after_hwframe+0x63/0xe7
RSP: 002b:00007f00bc58cd78 EFLAGS: 00000246
RIP: 0033:0x445dc9
RSP: 002b:00007f00bc56bd78 EFLAGS: 00000246
ORIG_RAX: 00000000000000f8
ORIG_RAX: 00000000000000f8
RAX: ffffffffffffffda RBX: 00000000006dbc24 RCX: 0000000000445dc9
RAX: ffffffffffffffda RBX: 00000000006dbc3c RCX: 0000000000445dc9
RDX: 0000000020000140 RSI: 0000000020000100 RDI: 00000000200000c0
RDX: 0000000020000140 RSI: 0000000020000100 RDI: 00000000200000c0
RBP: 0000000000000000 R08: 00000000fffffffc R09: 0000000000000039
RBP: 0000000000000000 R08: 00000000fffffffc R09: 0000000000000039
R10: 0000000000000311 R11: 0000000000000246 R12: 00007f00bc56bd80
R13: 00000000006dbc38 R14: 0000000000000006 R15: 0079656b5f676962
R10: 0000000000000311 R11: 0000000000000246 R12: 00007f00bc58cd80
Code:
R13: 00000000006dbc20 R14: 0000000000000005 R15: 0079656b5f676962
24
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
08 48 89 45 a0 41 8b 84 24 90 0c 00 00 89 45 cc 45 8b bc 24 88 0c 00 00 e8
54 fa b3 ff 4d 8d 75 08 48 85 db 0f 85 5b 01 00 00 <49> 8b 45 08 48 89 45
CPU: 1 PID: 4530 Comm: syz-executor237 Not tainted 4.17.0+ #17
a8 4c
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
89
Call Trace:
f7 e8
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:113
57
fail_dump lib/fault-inject.c:51 [inline]
should_fail+0x87b/0xab0 lib/fault-inject.c:149
bd
__should_failslab+0x278/0x2a0 mm/failslab.c:32
0e 00
should_failslab+0x29/0x70 mm/slab_common.c:1522
4d
slab_pre_alloc_hook mm/slab.h:423 [inline]
slab_alloc_node mm/slub.c:2679 [inline]
__kmalloc_node+0x22f/0x1200 mm/slub.c:3859
8d
75 18
48
RIP: map_vm_area+0x69/0x1f0 mm/vmalloc.c:1353 RSP: ffff8801c07df8b8
kmalloc_node include/linux/slab.h:554 [inline]
alloc_vmap_area+0x1e6/0x15a0 mm/vmalloc.c:420
CR2: 0000000000000008
---[ end trace 6c00f5bb0b95940c ]---
__get_vm_area_node+0x3a6/0x810 mm/vmalloc.c:1410
^ 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