* [PATCH net-next 00/23] bnxt_en: Add support for new 57500 chips.
From: Michael Chan @ 2018-10-14 11:02 UTC (permalink / raw)
To: davem; +Cc: netdev
This patch-set is larger than normal because I wanted a complete series
to add basic support for the new 57500 chips. The new chips have the
following main differences compared to legacy chips:
1. Requires the PF driver to allocate DMA context memory as a backing
store.
2. New NQ (notification queue) for interrupt events.
3. One or more CP rings can be associated with an NQ.
4. 64-bit doorbells.
Most other structures and firmware APIs are compatible with legacy
devices with some exceptions. For example, ring groups are no longer
used and RSS table format has changed.
The patch-set includes the usual firmware spec. update, some refactoring
and restructuring, and adding the new code to add basic support for the
new class of devices.
Michael Chan (23):
bnxt_en: Update firmware interface spec. to 1.10.0.3.
bnxt_en: Add additional extended port statistics.
bnxt_en: Add maximum extended request length fw message support.
bnxt_en: Update interrupt coalescing logic.
bnxt_en: Refactor bnxt_ring_struct.
bnxt_en: Add new flags to setup new page table PTE bits on newer
devices.
bnxt_en: Check context memory requirements from firmware.
bnxt_en: Configure context memory on new devices.
bnxt_en: Add 57500 new chip ID and basic structures.
bnxt_en: Re-structure doorbells.
bnxt_en: Adjust MSIX and ring groups for 57500 series chips.
bnxt_en: Modify the ring reservation functions for 57500 series chips.
bnxt_en: Allocate completion ring structures for 57500 series chips.
bnxt_en: Add helper functions to get firmware CP ring ID.
bnxt_en: Modify bnxt_ring_alloc_send_msg() to support 57500 chips.
bnxt_en: Allocate/Free CP rings for 57500 series chips.
bnxt_en: Increase RSS context array count and skip ring groups on
57500 chips.
bnxt_en: Add RSS support for 57500 chips.
bnxt_en: Use bnxt_cp_ring_info struct pointer as parameter for RX
path.
bnxt_en: Add coalescing setup for 57500 chips.
bnxt_en: Refactor bnxt_poll_work().
bnxt_en: Add new NAPI poll function for 57500 chips.
bnxt_en: Add PCI ID for BCM57508 device.
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 1671 +++++++++++++++++----
drivers/net/ethernet/broadcom/bnxt/bnxt.h | 250 ++-
drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 112 +-
drivers/net/ethernet/broadcom/bnxt/bnxt_hsi.h | 310 ++--
drivers/net/ethernet/broadcom/bnxt/bnxt_xdp.c | 2 +-
5 files changed, 1944 insertions(+), 401 deletions(-)
--
2.5.1
^ permalink raw reply
* net/wan: hostess_sv11 + z85230 problems
From: Randy Dunlap @ 2018-10-14 18:09 UTC (permalink / raw)
To: netdev@vger.kernel.org, LKML; +Cc: Krzysztof Halasa
kernel 4.19-rc7, on i386, with NO wan/hdlc/hostess/z85230 hardware:
modprobe hostess_sv11 + autoload of z85230 give:
[ 3162.494393] calling hdlc_module_init+0x0/0x1000 [hdlc] @ 4024
[ 3162.495528] hdlc: HDLC support module revision 1.22
[ 3162.496877] initcall hdlc_module_init+0x0/0x1000 [hdlc] returned 0 after 1312 usecs
[ 3162.500840] calling z85230_init_driver+0x0/0x1000 [z85230] @ 4024
[ 3162.502877] Generic Z85C30/Z85230 interface driver v0.02
[ 3162.503895] initcall z85230_init_driver+0x0/0x1000 [z85230] returned 0 after 987 usecs
[ 3162.506869] calling init_module+0x0/0x270 [hostess_sv11] @ 4024
[ 3162.508065] INFO: trying to register non-static key.
[ 3162.508986] the code is fine but needs lockdep annotation.
[ 3162.509026] turning off the locking correctness validator.
[ 3162.509026] CPU: 1 PID: 4024 Comm: modprobe Not tainted 4.19.0-rc7 #2
[ 3162.511877] Hardware name: Dell Inc. Inspiron 1318 /0C236D, BIOS A04 01/15/2009
[ 3162.511877] Call Trace:
[ 3162.511877] <IRQ>
[ 3162.511877] dump_stack+0x58/0x7d
[ 3162.511877] register_lock_class+0x4a3/0x4b0
[ 3162.511877] ? native_sched_clock+0x2f/0x110
[ 3162.511877] __lock_acquire.isra.26+0x46/0x770
[ 3162.511877] ? sched_clock+0x8/0x10
[ 3162.511877] lock_acquire+0x5c/0x80
[ 3162.511877] ? z8530_interrupt+0x35/0x180 [z85230]
[ 3162.511877] _raw_spin_lock+0x28/0x70
[ 3162.511877] ? z8530_interrupt+0x35/0x180 [z85230]
[ 3162.511877] z8530_interrupt+0x35/0x180 [z85230]
[ 3162.511877] __handle_irq_event_percpu+0x35/0xe0
[ 3162.511877] handle_irq_event_percpu+0x26/0x70
[ 3162.511877] handle_irq_event+0x29/0x42
[ 3162.511877] handle_fasteoi_irq+0x9b/0x170
[ 3162.511877] ? handle_simple_irq+0x90/0x90
[ 3162.511877] handle_irq+0xc3/0xee
[ 3162.511877] </IRQ>
[ 3162.511877] do_IRQ+0x51/0xe0
[ 3162.511877] common_interrupt+0xe7/0xec
[ 3162.511877] EIP: _raw_spin_unlock_irqrestore+0x24/0x50
[ 3162.511877] Code: 5b 5d c3 8d 76 00 55 89 e5 56 89 c6 83 c0 10 53 8b 4d 04 89 d3 ba 01 00 00 00 e8 17 14 9a ff 89 f0 e8 e0 4d 9a ff 89 d8 50 9d <66> 66 66 90 b8 01 00 00 00 e8 ee 89 97 ff 64 a1 ec 07 74 c7 85 c0
[ 3162.511877] EAX: 00000246 EBX: 00000246 ECX: 00000002 EDX: 00000058
[ 3162.511877] ESI: f400d8e4 EDI: 00000000 EBP: efbf9d74 ESP: efbf9d6c
[ 3162.511877] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00000246
[ 3162.511877] __setup_irq+0x2f0/0x620
[ 3162.511877] request_threaded_irq+0xcd/0x170
[ 3162.511877] init_module+0xb0/0x270 [hostess_sv11]
[ 3162.511877] ? hostess_queue_xmit+0x20/0x20 [hostess_sv11]
[ 3162.511877] do_one_initcall+0x3e/0x15a
[ 3162.511877] ? __slab_alloc.isra.71.constprop.76+0x3a/0x50
[ 3162.511877] ? do_init_module+0x17/0x1d0
[ 3162.511877] ? kmem_cache_alloc+0x13f/0x190
[ 3162.511877] ? do_init_module+0x17/0x1d0
[ 3162.511877] do_init_module+0x46/0x1d0
[ 3162.511877] load_module+0x131f/0x14f0
[ 3162.511877] sys_finit_module+0x81/0xd0
[ 3162.511877] do_fast_syscall_32+0x89/0x1f0
[ 3162.511877] entry_SYSENTER_32+0x6b/0xbe
[ 3162.511877] EIP: 0xb7facd11
[ 3162.511877] Code: f6 ff ff 55 89 e5 8b 55 08 8b 80 5c cd ff ff 85 d2 74 02 89 02 5d c3 8b 04 24 c3 8b 1c 24 c3 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76
[ 3162.511877] EAX: ffffffda EBX: 00000005 ECX: 0048834e EDX: 00000000
[ 3162.511877] ESI: 004a5870 EDI: 004a3470 EBP: 00000000 ESP: bfb9c32c
[ 3162.511877] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000292
[ 3162.883280] systemd-journald[1693]: Sent WATCHDOG=1 notification.
[ 3162.511877] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3163.549994] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3164.034994] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3164.522999] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3165.007005] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3165.494999] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3165.978998] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3166.466999] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3166.951999] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3167.440000] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3167.924000] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3168.408002] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3168.895999] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3169.380000] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3169.868001] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3170.351999] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3170.836001] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3171.324988] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3171.810991] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3172.296991] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3172.781991] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3173.268002] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3173.753994] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3174.240002] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3174.725990] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3175.211999] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3175.697002] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3176.183999] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3176.668989] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3177.153986] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3177.640002] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3178.125993] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3178.612002] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3179.097993] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3179.584002] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3180.069994] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3180.556001] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3181.041986] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3181.528001] z85230: (null): interrupt jammed - abort(0xFF)!
[ 3182.013986] z85230: (null): interrupt jammed - abort(0xFF)!
then manual poweroff.
--
~Randy
^ permalink raw reply
* Read Business Letter
From: info @ 2018-10-14 9:30 UTC (permalink / raw)
To: netdev
Steven Peter Walker(Esq)
Stone Chambers, 4 Field Court,
Gray's Inn, London,
WC1R 5EF..
Email: stevenwalkerchambers@workmail.co.za
Greetings To You,
This is a personal email directed to you and I request that it be
treated as such. I am Steven Walker, a personal attorney/sole
executor to the late Engineer Robert M, herein after referred to
as" my client" I represent the interest of my client killed with
his immediate family in a fatal motor accident in East London on
November 5, 2002.and I will like to negotiate the terms of
investment of resources available to him.
My late client worked as consulting engineer & sub-comptroller
with Genesis Oil and Gas Consultants Ltd here in the United
Kingdom and had left behind a deposit of Six Million Eight
Hundred Thousand British Pounds Sterling only (£6.8million) with
a finance company. The funds originated from contract
transactions he executed in his registered area of business. Just
after his death, I was contacted by the finance house to provide
his next of kin, reasons been that his deposit agreement contains
a residuary clause giving his personal attorney express authority
to nominate the beneficiary to his funds. Unknown to the bank,
Robert had left no possible trace of any of his close relative
with me, making all efforts in my part to locate his family
relative to be unfruitful since his death. In addition, from
Robert's own story, he was only adopted and his foster parents
whom he lost in 1976, according to him had no possible trace of
his real family.
The funds had remained unclaimed since his death, but I had made
effort writing several letters to the embassy with intent to
locate any of his extended relatives whom shall be
claimants/beneficiaries of his abandoned personal estate, and all
such efforts have been to no avail. More so, I have received
official letters in the last few weeks suggesting a likely
proceeding for confiscation of his abandoned personal assets in
line with existing laws by the bank However, it will interest you
to know that I discovered that some directors of this finance
company are making plans already to have this fund to themselves
only to use the excuse that since I am unable to find a next of
kin to my late client then the funds should be confiscated,
meanwhile their intentions is to have the funds retrieved for
themselves.
I reasoned very professionally and resolved to use a legal means
to retrieve the abandoned funds, and that is to present the next
of kin of my deceased client to the bank. This is legally
possible and would be done in accordance with the laws. On this
note, I decided to search for a credible person and finding that
you bear a similar last name, I was urged to contact you, that I
may, with your consent, present you to the "trustee" bank as my
late client's surviving family member so as to enable you put up
a claim to the bank in that capacity as a next of kin of my
client. I find this to be possible for the fuller reasons that
you are of the same nationality and you bear a similar last name
with my late client making it a lot easier for you to put up a
claim in that capacity. I have all vital documents that would
confer you the legal right to lay claim to the funds, and it
would back up your claim. I am willing to make these documents
available to you so that the proceeds of this bank account valued
at £6.8million can be paid to you before it is confiscated or
declared unserviceable to the bank where this huge amount is
lodged.
I do sincerely sympathize the death of my client but I think that
it is unprofitable for his funds to be submitted to the
government of this country or some financial institution. I seek
your assistance since I have been unable to locate the relatives
for the past three years now and since no one would come for the
claim. I seek your consent to present you as the next of kin of
the deceased since you have the same last name giving you the
advantage which also makes the claim most credible . In that
stand, the proceeds of this account can be paid to you. Then, we
talk about percentage. I know there are others with the same
surname as my client, but after a little search, my instinct
tells me to contact you. I shall assemble all the necessary
documents that would be used to back up your claim.
I guarantee that this will be executed under a legitimate
arrangement that will protect you from any breach of law. I will
not fail to bring to your notice that this proposal is hitch-free
and that you should not entertain any fears as the required
arrangements have been made for the completion of this transfer.
As I said, I require only a solemn confidentiality on this.
Please get in touch via my alternative
email{stevenwalkerchambers@workmail.co.za} for better
confidentiality and if it's okay to you send me your telephone
and fax numbers to enable us discuss further on this transaction,
please do not take undue advantage of the trust I have bestowed
in you, Thanks for your understanding.
Kind Regards.
Barrister Steven Peter Walker.
^ permalink raw reply
* Read Business Letter
From: info @ 2018-10-14 9:18 UTC (permalink / raw)
To: netdev
Steven Peter Walker(Esq)
Stone Chambers, 4 Field Court,
Gray's Inn, London,
WC1R 5EF..
Email: stevenwalkerchambers@workmail.co.za
Greetings To You,
This is a personal email directed to you and I request that it be
treated as such. I am Steven Walker, a personal attorney/sole
executor to the late Engineer Robert M, herein after referred to
as" my client" I represent the interest of my client killed with
his immediate family in a fatal motor accident in East London on
November 5, 2002.and I will like to negotiate the terms of
investment of resources available to him.
My late client worked as consulting engineer & sub-comptroller
with Genesis Oil and Gas Consultants Ltd here in the United
Kingdom and had left behind a deposit of Six Million Eight
Hundred Thousand British Pounds Sterling only (£6.8million) with
a finance company. The funds originated from contract
transactions he executed in his registered area of business. Just
after his death, I was contacted by the finance house to provide
his next of kin, reasons been that his deposit agreement contains
a residuary clause giving his personal attorney express authority
to nominate the beneficiary to his funds. Unknown to the bank,
Robert had left no possible trace of any of his close relative
with me, making all efforts in my part to locate his family
relative to be unfruitful since his death. In addition, from
Robert's own story, he was only adopted and his foster parents
whom he lost in 1976, according to him had no possible trace of
his real family.
The funds had remained unclaimed since his death, but I had made
effort writing several letters to the embassy with intent to
locate any of his extended relatives whom shall be
claimants/beneficiaries of his abandoned personal estate, and all
such efforts have been to no avail. More so, I have received
official letters in the last few weeks suggesting a likely
proceeding for confiscation of his abandoned personal assets in
line with existing laws by the bank However, it will interest you
to know that I discovered that some directors of this finance
company are making plans already to have this fund to themselves
only to use the excuse that since I am unable to find a next of
kin to my late client then the funds should be confiscated,
meanwhile their intentions is to have the funds retrieved for
themselves.
I reasoned very professionally and resolved to use a legal means
to retrieve the abandoned funds, and that is to present the next
of kin of my deceased client to the bank. This is legally
possible and would be done in accordance with the laws. On this
note, I decided to search for a credible person and finding that
you bear a similar last name, I was urged to contact you, that I
may, with your consent, present you to the "trustee" bank as my
late client's surviving family member so as to enable you put up
a claim to the bank in that capacity as a next of kin of my
client. I find this to be possible for the fuller reasons that
you are of the same nationality and you bear a similar last name
with my late client making it a lot easier for you to put up a
claim in that capacity. I have all vital documents that would
confer you the legal right to lay claim to the funds, and it
would back up your claim. I am willing to make these documents
available to you so that the proceeds of this bank account valued
at £6.8million can be paid to you before it is confiscated or
declared unserviceable to the bank where this huge amount is
lodged.
I do sincerely sympathize the death of my client but I think that
it is unprofitable for his funds to be submitted to the
government of this country or some financial institution. I seek
your assistance since I have been unable to locate the relatives
for the past three years now and since no one would come for the
claim. I seek your consent to present you as the next of kin of
the deceased since you have the same last name giving you the
advantage which also makes the claim most credible . In that
stand, the proceeds of this account can be paid to you. Then, we
talk about percentage. I know there are others with the same
surname as my client, but after a little search, my instinct
tells me to contact you. I shall assemble all the necessary
documents that would be used to back up your claim.
I guarantee that this will be executed under a legitimate
arrangement that will protect you from any breach of law. I will
not fail to bring to your notice that this proposal is hitch-free
and that you should not entertain any fears as the required
arrangements have been made for the completion of this transfer.
As I said, I require only a solemn confidentiality on this.
Please get in touch via my alternative
email{stevenwalkerchambers@workmail.co.za} for better
confidentiality and if it's okay to you send me your telephone
and fax numbers to enable us discuss further on this transaction,
please do not take undue advantage of the trust I have bestowed
in you, Thanks for your understanding.
Kind Regards.
Barrister Steven Peter Walker.
^ permalink raw reply
* Re: [PATCH RFC,net-next 0/3] ip_tunnel: specify tunnel type via template
From: Pablo Neira Ayuso @ 2018-10-14 9:24 UTC (permalink / raw)
To: Or Gerlitz
Cc: Jakub Kicinski, Linux Netdev List, netfilter-devel, Roopa Prabhu,
Amir Vadai, pravin shelar, u9012063, Jiri Pirko, Oz Shlomo
In-Reply-To: <CAJ3xEMhu+the6+1a_r+2CAiYK1S-M1U37-TTyWBR41ORgYN=-g@mail.gmail.com>
Hi Or,
On Sun, Oct 14, 2018 at 09:42:42AM +0300, Or Gerlitz wrote:
> On Fri, Oct 5, 2018 at 12:58 AM Pablo Neira Ayuso <pablo@netfilter.org> wrote:
[...]
> > On Thu, Oct 04, 2018 at 12:13:57PM -0700, Jakub Kicinski wrote:
> > > On Thu, 4 Oct 2018 02:03:42 +0200, Pablo Neira Ayuso wrote:
> > > > Hi,
> > > >
> > > > The following patchset adds a new field to the tunnel metadata template
> > > > to restrict the configuration to a given tunnel driver. Currently, a
> > > > misconfiguration may result in packets going to the wrong tunnel driver.
> > > >
> > > > Although we have the tunnel option flags, they are not mandatory for
> > > > some tunnel drivers, eg. vxlan, which may use it or not; and gre which
> > > > does not use them.
> > >
> > > Option flags are necessary because interpretation of option blob is
> > > entirely protocol-specific.
> > >
> > > > This patch updates tc's tunnel action and netfilter's tunnel extension
> > > > to use this new field. OVS netlink interface has been left unset, although they
> > > > could be updated to use this.
> > > >
> > > > By extending the existing tc action to support the IP_TUNNEL_INFO_BRIDGE
> > > > mode, I think it should be possible to expose IP_TUNNEL_TYPE_VLAN too,
> > > > although this patchset doesn't address this scenario.
>
> not following... can you elaborate further please?
It should be possible to extend act_key_tunnel to support the
IP_TUNNEL_INFO_BRIDGE flag, but this is just a suggestion.
> > > > The field is initialized to zero, which maps to IP_TUNNEL_TYPE_UNSPEC to
> > > > retain the existing behaviour, so the existing flexibility is still in
> > > > place while this new feature is added.
> > > >
> > > > Cc'ing people that git annotate show as dealing with these bits more
> > > > recently.
> > >
> > > What practical scenario are you trying to address here?
> >
> > Incorrect configuration. The tunnel template defines an ID field, this
> > ID means vni in vxlan, but it also means session in erspan. If a
> > packet that should go to vxlan tunnel device (to be encapsulated using
> > vni 5) ends up in a gre/erspan device, you will get an erspan packet
> > with session 5. With this new tunnel type field, you can restrict
> > the tunnel template to work _only_ for a given tunnel device driver.
> > Hence, if the packet ends up in the wrong tunnel device driver due to
> > incorrect configuration, packet gets dropped.
> >
> >> Have you seen
> >> https://www.mail-archive.com/netdev@vger.kernel.org/msg250705.html ?
>
> > Hm, I remember to have seen some hw offload driver code that is making
> > assumptions on the destination ports to pick the tunnel protocol,
> > based on what the act_key_tunnel is passing.
> [..]
>
> for udp based tunneling this is valid practice, b/c a driver can get the tunnel
> type <--> udp dest port relation from the stack through the udp tunnel ndo.
>
> HW offloading wise, I think it would be better first pursue Januk and Co
> proposal which deals with the problematic part of tc/tunnels -- ingress rules
> set on tunnel devices (decap rules). The RFC looks very promising and
> I understand this is going to be reposed as non-rfc early in the next cycle
Sorry, I think there's a misunderstanding here.
My patchset is of benefit for pure software/control plane approach:
This allows users to narrow down tunnel configurations, existing
approach is very flexible - probably a bit too much for people willing
to validate things are correct - since it is allowing too loose
configurations. This is leaving room to the user to make configuration
mistakes that result in bad things, such as packets being tunneled
through the wrong encapsulation type. With this patchset, packets
going to the wrong tunnel devices will be simply dropped - and we
could even do more specific validation from control plane after this.
This patchset is backward compatible, so it doesn't restrict for the
existing flexibility that users may want for this.
This patchset _never_ meant to replace Jakub's work nor any HW offload
infrastructure. After reading Jakub's email, I was just suggesting
that this may (probably) still help drivers too, since this would
provide more hints to the driver. Please, let me know if this is
causing any interference with your ongoing HW driver development in
some way, and if so, in what way.
Let me know,
Thanks.
^ permalink raw reply
* pull-request: bpf 2018-10-14
From: Daniel Borkmann @ 2018-10-14 9:09 UTC (permalink / raw)
To: davem; +Cc: daniel, ast, netdev
Hi David,
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) Fix xsk map update and delete operation to not call synchronize_net()
but to piggy back on SOCK_RCU_FREE for sockets instead as we are not
allowed to sleep under RCU, from Björn.
2) Do not change RLIMIT_MEMLOCK in reuseport_bpf selftest if the process
already has unlimited RLIMIT_MEMLOCK, from Eric.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit e2a322a0c8ce3d825e8a56c063ce3f81b719083c:
Merge branch 'net-smc-userspace-breakage-fixes' (2018-10-07 21:06:28 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
for you to fetch changes up to cee271678d0e3177a25d0fcb2fa5e051d48e4262:
xsk: do not call synchronize_net() under RCU read lock (2018-10-11 10:19:01 +0200)
----------------------------------------------------------------
Björn Töpel (1):
xsk: do not call synchronize_net() under RCU read lock
Eric Dumazet (1):
bpf: do not blindly change rlimit in reuseport net selftest
kernel/bpf/xskmap.c | 10 ++--------
net/xdp/xsk.c | 2 ++
tools/testing/selftests/net/reuseport_bpf.c | 13 +++++++++----
3 files changed, 13 insertions(+), 12 deletions(-)
^ permalink raw reply
* Re: [PATCH] Bluetooth: Remove redundant check on status
From: Marcel Holtmann @ 2018-10-14 8:33 UTC (permalink / raw)
To: Colin King
Cc: Johan Hedberg, David S. Miller, linux-bluetooth, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <20181010143731.16451-1-colin.king@canonical.com>
Hi Colin,
> The check on statis is redundant as a status has to be zero at
> the point it is being checked because of a previous check and return
> path via label 'unlock'. Remove the redundant check and the deadcode
> that can never be reached.
>
> Detected by CoverityScan, CID#1471710 ("Logically dead code")
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> net/bluetooth/hci_event.c | 38 +++++++++++++++++---------------------
> 1 file changed, 17 insertions(+), 21 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] net: bridge: fix a memory leak in __vlan_add
From: Nikolay Aleksandrov @ 2018-10-14 15:33 UTC (permalink / raw)
To: Li RongQing, netdev; +Cc: Roopa Prabhu, bridge
In-Reply-To: <1539487305-12761-1-git-send-email-lirongqing@baidu.com>
On 14/10/2018 06:21, Li RongQing wrote:
> After per-port vlan stats, vlan stats should be released
> when fail to add vlan
>
> Fixes: 9163a0fc1f0c0 ("net: bridge: add support for per-port vlan stats")
> cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> ---
> net/bridge/br_vlan.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
> index 9b707234e4ae..e08e269041dd 100644
> --- a/net/bridge/br_vlan.c
> +++ b/net/bridge/br_vlan.c
> @@ -305,6 +305,10 @@ static int __vlan_add(struct net_bridge_vlan *v, u16 flags)
> if (masterv) {
> br_vlan_put_master(masterv);
> v->brvlan = NULL;
> +
> + if (masterv->stats != v->stats && v->stats)
> + free_percpu(v->stats);
> + v->stats = NULL;
> }
> } else {
> br_switchdev_port_vlan_del(dev, v->vid);
>
Hi,
Good catch, but the patch doesn't fix the bug entirely. The problem is that masterv can be
created just for this vlan and the br_vlan_put_master() above can free it, so we can
check a pointer that's not really up-to-date (and thus again leak memory).
You should move the new code above the br_vlan_put_master() call.
Also please tag the proper branch, this is for net-next, and CC all bridge
maintainers (added Roopa).
Thank you,
Nik
^ permalink raw reply
* pull-request: wireless-drivers-next 2018-10-14
From: Kalle Valo @ 2018-10-14 15:05 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel, Johannes Berg
Hi Dave,
here's most likely the final pull request to net-next for 4.20. These
have not yet been in linux-next due to timing on my part (see below) but
luckily kbuild bot is back in action so I have pretty good confidence
with these.
I'm about to leave for a vacation and I will be offline the next 8 days.
But Johannes (CCed) kindly promised to look after driver patches while
I'm gone and see if there's anything urgent needing attention. So please
do let him know if there are any problems :)
Kalle
The following changes since commit d864991b220b7c62e81d21209e1fd978fd67352c:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-10-12 21:38:46 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2018-10-14
for you to fetch changes up to f95cd52476dee761a1a8ebe617dd01793e0eb39c:
Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2018-10-14 12:21:43 +0300)
----------------------------------------------------------------
wireless-drivers-next patches for 4.20
Third set of patches for 4.20. Most notable is finalising ath10k
wcn3990 support, all components should be implemented now.
Major changes:
ath10k
* support NET_DETECT WoWLAN feature
* wcn3990 basic functionality now working after we got QMI support
mt76
* mt76x0e improvements (should be usable now)
* more mt76x0/mt76x2 unification work
brcmsmac
* fix a problem on AP mode with clients using power save mode
iwlwifi
* support for a new scan type: fast balance
----------------------------------------------------------------
Ali MJ Al-Nasrawy (1):
brcmsmac: AP mode: update beacon when TIM changes
Arnd Bergmann (1):
ath9k: fix RX_STAT_INC() etc macros
Ayala Beker (2):
iwlwifi: mvm: introduce a new fragmented scan type: fast balance
iwlwifi: mvm: use fast balance scan in case of DCM mode with P2P GO
Balaji Pothunoori (1):
ath10k: management tx ack rssi capability check
Carl Huang (1):
ath10k: allocate small size dma memory in ath10k_pci_diag_write_mem
Colin Ian King (1):
rtlwifi: rtl8821ae: replace _rtl8821ae_mrate_idx_to_arfr_id with generic version
Dan Carpenter (1):
ath10k: htt: remove some dead code
Felix Fietkau (2):
mt76: do not store aggregation sequence number for null-data frames
mt76: mt76x0e: another fix for the external PA current setting
Govind Singh (5):
ath10k: add qmi service helpers for wcn3990 qmi client
dt: bindings: add bindings for msa memory region
firmware: qcom: scm: Add WLAN VMID for Qualcomm SCM interface
ath10k: add debug mask for QMI layer
ath10k: add QMI message handshake for wcn3990 client
Gustavo A. R. Silva (2):
ath10k: htt_rx: fix signedness bug in ath10k_update_per_peer_tx_stats
ath10k: remove unnecessary comparison of unsigned integer with < 0
Jia-Ju Bai (1):
iwlegacy: Add a lock assertion in il4965_send_rxon_assoc()
Johannes Berg (11):
iwlwifi: mvm: give TX queue info struct a name
iwlwifi: mvm: move queue management into sta.c
iwlwifi: mvm: remove per-queue hw refcount
iwlwifi: mvm: clean up iteration in iwl_mvm_inactivity_check()
iwlwifi: mvm: move queue reconfiguration into new function
iwlwifi: mvm: reconfigure queues during inactivity check
iwlwifi: mvm: remove RECONFIGURING queue state
iwlwifi: mvm: make queue TID change more explicit
iwlwifi: mvm: make iwl_mvm_scd_queue_redirect() static
iwlwifi: mvm: move iwl_mvm_sta_alloc_queue() down
iwlwifi: mvm: kill INACTIVE queue state
Kalle Valo (3):
Merge tag 'iwlwifi-next-for-kalle-2018-10-12' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge tag 'mt76-for-kvalo-2018-10-13' of https://github.com/nbd168/wireless
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Lorenzo Bianconi (26):
mt76x0: phy: fix bank check in mt76x0_rf_csr_{wr,rr}
mt76: use mt76x02_dev instead of mt76_dev in mt76x02_mcu.c
mt76: use mt76x02_dev instead of mt76_dev in mt76x02_phy.c
mt76: use mt76x02_dev instead of mt76_dev in mt76x02_util.c
mt76: use mt76x02_dev instead of mt76_dev in mt76x02_usb_mcu.c
mt76: use mt76x02_dev instead of mt76_dev in mt76x02_mac.c
mt76: use mt76x02_dev instead of mt76_dev in mt76x02_txrx.c
mt76: use mt76x02_dev instead of mt76_dev in mt76x02_eeprom.c
mt76x0: pci: report firmware version using ethtool
mt76x0: pci: add missing mac80211 callbacks
mt76: disable ldpc coding for mt76x0 devices
mt76x0: pci: add mt76x0_register_device in mt76x0e_register_device
mt76x0: phy: fix restore phase in mt76x0_phy_recalibrate_after_assoc
mt76x0: phy: remove channel parameter from mt76x0_phy_set_chan_bbp_params
mt76: move mt76x02_phy_set_bw in mt76x02-lib module
mt76: move mt76x02_phy_set_band in mt76x02-lib module
mt76x0: pci: rename mt76x0_phy_calibrate
mt76x0: pci: introduce mt76x0_phy_calirate routine
mt76x0: phy: update set_channel for mt76x0e devices
mt76x0: eeprom: introduce mt76x0_tssi_enabled routine
mt76x0: phy: add phy/vco temperature compensation
mt76: move rssi_gain_thresh routines in mt76x02-lib module
mt76: move mt76x02_phy_adjust_vga_gain in mt76/mt76x02_phy.c
mt76: introduce mt76x02_init_agc_gain routine
mt76x0: phy: align channel gain logic to mt76x2 one
mt76x0: phy: do not run calibration during channel switch
Lubomir Rintel (2):
libertas: don't set URB_ZERO_PACKET on IN USB transfer
libertas: return errno from lbs_add_card()
Luca Coelho (1):
iwlwifi: mvm: check return value of rs_rate_from_ucode_rate()
Rakesh Pillai (2):
ath10k: set probe request oui during driver start
ath10k: add support to create boardname for non-bmi target
Sara Sharon (3):
iwlwifi: mvm: don't send keys when entering D3
iwlwifi: pcie: don't pad AMSDU packets
iwlwifi: trace: change trace to trace one TB at a time
Sergey Matyukevich (3):
qtnfmac: use 'help' in Kconfig
qtnfmac: use SPDX identifier for pcie bus layer files
qtnfmac_pcie: cleanup Pearl platform headers
Shahar S Matityahu (2):
iwlwifi: dump debug data before stop device
iwlwifi: mvm: move rt status check to the start of the resume flow
Sriram R (1):
ath10k: fix possible out of bound access of ath10k_rates array
Stanislaw Gruszka (7):
mt76x0: print BBP version only for debug
mt76x0: correct RF access via RF_CSR register.
mt76: allow to identify bus
mt76x0: correct RF reg pairs write for PCIe
mt76x0: use bus helper to identify rf access method
mt76: reserve enough room for USB tx skbs
mt76x0: remove dma.h
Wen Gong (2):
ath10k: support NET_DETECT WoWLAN feature
ath10k: add peer flush in ath10k_flush for STATION
YueHaibing (3):
mt76x0: pci: fix set external PA I/O current
rtl8xxxu: Remove set but not used variables 'usedesc40' and 'seq_number'
wil6210: fix debugfs_simple_attr.cocci warnings
.../bindings/net/wireless/qcom,ath10k.txt | 6 +
drivers/net/wireless/ath/ath10k/Kconfig | 1 +
drivers/net/wireless/ath/ath10k/Makefile | 4 +-
drivers/net/wireless/ath/ath10k/core.c | 14 +-
drivers/net/wireless/ath/ath10k/core.h | 5 +
drivers/net/wireless/ath/ath10k/debug.c | 2 +-
drivers/net/wireless/ath/ath10k/debug.h | 1 +
drivers/net/wireless/ath/ath10k/htt_rx.c | 5 +-
drivers/net/wireless/ath/ath10k/mac.c | 76 +-
drivers/net/wireless/ath/ath10k/pci.c | 23 +-
drivers/net/wireless/ath/ath10k/qmi.c | 1019 ++++++++++
drivers/net/wireless/ath/ath10k/qmi.h | 129 ++
drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.c | 2072 ++++++++++++++++++++
drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h | 677 +++++++
drivers/net/wireless/ath/ath10k/snoc.c | 267 ++-
drivers/net/wireless/ath/ath10k/snoc.h | 4 +
drivers/net/wireless/ath/ath10k/wmi-ops.h | 21 +
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 187 ++
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 254 +++
drivers/net/wireless/ath/ath10k/wmi.h | 57 +
drivers/net/wireless/ath/ath10k/wow.c | 168 ++
drivers/net/wireless/ath/ath9k/antenna.c | 8 +-
drivers/net/wireless/ath/ath9k/common-spectral.c | 8 +-
drivers/net/wireless/ath/ath9k/debug.c | 24 +-
drivers/net/wireless/ath/ath9k/debug.h | 20 +-
drivers/net/wireless/ath/ath9k/main.c | 2 +-
drivers/net/wireless/ath/ath9k/recv.c | 18 +-
drivers/net/wireless/ath/ath9k/xmit.c | 18 +-
drivers/net/wireless/ath/wil6210/debugfs.c | 14 +-
.../broadcom/brcm80211/brcmsmac/mac80211_if.c | 26 +
.../wireless/broadcom/brcm80211/brcmsmac/main.h | 1 +
drivers/net/wireless/intel/iwlegacy/4965.c | 2 +
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 27 +-
drivers/net/wireless/intel/iwlwifi/fw/dbg.h | 1 +
.../net/wireless/intel/iwlwifi/iwl-devtrace-data.h | 30 +-
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 64 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 9 +-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 54 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 24 +-
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 115 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 837 +++++---
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 8 -
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 34 +-
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 420 +---
drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c | 28 +-
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 29 +-
drivers/net/wireless/marvell/libertas/if_cs.c | 4 +-
drivers/net/wireless/marvell/libertas/if_sdio.c | 4 +-
drivers/net/wireless/marvell/libertas/if_spi.c | 4 +-
drivers/net/wireless/marvell/libertas/if_usb.c | 7 +-
drivers/net/wireless/marvell/libertas/main.c | 17 +-
drivers/net/wireless/mediatek/mt76/mmio.c | 1 +
drivers/net/wireless/mediatek/mt76/mt76.h | 9 +
drivers/net/wireless/mediatek/mt76/mt76x0/dma.h | 126 --
drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c | 55 +-
drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.h | 6 +
drivers/net/wireless/mediatek/mt76/mt76x0/init.c | 9 +-
drivers/net/wireless/mediatek/mt76/mt76x0/main.c | 22 +-
drivers/net/wireless/mediatek/mt76/mt76x0/mcu.h | 3 +
drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h | 3 +-
drivers/net/wireless/mediatek/mt76/mt76x0/pci.c | 49 +-
.../net/wireless/mediatek/mt76/mt76x0/pci_mcu.c | 1 +
drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 311 +--
.../net/wireless/mediatek/mt76/mt76x0/usb_mcu.c | 7 +-
drivers/net/wireless/mediatek/mt76/mt76x02.h | 25 +-
.../net/wireless/mediatek/mt76/mt76x02_eeprom.c | 33 +-
.../net/wireless/mediatek/mt76/mt76x02_eeprom.h | 37 +-
drivers/net/wireless/mediatek/mt76/mt76x02_mac.c | 206 +-
drivers/net/wireless/mediatek/mt76/mt76x02_mac.h | 31 +-
drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c | 74 +-
drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h | 14 +-
drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt76x02_phy.c | 167 +-
drivers/net/wireless/mediatek/mt76/mt76x02_phy.h | 39 +-
drivers/net/wireless/mediatek/mt76/mt76x02_regs.h | 4 +-
drivers/net/wireless/mediatek/mt76/mt76x02_txrx.c | 29 +-
drivers/net/wireless/mediatek/mt76/mt76x02_usb.h | 8 +-
.../net/wireless/mediatek/mt76/mt76x02_usb_core.c | 20 +-
.../net/wireless/mediatek/mt76/mt76x02_usb_mcu.c | 27 +-
drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 120 +-
drivers/net/wireless/mediatek/mt76/mt76x2/eeprom.c | 80 +-
drivers/net/wireless/mediatek/mt76/mt76x2/eeprom.h | 23 +-
drivers/net/wireless/mediatek/mt76/mt76x2/init.c | 3 +
drivers/net/wireless/mediatek/mt76/mt76x2/mcu.c | 5 +-
drivers/net/wireless/mediatek/mt76/mt76x2/mt76x2.h | 2 -
.../net/wireless/mediatek/mt76/mt76x2/pci_init.c | 18 +-
.../net/wireless/mediatek/mt76/mt76x2/pci_mac.c | 2 +-
.../net/wireless/mediatek/mt76/mt76x2/pci_main.c | 2 +-
.../net/wireless/mediatek/mt76/mt76x2/pci_mcu.c | 6 +-
.../net/wireless/mediatek/mt76/mt76x2/pci_phy.c | 100 +-
drivers/net/wireless/mediatek/mt76/mt76x2/phy.c | 61 +-
.../net/wireless/mediatek/mt76/mt76x2/usb_init.c | 11 +-
.../net/wireless/mediatek/mt76/mt76x2/usb_mac.c | 6 +-
.../net/wireless/mediatek/mt76/mt76x2/usb_main.c | 4 +-
.../net/wireless/mediatek/mt76/mt76x2/usb_mcu.c | 18 +-
.../net/wireless/mediatek/mt76/mt76x2/usb_phy.c | 32 +-
drivers/net/wireless/mediatek/mt76/tx.c | 3 +-
drivers/net/wireless/mediatek/mt76/usb.c | 1 +
drivers/net/wireless/quantenna/Kconfig | 2 +-
drivers/net/wireless/quantenna/qtnfmac/Kconfig | 2 +-
.../wireless/quantenna/qtnfmac/pcie/pearl_pcie.c | 17 +-
.../quantenna/qtnfmac/pcie/pearl_pcie_ipc.h | 22 +-
.../quantenna/qtnfmac/pcie/pearl_pcie_regs.h | 245 +--
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 71 +-
include/linux/qcom_scm.h | 4 +-
106 files changed, 6783 insertions(+), 2249 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath10k/qmi.c
create mode 100644 drivers/net/wireless/ath/ath10k/qmi.h
create mode 100644 drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.c
create mode 100644 drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h
delete mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/dma.h
^ permalink raw reply
* Re: [PATCH RFC,net-next 0/3] ip_tunnel: specify tunnel type via template
From: Or Gerlitz @ 2018-10-14 6:42 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Jakub Kicinski, Linux Netdev List, netfilter-devel, Roopa Prabhu,
Amir Vadai, pravin shelar, u9012063, Jiri Pirko, Oz Shlomo
In-Reply-To: <20181004215805.wnpwrrgy2uzprtuv@salvia>
On Fri, Oct 5, 2018 at 12:58 AM Pablo Neira Ayuso <pablo@netfilter.org> wrote:
>
> Hi Jakub,
>
> On Thu, Oct 04, 2018 at 12:13:57PM -0700, Jakub Kicinski wrote:
> > On Thu, 4 Oct 2018 02:03:42 +0200, Pablo Neira Ayuso wrote:
> > > Hi,
> > >
> > > The following patchset adds a new field to the tunnel metadata template
> > > to restrict the configuration to a given tunnel driver. Currently, a
> > > misconfiguration may result in packets going to the wrong tunnel driver.
> > >
> > > Although we have the tunnel option flags, they are not mandatory for
> > > some tunnel drivers, eg. vxlan, which may use it or not; and gre which
> > > does not use them.
> >
> > Option flags are necessary because interpretation of option blob is
> > entirely protocol-specific.
> >
> > > This patch updates tc's tunnel action and netfilter's tunnel extension
> > > to use this new field. OVS netlink interface has been left unset, although they
> > > could be updated to use this.
> > >
> > > By extending the existing tc action to support the IP_TUNNEL_INFO_BRIDGE
> > > mode, I think it should be possible to expose IP_TUNNEL_TYPE_VLAN too,
> > > although this patchset doesn't address this scenario.
not following... can you elaborate further please?
> > > The field is initialized to zero, which maps to IP_TUNNEL_TYPE_UNSPEC to
> > > retain the existing behaviour, so the existing flexibility is still in
> > > place while this new feature is added.
> > >
> > > Cc'ing people that git annotate show as dealing with these bits more
> > > recently.
> >
> > What practical scenario are you trying to address here?
>
> Incorrect configuration. The tunnel template defines an ID field, this
> ID means vni in vxlan, but it also means session in erspan. If a
> packet that should go to vxlan tunnel device (to be encapsulated using
> vni 5) ends up in a gre/erspan device, you will get an erspan packet
> with session 5. With this new tunnel type field, you can restrict
> the tunnel template to work _only_ for a given tunnel device driver.
> Hence, if the packet ends up in the wrong tunnel device driver due to
> incorrect configuration, packet gets dropped.
>
>> Have you seen
>> https://www.mail-archive.com/netdev@vger.kernel.org/msg250705.html ?
> Hm, I remember to have seen some hw offload driver code that is making
> assumptions on the destination ports to pick the tunnel protocol,
> based on what the act_key_tunnel is passing.
[..]
for udp based tunneling this is valid practice, b/c a driver can get the tunnel
type <--> udp dest port relation from the stack through the udp tunnel ndo.
HW offloading wise, I think it would be better first pursue Januk and Co
proposal which deals with the problematic part of tc/tunnels -- ingress rules
set on tunnel devices (decap rules). The RFC looks very promising and
I understand
this is going to be reposed as non-rfc early in the next cycle
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: Fix dev pointer dereference from sk_skb
From: Alexei Starovoitov @ 2018-10-14 6:04 UTC (permalink / raw)
To: Joe Stringer; +Cc: daniel, netdev, dan.carpenter, ast
In-Reply-To: <20181012215053.17830-1-joe@wand.net.nz>
On Fri, Oct 12, 2018 at 02:50:53PM -0700, Joe Stringer wrote:
> Dan Carpenter reports:
>
> The patch 6acc9b432e67: "bpf: Add helper to retrieve socket in BPF"
> from Oct 2, 2018, leads to the following Smatch complaint:
>
> net/core/filter.c:4893 bpf_sk_lookup()
> error: we previously assumed 'skb->dev' could be null (see line 4885)
>
> Fix this issue by checking skb->dev before using it.
>
> Signed-off-by: Joe Stringer <joe@wand.net.nz>
Applied, Thanks
^ permalink raw reply
* [PATCH] net: bridge: fix a memory leak in __vlan_add
From: Li RongQing @ 2018-10-14 3:21 UTC (permalink / raw)
To: netdev; +Cc: nikolay, bridge
After per-port vlan stats, vlan stats should be released
when fail to add vlan
Fixes: 9163a0fc1f0c0 ("net: bridge: add support for per-port vlan stats")
cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
net/bridge/br_vlan.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index 9b707234e4ae..e08e269041dd 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -305,6 +305,10 @@ static int __vlan_add(struct net_bridge_vlan *v, u16 flags)
if (masterv) {
br_vlan_put_master(masterv);
v->brvlan = NULL;
+
+ if (masterv->stats != v->stats && v->stats)
+ free_percpu(v->stats);
+ v->stats = NULL;
}
} else {
br_switchdev_port_vlan_del(dev, v->vid);
--
2.16.2
^ permalink raw reply related
* Re: [PATCH iproute2 net-next] bridge: add support for backup port
From: David Ahern @ 2018-10-14 2:30 UTC (permalink / raw)
To: Nikolay Aleksandrov, netdev; +Cc: roopa, dsahern
In-Reply-To: <20181012114255.17217-1-nikolay@cumulusnetworks.com>
On 10/12/18 5:42 AM, Nikolay Aleksandrov wrote:
> This patch adds support for the new backup port option that can be set
> on a bridge port. If the port's carrier goes down all of the traffic
> gets redirected to the configured backup port. We add the following new
> arguments:
> $ ip link set dev brport type bridge_slave backup_port brport2
> $ ip link set dev brport type bridge_slave nobackup_port
>
> $ bridge link set dev brport backup_port brport2
> $ bridge link set dev brport nobackup_port
>
> The man pages are updated respectively.
> Also 2 minor style adjustments:
> - add missing space to bridge man page's state argument
> - use lower starting case for vlan_tunnel in ip-link man page (to be
> consistent with the rest)
>
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> ---
> bridge/link.c | 26 ++++++++++++++++++++++++++
> ip/iplink_bridge_slave.c | 18 ++++++++++++++++++
> man/man8/bridge.8 | 13 ++++++++++++-
> man/man8/ip-link.8.in | 14 ++++++++++++--
> 4 files changed, 68 insertions(+), 3 deletions(-)
>
applied to iproute2-next. Thanks
^ permalink raw reply
* Re: [PATCH iproute2 net-next] ipneigh: support for NTF_EXT_LEARNED flag on neigh entries
From: David Ahern @ 2018-10-14 2:26 UTC (permalink / raw)
To: Roopa Prabhu; +Cc: netdev
In-Reply-To: <1539290710-942-1-git-send-email-roopa@cumulusnetworks.com>
On 10/11/18 2:45 PM, Roopa Prabhu wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> Adds new option extern_learn to set NTF_EXT_LEARNED flag
> on neigh entries.
>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
> ---
> ip/ipneigh.c | 7 ++++++-
> man/man8/ip-neighbour.8 | 9 ++++++++-
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
applied to iproute2-next. Thanks
^ permalink raw reply
* Urgent,
From: Miss Juliet Muhammad @ 2018-10-14 1:18 UTC (permalink / raw)
To: Recipients
Hello
i need your help to invest in your region, please can you assist me?
^ permalink raw reply
* RE: linux-next: manual merge of the net-next tree with the net tree
From: Kiyanovski, Arthur @ 2018-10-14 7:58 UTC (permalink / raw)
To: Stephen Rothwell, David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20181012104501.063dcc4a@canb.auug.org.au>
> -----Original Message-----
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Sent: Friday, October 12, 2018 2:45 AM
> To: David Miller <davem@davemloft.net>; Networking
> <netdev@vger.kernel.org>
> Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>; Linux Kernel
> Mailing List <linux-kernel@vger.kernel.org>; Kiyanovski, Arthur
> <akiyano@amazon.com>
> Subject: linux-next: manual merge of the net-next tree with the net tree
>
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> drivers/net/ethernet/amazon/ena/ena_eth_com.c
>
> between commit:
>
> 248ab77342d0 ("net: ena: fix auto casting to boolean")
>
> from the net tree and commit:
>
> cb36bb36e1f1 ("net: ena: use CSUM_CHECKED device indication to report
> skb's checksum status")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This is now fixed
> as far as linux-next is concerned, but any non trivial conflicts should be
> mentioned to your upstream maintainer when your tree is submitted for
> merging. You may also want to consider cooperating with the maintainer of
> the conflicting tree to minimise any particularly complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/net/ethernet/amazon/ena/ena_eth_com.c
> index 2b3ff0c20155,6f8e15b9b3cf..000000000000
> --- a/drivers/net/ethernet/amazon/ena/ena_eth_com.c
> +++ b/drivers/net/ethernet/amazon/ena/ena_eth_com.c
> @@@ -245,11 -349,14 +349,14 @@@ static inline void ena_com_rx_set_flags
> (cdesc->status &
> ENA_ETH_IO_RX_CDESC_BASE_L4_PROTO_IDX_MASK) >>
> ENA_ETH_IO_RX_CDESC_BASE_L4_PROTO_IDX_SHIFT;
> ena_rx_ctx->l3_csum_err =
> - (cdesc->status &
> ENA_ETH_IO_RX_CDESC_BASE_L3_CSUM_ERR_MASK) >>
> - ENA_ETH_IO_RX_CDESC_BASE_L3_CSUM_ERR_SHIFT;
> + !!((cdesc->status &
> ENA_ETH_IO_RX_CDESC_BASE_L3_CSUM_ERR_MASK) >>
> + ENA_ETH_IO_RX_CDESC_BASE_L3_CSUM_ERR_SHIFT);
> ena_rx_ctx->l4_csum_err =
> - (cdesc->status &
> ENA_ETH_IO_RX_CDESC_BASE_L4_CSUM_ERR_MASK) >>
> - ENA_ETH_IO_RX_CDESC_BASE_L4_CSUM_ERR_SHIFT;
> + !!((cdesc->status &
> ENA_ETH_IO_RX_CDESC_BASE_L4_CSUM_ERR_MASK) >>
> + ENA_ETH_IO_RX_CDESC_BASE_L4_CSUM_ERR_SHIFT);
> + ena_rx_ctx->l4_csum_checked =
> + !!((cdesc->status &
> ENA_ETH_IO_RX_CDESC_BASE_L4_CSUM_CHECKED_MASK) >>
> + ENA_ETH_IO_RX_CDESC_BASE_L4_CSUM_CHECKED_SHIFT);
> ena_rx_ctx->hash = cdesc->hash;
> ena_rx_ctx->frag =
> (cdesc->status &
> ENA_ETH_IO_RX_CDESC_BASE_IPV4_FRAG_MASK) >>
Hi Stephen,
The merge looks good.
I will know to mention conflicts in my future upstream releases.
Sorry for the trouble caused.
Thanks,
Arthur
^ permalink raw reply
* Re: [PATCH] net/sysfs: Remove devices without receive buffers
From: David Miller @ 2018-10-13 23:50 UTC (permalink / raw)
To: mwb
Cc: netdev, linux-kernel, alexander.h.duyck, tyhicks,
jeffrey.t.kirsher, amritha.nambiar, joe, dmitry.torokhov, decot,
roopa, xiyou.wangcong, nfont, minkim, tyreld, tlfalcon
In-Reply-To: <20181013220451.6905.65084.stgit@ltcalpine2-lp9.aus.stglabs.ibm.com>
From: Michael Bringmann <mwb@linux.vnet.ibm.com>
Date: Sat, 13 Oct 2018 17:05:28 -0500
> Testing ran into a case where a network device was created and
> initialized, but then removed from the system before accepting
> traffic through it. In this case, no receive buffers were added
> to the device prior to attempting to release the driver. This
> resulted in generation of a WARNING notice/stack trace in the
> console log like,
That's not legal.
The device must setup all of this kind of state before calling
register_netdevice(). And this must happen for reasons other than the
crash situation mentioned here.
Please fix the ibmvnic driver to not register partially setup netdev
objects.
Thank you.
^ permalink raw reply
* Re: [PATCH] wil6210: fix debugfs_simple_attr.cocci warnings
From: Kalle Valo @ 2018-10-13 17:29 UTC (permalink / raw)
To: YueHaibing
Cc: Maya Erez, YueHaibing, linux-wireless, wil6210, kernel-janitors,
netdev
In-Reply-To: <1538737646-118337-1-git-send-email-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE
> for debugfs files.
>
> Semantic patch information:
> Rationale: DEFINE_SIMPLE_ATTRIBUTE + debugfs_create_file()
> imposes some significant overhead as compared to
> DEFINE_DEBUGFS_ATTRIBUTE + debugfs_create_file_unsafe().
>
> Generated by: scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
f9dca154a4e4 wil6210: fix debugfs_simple_attr.cocci warnings
--
https://patchwork.kernel.org/patch/10627883/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: remove unnecessary comparison of unsigned integer with < 0
From: Kalle Valo @ 2018-10-13 17:24 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: David S. Miller, ath10k, linux-wireless, netdev, linux-kernel,
Gustavo A. R. Silva
In-Reply-To: <20181005185623.GA14405@embeddedor.com>
"Gustavo A. R. Silva" <gustavo@embeddedor.com> wrote:
> There is no need to compare *ps_state_enable* with < 0 because
> such variable is of type u8 (8 bits, unsigned), making it
> impossible to hold a negative value.
>
> Fix this by removing such comparison.
>
> Addresses-Coverity-ID: 1473921 ("Unsigned compared against 0")
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
7bfd82bff60e ath10k: remove unnecessary comparison of unsigned integer with < 0
--
https://patchwork.kernel.org/patch/10628679/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH net-next 15/18] vxlan: Notify for each remote of a removed FDB entry
From: Ido Schimmel @ 2018-10-13 17:18 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, Petr Machata, ivecera@redhat.com,
roopa@cumulusnetworks.com, nikolay@cumulusnetworks.com,
andrew@lunn.ch, vivien.didelot@savoirfairelinux.com,
f.fainelli@gmail.com, stephen@networkplumber.org,
bridge@lists.linux-foundation.org, mlxsw, Ido Schimmel
In-Reply-To: <20181013171725.3261-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
When notifications are sent about FDB activity, and an FDB entry with
several remotes is removed, the notification is sent only for the first
destination. That makes it impossible to distinguish between the case
where only this first remote is removed, and the one where the FDB entry
is removed as a whole.
Therefore send one notification for each remote of a removed FDB entry.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/vxlan.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 0be9e285f265..db5d390b9130 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -839,12 +839,15 @@ static void vxlan_fdb_free(struct rcu_head *head)
static void vxlan_fdb_destroy(struct vxlan_dev *vxlan, struct vxlan_fdb *f,
bool do_notify)
{
+ struct vxlan_rdst *rd;
+
netdev_dbg(vxlan->dev,
"delete %pM\n", f->eth_addr);
--vxlan->addrcnt;
if (do_notify)
- vxlan_fdb_notify(vxlan, f, first_remote_rtnl(f), RTM_DELNEIGH);
+ list_for_each_entry(rd, &f->remotes, list)
+ vxlan_fdb_notify(vxlan, f, rd, RTM_DELNEIGH);
hlist_del_rcu(&f->hlist);
call_rcu(&f->rcu, vxlan_fdb_free);
--
2.17.2
^ permalink raw reply related
* [PATCH net-next 14/18] vxlan: Support marking RDSTs as offloaded
From: Ido Schimmel @ 2018-10-13 17:18 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, Petr Machata, ivecera@redhat.com,
roopa@cumulusnetworks.com, nikolay@cumulusnetworks.com,
andrew@lunn.ch, vivien.didelot@savoirfairelinux.com,
f.fainelli@gmail.com, stephen@networkplumber.org,
bridge@lists.linux-foundation.org, mlxsw, Ido Schimmel
In-Reply-To: <20181013171725.3261-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Offloaded bridge FDB entries are marked with NTF_OFFLOADED. Implement a
similar mechanism for VXLAN, where a given remote destination can be
marked as offloaded.
To that end, introduce a new event, SWITCHDEV_VXLAN_FDB_OFFLOADED,
through which the marking is communicated to the vxlan driver. To
identify which RDST should be marked as offloaded, an
switchdev_notifier_vxlan_fdb_info is passed to the listeners. The
"offloaded" flag in that object determines whether the offloaded mark
should be set or cleared.
When sending offloaded FDB entries over netlink, mark them with
NTF_OFFLOADED.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/vxlan.c | 59 ++++++++++++++++++++++++++++++++++++++++-
include/net/switchdev.h | 1 +
include/net/vxlan.h | 2 ++
3 files changed, 61 insertions(+), 1 deletion(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 97c2218569d9..0be9e285f265 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -272,6 +272,8 @@ static int vxlan_fdb_info(struct sk_buff *skb, struct vxlan_dev *vxlan,
ndm->ndm_state = fdb->state;
ndm->ndm_ifindex = vxlan->dev->ifindex;
ndm->ndm_flags = fdb->flags;
+ if (rdst->offloaded)
+ ndm->ndm_flags |= NTF_OFFLOADED;
ndm->ndm_type = RTN_UNICAST;
if (!net_eq(dev_net(vxlan->dev), vxlan->net) &&
@@ -373,6 +375,7 @@ static void vxlan_fdb_switchdev_call_notifiers(struct vxlan_dev *vxlan,
.remote_vni = rd->remote_vni,
.remote_ifindex = rd->remote_ifindex,
.vni = fdb->vni,
+ .offloaded = rd->offloaded,
};
memcpy(info.eth_addr, fdb->eth_addr, ETH_ALEN);
@@ -536,6 +539,7 @@ int vxlan_fdb_find_uc(struct net_device *dev, const u8 *mac, __be32 vni,
fdb_info->remote_vni = rdst->remote_vni;
fdb_info->remote_ifindex = rdst->remote_ifindex;
fdb_info->vni = vni;
+ fdb_info->offloaded = rdst->offloaded;
ether_addr_copy(fdb_info->eth_addr, mac);
out:
@@ -589,6 +593,7 @@ static int vxlan_fdb_append(struct vxlan_fdb *f,
rd->remote_ip = *ip;
rd->remote_port = port;
+ rd->offloaded = false;
rd->remote_vni = vni;
rd->remote_ifindex = ifindex;
@@ -3814,6 +3819,51 @@ static struct notifier_block vxlan_notifier_block __read_mostly = {
.notifier_call = vxlan_netdevice_event,
};
+static void
+vxlan_fdb_offloaded_set(struct net_device *dev,
+ struct switchdev_notifier_vxlan_fdb_info *fdb_info)
+{
+ struct vxlan_dev *vxlan = netdev_priv(dev);
+ struct vxlan_rdst *rdst;
+ struct vxlan_fdb *f;
+
+ spin_lock_bh(&vxlan->hash_lock);
+
+ f = vxlan_find_mac(vxlan, fdb_info->eth_addr, fdb_info->vni);
+ if (!f)
+ goto out;
+
+ rdst = vxlan_fdb_find_rdst(f, &fdb_info->remote_ip,
+ fdb_info->remote_port,
+ fdb_info->remote_vni,
+ fdb_info->remote_ifindex);
+ if (!rdst)
+ goto out;
+
+ rdst->offloaded = fdb_info->offloaded;
+
+out:
+ spin_unlock_bh(&vxlan->hash_lock);
+}
+
+static int vxlan_switchdev_event(struct notifier_block *unused,
+ unsigned long event, void *ptr)
+{
+ struct net_device *dev = switchdev_notifier_info_to_dev(ptr);
+
+ switch (event) {
+ case SWITCHDEV_VXLAN_FDB_OFFLOADED:
+ vxlan_fdb_offloaded_set(dev, ptr);
+ break;
+ }
+
+ return 0;
+}
+
+static struct notifier_block vxlan_switchdev_notifier_block __read_mostly = {
+ .notifier_call = vxlan_switchdev_event,
+};
+
static __net_init int vxlan_init_net(struct net *net)
{
struct vxlan_net *vn = net_generic(net, vxlan_net_id);
@@ -3887,11 +3937,17 @@ static int __init vxlan_init_module(void)
if (rc)
goto out2;
- rc = rtnl_link_register(&vxlan_link_ops);
+ rc = register_switchdev_notifier(&vxlan_switchdev_notifier_block);
if (rc)
goto out3;
+ rc = rtnl_link_register(&vxlan_link_ops);
+ if (rc)
+ goto out4;
+
return 0;
+out4:
+ unregister_switchdev_notifier(&vxlan_switchdev_notifier_block);
out3:
unregister_netdevice_notifier(&vxlan_notifier_block);
out2:
@@ -3904,6 +3960,7 @@ late_initcall(vxlan_init_module);
static void __exit vxlan_cleanup_module(void)
{
rtnl_link_unregister(&vxlan_link_ops);
+ unregister_switchdev_notifier(&vxlan_switchdev_notifier_block);
unregister_netdevice_notifier(&vxlan_notifier_block);
unregister_pernet_subsys(&vxlan_net_ops);
/* rcu_barrier() is called by netns */
diff --git a/include/net/switchdev.h b/include/net/switchdev.h
index 47199a11c586..b040f82351ba 100644
--- a/include/net/switchdev.h
+++ b/include/net/switchdev.h
@@ -148,6 +148,7 @@ enum switchdev_notifier_type {
SWITCHDEV_VXLAN_FDB_ADD_TO_DEVICE,
SWITCHDEV_VXLAN_FDB_DEL_TO_DEVICE,
+ SWITCHDEV_VXLAN_FDB_OFFLOADED,
};
struct switchdev_notifier_info {
diff --git a/include/net/vxlan.h b/include/net/vxlan.h
index 798ba5019f4e..6457a82764cf 100644
--- a/include/net/vxlan.h
+++ b/include/net/vxlan.h
@@ -191,6 +191,7 @@ union vxlan_addr {
struct vxlan_rdst {
union vxlan_addr remote_ip;
__be16 remote_port;
+ u8 offloaded:1;
__be32 remote_vni;
u32 remote_ifindex;
struct list_head list;
@@ -411,6 +412,7 @@ struct switchdev_notifier_vxlan_fdb_info {
u32 remote_ifindex;
u8 eth_addr[ETH_ALEN];
__be32 vni;
+ bool offloaded;
};
#if IS_ENABLED(CONFIG_VXLAN)
--
2.17.2
^ permalink raw reply related
* [PATCH net-next 13/18] vxlan: Add vxlan_fdb_find_uc() for FDB querying
From: Ido Schimmel @ 2018-10-13 17:18 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, Petr Machata, ivecera@redhat.com,
roopa@cumulusnetworks.com, nikolay@cumulusnetworks.com,
andrew@lunn.ch, vivien.didelot@savoirfairelinux.com,
f.fainelli@gmail.com, stephen@networkplumber.org,
bridge@lists.linux-foundation.org, mlxsw, Ido Schimmel
In-Reply-To: <20181013171725.3261-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
A switchdev-capable driver that is aware of VXLAN may need to query
VXLAN FDB. In the particular case of mlxsw, this functionality is
limited to querying UC FDBs. Those being easier to deal with than the
general case of RDST chain traversal, introduce an interface to query
specifically UC FDBs: vxlan_fdb_find_uc().
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/vxlan.c | 40 ++++++++++++++++++++++++++++++++++++++++
include/net/vxlan.h | 12 ++++++++++++
2 files changed, 52 insertions(+)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index f8b579648d42..97c2218569d9 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -504,6 +504,46 @@ static struct vxlan_rdst *vxlan_fdb_find_rdst(struct vxlan_fdb *f,
return NULL;
}
+int vxlan_fdb_find_uc(struct net_device *dev, const u8 *mac, __be32 vni,
+ struct switchdev_notifier_vxlan_fdb_info *fdb_info)
+{
+ struct vxlan_dev *vxlan = netdev_priv(dev);
+ u8 eth_addr[ETH_ALEN + 2] = { 0 };
+ struct vxlan_rdst *rdst;
+ struct vxlan_fdb *f;
+ int rc = 0;
+
+ if (is_multicast_ether_addr(mac) ||
+ is_zero_ether_addr(mac))
+ return -EINVAL;
+
+ ether_addr_copy(eth_addr, mac);
+
+ rcu_read_lock();
+
+ f = __vxlan_find_mac(vxlan, eth_addr, vni);
+ if (!f) {
+ rc = -ENOENT;
+ goto out;
+ }
+
+ rdst = first_remote_rcu(f);
+
+ memset(fdb_info, 0, sizeof(*fdb_info));
+ fdb_info->info.dev = dev;
+ fdb_info->remote_ip = rdst->remote_ip;
+ fdb_info->remote_port = rdst->remote_port;
+ fdb_info->remote_vni = rdst->remote_vni;
+ fdb_info->remote_ifindex = rdst->remote_ifindex;
+ fdb_info->vni = vni;
+ ether_addr_copy(fdb_info->eth_addr, mac);
+
+out:
+ rcu_read_unlock();
+ return rc;
+}
+EXPORT_SYMBOL_GPL(vxlan_fdb_find_uc);
+
/* Replace destination of unicast mac */
static int vxlan_fdb_replace(struct vxlan_fdb *f,
union vxlan_addr *ip, __be16 port, __be32 vni,
diff --git a/include/net/vxlan.h b/include/net/vxlan.h
index a82b735decbc..798ba5019f4e 100644
--- a/include/net/vxlan.h
+++ b/include/net/vxlan.h
@@ -413,4 +413,16 @@ struct switchdev_notifier_vxlan_fdb_info {
__be32 vni;
};
+#if IS_ENABLED(CONFIG_VXLAN)
+int vxlan_fdb_find_uc(struct net_device *dev, const u8 *mac, __be32 vni,
+ struct switchdev_notifier_vxlan_fdb_info *fdb_info);
+#else
+static inline int
+vxlan_fdb_find_uc(struct net_device *dev, const u8 *mac, __be32 vni,
+ struct switchdev_notifier_vxlan_fdb_info *fdb_info)
+{
+ return -ENOENT;
+}
+#endif
+
#endif
--
2.17.2
^ permalink raw reply related
* [PATCH net-next 12/18] vxlan: Add switchdev notifications
From: Ido Schimmel @ 2018-10-13 17:18 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, Petr Machata, ivecera@redhat.com,
roopa@cumulusnetworks.com, nikolay@cumulusnetworks.com,
andrew@lunn.ch, vivien.didelot@savoirfairelinux.com,
f.fainelli@gmail.com, stephen@networkplumber.org,
bridge@lists.linux-foundation.org, mlxsw, Ido Schimmel
In-Reply-To: <20181013171725.3261-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
When offloading VXLAN devices, drivers need to know about events in
VXLAN FDB database. Since VXLAN models a bridge, it is natural to
distribute the VXLAN FDB notifications using the pre-existing switchdev
notification mechanism.
To that end, introduce two new notification types:
SWITCHDEV_VXLAN_FDB_ADD_TO_DEVICE and SWITCHDEV_VXLAN_FDB_DEL_TO_DEVICE.
Introduce a new function, vxlan_fdb_switchdev_call_notifiers() to send
the new notifier types, and a struct switchdev_notifier_vxlan_fdb_info
to communicate the details of the FDB entry under consideration.
Invoke the new function from vxlan_fdb_notify().
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/vxlan.c | 46 +++++++++++++++++++++++++++++++++++++++--
include/net/switchdev.h | 3 +++
include/net/vxlan.h | 11 ++++++++++
3 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 9bfd562aa81c..f8b579648d42 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -327,8 +327,8 @@ static inline size_t vxlan_nlmsg_size(void)
+ nla_total_size(sizeof(struct nda_cacheinfo));
}
-static void vxlan_fdb_notify(struct vxlan_dev *vxlan, struct vxlan_fdb *fdb,
- struct vxlan_rdst *rd, int type)
+static void __vxlan_fdb_notify(struct vxlan_dev *vxlan, struct vxlan_fdb *fdb,
+ struct vxlan_rdst *rd, int type)
{
struct net *net = dev_net(vxlan->dev);
struct sk_buff *skb;
@@ -353,6 +353,48 @@ static void vxlan_fdb_notify(struct vxlan_dev *vxlan, struct vxlan_fdb *fdb,
rtnl_set_sk_err(net, RTNLGRP_NEIGH, err);
}
+static void vxlan_fdb_switchdev_call_notifiers(struct vxlan_dev *vxlan,
+ struct vxlan_fdb *fdb,
+ struct vxlan_rdst *rd,
+ bool adding)
+{
+ struct switchdev_notifier_vxlan_fdb_info info;
+ enum switchdev_notifier_type notifier_type;
+
+ if (WARN_ON(!rd))
+ return;
+
+ notifier_type = adding ? SWITCHDEV_VXLAN_FDB_ADD_TO_DEVICE
+ : SWITCHDEV_VXLAN_FDB_DEL_TO_DEVICE;
+
+ info = (struct switchdev_notifier_vxlan_fdb_info){
+ .remote_ip = rd->remote_ip,
+ .remote_port = rd->remote_port,
+ .remote_vni = rd->remote_vni,
+ .remote_ifindex = rd->remote_ifindex,
+ .vni = fdb->vni,
+ };
+ memcpy(info.eth_addr, fdb->eth_addr, ETH_ALEN);
+
+ call_switchdev_notifiers(notifier_type, vxlan->dev,
+ &info.info);
+}
+
+static void vxlan_fdb_notify(struct vxlan_dev *vxlan, struct vxlan_fdb *fdb,
+ struct vxlan_rdst *rd, int type)
+{
+ switch (type) {
+ case RTM_NEWNEIGH:
+ vxlan_fdb_switchdev_call_notifiers(vxlan, fdb, rd, true);
+ break;
+ case RTM_DELNEIGH:
+ vxlan_fdb_switchdev_call_notifiers(vxlan, fdb, rd, false);
+ break;
+ }
+
+ __vxlan_fdb_notify(vxlan, fdb, rd, type);
+}
+
static void vxlan_ip_miss(struct net_device *dev, union vxlan_addr *ipa)
{
struct vxlan_dev *vxlan = netdev_priv(dev);
diff --git a/include/net/switchdev.h b/include/net/switchdev.h
index d574ce63bf22..47199a11c586 100644
--- a/include/net/switchdev.h
+++ b/include/net/switchdev.h
@@ -145,6 +145,9 @@ enum switchdev_notifier_type {
SWITCHDEV_FDB_ADD_TO_DEVICE,
SWITCHDEV_FDB_DEL_TO_DEVICE,
SWITCHDEV_FDB_OFFLOADED,
+
+ SWITCHDEV_VXLAN_FDB_ADD_TO_DEVICE,
+ SWITCHDEV_VXLAN_FDB_DEL_TO_DEVICE,
};
struct switchdev_notifier_info {
diff --git a/include/net/vxlan.h b/include/net/vxlan.h
index dd3d72ce64b6..a82b735decbc 100644
--- a/include/net/vxlan.h
+++ b/include/net/vxlan.h
@@ -5,6 +5,7 @@
#include <linux/if_vlan.h>
#include <net/udp_tunnel.h>
#include <net/dst_metadata.h>
+#include <net/switchdev.h>
/* VXLAN protocol (RFC 7348) header:
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -402,4 +403,14 @@ static inline bool vxlan_addr_multicast(const union vxlan_addr *ipa)
#endif /* IS_ENABLED(CONFIG_IPV6) */
+struct switchdev_notifier_vxlan_fdb_info {
+ struct switchdev_notifier_info info; /* must be first */
+ union vxlan_addr remote_ip;
+ __be16 remote_port;
+ __be32 remote_vni;
+ u32 remote_ifindex;
+ u8 eth_addr[ETH_ALEN];
+ __be32 vni;
+};
+
#endif
--
2.17.2
^ permalink raw reply related
* [PATCH net-next 18/18] mlxsw: spectrum_switchdev: Add support for VxLAN encapsulation
From: Ido Schimmel @ 2018-10-13 17:18 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, Petr Machata, ivecera@redhat.com,
roopa@cumulusnetworks.com, nikolay@cumulusnetworks.com,
andrew@lunn.ch, vivien.didelot@savoirfairelinux.com,
f.fainelli@gmail.com, stephen@networkplumber.org,
bridge@lists.linux-foundation.org, mlxsw, Ido Schimmel
In-Reply-To: <20181013171725.3261-1-idosch@mellanox.com>
In the device, VxLAN encapsulation takes place in the FDB table where
certain {MAC, FID} entries are programmed with an underlay unicast IP.
MAC addresses that are not programmed in the FDB are flooded to the
relevant local ports and also to a list of underlay unicast IPs that are
programmed using the all zeros MAC address in the VxLAN driver.
One difference between the hardware and software data paths is the fact
that in the software data path there are two FDB lookups prior to the
encapsulation of the packet. First in the bridge's FDB table using {MAC,
VID} and another in the VxLAN's FDB table using {MAC, VNI}.
Therefore, when a new VxLAN FDB entry is notified, it is only programmed
to the device if there is a corresponding entry in the bridge's FDB
table. Similarly, when a new bridge FDB entry pointing to the VxLAN
device is notified, it is only programmed to the device if there is a
corresponding entry in the VxLAN's FDB table.
Note that the above scheme will result in a discrepancy between both
data paths if only one FDB table is populated in the software data path.
For example, if only the bridge's FDB is populated with an entry
pointing to a VxLAN device, then a packet hitting the entry will only be
flooded by the kernel to remote VTEPs whereas the device will also flood
the packets to other local ports member in the VLAN.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Petr Machata <petrm@mellanox.com>
---
.../mellanox/mlxsw/spectrum_switchdev.c | 406 +++++++++++++++++-
1 file changed, 405 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index bab7712e1721..bc60d7a8b49d 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -92,6 +92,11 @@ struct mlxsw_sp_bridge_ops {
struct mlxsw_sp_fid *
(*fid_get)(struct mlxsw_sp_bridge_device *bridge_device,
u16 vid);
+ struct mlxsw_sp_fid *
+ (*fid_lookup)(struct mlxsw_sp_bridge_device *bridge_device,
+ u16 vid);
+ u16 (*fid_vid)(struct mlxsw_sp_bridge_device *bridge_device,
+ const struct mlxsw_sp_fid *fid);
};
static int
@@ -1242,6 +1247,51 @@ static enum mlxsw_reg_sfd_op mlxsw_sp_sfd_op(bool adding)
MLXSW_REG_SFD_OP_WRITE_REMOVE;
}
+static int mlxsw_sp_port_fdb_tunnel_uc_op(struct mlxsw_sp *mlxsw_sp,
+ const char *mac, u16 fid,
+ enum mlxsw_sp_l3proto proto,
+ const union mlxsw_sp_l3addr *addr,
+ bool adding, bool dynamic)
+{
+ enum mlxsw_reg_sfd_uc_tunnel_protocol sfd_proto;
+ char *sfd_pl;
+ u8 num_rec;
+ u32 uip;
+ int err;
+
+ switch (proto) {
+ case MLXSW_SP_L3_PROTO_IPV4:
+ uip = be32_to_cpu(addr->addr4);
+ sfd_proto = MLXSW_REG_SFD_UC_TUNNEL_PROTOCOL_IPV4;
+ break;
+ case MLXSW_SP_L3_PROTO_IPV6: /* fall through */
+ default:
+ WARN_ON(1);
+ return -EOPNOTSUPP;
+ }
+
+ sfd_pl = kmalloc(MLXSW_REG_SFD_LEN, GFP_KERNEL);
+ if (!sfd_pl)
+ return -ENOMEM;
+
+ mlxsw_reg_sfd_pack(sfd_pl, mlxsw_sp_sfd_op(adding), 0);
+ mlxsw_reg_sfd_uc_tunnel_pack(sfd_pl, 0,
+ mlxsw_sp_sfd_rec_policy(dynamic), mac, fid,
+ MLXSW_REG_SFD_REC_ACTION_NOP, uip,
+ sfd_proto);
+ num_rec = mlxsw_reg_sfd_num_rec_get(sfd_pl);
+ err = mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(sfd), sfd_pl);
+ if (err)
+ goto out;
+
+ if (num_rec != mlxsw_reg_sfd_num_rec_get(sfd_pl))
+ err = -EBUSY;
+
+out:
+ kfree(sfd_pl);
+ return err;
+}
+
static int __mlxsw_sp_port_fdb_uc_op(struct mlxsw_sp *mlxsw_sp, u8 local_port,
const char *mac, u16 fid, bool adding,
enum mlxsw_reg_sfd_rec_action action,
@@ -1979,12 +2029,29 @@ mlxsw_sp_bridge_8021q_fid_get(struct mlxsw_sp_bridge_device *bridge_device,
return mlxsw_sp_fid_8021q_get(mlxsw_sp, vid);
}
+static struct mlxsw_sp_fid *
+mlxsw_sp_bridge_8021q_fid_lookup(struct mlxsw_sp_bridge_device *bridge_device,
+ u16 vid)
+{
+ WARN_ON(1);
+ return NULL;
+}
+
+static u16
+mlxsw_sp_bridge_8021q_fid_vid(struct mlxsw_sp_bridge_device *bridge_device,
+ const struct mlxsw_sp_fid *fid)
+{
+ return mlxsw_sp_fid_8021q_vid(fid);
+}
+
static const struct mlxsw_sp_bridge_ops mlxsw_sp_bridge_8021q_ops = {
.port_join = mlxsw_sp_bridge_8021q_port_join,
.port_leave = mlxsw_sp_bridge_8021q_port_leave,
.vxlan_join = mlxsw_sp_bridge_8021q_vxlan_join,
.vxlan_leave = mlxsw_sp_bridge_8021q_vxlan_leave,
.fid_get = mlxsw_sp_bridge_8021q_fid_get,
+ .fid_lookup = mlxsw_sp_bridge_8021q_fid_lookup,
+ .fid_vid = mlxsw_sp_bridge_8021q_fid_vid,
};
static bool
@@ -2140,12 +2207,34 @@ mlxsw_sp_bridge_8021d_fid_get(struct mlxsw_sp_bridge_device *bridge_device,
return ERR_PTR(err);
}
+static struct mlxsw_sp_fid *
+mlxsw_sp_bridge_8021d_fid_lookup(struct mlxsw_sp_bridge_device *bridge_device,
+ u16 vid)
+{
+ struct mlxsw_sp *mlxsw_sp = mlxsw_sp_lower_get(bridge_device->dev);
+
+ /* The only valid VLAN for a VLAN-unaware bridge is 0 */
+ if (vid)
+ return NULL;
+
+ return mlxsw_sp_fid_8021d_lookup(mlxsw_sp, bridge_device->dev->ifindex);
+}
+
+static u16
+mlxsw_sp_bridge_8021d_fid_vid(struct mlxsw_sp_bridge_device *bridge_device,
+ const struct mlxsw_sp_fid *fid)
+{
+ return 0;
+}
+
static const struct mlxsw_sp_bridge_ops mlxsw_sp_bridge_8021d_ops = {
.port_join = mlxsw_sp_bridge_8021d_port_join,
.port_leave = mlxsw_sp_bridge_8021d_port_leave,
.vxlan_join = mlxsw_sp_bridge_8021d_vxlan_join,
.vxlan_leave = mlxsw_sp_bridge_8021d_vxlan_leave,
.fid_get = mlxsw_sp_bridge_8021d_fid_get,
+ .fid_lookup = mlxsw_sp_bridge_8021d_fid_lookup,
+ .fid_vid = mlxsw_sp_bridge_8021d_fid_vid,
};
int mlxsw_sp_port_bridge_join(struct mlxsw_sp_port *mlxsw_sp_port,
@@ -2419,11 +2508,126 @@ static void mlxsw_sp_fdb_notify_work(struct work_struct *work)
struct mlxsw_sp_switchdev_event_work {
struct work_struct work;
- struct switchdev_notifier_fdb_info fdb_info;
+ union {
+ struct switchdev_notifier_fdb_info fdb_info;
+ struct switchdev_notifier_vxlan_fdb_info vxlan_fdb_info;
+ };
struct net_device *dev;
unsigned long event;
};
+static void
+mlxsw_sp_switchdev_vxlan_addr_convert(const union vxlan_addr *vxlan_addr,
+ enum mlxsw_sp_l3proto *proto,
+ union mlxsw_sp_l3addr *addr)
+{
+ if (vxlan_addr->sa.sa_family == AF_INET) {
+ addr->addr4 = vxlan_addr->sin.sin_addr.s_addr;
+ *proto = MLXSW_SP_L3_PROTO_IPV4;
+ } else {
+ addr->addr6 = vxlan_addr->sin6.sin6_addr;
+ *proto = MLXSW_SP_L3_PROTO_IPV6;
+ }
+}
+
+static void
+mlxsw_sp_switchdev_bridge_vxlan_fdb_event(struct mlxsw_sp *mlxsw_sp,
+ struct mlxsw_sp_switchdev_event_work *
+ switchdev_work,
+ struct mlxsw_sp_fid *fid, __be32 vni)
+{
+ struct switchdev_notifier_vxlan_fdb_info vxlan_fdb_info;
+ struct switchdev_notifier_fdb_info *fdb_info;
+ struct net_device *dev = switchdev_work->dev;
+ enum mlxsw_sp_l3proto proto;
+ union mlxsw_sp_l3addr addr;
+ int err;
+
+ fdb_info = &switchdev_work->fdb_info;
+ err = vxlan_fdb_find_uc(dev, fdb_info->addr, vni, &vxlan_fdb_info);
+ if (err)
+ return;
+
+ mlxsw_sp_switchdev_vxlan_addr_convert(&vxlan_fdb_info.remote_ip,
+ &proto, &addr);
+
+ switch (switchdev_work->event) {
+ case SWITCHDEV_FDB_ADD_TO_DEVICE:
+ err = mlxsw_sp_port_fdb_tunnel_uc_op(mlxsw_sp,
+ vxlan_fdb_info.eth_addr,
+ mlxsw_sp_fid_index(fid),
+ proto, &addr, true, false);
+ if (err)
+ return;
+ vxlan_fdb_info.offloaded = true;
+ call_switchdev_notifiers(SWITCHDEV_VXLAN_FDB_OFFLOADED, dev,
+ &vxlan_fdb_info.info);
+ mlxsw_sp_fdb_call_notifiers(SWITCHDEV_FDB_OFFLOADED,
+ vxlan_fdb_info.eth_addr,
+ fdb_info->vid, dev, true);
+ break;
+ case SWITCHDEV_FDB_DEL_TO_DEVICE:
+ err = mlxsw_sp_port_fdb_tunnel_uc_op(mlxsw_sp,
+ vxlan_fdb_info.eth_addr,
+ mlxsw_sp_fid_index(fid),
+ proto, &addr, false,
+ false);
+ vxlan_fdb_info.offloaded = false;
+ call_switchdev_notifiers(SWITCHDEV_VXLAN_FDB_OFFLOADED, dev,
+ &vxlan_fdb_info.info);
+ break;
+ }
+}
+
+static void
+mlxsw_sp_switchdev_bridge_nve_fdb_event(struct mlxsw_sp_switchdev_event_work *
+ switchdev_work)
+{
+ struct mlxsw_sp_bridge_device *bridge_device;
+ struct net_device *dev = switchdev_work->dev;
+ struct net_device *br_dev;
+ struct mlxsw_sp *mlxsw_sp;
+ struct mlxsw_sp_fid *fid;
+ __be32 vni;
+ int err;
+
+ if (switchdev_work->event != SWITCHDEV_FDB_ADD_TO_DEVICE &&
+ switchdev_work->event != SWITCHDEV_FDB_DEL_TO_DEVICE)
+ return;
+
+ if (!switchdev_work->fdb_info.added_by_user)
+ return;
+
+ if (!netif_running(dev))
+ return;
+ br_dev = netdev_master_upper_dev_get(dev);
+ if (!br_dev)
+ return;
+ if (!netif_is_bridge_master(br_dev))
+ return;
+ mlxsw_sp = mlxsw_sp_lower_get(br_dev);
+ if (!mlxsw_sp)
+ return;
+ bridge_device = mlxsw_sp_bridge_device_find(mlxsw_sp->bridge, br_dev);
+ if (!bridge_device)
+ return;
+
+ fid = bridge_device->ops->fid_lookup(bridge_device,
+ switchdev_work->fdb_info.vid);
+ if (!fid)
+ return;
+
+ err = mlxsw_sp_fid_vni(fid, &vni);
+ if (err)
+ goto out;
+
+ mlxsw_sp_switchdev_bridge_vxlan_fdb_event(mlxsw_sp, switchdev_work, fid,
+ vni);
+
+out:
+ mlxsw_sp_fid_put(fid);
+}
+
static void mlxsw_sp_switchdev_bridge_fdb_event_work(struct work_struct *work)
{
struct mlxsw_sp_switchdev_event_work *switchdev_work =
@@ -2434,6 +2638,11 @@ static void mlxsw_sp_switchdev_bridge_fdb_event_work(struct work_struct *work)
int err;
rtnl_lock();
+ if (netif_is_vxlan(dev)) {
+ mlxsw_sp_switchdev_bridge_nve_fdb_event(switchdev_work);
+ goto out;
+ }
+
mlxsw_sp_port = mlxsw_sp_port_dev_lower_find(dev);
if (!mlxsw_sp_port)
goto out;
@@ -2473,6 +2682,189 @@ static void mlxsw_sp_switchdev_bridge_fdb_event_work(struct work_struct *work)
dev_put(dev);
}
+static void
+mlxsw_sp_switchdev_vxlan_fdb_add(struct mlxsw_sp *mlxsw_sp,
+ struct mlxsw_sp_switchdev_event_work *
+ switchdev_work)
+{
+ struct switchdev_notifier_vxlan_fdb_info *vxlan_fdb_info;
+ struct mlxsw_sp_bridge_device *bridge_device;
+ struct net_device *dev = switchdev_work->dev;
+ u8 all_zeros_mac[ETH_ALEN] = { 0 };
+ enum mlxsw_sp_l3proto proto;
+ union mlxsw_sp_l3addr addr;
+ struct net_device *br_dev;
+ struct mlxsw_sp_fid *fid;
+ u16 vid;
+ int err;
+
+ vxlan_fdb_info = &switchdev_work->vxlan_fdb_info;
+ br_dev = netdev_master_upper_dev_get(dev);
+
+ bridge_device = mlxsw_sp_bridge_device_find(mlxsw_sp->bridge, br_dev);
+ if (!bridge_device)
+ return;
+
+ fid = mlxsw_sp_fid_lookup_by_vni(mlxsw_sp, vxlan_fdb_info->vni);
+ if (!fid)
+ return;
+
+ mlxsw_sp_switchdev_vxlan_addr_convert(&vxlan_fdb_info->remote_ip,
+ &proto, &addr);
+
+ if (ether_addr_equal(vxlan_fdb_info->eth_addr, all_zeros_mac)) {
+ err = mlxsw_sp_nve_flood_ip_add(mlxsw_sp, fid, proto, &addr);
+ if (err) {
+ mlxsw_sp_fid_put(fid);
+ return;
+ }
+ vxlan_fdb_info->offloaded = true;
+ call_switchdev_notifiers(SWITCHDEV_VXLAN_FDB_OFFLOADED, dev,
+ &vxlan_fdb_info->info);
+ mlxsw_sp_fid_put(fid);
+ return;
+ }
+
+ /* The device has a single FDB table, whereas Linux has two - one
+ * in the bridge driver and another in the VxLAN driver. We only
+ * program an entry to the device if the MAC points to the VxLAN
+ * device in the bridge's FDB table
+ */
+ vid = bridge_device->ops->fid_vid(bridge_device, fid);
+ if (br_fdb_find_port(br_dev, vxlan_fdb_info->eth_addr, vid) != dev)
+ goto err_br_fdb_find;
+
+ err = mlxsw_sp_port_fdb_tunnel_uc_op(mlxsw_sp, vxlan_fdb_info->eth_addr,
+ mlxsw_sp_fid_index(fid), proto,
+ &addr, true, false);
+ if (err)
+ goto err_fdb_tunnel_uc_op;
+ vxlan_fdb_info->offloaded = true;
+ call_switchdev_notifiers(SWITCHDEV_VXLAN_FDB_OFFLOADED, dev,
+ &vxlan_fdb_info->info);
+ mlxsw_sp_fdb_call_notifiers(SWITCHDEV_FDB_OFFLOADED,
+ vxlan_fdb_info->eth_addr, vid, dev, true);
+
+ mlxsw_sp_fid_put(fid);
+
+ return;
+
+err_fdb_tunnel_uc_op:
+err_br_fdb_find:
+ mlxsw_sp_fid_put(fid);
+}
+
+static void
+mlxsw_sp_switchdev_vxlan_fdb_del(struct mlxsw_sp *mlxsw_sp,
+ struct mlxsw_sp_switchdev_event_work *
+ switchdev_work)
+{
+ struct switchdev_notifier_vxlan_fdb_info *vxlan_fdb_info;
+ struct mlxsw_sp_bridge_device *bridge_device;
+ struct net_device *dev = switchdev_work->dev;
+ struct net_device *br_dev = netdev_master_upper_dev_get(dev);
+ u8 all_zeros_mac[ETH_ALEN] = { 0 };
+ enum mlxsw_sp_l3proto proto;
+ union mlxsw_sp_l3addr addr;
+ struct mlxsw_sp_fid *fid;
+ u16 vid;
+
+ vxlan_fdb_info = &switchdev_work->vxlan_fdb_info;
+
+ bridge_device = mlxsw_sp_bridge_device_find(mlxsw_sp->bridge, br_dev);
+ if (!bridge_device)
+ return;
+
+ fid = mlxsw_sp_fid_lookup_by_vni(mlxsw_sp, vxlan_fdb_info->vni);
+ if (!fid)
+ return;
+
+ mlxsw_sp_switchdev_vxlan_addr_convert(&vxlan_fdb_info->remote_ip,
+ &proto, &addr);
+
+ if (ether_addr_equal(vxlan_fdb_info->eth_addr, all_zeros_mac)) {
+ mlxsw_sp_nve_flood_ip_del(mlxsw_sp, fid, proto, &addr);
+ mlxsw_sp_fid_put(fid);
+ return;
+ }
+
+ mlxsw_sp_port_fdb_tunnel_uc_op(mlxsw_sp, vxlan_fdb_info->eth_addr,
+ mlxsw_sp_fid_index(fid), proto, &addr,
+ false, false);
+ vid = bridge_device->ops->fid_vid(bridge_device, fid);
+ mlxsw_sp_fdb_call_notifiers(SWITCHDEV_FDB_OFFLOADED,
+ vxlan_fdb_info->eth_addr, vid, dev, false);
+
+ mlxsw_sp_fid_put(fid);
+}
+
+static void mlxsw_sp_switchdev_vxlan_fdb_event_work(struct work_struct *work)
+{
+ struct mlxsw_sp_switchdev_event_work *switchdev_work =
+ container_of(work, struct mlxsw_sp_switchdev_event_work, work);
+ struct net_device *dev = switchdev_work->dev;
+ struct mlxsw_sp *mlxsw_sp;
+ struct net_device *br_dev;
+
+ rtnl_lock();
+
+ if (!netif_running(dev))
+ goto out;
+ br_dev = netdev_master_upper_dev_get(dev);
+ if (!br_dev)
+ goto out;
+ if (!netif_is_bridge_master(br_dev))
+ goto out;
+ mlxsw_sp = mlxsw_sp_lower_get(br_dev);
+ if (!mlxsw_sp)
+ goto out;
+
+ switch (switchdev_work->event) {
+ case SWITCHDEV_VXLAN_FDB_ADD_TO_DEVICE:
+ mlxsw_sp_switchdev_vxlan_fdb_add(mlxsw_sp, switchdev_work);
+ break;
+ case SWITCHDEV_VXLAN_FDB_DEL_TO_DEVICE:
+ mlxsw_sp_switchdev_vxlan_fdb_del(mlxsw_sp, switchdev_work);
+ break;
+ }
+
+out:
+ rtnl_unlock();
+ kfree(switchdev_work);
+ dev_put(dev);
+}
+
+static int
+mlxsw_sp_switchdev_vxlan_work_prepare(struct mlxsw_sp_switchdev_event_work *
+ switchdev_work,
+ struct switchdev_notifier_info *info)
+{
+ struct vxlan_dev *vxlan = netdev_priv(switchdev_work->dev);
+ struct switchdev_notifier_vxlan_fdb_info *vxlan_fdb_info;
+ struct vxlan_config *cfg = &vxlan->cfg;
+
+ vxlan_fdb_info = container_of(info,
+ struct switchdev_notifier_vxlan_fdb_info,
+ info);
+
+ if (vxlan_fdb_info->remote_port != cfg->dst_port)
+ return -EOPNOTSUPP;
+ if (vxlan_fdb_info->remote_vni != cfg->vni)
+ return -EOPNOTSUPP;
+ if (vxlan_fdb_info->vni != cfg->vni)
+ return -EOPNOTSUPP;
+ if (vxlan_fdb_info->remote_ifindex)
+ return -EOPNOTSUPP;
+ if (is_multicast_ether_addr(vxlan_fdb_info->eth_addr))
+ return -EOPNOTSUPP;
+ if (vxlan_addr_multicast(&vxlan_fdb_info->remote_ip))
+ return -EOPNOTSUPP;
+
+ switchdev_work->vxlan_fdb_info = *vxlan_fdb_info;
+
+ return 0;
+}
+
/* Called under rcu_read_lock() */
static int mlxsw_sp_switchdev_event(struct notifier_block *unused,
unsigned long event, void *ptr)
@@ -2482,6 +2874,7 @@ static int mlxsw_sp_switchdev_event(struct notifier_block *unused,
struct switchdev_notifier_fdb_info *fdb_info;
struct switchdev_notifier_info *info = ptr;
struct net_device *br_dev;
+ int err;
/* Tunnel devices are not our uppers, so check their master instead */
br_dev = netdev_master_upper_dev_get_rcu(dev);
@@ -2522,6 +2915,16 @@ static int mlxsw_sp_switchdev_event(struct notifier_block *unused,
*/
dev_hold(dev);
break;
+ case SWITCHDEV_VXLAN_FDB_ADD_TO_DEVICE: /* fall through */
+ case SWITCHDEV_VXLAN_FDB_DEL_TO_DEVICE:
+ INIT_WORK(&switchdev_work->work,
+ mlxsw_sp_switchdev_vxlan_fdb_event_work);
+ err = mlxsw_sp_switchdev_vxlan_work_prepare(switchdev_work,
+ info);
+ if (err)
+ goto err_vxlan_work_prepare;
+ dev_hold(dev);
+ break;
default:
kfree(switchdev_work);
return NOTIFY_DONE;
@@ -2531,6 +2934,7 @@ static int mlxsw_sp_switchdev_event(struct notifier_block *unused,
return NOTIFY_DONE;
+err_vxlan_work_prepare:
err_addr_alloc:
kfree(switchdev_work);
return NOTIFY_BAD;
--
2.17.2
^ permalink raw reply related
* [PATCH net-next 11/18] vxlan: Add netif_is_vxlan()
From: Ido Schimmel @ 2018-10-13 17:18 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, Petr Machata, ivecera@redhat.com,
roopa@cumulusnetworks.com, nikolay@cumulusnetworks.com,
andrew@lunn.ch, vivien.didelot@savoirfairelinux.com,
f.fainelli@gmail.com, stephen@networkplumber.org,
bridge@lists.linux-foundation.org, mlxsw, Ido Schimmel
In-Reply-To: <20181013171725.3261-1-idosch@mellanox.com>
Add the ability to determine whether a netdev is a VxLAN netdev by
calling the above mentioned function that checks the netdev's private
flags.
This will allow modules to identify netdev events involving a VxLAN
netdev and act accordingly. For example, drivers capable of VxLAN
offload will need to configure the underlying device when a VxLAN netdev
is being enslaved to an offloaded bridge.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Petr Machata <petrm@mellanox.com>
---
drivers/net/vxlan.c | 1 +
include/linux/netdevice.h | 8 ++++++++
2 files changed, 9 insertions(+)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index a646aa8e98ff..9bfd562aa81c 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -3178,6 +3178,7 @@ static int __vxlan_dev_create(struct net *net, struct net_device *dev,
if (err)
return err;
+ dev->priv_flags |= IFF_VXLAN;
dev->ethtool_ops = &vxlan_ethtool_ops;
/* create an fdb entry for a valid default destination */
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 22e4ef7bb701..290083ff285a 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1487,6 +1487,7 @@ struct net_device_ops {
* @IFF_NO_RX_HANDLER: device doesn't support the rx_handler hook
* @IFF_FAILOVER: device is a failover master device
* @IFF_FAILOVER_SLAVE: device is lower dev of a failover master device
+ * @IFF_VXLAN: device is a VxLAN device
*/
enum netdev_priv_flags {
IFF_802_1Q_VLAN = 1<<0,
@@ -1518,6 +1519,7 @@ enum netdev_priv_flags {
IFF_NO_RX_HANDLER = 1<<26,
IFF_FAILOVER = 1<<27,
IFF_FAILOVER_SLAVE = 1<<28,
+ IFF_VXLAN = 1<<29,
};
#define IFF_802_1Q_VLAN IFF_802_1Q_VLAN
@@ -1548,6 +1550,7 @@ enum netdev_priv_flags {
#define IFF_NO_RX_HANDLER IFF_NO_RX_HANDLER
#define IFF_FAILOVER IFF_FAILOVER
#define IFF_FAILOVER_SLAVE IFF_FAILOVER_SLAVE
+#define IFF_VXLAN IFF_VXLAN
/**
* struct net_device - The DEVICE structure.
@@ -4567,6 +4570,11 @@ static inline bool netif_is_failover_slave(const struct net_device *dev)
return dev->priv_flags & IFF_FAILOVER_SLAVE;
}
+static inline bool netif_is_vxlan(const struct net_device *dev)
+{
+ return dev->priv_flags & IFF_VXLAN;
+}
+
/* This device needs to keep skb dst for qdisc enqueue or ndo_start_xmit() */
static inline void netif_keep_dst(struct net_device *dev)
{
--
2.17.2
^ 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