* Re: [PATCH] rt2x00: improve calling conventions for register accessors
From: Arnd Bergmann @ 2017-05-16 15:11 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: David Miller, Helmut Schaa, Kalle Valo, Daniel Golle,
Mathias Kresin, Johannes Berg, Tomislav Požega,
Serge Vasilugin, Roman Yeryomin, linux-wireless, Networking,
Linux Kernel Mailing List
In-Reply-To: <20170516142342.GA6086-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Tue, May 16, 2017 at 4:23 PM, Stanislaw Gruszka <sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Tue, May 16, 2017 at 01:55:17PM +0200, Stanislaw Gruszka wrote:
>> On Mon, May 15, 2017 at 10:39:51AM -0400, David Miller wrote:
>> > From: Stanislaw Gruszka <sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> > Date: Mon, 15 May 2017 16:28:01 +0200
>> >
>> > > On Mon, May 15, 2017 at 03:46:55PM +0200, Arnd Bergmann wrote:
>> > >> With CONFIG_KASAN enabled and gcc-7, we get a warning about rather high
>> > >> stack usage (with a private patch set I have to turn on this warning,
>> > >> which I intend to get into the next kernel release):
>> > >>
>> > >> wireless/ralink/rt2x00/rt2800lib.c: In function 'rt2800_bw_filter_calibration':
>> > >> wireless/ralink/rt2x00/rt2800lib.c:7990:1: error: the frame size of 2144 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
>> > >>
>> > >> The problem is that KASAN inserts a redzone around each local variable that
>> > >> gets passed by reference, and the newly added function has a lot of them.
>> > >> We can easily avoid that here by changing the calling convention to have
>> > >> the output as the return value of the function. This should also results in
>> > >> smaller object code, saving around 4KB in .text with KASAN, or 2KB without
>> > >> KASAN.
>> > >>
>> > >> Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
>> > >> Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
>> > >> ---
>> > >> drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 319 +++++++++++++------------
>> > >> 1 file changed, 164 insertions(+), 155 deletions(-)
>> > >
>> > > We have read(, &val) calling convention since forever in rt2x00 and that
>> > > was never a problem. I dislike to change that now to make some tools
>> > > happy, I think problem should be fixed in the tools instead.
>> >
>> > Passing return values by reference is and always has been a really
>> > poor way to achieve what these functions are doing.
>> >
>> > And frankly, whilst the tool could see what's going on here better, we
>> > should be making code easier rather than more difficult to audit.
>> >
>> > I am therefore very much in favor of Arnd's change.
>> >
>> > This isn't even a situation where there are multiple return values,
>> > such as needing to signal an error and return an unsigned value at the
>> > same time.
>> >
>> > These functions return _one_ value, and therefore they should be
>> > returned as a true return value.
>>
>> In rt2x00 driver we use poor convention in other kind of registers
>> accessors like bbp, mac, eeprom. I dislike to changing only rfcsr
>> accessors and leaving others in the old way. And changing all accessors
>> would be massive and error prone change, which I'm not prefer either.
>>
>> Arnd, could this be fixed by refactoring rt2800_bw_filter_calibration()
>> function (which is enormous and definitely should be split into smaller
>> subroutines) ? If not, I would accept this patch.
>
> Does below patch make things better with KASAN compilation ?
Yes, that fixes the warning I got:
Before:
$ make -s EXTRA_CFLAGS=-Wframe-larger-than=500
/git/arm-soc/drivers/net/wireless/ralink/rt2x00/rt2800lib.c: In
function 'rt2800_bw_filter_calibration':
/git/arm-soc/drivers/net/wireless/ralink/rt2x00/rt2800lib.c:7990:1:
error: the frame size of 2144 bytes is larger than 500 bytes
[-Werror=frame-larger-than=]
$ size drivers/net/wireless/ralink/rt2x00/built-in.o text data
bss dec hex filename
255979 39442 1536 296957 487fd
drivers/net/wireless/ralink/rt2x00/built-in.o
With your patch:
$ make -s EXTRA_CFLAGS=-Wframe-larger-than=500
/git/arm-soc/drivers/net/wireless/ralink/rt2x00/rt2800lib.c: In
function 'rt2800_bw_filter_calibration':
/git/arm-soc/drivers/net/wireless/ralink/rt2x00/rt2800lib.c:7956:1:
warning: the frame size of 576 bytes is larger than 300 bytes
[-Wframe-larger-than=]
$ size drivers/net/wireless/ralink/rt2x00/built-in.o
text data bss dec hex filename
254367 39538 1536 295441 48211
drivers/net/wireless/ralink/rt2x00/built-in.o
With my 300kb patch:
$ make -s EXTRA_CFLAGS=-Wframe-larger-than=300
$ size drivers/net/wireless/ralink/rt2x00/built-in.o
237312 39442 1536 278290 43f12
drivers/net/wireless/ralink/rt2x00/built-in.o
I passed -Wframe-larger-than=500 here to see the actual stack consumption.
The 2144 bytes are definitely worrying, 576 bytes are generally harmless. My
larger patch improves stack consumption and code size further: it brings all
six functions that had >300 byte stacks below that, but it is not really needed
with your change.
Arnd
^ permalink raw reply
* Re: cxgb4 is broken in v4.12-rc1
From: Ganesh GR @ 2017-05-16 15:19 UTC (permalink / raw)
To: Logan Gunthorpe
Cc: David S. Miller, Stephen Bates, SWise OGC, netdev@vger.kernel.org
In-Reply-To: <745b4343-52e7-b8c7-0889-98ea843de15b@deltatee.com>
Hi Logan,
The latest firmware available is 1.16.43.0 kindly update your firmware and
give a try, 1.16.29.4 have no support for autoneg.
Thanks
Ganesh
From: Logan Gunthorpe <logang@deltatee.com>
Sent: Tuesday, May 16, 2017 7:20 AM
To: Ganesh GR
Cc: David S. Miller; Stephen Bates; SWise OGC; netdev@vger.kernel.org
Subject: Re: cxgb4 is broken in v4.12-rc1
Hi,
Thanks for looking into it. The version information of the card is:
[ 5.235956] cxgb4 0000:07:00.4: Chelsio T62100-LP-CR rev 0
[ 5.235957] cxgb4 0000:07:00.4: S/N: PT51160053, P/N: 11012106004
[ 5.235959] cxgb4 0000:07:00.4: Firmware version: 1.16.29.4
[ 5.235960] cxgb4 0000:07:00.4: Bootstrap version: 255.255.255.255
[ 5.235961] cxgb4 0000:07:00.4: TP Microcode version: 0.1.23.2
Logan
On 15/05/17 07:00 PM, Ganesh GR wrote:
>
> Hi Logan,
>
> Thanks for reporting the issue I will try to reproduce this, btw what is the firmware version
> on your setup?.
>
> Regards
> Ganesh
>
>
>
>
> From: Logan Gunthorpe <logang@deltatee.com>
> Sent: Tuesday, May 16, 2017 4:06 AM
> To: Ganesh GR
> Cc: David S. Miller; Stephen Bates; SWise OGC; netdev@vger.kernel.org
> Subject: BUG: cxgb4 is broken in v4.12-rc1
>
> Hi,
>
> With rc1 my T62100-LP-CR no longer functions correctly. Everything
> appears fine but the link never goes into the UP state. I have one peer
> with an older (functioning) kernel and the other peer on rc1.
>
> I've bisected to find this is the offending commit:
>
> 3bb4858fd: cxgb4: avoid disabling FEC by default
>
> I've also attached a bisect log.
>
> Let me know if you need anything else.
>
> Thanks,
>
> Logan
>
>
^ permalink raw reply
* Re: [PATCH iproute2] ip: add support for more MPLS labels
From: David Ahern @ 2017-05-16 15:21 UTC (permalink / raw)
To: Simon Horman; +Cc: netdev, stephen
In-Reply-To: <20170516083224.GC15081@vergenet.net>
On 5/16/17 1:32 AM, Simon Horman wrote:
>> diff --git a/lib/mpls_pton.c b/lib/mpls_pton.c
>> index bd448cfcf14a..6d2e6a69436a 100644
>> --- a/lib/mpls_pton.c
>> +++ b/lib/mpls_pton.c
>> @@ -7,12 +7,13 @@
>> #include "utils.h"
>>
>>
>> -static int mpls_pton1(const char *name, struct mpls_label *addr)
>> +static int mpls_pton1(const char *name, struct mpls_label *addr,
>> + unsigned int maxlabels)
>> {
>> char *endp;
>> unsigned count;
>>
>> - for (count = 0; count < MPLS_MAX_LABELS; count++) {
>> + for (count = 0; count < maxlabels; count++) {
>> unsigned long label;
>>
>> label = strtoul(name, &endp, 0);
>> @@ -37,17 +38,19 @@ static int mpls_pton1(const char *name, struct mpls_label *addr)
>> addr += 1;
>> }
>> /* The address was too long */
>> + fprintf(stderr, "Error: too many labels.\n");
>> return 0;
>> }
>>
>> -int mpls_pton(int af, const char *src, void *addr)
>> +int mpls_pton(int af, const char *src, void *addr, size_t alen)
>> {
>> + unsigned int maxlabels = alen / sizeof(struct mpls_label);
>
> Could ARRAY_SIZE be used?
>
> Also, I know its only calculated twice, but might it be nicer to
> provide a function or macro to do so? It seems like an ugly thing
> to open code.
I did it this way with intention -- to mpls_pton addr is just a buffer
of a given length. mpls_pton converts the alen into the number of labels
that the buffer can hold and passes that max to mpls_pton1 to do the
heavy lifting.
^ permalink raw reply
* [PATCH net-next] cxgb4: update latest firmware version supported
From: Ganesh Goudar @ 2017-05-16 15:26 UTC (permalink / raw)
To: netdev, davem; +Cc: nirranjan, indranil, Ganesh Goudar
Change t4fw_version.h to update latest firmware version
number to 1.16.43.0.
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4fw_version.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4fw_version.h b/drivers/net/ethernet/chelsio/cxgb4/t4fw_version.h
index fa37644..3549d387 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4fw_version.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4fw_version.h
@@ -37,7 +37,7 @@
#define T4FW_VERSION_MAJOR 0x01
#define T4FW_VERSION_MINOR 0x10
-#define T4FW_VERSION_MICRO 0x21
+#define T4FW_VERSION_MICRO 0x2B
#define T4FW_VERSION_BUILD 0x00
#define T4FW_MIN_VERSION_MAJOR 0x01
@@ -46,7 +46,7 @@
#define T5FW_VERSION_MAJOR 0x01
#define T5FW_VERSION_MINOR 0x10
-#define T5FW_VERSION_MICRO 0x21
+#define T5FW_VERSION_MICRO 0x2B
#define T5FW_VERSION_BUILD 0x00
#define T5FW_MIN_VERSION_MAJOR 0x00
@@ -55,7 +55,7 @@
#define T6FW_VERSION_MAJOR 0x01
#define T6FW_VERSION_MINOR 0x10
-#define T6FW_VERSION_MICRO 0x21
+#define T6FW_VERSION_MICRO 0x2B
#define T6FW_VERSION_BUILD 0x00
#define T6FW_MIN_VERSION_MAJOR 0x00
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] rt2x00: improve calling conventions for register accessors
From: David Miller @ 2017-05-16 15:37 UTC (permalink / raw)
To: johannes
Cc: sgruszka, arnd, helmut.schaa, kvalo, daniel, dev, pozega.tomislav,
vasilugin, roman, linux-wireless, netdev, linux-kernel
In-Reply-To: <1494935936.15923.0.camel@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Tue, 16 May 2017 13:58:56 +0200
> On Tue, 2017-05-16 at 13:55 +0200, Stanislaw Gruszka wrote:
>>
>> In rt2x00 driver we use poor convention in other kind of registers
>> accessors like bbp, mac, eeprom. I dislike to changing only rfcsr
>> accessors and leaving others in the old way. And changing all
>> accessors would be massive and error prone change, which I'm not
>> prefer either.
>
> That's a stupid argument, but for the sake of it - the conversion can
> easily be done with coccinelle/spatch without being "error prone".
Agreed, we have tools for this.
^ permalink raw reply
* [Patch][IPv6] Fix wrong routing mechanism for Link Local IPv6 packets
From: Michael Ulmer @ 2017-05-16 15:37 UTC (permalink / raw)
To: netdev@vger.kernel.org
Blast from the past. 10 years back Wei Dong submitted the patch found (amongst several places) here:
http://lists.openwall.net/netdev/2007/01/30/20
Problem:
I have a firewall rule that DNATs ipv6 traffic from a destination address to ::1. The route lookup gives me the Main table & forwards that DNAT'd traffic instead of sending it to local process.
Example:
Looking at this from a netfilter point of view, a client (IP of fd00::5) requests a web page at [2000::25:0:0:1]:8080. The firewall rule DNATs it to ::1 (note that I threw a -j TRACE in raw's REROUTING).
TRACE: nat:PREROUTING:rule:2 SRC=fd00::5 DST=2000::25:0:0:1
TRACE: mangle:FORWARD:rule:1 SRC=fd00::5 DST=::1
The patch is verbatim (as is the subject line for this email). Traffic DNAT'd to ::1 now goes to mangle's INPUT chain after routing decision. I'm not sure why it was removed--I'm assuming it was an accident--as I can't find a record in the mailing list archive.
diff --git a/gpl/kernel/linux/net/ipv6/route.c b/gpl/kernel/linux/net/ipv6/route.c
index 3809ca2..2a2563f 100644
--- a/gpl/kernel/linux/net/ipv6/route.c
+++ b/gpl/kernel/linux/net/ipv6/route.c
@@ -611,7 +611,7 @@ static int rt6_score_route(struct rt6_info *rt, int oif,
int m;
m = rt6_check_dev(rt, oif);
- if (!m && (strict & RT6_LOOKUP_F_IFACE))
+ if (!m && (rt->rt6i_flags & RTF_CACHE) && (strict & RT6_LOOKUP_F_IFACE))
return RT6_NUD_FAIL_HARD;
#ifdef CONFIG_IPV6_ROUTER_PREF
m |= IPV6_DECODE_PREF(IPV6_EXTRACT_PREF(rt->rt6i_flags)) << 2;
__
Mike Ulmer
^ permalink raw reply related
* OFFIZIELLE GEWINNBENACHRITIGUNG
From: LOTTERIA LOTTERIA LOTTERIA @ 2017-05-16 22:33 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 698 bytes --]
INTERNATIONALE LOTTERIE-PROMOTION
ONLINE LOTTERIE-ABTEILUNG
Referenznummer: CCX-772-876-EM
Gewinnbenachrichtigung
Wir sind verpflichtet, Ihnen mitteilen zu können das Ergebnis der gerechten abgeschlossen monatliche endgültig zieht der Internationale Online Lotterie Promotion und Ihre e-Mail unter den 20 glücklichen Gewinnern gewonnen €2.100,000.00 Euros
für Sicherheit Grund, Lesen Sie die Anlage in PDF Formant für weitere Informationen bezüglich Ihres Gewinns
Bitte kontaktieren Sie Herr Josef Feldrich über Ihren Gewinn auf joseffeldrich@gmail.com
Mit freundlichen Grüßen
HEAD, ONLINE LOTTERY DEPARTMENT
INTERNATIONALE LOTTERY PROMOTIO
[-- Attachment #2: ACHTUNG GEWINNER.pdf --]
[-- Type: application/octet-stream, Size: 659986 bytes --]
^ permalink raw reply
* Re: [PATCH v2] neighbour: update neigh timestamps iff update is effective
From: Ihar Hrachyshka @ 2017-05-16 15:44 UTC (permalink / raw)
To: davem; +Cc: ja, netdev, Ihar Hrachyshka
In-Reply-To: <20170515.131023.1878814687849300375.davem@davemloft.net>
It's a common practice to send gratuitous ARPs after moving an
IP address to another device to speed up healing of a service. To
fulfill service availability constraints, the timing of network peers
updating their caches to point to a new location of an IP address can be
particularly important.
Sometimes neigh_update calls won't touch neither lladdr nor state, for
example if an update arrives in locktime interval. The neigh->updated
value is tested by the protocol specific neigh code, which in turn
will influence whether NEIGH_UPDATE_F_OVERRIDE gets set in the
call to neigh_update() or not. As a result, we may effectively ignore
the update request, bailing out of touching the neigh entry, except that
we still bump its timestamps inside neigh_update.
This may be a problem for updates arriving in quick succession. For
example, consider the following scenario:
A service is moved to another device with its IP address. The new device
sends three gratuitous ARP requests into the network with ~1 seconds
interval between them. Just before the first request arrives to one of
network peer nodes, its neigh entry for the IP address transitions from
STALE to DELAY. This transition, among other things, updates
neigh->updated. Once the kernel receives the first gratuitous ARP, it
ignores it because its arrival time is inside the locktime interval. The
kernel still bumps neigh->updated. Then the second gratuitous ARP
request arrives, and it's also ignored because it's still in the (new)
locktime interval. Same happens for the third request. The node
eventually heals itself (after delay_first_probe_time seconds since the
initial transition to DELAY state), but it just wasted some time and
require a new ARP request/reply round trip. This unfortunate behaviour
both puts more load on the network, as well as reduces service
availability.
This patch changes neigh_update so that it bumps neigh->updated (as well
as neigh->confirmed) only once we are sure that either lladdr or entry
state will change). In the scenario described above, it means that the
second gratuitous ARP request will actually update the entry lladdr.
Ideally, we would update the neigh entry on the very first gratuitous
ARP request. The locktime mechanism is designed to ignore ARP updates in
a short timeframe after a previous ARP update was honoured by the kernel
layer. This would require tracking timestamps for state transitions
separately from timestamps when actual updates are received. This would
probably involve changes in neighbour struct. Therefore, the patch
doesn't tackle the issue of the first gratuitous APR ignored, leaving
it for a follow-up.
Signed-off-by: Ihar Hrachyshka <ihrachys@redhat.com>
---
v2: added more details to commit message to explain relation between arp
and neigh code.
---
net/core/neighbour.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 58b0bcc..d274f81 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1132,10 +1132,6 @@ int neigh_update(struct neighbour *neigh, const u8 *lladdr, u8 new,
lladdr = neigh->ha;
}
- if (new & NUD_CONNECTED)
- neigh->confirmed = jiffies;
- neigh->updated = jiffies;
-
/* If entry was valid and address is not changed,
do not change entry state, if new one is STALE.
*/
@@ -1157,6 +1153,16 @@ int neigh_update(struct neighbour *neigh, const u8 *lladdr, u8 new,
}
}
+ /* Update timestamps only once we know we will make a change to the
+ * neighbour entry. Otherwise we risk to move the locktime window with
+ * noop updates and ignore relevant ARP updates.
+ */
+ if (new != old || lladdr != neigh->ha) {
+ if (new & NUD_CONNECTED)
+ neigh->confirmed = jiffies;
+ neigh->updated = jiffies;
+ }
+
if (new != old) {
neigh_del_timer(neigh);
if (new & NUD_PROBE)
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] neighbour: update neigh timestamps iff update is effective
From: Ihar Hrachyshka @ 2017-05-16 15:47 UTC (permalink / raw)
To: David S. Miller; +Cc: Julian Anastasov, netdev, Ihar Hrachyshka
In-Reply-To: <20170515214025.28575-1-ihrachys@redhat.com>
On Mon, May 15, 2017 at 2:40 PM, Ihar Hrachyshka <ihrachys@redhat.com> wrote:
> It's a common practice to send gratuitous ARPs after moving an
> IP address to another device to speed up healing of a service. To
> fulfill service availability constraints, the timing of network peers
> updating their caches to point to a new location of an IP address can be
> particularly important.
>
> Sometimes neigh_update calls won't touch neither lladdr nor state, for
> example if an update arrives in locktime interval. The neigh->updated
> value is tested by the protocol specific neigh code, which in turn
> will influence whether NEIGH_UPDATE_F_OVERRIDE gets set in the
> call to neigh_update() or not. As a result, we may effectively ignore
> the update request, bailing out of touching the neigh entry, except that
> we still bump its timestamps inside neigh_update.
>
>
> This may be a problem for updates arriving in quick succession. For
> example, consider the following scenario:
>
> A service is moved to another device with its IP address. The new device
> sends three gratuitous ARP requests into the network with ~1 seconds
> interval between them. Just before the first request arrives to one of
> network peer nodes, its neigh entry for the IP address transitions from
> STALE to DELAY. This transition, among other things, updates
> neigh->updated. Once the kernel receives the first gratuitous ARP, it
> ignores it because its arrival time is inside the locktime interval. The
> kernel still bumps neigh->updated. Then the second gratuitous ARP
> request arrives, and it's also ignored because it's still in the (new)
> locktime interval. Same happens for the third request. The node
> eventually heals itself (after delay_first_probe_time seconds since the
> initial transition to DELAY state), but it just wasted some time and
> require a new ARP request/reply round trip. This unfortunate behaviour
> both puts more load on the network, as well as reduces service
> availability.
>
> This patch changes neigh_update so that it bumps neigh->updated (as well
> as neigh->confirmed) only once we are sure that either lladdr or entry
> state will change). In the scenario described above, it means that the
> second gratuitous ARP request will actually update the entry lladdr.
>
> Ideally, we would update the neigh entry on the very first gratuitous
> ARP request. The locktime mechanism is designed to ignore ARP updates in
> a short timeframe after a previous ARP update was honoured by the kernel
> layer. This would require tracking timestamps for state transitions
> separately from timestamps when actual updates are received. This would
> probably involve changes in neighbour struct. Therefore, the patch
> doesn't tackle the issue of the first gratuitous APR ignored, leaving
> it for a follow-up.
>
> Signed-off-by: Ihar Hrachyshka <ihrachys@redhat.com>
Please disregard this email, I forgot to update the patch version to
v2 and provide changelog. I posted (hopefully) correct version. Still
learning the process...
Ihar
^ permalink raw reply
* [PATCH net-next] cxgb4: reduce resource allocation in kdump kernel
From: Ganesh Goudar @ 2017-05-16 15:47 UTC (permalink / raw)
To: netdev, davem; +Cc: nirranjan, indranil, Ganesh Goudar
When is_kdump_kernel() is true, reduce memory footprint of
cxgb4 by using a single "Queue Set".
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 38a5c67..4249ffb 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -891,7 +891,7 @@ static u16 cxgb_select_queue(struct net_device *dev, struct sk_buff *skb,
* The skb's priority is determined via the VLAN Tag Priority Code
* Point field.
*/
- if (cxgb4_dcb_enabled(dev)) {
+ if (cxgb4_dcb_enabled(dev) && !is_kdump_kernel()) {
u16 vlan_tci;
int err;
@@ -4007,10 +4007,7 @@ static void cfg_queues(struct adapter *adap)
/* Reduce memory usage in kdump environment, disable all offload.
*/
- if (is_kdump_kernel()) {
- adap->params.offload = 0;
- adap->params.crypto = 0;
- } else if (is_uld(adap) && t4_uld_mem_alloc(adap)) {
+ if (is_kdump_kernel() || (is_uld(adap) && t4_uld_mem_alloc(adap))) {
adap->params.offload = 0;
adap->params.crypto = 0;
}
@@ -4031,7 +4028,7 @@ static void cfg_queues(struct adapter *adap)
struct port_info *pi = adap2pinfo(adap, i);
pi->first_qset = qidx;
- pi->nqsets = 8;
+ pi->nqsets = is_kdump_kernel() ? 1 : 8;
qidx += pi->nqsets;
}
#else /* !CONFIG_CHELSIO_T4_DCB */
@@ -4044,6 +4041,9 @@ static void cfg_queues(struct adapter *adap)
if (q10g > netif_get_num_default_rss_queues())
q10g = netif_get_num_default_rss_queues();
+ if (is_kdump_kernel())
+ q10g = 1;
+
for_each_port(adap, i) {
struct port_info *pi = adap2pinfo(adap, i);
--
2.1.0
^ permalink raw reply related
* Re: [PATCH v2 net-next 00/12] drivers: net: xgene: Add ethtool stats and bug fixes
From: David Miller @ 2017-05-16 15:48 UTC (permalink / raw)
To: isubramanian; +Cc: netdev, linux-arm-kernel, patches, qnguyen
In-Reply-To: <1494449110-23785-1-git-send-email-isubramanian@apm.com>
From: Iyappan Subramanian <isubramanian@apm.com>
Date: Wed, 10 May 2017 13:44:58 -0700
> This patch set,
>
> - adds ethtool extended statistics support
> - addresses errata workarounds
> - fixes bugs related to statistics
>
> Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
> Signed-off-by: Quan Nguyen <qnguyen@apm.com>
Series applied.
Please address Florian's feedback on patch #3.
^ permalink raw reply
* Re: [ISSUE: sky2 - rx error] Link stops working under heavy traffic load connected to a mv88e6176
From: Rafa Corvillo @ 2017-05-16 15:50 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Stephen Hemminger, netdev
In-Reply-To: <20170516132116.GE5456@lunn.ch>
> On Tue, May 16, 2017 at 03:09:17PM +0200, Rafa Corvillo wrote:
>>>> Adding 8 bytes (sky2->netdev->mtu + ETH_HLEN + VLAN_HLEN + 8
>>>> (EDSA_HLEN)) does not fix the error, because the interface keep
>>>> having a maximum length of 1518 bytes (sky2->netdev->mtu + ETH_HLEN
>>>> + VLAN_HLEN).
>>>
>>> Did you check the value being written to here:
>>>
>>> /*
>>> * The receiver hangs if it receives frames larger than the
>>> * packet buffer. As a workaround, truncate oversize frames, but
>>> * the register is limited to 9 bits, so if you do frames > 2052
>>> * you better get the MTU right!
>>> */
>>> thresh = sky2_get_rx_threshold(sky2);
>>> if (thresh > 0x1ff)
>>> sky2_write32(hw, SK_REG(sky2->port, RX_GMF_CTRL_T), RX_TRUNC_OFF);
>>> else {
>>> sky2_write16(hw, SK_REG(sky2->port, RX_GMF_TR_THR), thresh);
>>> sky2_write32(hw, SK_REG(sky2->port, RX_GMF_CTRL_T), RX_TRUNC_ON);
>>> }
>>>
>>>
>>> What is thresh?
>>
>> The value of thresh is 380.
>
> So that is 1528.
Yes, this is the result of the roundup function.
>
> You could hack it and try 0x1ff.
I have forced the value of thresh to 0x1ff and the rx error still appears.
>
> Also, check that in sky2_rx_add(), le->length is set to 4K.
>
The value of le->length is set to 1520.
Rafa
^ permalink raw reply
* Re: [PATCH v2 net-next] bnxt: add dma mapping attributes
From: David Miller @ 2017-05-16 15:53 UTC (permalink / raw)
To: shannon.nelson; +Cc: netdev, sparclinux, michael.chan
In-Reply-To: <1494379812-282087-1-git-send-email-shannon.nelson@oracle.com>
From: Shannon Nelson <shannon.nelson@oracle.com>
Date: Tue, 9 May 2017 18:30:12 -0700
> On the SPARC platform we need to use the DMA_ATTR_WEAK_ORDERING attribute
> in our Rx path dma mapping in order to get the expected performance out
> of the receive path. Adding it to the Tx path has little effect, so
> that's not a part of this patch.
>
> Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
> Reviewed-by: Tushar Dave <tushar.n.dave@oracle.com>
> Reviewed-by: Tom Saeger <tom.saeger@oracle.com>
> ---
> v2: simplify by getting rid of the driver-specific ifdef and define
Applied.
^ permalink raw reply
* Re: [PATCH net-next,v2] tools: hv: Add clean up for included files in Ubuntu net config
From: David Miller @ 2017-05-16 15:53 UTC (permalink / raw)
To: haiyangz, haiyangz; +Cc: netdev, kys, olaf, vkuznets, linux-kernel
In-Reply-To: <1494616451-30130-1-git-send-email-haiyangz@exchange.microsoft.com>
From: Haiyang Zhang <haiyangz@exchange.microsoft.com>
Date: Fri, 12 May 2017 12:14:11 -0700
> From: Haiyang Zhang <haiyangz@microsoft.com>
>
> The clean up function is updated to cover duplicate config info in
> files included by "source" key word in Ubuntu network config.
>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: socket: mark socket protocol handler structs as const
From: David Miller @ 2017-05-16 15:55 UTC (permalink / raw)
To: xiaolou4617-Re5JQEeQqe8AvxtiuMwx3w
Cc: marcel-kz+m5ild9QBg9hUCZPvPmw, gustavo-THi1TnShQwVAfugRpC6u6w,
johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w,
dmitry.tarnyagin-0TCahj4L2NoXWF+eFR7m5Q,
sameo-VuQAYsv1563Yd54FQh9/CA, nhorman-2XuSBdqkA4R54TAoqtyWWQ,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1494815207-9378-1-git-send-email-xiaolou4617-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: linzhang <xiaolou4617-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Mon, 15 May 2017 10:26:47 +0800
> Signed-off-by: linzhang <xiaolou4617-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Applied.
^ permalink raw reply
* [PATCH net-next] cxgb4: keep carrier off after registering netdev
From: Ganesh Goudar @ 2017-05-16 15:56 UTC (permalink / raw)
To: netdev, davem; +Cc: nirranjan, indranil, Surendra Mobiya, Ganesh Goudar
From: Surendra Mobiya <surendra@chelsio.com>
Mark carrier off after registering netdev to ensure that vlan device
picks up the correct state of the carrier
Signed-off-by: Surendra Mobiya <surendra@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 4249ffb..316ba8b 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -4954,6 +4954,7 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
break;
adapter->chan_map[pi->tx_chan] = i;
print_port_info(adapter->port[i]);
+ netif_carrier_off(adapter->port[i]);
}
if (i == 0) {
dev_err(&pdev->dev, "could not register any net devices\n");
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] net/smc: mark as BROKEN due to remote memory exposure
From: Doug Ledford @ 2017-05-16 15:57 UTC (permalink / raw)
To: David Miller, Bart.VanAssche-XdAiOPVOjttBDgjK7y7TUQ,
Torvalds, Linus
Cc: hch-jcswGhMUV9g, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, stable-u79uwXL29TY76Z2rM5mHXA,
ubraun-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
In-Reply-To: <20170514.204404.1844909849561204299.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Hi Linus,
I've added you to this thread. A quick synopsis: Dave sent you the
net/smc driver for 4.11. Even though it lives in net/smc, it is, for
the most part, a net<->rdma translator and so it is as much an RDMA
driver as anything else. And upon review, the rdma community does not
believe either the spec/rfc or the driver are the right way to engineer
this particular technology, and the implementation leaves much to be
desired.
On Sun, 2017-05-14 at 20:44 -0400, David Miller wrote:
> From: Bart Van Assche <Bart.VanAssche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
> Date: Sun, 14 May 2017 19:08:50 +0000
>
> > What is your plan to avoid that applications start using and
> > depending on AF_SMC?
>
> The API is out there already so we are out of luck, and neither
> you nor I nor anyone else can "stop" this from happening.
That's not true at all. There's nothing that says we can't revert this
now before it goes any further. It's only been in two kernels, I'm
positive it hasn't landed in any distros yet, and it can go back to
being something people can add on the side. Futher, the "standard"
this is based on is not a real standard, it's just a publication and
has not been through a standard track. I wouldn't consider this "out
there already" until there is a standard that has gone through the
standard track.
Regardless though, I'm rather purturbed about this entire thing. If
you are right that because this got into 4.11, it's now a done deal,
then the fact that this went through 4 review cycles on netdev@ that,
as I understand it, spanned roughly one years time, and not one single
person bothered to note that this was as much an RDMA driver as
anything else, and not one person bothered to note that linux-rdma@ was
not on the Cc: list, and not one person told the submitters that they
needed to include linux-rdma@ on the Cc: list of these submissions, and
you took it without any review comments from any RDMA people in the
course of a year, or an ack from me to show that the RDMA portion of
this had at least been given some sort of review, was a collosal fuckup
of cross tree maintainer cooperation.
The SMC driver makes several mistakes that people tried to avoid with
previous RDMA standards, it only supports one out of the five possible
link layers (iWARP, IB, OPA, RoCEv1, RoCEv2), it uses a highly
discouraged and deprecated technique for memory registration that is
considered horribly insecure (handing the keys to the castle to anyone
who connects to the machine, aka, the entire memory space is registered
with one key and that key is given to remote connections, so they can
read any bit of kernel memory they want as opposed to whatever we tell
them to read), and the design as articuled in the published rfc seems
incomplete for dealing with any of the other link layers, indicating
that this should have probably stayed out until the rfc was discussed
and updated to address the shortcomings obviously present in the
current rfc. With all of these issues outstanding against it, I hope
you can see why I think the way I do about you taking it without ever
consulting any of the RDMA community.
But that leaves us with the question of what to do moving forward.
Probably the number one concern is that this protocol chose to create
a new AF as opposed to reusing the IPv4 and IPv6 address families and
adding an option similar to SCTP for enabling the new protocol on a
specific socket. The concern is that we have means of addressing all
of the link layers the RDMA subsystem supports using IPv4 or IPv6 (sort
of...it's possible to have IB or OPA without IPoIB, which leaves them
without an IPv4 or IPv6 address, in which case the rdmacm can use
native GUIDs to resolve the other side, but that only works for verbs
connections, in the case of TCP connections, we always require IPoIB to
be present, and so IPv4 or IPv6 is always sufficient). In the end,
switching this protocol to use AF_INET and AF_INET6 and a protocol
option to enable SMC may be what we need to do. That, of course,
changes the user space API. So, are we truly locked in at this point?
I would suggest that, since this is only present in 4.11 and 4.12, and
I'm sure this has not landed in any distros as of yet (except maybe
something like Fedora rawhide), we can submit a patch to both the
current kernel and the 4.11 stable to set this code as
CONFIG_EXPERIMENTAL and mark the API as possibly going to undergo
change. Then let the RDMA community work with IBM to get this properly
fixed so that this is a reasonable RDMA driver and not something the
community is ready to immediately trash, and only after we've got it
whipped into shape and the RDMA community is satisfied it is a
reasonable driver that can continue to work with future planned RDMA
subsystem updates and across various link layers, we remove the
EXPERIMENTAL marker and freeze the API for user space.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [ISSUE: sky2 - rx error] Link stops working under heavy traffic load connected to a mv88e6176
From: Andrew Lunn @ 2017-05-16 15:58 UTC (permalink / raw)
To: Rafa Corvillo; +Cc: Stephen Hemminger, netdev
In-Reply-To: <591B1FC2.1090402@aoifes.com>
> >Also, check that in sky2_rx_add(), le->length is set to 4K.
> >
>
> The value of le->length is set to 1520.
> Rafa
Ah.
You probably need to change sky2_get_rx_data_size() as well, to add in
the extra 8 bytes.
Andrew
^ permalink raw reply
* [PATCH net-next] cxgb4: add new T5 pci device id
From: Ganesh Goudar @ 2017-05-16 16:09 UTC (permalink / raw)
To: netdev, davem; +Cc: nirranjan, indranil, Ganesh Goudar
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h b/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
index a323185..9232bec 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
@@ -172,6 +172,7 @@ CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN
CH_PCI_ID_TABLE_FENTRY(0x509e), /* Custom T520-CR */
CH_PCI_ID_TABLE_FENTRY(0x509f), /* Custom T540-CR */
CH_PCI_ID_TABLE_FENTRY(0x50a0), /* Custom T540-CR */
+ CH_PCI_ID_TABLE_FENTRY(0x50a1), /* Custom T540-CR */
/* T6 adapters:
*/
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] net: ethernet: broadcom: bnxt: remove dead code
From: Gustavo A. R. Silva @ 2017-05-16 16:18 UTC (permalink / raw)
To: Michael Chan; +Cc: Netdev, open list
In-Reply-To: <CACKFLimtPW-uxEUK2GaL-ZPLhLOx19Qqzr8d-pVcV3bOEXqYTA@mail.gmail.com>
Hi Michael,
Quoting Michael Chan <michael.chan@broadcom.com>:
> On Mon, May 15, 2017 at 3:28 PM, Gustavo A. R. Silva
> <garsilva@embeddedor.com> wrote:
>> Local variable _sh_ is assigned to a constant value and it is never updated
>> again. Remove this variable and the dead code it guards.
>>
>> Addresses-Coverity-ID: 1350916
>> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
>> ---
>> drivers/net/ethernet/broadcom/bnxt/bnxt.c | 9 +++------
>> 1 file changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
>> b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
>> index 1f1e54b..018674b 100644
>> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
>> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
>> @@ -7380,12 +7380,10 @@ static int bnxt_get_dflt_rings(struct bnxt
>> *bp, int *max_rx, int *max_tx,
>> static int bnxt_set_dflt_rings(struct bnxt *bp)
>> {
>> int dflt_rings, max_rx_rings, max_tx_rings, rc;
>> - bool sh = true;
>
> The point of this logic is that we can easily change the default to
> shared rings or separate rings. I think what I'll do is change it so
> that the parameter sh is passed in and let the caller decide. Thanks
> for pointing this out.
>
Sure thing, glad to help.
--
Gustavo A. R. Silva
^ permalink raw reply
* Re: [ISSUE: sky2 - rx error] Link stops working under heavy traffic load connected to a mv88e6176
From: Rafa Corvillo @ 2017-05-16 16:19 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Stephen Hemminger, netdev
In-Reply-To: <20170516155843.GE32357@lunn.ch>
>>> Also, check that in sky2_rx_add(), le->length is set to 4K.
>>>
>>
>> The value of le->length is set to 1520.
>
>> Rafa
>
> Ah.
>
> You probably need to change sky2_get_rx_data_size() as well, to add in
> the extra 8 bytes.
>
> Andrew
>
If I add the extra 8 byte in the function sky2_get_rx_data_size(), the
value of le->length is set to 1528. But the rx error still appears.
Because of that, I think it is possible the maximum length could be set
outside the sky2 code.
Rafa
^ permalink raw reply
* Re: [patch net-next v2 00/10] net: sched: introduce multichain support for filters
From: David Miller @ 2017-05-16 16:20 UTC (permalink / raw)
To: jiri
Cc: netdev, jhs, xiyou.wangcong, dsa, edumazet, stephen, daniel,
alexander.h.duyck, simon.horman, mlxsw
In-Reply-To: <20170515083857.3615-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Mon, 15 May 2017 10:38:47 +0200
> This patchset contains two major patches:
> 8/10 - This patch introduces the support for having multiple
> chains of filters.
> 10/10 - This patch adds new control action to allow going to specified chain
>
> The rest of the patches are smaller or bigger depencies of those 2.
> Please see individual patch descriptions for details.
I'm expecting at least some adjustments to the tests in the final
patch based upon your discussions with Daniel, and thus another
spin of this series.
^ permalink raw reply
* Re: [PATCH v3] bridge: netlink: check vlan_default_pvid range
From: Nikolay Aleksandrov @ 2017-05-16 16:23 UTC (permalink / raw)
To: Tobias Jungel, Sabrina Dubroca, Stephen Hemminger,
David S. Miller, netdev
In-Reply-To: <20170516084840.21432-1-tobias.jungel@bisdn.de>
On 5/16/17 11:48 AM, Tobias Jungel wrote:
> Currently it is allowed to set the default pvid of a bridge to a value
> above VLAN_VID_MASK (0xfff). This patch adds a check to br_validate and
> returns -EINVAL in case the pvid is out of bounds.
>
> Reproduce by calling:
>
> [root@test ~]# ip l a type bridge
> [root@test ~]# ip l a type dummy
> [root@test ~]# ip l s bridge0 type bridge vlan_filtering 1
> [root@test ~]# ip l s bridge0 type bridge vlan_default_pvid 9999
> [root@test ~]# ip l s dummy0 master bridge0
> [root@test ~]# bridge vlan
> port vlan ids
> bridge0 9999 PVID Egress Untagged
>
> dummy0 9999 PVID Egress Untagged
>
> Fixes: 0f963b7592ef ("bridge: netlink: add support for default_pvid")
> Signed-off-by: Tobias Jungel <tobias.jungel@bisdn.de>
> ---
> net/bridge/br_netlink.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
> index c5ce774..47cb95b 100644
> --- a/net/bridge/br_netlink.c
> +++ b/net/bridge/br_netlink.c
> @@ -835,6 +835,12 @@ static int br_validate(struct nlattr *tb[], struct nlattr *data[])
> return -EPROTONOSUPPORT;
> }
> }
> +
> + if (data[IFLA_BR_VLAN_DEFAULT_PVID]) {
> + __u16 defpvid = nla_get_u16(data[IFLA_BR_VLAN_DEFAULT_PVID]);
Please leave a blank line between the variable definition and the rest.
> + if (defpvid >= VLAN_VID_MASK)
> + return -EINVAL;
> + }
> #endif
>
> return 0;
>
This version looks good to me, with the above stylistic issue fixed feel
free to add my:
Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Thanks!
^ permalink raw reply
* Re: [patch net-next v2 00/10] net: sched: introduce multichain support for filters
From: Jiri Pirko @ 2017-05-16 16:23 UTC (permalink / raw)
To: David Miller
Cc: netdev, jhs, xiyou.wangcong, dsa, edumazet, stephen, daniel,
alexander.h.duyck, simon.horman, mlxsw
In-Reply-To: <20170516.122021.1415036093574332123.davem@davemloft.net>
Tue, May 16, 2017 at 06:20:21PM CEST, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Mon, 15 May 2017 10:38:47 +0200
>
>> This patchset contains two major patches:
>> 8/10 - This patch introduces the support for having multiple
>> chains of filters.
>> 10/10 - This patch adds new control action to allow going to specified chain
>>
>> The rest of the patches are smaller or bigger depencies of those 2.
>> Please see individual patch descriptions for details.
>
>I'm expecting at least some adjustments to the tests in the final
>patch based upon your discussions with Daniel, and thus another
>spin of this series.
Will send in a jiff. Thanks
^ permalink raw reply
* Re: linux-next: Tree for May 16 (net/core)
From: Randy Dunlap @ 2017-05-16 16:28 UTC (permalink / raw)
To: Stephen Rothwell, Linux-Next Mailing List
Cc: Linux Kernel Mailing List, netdev@vger.kernel.org
In-Reply-To: <20170516112125.517607f8@canb.auug.org.au>
On 05/15/17 18:21, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20170515:
>
on i386 or x86_64:
when CONFIG_INET is not enabled:
../net/core/sock.c: In function 'skb_orphan_partial':
../net/core/sock.c:1810:2: error: implicit declaration of function 'skb_is_tcp_pure_ack' [-Werror=implicit-function-declaration]
if (skb_is_tcp_pure_ack(skb))
^
--
~Randy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox