* Re: [RFC net-next 00/15] net: A socket API for LoRa
From: Jian-Hong Pan @ 2018-07-03 15:11 UTC (permalink / raw)
To: Andreas Färber
Cc: Michal Kubeček, Konstantin Böhm, contact, Ken Yu,
Michael Röder, Rob Herring, lora, Alexander Graf,
Jan Jongboom, Janus Piwek, Jon Ortego, devicetree, Jiri Pirko,
Marcel Holtmann, Mark Brown, Dollar Chen, Brian Ray,
linux-arm-kernel, lora, Matthias Brugger, Ben Whitten, netdev,
linux-kernel, linux-spi, Steve deRosier
In-Reply-To: <20180701110804.32415-1-afaerber@suse.de>
Hi Andreas,
First, thanks for your great jobs. LoRaWAN module needs the
compatible devices drivers.
I will reply the message under the LoRaWAN specification.
2018-07-01 19:07 GMT+08:00 Andreas Färber <afaerber@suse.de>:
> Hello,
>
> LoRa is a long-range, low-power wireless technology by Semtech.
> Unlike other LPWAN technologies, users don't need to rely on infrastructure
> providers and SIM cards and expensive subscription plans, they can set up
> their own gateways. Modules, adapters and evaluation boards are available
> from a large number of vendors.
>
> Many vendors also make available Open Source software examples on GitHub.
> But when taking a closer look, many of them combine licenses in ways that are
> not redistributable. My reports have remained without response or solution.
>
> https://github.com/ernstdevreede/lmic_pi/issues/2
> https://github.com/Snootlab/lmic_chisterapi/issues/2
> https://github.com/Snootlab/lora_chisterapi/issues/2
>
> Another issue was that most such projects around the Raspberry Pi make use of
> spidev to communicate with the Semtech chipsets from userspace. The Linux spi
> maintainers have chosen to greet any such users of spidev with a friendly
> WARN_ON(), preferring in-kernel spi drivers and white-listing individual
> devices only.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spidev.c?h=v4.17#n722
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spidev.c?h=v4.17#n667
>
> Also I don't quite see the point in having userspace probe what SPI devices
> are connected to a generic spidev driver when we have an easy Device Tree
> hardware description on arm/arm64 that could give us that info.
>
> I raised the topic during Q&A of a FOSDEM 2017 talk (cut off at the end
> of the video) but unfortunately found no one to collaborate on this.
>
> https://archive.fosdem.org/2017/schedule/event/lorawan/
>
> Instead of porting from wiringPi to a differently licensed GPIO library
> and dealing with seemingly unmaintained LoRaWAN code dumps, I started a
> spi kernel driver for SX1276 back in 2016. But obviously a kernel driver
> isn't too helpful without a userspace API to send and receive packets.
>
> This patchset, updated from 2017 and extended, is implementing kernel drivers
> for various LoRa chipsets and modules. As API I'm proposing a PF_LORA socket
> implementation. Why? LoRa uses data packets with headers and checksums
> and differing MTUs and multiple protocols layered on top of it. Apart from
> simple headers for addressing used by RadioHead library and IMST's LoRa P2P
> protocol, the main use case (not implemented in this patchset) is expected
> to be LoRaWAN. And LoRaWAN has competing proprietary protocols, such as
> Link Labs' Symphony Link or GlobalSat M.O.S.T. or RadioShuttle, that might
> at some point want to adopt a standard API for their implementations, too.
>
> Ready-made LoRa hardware modules come in three flavors,
> a) with SPI access to the underlying Semtech chipsets, needing a software
> implementation of e.g. LoRaWAN protocol stack (i.e., a soft MAC),
> b) with a custom, often UART based interface and a pre-certified LoRaWAN
> protocol stack already integrated (i.e., hard/full MAC), and
> c) with a microcontroller that serves not only for the protocol stack but
> also as application processor, not offering a ready-made interface.
>
> This patchset focuses on option a). An SX1276 based LoRaWAN stack appeared
> to be the project of Jian-Hong Pan and is not included here.
Thanks, LoRaWAN module needs the compatible device drivers.
> This patchset also includes drivers for b), from text based AT commands to
> a binary SLIP based HCI protocol.
> Hardware examples for c) are Murata CMWX1ZZABZ-078 and RAK813.
>
> This patchset is clearly not ready for merging, but is being submitted for
> discussion, as requested by Jiri, in particular of the design choices:
>
> 1) PF_LORA/AF_LORA and associated identifiers are proposed to represent
> this technology. While for an SX1276 - case a) above - it might work to
> layer LoRaWAN as a protocol option for PF_LORA and add LoRaWAN address
> fields to the union in my sockaddr_lora, how would that work for devices
> that only support LoRaWAN but not pure LoRa? Do we need both AF_LORA and
> AF_LORAWAN, or just a separate ETH_P_LORAWAN or ARPHRD_LORAWAN?
The LoRaWAN module also register the LoRa device as a network device.
Will use the macros AF_LORAWAN, PF_LORAWAN, ARPHRD_LORAWAN and ETH_P_LORAWAN.
> 2) PF_LORA is used with SOCK_DGRAM here. The assumption is that RAW mode
> would be DGRAM plus preamble plus optional checksum.
Is the preamble added by the hardware itself here or software here?
> 3) Only the transmit path is partially implemented already. The assumption
> is that the devices should go into receive mode by default and only
> interrupt that when asked to transmit.
If it goes with LoRaWAN spec., end devices should be in idle (or
called standby mode) by default. Unless the device is asked to be in
transmitting or receiving timing slot.
> 4) Some hardware settings need to be supplied externally, such as the radio
> frequency for some modules, but many others can be runtime-configured,
> such as Spreading Factor, Bandwidth, Sync Word, or which antenna to use.
> What settings should be implemented as socket option vs. netlink layer
> vs. ioctl vs. sysfs? What are the criteria to apply?
- We can have a pre-defined table according to LoRaWAN Regional Parameters.
- Device driver declares the hardware's capability, for example
frequency, TX power. And then registers as a LoRaWAN compatible
device.
- LoRaWAN module handle the requests from upper layer or MAC commands
from a gateway (netlink layer), than uses the pre-defined interface
functions to set the parameters.
LoRaWAN module will export the operation functions interface.
> 5) Many of the modules support multiple modes, such as LoRa, LoRaWAN and FSK.
> Lacking a LoRaWAN implementation, I am currently switching them into LoRa
> mode at probe time wherever possible. How do we deal with that properly?
- There are data rate tables defined in LoRaWAN Regional Parameters.
Those contain which data rate uses LoRa mode or FSK mode.
- LoRaWAN should handle the data rate changing requests and then calls
the corresponding operation functions. Of course, the hardware's
capability registered before should also be under consideration at the
same time.
> a) Is there any precedence from the Wifi world for dynamically selecting
> between our own trusted Open Source implementation vs. hardware/firmware
> accelerated and/or certified implementations?
>
> b) Would a proof of concept for FSK (non-LoRa) modes be required for
> merging any LoRa driver for chipsets that support both? Or is there any
> facility or design guidelines that would allow us to focus on LoRa and
> LoRaWAN and leave non-LoRa radio modes to later contributors?
>
> As evident by the many questions, this is my first deep dive into the Linux
> net subsystem. It's also my first experiments with the new serdev subsystem,
> so in particular the receive paths will need some review and optimizations.
>
> This patchset was developed and tested mainly as KMP, originally at
> https://github.com/afaerber/lora-modules. It was recently transformed into a
> linux-next based tree, still mostly tested on our openSUSE Tumbleweed kernel
> with a differing AF_LORA value below current AF_MAX limit.
>
> Some corresponding Device Tree Overlays have been collected here:
> https://github.com/afaerber/dt-overlays
>
> Only European models for 868 MHz and 433 MHz could be tested when available.
I can test 922-928 MHz in Taiwan.
But I need a workable LoRaWAN gateway first! XD
Cheers,
Jian-Hong Pan
> Thanks to all companies and people that have supported this project so far.
>
> Have a lot of fun!
>
> Cheers,
> Andreas
>
> Cc: Jian-Hong Pan <starnight@g.ncu.edu.tw>
> Cc: Jiri Pirko <jiri@resnulli.us>
> Cc: Marcel Holtmann <marcel@holtmann.org>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Matthias Brugger <mbrugger@suse.com>
> Cc: Konstantin Böhm <konstantin.boehm@ancud.de>
> Cc: Jan Jongboom <jan.jongboom@arm.com>
> Cc: Janus Piwek <jpiwek@arroweurope.com>
> Cc: Michael Röder <michael.roeder@avnet.eu>
> Cc: Dollar Chen (陳義元) <dollar.chen@wtmec.com>
> Cc: Ken Yu (禹凯) <ken.yu@rakwireless.com>
> Cc: Jon Ortego <Jon.Ortego@imst.de>
> Cc: contact@snootlab.com
> Cc: Ben Whitten <ben.whitten@lairdtech.com>
> Cc: Brian Ray <brian.ray@link-labs.com>
> Cc: lora@globalsat.com.tw
> Cc: lora@radioshuttle.de
> Cc: Alexander Graf <agraf@suse.de>
> Cc: Michal Kubeček <mkubecek@suse.cz>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: Steve deRosier <derosier@gmail.com>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: linux-spi@vger.kernel.org
>
> Andreas Färber (15):
> net: Reserve protocol numbers for LoRa
> net: lora: Define sockaddr_lora
> net: lora: Add protocol numbers
> net: Add lora subsystem
> HACK: net: lora: Deal with .poll_mask in 4.18-rc2
> net: lora: Prepare for device drivers
> net: lora: Add Semtech SX1276
> net: lora: sx1276: Add debugfs
> net: lora: Prepare EUI helpers
> net: lora: Add Microchip RN2483
> net: lora: Add IMST WiMOD
> net: lora: Add USI WM-SG-SM-42
> net: lora: Prepare RAK RAK811
> net: lora: Prepare Semtech SX1257
> net: lora: Add Semtech SX1301
>
> drivers/net/Makefile | 1 +
> drivers/net/lora/Kconfig | 72 ++++
> drivers/net/lora/Makefile | 32 ++
> drivers/net/lora/dev.c | 125 ++++++
> drivers/net/lora/rak811.c | 219 +++++++++++
> drivers/net/lora/rn2483.c | 344 +++++++++++++++++
> drivers/net/lora/rn2483.h | 40 ++
> drivers/net/lora/rn2483_cmd.c | 130 +++++++
> drivers/net/lora/sx1257.c | 96 +++++
> drivers/net/lora/sx1276.c | 740 ++++++++++++++++++++++++++++++++++++
> drivers/net/lora/sx1301.c | 446 ++++++++++++++++++++++
> drivers/net/lora/usi.c | 411 ++++++++++++++++++++
> drivers/net/lora/wimod.c | 597 +++++++++++++++++++++++++++++
> include/linux/lora/dev.h | 44 +++
> include/linux/lora/skb.h | 29 ++
> include/linux/socket.h | 4 +-
> include/uapi/linux/if_arp.h | 1 +
> include/uapi/linux/if_ether.h | 1 +
> include/uapi/linux/lora.h | 24 ++
> net/Kconfig | 1 +
> net/Makefile | 1 +
> net/lora/Kconfig | 15 +
> net/lora/Makefile | 8 +
> net/lora/af_lora.c | 152 ++++++++
> net/lora/af_lora.h | 13 +
> net/lora/dgram.c | 297 +++++++++++++++
> security/selinux/hooks.c | 4 +-
> security/selinux/include/classmap.h | 4 +-
> 28 files changed, 3848 insertions(+), 3 deletions(-)
> create mode 100644 drivers/net/lora/Kconfig
> create mode 100644 drivers/net/lora/Makefile
> create mode 100644 drivers/net/lora/dev.c
> create mode 100644 drivers/net/lora/rak811.c
> create mode 100644 drivers/net/lora/rn2483.c
> create mode 100644 drivers/net/lora/rn2483.h
> create mode 100644 drivers/net/lora/rn2483_cmd.c
> create mode 100644 drivers/net/lora/sx1257.c
> create mode 100644 drivers/net/lora/sx1276.c
> create mode 100644 drivers/net/lora/sx1301.c
> create mode 100644 drivers/net/lora/usi.c
> create mode 100644 drivers/net/lora/wimod.c
> create mode 100644 include/linux/lora/dev.h
> create mode 100644 include/linux/lora/skb.h
> create mode 100644 include/uapi/linux/lora.h
> create mode 100644 net/lora/Kconfig
> create mode 100644 net/lora/Makefile
> create mode 100644 net/lora/af_lora.c
> create mode 100644 net/lora/af_lora.h
> create mode 100644 net/lora/dgram.c
>
> --
> 2.16.4
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] tcp: fix high tail latencies in DCTCP
From: Lawrence Brakmo @ 2018-07-03 15:10 UTC (permalink / raw)
To: Neal Cardwell
Cc: Netdev, Kernel Team, Blake Matheny, Alexei Starovoitov,
Yuchung Cheng, Steve Ibanez, Eric Dumazet
In-Reply-To: <CADVnQy=0QXUnPAEr26xpCsEgP5bbT1tvjEqQovaCYtxB_9+QyQ@mail.gmail.com>
On 7/2/18, 5:52 PM, "netdev-owner@vger.kernel.org on behalf of Neal Cardwell" <netdev-owner@vger.kernel.org on behalf of ncardwell@google.com> wrote:
On Mon, Jul 2, 2018 at 5:39 PM Lawrence Brakmo <brakmo@fb.com> wrote:
>
> 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…
>
> [PATCH net-next v2 1/2] tcp: notify when a delayed ack is sent
> [PATCH net-next v2 2/2] tcp: ack immediately when a cwr packet
>
> net/ipv4/tcp_input.c | 16 +++++++++++-----
> net/ipv4/tcp_output.c | 4 ++--
> 2 files changed, 13 insertions(+), 7 deletions(-)
Thanks, Larry. Just for context, can you please let us know whether
your tests included zero, one, or both of Eric's recent commits
(listed below) that tuned the number of ACKs after ECN events? (Or
maybe the tests were literally using a net-next kernel?) Just wanted
to get a better handle on any possible interactions there.
Thanks!
neal
Yes, my test kernel includes both patches listed below. BTW, I will send a new patch where I move the call to tcp_incr_quickack from tcp_ecn_check_ce to tcp_ecn_accept_cwr.
---
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=522040ea5fdd1c33bbf75e1d7c7c0422b96a94ef
commit 522040ea5fdd1c33bbf75e1d7c7c0422b96a94ef
Author: Eric Dumazet <edumazet@google.com>
Date: Mon May 21 15:08:57 2018 -0700
tcp: do not aggressively quick ack after ECN events
ECN signals currently forces TCP to enter quickack mode for
up to 16 (TCP_MAX_QUICKACKS) following incoming packets.
We believe this is not needed, and only sending one immediate ack
for the current packet should be enough.
This should reduce the extra load noticed in DCTCP environments,
after congestion events.
This is part 2 of our effort to reduce pure ACK packets.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=15ecbe94a45ef88491ca459b26efdd02f91edb6d
commit 15ecbe94a45ef88491ca459b26efdd02f91edb6d
Author: Eric Dumazet <edumazet@google.com>
Date: Wed Jun 27 08:47:21 2018 -0700
tcp: add one more quick ack after after ECN events
Larry Brakmo proposal ( https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_935233_&d=DwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=pq_Mqvzfy-C8ltkgyx1u_g&m=-aaZOqM6jDpeeyDiKlVoiaQRFc55aJgk4jHQILSj3D4&s=tFz97077b4KhTvYd69-n-YhnWhX6PWZQceWJiylvL5Q&e=
tcp: force cwnd at least 2 in tcp_cwnd_reduction) made us rethink
about our recent patch removing ~16 quick acks after ECN events.
tcp_enter_quickack_mode(sk, 1) makes sure one immediate ack is sent,
but in the case the sender cwnd was lowered to 1, we do not want
to have a delayed ack for the next packet we will receive.
Fixes: 522040ea5fdd ("tcp: do not aggressively quick ack after ECN events")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Neal Cardwell <ncardwell@google.com>
Cc: Lawrence Brakmo <brakmo@fb.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301
From: Andreas Färber @ 2018-07-03 15:09 UTC (permalink / raw)
To: Mark Brown
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: <20180703145022.GA13744@sirena.org.uk>
Am 03.07.2018 um 16:50 schrieb Mark Brown:
> On Mon, Jul 02, 2018 at 07:34:21PM +0200, Andreas Färber wrote:
>> Hi Mark,
>>
>> This driver is still evolving, there's newer code on my lora-next branch
>> already: https://github.com/afaerber/linux/commits/lora-next
>
> Please don't top post, reply in line with needed context. This allows
> readers to readily follow the flow of conversation and understand what
> you are talking about and also helps ensure that everything in the
> discussion is being addressed.
I did reply inline, if you cared to read on. ;)
>> 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?
>> Am 02.07.2018 um 18:12 schrieb Mark Brown:
>>> On Sun, Jul 01, 2018 at 01:08:04PM +0200, Andreas Färber wrote:
>>>> +static void sx1301_radio_spi_set_cs(struct spi_device *spi, bool enable)
>>>> +{
>>>> + int ret;
>>>> +
>>>> + dev_dbg(&spi->dev, "setting SPI CS to %s\n", enable ? "1" : "0");
>>>> +
>>>> + if (enable)
>>>> + return;
>
>>> So we never disable chip select?
>
>> Not here, I instead did that in transfer_one below.
>
> That's obviously at best going to be fragile, you're implementing half
> the operation here and half somewhere else which is most likely going to
> break at some point when the framework changes.
>
>>>> + if (ret) {
>>>> + dev_err(&spi->dev, "SPI radio address write failed\n");
>>>> + return ret;
>>>> + }
>>>> +
>>>> + ret = sx1301_write(ssx->parent, ssx->regs + REG_RADIO_X_DATA, (tx_buf && xfr->len >= 2) ? tx_buf[1] : 0);
>>>> + if (ret) {
>>>> + dev_err(&spi->dev, "SPI radio data write failed\n");
>>>> + return ret;
>>>> + }
>
>>> This looks awfully like you're coming in at the wrong abstraction layer
>>> and the hardware actually implements a register abstraction rather than
>>> a SPI one so you should be using regmap as the abstraction.
>
>> I don't understand. Ben has suggested using regmap for the SPI _device_
>> that we're talking to, which may be a good idea. But this SX1301 device
>> in turn has two SPI _masters_ talking to an SX125x slave each. I don't
>> see how using regmap instead of my wrappers avoids this spi_controller?
>
> It seems obvious from the code that this isn't actually interacting with
> a SPI controller, you're writing an address and a value to a register
> map rather than dealing with a byte stream. There may be a SPI bus
> somewhere behind some other hardware but you don't seem to be
> interacting with it as such.
>
>> The whole point of this spi_controller is to abstract and separate the
>> SX1255 vs. SX1257 vs. whatever-radio-attached into a separate driver,
>> instead of mixing it into the SX1301 driver - to me that looks cleaner
>> and more extensible. It also has the side-effect that we could configure
>> the two radios via DT (frequencies, clk output, etc.).
>
> 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.
HTE,
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
* [PATCH v2] net: usb: asix: allow optionally getting mac address from device tree
From: Marcel Ziswiler @ 2018-07-03 15:06 UTC (permalink / raw)
To: netdev
Cc: Oliver Neukum, Marcel Ziswiler, linux-usb, David S. Miller,
Dean Jenkins, linux-kernel, Andrey Konovalov
From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
For Embedded use where e.g. AX88772B chips may be used without external
EEPROMs the boot loader may choose to pass the MAC address to be used
via device tree. Therefore, allow for optionally getting the MAC
address from device tree data e.g. as follows (excerpt from a T30 based
board, local-mac-address to be filled in by boot loader):
/* EHCI instance 1: USB2_DP/N -> AX88772B */
usb@7d004000 {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
asix@1 {
reg = <1>;
local-mac-address = [00 00 00 00 00 00];
};
};
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
Changes in v2:
- Use eth_platform_get_mac_address() as suggested by Andrew.
drivers/net/usb/asix_devices.c | 38 +++++++++++++++++++++++---------------
1 file changed, 23 insertions(+), 15 deletions(-)
diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index 3d4f7959dabb..8f41c6bda8e5 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -691,24 +691,32 @@ static int ax88772_bind(struct usbnet *dev, struct usb_interface *intf)
u32 phyid;
struct asix_common_private *priv;
- usbnet_get_endpoints(dev,intf);
+ usbnet_get_endpoints(dev, intf);
- /* Get the MAC address */
- if (dev->driver_info->data & FLAG_EEPROM_MAC) {
- for (i = 0; i < (ETH_ALEN >> 1); i++) {
- ret = asix_read_cmd(dev, AX_CMD_READ_EEPROM, 0x04 + i,
- 0, 2, buf + i * 2, 0);
- if (ret < 0)
- break;
- }
+ /* Maybe the boot loader passed the MAC address via device tree */
+ if (!eth_platform_get_mac_address(&dev->udev->dev, buf)) {
+ netif_dbg(dev, ifup, dev->net,
+ "MAC address read from device tree");
} else {
- ret = asix_read_cmd(dev, AX_CMD_READ_NODE_ID,
- 0, 0, ETH_ALEN, buf, 0);
- }
+ /* Try getting the MAC address from EEPROM */
+ if (dev->driver_info->data & FLAG_EEPROM_MAC) {
+ for (i = 0; i < (ETH_ALEN >> 1); i++) {
+ ret = asix_read_cmd(dev, AX_CMD_READ_EEPROM,
+ 0x04 + i, 0, 2, buf + i * 2,
+ 0);
+ if (ret < 0)
+ break;
+ }
+ } else {
+ ret = asix_read_cmd(dev, AX_CMD_READ_NODE_ID,
+ 0, 0, ETH_ALEN, buf, 0);
+ }
- if (ret < 0) {
- netdev_dbg(dev->net, "Failed to read MAC address: %d\n", ret);
- return ret;
+ if (ret < 0) {
+ netdev_dbg(dev->net, "Failed to read MAC address: %d\n",
+ ret);
+ return ret;
+ }
}
asix_set_netdev_dev_addr(dev, buf);
--
2.14.4
^ permalink raw reply related
* CHQ on 16-June-18
From: claudia.andrade @ 2018-07-03 11:18 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 104 bytes --]
Dear sir,
Please kindly approve as the bellow list and the attached file for
reference.
Regards
[-- Attachment #2: CHQ on 16-June-18.zip --]
[-- Type: application/zip, Size: 232461 bytes --]
^ permalink raw reply
* Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301
From: Mark Brown @ 2018-07-03 14:50 UTC (permalink / raw)
To: Andreas Färber
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
In-Reply-To: <4e06cc72-2092-70f3-c801-bf6e4c3cbec2@suse.de>
[-- Attachment #1: Type: text/plain, Size: 3135 bytes --]
On Mon, Jul 02, 2018 at 07:34:21PM +0200, Andreas Färber wrote:
> Hi Mark,
>
> This driver is still evolving, there's newer code on my lora-next branch
> already: https://github.com/afaerber/linux/commits/lora-next
Please don't top post, reply in line with needed context. This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.
> 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?
> Am 02.07.2018 um 18:12 schrieb Mark Brown:
> > On Sun, Jul 01, 2018 at 01:08:04PM +0200, Andreas Färber wrote:
> >> +static void sx1301_radio_spi_set_cs(struct spi_device *spi, bool enable)
> >> +{
> >> + int ret;
> >> +
> >> + dev_dbg(&spi->dev, "setting SPI CS to %s\n", enable ? "1" : "0");
> >> +
> >> + if (enable)
> >> + return;
> > So we never disable chip select?
> Not here, I instead did that in transfer_one below.
That's obviously at best going to be fragile, you're implementing half
the operation here and half somewhere else which is most likely going to
break at some point when the framework changes.
> >> + if (ret) {
> >> + dev_err(&spi->dev, "SPI radio address write failed\n");
> >> + return ret;
> >> + }
> >> +
> >> + ret = sx1301_write(ssx->parent, ssx->regs + REG_RADIO_X_DATA, (tx_buf && xfr->len >= 2) ? tx_buf[1] : 0);
> >> + if (ret) {
> >> + dev_err(&spi->dev, "SPI radio data write failed\n");
> >> + return ret;
> >> + }
> > This looks awfully like you're coming in at the wrong abstraction layer
> > and the hardware actually implements a register abstraction rather than
> > a SPI one so you should be using regmap as the abstraction.
> I don't understand. Ben has suggested using regmap for the SPI _device_
> that we're talking to, which may be a good idea. But this SX1301 device
> in turn has two SPI _masters_ talking to an SX125x slave each. I don't
> see how using regmap instead of my wrappers avoids this spi_controller?
It seems obvious from the code that this isn't actually interacting with
a SPI controller, you're writing an address and a value to a register
map rather than dealing with a byte stream. There may be a SPI bus
somewhere behind some other hardware but you don't seem to be
interacting with it as such.
> The whole point of this spi_controller is to abstract and separate the
> SX1255 vs. SX1257 vs. whatever-radio-attached into a separate driver,
> instead of mixing it into the SX1301 driver - to me that looks cleaner
> and more extensible. It also has the side-effect that we could configure
> the two radios via DT (frequencies, clk output, etc.).
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).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [bpf PATCH 1/2] bpf: sockmap, error path can not release psock in multi-map case
From: Daniel Borkmann @ 2018-07-03 14:40 UTC (permalink / raw)
To: John Fastabend, ast; +Cc: netdev, kafai
In-Reply-To: <20180630135131.6395.86522.stgit@john-Precision-Tower-5810>
On 06/30/2018 03:51 PM, John Fastabend wrote:
> The current code, in the error path of sock_hash_ctx_update_elem,
> checks if the sock has a psock in the user data and if so decrements
> the reference count of the psock. However, if the error happens early
> in the error path we may have never incremented the psock reference
> count and if the psock exists because the sock is in another map then
> we may inadvertently decrement the reference count.
>
> Fix this by making the error path only call smap_release_sock if the
> error happens after the increment.
>
> Reported-by: syzbot+d464d2c20c717ef5a6a8@syzkaller.appspotmail.com
> Fixes: 81110384441a ("bpf: sockmap, add hash map support")
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
> ---
> 0 files changed
>
> diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
> index 4fc2cb1..63fb047 100644
> --- a/kernel/bpf/sockmap.c
> +++ b/kernel/bpf/sockmap.c
> @@ -1896,7 +1896,7 @@ static int __sock_map_ctx_update_elem(struct bpf_map *map,
> e = kzalloc(sizeof(*e), GFP_ATOMIC | __GFP_NOWARN);
> if (!e) {
> err = -ENOMEM;
> - goto out_progs;
> + goto out_free;
> }
> }
>
> @@ -2324,7 +2324,12 @@ static int sock_hash_ctx_update_elem(struct bpf_sock_ops_kern *skops,
> if (err)
> goto err;
>
> - /* bpf_map_update_elem() can be called in_irq() */
> + psock = smap_psock_sk(sock);
> + if (unlikely(!psock)) {
> + err = -EINVAL;
> + goto err;
> + }
Is an error even possible at this point? If __sock_map_ctx_update_elem() succeeds,
we either allocated and linked a new psock to the sock or we inc'ed the existing
one's refcount. From my reading it seems we should always succeed the subsequent
smap_psock_sk(). If we would have failed here in between it would mean we'd have
a refcount imbalance somewhere?
> +
> raw_spin_lock_bh(&b->lock);
> l_old = lookup_elem_raw(head, hash, key, key_size);
> if (l_old && map_flags == BPF_NOEXIST) {
> @@ -2342,12 +2347,6 @@ static int sock_hash_ctx_update_elem(struct bpf_sock_ops_kern *skops,
> goto bucket_err;
> }
>
> - psock = smap_psock_sk(sock);
> - if (unlikely(!psock)) {
> - err = -EINVAL;
> - goto bucket_err;
> - }
> -
> rcu_assign_pointer(e->hash_link, l_new);
> rcu_assign_pointer(e->htab,
> container_of(map, struct bpf_htab, map));
> @@ -2370,12 +2369,10 @@ static int sock_hash_ctx_update_elem(struct bpf_sock_ops_kern *skops,
> raw_spin_unlock_bh(&b->lock);
> return 0;
> bucket_err:
> + smap_release_sock(psock, sock);
> raw_spin_unlock_bh(&b->lock);
> err:
> kfree(e);
> - psock = smap_psock_sk(sock);
> - if (psock)
> - smap_release_sock(psock, sock);
> return err;
> }
>
>
Thanks,
Daniel
^ permalink raw reply
* Re: pull-request: wireless-drivers 2018-07-03
From: David Miller @ 2018-07-03 14:29 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87tvpgr3n4.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Tue, 03 Jul 2018 13:54:07 +0300
> this is the first pull request to net tree for 4.18, more info below and
> please let me know if you have any problems.
Pulled, thanks Kalle.
^ permalink raw reply
* Re: [PATCH] staging: fsl-dpaa2/ethsw: Update maintainers for Ethernet Switch driver
From: Greg KH @ 2018-07-03 14:29 UTC (permalink / raw)
To: Razvan Stefanescu; +Cc: devel, netdev, linux-kernel, ioana.ciornei
In-Reply-To: <1530626724-20833-1-git-send-email-razvan.stefanescu@nxp.com>
On Tue, Jul 03, 2018 at 05:05:24PM +0300, Razvan Stefanescu wrote:
> Signed-off-by: Razvan Stefanescu <razvan.stefanescu@nxp.com>
No changelog text?
> ---
> MAINTAINERS | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b6d0cc0..0d36546 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4434,7 +4434,8 @@ S: Maintained
> F: drivers/staging/fsl-dpaa2/ethernet
>
> DPAA2 ETHERNET SWITCH DRIVER
> -M: Razvan Stefanescu <razvan.stefanescu@nxp.com>
> +M: Ioana Radulescu <ruxandra.radulescu@nxp.com>
> +M: Ioana Ciornei <ioana.ciornei@nxp.com>
No ack/signed-off-by from either of these developers?
I can't take this as-is :(
thanks,
greg k-h
^ permalink raw reply
* [PATCH net] smsc75xx: Add workaround for gigabit link up hardware errata.
From: Yuiko Oshino @ 2018-07-03 15:21 UTC (permalink / raw)
To: davem; +Cc: netdev, UNGLinuxDriver
In certain conditions, the device may not be able to link in gigabit mode. This software workaround ensures that the device will not enter the failure state.
Fixes: d0cad871703b898a442e4049c532ec39168e5b57 ("SMSC75XX USB 2.0 Gigabit Ethernet Devices")
Signed-off-by: Yuiko Oshino <yuiko.oshino@microchip.com>
---
drivers/net/usb/smsc75xx.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 62 insertions(+)
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 7a6a1fe..05553d2 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -82,6 +82,9 @@ static bool turbo_mode = true;
module_param(turbo_mode, bool, 0644);
MODULE_PARM_DESC(turbo_mode, "Enable multiple frames per Rx transaction");
+static int smsc75xx_link_ok_nopm(struct usbnet *dev);
+static int smsc75xx_phy_gig_workaround(struct usbnet *dev);
+
static int __must_check __smsc75xx_read_reg(struct usbnet *dev, u32 index,
u32 *data, int in_pm)
{
@@ -852,6 +855,9 @@ static int smsc75xx_phy_initialize(struct usbnet *dev)
return -EIO;
}
+ /* phy workaround for gig link */
+ smsc75xx_phy_gig_workaround(dev);
+
smsc75xx_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE,
ADVERTISE_ALL | ADVERTISE_CSMA | ADVERTISE_PAUSE_CAP |
ADVERTISE_PAUSE_ASYM);
@@ -987,6 +993,62 @@ static int smsc75xx_wait_ready(struct usbnet *dev, int in_pm)
return -EIO;
}
+static int smsc75xx_phy_gig_workaround(struct usbnet *dev)
+{
+ struct mii_if_info *mii = &dev->mii;
+ int ret = 0, timeout = 0;
+ u32 buf, link_up = 0;
+
+ /* Set the phy in Gig loopback */
+ smsc75xx_mdio_write(dev->net, mii->phy_id, MII_BMCR, 0x4040);
+
+ /* Wait for the link up */
+ do {
+ link_up = smsc75xx_link_ok_nopm(dev);
+ usleep_range(10000, 20000);
+ timeout++;
+ } while ((!link_up) && (timeout < 1000));
+
+ if (timeout >= 1000) {
+ netdev_warn(dev->net, "Timeout waiting for PHY link up\n");
+ return -EIO;
+ }
+
+ /* phy reset */
+ ret = smsc75xx_read_reg(dev, PMT_CTL, &buf);
+ if (ret < 0) {
+ netdev_warn(dev->net, "Failed to read PMT_CTL: %d\n", ret);
+ return ret;
+ }
+
+ buf |= PMT_CTL_PHY_RST;
+
+ ret = smsc75xx_write_reg(dev, PMT_CTL, buf);
+ if (ret < 0) {
+ netdev_warn(dev->net, "Failed to write PMT_CTL: %d\n", ret);
+ return ret;
+ }
+
+ timeout = 0;
+ do {
+ usleep_range(10000, 20000);
+ ret = smsc75xx_read_reg(dev, PMT_CTL, &buf);
+ if (ret < 0) {
+ netdev_warn(dev->net, "Failed to read PMT_CTL: %d\n",
+ ret);
+ return ret;
+ }
+ timeout++;
+ } while ((buf & PMT_CTL_PHY_RST) && (timeout < 100));
+
+ if (timeout >= 100) {
+ netdev_warn(dev->net, "timeout waiting for PHY Reset\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
static int smsc75xx_reset(struct usbnet *dev)
{
struct smsc75xx_priv *pdata = (struct smsc75xx_priv *)(dev->data[0]);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net] r8169: fix mac address change
From: David Miller @ 2018-07-03 14:28 UTC (permalink / raw)
To: hkallweit1; +Cc: vinschen, netdev
In-Reply-To: <1770bc23-75f1-d462-b8a3-61e81ade4c3c@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Mon, 2 Jul 2018 22:49:35 +0200
> Network core refuses to change mac address because flag
> IFF_LIVE_ADDR_CHANGE isn't set. Set this missing flag.
>
> Fixes: 1f7aa2bc268e ("r8169: simplify rtl_set_mac_address")
> Reported-by: Corinna Vinschen <vinschen@redhat.com>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH] lib: rhashtable: Correct self-assignment in rhashtable.c
From: David Miller @ 2018-07-03 14:26 UTC (permalink / raw)
To: rishabhb; +Cc: netdev, neilb, tgraf, herbert, linux-arm-msm
In-Reply-To: <1530549334-13890-1-git-send-email-rishabhb@codeaurora.org>
From: Rishabh Bhatnagar <rishabhb@codeaurora.org>
Date: Mon, 2 Jul 2018 09:35:34 -0700
> In file lib/rhashtable.c line 777, skip variable is assigned to
> itself. The following error was observed:
>
> lib/rhashtable.c:777:41: warning: explicitly assigning value of
> variable of type 'int' to itself [-Wself-assign] error, forbidden
> warning: rhashtable.c:777
> This error was found when compiling with Clang 6.0. Change it to iter->skip.
>
> Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
> Reviewed-by: NeilBrown <neilb@suse.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v3 0/5] net: aquantia: various ethtool ops implementation
From: David Miller @ 2018-07-03 14:24 UTC (permalink / raw)
To: igor.russkikh; +Cc: netdev, darcari, pavel.belous
In-Reply-To: <cover.1530537192.git.igor.russkikh@aquantia.com>
From: Igor Russkikh <igor.russkikh@aquantia.com>
Date: Mon, 2 Jul 2018 17:03:34 +0300
> In this patchset Anton Mikaev and I added some useful ethtool operations:
> - ring size changes
> - link renegotioation
> - flow control management
>
> The patch also improves init/deinit sequence.
>
> V3 changes:
> - After review and analysis it is clear that rtnl lock (which is
> captured by default on ethtool ops) is enough to secure possible
> overlapping of dev open/close. Thus, just dropping internal mutex.
>
> V2 changes:
> - using mutex to secure simultaneous dev close/open
> - using state var to store/restore dev state
Series applied.
^ permalink raw reply
* Re: [PATCH] net: stmmac_tc: use 64-bit arithmetic instead of 32-bit
From: David Miller @ 2018-07-03 14:21 UTC (permalink / raw)
To: gustavo; +Cc: peppe.cavallaro, alexandre.torgue, joabreu, netdev, linux-kernel
In-Reply-To: <20180702120932.GA13079@embeddedor.com>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Mon, 2 Jul 2018 07:09:32 -0500
> Add suffix UL to constant 1024 in order to give the compiler complete
> information about the proper arithmetic to use. Notice that this
> constant is used in a context that expects an expression of type
> u64 (64 bits, unsigned) and following expressions are currently
> being evaluated using 32-bit arithmetic:
>
> qopt->idleslope * 1024 * ptr
> qopt->hicredit * 1024 * 8
> qopt->locredit * 1024 * 8
>
> Addresses-Coverity-ID: 1470246 ("Unintentional integer overflow")
> Addresses-Coverity-ID: 1470248 ("Unintentional integer overflow")
> Addresses-Coverity-ID: 1470249 ("Unintentional integer overflow")
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [net-next,v1] tcp: Improve setsockopt() TCP_USER_TIMEOUT accuracy
From: Neal Cardwell @ 2018-07-03 14:13 UTC (permalink / raw)
To: Jonathan Maxwell
Cc: David Miller, Eric Dumazet, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Netdev, LKML, jmaxwell
In-Reply-To: <20180703072113.19910-1-jmaxwell37@gmail.com>
On Tue, Jul 3, 2018 at 3:21 AM Jon Maxwell <jmaxwell37@gmail.com> wrote:
>
> v1 contains the following suggestions by Neal Cardwell:
>
> 1) Fix up units mismatch regarding msec/jiffies.
> 2) Address possiblility of time_remaining being negative.
> 3) Add a helper routine to do the rto calculation.
>
> Every time the TCP retransmission timer fires. It checks to see if there is a
> timeout before scheduling the next retransmit timer. The retransmit interval
> between each retransmission increases exponentially. The issue is that in order
> for the timeout to occur the retransmit timer needs to fire again. If the user
> timeout check happens after the 9th retransmit for example. It needs to wait for
> the 10th retransmit timer to fire in order to evaluate whether a timeout has
> occurred or not. If the interval is large enough then the timeout will be
> inaccurate.
>
> For example with a TCP_USER_TIMEOUT of 10 seconds without patch:
>
> 1st retransmit:
>
> 22:25:18.973488 IP host1.49310 > host2.search-agent: Flags [.]
>
> Last retransmit:
>
> 22:25:26.205499 IP host1.49310 > host2.search-agent: Flags [.]
>
> Timeout:
>
> send: Connection timed out
> Sun Jul 1 22:25:34 EDT 2018
>
> We can see that last retransmit took ~7 seconds. Which pushed the total
> timeout to ~15 seconds instead of the expected 10 seconds. This gets more
> inaccurate the larger the TCP_USER_TIMEOUT value. As the interval increases.
>
> Add tcp_clamp_rto_to_user_timeout() to determine if the user rto has expired.
> Or whether the rto interval needs to be recalculated. Use the original interval
> if user rto is not set.
>
> Test results with the patch is the expected 10 second timeout:
>
> 1st retransmit:
>
> 01:37:59.022555 IP host1.49310 > host2.search-agent: Flags [.]
>
> Last retransmit:
>
> 01:38:06.486558 IP host1.49310 > host2.search-agent: Flags [.]
>
> Timeout:
>
> send: Connection timed out
> Mon Jul 2 01:38:09 EDT 2018
>
> Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com>
> ---
> net/ipv4/tcp_timer.c | 21 ++++++++++++++++++++-
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
> index 3b3611729928..82c2a3b3713c 100644
> --- a/net/ipv4/tcp_timer.c
> +++ b/net/ipv4/tcp_timer.c
> @@ -22,6 +22,23 @@
> #include <linux/gfp.h>
> #include <net/tcp.h>
>
> +static __u32 tcp_clamp_rto_to_user_timeout(struct sock *sk)
> +{
> + struct inet_connection_sock *icsk = inet_csk(sk);
> + __u32 rto = icsk->icsk_rto;
> + __u32 elapsed, user_timeout;
> +
> + if (!icsk->icsk_user_timeout)
> + return rto;
> + elapsed = tcp_time_stamp(tcp_sk(sk)) - tcp_sk(sk)->retrans_stamp;
Thanks. The local logic seems OK to me now, but from reading
retransmits_timed_out() it looks like at this point in the code we are
not guaranteed that tcp_sk(sk)->retrans_stamp is initialized to
something non-zero. So we probably need a preceding preparatory patch
that factors out the first few lines of retransmits_timed_out() into
a helper frunction to get the start_ts for use in this calculation.
Perhaps:
u32 tcp_retrans_stamp():
start_ts = tcp_sk(sk)->retrans_stamp;
if (unlikely(!start_ts)) {
head = tcp_rtx_queue_head(sk);
if (!head)
return 0;
start_ts = tcp_skb_timestamp(head);
}
return start_ts;
And then the new tcp_clamp_rto_to_user_timeout() can use the helper:
...
retrans_stamp = tcp_retransmit_stamp(sk);
if (!retrans_stamp)
return rto;
elapsed = tcp_time_stamp(tcp_sk(sk)) - retrans_stamp;
...
Eric wrote those lines to recalculate start_ts, so we may want to wait
until Eric returns to review this before merging the resulting patch
series.
neal
^ permalink raw reply
* [PATCH] staging: fsl-dpaa2/ethsw: Update maintainers for Ethernet Switch driver
From: Razvan Stefanescu @ 2018-07-03 14:05 UTC (permalink / raw)
To: gregkh; +Cc: devel, linux-kernel, netdev, ruxandra.radulescu, ioana.ciornei
Signed-off-by: Razvan Stefanescu <razvan.stefanescu@nxp.com>
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index b6d0cc0..0d36546 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4434,7 +4434,8 @@ S: Maintained
F: drivers/staging/fsl-dpaa2/ethernet
DPAA2 ETHERNET SWITCH DRIVER
-M: Razvan Stefanescu <razvan.stefanescu@nxp.com>
+M: Ioana Radulescu <ruxandra.radulescu@nxp.com>
+M: Ioana Ciornei <ioana.ciornei@nxp.com>
L: linux-kernel@vger.kernel.org
S: Maintained
F: drivers/staging/fsl-dpaa2/ethsw
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 net-next 1/3] rds: Changing IP address internal representation to struct in6_addr
From: Ka-Cheong Poon @ 2018-07-03 14:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev, santosh.shilimkar, rds-devel
In-Reply-To: <20180630.175049.1607480149466051192.davem@davemloft.net>
On 06/30/2018 04:50 PM, David Miller wrote:
> From: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
> Date: Wed, 27 Jun 2018 03:23:27 -0700
>
>> This patch changes the internal representation of an IP address to use
>> struct in6_addr. IPv4 address is stored as an IPv4 mapped address.
>> All the functions which take an IP address as argument are also
>> changed to use struct in6_addr. But RDS socket layer is not modified
>> such that it still does not accept IPv6 address from an application.
>> And RDS layer does not accept nor initiate IPv6 connections.
>>
>> v2: Fixed sparse warnings.
>>
>> Signed-off-by: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
>
> I really don't like this.
>
> An ipv4 mapped ipv6 address is not the same as an ipv4 address.
>
> You are effectively preventing the use of ipv6 connections
> using ipv4 mapped addresses.
Could you please clarify what is meant by an IPv6
connections using IPv4 mapped address? An IPv6 packet
cannot use an IPv4 mapped address as source or destination
address. Do you mean an app uses an IPv4 mapped address
in a struct sockaddr_in6 to set up an IPv4 connection?
Please note that this patch is patch #1. This patch
alone does not support RDS/IPv6. Hence this patch has
checks to prevent an app to use IPv6 address. Those
checks will be removed in patch #2.
> Also, assuming the sockaddr type based upon size is wrong.
> You have to check the family field, then you can decide
> to interpret the rest of the sockaddr in one way or another
> and also validate it's length.
>
--
K. Poon
ka-cheong.poon@oracle.com
^ permalink raw reply
* Re: [GIT] Networking
From: Ursula Braun @ 2018-07-03 13:52 UTC (permalink / raw)
To: Linus Torvalds, David Miller
Cc: Andrew Morton, Network Development, Linux Kernel Mailing List
In-Reply-To: <CA+55aFw4+YPQUh9RTJBzxdvJ9Xf_s4soPLbCXsXuhHT0TjPtZw@mail.gmail.com>
On 07/02/2018 08:29 PM, Linus Torvalds wrote:
> On Mon, Jul 2, 2018 at 6:03 AM David Miller <davem@davemloft.net> wrote:
>>
>> are available in the Git repository at:
>>
>> gitolite@ra.kernel.org:/pub/scm/linux/kernel/git/davem/net.git
>
> So the af_smc poll fixes clashed with the revert of the commit that
> caused those fixed to be done in the first place.
>
> See the changes to net/smc/af_smc.c in my commit
>
> a11e1d432b51 ("Revert changes to convert to ->poll_mask() and aio
> IOCB_CMD_POLL")
>
> vs Ursula's
>
> 24ac3a08e658 ("net/smc: rebuild nonblocking connect")
>
> I (briefly) considered just dropping Ursula's changes entirely, but
> they looked like a nice cleanup on their own, so what I did instead
> was to try to fix up my revert instead.
>
> That involved removing the release_sock/lock_sock pair around the
> ->poll() call, and removing the special "sock_poll_wait()" that got
> re-introduced by my revert, but that Ursula's changes seem to obviate.
>
> However, while I can look at the code and say "my merge makes sense to
> me", (a) I can't test it, (b) I don't actually know the rules for SMC
> sockets in the first place, and (c) I may be just incompetent.
>
> So Ursula - mind checking and testing the end result? I _think_ it's
> fine and the merge looked pretty obvious, but maybe af_smc got broken
> again.
>
Thanks Linus for your revert. I run a test, and found it is almost fine.
Just these 2 lines are missing:
---
net/smc/af_smc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index e017b6a4452b..e7d7ff87499e 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -1345,6 +1345,8 @@ static __poll_t smc_poll(struct file *file, struct socket *sock,
if (sk->sk_err)
mask |= EPOLLERR;
} else {
+ if (sk->sk_state != SMC_CLOSED)
+ sock_poll_wait(file, sk_sleep(sk), wait);
if (sk->sk_err)
mask |= EPOLLERR;
if ((sk->sk_shutdown == SHUTDOWN_MASK) ||
--
> [ It's still going through by basic build tests, so I haven't pushed
> out my merge yet, but it should be in the usual places in a short
> while ]
>
> Thanks,
>
> Linus
>
Regards, Ursula
^ permalink raw reply related
* Re: [PATCH] 6lowpan: iphc: reset mac_header after decompress to fix panic
From: Alexander Aring @ 2018-07-03 13:48 UTC (permalink / raw)
To: Michael Scott
Cc: Alexander Aring, Jukka Rissanen, David S. Miller, linux-bluetooth,
linux-wpan, netdev, linux-kernel
In-Reply-To: <20180619234406.8217-1-michael@opensourcefoundries.com>
On Tue, Jun 19, 2018 at 04:44:06PM -0700, Michael Scott wrote:
> After decompression of 6lowpan socket data, an IPv6 header is inserted
> before the existing socket payload. After this, we reset the
> network_header value of the skb to account for the difference in payload
> size from prior to decompression + the addition of the IPv6 header.
>
> However, we fail to reset the mac_header value.
>
> Leaving the mac_header value untouched here, can cause a calculation
> error in net/packet/af_packet.c packet_rcv() function when an
> AF_PACKET socket is opened in SOCK_RAW mode for use on a 6lowpan
> interface.
>
> On line 2088, the data pointer is moved backward by the value returned
> from skb_mac_header(). If skb->data is adjusted so that it is before
> the skb->head pointer (which can happen when an old value of mac_header
> is left in place) the kernel generates a panic in net/core/skbuff.c
> line 1717.
>
> This panic can be generated by BLE 6lowpan interfaces (such as bt0) and
> 802.15.4 interfaces (such as lowpan0) as they both use the same 6lowpan
> sources for compression and decompression.
>
> Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
Acked-by: Alexander Aring <aring@mojatatu.com>
Thanks!
- Alex
^ permalink raw reply
* Re: [PATCH net] net/ipv6: Revert attempt to simplify route replace and append
From: Ido Schimmel @ 2018-07-03 13:43 UTC (permalink / raw)
To: dsahern; +Cc: netdev, sharpd, Thomas.Winter, David Ahern, petrm
In-Reply-To: <20180702220312.14590-1-dsahern@kernel.org>
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?
Also, Petr added a multipath test that relies on IPv6 device only
nexthops. See commit 54818c4c4b937.
^ permalink raw reply
* [PATCH net-next] net: sched: act_pedit: fix possible memory leak in tcf_pedit_init()
From: Wei Yongjun @ 2018-07-03 13:45 UTC (permalink / raw)
To: Jamal Hadi Salim, Cong Wang, Jiri Pirko, Amir Vadai
Cc: Wei Yongjun, netdev, kernel-janitors
'keys_ex' is malloced by tcf_pedit_keys_ex_parse() in tcf_pedit_init()
but not all of the error handle path free it, this may cause memory
leak. This patch fix it.
Fixes: 71d0ed7079df ("net/act_pedit: Support using offset relative to the conventional network headers")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
net/sched/act_pedit.c | 25 ++++++++++++++++---------
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/net/sched/act_pedit.c b/net/sched/act_pedit.c
index 55bc96b..e43aef2 100644
--- a/net/sched/act_pedit.c
+++ b/net/sched/act_pedit.c
@@ -175,32 +175,35 @@ static int tcf_pedit_init(struct net *net, struct nlattr *nla,
if (!tcf_idr_check(tn, parm->index, a, bind)) {
if (!parm->nkeys) {
NL_SET_ERR_MSG_MOD(extack, "Pedit requires keys to be passed");
- return -EINVAL;
+ ret = -EINVAL;
+ goto out_free;
}
ret = tcf_idr_create(tn, parm->index, est, a,
&act_pedit_ops, bind, false);
if (ret)
- return ret;
+ goto out_free;
p = to_pedit(*a);
keys = kmalloc(ksize, GFP_KERNEL);
if (!keys) {
tcf_idr_release(*a, bind);
- kfree(keys_ex);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto out_free;
}
ret = ACT_P_CREATED;
} else {
if (bind)
- return 0;
+ goto out_free;
tcf_idr_release(*a, bind);
- if (!ovr)
- return -EEXIST;
+ if (!ovr) {
+ ret = -EEXIST;
+ goto out_free;
+ }
p = to_pedit(*a);
if (p->tcfp_nkeys && p->tcfp_nkeys != parm->nkeys) {
keys = kmalloc(ksize, GFP_KERNEL);
if (!keys) {
- kfree(keys_ex);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto out_free;
}
}
}
@@ -222,6 +225,10 @@ static int tcf_pedit_init(struct net *net, struct nlattr *nla,
if (ret == ACT_P_CREATED)
tcf_idr_insert(tn, *a);
return ret;
+out_free:
+ kfree(keys_ex);
+ return ret;
+
}
static void tcf_pedit_cleanup(struct tc_action *a)
^ permalink raw reply related
* [PATCH] rhashtable: add restart routine in rhashtable_free_and_destroy()
From: Taehee Yoo @ 2018-07-03 13:19 UTC (permalink / raw)
To: davem, tgraf, herbert; +Cc: netdev, fw, pablo, ap420073
rhashtable_free_and_destroy() cancels re-hash deferred work
then walks and destroys elements. at this moment, some elements can be
still in future_tbl. that elements are not destroyed.
test case:
nft_rhash_destroy() calls rhashtable_free_and_destroy() to destroy
all elements of sets before destroying sets and chains.
But rhashtable_free_and_destroy() doesn't destroy elements of future_tbl.
so that splat occurred.
test script:
%cat test.nft
table ip aa {
map map1 {
type ipv4_addr : verdict;
elements = {
0 : jump a0,
1 : jump a0,
2 : jump a0,
3 : jump a0,
4 : jump a0,
5 : jump a0,
6 : jump a0,
7 : jump a0,
8 : jump a0,
9 : jump a0,
}
}
chain a0 {
}
}
flush ruleset
table ip aa {
map map1 {
type ipv4_addr : verdict;
elements = {
0 : jump a0,
1 : jump a0,
2 : jump a0,
3 : jump a0,
4 : jump a0,
5 : jump a0,
6 : jump a0,
7 : jump a0,
8 : jump a0,
9 : jump a0,
}
}
chain a0 {
}
}
flush ruleset
%while :; do nft -f test.nft; done
Splat looks like:
[ 200.795603] kernel BUG at net/netfilter/nf_tables_api.c:1363!
[ 200.806944] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
[ 200.812253] CPU: 1 PID: 1582 Comm: nft Not tainted 4.17.0+ #24
[ 200.820297] Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 07/08/2015
[ 200.830309] RIP: 0010:nf_tables_chain_destroy.isra.34+0x62/0x240 [nf_tables]
[ 200.838317] Code: 43 50 85 c0 74 26 48 8b 45 00 48 8b 4d 08 ba 54 05 00 00 48 c7 c6 60 6d 29 c0 48 c7 c7 c0 65 29 c0 4c 8b 40 08 e8 58 e5 fd f8 <0f> 0b 48 89 da 48 b8 00 00 00 00 00 fc ff
[ 200.860366] RSP: 0000:ffff880118dbf4d0 EFLAGS: 00010282
[ 200.866354] RAX: 0000000000000061 RBX: ffff88010cdeaf08 RCX: 0000000000000000
[ 200.874355] RDX: 0000000000000061 RSI: 0000000000000008 RDI: ffffed00231b7e90
[ 200.882361] RBP: ffff880118dbf4e8 R08: ffffed002373bcfb R09: ffffed002373bcfa
[ 200.890354] R10: 0000000000000000 R11: ffffed002373bcfb R12: dead000000000200
[ 200.898356] R13: dead000000000100 R14: ffffffffbb62af38 R15: dffffc0000000000
[ 200.906354] FS: 00007fefc31fd700(0000) GS:ffff88011b800000(0000) knlGS:0000000000000000
[ 200.915533] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 200.922355] CR2: 0000557f1c8e9128 CR3: 0000000106880000 CR4: 00000000001006e0
[ 200.930353] Call Trace:
[ 200.932351] ? nf_tables_commit+0x26f6/0x2c60 [nf_tables]
[ 200.939525] ? nf_tables_setelem_notify.constprop.49+0x1a0/0x1a0 [nf_tables]
[ 200.947525] ? nf_tables_delchain+0x6e0/0x6e0 [nf_tables]
[ 200.952383] ? nft_add_set_elem+0x1700/0x1700 [nf_tables]
[ 200.959532] ? nla_parse+0xab/0x230
[ 200.963529] ? nfnetlink_rcv_batch+0xd06/0x10d0 [nfnetlink]
[ 200.968384] ? nfnetlink_net_init+0x130/0x130 [nfnetlink]
[ 200.975525] ? debug_show_all_locks+0x290/0x290
[ 200.980363] ? debug_show_all_locks+0x290/0x290
[ 200.986356] ? sched_clock_cpu+0x132/0x170
[ 200.990352] ? find_held_lock+0x39/0x1b0
[ 200.994355] ? sched_clock_local+0x10d/0x130
[ 200.999531] ? memset+0x1f/0x40
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
---
lib/rhashtable.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index 0e04947..8ea27fa 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -1134,6 +1134,7 @@ void rhashtable_free_and_destroy(struct rhashtable *ht,
mutex_lock(&ht->mutex);
tbl = rht_dereference(ht->tbl, ht);
if (free_fn) {
+restart:
for (i = 0; i < tbl->size; i++) {
struct rhash_head *pos, *next;
@@ -1147,9 +1148,11 @@ void rhashtable_free_and_destroy(struct rhashtable *ht,
rht_dereference(pos->next, ht) : NULL)
rhashtable_free_one(ht, pos, free_fn, arg);
}
+ tbl = rht_dereference(tbl->future_tbl, ht);
+ if (tbl)
+ goto restart;
}
-
- bucket_table_free(tbl);
+ bucket_table_free(rht_dereference(ht->tbl, ht));
mutex_unlock(&ht->mutex);
}
EXPORT_SYMBOL_GPL(rhashtable_free_and_destroy);
--
2.9.3
^ permalink raw reply related
* Re: [PATCH net-next v2 1/2] tcp: notify when a delayed ack is sent
From: Neal Cardwell @ 2018-07-03 13:14 UTC (permalink / raw)
To: Yuchung Cheng
Cc: Lawrence Brakmo, Netdev, Kernel Team, bmatheny, ast, Steve Ibanez,
Eric Dumazet
In-Reply-To: <CAK6E8=f2n9PKwne5COvT0sFyFymfJDDeE9Vxk6PeTpOEwg7z8w@mail.gmail.com>
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://patchwork.ozlabs.org/patch/935233/
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
^ permalink raw reply
* [PATCH iproute2] tc: Fix output of ip attributes
From: Roi Dayan @ 2018-07-03 12:54 UTC (permalink / raw)
To: netdev; +Cc: Jiri Pirko, Or Gerlitz, Roi Dayan
Example output is of tos and ttl.
Befoe this fix the format used %x caused output of the pointer
instead of the intended string created in the out variable.
Fixes: e28b88a464c4 ("tc: jsonify flower filter")
Signed-off-by: Roi Dayan <roid@mellanox.com>
---
tc/f_flower.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tc/f_flower.c b/tc/f_flower.c
index c710765179fb..1dfd57d286d9 100644
--- a/tc/f_flower.c
+++ b/tc/f_flower.c
@@ -1134,7 +1134,7 @@ static void flower_print_ip_attr(char *name, struct rtattr *key_attr,
if (mask_attr)
sprintf(out + done, "/%x", rta_getattr_u8(mask_attr));
- sprintf(namefrm, "\n %s %%x", name);
+ sprintf(namefrm, "\n %s %%s", name);
print_string(PRINT_ANY, name, namefrm, out);
}
--
2.7.5
^ permalink raw reply related
* [PATCH net-next 2/2] selftests: forwarding: test for bridge port isolation
From: Nikolay Aleksandrov @ 2018-07-03 12:42 UTC (permalink / raw)
To: netdev; +Cc: roopa, dsahern, idosch, stephen, Nikolay Aleksandrov
In-Reply-To: <20180703124244.6864-1-nikolay@cumulusnetworks.com>
This test checks if the bridge port isolation feature works as expected
by performing ping/ping6 tests between hosts that are isolated (should
not work) and between an isolated and non-isolated hosts (should work).
Same test is performed for flooding from and to isolated and
non-isolated ports.
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
.../net/forwarding/bridge_port_isolation.sh | 151 +++++++++++++++++++++
1 file changed, 151 insertions(+)
create mode 100755 tools/testing/selftests/net/forwarding/bridge_port_isolation.sh
diff --git a/tools/testing/selftests/net/forwarding/bridge_port_isolation.sh b/tools/testing/selftests/net/forwarding/bridge_port_isolation.sh
new file mode 100755
index 000000000000..a43b4645c4de
--- /dev/null
+++ b/tools/testing/selftests/net/forwarding/bridge_port_isolation.sh
@@ -0,0 +1,151 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+ALL_TESTS="ping_ipv4 ping_ipv6 flooding"
+NUM_NETIFS=6
+CHECK_TC="yes"
+source lib.sh
+
+h1_create()
+{
+ simple_if_init $h1 192.0.2.1/24 2001:db8:1::1/64
+}
+
+h1_destroy()
+{
+ simple_if_fini $h1 192.0.2.1/24 2001:db8:1::1/64
+}
+
+h2_create()
+{
+ simple_if_init $h2 192.0.2.2/24 2001:db8:1::2/64
+}
+
+h2_destroy()
+{
+ simple_if_fini $h2 192.0.2.2/24 2001:db8:1::2/64
+}
+
+h3_create()
+{
+ simple_if_init $h3 192.0.2.3/24 2001:db8:1::3/64
+}
+
+h3_destroy()
+{
+ simple_if_fini $h3 192.0.2.3/24 2001:db8:1::3/64
+}
+
+switch_create()
+{
+ ip link add dev br0 type bridge
+
+ ip link set dev $swp1 master br0
+ ip link set dev $swp2 master br0
+ ip link set dev $swp3 master br0
+
+ ip link set dev $swp1 type bridge_slave isolated on
+ check_err $? "Can't set isolation on port $swp1"
+ ip link set dev $swp2 type bridge_slave isolated on
+ check_err $? "Can't set isolation on port $swp2"
+ ip link set dev $swp3 type bridge_slave isolated off
+ check_err $? "Can't disable isolation on port $swp3"
+
+ ip link set dev br0 up
+ ip link set dev $swp1 up
+ ip link set dev $swp2 up
+ ip link set dev $swp3 up
+}
+
+switch_destroy()
+{
+ ip link set dev $swp3 down
+ ip link set dev $swp2 down
+ ip link set dev $swp1 down
+
+ ip link del dev br0
+}
+
+setup_prepare()
+{
+ h1=${NETIFS[p1]}
+ swp1=${NETIFS[p2]}
+
+ swp2=${NETIFS[p3]}
+ h2=${NETIFS[p4]}
+
+ swp3=${NETIFS[p5]}
+ h3=${NETIFS[p6]}
+
+ vrf_prepare
+
+ h1_create
+ h2_create
+ h3_create
+
+ switch_create
+}
+
+cleanup()
+{
+ pre_cleanup
+
+ switch_destroy
+
+ h3_destroy
+ h2_destroy
+ h1_destroy
+
+ vrf_cleanup
+}
+
+ping_ipv4()
+{
+ RET=0
+ ping_do $h1 192.0.2.2
+ check_fail $? "Ping worked when it should not have"
+
+ RET=0
+ ping_do $h3 192.0.2.2
+ check_err $? "Ping didn't work when it should have"
+
+ log_test "Isolated port ping"
+}
+
+ping_ipv6()
+{
+ RET=0
+ ping6_do $h1 2001:db8:1::2
+ check_fail $? "Ping6 worked when it should not have"
+
+ RET=0
+ ping6_do $h3 2001:db8:1::2
+ check_err $? "Ping6 didn't work when it should have"
+
+ log_test "Isolated port ping6"
+}
+
+flooding()
+{
+ local mac=de:ad:be:ef:13:37
+ local ip=192.0.2.100
+
+ RET=0
+ flood_test_do false $mac $ip $h1 $h2
+ check_err $? "Packet was flooded when it should not have been"
+
+ RET=0
+ flood_test_do true $mac $ip $h3 $h2
+ check_err $? "Packet was not flooded when it should have been"
+
+ log_test "Isolated port flooding"
+}
+
+trap cleanup EXIT
+
+setup_prepare
+setup_wait
+
+tests_run
+
+exit $EXIT_STATUS
--
2.11.0
^ permalink raw reply related
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