* Re: bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers
From: Neil Horman @ 2018-09-27 13:23 UTC (permalink / raw)
To: Andrew Lunn
Cc: Chris Preimesberger, linville@tuxdriver.com,
netdev@vger.kernel.org
In-Reply-To: <20180926215812.GD1251@lunn.ch>
On Wed, Sep 26, 2018 at 11:58:12PM +0200, Andrew Lunn wrote:
> > When you run ethtool -m on this driver, the kernel calls mlx4_en_get_module_info
> > to determine the length of the eeprom, and that value will be either 256 or 512
> > bytes.
>
> So it sounds like QSFP modules using 8636 are not supported. You would
> expect a size to be one of 256, 384, 512 or 640.
>
> > Next it calls mlx4_en_get_module_eeprom, passing in that size 256 to actually
> > read the eeprom data, which in turn calls mlx4_get_module_info to fetch the data
> > from hardware, again, passing in 256 as the size for the first call (theres a
> > loop, but it will only get executed once in this scenario)
> >
> > mlx4_get_module_info then issues the appropriate mailbox commands to dump the
> > eeprom. Here it starts to go sideways. The mailbox buffer allocated for the
> > return data is of type mlx4_mad_ifc, which has some front matter information and
> > a data buffer that is 192 bytes long!
>
> Which suggests all SFP dumps are broken as well, not just QSFP.
>
No, not at all. Each driver that implements a get_eeprom ethtool method, is
capable of doing multiple reads at various offsets, and filling up the user
buffer with real data. The bug here is that the mellanox data structures are
not sized properly vis a vis the amount of eeprom data that user space might
expect, or more specifically that the driver isn't smart enough to do several
small reads to fill up the full sized request buffer
Neil
> Oh dear.
>
> Andrew
>
^ permalink raw reply
* Re: kernel 4.18.5 Realtek 8111G network adapter stops responding under high system load
From: David Arendt @ 2018-09-27 19:33 UTC (permalink / raw)
To: Heiner Kallweit, Maciej S. Szmigiero, Gabriel C,
Ortwin Glück
Cc: linux-kernel, nic_swsd, netdev
In-Reply-To: <968f03ee-a271-242b-d90a-5c70ea72ce3b@gmail.com>
Hi,
Heiner Kallweit's patch seems to resolve the problem. The machine was
under high disk and network io pressure today and networking was
perfectly stable.
Bye,
David Arendt
On 9/25/18 11:03 PM, Heiner Kallweit wrote:
> On 19.09.2018 06:12, David Arendt wrote:
>> Hi,
>>
>> Thanks for the patch.
>>
>> I just applied it and the TxConfig register now contains 0x4f000f80.
>> The next day will show if it really solves the problem.
>>
>> Thanks in advance,
>> David Arendt
>>
>> On 9/19/18 12:30 AM, Maciej S. Szmigiero wrote:
>>> Hi,
>>>
>>> On 18.09.2018 12:23, David Arendt wrote:
>>>> Hi,
>>>>
>>>> Today I had the network adapter problems again.
>>>> So the patch doesn't seem to change anything regarding this problem.
>>>> This week my time is unfortunately very limited, but I will try to
>>>> find some time next weekend to look a bit more into the issue.
>>> If the problem is caused by missing TXCFG_AUTO_FIFO bit in TxConfig,
>>> as the register difference would suggest, then you can try applying
>>> the following patch (hack) on top of 4.18.8 that is already patched
>>> with commit f74dd480cf4e:
>>> --- a/drivers/net/ethernet/realtek/r8169.c
>>> +++ b/drivers/net/ethernet/realtek/r8169.c
>>> @@ -5043,7 +5043,8 @@
>>> {
>>> /* Set DMA burst size and Interframe Gap Time */
>>> RTL_W32(tp, TxConfig, (TX_DMA_BURST << TxDMAShift) |
>>> - (InterFrameGap << TxInterFrameGapShift));
>>> + (InterFrameGap << TxInterFrameGapShift)
>>> + | TXCFG_AUTO_FIFO);
>>> }
>>>
>>> static void rtl_set_rx_max_size(struct rtl8169_private *tp)
>>>
>>> This hack will probably only work properly on RTL_GIGA_MAC_VER_40 or
>>> later NICs.
>>>
>>> Before running any tests please verify with "ethtool -d enp3s0" that
>>> TxConfig register now contains 0x4f000f80, as it did in the old,
>>> working driver version.
>>>
>>> If this does not help then a bisection will most likely be needed.
>>>
>>>> Thanks in advance,
>>>> David Arendt
>>> Maciej
>>
>>
> @Gabriel:
> Thanks for the hint, I wasn't fully aware of this thread.
> @Maciej:
> Thanks for the analysis.
>
> It seems that all chip versions from 34 (= RTL8168E-VL) with the
> exception of version 39 (= RTL8106E, first sub-version) need
> bit TXCFG_AUTO_FIFO.
>
> And indeed, due to reordering of calls this bit is overwritten.
> Following patch moves setting the bit from the chip-specific
> hw_start function to rtl_set_tx_config_registers().
>
> Whoever is hit by the issue and has the option to build a kernel,
> could you please test whether the patch fixes the issue for you?
>
> Thanks, Heiner
>
> ---
> drivers/net/ethernet/realtek/r8169.c | 20 ++++++++------------
> 1 file changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
> index f882be49f..ae8abe900 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -4514,9 +4514,14 @@ static void rtl8169_hw_reset(struct rtl8169_private *tp)
>
> static void rtl_set_tx_config_registers(struct rtl8169_private *tp)
> {
> - /* Set DMA burst size and Interframe Gap Time */
> - RTL_W32(tp, TxConfig, (TX_DMA_BURST << TxDMAShift) |
> - (InterFrameGap << TxInterFrameGapShift));
> + u32 val = TX_DMA_BURST << TxDMAShift |
> + InterFrameGap << TxInterFrameGapShift;
> +
> + if (tp->mac_version >= RTL_GIGA_MAC_VER_34 &&
> + tp->mac_version != RTL_GIGA_MAC_VER_39)
> + val |= TXCFG_AUTO_FIFO;
> +
> + RTL_W32(tp, TxConfig, val);
> }
>
> static void rtl_set_rx_max_size(struct rtl8169_private *tp)
> @@ -5011,7 +5016,6 @@ static void rtl_hw_start_8168e_2(struct rtl8169_private *tp)
>
> rtl_disable_clock_request(tp);
>
> - RTL_W32(tp, TxConfig, RTL_R32(tp, TxConfig) | TXCFG_AUTO_FIFO);
> RTL_W8(tp, MCU, RTL_R8(tp, MCU) & ~NOW_IS_OOB);
>
> /* Adjust EEE LED frequency */
> @@ -5045,7 +5049,6 @@ static void rtl_hw_start_8168f(struct rtl8169_private *tp)
>
> rtl_disable_clock_request(tp);
>
> - RTL_W32(tp, TxConfig, RTL_R32(tp, TxConfig) | TXCFG_AUTO_FIFO);
> RTL_W8(tp, MCU, RTL_R8(tp, MCU) & ~NOW_IS_OOB);
> RTL_W8(tp, DLLPR, RTL_R8(tp, DLLPR) | PFM_EN);
> RTL_W32(tp, MISC, RTL_R32(tp, MISC) | PWM_EN);
> @@ -5090,8 +5093,6 @@ static void rtl_hw_start_8411(struct rtl8169_private *tp)
>
> static void rtl_hw_start_8168g(struct rtl8169_private *tp)
> {
> - RTL_W32(tp, TxConfig, RTL_R32(tp, TxConfig) | TXCFG_AUTO_FIFO);
> -
> rtl_eri_write(tp, 0xc8, ERIAR_MASK_0101, 0x080002, ERIAR_EXGMAC);
> rtl_eri_write(tp, 0xcc, ERIAR_MASK_0001, 0x38, ERIAR_EXGMAC);
> rtl_eri_write(tp, 0xd0, ERIAR_MASK_0001, 0x48, ERIAR_EXGMAC);
> @@ -5189,8 +5190,6 @@ static void rtl_hw_start_8168h_1(struct rtl8169_private *tp)
> rtl_hw_aspm_clkreq_enable(tp, false);
> rtl_ephy_init(tp, e_info_8168h_1, ARRAY_SIZE(e_info_8168h_1));
>
> - RTL_W32(tp, TxConfig, RTL_R32(tp, TxConfig) | TXCFG_AUTO_FIFO);
> -
> rtl_eri_write(tp, 0xc8, ERIAR_MASK_0101, 0x00080002, ERIAR_EXGMAC);
> rtl_eri_write(tp, 0xcc, ERIAR_MASK_0001, 0x38, ERIAR_EXGMAC);
> rtl_eri_write(tp, 0xd0, ERIAR_MASK_0001, 0x48, ERIAR_EXGMAC);
> @@ -5273,8 +5272,6 @@ static void rtl_hw_start_8168ep(struct rtl8169_private *tp)
> {
> rtl8168ep_stop_cmac(tp);
>
> - RTL_W32(tp, TxConfig, RTL_R32(tp, TxConfig) | TXCFG_AUTO_FIFO);
> -
> rtl_eri_write(tp, 0xc8, ERIAR_MASK_0101, 0x00080002, ERIAR_EXGMAC);
> rtl_eri_write(tp, 0xcc, ERIAR_MASK_0001, 0x2f, ERIAR_EXGMAC);
> rtl_eri_write(tp, 0xd0, ERIAR_MASK_0001, 0x5f, ERIAR_EXGMAC);
> @@ -5596,7 +5593,6 @@ static void rtl_hw_start_8402(struct rtl8169_private *tp)
> /* Force LAN exit from ASPM if Rx/Tx are not idle */
> RTL_W32(tp, FuncEvent, RTL_R32(tp, FuncEvent) | 0x002800);
>
> - RTL_W32(tp, TxConfig, RTL_R32(tp, TxConfig) | TXCFG_AUTO_FIFO);
> RTL_W8(tp, MCU, RTL_R8(tp, MCU) & ~NOW_IS_OOB);
>
> rtl_ephy_init(tp, e_info_8402, ARRAY_SIZE(e_info_8402));
^ permalink raw reply
* Re: [PATCH v2 net-next 0/2] Add support for Microchip Technology KSZ9131 10/100/1000 Ethernet PHY
From: Florian Fainelli @ 2018-09-27 19:28 UTC (permalink / raw)
To: Yuiko Oshino, davem, robh+dt, devicetree, andrew
Cc: linux-kernel, mark.rutland, m.felsch, Markus.Niebel, netdev,
UNGLinuxDriver
In-Reply-To: <1538079344-6152-1-git-send-email-yuiko.oshino@microchip.com>
On 09/27/2018 01:15 PM, Yuiko Oshino wrote:
> This is the initial driver for Microchip KSZ9131 10/100/1000 Ethernet PHY
>
> v2:
> - Creating a series from two related patches.
When people give you Acked-by or Reviewed-by tags in prior versions, it
is usually a good practice to add them to your next version of the
patch submission. Also, your patches 1 and 2 did not show up as as reply
to this cover letter, while they should, please fix this if you ever
need to submit new patches in the future.
Thank you!
>
> Yuiko Oshino (2):
> net: phy: micrel: add Microchip KSZ9131 inital driver
> dt-bindings: net: add support for Microchip KSZ9131 Ethernet PHY
>
> .../devicetree/bindings/net/micrel-ksz90x1.txt | 29 +++++++++++++++++++-
> drivers/net/phy/micrel.c | 32 ++++++++++++++++++++--
> include/linux/micrel_phy.h | 1 +
> 3 files changed, 58 insertions(+), 4 deletions(-)
>
--
Florian
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: test_bpf: add dummy dev->net for flow_dissector
From: Eric Dumazet @ 2018-09-27 12:58 UTC (permalink / raw)
To: Song Liu, netdev; +Cc: daniel, kernel-team, Willem de Bruijn, Petar Penkov
In-Reply-To: <20180927071533.2290229-1-songliubraving@fb.com>
On 09/27/2018 12:15 AM, Song Liu wrote:
> Latest changes in __skb_flow_dissect() assume skb->dev has valid nd_net.
> However, this is not true for test_bpf. As a result, test_bpf.ko crashes
> the system with the following stack trace:
>
> + dev_net_set(&dev, &net);
This is yet another fake stuff that will break some day, so many other things would
need to be setup properly in a real "struct net"
What about using the current net_ns ?
dev_net_set(&dev, current->nsproxy->net_ns);
This might be &init_net in the context of test_bpf(), so maybe simply use &init_net
to clearly state that test_bpf is not net ns fully ready.
> + RCU_INIT_POINTER(net.flow_dissector_prog, NULL);
This really was not needed. Everything is already zero.
> skb->dev = &dev;
> skb->dev->ifindex = SKB_DEV_IFINDEX;
> skb->dev->type = SKB_DEV_TYPE;
>
^ permalink raw reply
* Re: re iproute2 - don't return error on success fix
From: Phil Sutter @ 2018-09-27 12:53 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Stephen Hemminger, David Ahern, Linux Netdev List, Roi Dayan
In-Reply-To: <CAJ3xEMiasPrGAQkY=uVxCaFG_An1cm+emJCc6jr76=xuLcQ=0Q@mail.gmail.com>
Hi,
On Thu, Sep 27, 2018 at 03:22:41PM +0300, Or Gerlitz wrote:
> Something is still broken also after commit b45e300 "libnetlink: don't
> return error on success" - when error is returned, the error code is
> success..
>
> $ tc filter add dev enp33s0f0 protocol ip parent ffff: flower skip_sw
> ip_flags nofirstfrag action drop && echo "success" || echo "failed"
>
> RTNETLINK answers: Operation not supported
> success
Hmm, I can't reproduce this. My HEAD is at the commit you mentioned:
| % sudo ./tc/tc filter add dev d0 protocol ip parent ffff: flower skip_sw ip_flags nofirstfrag action drop
| RTNETLINK answers: Operation not supported
| We have an error talking to the kernel, -1
| % echo $?
| 2
Are you sure you tested the right binary?
Cheers, Phil
^ permalink raw reply
* Re: [RFC PATCH iproute2-next V2] System specification exception API
From: Jiri Pirko @ 2018-09-27 12:47 UTC (permalink / raw)
To: Eran Ben Elisha
Cc: netdev, Jakub Kicinski, Jiri Pirko, Stephen Hemminger,
Andrew Lunn, Tobin C. Harding, Ariel Almog, Tal Alon
In-Reply-To: <1537962779-8910-1-git-send-email-eranbe@mellanox.com>
Wed, Sep 26, 2018 at 01:52:58PM CEST, eranbe@mellanox.com wrote:
>The exception spec is targeted for Real Time Alerting, in order to know when
>something bad had happened to a PCI device
>- Provide alert debug information
>- Self healing
>- If problem needs vendor support, provide a way to gather all needed debugging
> information.
>
>The exception mechanism contains condition checkers which sense for malfunction. Upon a condition hit,
>actions such as logs and correction can be taken.
>
>The condition checkers are divided into the following groups
>- Hardware - a checker which is triggered by the device due to
> malfunction.
>- Software - a checker which is triggered by the software due to
> malfunction.
What do you mean by a "software malfunction", a "FW malfunction"?
Also, I don't see this 2 groups in the man.
>Both groups of condition checkers can be triggered due to error event or due to a periodic check.
>
>Actions are the way to handle those events. Action can be in one of the
>following groups:
>- Dump - SW trace, SW dump, HW trace, HW dump
>- Reset - Surgical correction (e.g. modify Q, flush Q, reset of device, etc)
>Actions can be performed by SW or HW.
>
>User is allowed to enable or disable condition checkers and its action mapping.
>
>This RFC man page patch describes the suggested API of devlink-exception in order
>to control conditions and actions.
>
>V2:
>* Renaming terms:
> health -> exception
> sensor -> condition
>* Remove reinit command and merge with action command.
>* Consmetics in grammer.
>
>Eran Ben Elisha (1):
> man: Add devlink exception man page
>
> man/man8/devlink-exception.8 | 158 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 158 insertions(+)
> create mode 100644 man/man8/devlink-exception.8
>
>--
>1.8.3.1
>
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: b53: Fix build with B53_SRAB enabled and B53_SERDES=m
From: Florian Fainelli @ 2018-09-27 19:07 UTC (permalink / raw)
To: Arnd Bergmann, Andrew Lunn, Vivien Didelot, David S. Miller
Cc: netdev, linux-kernel
In-Reply-To: <20180927100244.692546-1-arnd@arndb.de>
On 09/27/2018 03:02 AM, Arnd Bergmann wrote:
> When B53_SERDES is a loadable module, a built-in srab driver still
> cannot reach it, so the previous fix is incomplete:
>
> b53_srab.c:(.text+0x3f4): undefined reference to `b53_serdes_init'
> drivers/net/dsa/b53/b53_srab.o:(.rodata+0xe64): undefined reference to `b53_serdes_link_state'
> drivers/net/dsa/b53/b53_srab.o:(.rodata+0xe74): undefined reference to `b53_serdes_link_set'
> drivers/net/dsa/b53/b53_srab.o:(.rodata+0xe88): undefined reference to `b53_serdes_an_restart'
> drivers/net/dsa/b53/b53_srab.o:(.rodata+0xea0): undefined reference to `b53_serdes_phylink_validate'
> drivers/net/dsa/b53/b53_srab.o:(.rodata+0xea4): undefined reference to `b53_serdes_config'
>
> Add a Kconfig dependency that forces srab to also be a module
> in this case, but allow it to be built-in when serdes is
> disabled or built-in.
>
> Fixes: 7a8c7f5c30f9 ("net: dsa: b53: Fix build with B53_SRAB enabled and not B53_SERDES")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Thanks!
--
Florian
^ permalink raw reply
* Re: re iproute2 - don't return error on success fix
From: Stephen Hemminger @ 2018-09-27 12:39 UTC (permalink / raw)
To: Or Gerlitz; +Cc: David Ahern, Linux Netdev List, Roi Dayan
In-Reply-To: <CAJ3xEMiasPrGAQkY=uVxCaFG_An1cm+emJCc6jr76=xuLcQ=0Q@mail.gmail.com>
On Thu, 27 Sep 2018 15:22:41 +0300
Or Gerlitz <gerlitz.or@gmail.com> wrote:
> Something is still broken also after commit b45e300 "libnetlink: don't
> return error on success" - when error is returned, the error code is
> success..
>
> $ tc filter add dev enp33s0f0 protocol ip parent ffff: flower skip_sw
> ip_flags nofirstfrag action drop && echo "success" || echo "failed"
>
Yes this looks broken. Let me check.
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: test_bpf: add dummy dev->net for flow_dissector
From: Eric Dumazet @ 2018-09-27 12:36 UTC (permalink / raw)
To: Song Liu, netdev; +Cc: daniel, kernel-team, Willem de Bruijn, Petar Penkov
In-Reply-To: <20180927071533.2290229-1-songliubraving@fb.com>
On 09/27/2018 12:15 AM, Song Liu wrote:
> Latest changes in __skb_flow_dissect() assume skb->dev has valid nd_net.
> However, this is not true for test_bpf. As a result, test_bpf.ko crashes
> the system with the following stack trace:
>
>
> This patch fixes tes_bpf by adding a dummy struct net to the dummy dev.
>
> Fixes: d0e13a1488ad ("flow_dissector: lookup netns by skb->sk if skb->dev is NULL")
> Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook")
> Cc: Willem de Bruijn <willemb@google.com>
> Cc: Petar Penkov <ppenkov@google.com>
> Signed-off-by: Song Liu <songliubraving@fb.com>
Reported-by: Eric Dumazet <edumazet@google.com>
Thanks.
^ permalink raw reply
* re iproute2 - don't return error on success fix
From: Or Gerlitz @ 2018-09-27 12:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Ahern, Linux Netdev List, Roi Dayan
Something is still broken also after commit b45e300 "libnetlink: don't
return error on success" - when error is returned, the error code is
success..
$ tc filter add dev enp33s0f0 protocol ip parent ffff: flower skip_sw
ip_flags nofirstfrag action drop && echo "success" || echo "failed"
RTNETLINK answers: Operation not supported
success
^ permalink raw reply
* [PATCH] dt-bindings: can: rcar_can: Add r8a7744 support
From: Biju Das @ 2018-09-27 12:08 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde, Rob Herring, Mark Rutland
Cc: Biju Das, David S. Miller, linux-can, netdev, devicetree,
Simon Horman, Geert Uytterhoeven, Chris Paterson, Fabrizio Castro,
linux-renesas-soc
Document RZ/G1N (r8a7744) SoC specific bindings.
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com>
---
This patch is tested against linux-next next-20180927
---
Documentation/devicetree/bindings/net/can/rcar_can.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
index 94a7f33..cc43728 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
@@ -3,6 +3,7 @@ Renesas R-Car CAN controller Device Tree Bindings
Required properties:
- compatible: "renesas,can-r8a7743" if CAN controller is a part of R8A7743 SoC.
+ "renesas,can-r8a7744" if CAN controller is a part of R8A7744 SoC.
"renesas,can-r8a7745" if CAN controller is a part of R8A7745 SoC.
"renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC.
"renesas,can-r8a7779" if CAN controller is a part of R8A7779 SoC.
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel
From: Eric Biggers @ 2018-09-27 18:29 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: linux-kernel, netdev, linux-crypto, davem, gregkh
In-Reply-To: <20180925145622.29959-1-Jason@zx2c4.com>
On Tue, Sep 25, 2018 at 04:55:59PM +0200, Jason A. Donenfeld wrote:
>
> It is intended that this entire patch series enter the kernel through
> DaveM's net-next tree. Subsequently, WireGuard patches will go through
> DaveM's net-next tree, while Zinc patches will go through Greg KH's tree.
>
Why is Herbert Xu's existing crypto tree being circumvented, especially for
future patches (the initial merge isn't quite as important as that's a one-time
event)? I like being able to check out cryptodev to test upcoming crypto
patches. And currently, changes to APIs, algorithms, tests, and implementations
all go through cryptodev, which is convenient for crypto developers.
Apparently, you're proposing that someone adding a new algorithm will now have
to submit the API portion to one maintainer (Herbert Xu) and the implementation
portion to another maintainer (you), and they'll go through separate git trees.
That's inconvenient for developers, and it seems that in practice you and
Herbert will be stepping on each other's toes a lot.
Can you please reach some kind of sane agreement with Herbert so that the
development process isn't fractured into two? Perhaps you could review patches,
but Herbert could still apply them?
I'm also wondering about the criteria for making additions and changes to
"Zinc". You mentioned before that one of the "advantages" of Zinc is that it
doesn't include "cipher modes from 90s cryptographers" -- what does that mean
exactly? You've also indicated before that you don't want people modifying the
Poly1305 implementations as they are too error-prone. Yet apparently it's fine
to change them yourself, e.g. when you added the part that converts the
accumulator from base 26 to base 32. I worry there may be double standards
here, and useful contributions could be blocked or discouraged in the future.
Can you please elaborate on your criteria for contributions to Zinc?
Also, will you allow algorithms that aren't up to modern security standards but
are needed for compatibility reasons, e.g. MD5, SHA-1, and DES? There are
existing standards, APIs, and data formats that use these "legacy" algorithms;
so implementations of them are often still needed, whether we like it or not.
And does it matter who designed the algorithms, e.g. do algorithms from Daniel
Bernstein get effectively a free pass, while algorithms from certain countries,
governments, or organizations are not allowed? E.g. wireless driver developers
may need the SM4 block cipher (which is now supported by the crypto API) as it's
specified in a Chinese wireless standard. Will you allow SM4 in Zinc? Or will
people have to submit some algorithms to Herbert and some to you due to
disagreements about what algorithms should be included?
- Eric
^ permalink raw reply
* [PATCH net-next] net: bridge: explicitly zero is_sticky in fdb_create
From: Nikolay Aleksandrov @ 2018-09-27 12:05 UTC (permalink / raw)
To: netdev; +Cc: roopa, davem, stephen, bridge, Nikolay Aleksandrov
We need to explicitly zero is_sticky when creating a new fdb, otherwise
we might get a stale value for a new entry.
Fixes: 435f2e7cc0b7 ("net: bridge: add support for sticky fdb entries")
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
net/bridge/br_fdb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index a56ed7f2a3a3..74331690a390 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -504,6 +504,7 @@ static struct net_bridge_fdb_entry *fdb_create(struct net_bridge *br,
fdb->added_by_user = 0;
fdb->added_by_external_learn = 0;
fdb->offloaded = 0;
+ fdb->is_sticky = 0;
fdb->updated = fdb->used = jiffies;
if (rhashtable_lookup_insert_fast(&br->fdb_hash_tbl,
&fdb->rhnode,
--
2.11.0
^ permalink raw reply related
* Re: KASAN: use-after-free Read in tcf_block_find
From: Dmitry Vyukov @ 2018-09-27 18:04 UTC (permalink / raw)
To: Cong Wang
Cc: Eric Dumazet, syzbot+37b8770e6d5a8220a039, David Miller,
Jamal Hadi Salim, Jiri Pirko, LKML,
Linux Kernel Network Developers, syzkaller-bugs
In-Reply-To: <CAM_iQpUpe5J30_aOzDUHrxiC7hXyQfH6-R7TM_L==gkj_XTu5w@mail.gmail.com>
On Thu, Sep 27, 2018 at 7:50 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Thu, Sep 27, 2018 at 1:11 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>>
>> Would a stack trace for call_rcu be helpful here? I have this idea for
>> a long time, but never get around to implementing it:
>> https://bugzilla.kernel.org/show_bug.cgi?id=198437
>
> Yes. Generally speaking, showing backtrace of call_rcu()
> or schedule_work(0 etc. is very helpful, we are more interested
> in who calls call_rcu() than what that RCU callback does.
>
> BTW, yesterday I asked syzbot to test this:
> https://github.com/congwang/linux/commit/b7815584cf1c0bbb79e8f6fe3e4b66ba10375560
> I still don't get any result.
I see that test job. It's in some dead loop, now trying to run for 37'th time.
I've just pushed a fix a bug that could have caused it (fuzzing the
fuzzer, we should go deeper!):
https://github.com/google/syzkaller/commit/98b28ead6ceaf22064b9715cc1950848d2bdef0b
If it won't help, I will take a look tomorrow.
> For this specific bug, we should hold a refcnt in dev->qdisc, I don't
> even see how call_rcu() could be invoked, unless of course we mess
> up with qdisc refcnt.
^ permalink raw reply
* [PATCH net-next 7/7] rtnetlink: enable RTM_GETADDR2
From: Christian Brauner @ 2018-09-27 17:58 UTC (permalink / raw)
To: jbenc, davem, dsahern, stephen, netdev, linux-kernel; +Cc: Christian Brauner
In-Reply-To: <20180927175857.3511-1-christian@brauner.io>
Various userspace programs (e.g. iproute2) have sent RTM_GETADDR
requests with struct ifinfomsg. This is wrong and should have been
struct ifaddrmsg all along as mandated by the manpages. However, dump
requests so far didn't parse the netlink message that was sent and
succeeded even when a wrong struct was passed along.
Currently, the message is parsed under the assumption that the correct
struct ifaddrmsg is sent down. If the parsing fails the kernel will
still fulfill the request to preserve backwards compatability but a
rate-limited message that there were leftover bytes after parsing the
message is recorded in dmesg. It has been argued that this is
unacceptable [1].
But various new features that got and will get added to RTM_GETADDR make
it necessary to definitely know what header was passed along.
This is currently not possible without resorting to (likely unreliable)
hacks such as introducing a nested attribute that ensures that
RTM_GETADDR which pass along properties such as IFA_TARGET_NETNSID
always exceed RTM_GETADDR requests that send down the wrong struct
ifinfomsg [2]. Basically, multiple approaches to solve this have been
shut down. Furthermore, the API expressed via RTM_GETADDR is apparently
frozen [3] so the wiggle room at this point seems very much zero.
The correct solution at this point seems to me to introduce a new
RTM_GETADDR2 request. This way we can parse the message and fail hard if
the struct is not struct ifaddrmsg and can safely extend it in the
future. Userspace tools that rely on the buggy RTM_GETADDR API will
still keep working without even having to see any log messages and new
userspace tools that want to make user of new features can make use of
the new RTM_GETADDR2 requests.
[1]: https://lists.openwall.net/netdev/2018/09/25/59
[2]: https://lists.openwall.net/netdev/2018/09/25/75
[3]: https://lists.openwall.net/netdev/2018/09/26/166
Signed-off-by: Christian Brauner <christian@brauner.io>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Benc <jbenc@redhat.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
---
net/core/rtnetlink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 35162e1b06ad..2ec020236053 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -4835,6 +4835,7 @@ void __init rtnetlink_init(void)
rtnl_register(PF_UNSPEC, RTM_DELLINK, rtnl_dellink, NULL, 0);
rtnl_register(PF_UNSPEC, RTM_GETADDR, NULL, rtnl_dump_all, 0);
+ rtnl_register(PF_UNSPEC, RTM_GETADDR2, NULL, rtnl_dump_all, 0);
rtnl_register(PF_UNSPEC, RTM_GETROUTE, NULL, rtnl_dump_all, 0);
rtnl_register(PF_UNSPEC, RTM_GETNETCONF, NULL, rtnl_dump_all, 0);
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 5/7] phonet: add RTM_GETADDR2
From: Christian Brauner @ 2018-09-27 17:58 UTC (permalink / raw)
To: jbenc, davem, dsahern, stephen, netdev, linux-kernel; +Cc: Christian Brauner
In-Reply-To: <20180927175857.3511-1-christian@brauner.io>
Various userspace programs (e.g. iproute2) have sent RTM_GETADDR
requests with struct ifinfomsg. This is wrong and should have been
struct ifaddrmsg all along as mandated by the manpages. However, dump
requests so far didn't parse the netlink message that was sent and
succeeded even when a wrong struct was passed along.
Currently, the message is parsed under the assumption that the correct
struct ifaddrmsg is sent down. If the parsing fails the kernel will
still fulfill the request to preserve backwards compatability but a
rate-limited message that there were leftover bytes after parsing the
message is recorded in dmesg. It has been argued that this is
unacceptable [1].
But various new features that got and will get added to RTM_GETADDR make
it necessary to definitely know what header was passed along.
This is currently not possible without resorting to (likely unreliable)
hacks such as introducing a nested attribute that ensures that
RTM_GETADDR which pass along properties such as IFA_TARGET_NETNSID
always exceed RTM_GETADDR requests that send down the wrong struct
ifinfomsg [2]. Basically, multiple approaches to solve this have been
shut down. Furthermore, the API expressed via RTM_GETADDR is apparently
frozen [3] so the wiggle room at this point seems very much zero.
The correct solution at this point seems to me to introduce a new
RTM_GETADDR2 request. This way we can parse the message and fail hard if
the struct is not struct ifaddrmsg and can safely extend it in the
future. Userspace tools that rely on the buggy RTM_GETADDR API will
still keep working without even having to see any log messages and new
userspace tools that want to make user of new features can make use of
the new RTM_GETADDR2 requests.
[1]: https://lists.openwall.net/netdev/2018/09/25/59
[2]: https://lists.openwall.net/netdev/2018/09/25/75
[3]: https://lists.openwall.net/netdev/2018/09/26/166
Signed-off-by: Christian Brauner <christian@brauner.io>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Benc <jbenc@redhat.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
---
net/phonet/pn_netlink.c | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/net/phonet/pn_netlink.c b/net/phonet/pn_netlink.c
index 871eaf2cb85e..acba4fe9a612 100644
--- a/net/phonet/pn_netlink.c
+++ b/net/phonet/pn_netlink.c
@@ -131,13 +131,22 @@ static int fill_addr(struct sk_buff *skb, struct net_device *dev, u8 addr,
return -EMSGSIZE;
}
-static int getaddr_dumpit(struct sk_buff *skb, struct netlink_callback *cb)
+static int getaddr_dumpit_common(struct sk_buff *skb,
+ struct netlink_callback *cb, int rtm_type)
{
struct phonet_device_list *pndevs;
+ struct nlattr *tb[IFA_MAX+1];
struct phonet_device *pnd;
- int dev_idx = 0, dev_start_idx = cb->args[0];
+ int err, dev_idx = 0, dev_start_idx = cb->args[0];
int addr_idx = 0, addr_start_idx = cb->args[1];
+ if (rtm_type == RTM_GETADDR2) {
+ err = nlmsg_parse(cb->nlh, sizeof(struct ifaddrmsg), tb,
+ IFA_MAX, ifa_phonet_policy, NULL);
+ if (err < 0)
+ return err;
+ }
+
pndevs = phonet_device_list(sock_net(skb->sk));
rcu_read_lock();
list_for_each_entry_rcu(pnd, &pndevs->list, list) {
@@ -168,6 +177,16 @@ static int getaddr_dumpit(struct sk_buff *skb, struct netlink_callback *cb)
return skb->len;
}
+static int getaddr_dumpit(struct sk_buff *skb, struct netlink_callback *cb)
+{
+ return getaddr_dumpit_common(skb, cb, RTM_GETADDR);
+}
+
+static int getaddr_dumpit2(struct sk_buff *skb, struct netlink_callback *cb)
+{
+ return getaddr_dumpit_common(skb, cb, RTM_GETADDR2);
+}
+
/* Routes handling */
static int fill_route(struct sk_buff *skb, struct net_device *dev, u8 dst,
@@ -309,6 +328,8 @@ int __init phonet_netlink_register(void)
addr_doit, NULL, 0);
rtnl_register_module(THIS_MODULE, PF_PHONET, RTM_GETADDR,
NULL, getaddr_dumpit, 0);
+ rtnl_register_module(THIS_MODULE, PF_PHONET, RTM_GETADDR2,
+ NULL, getaddr_dumpit2, 0);
rtnl_register_module(THIS_MODULE, PF_PHONET, RTM_NEWROUTE,
route_doit, NULL, 0);
rtnl_register_module(THIS_MODULE, PF_PHONET, RTM_DELROUTE,
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 2/7] ipv4: add RTM_GETADDR2
From: Christian Brauner @ 2018-09-27 17:58 UTC (permalink / raw)
To: jbenc, davem, dsahern, stephen, netdev, linux-kernel; +Cc: Christian Brauner
In-Reply-To: <20180927175857.3511-1-christian@brauner.io>
Various userspace programs (e.g. iproute2) have sent RTM_GETADDR
requests with struct ifinfomsg. This is wrong and should have been
struct ifaddrmsg all along as mandated by the manpages. However, dump
requests so far didn't parse the netlink message that was sent and
succeeded even when a wrong struct was passed along.
Currently, the message is parsed under the assumption that the correct
struct ifaddrmsg is sent down. If the parsing fails the kernel will
still fulfill the request to preserve backwards compatability but a
rate-limited message that there were leftover bytes after parsing the
message is recorded in dmesg. It has been argued that this is
unacceptable [1].
But various new features that got and will get added to RTM_GETADDR make
it necessary to definitely know what header was passed along.
This is currently not possible without resorting to (likely unreliable)
hacks such as introducing a nested attribute that ensures that
RTM_GETADDR which pass along properties such as IFA_TARGET_NETNSID
always exceed RTM_GETADDR requests that send down the wrong struct
ifinfomsg [2]. Basically, multiple approaches to solve this have been
shut down. Furthermore, the API expressed via RTM_GETADDR is apparently
frozen [3] so the wiggle room at this point seems very much zero.
The correct solution at this point seems to me to introduce a new
RTM_GETADDR2 request. This way we can parse the message and fail hard if
the struct is not struct ifaddrmsg and can safely extend it in the
future. Userspace tools that rely on the buggy RTM_GETADDR API will
still keep working without even having to see any log messages and new
userspace tools that want to make user of new features can make use of
the new RTM_GETADDR2 requests.
[1]: https://lists.openwall.net/netdev/2018/09/25/59
[2]: https://lists.openwall.net/netdev/2018/09/25/75
[3]: https://lists.openwall.net/netdev/2018/09/26/166
Signed-off-by: Christian Brauner <christian@brauner.io>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Benc <jbenc@redhat.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
---
net/ipv4/devinet.c | 24 +++++++++++++++++++++---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 44d931a3cd50..3ac004ba67b0 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1659,7 +1659,8 @@ static int inet_fill_ifaddr(struct sk_buff *skb, struct in_ifaddr *ifa,
return -EMSGSIZE;
}
-static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
+static int inet_dump_ifaddr_common(struct sk_buff *skb,
+ struct netlink_callback *cb, int rtm_type)
{
struct inet_fill_args fillargs = {
.portid = NETLINK_CB(cb->skb).portid,
@@ -1683,8 +1684,14 @@ static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
s_idx = idx = cb->args[1];
s_ip_idx = ip_idx = cb->args[2];
- if (nlmsg_parse(cb->nlh, sizeof(struct ifaddrmsg), tb, IFA_MAX,
- ifa_ipv4_policy, NULL) >= 0) {
+ if (rtm_type == RTM_GETADDR2) {
+ int err;
+
+ err = nlmsg_parse(cb->nlh, sizeof(struct ifaddrmsg), tb,
+ IFA_MAX, ifa_ipv4_policy, NULL);
+ if (err < 0)
+ return err;
+
if (tb[IFA_TARGET_NETNSID]) {
fillargs.netnsid = nla_get_s32(tb[IFA_TARGET_NETNSID]);
@@ -1736,6 +1743,16 @@ static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
return skb->len;
}
+static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
+{
+ return inet_dump_ifaddr_common(skb, cb, RTM_GETADDR);
+}
+
+static int inet_dump_ifaddr2(struct sk_buff *skb, struct netlink_callback *cb)
+{
+ return inet_dump_ifaddr_common(skb, cb, RTM_GETADDR2);
+}
+
static void rtmsg_ifa(int event, struct in_ifaddr *ifa, struct nlmsghdr *nlh,
u32 portid)
{
@@ -2564,6 +2581,7 @@ void __init devinet_init(void)
rtnl_register(PF_INET, RTM_NEWADDR, inet_rtm_newaddr, NULL, 0);
rtnl_register(PF_INET, RTM_DELADDR, inet_rtm_deladdr, NULL, 0);
rtnl_register(PF_INET, RTM_GETADDR, NULL, inet_dump_ifaddr, 0);
+ rtnl_register(PF_INET, RTM_GETADDR2, NULL, inet_dump_ifaddr2, 0);
rtnl_register(PF_INET, RTM_GETNETCONF, inet_netconf_get_devconf,
inet_netconf_dump_devconf, 0);
}
--
2.17.1
^ permalink raw reply related
* Re: KASAN: use-after-free Read in tcf_block_find
From: Cong Wang @ 2018-09-27 17:50 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Eric Dumazet, syzbot+37b8770e6d5a8220a039, David Miller,
Jamal Hadi Salim, Jiri Pirko, LKML,
Linux Kernel Network Developers, syzkaller-bugs
In-Reply-To: <CACT4Y+YbQbZ7XTPK1HLvPiR9rmSm7Cz0H2LJAFfYfAta1Y3CiQ@mail.gmail.com>
On Thu, Sep 27, 2018 at 1:11 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> Would a stack trace for call_rcu be helpful here? I have this idea for
> a long time, but never get around to implementing it:
> https://bugzilla.kernel.org/show_bug.cgi?id=198437
Yes. Generally speaking, showing backtrace of call_rcu()
or schedule_work(0 etc. is very helpful, we are more interested
in who calls call_rcu() than what that RCU callback does.
BTW, yesterday I asked syzbot to test this:
https://github.com/congwang/linux/commit/b7815584cf1c0bbb79e8f6fe3e4b66ba10375560
I still don't get any result.
For this specific bug, we should hold a refcnt in dev->qdisc, I don't
even see how call_rcu() could be invoked, unless of course we mess
up with qdisc refcnt.
^ permalink raw reply
* Re: KMSAN: uninit-value in memcmp (2)
From: Dmitry Vyukov @ 2018-09-27 11:20 UTC (permalink / raw)
To: Vladis Dronov; +Cc: syzbot, syzkaller-bugs, LKML, Networking
In-Reply-To: <1439650590.16502818.1538047050900.JavaMail.zimbra@redhat.com>
On Thu, Sep 27, 2018 at 1:17 PM, Vladis Dronov <vdronov@redhat.com> wrote:
> Hello, Dmirty,
>
> Thank you for the explanation of how syzkaller/syzbot works in this and
> other emails. I understand that is it a complicated task to determine
> and categorize bugs based on just crash dump and messages, and syzkaller
> does a great job of doing so.
Thanks.
>> Re __hw_addr_add_ex bug, as Alex noted the crash was detected _after_
>> the fixing commit went in. So it's something new and different and
>> can't be fixed by the older commit.
>
> Indeed, you're right, there is another issue with tun/tap devices which
> leads to this bug. I've posted a patch (https://lkml.org/lkml/2018/9/26/416)
> to fix it.
>
> I hope I did not do much damage, reporting previous fix as a fix for this bug,
> as syzkaller will probably create another "KMSAN: uninit-value in <...>"
> report.
No, it did not do any damage.
This is in fact already re-reported as "KMSAN: uninit-value in __dev_mc_add":
https://syzkaller.appspot.com/bug?id=0766d38c656abeace60621896d705743aeefed51
> ----- Original Message -----
>> From: "Dmitry Vyukov" <dvyukov@google.com>
>> To: "Alexander Potapenko" <glider@google.com>
>> Cc: "Vladis Dronov" <vdronov@redhat.com>, "syzbot" <syzbot+d3402c47f680ff24b29c@syzkaller.appspotmail.com>,
>> "syzkaller-bugs" <syzkaller-bugs@googlegroups.com>, "David Miller" <davem@davemloft.net>, "Eric Dumazet"
>> <edumazet@google.com>, "LKML" <linux-kernel@vger.kernel.org>, "Networking" <netdev@vger.kernel.org>, "sunlianwen"
>> <sunlw.fnst@cn.fujitsu.com>
>> Sent: Monday, September 24, 2018 11:39:08 AM
>> Subject: Re: KMSAN: uninit-value in memcmp (2)
>>
>> On Mon, Sep 24, 2018 at 8:53 AM, Alexander Potapenko <glider@google.com>
>> wrote:
>> > On Mon, Sep 24, 2018 at 12:09 AM Vladis Dronov <vdronov@redhat.com> wrote:
>> >>
>> >> Hello, Dmirty,
>> >>
>> >> Thank you for the reply. Can we please, discuss this further?
>> > Hi Vladis,
>> >> > You can see on dashboard that the last crash
>> >> > for the second version (2) happened just few days ago. So this is a
>> >> > different bug.
>> > FWIW I've just double-checked that the reproducer provided by
>> > syzkaller in the original message still triggers the report from the
>> > original message in the latest KMSAN tree (which already contains the
>> > __hw_addr_add_ex() fix from April).
>> >> Well... yes and no. When I was looking at this bug (bug?id=088efeac32fd) I
>> >> was looking
>> >> at the report at "2018/05/09 18:55"
>> >> (https://syzkaller.appspot.com/text?tag=CrashReport&x=141b707b800000),
>> >> since it was the only report with a reproducer. This was my error.
>> >>
>> >> The error and the call trace in this report are:
>> >>
>> >> >>>
>> >> BUG: KMSAN: uninit-value in memcmp+0x119/0x180 lib/string.c:861
>> >> CPU: 0 PID: 38 Comm: kworker/0:1 Not tainted 4.17.0-rc3+ #88
>> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> >> Google 01/01/2011
>> >> Workqueue: ipv6_addrconf addrconf_dad_work
>> >> Call Trace:
>> >> __dump_stack lib/dump_stack.c:77 [inline]
>> >> dump_stack+0x185/0x1d0 lib/dump_stack.c:113
>> >> kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
>> >> __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
>> >> memcmp+0x119/0x180 lib/string.c:861
>> >> __hw_addr_add_ex net/core/dev_addr_lists.c:61 [inline]
>> >> __dev_mc_add+0x1fc/0x900 net/core/dev_addr_lists.c:670
>> >> dev_mc_add+0x6d/0x80 net/core/dev_addr_lists.c:687
>> >> igmp6_group_added+0x2db/0xa00 net/ipv6/mcast.c:662
>> >> ipv6_dev_mc_inc+0xe9e/0x1130 net/ipv6/mcast.c:914
>> >> addrconf_join_solict net/ipv6/addrconf.c:2103 [inline]
>> >> addrconf_dad_begin net/ipv6/addrconf.c:3853 [inline]
>> >> addrconf_dad_work+0x462/0x2a20 net/ipv6/addrconf.c:3979
>> >> process_one_work+0x12c6/0x1f60 kernel/workqueue.c:2145
>> >> worker_thread+0x113c/0x24f0 kernel/workqueue.c:2279
>> >> kthread+0x539/0x720 kernel/kthread.c:239
>> >> ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:412
>> >>
>> >> Local variable description: ----buf@igmp6_group_added
>> >> Variable was created at:
>> >> igmp6_group_added+0x4a/0xa00 net/ipv6/mcast.c:650
>> >> ipv6_dev_mc_inc+0xe9e/0x1130 net/ipv6/mcast.c:914
>> >> <<<
>> >>
>> >> It is the same like in bug?id=3887c0d99aecb27d085180c5222d245d08a30806
>> >> which, after some more test, made me believe these bugs are duplicate
>> >> and are fixed by the same commit.
>> >>
>> >> But let's look at another report at "2018/09/12 21:00"
>> >> (https://syzkaller.appspot.com/text?tag=CrashReport&x=14f99b71400000)
>> >> at the bug (bug?id=088efeac32fd), the one you've mentioned as
>> >> "the last crash for the second version (2) happened just few days ago".
>> >>
>> >> Its error and the call trace are completely different:
>> >>
>> >> >>>
>> >> BUG: KMSAN: uninit-value in memcmp+0x11d/0x180 lib/string.c:863
>> >> CPU: 0 PID: 6107 Comm: syz-executor4 Not tainted 4.19.0-rc3+ #45
>> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> >> Google 01/01/2011
>> >> Call Trace:
>> >> __dump_stack lib/dump_stack.c:77 [inline]
>> >> dump_stack+0x14b/0x190 lib/dump_stack.c:113
>> >> kmsan_report+0x183/0x2b0 mm/kmsan/kmsan.c:956
>> >> __msan_warning+0x70/0xc0 mm/kmsan/kmsan_instr.c:645
>> >> memcmp+0x11d/0x180 lib/string.c:863
>> >> dev_uc_add_excl+0x165/0x7b0 net/core/dev_addr_lists.c:464
>> >> ndo_dflt_fdb_add net/core/rtnetlink.c:3463 [inline]
>> >> rtnl_fdb_add+0x1081/0x1270 net/core/rtnetlink.c:3558
>> >> rtnetlink_rcv_msg+0xa0b/0x1530 net/core/rtnetlink.c:4715
>> >> netlink_rcv_skb+0x36e/0x5f0 net/netlink/af_netlink.c:2454
>> >> rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4733
>> >> netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
>> >> netlink_unicast+0x1638/0x1720 net/netlink/af_netlink.c:1343
>> >> netlink_sendmsg+0x1205/0x1290 net/netlink/af_netlink.c:1908
>> >> sock_sendmsg_nosec net/socket.c:621 [inline]
>> >> sock_sendmsg net/socket.c:631 [inline]
>> >> ...
>> >> Uninit was created at:
>> >> ...
>> >> slab_post_alloc_hook mm/slab.h:446 [inline]
>> >> slab_alloc_node mm/slub.c:2718 [inline]
>> >> __kmalloc_node_track_caller+0x9e7/0x1160 mm/slub.c:4351
>> >> __kmalloc_reserve net/core/skbuff.c:138 [inline]
>> >> __alloc_skb+0x2f5/0x9e0 net/core/skbuff.c:206
>> >> alloc_skb include/linux/skbuff.h:996 [inline]
>> >> netlink_alloc_large_skb net/netlink/af_netlink.c:1189 [inline]
>> >> netlink_sendmsg+0xb49/0x1290 net/netlink/af_netlink.c:1883
>> >> sock_sendmsg_nosec net/socket.c:621 [inline]
>> >> sock_sendmsg net/socket.c:631 [inline]
>> >> ___sys_sendmsg+0xe70/0x1290 net/socket.c:2114
>> >> <<<
>> >>
>> >> This is a different bug. How come these 2 different reports for 2
>> >> different
>> >> bugs have ended in the same syzkaller report (bug?id=088efeac32fd) ?
>> >
>> > I suspect this is because syzbot used the top stack frame as the
>> > report signature.
>> > There's a mechanism to ignore frames like memcmp() in the reports, not
>> > sure why didn't it work in this case (maybe it just wasn't in place at
>> > the time the report happened).
>> >> One bug is fixed by the "net: fix uninit-value in __hw_addr_add_ex()"
>> >> commit,
>> >> the second one is not, but they are still in the same syzkaller report.
>> >>
>> >> This was the reason of my confusion. I'm not sure how to fix this. If it
>> >> is possible,
>> >> probably we need to cancel/revoke "#syz fix: net: fix uninit-value in
>> >> __hw_addr_add_ex()"
>> >> for this syzkaller report (bug?id=088efeac32fd). And then "split" it into
>> >> 2 or
>> >> more different reports, but I'm not sure if this is possible.
>> >>
>> >> Probably, syzkaller needs to look deeper into the KMSAN reports to
>> >> differentiate
>> >> KMSAN errors happening because of different reasons.
>> >>
>> >> > On Sun, Sep 23, 2018 at 6:02 PM, Vladis Dronov <vdronov@redhat.com>
>> >> > wrote:
>> >> > > #syz fix: net: fix uninit-value in __hw_addr_add_ex()
>> >> >
>> >> > Hi Vladis,
>> >> >
>> >> > This can be fixed with "net: fix uninit-value in __hw_addr_add_ex()".
>> >> > That commit landed in April, syzbot waited till the commit reached all
>> >> > tested trees, and then closed the bug.
>> >> > But the similar bug continued to happen, so syzbot created second
>> >> > version of this bug (2). You can see on dashboard that the last crash
>> >> > for the second version (2) happened just few days ago. So this is a
>> >> > different bug.
>>
>>
>> Precisely discriminating bugs (root causes) bases on crash text is
>> generally undecidable problem, even for humans. We even can have
>> literally equal crash texts, which are still different bugs. And we
>> can have significantly differently looking crash texts, which are
>> actually caused by the same root cause. syzbot extracts some
>> "identity" string for each crash and than uses that string to
>> discriminate crashes and sort them into bins. This identity string is
>> what you see in email subject and bug title on dashboard. This method
>> can have both false positives and false negatives, but works
>> reasonably well in most cases and looks like the best practical
>> option.
>>
>> For this exact instance (memcmp) we actually improved the analysis
>> logic recently:
>> https://github.com/google/syzkaller/commit/0e29942f77715486995d996f80f82742812d75a2#diff-abe1515f011fad2659ff218f9eea9ae1
>> But this crash was analyzed and reported before the change. So if this
>> crash happens again it should be reported as "in __hw_addr_add_ex"
>> now.
>>
>> Re __hw_addr_add_ex bug, as Alex noted the crash was detected _after_
>> the fixing commit went in. So it's something new and different and
>> can't be fixed by the older commit.
>>
>> There are no general, single guideline as to what to do when several
>> different bugs glued together into a single bug. Fixing at least one
>> of them (any) in the context of the bug is good, fixing both is good
>> too. When/if a bug is closed, new occurrences of similar crashes (the
>> same identity string) will lead to creation of a new bug. So if we fix
>> only one and close the bug, eventually the second one will lead to a
>> new bug (won't be lost), now dedicated to this second crash.
>>
>> Now syzbot thinks that this bug is fixed/closed:
>> https://syzkaller.appspot.com/bug?extid=d3402c47f680ff24b29c
>> There is specifically no "undo" functionality, because it's inherently
>> racy with creation of a new version of this bugs by new crashes. So if
>> of these crashes will happen again, syzbot will open new bugs (now
>> with better discriminated titles). We can wait for that. Or we can
>> submit new fixes without waiting for new syzbot bugs (adding
>> Reported-by to new commits referencing this bug should not do any
>> harm).
>>
>> Hope this clarifies things a bit.
>>
>> Thanks
^ permalink raw reply
* pull-request: mac80211 2018-09-27
From: Johannes Berg @ 2018-09-27 11:18 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Here's another - unfortunately pretty large - set of fixes
for the current cycle. The changes are pretty simple or even
trivial though.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 28619527b8a712590c93d0a9e24b4425b9376a8c:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-09-04 12:45:11 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2018-09-27
for you to fetch changes up to 1222a16014888ed9733c11e221730d4a8196222b:
nl80211: Fix possible Spectre-v1 for CQM RSSI thresholds (2018-09-27 11:44:44 +0200)
----------------------------------------------------------------
More patches than I'd like perhaps, but each seems reasonable:
* two new spectre-v1 mitigations in nl80211
* TX status fix in general, and mesh in particular
* powersave vs. offchannel fix
* regulatory initialization fix
* fix for a queue hang due to a bad return value
* allocate TXQs for active monitor interfaces, fixing my
earlier patch to avoid unnecessary allocations where I
missed this case needed them
* fix TDLS data frames priority assignment
* fix scan results processing to take into account duplicate
channel numbers (over different operating classes, but we
don't necessarily know the operating class)
* various hwsim fixes for radio destruction and new radio
announcement messages
* remove an extraneous kernel-doc line
----------------------------------------------------------------
Andrei Otcheretianski (3):
mac80211: Always report TX status
mac80211: Don't wake up from PS for offchannel TX
cfg80211: reg: Init wiphy_idx in regulatory_hint_core()
Bob Copeland (1):
mac80211: fix pending queue hang due to TX_DROP
Felix Fietkau (1):
mac80211: allocate TXQs for active monitor interfaces
Johannes Berg (1):
mac80211: TDLS: fix skb queue/priority assignment
Jouni Malinen (1):
cfg80211: Address some corner cases in scan result channel updating
Martin Willi (3):
mac80211_hwsim: fix locking when iterating radios during ns exit
mac80211_hwsim: fix race in radio destruction from netlink notifier
mac80211_hwsim: do not omit multicast announce of first added radio
Masashi Honma (2):
nl80211: Fix possible Spectre-v1 for NL80211_TXRATE_HT
nl80211: Fix possible Spectre-v1 for CQM RSSI thresholds
Randy Dunlap (1):
cfg80211: fix reg_query_regdb_wmm kernel-doc
Yuan-Chi Pang (1):
mac80211: fix TX status reporting for ieee80211s
drivers/net/wireless/mac80211_hwsim.c | 36 ++++++++++------------
include/net/cfg80211.h | 2 --
net/mac80211/iface.c | 3 +-
net/mac80211/mesh.h | 3 +-
net/mac80211/mesh_hwmp.c | 9 ++----
net/mac80211/status.c | 11 +++----
net/mac80211/tdls.c | 8 ++---
net/mac80211/tx.c | 6 +++-
net/wireless/nl80211.c | 20 +++++++++---
net/wireless/reg.c | 1 +
net/wireless/scan.c | 58 +++++++++++++++++++++++++++++------
11 files changed, 103 insertions(+), 54 deletions(-)
^ permalink raw reply
* [PATCH net 1/1] qed: Fix shmem structure inconsistency between driver and the mfw.
From: Sudarsana Reddy Kalluru @ 2018-09-27 11:12 UTC (permalink / raw)
To: davem; +Cc: netdev, Michal.Kalderon
The structure shared between driver and the management FW (mfw) differ in
sizes. This would lead to issues when driver try to access the structure
members which are not-aligned with the mfw copy e.g., data_ptr usage in the
case of mfw_tlv request.
Align the driver structure with mfw copy, add reserved field(s) to driver
structure for the members not used by the driver.
Fixes: dd006921d ("qed: Add MFW interfaces for TLV request support.)
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Michal Kalderon <Michal.Kalderon@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_hsi.h b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
index 9b3ef00e..a713826 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_hsi.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
@@ -11987,6 +11987,7 @@ struct public_global {
u32 running_bundle_id;
s32 external_temperature;
u32 mdump_reason;
+ u64 reserved;
u32 data_ptr;
u32 data_size;
};
--
1.8.3.1
^ permalink raw reply related
* [PATCH 1/2] net: dpaa2: move DPAA2 PTP driver out of staging/
From: Yangbo Lu @ 2018-09-27 11:12 UTC (permalink / raw)
To: linux-kernel, devel, netdev, Richard Cochran, David S . Miller,
Ioana Radulescu, Greg Kroah-Hartman
Cc: Yangbo Lu
This patch is to move DPAA2 PTP driver out of staging/
since the dpaa2-eth had been moved out.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
---
drivers/net/ethernet/freescale/Kconfig | 9 +--------
drivers/net/ethernet/freescale/dpaa2/Kconfig | 15 +++++++++++++++
drivers/net/ethernet/freescale/dpaa2/Makefile | 6 ++++--
.../ethernet/freescale/dpaa2}/dprtc-cmd.h | 0
.../rtc => net/ethernet/freescale/dpaa2}/dprtc.c | 0
.../rtc => net/ethernet/freescale/dpaa2}/dprtc.h | 0
.../rtc => net/ethernet/freescale/dpaa2}/rtc.c | 0
.../rtc => net/ethernet/freescale/dpaa2}/rtc.h | 0
drivers/staging/fsl-dpaa2/Kconfig | 8 --------
drivers/staging/fsl-dpaa2/Makefile | 1 -
drivers/staging/fsl-dpaa2/rtc/Makefile | 7 -------
11 files changed, 20 insertions(+), 26 deletions(-)
create mode 100644 drivers/net/ethernet/freescale/dpaa2/Kconfig
rename drivers/{staging/fsl-dpaa2/rtc => net/ethernet/freescale/dpaa2}/dprtc-cmd.h (100%)
rename drivers/{staging/fsl-dpaa2/rtc => net/ethernet/freescale/dpaa2}/dprtc.c (100%)
rename drivers/{staging/fsl-dpaa2/rtc => net/ethernet/freescale/dpaa2}/dprtc.h (100%)
rename drivers/{staging/fsl-dpaa2/rtc => net/ethernet/freescale/dpaa2}/rtc.c (100%)
rename drivers/{staging/fsl-dpaa2/rtc => net/ethernet/freescale/dpaa2}/rtc.h (100%)
delete mode 100644 drivers/staging/fsl-dpaa2/rtc/Makefile
diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
index 7a30276..d3a62bc 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -96,13 +96,6 @@ config GIANFAR
on the 8540.
source "drivers/net/ethernet/freescale/dpaa/Kconfig"
-
-config FSL_DPAA2_ETH
- tristate "Freescale DPAA2 Ethernet"
- depends on FSL_MC_BUS && FSL_MC_DPIO
- depends on NETDEVICES && ETHERNET
- ---help---
- Ethernet driver for Freescale DPAA2 SoCs, using the
- Freescale MC bus driver
+source "drivers/net/ethernet/freescale/dpaa2/Kconfig"
endif # NET_VENDOR_FREESCALE
diff --git a/drivers/net/ethernet/freescale/dpaa2/Kconfig b/drivers/net/ethernet/freescale/dpaa2/Kconfig
new file mode 100644
index 0000000..44c5c3a
--- /dev/null
+++ b/drivers/net/ethernet/freescale/dpaa2/Kconfig
@@ -0,0 +1,15 @@
+config FSL_DPAA2_ETH
+ tristate "Freescale DPAA2 Ethernet"
+ depends on FSL_MC_BUS && FSL_MC_DPIO
+ depends on NETDEVICES && ETHERNET
+ help
+ Ethernet driver for Freescale DPAA2 SoCs, using the
+ Freescale MC bus driver
+
+config FSL_DPAA2_PTP_CLOCK
+ tristate "Freescale DPAA2 PTP Clock"
+ depends on FSL_DPAA2_ETH && POSIX_TIMERS
+ select PTP_1588_CLOCK
+ help
+ This driver adds support for using the DPAA2 1588 timer module
+ as a PTP clock.
diff --git a/drivers/net/ethernet/freescale/dpaa2/Makefile b/drivers/net/ethernet/freescale/dpaa2/Makefile
index 9315ecd..312e37f 100644
--- a/drivers/net/ethernet/freescale/dpaa2/Makefile
+++ b/drivers/net/ethernet/freescale/dpaa2/Makefile
@@ -3,9 +3,11 @@
# Makefile for the Freescale DPAA2 Ethernet controller
#
-obj-$(CONFIG_FSL_DPAA2_ETH) += fsl-dpaa2-eth.o
+obj-$(CONFIG_FSL_DPAA2_ETH) += fsl-dpaa2-eth.o
+obj-$(CONFIG_FSL_DPAA2_PTP_CLOCK) += fsl-dpaa2-rtc.o
-fsl-dpaa2-eth-objs := dpaa2-eth.o dpaa2-ethtool.o dpni.o
+fsl-dpaa2-eth-objs := dpaa2-eth.o dpaa2-ethtool.o dpni.o
+fsl-dpaa2-rtc-objs := rtc.o dprtc.o
# Needed by the tracing framework
CFLAGS_dpaa2-eth.o := -I$(src)
diff --git a/drivers/staging/fsl-dpaa2/rtc/dprtc-cmd.h b/drivers/net/ethernet/freescale/dpaa2/dprtc-cmd.h
similarity index 100%
rename from drivers/staging/fsl-dpaa2/rtc/dprtc-cmd.h
rename to drivers/net/ethernet/freescale/dpaa2/dprtc-cmd.h
diff --git a/drivers/staging/fsl-dpaa2/rtc/dprtc.c b/drivers/net/ethernet/freescale/dpaa2/dprtc.c
similarity index 100%
rename from drivers/staging/fsl-dpaa2/rtc/dprtc.c
rename to drivers/net/ethernet/freescale/dpaa2/dprtc.c
diff --git a/drivers/staging/fsl-dpaa2/rtc/dprtc.h b/drivers/net/ethernet/freescale/dpaa2/dprtc.h
similarity index 100%
rename from drivers/staging/fsl-dpaa2/rtc/dprtc.h
rename to drivers/net/ethernet/freescale/dpaa2/dprtc.h
diff --git a/drivers/staging/fsl-dpaa2/rtc/rtc.c b/drivers/net/ethernet/freescale/dpaa2/rtc.c
similarity index 100%
rename from drivers/staging/fsl-dpaa2/rtc/rtc.c
rename to drivers/net/ethernet/freescale/dpaa2/rtc.c
diff --git a/drivers/staging/fsl-dpaa2/rtc/rtc.h b/drivers/net/ethernet/freescale/dpaa2/rtc.h
similarity index 100%
rename from drivers/staging/fsl-dpaa2/rtc/rtc.h
rename to drivers/net/ethernet/freescale/dpaa2/rtc.h
diff --git a/drivers/staging/fsl-dpaa2/Kconfig b/drivers/staging/fsl-dpaa2/Kconfig
index 59aaae7..991e154 100644
--- a/drivers/staging/fsl-dpaa2/Kconfig
+++ b/drivers/staging/fsl-dpaa2/Kconfig
@@ -16,11 +16,3 @@ config FSL_DPAA2_ETHSW
---help---
Driver for Freescale DPAA2 Ethernet Switch. Select
BRIDGE to have support for bridge tools.
-
-config FSL_DPAA2_PTP_CLOCK
- tristate "Freescale DPAA2 PTP Clock"
- depends on FSL_DPAA2_ETH && POSIX_TIMERS
- select PTP_1588_CLOCK
- help
- This driver adds support for using the DPAA2 1588 timer module
- as a PTP clock.
diff --git a/drivers/staging/fsl-dpaa2/Makefile b/drivers/staging/fsl-dpaa2/Makefile
index 464f242..c92ab98 100644
--- a/drivers/staging/fsl-dpaa2/Makefile
+++ b/drivers/staging/fsl-dpaa2/Makefile
@@ -3,4 +3,3 @@
#
obj-$(CONFIG_FSL_DPAA2_ETHSW) += ethsw/
-obj-$(CONFIG_FSL_DPAA2_PTP_CLOCK) += rtc/
diff --git a/drivers/staging/fsl-dpaa2/rtc/Makefile b/drivers/staging/fsl-dpaa2/rtc/Makefile
deleted file mode 100644
index 5468da0..0000000
--- a/drivers/staging/fsl-dpaa2/rtc/Makefile
+++ /dev/null
@@ -1,7 +0,0 @@
-#
-# Makefile for the Freescale DPAA2 PTP clock
-#
-
-obj-$(CONFIG_FSL_DPAA2_PTP_CLOCK) += dpaa2-rtc.o
-
-dpaa2-rtc-objs := rtc.o dprtc.o
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations
From: Jason A. Donenfeld @ 2018-09-27 17:06 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Thomas Gleixner, Peter Zijlstra, Ard Biesheuvel, LKML, Netdev,
Linux Crypto Mailing List, David Miller, Greg Kroah-Hartman,
Samuel Neves, Andrew Lutomirski, Jean-Philippe Aumasson,
Russell King - ARM Linux, linux-arm-kernel
In-Reply-To: <BB2CD8D5-E7FF-4D25-8C83-F64960253248@amacapital.net>
On Thu, Sep 27, 2018 at 6:27 PM Andy Lutomirski <luto@amacapital.net> wrote:
> I would add another consideration: if you can get better latency with negligible overhead (0.1%? 0.05%), then that might make sense too. For example, it seems plausible that checking need_resched() every few blocks adds basically no overhead, and the SIMD helpers could do this themselves or perhaps only ever do a block at a time.
>
> need_resched() costs a cacheline access, but it’s usually a hot cacheline, and the actual check is just whether a certain bit in memory is set.
Yes you're right, I do plan to check quite often, rather than seldom,
for this reason. I've been toying with the idea of instead processing
65k (maximum size of a UDP packet) at a time before checking
need_resched(), but armed with the 20µs figure, this isn't remotely
possible on most hardware. So I'll stick with the original
conservative plan of checking very often, and not making things
different from the aspects worked out by the present crypto API in
this regard.
^ permalink raw reply
* Re: [PATCH net V2] vhost-vsock: fix use after free
From: Michael S. Tsirkin @ 2018-09-27 17:04 UTC (permalink / raw)
To: Jason Wang
Cc: stefanha, kvm, virtualization, netdev, linux-kernel,
sergei.shtylyov
In-Reply-To: <20180927122204.4188-1-jasowang@redhat.com>
On Thu, Sep 27, 2018 at 08:22:04PM +0800, Jason Wang wrote:
> The access of vsock is not protected by vhost_vsock_lock. This may
> lead to use after free since vhost_vsock_dev_release() may free the
> pointer at the same time.
>
> Fix this by holding the lock during the access.
>
> Reported-by: syzbot+e3e074963495f92a89ed@syzkaller.appspotmail.com
> Fixes: 16320f363ae1 ("vhost-vsock: add pkt cancel capability")
> Fixes: 433fc58e6bf2 ("VSOCK: Introduce vhost_vsock.ko")
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Wow is that really the best we can do? A global lock on a data path
operation? Granted use after free is nasty but Stefan said he sees
a way to fix it using a per socket refcount. He's on vacation
until Oct 4 though ...
> ---
> - V2: fix typos
> - The patch is needed for -stable.
> ---
> drivers/vhost/vsock.c | 26 +++++++++++++++++++-------
> 1 file changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
> index 34bc3ab40c6d..7d0b292867fd 100644
> --- a/drivers/vhost/vsock.c
> +++ b/drivers/vhost/vsock.c
> @@ -210,21 +210,27 @@ vhost_transport_send_pkt(struct virtio_vsock_pkt *pkt)
> struct vhost_vsock *vsock;
> int len = pkt->len;
>
> + spin_lock_bh(&vhost_vsock_lock);
> +
> /* Find the vhost_vsock according to guest context id */
> - vsock = vhost_vsock_get(le64_to_cpu(pkt->hdr.dst_cid));
> + vsock = __vhost_vsock_get(le64_to_cpu(pkt->hdr.dst_cid));
> if (!vsock) {
> virtio_transport_free_pkt(pkt);
> + spin_unlock_bh(&vhost_vsock_lock);
> return -ENODEV;
> }
>
> if (pkt->reply)
> atomic_inc(&vsock->queued_replies);
>
> - spin_lock_bh(&vsock->send_pkt_list_lock);
> + spin_lock(&vsock->send_pkt_list_lock);
> list_add_tail(&pkt->list, &vsock->send_pkt_list);
> - spin_unlock_bh(&vsock->send_pkt_list_lock);
> + spin_unlock(&vsock->send_pkt_list_lock);
>
> vhost_work_queue(&vsock->dev, &vsock->send_pkt_work);
> +
> + spin_unlock_bh(&vhost_vsock_lock);
> +
> return len;
> }
>
> @@ -236,18 +242,22 @@ vhost_transport_cancel_pkt(struct vsock_sock *vsk)
> int cnt = 0;
> LIST_HEAD(freeme);
>
> + spin_lock_bh(&vhost_vsock_lock);
> +
> /* Find the vhost_vsock according to guest context id */
> - vsock = vhost_vsock_get(vsk->remote_addr.svm_cid);
> - if (!vsock)
> + vsock = __vhost_vsock_get(vsk->remote_addr.svm_cid);
> + if (!vsock) {
> + spin_unlock_bh(&vhost_vsock_lock);
> return -ENODEV;
> + }
>
> - spin_lock_bh(&vsock->send_pkt_list_lock);
> + spin_lock(&vsock->send_pkt_list_lock);
> list_for_each_entry_safe(pkt, n, &vsock->send_pkt_list, list) {
> if (pkt->vsk != vsk)
> continue;
> list_move(&pkt->list, &freeme);
> }
> - spin_unlock_bh(&vsock->send_pkt_list_lock);
> + spin_unlock(&vsock->send_pkt_list_lock);
>
> list_for_each_entry_safe(pkt, n, &freeme, list) {
> if (pkt->reply)
> @@ -265,6 +275,8 @@ vhost_transport_cancel_pkt(struct vsock_sock *vsk)
> vhost_poll_queue(&tx_vq->poll);
> }
>
> + spin_unlock_bh(&vhost_vsock_lock);
> +
> return 0;
> }
>
> --
> 2.17.1
^ permalink raw reply
* Re: [PATCH v3 net-next] dt-bindings: can: rcar_can: document r8a77965 support
From: Marc Kleine-Budde @ 2018-09-27 10:46 UTC (permalink / raw)
To: Eugeniu Rosca
Cc: Simon Horman, Kieran Bingham, Sergei Shtylyov,
Wolfgang Grandegger, David S . Miller, Rob Herring, Mark Rutland,
linux-can, netdev, devicetree, Magnus Damm, linux-renesas-soc,
Eugeniu Rosca
In-Reply-To: <20180921194833.GA28500@vmlxhi-102.adit-jv.com>
[-- Attachment #1.1: Type: text/plain, Size: 1287 bytes --]
On 09/21/2018 09:48 PM, Eugeniu Rosca wrote:
> Hi Marc,
>
> On Mon, Aug 27, 2018 at 12:08:48PM +0200, Marc Kleine-Budde wrote:
>> On 08/20/2018 04:49 PM, Eugeniu Rosca wrote:
>>> From: Eugeniu Rosca <rosca.eugeniu@gmail.com>
>>>
>>> Document the support for rcar_can on R8A77965 SoC devices.
>>> Add R8A77965 to the list of SoCs which require the "assigned-clocks" and
>>> "assigned-clock-rates" properties (thanks, Sergei).
>>>
>>> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
>>> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
>>> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
>>
>> Added to linux-can.
>
> I can't find the patch in below repositories:
> - https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git
> - https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git
>
> Could you please let me know what "linux-can" means?
I haven't pushed it yet, it will be in the testing branch of linux-can.git
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ 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