* Re: [PATCH net-next] net: dsa: bcm_sf2: dst in not an array
From: Florian Fainelli @ 2017-08-02 19:55 UTC (permalink / raw)
To: Vivien Didelot, netdev; +Cc: linux-kernel, kernel, David S. Miller, Andrew Lunn
In-Reply-To: <20170802194825.29002-1-vivien.didelot@savoirfairelinux.com>
On 08/02/2017 12:48 PM, Vivien Didelot wrote:
> It's been a while now since ds->dst is not an array anymore, but a
> simple pointer to a dsa_switch_tree.
>
> Fortunately, SF2 does not support multi-chip and thus ds->index is
> always 0.
>
> This patch substitutes 'ds->dst[ds->index].' with 'ds->dst->'.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Thanks!
--
Florian
^ permalink raw reply
* [PATCH net-next] net: dsa: bcm_sf2: dst in not an array
From: Vivien Didelot @ 2017-08-02 19:48 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn, Vivien Didelot
It's been a while now since ds->dst is not an array anymore, but a
simple pointer to a dsa_switch_tree.
Fortunately, SF2 does not support multi-chip and thus ds->index is
always 0.
This patch substitutes 'ds->dst[ds->index].' with 'ds->dst->'.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
drivers/net/dsa/bcm_sf2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 6bbfa6ea1efb..558667c814c9 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -788,7 +788,7 @@ static int bcm_sf2_sw_resume(struct dsa_switch *ds)
static void bcm_sf2_sw_get_wol(struct dsa_switch *ds, int port,
struct ethtool_wolinfo *wol)
{
- struct net_device *p = ds->dst[ds->index].cpu_dp->netdev;
+ struct net_device *p = ds->dst->cpu_dp->netdev;
struct bcm_sf2_priv *priv = bcm_sf2_to_priv(ds);
struct ethtool_wolinfo pwol;
@@ -811,7 +811,7 @@ static void bcm_sf2_sw_get_wol(struct dsa_switch *ds, int port,
static int bcm_sf2_sw_set_wol(struct dsa_switch *ds, int port,
struct ethtool_wolinfo *wol)
{
- struct net_device *p = ds->dst[ds->index].cpu_dp->netdev;
+ struct net_device *p = ds->dst->cpu_dp->netdev;
struct bcm_sf2_priv *priv = bcm_sf2_to_priv(ds);
s8 cpu_port = ds->dst->cpu_dp->index;
struct ethtool_wolinfo pwol;
--
2.13.3
^ permalink raw reply related
* Re: [iproute PATCH] bpf: Make bytecode-file reading a little more robust
From: Daniel Borkmann @ 2017-08-02 19:21 UTC (permalink / raw)
To: Phil Sutter, Stephen Hemminger; +Cc: netdev
In-Reply-To: <20170802125756.26210-1-phil@nwl.cc>
On 08/02/2017 02:57 PM, Phil Sutter wrote:
> bpf_parse_string() will now correctly handle:
>
> - Extraneous whitespace,
> - OPs on multiple lines and
> - overlong file names.
>
> The added feature of allowing to have OPs on multiple lines (like e.g.
> tcpdump prints them) is rather a side effect of fixing detection of
> malformed bytecode files having random content on a second line, like
> e.g.:
>
> | 4,40 0 0 12,21 0 1 2048,6 0 0 262144,6 0 0 0
> | foobar
>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: [PATCH v2 net-next 3/4] tcp: Adjust TCP ULP to defer to sockets ULP
From: Tom Herbert @ 2017-08-02 19:03 UTC (permalink / raw)
To: Dave Watson; +Cc: netdev, Rohit LastName
In-Reply-To: <20170802185908.GA47485@apz-mbp.dhcp.thefacebook.com>
On Wed, Aug 2, 2017 at 11:59 AM, Dave Watson <davejwatson@fb.com> wrote:
> On 08/01/17 08:18 PM, Tom Herbert wrote:
>> Fix TCP and TLS to use the newer ULP infrastructure in sockets.
>>
>> Signed-off-by: Tom Herbert <tom@quantonium.net>
>> ---
>> Documentation/networking/tls.txt | 6 +-
>> include/net/inet_connection_sock.h | 4 --
>> include/net/tcp.h | 25 -------
>> include/net/tls.h | 4 +-
>> net/ipv4/sysctl_net_ipv4.c | 9 ++-
>> net/ipv4/tcp.c | 40 ++++++-----
>> net/ipv4/tcp_ipv4.c | 2 -
>> net/ipv4/tcp_ulp.c | 135 -------------------------------------
>> net/tls/Kconfig | 1 +
>> net/tls/tls_main.c | 21 +++---
>> 10 files changed, 47 insertions(+), 200 deletions(-)
>> delete mode 100644 net/ipv4/tcp_ulp.c
>
> It looks like net/ipv4/Makefile needs updating as well.
>
Right, I'll send out v3.
> I ran this through some ktls tests with no issues. Thanks
>
> Tested-by: Dave Watson <davejwatson@fb.com>
Thanks for testing!
Tom
^ permalink raw reply
* Re: [PATCH v2 net-next 3/4] tcp: Adjust TCP ULP to defer to sockets ULP
From: Dave Watson @ 2017-08-02 18:59 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev, rohit
In-Reply-To: <20170802031846.21993-4-tom@quantonium.net>
On 08/01/17 08:18 PM, Tom Herbert wrote:
> Fix TCP and TLS to use the newer ULP infrastructure in sockets.
>
> Signed-off-by: Tom Herbert <tom@quantonium.net>
> ---
> Documentation/networking/tls.txt | 6 +-
> include/net/inet_connection_sock.h | 4 --
> include/net/tcp.h | 25 -------
> include/net/tls.h | 4 +-
> net/ipv4/sysctl_net_ipv4.c | 9 ++-
> net/ipv4/tcp.c | 40 ++++++-----
> net/ipv4/tcp_ipv4.c | 2 -
> net/ipv4/tcp_ulp.c | 135 -------------------------------------
> net/tls/Kconfig | 1 +
> net/tls/tls_main.c | 21 +++---
> 10 files changed, 47 insertions(+), 200 deletions(-)
> delete mode 100644 net/ipv4/tcp_ulp.c
It looks like net/ipv4/Makefile needs updating as well.
I ran this through some ktls tests with no issues. Thanks
Tested-by: Dave Watson <davejwatson@fb.com>
^ permalink raw reply
* Re: [PATCH RFC, iproute2] tc/mirred: Extend the mirred/redirect action to accept additional traffic class parameter
From: Nambiar, Amritha @ 2017-08-02 18:58 UTC (permalink / raw)
To: Roopa Prabhu
Cc: stephen@networkplumber.org, netdev@vger.kernel.org,
Alexander Duyck, kiran.patil, Samudrala, Sridhar,
mitch.a.williams, Alexander Duyck, neerav.parikh, carolyn.wyborny,
Jeff Kirsher
In-Reply-To: <CAJieiUi=W1jJBkMXTnFYL=Cw4ZWCv5zeg1vtveW5TyfJ2noe9w@mail.gmail.com>
On 8/2/2017 11:41 AM, Roopa Prabhu wrote:
> On Mon, Jul 31, 2017 at 5:40 PM, Amritha Nambiar
> <amritha.nambiar@intel.com> wrote:
>> The Mirred/redirect action is extended to accept a traffic
>> class on the device in addition to the device's ifindex.
>>
>> Usage: mirred <DIRECTION> <ACTION> <dev DEVICENAME> <tc TC_INDEX>
>>
>> Example:
>> # tc qdisc add dev eth0 ingress
>>
>> # tc filter add dev eth0 protocol ip parent ffff: prio 1 flower\
>> dst_ip 192.168.1.1/32 ip_proto udp dst_port 22\
>> indev eth0 action mirred ingress redirect dev eth0 tc 1
>
>
> Can we call the new parameter tclass or something else ?.
> with this 'tc' appears twice in the command :)
>
Sounds right. I was already thinking of alternatives like 'tcqgroup',
'qgroup' and now we have 'tclass'.
^ permalink raw reply
* Re: [PATCH RFC, iproute2] tc/mirred: Extend the mirred/redirect action to accept additional traffic class parameter
From: Roopa Prabhu @ 2017-08-02 18:41 UTC (permalink / raw)
To: Amritha Nambiar
Cc: stephen@networkplumber.org, netdev@vger.kernel.org,
Alexander Duyck, kiran.patil, Samudrala, Sridhar,
mitch.a.williams, Alexander Duyck, neerav.parikh, carolyn.wyborny,
Jeff Kirsher
In-Reply-To: <150154805003.4819.12498976860683140342.stgit@anamdev.jf.intel.com>
On Mon, Jul 31, 2017 at 5:40 PM, Amritha Nambiar
<amritha.nambiar@intel.com> wrote:
> The Mirred/redirect action is extended to accept a traffic
> class on the device in addition to the device's ifindex.
>
> Usage: mirred <DIRECTION> <ACTION> <dev DEVICENAME> <tc TC_INDEX>
>
> Example:
> # tc qdisc add dev eth0 ingress
>
> # tc filter add dev eth0 protocol ip parent ffff: prio 1 flower\
> dst_ip 192.168.1.1/32 ip_proto udp dst_port 22\
> indev eth0 action mirred ingress redirect dev eth0 tc 1
Can we call the new parameter tclass or something else ?.
with this 'tc' appears twice in the command :)
^ permalink raw reply
* Re: [PATCH 1/2] [for 4.13] net: qcom/emac: disable flow control autonegotiation by default
From: Timur Tabi @ 2017-08-02 18:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20170802.113531.1671960264039506111.davem@davemloft.net>
On 08/02/2017 01:35 PM, David Miller wrote:
> Again, any serious installation will have a system watchdog enabled
> which will break the pause frame bomb.
Oh well. I guess I'll have to carry this patch internally.
What about patch #2?
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH 1/2] [for 4.13] net: qcom/emac: disable flow control autonegotiation by default
From: David Miller @ 2017-08-02 18:36 UTC (permalink / raw)
To: timur; +Cc: netdev
In-Reply-To: <290fdd25-7e05-57c8-8f89-52bb3bae1e59@codeaurora.org>
From: Timur Tabi <timur@codeaurora.org>
Date: Wed, 2 Aug 2017 13:23:18 -0500
> It's practically impossible to overload the chip such that it can't
> process the incoming packets fast enough. I don't know of any
> real-world situation where the EMAC needs to transmit pause frames.
Slow cpus or very expensive stack operations can cause this, it's not
a property of the EMAC chip at all.
^ permalink raw reply
* Re: [PATCH 1/2] [for 4.13] net: qcom/emac: disable flow control autonegotiation by default
From: David Miller @ 2017-08-02 18:35 UTC (permalink / raw)
To: timur; +Cc: netdev
In-Reply-To: <290fdd25-7e05-57c8-8f89-52bb3bae1e59@codeaurora.org>
From: Timur Tabi <timur@codeaurora.org>
Date: Wed, 2 Aug 2017 13:23:18 -0500
> On 08/02/2017 12:54 PM, David Miller wrote:
>> And if this kind of thing matters to the user, they will have a
>> software or hardware watchdog driver enabled to break out of this
>> situation.
>
> The problem is that the user is not going to expect that the EMAC can
> disable the nearby switch(es) when the kernel is hung and not rebooted
> quickly enough. Internally, this bug/feature has caused quite a bit
> of mayhem, so the problem is real. No cares about enabling flow
> control -- it just happens to be enabled on some systems where the
> switch agrees to it. So random individuals can't debug the hardware
> because suddenly the EMAC has gone haywire and disabled the local
> network.
Again, any serious installation will have a system watchdog enabled
which will break the pause frame bomb.
^ permalink raw reply
* Re: [PATCH RFC, iproute2] tc/mirred: Extend the mirred/redirect action to accept additional traffic class parameter
From: Nambiar, Amritha @ 2017-08-02 18:28 UTC (permalink / raw)
To: David Laight, 'Stephen Hemminger'
Cc: netdev@vger.kernel.org, alexander.h.duyck@intel.com,
kiran.patil@intel.com, sridhar.samudrala@intel.com,
mitch.a.williams@intel.com, alexander.duyck@gmail.com,
neerav.parikh@intel.com, carolyn.wyborny@intel.com,
jeffrey.t.kirsher@intel.com
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DD00483C5@AcuExch.aculab.com>
On 8/1/2017 8:12 AM, David Laight wrote:
> From: Stephen Hemminger
>> Sent: 01 August 2017 04:52
>> On Mon, 31 Jul 2017 17:40:50 -0700
>> Amritha Nambiar <amritha.nambiar@intel.com> wrote:
>> The concept is fine, bu t the code looks different than the rest which
>> is never a good sign.
>>
>>
>>> + if ((argc > 0) && (matches(*argv, "tc") == 0)) {
>>
>> Extra () are unnecessary in compound conditional.
>>
>>> + tc = atoi(*argv);
>>
>> Prefer using strtoul since it has better error handling than atoi()
>>
>>> + argc--;
>>> + argv++;
>>> + }
>>
>>
>> Use NEXT_ARG() construct like rest of the code.
>
> Why bother faffing about with argc at all?
> The argument list terminates when *argv == NULL.
>
I'll submit the next version with these fixes.
> David
>
^ permalink raw reply
* Re: [PATCH 1/2] [for 4.13] net: qcom/emac: disable flow control autonegotiation by default
From: Timur Tabi @ 2017-08-02 18:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20170802.105453.1408822174555343968.davem@davemloft.net>
On 08/02/2017 12:54 PM, David Miller wrote:
> And if this kind of thing matters to the user, they will have a
> software or hardware watchdog driver enabled to break out of this
> situation.
The problem is that the user is not going to expect that the EMAC can
disable the nearby switch(es) when the kernel is hung and not rebooted
quickly enough. Internally, this bug/feature has caused quite a bit of
mayhem, so the problem is real. No cares about enabling flow control --
it just happens to be enabled on some systems where the switch agrees to
it. So random individuals can't debug the hardware because suddenly the
EMAC has gone haywire and disabled the local network.
> Turning off flow control by default has so many negative ramifications
> and don't try to convince me that users will be "aware" of this and
> turn it back on.
What are the negative ramifications? It's practically impossible to
overload the chip such that it can't process the incoming packets fast
enough. I don't know of any real-world situation where the EMAC needs
to transmit pause frames.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH 6/6] [net-next]net: i40e: Enable cloud filters in i40e via tc/flower classifier
From: Nambiar, Amritha @ 2017-08-02 18:20 UTC (permalink / raw)
To: Jamal Hadi Salim, intel-wired-lan, jeffrey.t.kirsher
Cc: alexander.h.duyck, kiran.patil, netdev, mitch.a.williams,
alexander.duyck, neerav.parikh, sridhar.samudrala,
carolyn.wyborny, Or Gerlitz
In-Reply-To: <382b07c6-562b-9dc6-a4be-8f82819ab87a@mojatatu.com>
On 8/2/2017 5:02 AM, Jamal Hadi Salim wrote:
> On 17-08-01 10:13 PM, Nambiar, Amritha wrote:
>>
>> On 8/1/2017 3:56 AM, Jamal Hadi Salim wrote:
>>> On 17-07-31 08:38 PM, Amritha Nambiar wrote:
>>>> This patch enables tc-flower based hardware offloads. tc/flower
>>>> filter provided by the kernel is configured as driver specific
>>>> cloud filter. The patch implements functions and admin queue
>>>> commands needed to support cloud filters in the driver and
>>>> adds cloud filters to configure these tc-flower filters.
>>>>
>>>> The only action supported is to redirect packets to a traffic class
>>>> on the same device.
>>>>
>>>> # tc qdisc add dev eth0 ingress
>>>> # ethtool -K eth0 hw-tc-offload on
>>>>
>>>> # tc filter add dev eth0 protocol ip parent ffff:\
>>>> prio 1 flower dst_mac 3c:fd:fe:a0:d6:70 skip_sw indev eth0\
>>>> action mirred ingress redirect dev eth0 tc 0
>>>>
>>>
>>> Out of curiosity - did you need to say "indev eth0" there?
>>
>> It looks like I don't need to specify "indev eth0". I will need to look
>> up how this part is offloaded and probably validate in the driver when
>> this is specified.
>>
>>> Also: Is it possible to add an skbmark? Example something like
>>> these that directs two flows to the same queue but different
>>> skb marks:
>>>
>>> # tc filter add dev eth0 protocol ip parent ffff: \
>>> prio 2 flower dst_ip 192.168.3.5/32 \
>>> ip_proto udp dst_port 2a skip_sw \
>>> action skbedit mark 11 \
>>> action mirred ingress redirect dev eth0 tcqueue 1
>>>
>>> # tc filter add dev eth0 protocol ip parent ffff: \
>>> prio 1 flower dst_mac 3c:fd:fe:a0:d6:70 skip_sw \
>>> action skbedit mark 12 \
>>> action mirred ingress redirect dev eth0 tcqueue 1
>>>
>>
>> It is possible to support the skbedit mark action for the first rule
>> here (L3 and L4) which I can take up in a subsequent patch, but this
>> cannot be supported on our device for L2 based match in the second rule.
>>
>
> Ok, thanks. So the issue is one of hardware limitation?
>
Right. Our hardware does not have this support now.
> cheers,
> jamal
>
^ permalink raw reply
* Re: [PATCH net-next RFC 0/6] Configure cloud filters in i40e via tc/flower classifier
From: Nambiar, Amritha @ 2017-08-02 18:17 UTC (permalink / raw)
To: Jamal Hadi Salim, intel-wired-lan, jeffrey.t.kirsher
Cc: alexander.h.duyck, kiran.patil, netdev, mitch.a.williams,
alexander.duyck, neerav.parikh, sridhar.samudrala,
carolyn.wyborny, Or Gerlitz
In-Reply-To: <146b5375-5d70-bb65-74aa-5c19c1de7daf@mojatatu.com>
On 8/2/2017 5:01 AM, Jamal Hadi Salim wrote:
> On 17-08-01 08:57 PM, Nambiar, Amritha wrote:
>>
>> On 8/1/2017 3:15 AM, Jamal Hadi Salim wrote:
>>> On 17-07-31 08:36 PM, Amritha Nambiar wrote:
>
>>>>
>>>> # tc filter add dev eth0 protocol ip parent ffff: prio 1 flower\
>>>> dst_ip 192.168.1.1/32 ip_proto udp dst_port 22\
>>>> skip_sw indev eth0 action mirred ingress redirect dev eth0 tc 1
>>>>
>>>
>>> I think "queue 1" sounds better than "tc 1".
>>> "tc" is already a keyword in a few places (even within that declaration
>>> above).
>>
>> The idea is to redirect to a traffic class that has queues assigned to
>> it and not a single queue i.e. these are actually queue groups and not a
>> single queue. So may be "qgroup 1" or "tcqgroup 1" fits better.
>>
>
> Can you describe how this works? So the specific memeber of a
> a tcgroups show up on a specific rx DMA ring? If you only have
> 16 and 512 RX DMA rings - how does that work?
>
The Rx rule here is to redirect packets a specific traffic class. It is
the traffic class index (queue group index) that is offloaded to the
device. Queues were already configured for the traffic class by mapping
the queue counts and offsets and offloading this layout using the mqprio
framework. I had submitted a patch series for this which uses a new
hardware offload mode in mqprio to offload the TCs, the queue
configurations and the bandwidth rates for the TCs. So the 512 rings can
be mapped into 16 TCs using the mqprio offload mechanism, something like
this:
TC0 : 0 – 15
TC1: 16 – 31
TC2: 32 – 33
TC3: 34 – 49
.
.
.
TC15: 500 - 511
Now, once the TC configuration is prepared, it is just a matter of
hooking up the Rx rules to route traffic to the traffic class/queue
group. Rx queue selection within the queue group happens based on RSS.
> cheers,
> jamal
>
^ permalink raw reply
* Re: [PATCH net] tcp: avoid setting cwnd to invalid ssthresh after cwnd reduction states
From: Yuchung Cheng @ 2017-08-02 17:58 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Neal Cardwell, Eric Dumazet
In-Reply-To: <20170802.105136.1599120748083773522.davem@davemloft.net>
On Wed, Aug 2, 2017 at 10:51 AM, David Miller <davem@davemloft.net> wrote:
>
> From: Yuchung Cheng <ycheng@google.com>
> Date: Tue, 1 Aug 2017 13:22:32 -0700
>
> > If the sender switches the congestion control during ECN-triggered
> > cwnd-reduction state (CA_CWR), upon exiting recovery cwnd is set to
> > the ssthresh value calculated by the previous congestion control. If
> > the previous congestion control is BBR that always keep ssthresh
> > to TCP_INIFINITE_SSTHRESH, cwnd ends up being infinite. The safe
> > step is to avoid assigning invalid ssthresh value when recovery ends.
> >
> > Signed-off-by: Yuchung Cheng <ycheng@google.com>
> > Signed-off-by: Neal Cardwell <ncardwell@google.com>
>
> Applied, thanks.
>
> Is this a -stable candidate?
Yes it is. Thanks!
^ permalink raw reply
* [PATCH 2/2] qlcnic: add const to bin_attribute structure
From: Bhumika Goyal @ 2017-08-02 17:57 UTC (permalink / raw)
To: julia.lawall, kvalo, linux-wireless, netdev, linux-kernel,
harish.patil, manish.chopra, Dept-GELinuxNICDev
Cc: Bhumika Goyal
In-Reply-To: <1501696634-15765-1-git-send-email-bhumirks@gmail.com>
Add const to bin_attribute structure as it is only passed to the
functions sysfs_{remove/create}_bin_file. The corresponding
arguments are of type const, so declare the structure to be const.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
index 73027a6..82fcb83 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
@@ -1248,7 +1248,7 @@ static ssize_t qlcnic_83xx_sysfs_flash_write_handler(struct file *filp,
.write = qlcnic_sysfs_write_pm_config,
};
-static struct bin_attribute bin_attr_flash = {
+static const struct bin_attribute bin_attr_flash = {
.attr = {.name = "flash", .mode = (S_IRUGO | S_IWUSR)},
.size = 0,
.read = qlcnic_83xx_sysfs_flash_read_handler,
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] wlcore: add const to bin_attribute structure
From: Bhumika Goyal @ 2017-08-02 17:57 UTC (permalink / raw)
To: julia.lawall, kvalo, linux-wireless, netdev, linux-kernel,
harish.patil, manish.chopra, Dept-GELinuxNICDev
Cc: Bhumika Goyal
In-Reply-To: <1501696634-15765-1-git-send-email-bhumirks@gmail.com>
Add const to bin_attribute structure as it is only passed to the
functions sysfs_{remove/create}_bin_file. The corresponding arguments
are of type const, so declare the structure to be const.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
---
drivers/net/wireless/ti/wlcore/sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ti/wlcore/sysfs.c b/drivers/net/wireless/ti/wlcore/sysfs.c
index a9218e5..b72e210 100644
--- a/drivers/net/wireless/ti/wlcore/sysfs.c
+++ b/drivers/net/wireless/ti/wlcore/sysfs.c
@@ -138,7 +138,7 @@ static ssize_t wl1271_sysfs_read_fwlog(struct file *filp, struct kobject *kobj,
return len;
}
-static struct bin_attribute fwlog_attr = {
+static const struct bin_attribute fwlog_attr = {
.attr = {.name = "fwlog", .mode = S_IRUSR},
.read = wl1271_sysfs_read_fwlog,
};
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] drivers/net: add const to bin_attribute structures
From: Bhumika Goyal @ 2017-08-02 17:57 UTC (permalink / raw)
To: julia.lawall, kvalo, linux-wireless, netdev, linux-kernel,
harish.patil, manish.chopra, Dept-GELinuxNICDev
Cc: Bhumika Goyal
Declare bin_attribute structures as const.
Bhumika Goyal (2):
wlcore: add const to bin_attribute structure
qlcnic: add const to bin_attribute structure
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c | 2 +-
drivers/net/wireless/ti/wlcore/sysfs.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH 1/2] [for 4.13] net: qcom/emac: disable flow control autonegotiation by default
From: David Miller @ 2017-08-02 17:54 UTC (permalink / raw)
To: timur; +Cc: netdev
In-Reply-To: <1501623460-3575-2-git-send-email-timur@codeaurora.org>
From: Timur Tabi <timur@codeaurora.org>
Date: Tue, 1 Aug 2017 16:37:39 -0500
> The EMAC has a curious qwirk when RX flow control is enabled and the
> kernel hangs. With the kernel hung, the EMAC's RX queue soon fills.
> If RX flow control is enabled, the EMAC will then send a non-stop
> stream of pause frames until the system is reset. The EMAC does not
> have a built-in watchdog.
>
> In various tests, the pause frame stream sometimes overloads nearby
> switches, effectively disabling the network. Since the RX queue is
> large and the host processor is more than capable of handling incoming
> packets quickly, the only time the EMAC will send any pause frames is
> when the kernel is hung and unrecoverable.
>
> To avoid all these problems, we disable flow control autonegotiation
> by default, and only enable receiving pause frames.
>
> Cc: stable@vger.kernel.org # 4.11.x
> Signed-off-by: Timur Tabi <timur@codeaurora.org>
I've thought about this a lot and I don't like it for many reasons.
First of all, this hung kernel scenerio is completely bogus.
The ethernet chip may not have a proper watchdog for the pause frame
generation logic, but the whole kernel sure as hell does.
And if this kind of thing matters to the user, they will have a
software or hardware watchdog driver enabled to break out of this
situation.
Turning off flow control by default has so many negative ramifications
and don't try to convince me that users will be "aware" of this and
turn it back on.
They largely won't.
^ permalink raw reply
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported
From: Casey Leedom @ 2017-08-02 17:53 UTC (permalink / raw)
To: Ding Tianhong, Alexander Duyck
Cc: Alex Williamson, Sinan Kaya, ashok.raj@intel.com,
bhelgaas@google.com, helgaas@kernel.org, Michael Werner,
Ganesh GR, asit.k.mallick@intel.com, patrick.j.cramer@intel.com,
Suravee.Suthikulpanit@amd.com, Bob.Shaw@amd.com,
l.stach@pengutronix.de, amira@mellanox.com,
gabriele.paoloni@huawei.com, David.Laight@aculab.com,
jeffrey.t.kirsher@intel.com
In-Reply-To: <14218972-553d-eb60-0207-460ac7f4b064@huawei.com>
Okay, here you go. As you can tell, it's almost a trivial copy of the
cxgb4 patch.
By the way, I realized that we have yet another hole which is likely not
to be fixable. If we're dealing with a problematic Root Complex, and we
instantiate Virtual Functions and attach them to a Virtual Machine along
with an NVMe device which can deal with Relaxed Ordering TLPs, the VF driver
in the VM will be able to tell that it shouldn't attempt to send RO TLPs to
the RC because it will see the state of its own PCIe Capability Device
Control[Relaxed Ordering Enable] (a copy of the setting in the VF's
corresponding PF), but it won't be able to change that and send non-RO TLPs
to the RC, and RO TLPs to the NVMe device. Oh well.
I sure wish that the Intel guys would pop up with a hidden register change
for these problematic Intel RCs that perform poorly with RO TLPs. Their
silence has been frustrating.
Casey
----------
cxgb4vf Ethernet driver now queries PCIe configuration space to determine if
it can send TLPs to it with the Relaxed Ordering Attribute set.
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h b/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h
index 109bc63..08c6ddb 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h
@@ -408,6 +408,7 @@ enum { /* adapter flags */
USING_MSI = (1UL << 1),
USING_MSIX = (1UL << 2),
QUEUES_BOUND = (1UL << 3),
+ ROOT_NO_RELAXED_ORDERING = (1UL << 4),
};
/*
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
index ac7a150..59e7639 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
@@ -2888,6 +2888,24 @@ static int cxgb4vf_pci_probe(struct pci_dev *pdev,
*/
adapter->name = pci_name(pdev);
adapter->msg_enable = DFLT_MSG_ENABLE;
+
+ /* If possible, we use PCIe Relaxed Ordering Attribute to deliver
+ * Ingress Packet Data to Free List Buffers in order to allow for
+ * chipset performance optimizations between the Root Complex and
+ * Memory Controllers. (Messages to the associated Ingress Queue
+ * notifying new Packet Placement in the Free Lists Buffers will be
+ * send without the Relaxed Ordering Attribute thus guaranteeing that
+ * all preceding PCIe Transaction Layer Packets will be processed
+ * first.) But some Root Complexes have various issues with Upstream
+ * Transaction Layer Packets with the Relaxed Ordering Attribute set.
+ * The PCIe devices which under the Root Complexes will be cleared the
+ * Relaxed Ordering bit in the configuration space, So we check our
+ * PCIe configuration space to see if it's flagged with advice against
+ * using Relaxed Ordering.
+ */
+ if (!pcie_relaxed_ordering_supported(pdev))
+ adapter->flags |= ROOT_NO_RELAXED_ORDERING;
+
err = adap_init0(adapter);
if (err)
goto err_unmap_bar;
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
index e37dde2..05498e7 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
@@ -2205,6 +2205,7 @@ int t4vf_sge_alloc_rxq(struct adapter *adapter, struct sge_rspq *rspq,
struct port_info *pi = netdev_priv(dev);
struct fw_iq_cmd cmd, rpl;
int ret, iqandst, flsz = 0;
+ int relaxed = !(adapter->flags & ROOT_NO_RELAXED_ORDERING);
/*
* If we're using MSI interrupts and we're not initializing the
@@ -2300,6 +2301,8 @@ int t4vf_sge_alloc_rxq(struct adapter *adapter, struct sge_rspq *rspq,
cpu_to_be32(
FW_IQ_CMD_FL0HOSTFCMODE_V(SGE_HOSTFCMODE_NONE) |
FW_IQ_CMD_FL0PACKEN_F |
+ FW_IQ_CMD_FL0FETCHRO_V(relaxed) |
+ FW_IQ_CMD_FL0DATARO_V(relaxed) |
FW_IQ_CMD_FL0PADEN_F);
/* In T6, for egress queue type FL there is internal overhead
^ permalink raw reply related
* Re: [PATCH net] tcp: avoid setting cwnd to invalid ssthresh after cwnd reduction states
From: David Miller @ 2017-08-02 17:51 UTC (permalink / raw)
To: ycheng; +Cc: netdev, ncardwell, edumazet
In-Reply-To: <20170801202232.162176-1-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Tue, 1 Aug 2017 13:22:32 -0700
> If the sender switches the congestion control during ECN-triggered
> cwnd-reduction state (CA_CWR), upon exiting recovery cwnd is set to
> the ssthresh value calculated by the previous congestion control. If
> the previous congestion control is BBR that always keep ssthresh
> to TCP_INIFINITE_SSTHRESH, cwnd ends up being infinite. The safe
> step is to avoid assigning invalid ssthresh value when recovery ends.
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
Applied, thanks.
Is this a -stable candidate?
^ permalink raw reply
* Re: [Patch net-next] flow_dissector: remove unused functions
From: David Miller @ 2017-08-02 17:50 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, tom
In-Reply-To: <20170801201809.12922-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue, 1 Aug 2017 13:18:09 -0700
> They are introduced by commit f70ea018da06
> ("net: Add functions to get skb->hash based on flow structures")
> but never gets used in tree.
>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Yeah these can be reintroduced if we really end up needing them.
Applied, thanks.
^ permalink raw reply
* [PATCH] xfrm: policy: check policy direction value
From: Vladis Dronov @ 2017-08-02 17:50 UTC (permalink / raw)
To: Steffen Klassert, Herbert Xu, David S . Miller, netdev,
linux-kernel, stable
Cc: Vladis Dronov
The 'dir' parameter in xfrm_migrate() is a user-controlled byte which is used
as an array index. This can lead to an out-of-bound access, kernel lockup and
DoS. Add a check for the 'dir' value.
This fixes CVE-2017-11600.
References: https://bugzilla.redhat.com/show_bug.cgi?id=1474928
Fixes: 80c9abaabf42 ("[XFRM]: Extension for dynamic update of endpoint address(es)")
Cc: <stable@vger.kernel.org> # v2.6.21-rc1
Reported-by: "bo Zhang" <zhangbo5891001@gmail.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
---
net/xfrm/xfrm_policy.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index ff61d85..6f5a0dad 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -3308,9 +3308,15 @@ int xfrm_migrate(const struct xfrm_selector *sel, u8 dir, u8 type,
struct xfrm_state *x_new[XFRM_MAX_DEPTH];
struct xfrm_migrate *mp;
+ /* Stage 0 - sanity checks */
if ((err = xfrm_migrate_check(m, num_migrate)) < 0)
goto out;
+ if (dir >= XFRM_POLICY_MAX) {
+ err = -EINVAL;
+ goto out;
+ }
+
/* Stage 1 - find policy */
if ((pol = xfrm_migrate_policy_find(sel, dir, type, net)) == NULL) {
err = -ENOENT;
--
2.9.4
^ permalink raw reply related
* Re: [PATCH net] ibmvnic: Initialize SCRQ's during login renegotiation
From: David Miller @ 2017-08-02 17:48 UTC (permalink / raw)
To: tlfalcon; +Cc: netdev
In-Reply-To: <1501617876-17568-1-git-send-email-tlfalcon@linux.vnet.ibm.com>
From: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Date: Tue, 1 Aug 2017 15:04:36 -0500
> SCRQ resources are freed during renegotiation, but they are not
> re-allocated afterwards due to some changes in the initialization
> process. Fix that by re-allocating the memory after renegotation.
>
> SCRQ's can also be freed if a server capabilities request fails.
> If this were encountered during a device reset for example,
> SCRQ's may not be re-allocated. This operation is not necessary
> anymore so remove it.
>
> Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH 2/2] usb: qmi_wwan: add D-Link DWM-222 device ID
From: David Miller @ 2017-08-02 17:47 UTC (permalink / raw)
To: marcan; +Cc: bjorn, netdev, linux-usb, linux-kernel, stable
In-Reply-To: <20170801154544.1104-1-marcan@marcan.st>
From: Hector Martin <marcan@marcan.st>
Date: Wed, 2 Aug 2017 00:45:44 +0900
> Signed-off-by: Hector Martin <marcan@marcan.st>
Applied.
^ 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