* [PATCH][net-next][v2] net: bridge: fix a possible memory leak in __vlan_add
From: Li RongQing @ 2018-10-15 11:00 UTC (permalink / raw)
To: netdev; +Cc: bridge, nikolay, roopa
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: bridge@lists.linux-foundation.org
cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
CC: Roopa Prabhu <roopa@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..8c9297a01947 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -303,6 +303,10 @@ static int __vlan_add(struct net_bridge_vlan *v, u16 flags)
if (p) {
__vlan_vid_del(dev, br, v->vid);
if (masterv) {
+ if (v->stats && masterv->stats != v->stats)
+ free_percpu(v->stats);
+ v->stats = NULL;
+
br_vlan_put_master(masterv);
v->brvlan = NULL;
}
--
2.16.2
^ permalink raw reply related
* Re: [PATCH 2/2] 9p/trans_fd: put worker reqs on destroy
From: Dominique Martinet @ 2018-10-15 10:46 UTC (permalink / raw)
To: Tomas Bortoli
Cc: Dominique Martinet, v9fs-developer, netdev, LKML,
Eric Van Hensbergen, Latchesar Ionkov
In-Reply-To: <CAAHj5qgBteZQOkjF-n3OXvN9e0v6NYEsqg3YOitEKW0jikTpng@mail.gmail.com>
Tomas Bortoli wrote on Tue, Oct 09, 2018:
> Il giorno mar 9 ott 2018 alle ore 06:06 Dominique Martinet
> > Fixes: 728356dedeff8 ("9p: Add refcount to p9_req_t")
> > Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
> > Cc: Eric Van Hensbergen <ericvh@gmail.com>
> > Cc: Latchesar Ionkov <lucho@ionkov.net>
> > Cc: Tomas Bortoli <tomasbortoli@gmail.com>
>
> Reviewed-by: Tomas Bortoli <tomasbortoli@gmail.com>
Thanks Tomas.
Tests seem ok, I've push both patches to my next branch, and will submit
them with the rest in a couple of weeks.
Quite a few of my patches haven't had reviews this cycle, if you read
this and have a bit of time, please pull my branch and have a read, or
each commit has a link to the lkml post to reply somewhat easily.
Reminder gir url:
git://github.com/martinetd/linux 9p-next
--
Dominique
^ permalink raw reply
* Apply For Affordable Loan Offer
From: rifat @ 2018-10-15 10:27 UTC (permalink / raw)
Cc: mooney, morenom, moshrif, mozharovskiy, mr.s.adams,
muhle-bammbuhle, murdoch, muriel.groves, musart, music, muzyka,
mvickers, mvillarino, mylifeismyrule, mzahan, n.dzyubenko,
n.muratova, n.oleshkevich, n2006, n230063, narimantas.paliulis,
narimantas.samalavicius, nataber, naujininkai,
necpalova.magdalena, nehmeazoury, nerijus, nerijus,
nestor-internet, netdev, news, next, nickyra3, nikolay
Do you need a loan? If YES Kindly contact us via: citigrouploaninvestment@aol.com
^ permalink raw reply
* Re: net/wan: hostess_sv11 + z85230 problems
From: Alan Cox @ 2018-10-15 10:29 UTC (permalink / raw)
To: Krzysztof Hałasa; +Cc: Randy Dunlap, netdev@vger.kernel.org, LKML
In-Reply-To: <m34ldnd3ju.fsf@t19.piap.pl>
On Mon, 15 Oct 2018 10:20:21 +0200
khalasa@piap.pl (Krzysztof Hałasa) wrote:
> Hi,
>
> Randy Dunlap <rdunlap@infradead.org> writes:
>
> > kernel 4.19-rc7, on i386, with NO wan/hdlc/hostess/z85230 hardware:
> >
> > modprobe hostess_sv11 + autoload of z85230 give:
>
> BTW Hostess SV11 is apparently an ISA card, with all those problems.
Actually it worked perfectly well of old but people kept changing it
who didn't have hardware. Please just delete the driver instead of
pretending we can test it.
Nobody has one, even if they did there is no use for it as nobody runs
their internet over an old HDLC 64K link any more.
And we know since it's broken several ways by bit-rot that nobody uses it.
Alan
^ permalink raw reply
* Re: BBR and TCP internal pacing causing interrupt storm with pfifo_fast
From: Gasper Zejn @ 2018-10-15 10:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Eric Dumazet, Kevin Yang, netdev
In-Reply-To: <CANn89iLOHxOOuGzqNODk0hNWJ7an0bZXs4G-8mQjq3WWhZPo9g@mail.gmail.com>
On 09. 10. 2018 19:26, Eric Dumazet wrote:
> On Tue, Oct 9, 2018 at 10:22 AM Gasper Zejn <zelo.zejn@gmail.com> wrote:
>> On 09. 10. 2018 19:00, Eric Dumazet wrote:
>>> On 10/09/2018 09:38 AM, Gasper Zejn wrote:
>>>> Hello,
>>>>
>>>> I am seeing interrupt storms of over 100k-900k local timer interrupts
>>>> when changing between network devices or networks with open TCP
>>>> connections when not using sch_fq (I was using pfifo_fast). Using sch_fq
>>>> makes the bug with interrupt storm go away.
>>>>
>>> That is for what kind of traffic ?
>>>
>>> If your TCP flows send 100k-3M packets per second, then yes, the pacing timers
>>> could be setup in the 100k-900k range.
>>>
>> Traffic is nowhere in that range, think of having a few browser tabs of
>> javascript rich
>> web pages open, mostly idle, for example slack, gmail or tweetdeck. No
>> significant
>> packet rate is needed, just open connections.
> No idea of what is going on really. A repro would be nice.
I've tried to isolate the issue as best I could. There seems to be an
issue if the TCP socket has keepalive set and send queue is not empty
and the route goes away.
https://github.com/zejn/bbr_pfifo_interrupts_issue
Hope this helps,
Gasper
^ permalink raw reply
* Re: [PATCH net 1/2] geneve, vxlan: Don't check skb_dst() twice
From: Nicolas Dichtel @ 2018-10-15 10:19 UTC (permalink / raw)
To: Stefano Brivio, David S. Miller; +Cc: Xin Long, Sabrina Dubroca, netdev
In-Reply-To: <f58a94b95460594c31348cc517f3917bbb9cc51e.1539381018.git.sbrivio@redhat.com>
Le 12/10/2018 à 23:53, Stefano Brivio a écrit :
> Commit f15ca723c1eb ("net: don't call update_pmtu unconditionally") avoids
> that we try updating PMTU for a non-existent destination, but didn't clean
> up cases where the check was already explicit. Drop those redundant checks.
Yes, I leave them to avoid calculating the new mtu value when not needed. We are
in the xmit path.
As skb_dst_update_pmtu() is inlined, we probably don't care, but gcc could still
decide to not inline it.
Regards,
Nicolas
^ permalink raw reply
* Re: [PATCH] dt-bindings: Add bindings for aliases node
From: Rob Herring @ 2018-10-15 18:00 UTC (permalink / raw)
To: Brian Norris
Cc: Geert Uytterhoeven, Matthias Kaehlcke, Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, linux-wireless, linux-spi, netdev,
swboyd, Florian Fainelli
In-Reply-To: <20181009183141.GA126050@ban.mtv.corp.google.com>
On Tue, Oct 09, 2018 at 11:31:42AM -0700, Brian Norris wrote:
> On Tue, Oct 09, 2018 at 09:22:07AM +0200, Geert Uytterhoeven wrote:
> > Please note these aliases become cumbersome once you start considering
> > (dynamic) DT overlays. That's why I made them optional in the sh-sci
> > serial driver, cfr. commit 7678f4c20fa7670f ("serial: sh-sci: Add support
> > for dynamic instances").
>
> Note that as I understand it, the entire point of documenting this sort
> of thing is to help solidify the interface between a DT aware boot
> program (e.g., bootloader) and a device tree which is provided
> separately, to avoid memorizing node/path hierarchy. It doesn't need to
> (and doesn't, as I read it) enforce an OS's device naming policy.
I'm all for documenting this primarily to prevent folks from just adding
whatever they wish in /aliases. Some platforms seem to want to have
aliases for everything.
> > Relevant parts of the commit description are:
> >
> > On DT platforms, the sh-sci driver requires the presence of "serialN"
> > aliases in DT, from which instance IDs are derived. If a DT alias is
> > missing, the drivers fails to probe the corresponding serial port.
> >
> > This becomes cumbersome when considering DT overlays, as currently
> > there is no upstream support for dynamically updating the /aliases node
> > in DT.
>
> That part is not a DT spec problem :)
>
> > Furthermore, even in the presence of such support, hardcoded
> > instance IDs in independent overlays are prone to conflicts.
> >
> > Hence add support for dynamic instance IDs, to be used in the absence of
> > a DT alias. This makes serial ports behave similar to I2C and SPI
> > buses, which already support dynamic instances.
>
> This seems to be a much different sort of problem. People always love
> having predictable IDs given by the OS (myself included), but that's
> just plain hard to do and impossible in some cases. I don't think that's
> what this document is about though.
>
> IOW, this document seems pretty consistent with the above: it doesn't
> require the usage of aliases (and it seems silly to have a driver
> *require* an alias) -- it just documents how one should name such an
> alias if you expect multiple independent software components to
> understand it.
>
> > To clarify my point: R-Car M2-W has 4 different types of serial ports, for a
> > total of 18 ports, and the two ports on a board labeled 0 and 1 may not
> > correspond to the physical first two ports (what's "first" in a collection of
> > 4 different types?).
> >
> > Aliases may be fine for referring to the main serial console (labeled
> > port 0 on the device, too), and the primary Ethernet interface (so U-Boot
> > knows where to add the "local-mac-address" property), but beyond that,
> > I think they should be avoided.
This basically matches my opinion on aliases.
I'd decouple it from board labels a bit. Sometimes the numbering may
match, but others not. What if a board serial port is labeled "DBG" for
example? I think 'label' is the right way to handle human identifible
ports (and then we should have something like /dev/serial/by-label/...).
> That's fair enough. Just because the solution isn't an all-purpose tool
> doesn't mean it shouldn't be documented. The general concept is already
> in ePAPR, but it's just not very specific about property names.
Agreed. I guess the question is what to do on used, but not recommended
aliases. I would put SPI and I2C into that category BTW.
Rob
^ permalink raw reply
* Re: [PATCH stable 4.9 v2 00/29] backport of IP fragmentation fixes
From: Eric Dumazet @ 2018-10-15 17:53 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David Miller, Greg Kroah-Hartman, stable, sthemmin
In-Reply-To: <e9b8ade3-e52e-d7a5-2238-77b4e9e55b60@gmail.com>
On Mon, Oct 15, 2018 at 10:47 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>
>
> On 10/10/2018 12:29 PM, Florian Fainelli wrote:
> > This is based on Stephen's v4.14 patches, with the necessary merge
> > conflicts, and the lack of timer_setup() on the 4.9 baseline.
> >
> > Perf results on a gigabit capable system, before and after are below.
> >
> > Series can also be found here:
> >
> > https://github.com/ffainelli/linux/commits/fragment-stack-v4.9-v2
> >
> > Changes in v2:
> >
> > - drop "net: sk_buff rbnode reorg"
> > - added original "ip: use rb trees for IP frag queue." commit
>
> Eric, does this look reasonable to you?
Yes, thanks a lot Florian.
>
> >
> > Before patches:
> >
> > PerfTop: 180 irqs/sec kernel:78.9% exact: 0.0% [4000Hz cycles:ppp], (all, 4 CPUs)
> > -------------------------------------------------------------------------------
> >
> > 34.81% [kernel] [k] ip_defrag
> > 4.57% [kernel] [k] arch_cpu_idle
> > 2.09% [kernel] [k] fib_table_lookup
> > 1.74% [kernel] [k] finish_task_switch
> > 1.57% [kernel] [k] v7_dma_inv_range
> > 1.47% [kernel] [k] __netif_receive_skb_core
> > 1.06% [kernel] [k] __slab_free
> > 1.04% [kernel] [k] __netdev_alloc_skb
> > 0.99% [kernel] [k] ip_route_input_noref
> > 0.96% [kernel] [k] dev_gro_receive
> > 0.96% [kernel] [k] tick_nohz_idle_enter
> > 0.93% [kernel] [k] bcm_sysport_poll
> > 0.92% [kernel] [k] skb_release_data
> > 0.91% [kernel] [k] __memzero
> > 0.90% [kernel] [k] __free_page_frag
> > 0.87% [kernel] [k] ip_rcv
> > 0.77% [kernel] [k] eth_type_trans
> > 0.71% [kernel] [k] _raw_spin_unlock_irqrestore
> > 0.68% [kernel] [k] tick_nohz_idle_exit
> > 0.65% [kernel] [k] bcm_sysport_rx_refill
> >
> > After patches:
> >
> > PerfTop: 214 irqs/sec kernel:80.4% exact: 0.0% [4000Hz cycles:ppp], (all, 4 CPUs)
> > -------------------------------------------------------------------------------
> >
> > 6.61% [kernel] [k] arch_cpu_idle
> > 3.77% [kernel] [k] ip_defrag
> > 3.65% [kernel] [k] v7_dma_inv_range
> > 3.18% [kernel] [k] fib_table_lookup
> > 3.04% [kernel] [k] __netif_receive_skb_core
> > 2.31% [kernel] [k] finish_task_switch
> > 2.31% [kernel] [k] _raw_spin_unlock_irqrestore
> > 1.65% [kernel] [k] bcm_sysport_poll
> > 1.63% [kernel] [k] ip_route_input_noref
> > 1.63% [kernel] [k] __memzero
> > 1.58% [kernel] [k] __netdev_alloc_skb
> > 1.47% [kernel] [k] tick_nohz_idle_enter
> > 1.40% [kernel] [k] __slab_free
> > 1.32% [kernel] [k] ip_rcv
> > 1.32% [kernel] [k] __softirqentry_text_start
> > 1.30% [kernel] [k] dev_gro_receive
> > 1.23% [kernel] [k] bcm_sysport_rx_refill
> > 1.11% [kernel] [k] tick_nohz_idle_exit
> > 1.06% [kernel] [k] memcmp
> > 1.02% [kernel] [k] dma_cache_maint_page
> >
> >
> > Dan Carpenter (1):
> > ipv4: frags: precedence bug in ip_expire()
> >
> > Eric Dumazet (21):
> > inet: frags: change inet_frags_init_net() return value
> > inet: frags: add a pointer to struct netns_frags
> > inet: frags: refactor ipfrag_init()
> > inet: frags: refactor ipv6_frag_init()
> > inet: frags: refactor lowpan_net_frag_init()
> > ipv6: export ip6 fragments sysctl to unprivileged users
> > rhashtable: add schedule points
> > inet: frags: use rhashtables for reassembly units
> > inet: frags: remove some helpers
> > inet: frags: get rif of inet_frag_evicting()
> > inet: frags: remove inet_frag_maybe_warn_overflow()
> > inet: frags: break the 2GB limit for frags storage
> > inet: frags: do not clone skb in ip_expire()
> > ipv6: frags: rewrite ip6_expire_frag_queue()
> > rhashtable: reorganize struct rhashtable layout
> > inet: frags: reorganize struct netns_frags
> > inet: frags: get rid of ipfrag_skb_cb/FRAG_CB
> > inet: frags: fix ip6frag_low_thresh boundary
> > net: speed up skb_rbtree_purge()
> > net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends
> > net: add rb_to_skb() and other rb tree helpers
> >
> > Florian Westphal (1):
> > ipv6: defrag: drop non-last frags smaller than min mtu
> >
> > Peter Oskolkov (5):
> > ip: discard IPv4 datagrams with overlapping segments.
> > net: modify skb_rbtree_purge to return the truesize of all purged
> > skbs.
> > ip: use rb trees for IP frag queue.
> > ip: add helpers to process in-order fragments faster.
> > ip: process in-order fragments efficiently
> >
> > Taehee Yoo (1):
> > ip: frags: fix crash in ip_do_fragment()
> >
> > Documentation/networking/ip-sysctl.txt | 13 +-
> > include/linux/rhashtable.h | 4 +-
> > include/linux/skbuff.h | 34 +-
> > include/net/inet_frag.h | 133 +++---
> > include/net/ip.h | 1 -
> > include/net/ipv6.h | 26 +-
> > include/uapi/linux/snmp.h | 1 +
> > lib/rhashtable.c | 5 +-
> > net/core/skbuff.c | 31 +-
> > net/ieee802154/6lowpan/6lowpan_i.h | 26 +-
> > net/ieee802154/6lowpan/reassembly.c | 148 +++---
> > net/ipv4/inet_fragment.c | 379 ++++------------
> > net/ipv4/ip_fragment.c | 573 +++++++++++++-----------
> > net/ipv4/proc.c | 7 +-
> > net/ipv4/tcp_input.c | 33 +-
> > net/ipv6/netfilter/nf_conntrack_reasm.c | 100 ++---
> > net/ipv6/proc.c | 5 +-
> > net/ipv6/reassembly.c | 212 ++++-----
> > 18 files changed, 774 insertions(+), 957 deletions(-)
> >
>
> --
> Florian
^ permalink raw reply
* Re: [PATCH stable 4.9 v2 00/29] backport of IP fragmentation fixes
From: Florian Fainelli @ 2018-10-15 17:47 UTC (permalink / raw)
To: netdev, edumazet; +Cc: davem, gregkh, stable, sthemmin
In-Reply-To: <20181010193017.25221-1-f.fainelli@gmail.com>
On 10/10/2018 12:29 PM, Florian Fainelli wrote:
> This is based on Stephen's v4.14 patches, with the necessary merge
> conflicts, and the lack of timer_setup() on the 4.9 baseline.
>
> Perf results on a gigabit capable system, before and after are below.
>
> Series can also be found here:
>
> https://github.com/ffainelli/linux/commits/fragment-stack-v4.9-v2
>
> Changes in v2:
>
> - drop "net: sk_buff rbnode reorg"
> - added original "ip: use rb trees for IP frag queue." commit
Eric, does this look reasonable to you?
>
> Before patches:
>
> PerfTop: 180 irqs/sec kernel:78.9% exact: 0.0% [4000Hz cycles:ppp], (all, 4 CPUs)
> -------------------------------------------------------------------------------
>
> 34.81% [kernel] [k] ip_defrag
> 4.57% [kernel] [k] arch_cpu_idle
> 2.09% [kernel] [k] fib_table_lookup
> 1.74% [kernel] [k] finish_task_switch
> 1.57% [kernel] [k] v7_dma_inv_range
> 1.47% [kernel] [k] __netif_receive_skb_core
> 1.06% [kernel] [k] __slab_free
> 1.04% [kernel] [k] __netdev_alloc_skb
> 0.99% [kernel] [k] ip_route_input_noref
> 0.96% [kernel] [k] dev_gro_receive
> 0.96% [kernel] [k] tick_nohz_idle_enter
> 0.93% [kernel] [k] bcm_sysport_poll
> 0.92% [kernel] [k] skb_release_data
> 0.91% [kernel] [k] __memzero
> 0.90% [kernel] [k] __free_page_frag
> 0.87% [kernel] [k] ip_rcv
> 0.77% [kernel] [k] eth_type_trans
> 0.71% [kernel] [k] _raw_spin_unlock_irqrestore
> 0.68% [kernel] [k] tick_nohz_idle_exit
> 0.65% [kernel] [k] bcm_sysport_rx_refill
>
> After patches:
>
> PerfTop: 214 irqs/sec kernel:80.4% exact: 0.0% [4000Hz cycles:ppp], (all, 4 CPUs)
> -------------------------------------------------------------------------------
>
> 6.61% [kernel] [k] arch_cpu_idle
> 3.77% [kernel] [k] ip_defrag
> 3.65% [kernel] [k] v7_dma_inv_range
> 3.18% [kernel] [k] fib_table_lookup
> 3.04% [kernel] [k] __netif_receive_skb_core
> 2.31% [kernel] [k] finish_task_switch
> 2.31% [kernel] [k] _raw_spin_unlock_irqrestore
> 1.65% [kernel] [k] bcm_sysport_poll
> 1.63% [kernel] [k] ip_route_input_noref
> 1.63% [kernel] [k] __memzero
> 1.58% [kernel] [k] __netdev_alloc_skb
> 1.47% [kernel] [k] tick_nohz_idle_enter
> 1.40% [kernel] [k] __slab_free
> 1.32% [kernel] [k] ip_rcv
> 1.32% [kernel] [k] __softirqentry_text_start
> 1.30% [kernel] [k] dev_gro_receive
> 1.23% [kernel] [k] bcm_sysport_rx_refill
> 1.11% [kernel] [k] tick_nohz_idle_exit
> 1.06% [kernel] [k] memcmp
> 1.02% [kernel] [k] dma_cache_maint_page
>
>
> Dan Carpenter (1):
> ipv4: frags: precedence bug in ip_expire()
>
> Eric Dumazet (21):
> inet: frags: change inet_frags_init_net() return value
> inet: frags: add a pointer to struct netns_frags
> inet: frags: refactor ipfrag_init()
> inet: frags: refactor ipv6_frag_init()
> inet: frags: refactor lowpan_net_frag_init()
> ipv6: export ip6 fragments sysctl to unprivileged users
> rhashtable: add schedule points
> inet: frags: use rhashtables for reassembly units
> inet: frags: remove some helpers
> inet: frags: get rif of inet_frag_evicting()
> inet: frags: remove inet_frag_maybe_warn_overflow()
> inet: frags: break the 2GB limit for frags storage
> inet: frags: do not clone skb in ip_expire()
> ipv6: frags: rewrite ip6_expire_frag_queue()
> rhashtable: reorganize struct rhashtable layout
> inet: frags: reorganize struct netns_frags
> inet: frags: get rid of ipfrag_skb_cb/FRAG_CB
> inet: frags: fix ip6frag_low_thresh boundary
> net: speed up skb_rbtree_purge()
> net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends
> net: add rb_to_skb() and other rb tree helpers
>
> Florian Westphal (1):
> ipv6: defrag: drop non-last frags smaller than min mtu
>
> Peter Oskolkov (5):
> ip: discard IPv4 datagrams with overlapping segments.
> net: modify skb_rbtree_purge to return the truesize of all purged
> skbs.
> ip: use rb trees for IP frag queue.
> ip: add helpers to process in-order fragments faster.
> ip: process in-order fragments efficiently
>
> Taehee Yoo (1):
> ip: frags: fix crash in ip_do_fragment()
>
> Documentation/networking/ip-sysctl.txt | 13 +-
> include/linux/rhashtable.h | 4 +-
> include/linux/skbuff.h | 34 +-
> include/net/inet_frag.h | 133 +++---
> include/net/ip.h | 1 -
> include/net/ipv6.h | 26 +-
> include/uapi/linux/snmp.h | 1 +
> lib/rhashtable.c | 5 +-
> net/core/skbuff.c | 31 +-
> net/ieee802154/6lowpan/6lowpan_i.h | 26 +-
> net/ieee802154/6lowpan/reassembly.c | 148 +++---
> net/ipv4/inet_fragment.c | 379 ++++------------
> net/ipv4/ip_fragment.c | 573 +++++++++++++-----------
> net/ipv4/proc.c | 7 +-
> net/ipv4/tcp_input.c | 33 +-
> net/ipv6/netfilter/nf_conntrack_reasm.c | 100 ++---
> net/ipv6/proc.c | 5 +-
> net/ipv6/reassembly.c | 212 ++++-----
> 18 files changed, 774 insertions(+), 957 deletions(-)
>
--
Florian
^ permalink raw reply
* Re: [Potential Spoof] Re: [PATCH net-next v4] net/ncsi: Add NCSI Broadcom OEM command
From: Vijay Khemka @ 2018-10-15 17:38 UTC (permalink / raw)
To: Samuel Mendoza-Jonas, David S. Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: openbmc@lists.ozlabs.org, linux-aspeed@lists.ozlabs.org
On 10/15/18, 10:27 AM, "Linux-aspeed on behalf of Vijay Khemka" <linux-aspeed-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of vijaykhemka@fb.com> wrote:
On 10/14/18, 8:51 PM, "Samuel Mendoza-Jonas" <sam@mendozajonas.com> wrote:
On Mon, 2018-10-15 at 13:08 +1100, Samuel Mendoza-Jonas wrote:
> On Fri, 2018-10-12 at 11:20 -0700, Vijay Khemka wrote:
> > This patch adds OEM Broadcom commands and response handling. It also
> > defines OEM Get MAC Address handler to get and configure the device.
> >
> > ncsi_oem_gma_handler_bcm: This handler send NCSI broadcom command for
> > getting mac address.
> > ncsi_rsp_handler_oem_bcm: This handles response received for all
> > broadcom OEM commands.
> > ncsi_rsp_handler_oem_bcm_gma: This handles get mac address response and
> > set it to device.
> >
> > Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
> > ---
> > v4: updated as per comment from Sam, I was just wondering if I can remove
> > NCSI_OEM_CMD_GET_MAC config option and let this code be valid always and
> > it will configure mac address if there is get mac address handler for given
> > manufacture id.
>
> Hi Vijay,
>
> We can look at handling this a different way, but I don't think we want
> to unconditionally set the system's MAC address based on the OEM GMA
> command. If the user wants to set a custom MAC address, or in the case of
> OpenBMC for example who have their MAC address saved in flash, this will
> override that value with whatever the Network Controller has saved. In
> particular as it is set up it will override any MAC address every time a
> channel is configured, such as during a failover event.
>
> We *could* always send the GMA command if it is available and move the
> decision whether to use the resulting address or not into the response
> handler. That would simplify the ncsi_configure_channel() logic a bit.
> Another idea may be to have a Netlink command to tell NCSI to ignore the
> GMA result; then we could drop the config option and the system can
> safely change the address if desired.
>
> Any thoughts? I'll also ping some of the OpenBMC people and see what
> their expectations are.
After a bit of a think and an ask around, to quote a colleague:
> I think we'd want it handled (overall) like any other net device; the MAC
> address in the device's ROM provides a default, and is overridden by anything
> specified by userspace
Which describes what I was thinking pretty well.
So if we can have it such that the NCSI driver only sets the MAC address
_once_, and then after then does not update it again, we should be able to call
the OEM GMA command without hiding it behind a config option. So the first time
a channel was configured we store and set the MAC address given, but then on
later configure events we don't continue to update it. What do you think?
Cheers,
Sam
I agree with you setting it only once. I gave a thought about config option and realize that
we should allow user to configure it. If user wants to set mac address through device tree
and not through ROM then we must not override mac set by device tree. So my proposal is
setting of mac address in response should be hidden under config option. Getting mac address
can still go without config option. Your thought?
or simply guard following block under config and no other function declaration guard required.
And set static variable flag in function " ncsi_oem_handler" for calling this only once.
#if IS_ENABLED(CONFIG_NCSI_OEM_CMD_GET_MAC)
nca.type = NCSI_PKT_CMD_OEM;
nca.package = np->id;
nca.channel = nc->id;
ndp->pending_req_num = 1;
ret = ncsi_oem_handler(&nca, nc->version.mf_id);
#endif /* CONFIG_NCSI_OEM_CMD_GET_MAC */
^ permalink raw reply
* Re: [PATCH net-next v4] net/ncsi: Add NCSI Broadcom OEM command
From: Vijay Khemka @ 2018-10-15 17:27 UTC (permalink / raw)
To: Samuel Mendoza-Jonas, David S. Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: linux-aspeed@lists.ozlabs.org, openbmc@lists.ozlabs.org
In-Reply-To: <9c82f52a7ce3fb9052600709a10783b23ef88457.camel@mendozajonas.com>
On 10/14/18, 8:51 PM, "Samuel Mendoza-Jonas" <sam@mendozajonas.com> wrote:
On Mon, 2018-10-15 at 13:08 +1100, Samuel Mendoza-Jonas wrote:
> On Fri, 2018-10-12 at 11:20 -0700, Vijay Khemka wrote:
> > This patch adds OEM Broadcom commands and response handling. It also
> > defines OEM Get MAC Address handler to get and configure the device.
> >
> > ncsi_oem_gma_handler_bcm: This handler send NCSI broadcom command for
> > getting mac address.
> > ncsi_rsp_handler_oem_bcm: This handles response received for all
> > broadcom OEM commands.
> > ncsi_rsp_handler_oem_bcm_gma: This handles get mac address response and
> > set it to device.
> >
> > Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
> > ---
> > v4: updated as per comment from Sam, I was just wondering if I can remove
> > NCSI_OEM_CMD_GET_MAC config option and let this code be valid always and
> > it will configure mac address if there is get mac address handler for given
> > manufacture id.
>
> Hi Vijay,
>
> We can look at handling this a different way, but I don't think we want
> to unconditionally set the system's MAC address based on the OEM GMA
> command. If the user wants to set a custom MAC address, or in the case of
> OpenBMC for example who have their MAC address saved in flash, this will
> override that value with whatever the Network Controller has saved. In
> particular as it is set up it will override any MAC address every time a
> channel is configured, such as during a failover event.
>
> We *could* always send the GMA command if it is available and move the
> decision whether to use the resulting address or not into the response
> handler. That would simplify the ncsi_configure_channel() logic a bit.
> Another idea may be to have a Netlink command to tell NCSI to ignore the
> GMA result; then we could drop the config option and the system can
> safely change the address if desired.
>
> Any thoughts? I'll also ping some of the OpenBMC people and see what
> their expectations are.
After a bit of a think and an ask around, to quote a colleague:
> I think we'd want it handled (overall) like any other net device; the MAC
> address in the device's ROM provides a default, and is overridden by anything
> specified by userspace
Which describes what I was thinking pretty well.
So if we can have it such that the NCSI driver only sets the MAC address
_once_, and then after then does not update it again, we should be able to call
the OEM GMA command without hiding it behind a config option. So the first time
a channel was configured we store and set the MAC address given, but then on
later configure events we don't continue to update it. What do you think?
Cheers,
Sam
I agree with you setting it only once. I gave a thought about config option and realize that
we should allow user to configure it. If user wants to set mac address through device tree
and not through ROM then we must not override mac set by device tree. So my proposal is
setting of mac address in response should be hidden under config option. Getting mac address
can still go without config option. Your thought?
>
> > +#if IS_ENABLED(CONFIG_NCSI_OEM_CMD_GET_MAC)
> > +
> > +/* NCSI OEM Command APIs */
> > +static void ncsi_oem_gma_handler_bcm(struct ncsi_cmd_arg *nca)
> > +{
> > + unsigned char data[NCSI_OEM_BCM_CMD_GMA_LEN];
> > + int ret = 0;
> > +
> > + nca->payload = NCSI_OEM_BCM_CMD_GMA_LEN;
> > +
> > + memset(data, 0, NCSI_OEM_BCM_CMD_GMA_LEN);
> > + *(unsigned int *)data = ntohl(NCSI_OEM_MFR_BCM_ID);
> > + data[5] = NCSI_OEM_BCM_CMD_GMA;
> > +
> > + nca->data = data;
> > +
> > + ret = ncsi_xmit_cmd(nca);
> > + if (ret)
> > + netdev_err(nca->ndp->ndev.dev,
> > + "NCSI: Failed to transmit cmd 0x%x during configure\n",
> > + nca->type);
> > +}
>
> As a side note while unlikely we probably want to propagate the return
> value of ncsi_xmit_cmd() from here; otherwise we'll miss a failure and
> the configure process will stall.
>
> Regards,
> Sam
>
I will take care of this.
^ permalink raw reply
* Re: [PATCH net 0/2] geneve, vxlan: Don't set exceptions if skb->len < mtu
From: Xin Long @ 2018-10-15 9:40 UTC (permalink / raw)
To: Stefano Brivio; +Cc: davem, Sabrina Dubroca, network dev
In-Reply-To: <cover.1539381018.git.sbrivio@redhat.com>
On Sat, Oct 13, 2018 at 6:54 AM Stefano Brivio <sbrivio@redhat.com> wrote:
>
> This series fixes the exception abuse described in 2/2, and 1/2
> is just a preparatory change to make 2/2 less ugly.
>
> Stefano Brivio (2):
> geneve, vxlan: Don't check skb_dst() twice
> geneve, vxlan: Don't set exceptions if skb->len < mtu
>
> drivers/net/geneve.c | 14 +++-----------
> drivers/net/vxlan.c | 12 ++----------
> include/net/dst.h | 10 ++++++++++
> 3 files changed, 15 insertions(+), 21 deletions(-)
>
> --
> 2.19.1
>
Series Reviewed-by: Xin Long <lucien.xin@gmail.com>
^ permalink raw reply
* Re: [PATCH net] ip6_tunnel: Don't update PMTU on tunnels with collect_md
From: Stefano Brivio @ 2018-10-15 9:09 UTC (permalink / raw)
To: Nicolas Dichtel, David S. Miller; +Cc: Alexei Starovoitov, netdev
In-Reply-To: <eb26ebd1-19e3-e72a-2d90-3793889a635e@6wind.com>
On Mon, 15 Oct 2018 10:48:05 +0200
Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> Le 12/10/2018 à 18:34, Stefano Brivio a écrit :
> > On Fri, 12 Oct 2018 17:58:55 +0200
> > Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> [snip]
> >> Could you explain in your commit log which problem your patch fixes?
> >
> > Nothing really.
> >
> > The change in f15ca723c1eb looked accidental and I thought it doesn't
> > make sense to update the PMTU in that case, but I didn't figure out
> > it's not actually done anyway.
> >
> > Maybe it makes things a bit more readable, in that case I'd target it
> > for net-next. What do you think?
> >
> I don't think that this patch helps. The purpose of the skb_dst_update_pmtu()
> helper is to hide those things. If one day, update_pmtu is defined for
> md_dst_op, I bet that we won't remove this test.
I see, makes sense.
David, please drop this patch, and sorry for the noise.
--
Stefano
^ permalink raw reply
* Re: [PATCH net] ip6_tunnel: Don't update PMTU on tunnels with collect_md
From: Nicolas Dichtel @ 2018-10-15 8:48 UTC (permalink / raw)
To: Stefano Brivio; +Cc: David S. Miller, Alexei Starovoitov, netdev
In-Reply-To: <20181012183438.59f4308e@epycfail>
Le 12/10/2018 à 18:34, Stefano Brivio a écrit :
> On Fri, 12 Oct 2018 17:58:55 +0200
> Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
[snip]
>> Could you explain in your commit log which problem your patch fixes?
>
> Nothing really.
>
> The change in f15ca723c1eb looked accidental and I thought it doesn't
> make sense to update the PMTU in that case, but I didn't figure out
> it's not actually done anyway.
>
> Maybe it makes things a bit more readable, in that case I'd target it
> for net-next. What do you think?
>
I don't think that this patch helps. The purpose of the skb_dst_update_pmtu()
helper is to hide those things. If one day, update_pmtu is defined for
md_dst_op, I bet that we won't remove this test.
Regards,
Nicolas
^ permalink raw reply
* Re: [PATCH] net: bridge: fix a memory leak in __vlan_add
From: Li RongQing @ 2018-10-15 8:31 UTC (permalink / raw)
To: nikolay; +Cc: Li RongQing, netdev, bridge, roopa
In-Reply-To: <2badfb2b-0a50-4d18-cdb4-d894b4ef7bec@cumulusnetworks.com>
> >
>
> 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).
>
Ok, thanks, I will send v2
-RongQing
> Thank you,
> Nik
^ permalink raw reply
* Re: [PATCH net 2/2] geneve, vxlan: Don't set exceptions if skb->len < mtu
From: Stefano Brivio @ 2018-10-15 8:27 UTC (permalink / raw)
To: Xin Long; +Cc: davem, Sabrina Dubroca, network dev
In-Reply-To: <CADvbK_fVyZA-MzmESYOQmp_pes+X61iftnYtNNU4Y_uqSg2LhQ@mail.gmail.com>
On Mon, 15 Oct 2018 15:01:31 +0900
Xin Long <lucien.xin@gmail.com> wrote:
> On Sat, Oct 13, 2018 at 6:54 AM Stefano Brivio <sbrivio@redhat.com> wrote:
> >
> > We shouldn't abuse exceptions: if the destination MTU is already higher
> > than what we're transmitting, no exception should be created.
> makes sense, shouldn't ip(6) tunnels also do this?
I should probably have mentioned this in the cover letter: in theory
yes, but I'm doing this as preparation for ICMP handling in UDP
tunnels, and those will get selftests soon (once I'm done).
Writing extensive selftests for IP tunnels will take significantly
longer, so I'm not too confident to change this right now. I'd prefer
to address that at a later time.
--
Stefano
^ permalink raw reply
* Re: [RFC] VSOCK: The performance problem of vhost_vsock.
From: jiangyiwen @ 2018-10-15 6:12 UTC (permalink / raw)
To: Jason Wang, stefanha; +Cc: kvm, virtualization, netdev
In-Reply-To: <30d7c370-b206-cdac-dc85-53e9be1e1c63@redhat.com>
On 2018/10/15 10:33, Jason Wang wrote:
>
>
> On 2018年10月15日 09:43, jiangyiwen wrote:
>> Hi Stefan & All:
>>
>> Now I find vhost-vsock has two performance problems even if it
>> is not designed for performance.
>>
>> First, I think vhost-vsock should faster than vhost-net because it
>> is no TCP/IP stack, but the real test result vhost-net is 5~10
>> times than vhost-vsock, currently I am looking for the reason.
>
> TCP/IP is not a must for vhost-net.
>
> How do you test and compare the performance?
>
> Thanks
>
I test the performance used my test tool, like follows:
Server Client
socket()
bind()
listen()
socket(AF_VSOCK) or socket(AF_INET)
Accept() <-------------->connect()
*======Start Record Time======*
Call syscall sendfile()
Recv()
Send end
Receive end
Send(file_size)
Recv(file_size)
*======End Record Time======*
The test result, vhost-vsock is about 500MB/s, and vhost-net is about 2500MB/s.
By the way, vhost-net use single queue.
Thanks.
>> Second, vhost-vsock only supports two vqs(tx and rx), that means
>> if multiple sockets in the guest will use the same vq to transmit
>> the message and get the response. So if there are multiple applications
>> in the guest, we should support "Multiqueue" feature for Virtio-vsock.
>>
>> Stefan, have you encountered these problems?
>>
>> Thanks,
>> Yiwen.
>>
>
>
> .
>
^ permalink raw reply
* Re: [PATCH net 2/2] geneve, vxlan: Don't set exceptions if skb->len < mtu
From: Xin Long @ 2018-10-15 6:01 UTC (permalink / raw)
To: Stefano Brivio; +Cc: davem, Sabrina Dubroca, network dev
In-Reply-To: <97f93a69894ed49e6b914a8211ec813cc1bbc433.1539381018.git.sbrivio@redhat.com>
On Sat, Oct 13, 2018 at 6:54 AM Stefano Brivio <sbrivio@redhat.com> wrote:
>
> We shouldn't abuse exceptions: if the destination MTU is already higher
> than what we're transmitting, no exception should be created.
makes sense, shouldn't ip(6) tunnels also do this?
>
> Fixes: 52a589d51f10 ("geneve: update skb dst pmtu on tx path")
> Fixes: a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path")
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
> ---
> drivers/net/geneve.c | 7 +++----
> drivers/net/vxlan.c | 4 ++--
> include/net/dst.h | 10 ++++++++++
> 3 files changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
> index 61c4bfbeb41c..493cd382b8aa 100644
> --- a/drivers/net/geneve.c
> +++ b/drivers/net/geneve.c
> @@ -830,8 +830,8 @@ static int geneve_xmit_skb(struct sk_buff *skb, struct net_device *dev,
> if (IS_ERR(rt))
> return PTR_ERR(rt);
>
> - skb_dst_update_pmtu(skb, dst_mtu(&rt->dst) -
> - GENEVE_IPV4_HLEN - info->options_len);
> + skb_tunnel_check_pmtu(skb, &rt->dst,
> + GENEVE_IPV4_HLEN + info->options_len);
>
> sport = udp_flow_src_port(geneve->net, skb, 1, USHRT_MAX, true);
> if (geneve->collect_md) {
> @@ -872,8 +872,7 @@ static int geneve6_xmit_skb(struct sk_buff *skb, struct net_device *dev,
> if (IS_ERR(dst))
> return PTR_ERR(dst);
>
> - skb_dst_update_pmtu(skb, dst_mtu(dst) -
> - GENEVE_IPV6_HLEN - info->options_len);
> + skb_tunnel_check_pmtu(skb, dst, GENEVE_IPV6_HLEN + info->options_len);
>
> sport = udp_flow_src_port(geneve->net, skb, 1, USHRT_MAX, true);
> if (geneve->collect_md) {
> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> index 22e0ce592e07..27bd586b94b0 100644
> --- a/drivers/net/vxlan.c
> +++ b/drivers/net/vxlan.c
> @@ -2194,7 +2194,7 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct net_device *dev,
> }
>
> ndst = &rt->dst;
> - skb_dst_update_pmtu(skb, dst_mtu(ndst) - VXLAN_HEADROOM);
> + skb_tunnel_check_pmtu(skb, ndst, VXLAN_HEADROOM);
>
> tos = ip_tunnel_ecn_encap(tos, old_iph, skb);
> ttl = ttl ? : ip4_dst_hoplimit(&rt->dst);
> @@ -2231,7 +2231,7 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct net_device *dev,
> goto out_unlock;
> }
>
> - skb_dst_update_pmtu(skb, dst_mtu(ndst) - VXLAN6_HEADROOM);
> + skb_tunnel_check_pmtu(skb, ndst, VXLAN6_HEADROOM);
>
> tos = ip_tunnel_ecn_encap(tos, old_iph, skb);
> ttl = ttl ? : ip6_dst_hoplimit(ndst);
> diff --git a/include/net/dst.h b/include/net/dst.h
> index 7f735e76ca73..6cf0870414c7 100644
> --- a/include/net/dst.h
> +++ b/include/net/dst.h
> @@ -527,4 +527,14 @@ static inline void skb_dst_update_pmtu(struct sk_buff *skb, u32 mtu)
> dst->ops->update_pmtu(dst, NULL, skb, mtu);
> }
>
> +static inline void skb_tunnel_check_pmtu(struct sk_buff *skb,
> + struct dst_entry *encap_dst,
> + int headroom)
> +{
> + u32 encap_mtu = dst_mtu(encap_dst);
> +
> + if (skb->len > encap_mtu - headroom)
> + skb_dst_update_pmtu(skb, encap_mtu - headroom);
> +}
> +
> #endif /* _NET_DST_H */
> --
> 2.19.1
>
^ permalink raw reply
* Re: [rtnetlink] Potential bug in Linux (rt)netlink code
From: Henning Rogge @ 2018-10-15 5:25 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20181012115159.7ead2f97@xeon-e3>
Am 12.10.2018 um 20:51 schrieb Stephen Hemminger:
> On Fri, 12 Oct 2018 09:30:40 +0200
> Henning Rogge <henning.rogge@fkie.fraunhofer.de> wrote:
>
>> Hi,
>>
>> I am working on a self-written routing agent
>> (https://github.com/OLSR/OONF) and am stuck on a problem with netlink
>> that I cannot explain with an userspace error.
>>
>> I am using a netlink socket for setting routes
>> (RTM_NEWROUTE/RTM_DELROUTE), querying the kernel for the current routes
>> in the database (via a RTM_GETROUTE dump) and for getting multicast
>> messages for ongoing routing changes.
>>
>> After a few netlink messages I get to the point where the kernel just
>> does not responst to a RTM_NEWROUTE. No error, no answer, despite the
>> NLM_F_ACK flag set)... but sometime when (during shutdown of the routing
>> agent) the program sends another route command (most times a
>> RTM_DELROUTE) I get a single netlink packet with a "successful" response
>> for both the "missing" RTM_NEWROUTE and one for the new RTM DELROUTE
>> sequence number.
>>
>> I am testing two routing agents, each of them in a systemd-nspawn based
>> container connected over a bridge on the host system on a current Debian
>> Testing (kernel 4.18.0-1-amd64).
>>
>> I am directly using the netlink sockets, without any other userspace
>> library in between.
>>
>> I have checked the hexdumps of a couple of netlink messages (including
>> the ones just before the bug happens) by hand and they seem to be okay.
>>
>> When I tried to add a "netlink listener" socket for futher debugging (ip
>> link add nlmon0 type nlmon) the problem vanished until I removed the
>> listener socket again.
>>
>> Any ideas how to debug this problem? Unfortunately I have no short
>> example program to trigger the bug... I have rarely seen the problem for
>> years (once every couple of months), but until a few days ago I never
>> managed to reproduce it.
>>
>> Henning Rogge
>
> Are you reading the responses to your requests? If you don't read
> the response, the socket will get flow blocked.
Yes, I do...
all netlink sockets the program uses are constantly watched for traffic
coming from the kernel (with an epoll()-based event loop, no edge-trigger).
I even have a rate limitation towards the kernel, only sending a
"pagesize" full of netlink data towards the kernel, then waiting for the
reply before sending more (I had the blocking problem a few years ago
when experimenting with LOTS of routes).
Henning Rogge
--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Zanderstrasse 5, 53177 Bonn, Germany
Telefon +49 228 50212-469
mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
^ permalink raw reply
* [PATCH net,stable 1/1] net: fec: don't dump RX FIFO register when not available
From: Andy Duan @ 2018-10-15 5:19 UTC (permalink / raw)
To: davem@davemloft.net; +Cc: netdev@vger.kernel.org, tremyfr@gmail.com, Andy Duan
From: Fugang Duan <fugang.duan@nxp.com>
Commit db65f35f50e0 ("net: fec: add support of ethtool get_regs") introduce
ethool "--register-dump" interface to dump all FEC registers.
But not all silicon implementations of the Freescale FEC hardware module
have the FRBR (FIFO Receive Bound Register) and FRSR (FIFO Receive Start
Register) register, so we should not be trying to dump them on those that
don't.
To fix it we create a quirk flag, FEC_QUIRK_HAS_RFREG, and check it before
dump those RX FIFO registers.
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
---
drivers/net/ethernet/freescale/fec.h | 4 ++++
drivers/net/ethernet/freescale/fec_main.c | 16 ++++++++++++----
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index 4778b66..bf80855 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -452,6 +452,10 @@ struct bufdesc_ex {
* initialisation.
*/
#define FEC_QUIRK_MIB_CLEAR (1 << 15)
+/* Only i.MX25/i.MX27/i.MX28 controller supports FRBR,FRSR registers,
+ * those FIFO receive registers are resolved in other platforms.
+ */
+#define FEC_QUIRK_HAS_FRREG (1 << 16)
struct bufdesc_prop {
int qid;
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index a17cc97..6db69ba 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -91,14 +91,16 @@
.driver_data = 0,
}, {
.name = "imx25-fec",
- .driver_data = FEC_QUIRK_USE_GASKET | FEC_QUIRK_MIB_CLEAR,
+ .driver_data = FEC_QUIRK_USE_GASKET | FEC_QUIRK_MIB_CLEAR |
+ FEC_QUIRK_HAS_FRREG,
}, {
.name = "imx27-fec",
- .driver_data = FEC_QUIRK_MIB_CLEAR,
+ .driver_data = FEC_QUIRK_MIB_CLEAR | FEC_QUIRK_HAS_FRREG,
}, {
.name = "imx28-fec",
.driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_SWAP_FRAME |
- FEC_QUIRK_SINGLE_MDIO | FEC_QUIRK_HAS_RACC,
+ FEC_QUIRK_SINGLE_MDIO | FEC_QUIRK_HAS_RACC |
+ FEC_QUIRK_HAS_FRREG,
}, {
.name = "imx6q-fec",
.driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT |
@@ -2162,7 +2164,13 @@ static void fec_enet_get_regs(struct net_device *ndev,
memset(buf, 0, regs->len);
for (i = 0; i < ARRAY_SIZE(fec_enet_register_offset); i++) {
- off = fec_enet_register_offset[i] / 4;
+ off = fec_enet_register_offset[i];
+
+ if ((off == FEC_R_BOUND || off == FEC_R_FSTART) &&
+ !(fep->quirks & FEC_QUIRK_HAS_FRREG))
+ continue;
+
+ off >>= 2;
buf[off] = readl(&theregs[off]);
}
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 2/8] usbnet: smsc95xx: add kconfig for turbo mode
From: Bjørn Mork @ 2018-10-15 12:48 UTC (permalink / raw)
To: Ben Dooks; +Cc: netdev, oneukum, davem, linux-usb, linux-kernel, linux-kernel
In-Reply-To: <20181012083405.19246-3-ben.dooks@codethink.co.uk>
Ben Dooks <ben.dooks@codethink.co.uk> writes:
> Add a configuration option for the default state of turbo mode
> on the smsc95xx networking driver. Some systems it is better
> to default this to off as it causes significant increases in
> soft-irq load.
So there is already a module option allowing you to change this, using
e.g kernel command line or kmod config files. It's even writable,
taking effect on the next netdev open, so you can change it at runtime
without reloading the module.
What good does this new build-time setting do, except causing confusion
wrt driver defaults?
Note also that the smsc95xx and smsc75xx drivers are pretty similar.
Both have the same turbo_mode setting. If you change the defaults, then
they should at least be kept in sync to cause as little confusion as
possible..
Bjørn
^ permalink raw reply
* Re: net/wan: hostess_sv11 + z85230 problems
From: Krzysztof Hałasa @ 2018-10-15 12:41 UTC (permalink / raw)
To: Alan Cox; +Cc: Randy Dunlap, netdev@vger.kernel.org, LKML
In-Reply-To: <20181015112910.4504cd3a@alans-desktop>
Alan Cox <gnomes@lxorguk.ukuu.org.uk> writes:
>> BTW Hostess SV11 is apparently an ISA card, with all those problems.
>
> Actually it worked perfectly well of old but people kept changing it
> who didn't have hardware.
Right, that's the same with all of this hardware.
In fact I meant all the ISA problems (in comparison to e.g. PCI),
not of any particular design.
--
Krzysztof Halasa
Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
^ permalink raw reply
* Re: [PATCH net-next v4] net/ncsi: Add NCSI Broadcom OEM command
From: Samuel Mendoza-Jonas @ 2018-10-15 3:51 UTC (permalink / raw)
To: Vijay Khemka, David S. Miller, netdev, linux-kernel; +Cc: linux-aspeed, openbmc
In-Reply-To: <69cae9d44cbebb2cd4f468dc710d6a97210af835.camel@mendozajonas.com>
On Mon, 2018-10-15 at 13:08 +1100, Samuel Mendoza-Jonas wrote:
> On Fri, 2018-10-12 at 11:20 -0700, Vijay Khemka wrote:
> > This patch adds OEM Broadcom commands and response handling. It also
> > defines OEM Get MAC Address handler to get and configure the device.
> >
> > ncsi_oem_gma_handler_bcm: This handler send NCSI broadcom command for
> > getting mac address.
> > ncsi_rsp_handler_oem_bcm: This handles response received for all
> > broadcom OEM commands.
> > ncsi_rsp_handler_oem_bcm_gma: This handles get mac address response and
> > set it to device.
> >
> > Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
> > ---
> > v4: updated as per comment from Sam, I was just wondering if I can remove
> > NCSI_OEM_CMD_GET_MAC config option and let this code be valid always and
> > it will configure mac address if there is get mac address handler for given
> > manufacture id.
>
> Hi Vijay,
>
> We can look at handling this a different way, but I don't think we want
> to unconditionally set the system's MAC address based on the OEM GMA
> command. If the user wants to set a custom MAC address, or in the case of
> OpenBMC for example who have their MAC address saved in flash, this will
> override that value with whatever the Network Controller has saved. In
> particular as it is set up it will override any MAC address every time a
> channel is configured, such as during a failover event.
>
> We *could* always send the GMA command if it is available and move the
> decision whether to use the resulting address or not into the response
> handler. That would simplify the ncsi_configure_channel() logic a bit.
> Another idea may be to have a Netlink command to tell NCSI to ignore the
> GMA result; then we could drop the config option and the system can
> safely change the address if desired.
>
> Any thoughts? I'll also ping some of the OpenBMC people and see what
> their expectations are.
After a bit of a think and an ask around, to quote a colleague:
> I think we'd want it handled (overall) like any other net device; the MAC
> address in the device's ROM provides a default, and is overridden by anything
> specified by userspace
Which describes what I was thinking pretty well.
So if we can have it such that the NCSI driver only sets the MAC address
_once_, and then after then does not update it again, we should be able to call
the OEM GMA command without hiding it behind a config option. So the first time
a channel was configured we store and set the MAC address given, but then on
later configure events we don't continue to update it. What do you think?
Cheers,
Sam
>
> > +#if IS_ENABLED(CONFIG_NCSI_OEM_CMD_GET_MAC)
> > +
> > +/* NCSI OEM Command APIs */
> > +static void ncsi_oem_gma_handler_bcm(struct ncsi_cmd_arg *nca)
> > +{
> > + unsigned char data[NCSI_OEM_BCM_CMD_GMA_LEN];
> > + int ret = 0;
> > +
> > + nca->payload = NCSI_OEM_BCM_CMD_GMA_LEN;
> > +
> > + memset(data, 0, NCSI_OEM_BCM_CMD_GMA_LEN);
> > + *(unsigned int *)data = ntohl(NCSI_OEM_MFR_BCM_ID);
> > + data[5] = NCSI_OEM_BCM_CMD_GMA;
> > +
> > + nca->data = data;
> > +
> > + ret = ncsi_xmit_cmd(nca);
> > + if (ret)
> > + netdev_err(nca->ndp->ndev.dev,
> > + "NCSI: Failed to transmit cmd 0x%x during configure\n",
> > + nca->type);
> > +}
>
> As a side note while unlikely we probably want to propagate the return
> value of ncsi_xmit_cmd() from here; otherwise we'll miss a failure and
> the configure process will stall.
>
> Regards,
> Sam
>
^ permalink raw reply
* [PATCH -next] fore200e: fix missing unlock on error in bsq_audit()
From: Wei Yongjun @ 2018-10-15 3:07 UTC (permalink / raw)
To: Chas Williams, Christoph Hellwig
Cc: Wei Yongjun, linux-atm-general, netdev, kernel-janitors
Add the missing unlock before return from function bsq_audit()
in the error handling case.
Fixes: 1d9d8be91788 ("fore200e: check for dma mapping failures")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/atm/fore200e.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c
index 2b5dc8f..ffc07ab 100644
--- a/drivers/atm/fore200e.c
+++ b/drivers/atm/fore200e.c
@@ -1606,6 +1606,7 @@ int bsq_audit(int where, struct host_bsq* bsq, int scheme, int magn)
if (dma_mapping_error(fore200e->dev, tpd->tsd[0].buffer)) {
if (tx_copy)
kfree(data);
+ spin_unlock_irqrestore(&fore200e->q_lock, flags);
return -ENOMEM;
}
tpd->tsd[ 0 ].length = tx_len;
^ permalink raw reply related
* [PATCH net-next] rxrpc: Add /proc/net/rxrpc/peers to display peer list
From: David Howells @ 2018-10-15 10:31 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
Add /proc/net/rxrpc/peers to display the list of peers currently active.
Signed-off-by: David Howells <dhowells@redhat.com>
---
net/rxrpc/ar-internal.h | 1
net/rxrpc/net_ns.c | 3 +
net/rxrpc/proc.c | 126 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 130 insertions(+)
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index 8cee7644965c..0a7c49e8e053 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -1062,6 +1062,7 @@ void rxrpc_put_peer(struct rxrpc_peer *);
*/
extern const struct seq_operations rxrpc_call_seq_ops;
extern const struct seq_operations rxrpc_connection_seq_ops;
+extern const struct seq_operations rxrpc_peer_seq_ops;
/*
* recvmsg.c
diff --git a/net/rxrpc/net_ns.c b/net/rxrpc/net_ns.c
index 417d80867c4f..fd7eba8467fa 100644
--- a/net/rxrpc/net_ns.c
+++ b/net/rxrpc/net_ns.c
@@ -102,6 +102,9 @@ static __net_init int rxrpc_init_net(struct net *net)
proc_create_net("conns", 0444, rxnet->proc_net,
&rxrpc_connection_seq_ops,
sizeof(struct seq_net_private));
+ proc_create_net("peers", 0444, rxnet->proc_net,
+ &rxrpc_peer_seq_ops,
+ sizeof(struct seq_net_private));
return 0;
err_proc:
diff --git a/net/rxrpc/proc.c b/net/rxrpc/proc.c
index 9805e3b85c36..c7d976859d40 100644
--- a/net/rxrpc/proc.c
+++ b/net/rxrpc/proc.c
@@ -212,3 +212,129 @@ const struct seq_operations rxrpc_connection_seq_ops = {
.stop = rxrpc_connection_seq_stop,
.show = rxrpc_connection_seq_show,
};
+
+/*
+ * generate a list of extant virtual peers in /proc/net/rxrpc/peers
+ */
+static int rxrpc_peer_seq_show(struct seq_file *seq, void *v)
+{
+ struct rxrpc_peer *peer;
+ time64_t now;
+ char lbuff[50], rbuff[50];
+
+ if (v == SEQ_START_TOKEN) {
+ seq_puts(seq,
+ "Proto Local "
+ " Remote "
+ " Use CW MTU LastUse RTT Rc\n"
+ );
+ return 0;
+ }
+
+ peer = list_entry(v, struct rxrpc_peer, hash_link);
+
+ sprintf(lbuff, "%pISpc", &peer->local->srx.transport);
+
+ sprintf(rbuff, "%pISpc", &peer->srx.transport);
+
+ now = ktime_get_seconds();
+ seq_printf(seq,
+ "UDP %-47.47s %-47.47s %3u"
+ " %3u %5u %6llus %12llu %2u\n",
+ lbuff,
+ rbuff,
+ atomic_read(&peer->usage),
+ peer->cong_cwnd,
+ peer->mtu,
+ now - peer->last_tx_at,
+ peer->rtt,
+ peer->rtt_cursor);
+
+ return 0;
+}
+
+static void *rxrpc_peer_seq_start(struct seq_file *seq, loff_t *_pos)
+ __acquires(rcu)
+{
+ struct rxrpc_net *rxnet = rxrpc_net(seq_file_net(seq));
+ unsigned int bucket, n;
+ unsigned int shift = 32 - HASH_BITS(rxnet->peer_hash);
+ void *p;
+
+ rcu_read_lock();
+
+ if (*_pos >= UINT_MAX)
+ return NULL;
+
+ n = *_pos & ((1U << shift) - 1);
+ bucket = *_pos >> shift;
+ for (;;) {
+ if (bucket >= HASH_SIZE(rxnet->peer_hash)) {
+ *_pos = UINT_MAX;
+ return NULL;
+ }
+ if (n == 0) {
+ if (bucket == 0)
+ return SEQ_START_TOKEN;
+ *_pos += 1;
+ n++;
+ }
+
+ p = seq_hlist_start_rcu(&rxnet->peer_hash[bucket], n - 1);
+ if (p)
+ return p;
+ bucket++;
+ n = 1;
+ *_pos = (bucket << shift) | n;
+ }
+}
+
+static void *rxrpc_peer_seq_next(struct seq_file *seq, void *v, loff_t *_pos)
+{
+ struct rxrpc_net *rxnet = rxrpc_net(seq_file_net(seq));
+ unsigned int bucket, n;
+ unsigned int shift = 32 - HASH_BITS(rxnet->peer_hash);
+ void *p;
+
+ if (*_pos >= UINT_MAX)
+ return NULL;
+
+ bucket = *_pos >> shift;
+
+ p = seq_hlist_next_rcu(v, &rxnet->peer_hash[bucket], _pos);
+ if (p)
+ return p;
+
+ for (;;) {
+ bucket++;
+ n = 1;
+ *_pos = (bucket << shift) | n;
+
+ if (bucket >= HASH_SIZE(rxnet->peer_hash)) {
+ *_pos = UINT_MAX;
+ return NULL;
+ }
+ if (n == 0) {
+ *_pos += 1;
+ n++;
+ }
+
+ p = seq_hlist_start_rcu(&rxnet->peer_hash[bucket], n - 1);
+ if (p)
+ return p;
+ }
+}
+
+static void rxrpc_peer_seq_stop(struct seq_file *seq, void *v)
+ __releases(rcu)
+{
+ rcu_read_unlock();
+}
+
+
+const struct seq_operations rxrpc_peer_seq_ops = {
+ .start = rxrpc_peer_seq_start,
+ .next = rxrpc_peer_seq_next,
+ .stop = rxrpc_peer_seq_stop,
+ .show = rxrpc_peer_seq_show,
+};
^ 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