* Re: Linux kernel error stack
From: Florian Westphal @ 2018-08-05 19:42 UTC (permalink / raw)
To: Satish Patel; +Cc: Florian Westphal, netdev
In-Reply-To: <CAPgF-fq7pa3Ai0iOCWnJqHCrFWdyfiGBmBo5JDDCHjzypYHLFA@mail.gmail.com>
Satish Patel <satish.txt@gmail.com> wrote:
> Thanks Florian,
>
> FYI, I don't have any CHECKSUM configure in my iptables,
You have, according to WARN stacktrace you provided.
iptables-save -c
ip6tables-save -c
^ permalink raw reply
* [PATCH net-next] tc-testing: remove duplicate spaces in skbedit match patterns
From: Vlad Buslov @ 2018-08-05 19:37 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs, Vlad Buslov
Match patterns for some skbedit tests contain duplicate whitespace that is
not present in actual tc output. This causes tests to fail because they
can't match required action, even when it was successfully created.
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
---
.../tc-testing/tc-tests/actions/skbedit.json | 26 +++++++++++-----------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/tools/testing/selftests/tc-testing/tc-tests/actions/skbedit.json b/tools/testing/selftests/tc-testing/tc-tests/actions/skbedit.json
index 37ecc2716fee..5aaf593b914a 100644
--- a/tools/testing/selftests/tc-testing/tc-tests/actions/skbedit.json
+++ b/tools/testing/selftests/tc-testing/tc-tests/actions/skbedit.json
@@ -17,7 +17,7 @@
"cmdUnderTest": "$TC actions add action skbedit mark 1",
"expExitCode": "0",
"verifyCmd": "$TC actions list action skbedit",
- "matchPattern": "action order [0-9]*: skbedit mark 1",
+ "matchPattern": "action order [0-9]*: skbedit mark 1",
"matchCount": "1",
"teardown": [
"$TC actions flush action skbedit"
@@ -65,7 +65,7 @@
"cmdUnderTest": "$TC actions add action skbedit prio 99",
"expExitCode": "0",
"verifyCmd": "$TC actions list action skbedit",
- "matchPattern": "action order [0-9]*: skbedit priority :99",
+ "matchPattern": "action order [0-9]*: skbedit priority :99",
"matchCount": "1",
"teardown": [
"$TC actions flush action skbedit"
@@ -113,7 +113,7 @@
"cmdUnderTest": "$TC actions add action skbedit queue_mapping 909",
"expExitCode": "0",
"verifyCmd": "$TC actions list action skbedit",
- "matchPattern": "action order [0-9]*: skbedit queue_mapping 909",
+ "matchPattern": "action order [0-9]*: skbedit queue_mapping 909",
"matchCount": "1",
"teardown": [
"$TC actions flush action skbedit"
@@ -161,7 +161,7 @@
"cmdUnderTest": "$TC actions add action skbedit ptype host",
"expExitCode": "0",
"verifyCmd": "$TC actions list action skbedit",
- "matchPattern": "action order [0-9]*: skbedit ptype host",
+ "matchPattern": "action order [0-9]*: skbedit ptype host",
"matchCount": "1",
"teardown": [
"$TC actions flush action skbedit"
@@ -185,7 +185,7 @@
"cmdUnderTest": "$TC actions add action skbedit ptype otherhost",
"expExitCode": "0",
"verifyCmd": "$TC actions list action skbedit",
- "matchPattern": "action order [0-9]*: skbedit ptype otherhost",
+ "matchPattern": "action order [0-9]*: skbedit ptype otherhost",
"matchCount": "1",
"teardown": [
"$TC actions flush action skbedit"
@@ -233,7 +233,7 @@
"cmdUnderTest": "$TC actions add action skbedit ptype host pipe index 11",
"expExitCode": "0",
"verifyCmd": "$TC actions get action skbedit index 11",
- "matchPattern": "action order [0-9]*: skbedit ptype host pipe.*index 11 ref",
+ "matchPattern": "action order [0-9]*: skbedit ptype host pipe.*index 11 ref",
"matchCount": "1",
"teardown": [
"$TC actions flush action skbedit"
@@ -257,7 +257,7 @@
"cmdUnderTest": "$TC actions add action skbedit mark 56789 reclassify index 90",
"expExitCode": "0",
"verifyCmd": "$TC actions get action skbedit index 90",
- "matchPattern": "action order [0-9]*: skbedit mark 56789 reclassify.*index 90 ref",
+ "matchPattern": "action order [0-9]*: skbedit mark 56789 reclassify.*index 90 ref",
"matchCount": "1",
"teardown": [
"$TC actions flush action skbedit"
@@ -281,7 +281,7 @@
"cmdUnderTest": "$TC actions add action skbedit queue_mapping 3 pass index 271",
"expExitCode": "0",
"verifyCmd": "$TC actions get action skbedit index 271",
- "matchPattern": "action order [0-9]*: skbedit queue_mapping 3 pass.*index 271 ref",
+ "matchPattern": "action order [0-9]*: skbedit queue_mapping 3 pass.*index 271 ref",
"matchCount": "1",
"teardown": [
"$TC actions flush action skbedit"
@@ -305,7 +305,7 @@
"cmdUnderTest": "$TC actions add action skbedit queue_mapping 3 drop index 271",
"expExitCode": "0",
"verifyCmd": "$TC actions get action skbedit index 271",
- "matchPattern": "action order [0-9]*: skbedit queue_mapping 3 drop.*index 271 ref",
+ "matchPattern": "action order [0-9]*: skbedit queue_mapping 3 drop.*index 271 ref",
"matchCount": "1",
"teardown": [
"$TC actions flush action skbedit"
@@ -329,7 +329,7 @@
"cmdUnderTest": "$TC actions add action skbedit priority 8 jump 9 index 2",
"expExitCode": "0",
"verifyCmd": "$TC actions get action skbedit index 2",
- "matchPattern": "action order [0-9]*: skbedit priority :8 jump 9.*index 2 ref",
+ "matchPattern": "action order [0-9]*: skbedit priority :8 jump 9.*index 2 ref",
"matchCount": "1",
"teardown": [
"$TC actions flush action skbedit"
@@ -353,7 +353,7 @@
"cmdUnderTest": "$TC actions add action skbedit priority 16 continue index 32",
"expExitCode": "0",
"verifyCmd": "$TC actions get action skbedit index 32",
- "matchPattern": "action order [0-9]*: skbedit priority :16 continue.*index 32 ref",
+ "matchPattern": "action order [0-9]*: skbedit priority :16 continue.*index 32 ref",
"matchCount": "1",
"teardown": [
"$TC actions flush action skbedit"
@@ -377,7 +377,7 @@
"cmdUnderTest": "$TC actions add action skbedit priority 16 continue index 32 cookie deadbeef",
"expExitCode": "0",
"verifyCmd": "$TC actions get action skbedit index 32",
- "matchPattern": "action order [0-9]*: skbedit priority :16 continue.*index 32 ref.*cookie deadbeef",
+ "matchPattern": "action order [0-9]*: skbedit priority :16 continue.*index 32 ref.*cookie deadbeef",
"matchCount": "1",
"teardown": [
"$TC actions flush action skbedit"
@@ -405,7 +405,7 @@
"cmdUnderTest": "$TC actions list action skbedit",
"expExitCode": "0",
"verifyCmd": "$TC actions list action skbedit",
- "matchPattern": "action order [0-9]*: skbedit",
+ "matchPattern": "action order [0-9]*: skbedit",
"matchCount": "4",
"teardown": [
"$TC actions flush action skbedit"
--
2.7.5
^ permalink raw reply related
* [PATCH net-next] tc-testing: remove duplicate spaces in connmark match patterns
From: Vlad Buslov @ 2018-08-05 19:36 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs, Vlad Buslov
Match patterns for some connmark tests contain duplicate whitespace that is
not present in actual tc output. This causes tests to fail because they
can't match required action, even when it was successfully created.
Fixes: 1dad0f9ffff7 ("tc-testing: add connmark action tests")
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
---
.../tc-testing/tc-tests/actions/connmark.json | 24 +++++++++++-----------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/tools/testing/selftests/tc-testing/tc-tests/actions/connmark.json b/tools/testing/selftests/tc-testing/tc-tests/actions/connmark.json
index 70952bd98ff9..13147a1f5731 100644
--- a/tools/testing/selftests/tc-testing/tc-tests/actions/connmark.json
+++ b/tools/testing/selftests/tc-testing/tc-tests/actions/connmark.json
@@ -17,7 +17,7 @@
"cmdUnderTest": "$TC actions add action connmark",
"expExitCode": "0",
"verifyCmd": "$TC actions list action connmark",
- "matchPattern": "action order [0-9]+: connmark zone 0 pipe",
+ "matchPattern": "action order [0-9]+: connmark zone 0 pipe",
"matchCount": "1",
"teardown": [
"$TC actions flush action connmark"
@@ -41,7 +41,7 @@
"cmdUnderTest": "$TC actions add action connmark pass index 1",
"expExitCode": "0",
"verifyCmd": "$TC actions get action connmark index 1",
- "matchPattern": "action order [0-9]+: connmark zone 0 pass.*index 1 ref",
+ "matchPattern": "action order [0-9]+: connmark zone 0 pass.*index 1 ref",
"matchCount": "1",
"teardown": [
"$TC actions flush action connmark"
@@ -65,7 +65,7 @@
"cmdUnderTest": "$TC actions add action connmark drop index 100",
"expExitCode": "0",
"verifyCmd": "$TC actions get action connmark index 100",
- "matchPattern": "action order [0-9]+: connmark zone 0 drop.*index 100 ref",
+ "matchPattern": "action order [0-9]+: connmark zone 0 drop.*index 100 ref",
"matchCount": "1",
"teardown": [
"$TC actions flush action connmark"
@@ -89,7 +89,7 @@
"cmdUnderTest": "$TC actions add action connmark pipe index 455",
"expExitCode": "0",
"verifyCmd": "$TC actions get action connmark index 455",
- "matchPattern": "action order [0-9]+: connmark zone 0 pipe.*index 455 ref",
+ "matchPattern": "action order [0-9]+: connmark zone 0 pipe.*index 455 ref",
"matchCount": "1",
"teardown": [
"$TC actions flush action connmark"
@@ -113,7 +113,7 @@
"cmdUnderTest": "$TC actions add action connmark reclassify index 7",
"expExitCode": "0",
"verifyCmd": "$TC actions list action connmark",
- "matchPattern": "action order [0-9]+: connmark zone 0 reclassify.*index 7 ref",
+ "matchPattern": "action order [0-9]+: connmark zone 0 reclassify.*index 7 ref",
"matchCount": "1",
"teardown": [
"$TC actions flush action connmark"
@@ -137,7 +137,7 @@
"cmdUnderTest": "$TC actions add action connmark continue index 17",
"expExitCode": "0",
"verifyCmd": "$TC actions list action connmark",
- "matchPattern": "action order [0-9]+: connmark zone 0 continue.*index 17 ref",
+ "matchPattern": "action order [0-9]+: connmark zone 0 continue.*index 17 ref",
"matchCount": "1",
"teardown": [
"$TC actions flush action connmark"
@@ -161,7 +161,7 @@
"cmdUnderTest": "$TC actions add action connmark jump 10 index 17",
"expExitCode": "0",
"verifyCmd": "$TC actions list action connmark",
- "matchPattern": "action order [0-9]+: connmark zone 0 jump 10.*index 17 ref",
+ "matchPattern": "action order [0-9]+: connmark zone 0 jump 10.*index 17 ref",
"matchCount": "1",
"teardown": [
"$TC actions flush action connmark"
@@ -185,7 +185,7 @@
"cmdUnderTest": "$TC actions add action connmark zone 100 pipe index 1",
"expExitCode": "0",
"verifyCmd": "$TC actions get action connmark index 1",
- "matchPattern": "action order [0-9]+: connmark zone 100 pipe.*index 1 ref",
+ "matchPattern": "action order [0-9]+: connmark zone 100 pipe.*index 1 ref",
"matchCount": "1",
"teardown": [
"$TC actions flush action connmark"
@@ -209,7 +209,7 @@
"cmdUnderTest": "$TC actions add action connmark zone 65536 reclassify index 21",
"expExitCode": "255",
"verifyCmd": "$TC actions get action connmark index 1",
- "matchPattern": "action order [0-9]+: connmark zone 65536 reclassify.*index 21 ref",
+ "matchPattern": "action order [0-9]+: connmark zone 65536 reclassify.*index 21 ref",
"matchCount": "0",
"teardown": [
"$TC actions flush action connmark"
@@ -233,7 +233,7 @@
"cmdUnderTest": "$TC actions add action connmark zone 655 unsupp_arg pass index 2",
"expExitCode": "255",
"verifyCmd": "$TC actions get action connmark index 2",
- "matchPattern": "action order [0-9]+: connmark zone 655 unsupp_arg pass.*index 2 ref",
+ "matchPattern": "action order [0-9]+: connmark zone 655 unsupp_arg pass.*index 2 ref",
"matchCount": "0",
"teardown": [
"$TC actions flush action connmark"
@@ -258,7 +258,7 @@
"cmdUnderTest": "$TC actions replace action connmark zone 555 reclassify index 555",
"expExitCode": "0",
"verifyCmd": "$TC actions get action connmark index 555",
- "matchPattern": "action order [0-9]+: connmark zone 555 reclassify.*index 555 ref",
+ "matchPattern": "action order [0-9]+: connmark zone 555 reclassify.*index 555 ref",
"matchCount": "1",
"teardown": [
"$TC actions flush action connmark"
@@ -282,7 +282,7 @@
"cmdUnderTest": "$TC actions add action connmark zone 555 pipe index 5 cookie aabbccddeeff112233445566778800a1",
"expExitCode": "0",
"verifyCmd": "$TC actions get action connmark index 5",
- "matchPattern": "action order [0-9]+: connmark zone 555 pipe.*index 5 ref.*cookie aabbccddeeff112233445566778800a1",
+ "matchPattern": "action order [0-9]+: connmark zone 555 pipe.*index 5 ref.*cookie aabbccddeeff112233445566778800a1",
"matchCount": "1",
"teardown": [
"$TC actions flush action connmark"
--
2.7.5
^ permalink raw reply related
* [PATCH net-next] tc-testing: flush gact actions on test teardown
From: Vlad Buslov @ 2018-08-05 19:36 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs, Vlad Buslov
Test 6fb4 creates one mirred and one pipe action, but only flushes mirred
on teardown. Leaking pipe action causes failures in other tests.
Add additional teardown command to also flush gact actions.
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
---
tools/testing/selftests/tc-testing/tc-tests/actions/mirred.json | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/tc-testing/tc-tests/actions/mirred.json b/tools/testing/selftests/tc-testing/tc-tests/actions/mirred.json
index 6e4edfae1799..db49fd0f8445 100644
--- a/tools/testing/selftests/tc-testing/tc-tests/actions/mirred.json
+++ b/tools/testing/selftests/tc-testing/tc-tests/actions/mirred.json
@@ -44,7 +44,8 @@
"matchPattern": "action order [0-9]*: mirred \\(Egress Redirect to device lo\\).*index 2 ref",
"matchCount": "1",
"teardown": [
- "$TC actions flush action mirred"
+ "$TC actions flush action mirred",
+ "$TC actions flush action gact"
]
},
{
--
2.7.5
^ permalink raw reply related
* [PATCH net-next] tc-testing: fix ip address in u32 test
From: Vlad Buslov @ 2018-08-05 19:35 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs, Vlad Buslov
Fix expected ip address to actually match configured ip address.
Fix test to expect single matched filter.
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
---
tools/testing/selftests/tc-testing/tc-tests/filters/tests.json | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/tc-testing/tc-tests/filters/tests.json b/tools/testing/selftests/tc-testing/tc-tests/filters/tests.json
index 5fa02d86b35f..99a5ffca1088 100644
--- a/tools/testing/selftests/tc-testing/tc-tests/filters/tests.json
+++ b/tools/testing/selftests/tc-testing/tc-tests/filters/tests.json
@@ -12,8 +12,8 @@
"cmdUnderTest": "$TC filter add dev $DEV1 parent ffff: protocol ip prio 1 u32 match ip src 127.0.0.1/32 flowid 1:1 action ok",
"expExitCode": "0",
"verifyCmd": "$TC filter show dev $DEV1 parent ffff:",
- "matchPattern": "match 7f000002/ffffffff at 12",
- "matchCount": "0",
+ "matchPattern": "match 7f000001/ffffffff at 12",
+ "matchCount": "1",
"teardown": [
"$TC qdisc del dev $DEV1 ingress"
]
--
2.7.5
^ permalink raw reply related
* [RFC] weirdness in cxgb3_main.c:init_tp_parity()
From: Al Viro @ 2018-08-05 17:46 UTC (permalink / raw)
To: Santosh Raspatur; +Cc: netdev
for (i = 0; i < 2048; i++) {
...
req->l2t_idx = htonl(V_L2T_W_IDX(i));
...
in there is very odd; l2t_idx is a 16bit field, and
#define V_L2T_W_IDX(x) ((x) << S_L2T_W_IDX)
#define S_L2T_W_IDX 0
IOW, we are taking htonl(something in range 0..2047) and
shove it into 16bit field. Which would, on a little-endian
host, be a fancy way of spelling
req->l2t_idx = 0;
What's the intended behaviour there? I'm not familiar with
the hardware in question; this smells like a typoed
req->l2t_idx = htons(...)
but how does the current code manage to work (i.e. does
anything even care about the value stored there)? It's not
a big-endian-only driver, after all...
^ permalink raw reply
* [endianness bug] cxgb4: mk_act_open_req() buggers ->{local,peer}_ip on big-endian hosts
From: Al Viro @ 2018-08-05 17:22 UTC (permalink / raw)
To: Kumar Sanghvi; +Cc: Rahul Lakkireddy, David Miller, netdev
Unlike fs.val.lport and fs.val.fport, cxgb4_process_flow_match()
sets fs.val.{l,f}ip to net-endian values without conversion - they come
straight from flow_dissector_key_ipv4_addrs ->dst and ->src resp. So
the assignment in mk_act_open_req() ought to be a straigh copy.
As far as I know, T4 PCIe cards do exist, so it's not as if that
thing could only be found on little-endian systems...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
index 00fc5f1afb1d..7dddb9e748b8 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
@@ -1038,10 +1038,8 @@ static void mk_act_open_req(struct filter_entry *f, struct sk_buff *skb,
OPCODE_TID(req) = htonl(MK_OPCODE_TID(CPL_ACT_OPEN_REQ, qid_filterid));
req->local_port = cpu_to_be16(f->fs.val.lport);
req->peer_port = cpu_to_be16(f->fs.val.fport);
- req->local_ip = f->fs.val.lip[0] | f->fs.val.lip[1] << 8 |
- f->fs.val.lip[2] << 16 | f->fs.val.lip[3] << 24;
- req->peer_ip = f->fs.val.fip[0] | f->fs.val.fip[1] << 8 |
- f->fs.val.fip[2] << 16 | f->fs.val.fip[3] << 24;
+ memcpy(&req->local_ip, f->fs.val.lip, 4);
+ memcpy(&req->peer_ip, f->fs.val.fip, 4);
req->opt0 = cpu_to_be64(NAGLE_V(f->fs.newvlan == VLAN_REMOVE ||
f->fs.newvlan == VLAN_REWRITE) |
DELACK_V(f->fs.hitcnts) |
^ permalink raw reply related
* pull-request: wireless-drivers-next 2018-08-05
From: Kalle Valo @ 2018-08-05 17:07 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
a pull request to net-next tree for 4.19. If the merge window doesn't
open today I'm planning to submit one more pull request later next week.
Please let me know if you have any problems.
Kalle
The following changes since commit aea5f654e6b78a0c976f7a25950155932c77a53f:
net/sched: add skbprio scheduler (2018-07-24 14:44:00 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2018-08-05
for you to fetch changes up to e800a333135bef633ffb21bdd471b8ffc491db7b:
mt76x0: rename trace symbols (2018-08-04 09:06:15 +0300)
----------------------------------------------------------------
wireless-drivers-next patches for 4.19
This time a bigger pull request as we have two new Mediatek drivers
MT76x2u (CONFIG_MT76x2U) and MT76x0U (CONFIG_MT76x0U). Also iwlwifi got
support for the new IEEE 802.11ax standard, the successor for
802.11ac. And naturally smaller new features and bugfixes all over.
Major changes:
wcn36xx
* fix WEP in client mode
wil6210
* add support for Talyn-MB (Talyn ver 2.0) device
* add support for enhanced DMA firmware feature
iwlwifi
* implement 802.11ax D2.0
* support for the new 22560 device family
* new PCI IDs for 22000 and 22560
qtnfmac
* implement cfg80211 power management callback
* enable multiple SSIDs scan support
* qtnfmac: implement basic WoWLAN support
mt7601u
* fall back to software encryption for hw unsupported ciphers
* enable 802.11 Management Frame Protection (MFP)
mt76
* support setting RTS threshold
* add USB support
* add support for MT76x2u devices
* add support for MT76x0U devices
mwifiex
* allow user space to set all other IEs except WMM IE
rsi
* add firmware support for AP+BT dual mode
----------------------------------------------------------------
Alagu Sankar (3):
ath10k: sdio: use same endpoint id for all packets in a bundle
ath10k: sdio: allocate correct size for RECV_1MORE_BLOCK rx packets
ath10k: sdio: set skb len for all rx packets
Amol Hanwate (3):
rsi: Correct RSI_NEEDED_HEADROOM in mac80211_attach.
rsi: fill rx_params only once.
rsi: move init_done flag to end of rsi_91x_init().
Andrey Shevchenko (1):
qtnfmac: enable multiple SSIDs scan support
Arnd Bergmann (1):
ath9k: use timespec64 for tsf_ts
Ben Greear (1):
ath10k: protect ath10k_htt_rx_ring_free with rx_ring.lock
Bob Copeland (1):
ath10k: use locked skb_dequeue for rx completions
Colin Ian King (4):
airo: remove unused variables len and dev and clean up formatting
ipw2x00: remove redundant variables len, ret, reason and crypt
iwlegacy: remove several redundant variables
ray_cs: remove redundant pointer 'p'
Daniel Mack (1):
wcn36xx: drop unnecessary initialization of variables
Davide Caratti (1):
mt7601u: expose 802.11w support
Emmanuel Grumbach (1):
iwlwifi: pcie: don't access periphery registers when not available
Erik Stromdahl (3):
ath10k: fix bug in masking of TID value
ath10k: rename HTC_HOST_MAX_MSG_PER_BUNDLE define
ath10k: replace hardcoded constant with define
Ganapathi Bhat (3):
mwifiex: replace rx_pkt_lock by rx_reorder_tbl_lock
mwifiex: restructure rx_reorder_tbl_lock usage
mwifiex: use atomic bitops to represent adapter status variables
Ganapathi Raju (1):
rsi: fix for 40MHZ connection issue.
Gidon Studinski (3):
wil6210: add support for enhanced DMA structures
wil6210: initialize TX and RX enhanced DMA rings
wil6210: add support for enhanced DMA RX data flows
Golan Ben Ami (17):
iwlwifi: allow different csr flags for different device families
iwlwifi: introduce device family 22560
iwlwifi: pcie: allocate and free rx cr's and tr's tails
iwlwifi: pcie: support context information for 22560 devices
iwlwifi: pcie: update bytes in the byte count table
iwlwifi: pcie: start early debug for 22560 devices
iwlwifi: update gen3 interrupts - sw error and image response
iwlwifi: cancel the injective function between hw pointers to tfd entry index
iwlwifi: support multiple tfd queue max sizes for different devices
iwlwifi: support new tx api
iwlwifi: introduce new rx structures used by 22560 RFH
iwlwifi: update registers changed for 22560 devices
iwlwifi: pcie: support 2k rx buffers
iwlwifi: pcie: support rx structures for 22560 devices
iwlwifi: support new rx_mpdu_desc api
iwlwifi: hard code power save mode to CAM for 22560 devices
iwlwifi: move some msix and rx functions to a common place
H. Nikolaus Schaller (1):
wlcore: remove duplicate \n for some warnings
Jia-Ju Bai (2):
atmel: Replace mdelay() with msleep() in probe_atmel_card()
rtl818x: Replace mdelay() with msleep() in rtl8225se_rf_init
Johannes Berg (1):
iwlwifi: 22000 devices: restrict to HT A-MPDU size
Kalle Valo (3):
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Merge tag 'iwlwifi-next-for-kalle-2018-07-26' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge tag 'iwlwifi-next-for-kalle-2018-08-02' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Loic Poulain (4):
wcn36xx: Fix WEP104 encryption type
wcn36xx: Track associated stations
wcn36xx: Fix WEP encryption
wlcore: Set rx_status boottime_ns field on rx
Lorenzo Bianconi (22):
mt7601u: use sw encryption for hw unsupported ciphers
mt76x2: add frame protection support
mt76x2: fix CCK protection control frame rate
mt76: move MT_TXD_INFO, MT_MCU_MSG and MT_RX_FCE_INFO defs in dma.h
mt76x2: move mt76x2_fw_header and mt76x2_patch_header definitions in mcu.h
mt76x2: move utility routines in mt76x2.h
mt76x2: introduce mt76x2_init_device routine
mt76x2: move interface_modes definition in mt76x2_init
mt76x2: introduce mt76x2_mac_load_tx_status routine
mt76x2: add napi struct to mt76_rx_poll_complete/mt76_rx_complete signatures
mt76x2: add buffer len to mt76x2_mac_write_txwi signature
mt76: rename mt76_tx_queue_skb in mt76_dma_tx_queue_skb
mt76: introduce tx_queue_skb function pointer in mt76_bus_ops
mt76: introduce mt76x2-common module
mt76: add mt76x2_tx_common to mt76x2-common module
mt76: add mt76x2_mac_common to mt76x2-common module
mt76: add mt76x2_init_common to mt76x2-common module
mt76: add mt76x2_common to mt76x2-common module
mt76: add mt76x2_phy_common to mt76x2-common module
mt76: move mt76x2_debugfs in mt76-common module
mt76: add usb support to mt76 layer
mt76: add driver code for MT76x2u based devices
Luca Coelho (9):
iwlwifi: fw: add FW APIs for HE
iwlwifi: add support for IEEE802.11ax
iwlwifi: add module parameter to disable 802.11ax
iwlwifi: mvm: add radiotap data for HE
iwlwifi: add support for 22560 devices
iwlwifi: pcie: add a bunch of PCI IDs for 22000 and 22560
iwlwifi: d3: disable dbg recording before entering D3
iwlwifi: mvm: remove dead gscan code
iwlwifi: pcie: include tcp.h implicitly
Maya Erez (5):
wil6210: add support for Talyn-MB (Talyn ver 2.0) device
wil6210: add support for enhanced DMA TX data flows
wil6210: add support for enhanced DMA debugfs
wil6210: add support for Talyn-MB boot flow
wil6210: remove crash dump collection from OTP section
Niklas Cassel (1):
ath10k: transmit queued frames after processing rx packets
Rafał Miłecki (1):
brcmfmac: specify some features per firmware version
Roman Stratiienko (1):
mwifiex: Fix skipped vendor specific IEs
Sara Sharon (6):
iwlwifi: pcie: unionize used bd and completion descriptor
iwlwifi: pcie: move rxb retrieval to a helper function
iwlwifi: trans: add a new op for getting DMA data
iwlwifi: mvm: configure multi RX queue
Revert "iwlwifi: implement fseq version mismatch warning"
iwlwifi: pcie: split tx to amsdu and non amsdu
Sebastian Andrzej Siewior (1):
ath9k: use irqsave() in USB's complete callback
Sergei Maksimenko (1):
qtnfmac: implement cfg80211 power management callback
Sergey Matyukevich (1):
qtnfmac: implement basic WoWLAN support
Shahar S Matityahu (1):
iwlwifi: allow masking out memory areas from the fw dump
Siva Rebbagondla (6):
rsi: fix for low throughput issue
rsi: fix for WoWLAN wakeup in security mode.
rsi: optimize virtual interfaces
rsi: remove redundant device ids
rsi: remove redundant flash_content variable
rsi: add firmware support for AP+BT dual mode
Stanislaw Gruszka (16):
mt76x0: core files
mt76x0: mac files
mt76x0: usb files
mt76x0: mcu files
mt76x0: phy files
mt76x0: init files
mt76x0: eeprom files
mt76x0: trace and debugfs files
mt76x0: dma and tx files
mt76x0: main file
mt76: add more states
mt76: Kconfig and Makefile for mt76x0 driver
mt76x0: disable HW before probe
mt76x0: load firmware from mediatek subdir
mt76x0: rename mt76_* functions
mt76x0: rename trace symbols
YueHaibing (3):
atmel: hide unused procfs helpers
hostap: hide unused procfs helpers
rt2x00: remove redundant functions rt2x00mac_sta_{add/remove}
Zhi Chen (2):
ath10k: fix scan crash due to incorrect length calculation
ath10k: fix tlv 5ghz channel missing issue
drivers/net/wireless/ath/ath10k/htc.c | 4 +-
drivers/net/wireless/ath/ath10k/htc.h | 4 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 13 +-
drivers/net/wireless/ath/ath10k/htt_tx.c | 2 +-
drivers/net/wireless/ath/ath10k/mac.c | 5 +-
drivers/net/wireless/ath/ath10k/sdio.c | 16 +-
drivers/net/wireless/ath/ath10k/sdio.h | 8 +-
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 10 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 4 +-
drivers/net/wireless/ath/ath9k/channel.c | 14 +-
drivers/net/wireless/ath/ath9k/hif_usb.c | 7 +-
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 9 +-
drivers/net/wireless/ath/ath9k/hw.c | 10 +-
drivers/net/wireless/ath/ath9k/hw.h | 2 +-
drivers/net/wireless/ath/ath9k/main.c | 4 +-
drivers/net/wireless/ath/ath9k/wmi.c | 11 +-
drivers/net/wireless/ath/wcn36xx/main.c | 30 +-
drivers/net/wireless/ath/wcn36xx/smd.c | 95 +-
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 3 +
drivers/net/wireless/ath/wil6210/Makefile | 1 +
drivers/net/wireless/ath/wil6210/cfg80211.c | 12 +-
drivers/net/wireless/ath/wil6210/debugfs.c | 490 +++++-
drivers/net/wireless/ath/wil6210/ethtool.c | 2 +-
drivers/net/wireless/ath/wil6210/interrupt.c | 225 ++-
drivers/net/wireless/ath/wil6210/main.c | 360 ++++-
drivers/net/wireless/ath/wil6210/netdev.c | 73 +-
drivers/net/wireless/ath/wil6210/pcie_bus.c | 59 +-
drivers/net/wireless/ath/wil6210/pm.c | 6 +-
drivers/net/wireless/ath/wil6210/rx_reorder.c | 26 +-
drivers/net/wireless/ath/wil6210/trace.h | 59 +
drivers/net/wireless/ath/wil6210/txrx.c | 649 ++++----
drivers/net/wireless/ath/wil6210/txrx.h | 105 +-
drivers/net/wireless/ath/wil6210/txrx_edma.c | 1598 ++++++++++++++++++++
drivers/net/wireless/ath/wil6210/txrx_edma.h | 562 +++++++
drivers/net/wireless/ath/wil6210/wil6210.h | 228 ++-
drivers/net/wireless/ath/wil6210/wil_crash_dump.c | 5 +-
drivers/net/wireless/ath/wil6210/wmi.c | 502 +++++-
drivers/net/wireless/ath/wil6210/wmi.h | 167 +-
drivers/net/wireless/atmel/atmel.c | 4 +-
.../wireless/broadcom/brcm80211/brcmfmac/feature.c | 38 +
drivers/net/wireless/cisco/airo.c | 8 +-
drivers/net/wireless/cisco/airo_cs.c | 3 -
drivers/net/wireless/intel/ipw2x00/ipw2100.c | 7 -
drivers/net/wireless/intel/ipw2x00/libipw_wx.c | 2 -
drivers/net/wireless/intel/iwlegacy/3945-mac.c | 10 -
drivers/net/wireless/intel/iwlegacy/3945.c | 2 -
drivers/net/wireless/intel/iwlegacy/4965-mac.c | 6 -
drivers/net/wireless/intel/iwlwifi/Makefile | 4 +-
drivers/net/wireless/intel/iwlwifi/cfg/2000.c | 2 +
drivers/net/wireless/intel/iwlwifi/cfg/22000.c | 163 +-
drivers/net/wireless/intel/iwlwifi/cfg/5000.c | 1 +
drivers/net/wireless/intel/iwlwifi/cfg/6000.c | 3 +
drivers/net/wireless/intel/iwlwifi/cfg/7000.c | 1 +
drivers/net/wireless/intel/iwlwifi/cfg/8000.c | 1 +
drivers/net/wireless/intel/iwlwifi/cfg/9000.c | 1 +
drivers/net/wireless/intel/iwlwifi/fw/api/alive.h | 18 +-
.../net/wireless/intel/iwlwifi/fw/api/commands.h | 10 +-
.../net/wireless/intel/iwlwifi/fw/api/datapath.h | 12 +
drivers/net/wireless/intel/iwlwifi/fw/api/mac.h | 172 +++
.../net/wireless/intel/iwlwifi/fw/api/nvm-reg.h | 4 +-
drivers/net/wireless/intel/iwlwifi/fw/api/rs.h | 36 +-
drivers/net/wireless/intel/iwlwifi/fw/api/rx.h | 250 ++-
drivers/net/wireless/intel/iwlwifi/fw/api/tx.h | 25 +
drivers/net/wireless/intel/iwlwifi/fw/common_rx.c | 88 --
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 284 ++--
drivers/net/wireless/intel/iwlwifi/fw/file.h | 40 +-
drivers/net/wireless/intel/iwlwifi/fw/img.h | 37 +-
drivers/net/wireless/intel/iwlwifi/fw/runtime.h | 3 -
drivers/net/wireless/intel/iwlwifi/fw/smem.c | 4 +-
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 7 +-
.../wireless/intel/iwlwifi/iwl-context-info-gen3.h | 286 ++++
.../net/wireless/intel/iwlwifi/iwl-context-info.h | 5 +
drivers/net/wireless/intel/iwlwifi/iwl-csr.h | 5 +
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 74 +-
.../net/wireless/intel/iwlwifi/iwl-eeprom-parse.c | 8 +-
drivers/net/wireless/intel/iwlwifi/iwl-fh.h | 28 +-
drivers/net/wireless/intel/iwlwifi/iwl-modparams.h | 12 +-
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 110 ++
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 29 +
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 7 +
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 8 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 50 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 4 +
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 205 ++-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 23 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c | 44 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 39 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs.h | 21 +-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 364 ++++-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 8 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 6 +-
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 48 +-
.../wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c | 207 +++
.../net/wireless/intel/iwlwifi/pcie/ctxt-info.c | 62 +-
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 27 +-
drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 294 +++-
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 388 +++--
.../net/wireless/intel/iwlwifi/pcie/trans-gen2.c | 11 +-
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 235 +--
drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c | 192 ++-
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 92 +-
drivers/net/wireless/intersil/hostap/hostap_ap.c | 8 +-
drivers/net/wireless/intersil/hostap/hostap_hw.c | 17 +-
drivers/net/wireless/intersil/hostap/hostap_proc.c | 10 +-
drivers/net/wireless/marvell/mwifiex/11n.c | 5 +-
.../net/wireless/marvell/mwifiex/11n_rxreorder.c | 95 +-
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 3 +-
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 34 +-
drivers/net/wireless/marvell/mwifiex/debugfs.c | 2 +-
drivers/net/wireless/marvell/mwifiex/ie.c | 8 +-
drivers/net/wireless/marvell/mwifiex/init.c | 5 +-
drivers/net/wireless/marvell/mwifiex/main.c | 33 +-
drivers/net/wireless/marvell/mwifiex/main.h | 17 +-
drivers/net/wireless/marvell/mwifiex/pcie.c | 12 +-
drivers/net/wireless/marvell/mwifiex/scan.c | 3 +-
drivers/net/wireless/marvell/mwifiex/sdio.c | 12 +-
drivers/net/wireless/marvell/mwifiex/sta_event.c | 3 +-
drivers/net/wireless/marvell/mwifiex/sta_ioctl.c | 8 +-
drivers/net/wireless/marvell/mwifiex/sta_tx.c | 2 +-
drivers/net/wireless/marvell/mwifiex/uap_txrx.c | 3 +
drivers/net/wireless/marvell/mwifiex/usb.c | 25 +-
drivers/net/wireless/marvell/mwifiex/util.c | 6 +-
drivers/net/wireless/marvell/mwifiex/wmm.c | 2 +-
drivers/net/wireless/mediatek/mt76/Kconfig | 26 +
drivers/net/wireless/mediatek/mt76/Makefile | 20 +-
drivers/net/wireless/mediatek/mt76/agg-rx.c | 2 +-
drivers/net/wireless/mediatek/mt76/dma.c | 77 +-
drivers/net/wireless/mediatek/mt76/dma.h | 43 +
drivers/net/wireless/mediatek/mt76/mac80211.c | 20 +-
drivers/net/wireless/mediatek/mt76/mt76.h | 162 +-
drivers/net/wireless/mediatek/mt76/mt76x0/Makefile | 7 +
drivers/net/wireless/mediatek/mt76/mt76x0/core.c | 34 +
.../net/wireless/mediatek/mt76/mt76x0/debugfs.c | 166 ++
drivers/net/wireless/mediatek/mt76/mt76x0/dma.c | 522 +++++++
drivers/net/wireless/mediatek/mt76/mt76x0/dma.h | 126 ++
drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c | 445 ++++++
drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.h | 149 ++
drivers/net/wireless/mediatek/mt76/mt76x0/init.c | 720 +++++++++
.../net/wireless/mediatek/mt76/mt76x0/initvals.h | 282 ++++
.../wireless/mediatek/mt76/mt76x0/initvals_phy.h | 772 ++++++++++
drivers/net/wireless/mediatek/mt76/mt76x0/mac.c | 660 ++++++++
drivers/net/wireless/mediatek/mt76/mt76x0/mac.h | 154 ++
drivers/net/wireless/mediatek/mt76/mt76x0/main.c | 403 +++++
drivers/net/wireless/mediatek/mt76/mt76x0/mcu.c | 656 ++++++++
drivers/net/wireless/mediatek/mt76/mt76x0/mcu.h | 101 ++
drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h | 330 ++++
drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 1008 ++++++++++++
drivers/net/wireless/mediatek/mt76/mt76x0/phy.h | 81 +
drivers/net/wireless/mediatek/mt76/mt76x0/regs.h | 651 ++++++++
drivers/net/wireless/mediatek/mt76/mt76x0/trace.c | 21 +
drivers/net/wireless/mediatek/mt76/mt76x0/trace.h | 313 ++++
drivers/net/wireless/mediatek/mt76/mt76x0/tx.c | 270 ++++
drivers/net/wireless/mediatek/mt76/mt76x0/usb.c | 381 +++++
drivers/net/wireless/mediatek/mt76/mt76x0/usb.h | 61 +
drivers/net/wireless/mediatek/mt76/mt76x0/util.c | 42 +
drivers/net/wireless/mediatek/mt76/mt76x2.h | 91 +-
drivers/net/wireless/mediatek/mt76/mt76x2_common.c | 350 +++++
.../net/wireless/mediatek/mt76/mt76x2_debugfs.c | 1 +
drivers/net/wireless/mediatek/mt76/mt76x2_dma.c | 21 -
drivers/net/wireless/mediatek/mt76/mt76x2_dma.h | 38 -
drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.c | 13 +-
drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.h | 1 +
drivers/net/wireless/mediatek/mt76/mt76x2_init.c | 305 +---
.../wireless/mediatek/mt76/mt76x2_init_common.c | 259 ++++
drivers/net/wireless/mediatek/mt76/mt76x2_mac.c | 656 +-------
drivers/net/wireless/mediatek/mt76/mt76x2_mac.h | 2 +-
.../net/wireless/mediatek/mt76/mt76x2_mac_common.c | 699 +++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_main.c | 323 +---
drivers/net/wireless/mediatek/mt76/mt76x2_mcu.c | 17 -
drivers/net/wireless/mediatek/mt76/mt76x2_mcu.h | 17 +
drivers/net/wireless/mediatek/mt76/mt76x2_phy.c | 347 -----
.../net/wireless/mediatek/mt76/mt76x2_phy_common.c | 349 +++++
drivers/net/wireless/mediatek/mt76/mt76x2_regs.h | 30 +
drivers/net/wireless/mediatek/mt76/mt76x2_tx.c | 128 +-
.../net/wireless/mediatek/mt76/mt76x2_tx_common.c | 149 ++
drivers/net/wireless/mediatek/mt76/mt76x2_usb.c | 142 ++
drivers/net/wireless/mediatek/mt76/mt76x2u.h | 83 +
drivers/net/wireless/mediatek/mt76/mt76x2u_core.c | 108 ++
drivers/net/wireless/mediatek/mt76/mt76x2u_init.c | 318 ++++
drivers/net/wireless/mediatek/mt76/mt76x2u_mac.c | 240 +++
drivers/net/wireless/mediatek/mt76/mt76x2u_main.c | 185 +++
drivers/net/wireless/mediatek/mt76/mt76x2u_mcu.c | 463 ++++++
drivers/net/wireless/mediatek/mt76/mt76x2u_phy.c | 303 ++++
drivers/net/wireless/mediatek/mt76/tx.c | 85 +-
drivers/net/wireless/mediatek/mt76/usb.c | 845 +++++++++++
drivers/net/wireless/mediatek/mt76/usb_mcu.c | 242 +++
drivers/net/wireless/mediatek/mt76/usb_trace.c | 23 +
drivers/net/wireless/mediatek/mt76/usb_trace.h | 71 +
drivers/net/wireless/mediatek/mt7601u/init.c | 1 +
drivers/net/wireless/mediatek/mt7601u/main.c | 11 +
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 100 +-
drivers/net/wireless/quantenna/qtnfmac/commands.c | 154 +-
drivers/net/wireless/quantenna/qtnfmac/commands.h | 3 +
drivers/net/wireless/quantenna/qtnfmac/core.c | 1 +
drivers/net/wireless/quantenna/qtnfmac/core.h | 3 +-
drivers/net/wireless/quantenna/qtnfmac/qlink.h | 85 ++
drivers/net/wireless/ralink/rt2x00/rt2x00mac.c | 18 -
drivers/net/wireless/ray_cs.c | 6 +-
.../wireless/realtek/rtl818x/rtl8180/rtl8225se.c | 4 +-
drivers/net/wireless/rsi/rsi_91x_hal.c | 28 +-
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 3 +-
drivers/net/wireless/rsi/rsi_91x_main.c | 7 +-
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 23 +-
drivers/net/wireless/rsi/rsi_91x_sdio.c | 5 +-
drivers/net/wireless/rsi/rsi_91x_usb.c | 6 +-
drivers/net/wireless/rsi/rsi_mgmt.h | 2 +-
drivers/net/wireless/rsi/rsi_sdio.h | 3 +
drivers/net/wireless/rsi/rsi_usb.h | 3 +
drivers/net/wireless/ti/wlcore/main.c | 10 +-
drivers/net/wireless/ti/wlcore/rx.c | 8 +-
211 files changed, 22060 insertions(+), 3866 deletions(-)
create mode 100644 drivers/net/wireless/ath/wil6210/txrx_edma.c
create mode 100644 drivers/net/wireless/ath/wil6210/txrx_edma.h
delete mode 100644 drivers/net/wireless/intel/iwlwifi/fw/common_rx.c
create mode 100644 drivers/net/wireless/intel/iwlwifi/iwl-context-info-gen3.h
create mode 100644 drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/Makefile
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/core.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/debugfs.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/dma.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/dma.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/init.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/initvals.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/initvals_phy.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/mac.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/mac.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/main.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/mcu.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/mcu.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/phy.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/regs.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/trace.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/trace.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/tx.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/usb.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/util.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_common.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_init_common.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_mac_common.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_phy_common.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_tx_common.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_usb.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2u.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2u_core.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2u_init.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2u_mac.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2u_main.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2u_mcu.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2u_phy.c
create mode 100644 drivers/net/wireless/mediatek/mt76/usb.c
create mode 100644 drivers/net/wireless/mediatek/mt76/usb_mcu.c
create mode 100644 drivers/net/wireless/mediatek/mt76/usb_trace.c
create mode 100644 drivers/net/wireless/mediatek/mt76/usb_trace.h
^ permalink raw reply
* Re: [endianness bug?] cxgb4_next_header .match_val/.match_mask should be net-endian
From: Al Viro @ 2018-08-05 15:49 UTC (permalink / raw)
To: Rahul Lakkireddy; +Cc: netdev, David S. Miller
In-Reply-To: <20180805152811.GF15082@ZenIV.linux.org.uk>
On Sun, Aug 05, 2018 at 04:28:11PM +0100, Al Viro wrote:
> On little-endian host those do yield the right values - e.g. 0x1100 is
> {0, 17, 0, 0}, etc. On big-endian, though, these will end up checking
> in IPv4 case the octet at offset 10 (i.e. upper 16 bits of checksum) and for IPv6
> - the octet at offset 5 (i.e. the lower 8 bits of payload length).
>
> Unless I'm misreading that code, it needs the following to do the right
> thing both on l-e and b-e. Comments?
... and it looks like the same story with ->mask - it's compared to ->offmask,
which is __be16. For little-endian hosts the values make sense (htons(0x0f00),
with offoff 0 and shift 6, i.e. "take the first two octets, treat them as
net-endian, clear everything except IHL bits and shift down by 6, which'd
yield IHL*4"), for big-endian they don't - you'd get TOS * 4 instead...
^ permalink raw reply
* [endianness bug?] cxgb4_next_header .match_val/.match_mask should be net-endian
From: Al Viro @ 2018-08-05 15:28 UTC (permalink / raw)
To: Rahul Lakkireddy; +Cc: netdev, Hariprasad Shenai, David S. Miller
AFAICS, cxgb4_next_header() expects to find match_val/match_mask in
struct cxgb4_next_header stored as big-endian:
/* Found a possible candidate. Find a key that
* matches the corresponding offset, value, and
* mask to jump to next header.
*/
for (j = 0; j < cls->knode.sel->nkeys; j++) {
off = cls->knode.sel->keys[j].off;
val = cls->knode.sel->keys[j].val;
mask = cls->knode.sel->keys[j].mask;
if (next[i].match_off == off &&
next[i].match_val == val &&
next[i].match_mask == mask) {
found = true;
break;
}
}
Here ->keys[] is struct tc_u32_key and there mask and val are definitely
__be32. match_val and match_mask are never changed after initialization
and they are set to:
* .match_off = 8, .match_val = 0x600, .match_mask = 0xFF00
meant to check for IPV4.Protocol == TCP, i.e. octet at offset 9 being 6
* .match_off = 8, .match_val = 0x1100, .match_mask = 0xFF00
meant to check for IPV4.Protocol == UDP, i.e. octet at offset 9 being 0x11
* .match_off = 4, .match_val = 0x60000, .match_mask = 0xFF0000
IPV6.NextHeader == TCP, i.e. octet at offset 6 being 6
* .match_off = 4, .match_val = 0x110000, .match_mask = 0xFF0000
IPV6.NextHeader == UDP, i.e. octet at offset 6 being 0x11
On little-endian host those do yield the right values - e.g. 0x1100 is
{0, 17, 0, 0}, etc. On big-endian, though, these will end up checking
in IPv4 case the octet at offset 10 (i.e. upper 16 bits of checksum) and for IPv6
- the octet at offset 5 (i.e. the lower 8 bits of payload length).
Unless I'm misreading that code, it needs the following to do the right
thing both on l-e and b-e. Comments?
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32_parse.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32_parse.h
index a4b99edcc339..ec226b1cebf4 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32_parse.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32_parse.h
@@ -259,11 +259,11 @@ struct cxgb4_next_header {
*/
static const struct cxgb4_next_header cxgb4_ipv4_jumps[] = {
{ .offset = 0, .offoff = 0, .shift = 6, .mask = 0xF,
- .match_off = 8, .match_val = 0x600, .match_mask = 0xFF00,
- .jump = cxgb4_tcp_fields },
+ .match_off = 8, .match_val = htonl(6 << 16),
+ .match_mask = htonl(0xff<<16), .jump = cxgb4_tcp_fields },
{ .offset = 0, .offoff = 0, .shift = 6, .mask = 0xF,
- .match_off = 8, .match_val = 0x1100, .match_mask = 0xFF00,
- .jump = cxgb4_udp_fields },
+ .match_off = 8, .match_val = htonl(17 << 16),
+ .match_mask = htonl(0xff<<16), .jump = cxgb4_udp_fields },
{ .jump = NULL }
};
@@ -272,11 +272,11 @@ static const struct cxgb4_next_header cxgb4_ipv4_jumps[] = {
*/
static const struct cxgb4_next_header cxgb4_ipv6_jumps[] = {
{ .offset = 0x28, .offoff = 0, .shift = 0, .mask = 0,
- .match_off = 4, .match_val = 0x60000, .match_mask = 0xFF0000,
- .jump = cxgb4_tcp_fields },
+ .match_off = 4, .match_val = htonl(6 << 8),
+ .match_mask = htonl(0xff << 8), .jump = cxgb4_tcp_fields },
{ .offset = 0x28, .offoff = 0, .shift = 0, .mask = 0,
- .match_off = 4, .match_val = 0x110000, .match_mask = 0xFF0000,
- .jump = cxgb4_udp_fields },
+ .match_off = 4, .match_val = htonl(17 << 8),
+ .match_mask = htonl(0xff << 8), .jump = cxgb4_udp_fields },
{ .jump = NULL }
};
^ permalink raw reply related
* Re: consequences of setting net_device_ops ndo_change_carrier()?
From: Andrew Lunn @ 2018-08-05 14:58 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Linux kernel ntedev mailing list
In-Reply-To: <alpine.LFD.2.21.1808050625220.7483@localhost.localdomain>
> > You should have a PHY device of some sort. Either a traditional
> > copper PHY, or an SFP module. There should be a driver for this PHY.
> > This could be one of those in drivers/net/phy. Or it could be
> > firmware running, running on a little microcontroller inside your
> > FPGA?
>
> in my case, it's properly in drivers/net/phy, so at least that part
> is normal. back to investigating ...
Hi Robert
O.K, that makes thing simpler.
PHYs are controlled via an MDIO bus. Do you have an MDIO bus driver?
You said this was an FPGA design. MDIO might be a standard cell you
can just drop in. If so, look around and see if there is an existing
driver for it. Otherwise you might have to write one. They are quite
simple, some examples are in driver/net/phy. Depending on the address
range, the MDIO bus driver can also be embedded in the MAC driver.
Andrew
^ permalink raw reply
* [PATCH net] ip6_tunnel: use the right value for ipv4 min mtu check in ip6_tnl_xmit
From: Xin Long @ 2018-08-05 14:46 UTC (permalink / raw)
To: network dev; +Cc: davem, Sabrina Dubroca
According to RFC791, 68 bytes is the minimum size of IPv4 datagram every
device must be able to forward without further fragmentation while 576
bytes is the minimum size of IPv4 datagram every device has to be able
to receive, so in ip6_tnl_xmit(), 68(IPV4_MIN_MTU) should be the right
value for the ipv4 min mtu check in ip6_tnl_xmit.
While at it, change to use max() instead of if statement.
Fixes: c9fefa08190f ("ip6_tunnel: get the min mtu properly in ip6_tnl_xmit")
Reported-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/ipv6/ip6_tunnel.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 00e138a..1cc9650 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1133,12 +1133,8 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev, __u8 dsfield,
max_headroom += 8;
mtu -= 8;
}
- if (skb->protocol == htons(ETH_P_IPV6)) {
- if (mtu < IPV6_MIN_MTU)
- mtu = IPV6_MIN_MTU;
- } else if (mtu < 576) {
- mtu = 576;
- }
+ mtu = max(mtu, skb->protocol == htons(ETH_P_IPV6) ?
+ IPV6_MIN_MTU : IPV4_MIN_MTU);
skb_dst_update_pmtu(skb, mtu);
if (skb->len - t->tun_hlen - eth_hlen > mtu && !skb_is_gso(skb)) {
--
2.1.0
^ permalink raw reply related
* Re: KCM - recvmsg() mangles packets?
From: Dominique Martinet @ 2018-08-05 14:12 UTC (permalink / raw)
To: Tom Herbert; +Cc: Linux Kernel Network Developers
In-Reply-To: <20180805064410.GA26807@nautica>
Dominique Martinet wrote on Sun, Aug 05, 2018:
> (I'm not sure about offset, since we pass the full skb to parse message,
> wouldn't it look at the start of the buffer everytime? Well, offset
> seems to be 0 everytime the first time that check fails so I can
> probably ignore that for now...)
Oh, this might actually not have been such a bad remark; if I have the
client write two "messages" in a single write() kcm seems to reliably
fail the same way...
Conversely, if I setsockopt(s, IPPROTO_TCP, TCP_NODELAY...) on the
sender socket, *and* make it wait till the kcm socket has been created
to start sending data, then it dramatically reduces the probability of
this happening (I had to let the reproducer run in a loop for 5 minutes,
wheras it used to happen within seconds).
So I think the problem is packet aggregation, and strparser not handling
that properly... The first packet still fails with TCP_NODELAY but
there's probably aggregation on the recv side as well before the socket
is attached to the multiplexor... I guess the low probability failure
that is still happening could be similar.
(I also noticed that I've mistakedly believed that the problem was the
first packet contained the 2nd packet's data because of an off-by-one in
the receiver, it really is the second packet, it only has the first
packet's length)
I've moved my check from kcm_rcv_strparser to just before parse_msg in
__strp_recv and surely enough it fails everytime there's an offset.
It's getting late but I'll try adding a pskb_pull in there tomorrow, it
would be better to make the bpf program start with an offset but I don't
think that'll be easy to change...
I'm almost done spamming, thanks for being a good rubber duck! :p
--
Dominique Martinet
^ permalink raw reply
* Re: linux-lora.git and LoRaWAN (was: [RFC net-next 00/15] net: A socket API for LoRa)
From: Jian-Hong Pan @ 2018-08-05 14:08 UTC (permalink / raw)
To: Alan Cox
Cc: Andreas Färber, Ben Whitten, netdev@vger.kernel.org,
<linux-arm-kernel@lists.infradead.org\, Jan Jongboom,
Konstantin Böhm, Ken Yu, Dollar Chen, Michael Röder,
Janus Piwek, Matthias Brugger, S. Miller,
linux-kernel@vger.kernel.org>,, Brian Ray
In-Reply-To: <20180803150258.791b9942@alans-desktop>
Hi Alan,
2018-08-03 22:02 GMT+08:00 Alan Cox <gnomes@lxorguk.ukuu.org.uk>:
>> I'm not yet too deep into LoRaWAN, but from the AT command interfaces
>> I've seen there's confirmed and unconfirmed transmission modes that with
>> PF_LORAWAN might be mapped to SOCK_STREAM and SOCK_DGRAM. Or do you see
>> a way of doing both on a single PF_LORA SOCK_LORAWAN socket?
>
> SOCK_STREAM is not a confirmed message, but a reliable data stream where
> packet boundaries have no meaning.
>
> SOCK_SEQPACKET is a reliable ordered stream where message boundaries have
> meaning.
>
> SOCK_RDM is reliable messaging where there is no ordering.
>
> The standard socket API has no concept of a single connection doing both
> reliable and unreliable messages.
Thanks for the useful information.
LoRaWAN has 4 kinds of data messages: Unconfirmed data up/down,
Confirmed data up/down.
Unconfirmed data up/down can be mapped to SOCK_DGRAM.
Confirmed data up/down can be mapped to SOCK_SEQPACKET. Because,
there is the FCnt (frame counter) field in frame header for the order.
Regards,
Jian-Hong Pan
>> Additionally I've been looking into socket options at PF_LORA dgram
>> layer for some radio options, but discarded that again for lack of
>> precedence. Basically I wondered whether we could allow to choose SF,
>
> I don't know if it'll stretch that far in the right directions but to the
> extent you can re-use bits of the wifi API and it makes sense it would be
> good to do so.
>
> For stuff bound to a specific socket you need to use the generic SOCK_
> stuff or you may indeed need some socket options at the PF_LORA level -
> which is fine, and the whole point of setsockopt passing layers around.
>
> Some of the existing general stuff like priority is probably quite
> useable.
>
>> bandwidth, etc. on socket level and then apply those settings before
>> sending one packet rather than expecting a global netlink operation that
>> affects all sockets for that interface.
>
> Alan
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2018-08-05 15:52 UTC (permalink / raw)
To: David Miller
Cc: Andrew Morton, Network Development, Linux Kernel Mailing List
In-Reply-To: <20180805.004744.1043412275329854518.davem@davemloft.net>
On Sun, Aug 5, 2018 at 12:47 AM David Miller <davem@davemloft.net> wrote:
>
> 4) Fix regression in netlink bind handling of multicast
> gruops, from Dmitry Safonov.
This one is written kind of stupidly.
The code went from the original
groups &= (1UL << nlk->ngroups) - 1;
(which is incorrect for large values of nlk->ngroups) to the fixed
if (nlk->ngroups == 0)
groups = 0;
else if (nlk->ngroups < 8*sizeof(groups))
groups &= (1UL << nlk->ngroups) - 1;
which isn't technically incorrect...
But it is stupid.
Why stupid? Because the test for 0 is pointless.
Just doing
if (nlk->ngroups < 8*sizeof(groups))
groups &= (1UL << nlk->ngroups) - 1;
would have been fine and more understandable, since the "mask by shift
count" already does the right thing for a ngroups value of 0. Now that
test for zero makes me go "what's special about zero?". It turns out
that the answer to that is "nothing".
I certainly didn't care enough to fix it up, and maybe the compiler is
even smart enough to remove the unnecessary test for zero, but it's
kind of sad to see this kind of "people didn't think the code through"
patch this late in the rc.
I'll be making an rc8 today anyway, but I did want to just point to it
and say "hey guys, the code is unnecessarily stupid and overly
complicated".
The type of "groups" is kind of silly too.
Yeah, "long unsigned int" isn't _technically_ wrong. But we normally
call that type "unsigned long".
And comparing against "8*sizeof(groups)" is misleading too, when the
actual masking expression works and is correct in "unsigned long"
because that's the type of the actual mask we're computing (due to the
"1UL").
So _regardless_ of the type of "groups" itself, the mask is actually
correct in unsigned long. I personally think it would have been more
legible as just
unsigned long groups;
...
if (nlk->ngroups < BITS_PER_LONG)
groups &= (1UL << nlk->ngroups) - 1;
but by now I'm just nitpicking.
Linus
^ permalink raw reply
* Re: Linux kernel error stack
From: Satish Patel @ 2018-08-05 12:43 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev
In-Reply-To: <20180805094835.3e2njq2f3plj7njj@breakpoint.cc>
Thanks Florian,
FYI, I don't have any CHECKSUM configure in my iptables, i have
following rules, also do you think this kernel WARNNING is just
warning and not impacting my performance, based on that i have to
decided criticality of this issue.
[root@ostack-infra-02 ~]# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:67
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:67
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
On Sun, Aug 5, 2018 at 5:48 AM, Florian Westphal <fw@strlen.de> wrote:
> Satish Patel <satish.txt@gmail.com> wrote:
>> I am installing openstack and as you know i have lots of bridges and
>> vlan interface on my Linux CentOS 7.5
>>
>> I was getting following error stack on 3.10 kernel and found this is
>> kernel bug which required kernel upgrade so now i have upgraded my
>> kernel to 4.17.12 but i am still seeing same kernel stack error on my
>> dmesg
>>
>> I have disable TSO, LRO, SG & GSO on my NIC but still getting error
>> just wanted to understand what is this and why it popping up
>
> Get rid of CHECKSUM target in the iptables rules.
> This thing was added 8 years ago to work around dhcp bugs, I don't
> think its use is needed anymore.
> Try removing it and see that all VMs can still retrieve IP address
> via DHCP.
>
> I'm curious as to the rules, normally CHECKSUM target should be
> limited to -p udp --dport bootp; its bad idea to feed it normal
> packets, its expensive to do this in software rather than have device
> do the checksumming.
>
> As for fix, I'm tempted to send patch to make checksum target
> eval a no-op & add deprecation warning on init...
>
> Other "fix" is to
>
> diff --git a/net/netfilter/xt_CHECKSUM.c b/net/netfilter/xt_CHECKSUM.c
> index 9f4151ec3e06..23a17dda604d 100644
> --- a/net/netfilter/xt_CHECKSUM.c
> +++ b/net/netfilter/xt_CHECKSUM.c
> @@ -25,8 +25,12 @@ MODULE_ALIAS("ip6t_CHECKSUM");
> static unsigned int
> checksum_tg(struct sk_buff *skb, const struct xt_action_param *par)
> {
> - if (skb->ip_summed == CHECKSUM_PARTIAL)
> - skb_checksum_help(skb);
> + if (skb->ip_summed == CHECKSUM_PARTIAL) {
> + if (skb_shinfo(skb)->gso_size)
> + skb->ip_summed = CHECKSUM_NONE;
> + else
> + skb_checksum_help(skb);
> + }
>
> return XT_CONTINUE;
> }
>
> (unfortunately, the target isn't restricted to POSTROUTING, sigh).
^ permalink raw reply
* Re: [PATCH net-next 0/6] virtio_net: Add ethtool stat items
From: Tariq Toukan @ 2018-08-05 14:22 UTC (permalink / raw)
To: David Miller, mst, toshiaki.makita1, makita.toshiaki
Cc: ranro, netdev, Eran Ben Elisha, virtualization, Maor Gottlieb
In-Reply-To: <8a21b956-af42-3598-b752-d1e3fa9e63d3@mellanox.com>
On 05/08/2018 4:45 PM, Tariq Toukan wrote:
>
>
> On 05/08/2018 4:15 PM, Tariq Toukan wrote:
>>
>>
>> On 25/07/2018 10:59 PM, David Miller wrote:
>>> From: "Michael S. Tsirkin" <mst@redhat.com>
>>> Date: Wed, 25 Jul 2018 12:40:12 +0300
>>>
>>>> On Mon, Jul 23, 2018 at 11:36:03PM +0900, Toshiaki Makita wrote:
>>>>> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>>>>
>>>>> Add some ethtool stat items useful for performance analysis.
>>>>>
>>>>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>>>
>>>> Series:
>>>>
>>>> Acked-by: Michael S. Tsirkin <mst@redhat.com>
>>>
>>> Series applied.
>>>
>>>> Patch 1 seems appropriate for stable, even though it's minor.
>>>
>>> Ok, I'll put patch #1 also into 'net' and queue it up for -stable.
>>>
>>> Thanks.
>>>
>>
>> Hi,
>> Our verification team encountered the following degradation,
>> introduced by this series. Please check KASAN bug report below.
>>
>> We tested before and after the series, but didn't bisect within it. We
>> can do if necessary.
>>
>> Thanks,
>> Tariq
>>
>
> I see this might already be fixed, here:
> https://marc.info/?l=linux-netdev&m=153335713407532&w=2
>
> Verifying...
>
No repro when applying this fix.
Thanks,
Tariq
^ permalink raw reply
* [PATCH] net/bridge/br_multicast: remove redundant variable "err"
From: zhong jiang @ 2018-08-05 14:18 UTC (permalink / raw)
To: davem, stephen; +Cc: netdev, linux-kernel
The err is not used after initalization, So remove it and make
it void function.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
net/bridge/br_multicast.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 920665d..dc26c53 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1423,10 +1423,10 @@ static void br_multicast_query_received(struct net_bridge *br,
br_multicast_mark_router(br, port);
}
-static int br_ip4_multicast_query(struct net_bridge *br,
- struct net_bridge_port *port,
- struct sk_buff *skb,
- u16 vid)
+static void br_ip4_multicast_query(struct net_bridge *br,
+ struct net_bridge_port *port,
+ struct sk_buff *skb,
+ u16 vid)
{
const struct iphdr *iph = ip_hdr(skb);
struct igmphdr *ih = igmp_hdr(skb);
@@ -1439,7 +1439,6 @@ static int br_ip4_multicast_query(struct net_bridge *br,
unsigned long now = jiffies;
unsigned int offset = skb_transport_offset(skb);
__be32 group;
- int err = 0;
spin_lock(&br->multicast_lock);
if (!netif_running(br->dev) ||
@@ -1498,7 +1497,6 @@ static int br_ip4_multicast_query(struct net_bridge *br,
out:
spin_unlock(&br->multicast_lock);
- return err;
}
#if IS_ENABLED(CONFIG_IPV6)
@@ -1797,7 +1795,7 @@ static int br_multicast_ipv4_rcv(struct net_bridge *br,
struct sk_buff *skb_trimmed = NULL;
const unsigned char *src;
struct igmphdr *ih;
- int err;
+ int err = 0;
err = ip_mc_check_igmp(skb, &skb_trimmed);
@@ -1828,7 +1826,7 @@ static int br_multicast_ipv4_rcv(struct net_bridge *br,
err = br_ip4_multicast_igmp3_report(br, port, skb_trimmed, vid);
break;
case IGMP_HOST_MEMBERSHIP_QUERY:
- err = br_ip4_multicast_query(br, port, skb_trimmed, vid);
+ br_ip4_multicast_query(br, port, skb_trimmed, vid);
break;
case IGMP_HOST_LEAVE_MESSAGE:
br_ip4_multicast_leave_group(br, port, ih->group, vid, src);
--
1.7.12.4
^ permalink raw reply related
* Re: [PATCH 4.4 106/124] netlink: Do not subscribe to non-existent groups
From: Greg Kroah-Hartman @ 2018-08-05 14:03 UTC (permalink / raw)
To: Nathan Chancellor
Cc: linux-kernel, stable, David S. Miller, Herbert Xu,
Steffen Klassert, netdev, Dmitry Safonov
In-Reply-To: <20180804180734.GA25546@flashbox>
On Sat, Aug 04, 2018 at 11:07:34AM -0700, Nathan Chancellor wrote:
> On Sat, Aug 04, 2018 at 11:01:35AM +0200, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Dmitry Safonov <dima@arista.com>
> >
> > [ Upstream commit 7acf9d4237c46894e0fa0492dd96314a41742e84 ]
> >
> > Make ABI more strict about subscribing to group > ngroups.
> > Code doesn't check for that and it looks bogus.
> > (one can subscribe to non-existing group)
> > Still, it's possible to bind() to all possible groups with (-1)
> >
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: Herbert Xu <herbert@gondor.apana.org.au>
> > Cc: Steffen Klassert <steffen.klassert@secunet.com>
> > Cc: netdev@vger.kernel.org
> > Signed-off-by: Dmitry Safonov <dima@arista.com>
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > ---
> > net/netlink/af_netlink.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > --- a/net/netlink/af_netlink.c
> > +++ b/net/netlink/af_netlink.c
> > @@ -983,6 +983,7 @@ static int netlink_bind(struct socket *s
> > if (err)
> > return err;
> > }
> > + groups &= (1UL << nlk->ngroups) - 1;
> >
> > bound = nlk->bound;
> > if (bound) {
> >
> >
>
> Hi Greg,
>
> I am so sorry I didn't catch this in my initial report but this commit
> along with ba7aaf93ef2f ("netlink: Don't shift with UB on nlk->ngroups")
> breaks mobile data on both the Pixel 2 XL and OnePlus 6. There is signal
> but it just never connects to 3G/LTE. Reverting those two commits fixes
> the issue.
>
> Nothing stands out to me in dmesg unfortunately and iven neither device
> is running a vanilla kernel, I cannot say if this is a problem in mainline
> or not but I just wanted to make you aware of it.
Many thanks for catching this. I'll go drop this patch from the trees
for now, and will queue it up later with the fixup patch when that lands
in Linus's tree.
thanks,
greg k-h
^ permalink raw reply
* Re: [RFC net-next 00/15] net: A socket API for LoRa
From: Andreas Färber @ 2018-08-05 13:49 UTC (permalink / raw)
To: Ben Whitten, Jian-Hong Pan
Cc: netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Jiri Pirko, Marcel Holtmann,
David S. Miller, Matthias Brugger, Janus Piwek,
Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm,
Jan Jongboom, Jon Ortego, contact@snootlab.com, Brian Ray,
lora@globalsat.com.tw
In-Reply-To: <BY1PR02MB11143134B9ABAC9C9929A9C4E7530@BY1PR02MB1114.namprd02.prod.outlook.com>
Hi Ben and Jian-Hong,
[- SPI - devicetree]
Am 18.07.2018 um 13:28 schrieb Ben Whitten:
>> Meanwhile my attempt to play with netlink during SUSE
>> Hackweek has been
>> going slow and I could use some guidance or a volunteer to
>> contribute: I
>> have a bare skeleton of registration, commands, attributes
>> and multicast
>> groups, but no plan yet how to connect that to the actual
>> drivers to
>> query or apply the settings...
>
> Happy to help, I will be starting from zero on netlink but I can contribute my existing work incorporating Marks comments for sx1301 etal.
I've figured out a way to retrieve a frequency value via netlink:
By passing the lora0 ifindex in as attribute, nllora can look up the
net_device by index, and then via struct lora_dev_priv call into hooks
that the device drivers can optionally implement. :)
https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/net/lora/netlink.c?h=lora-next
Tested with HIMO-01M module.
The command might need an additional channel attribute for SX130x.
The corresponding nltest program (using libnl-genl) is here:
https://github.com/afaerber/lora-modules/blob/master/nltest.c
Cheers,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH net-next 0/6] virtio_net: Add ethtool stat items
From: Tariq Toukan @ 2018-08-05 13:45 UTC (permalink / raw)
To: David Miller, mst, toshiaki.makita1, makita.toshiaki
Cc: ranro, netdev, Eran Ben Elisha, virtualization, Maor Gottlieb
In-Reply-To: <eacdf80a-87cd-ce8d-b56a-c49432948773@mellanox.com>
On 05/08/2018 4:15 PM, Tariq Toukan wrote:
>
>
> On 25/07/2018 10:59 PM, David Miller wrote:
>> From: "Michael S. Tsirkin" <mst@redhat.com>
>> Date: Wed, 25 Jul 2018 12:40:12 +0300
>>
>>> On Mon, Jul 23, 2018 at 11:36:03PM +0900, Toshiaki Makita wrote:
>>>> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>>>
>>>> Add some ethtool stat items useful for performance analysis.
>>>>
>>>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>>
>>> Series:
>>>
>>> Acked-by: Michael S. Tsirkin <mst@redhat.com>
>>
>> Series applied.
>>
>>> Patch 1 seems appropriate for stable, even though it's minor.
>>
>> Ok, I'll put patch #1 also into 'net' and queue it up for -stable.
>>
>> Thanks.
>>
>
> Hi,
> Our verification team encountered the following degradation, introduced
> by this series. Please check KASAN bug report below.
>
> We tested before and after the series, but didn't bisect within it. We
> can do if necessary.
>
> Thanks,
> Tariq
>
I see this might already be fixed, here:
https://marc.info/?l=linux-netdev&m=153335713407532&w=2
Verifying...
>
> [ 46.166544] BUG: KASAN: use-after-free in virtnet_poll+0xd9c/0xfd1
> [virtio_net]
> [ 46.166593] Read of size 8 at addr ffff8803400da608 by task ip/1013
>
> [ 46.166603] CPU: 3 PID: 1013 Comm: ip Not tainted
> 4.18.0-rc6-for-upstream-dbg-2018-07-26_19-45-52-64 #1
> [ 46.166606] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.10.2-1ubuntu1 04/01/2014
> [ 46.166609] Call Trace:
> [ 46.166613] <IRQ>
> [ 46.166624] dump_stack+0xf0/0x17b
> [ 46.166647] ? show_regs_print_info+0x5/0x5
> [ 46.166654] ? printk+0x9c/0xc3
> [ 46.166661] ? kmsg_dump_rewind_nolock+0xf5/0xf5
> [ 46.166677] ? virtnet_poll+0xd9c/0xfd1 [virtio_net]
> [ 46.166685] print_address_description+0xea/0x380
> [ 46.166701] ? virtnet_poll+0xd9c/0xfd1 [virtio_net]
> [ 46.166711] kasan_report+0x1dd/0x460
> [ 46.166727] ? virtnet_poll+0xd9c/0xfd1 [virtio_net]
> [ 46.166743] virtnet_poll+0xd9c/0xfd1 [virtio_net]
> [ 46.166767] ? receive_buf+0x2e30/0x2e30 [virtio_net]
> [ 46.166796] ? sched_clock_cpu+0x18/0x2b0
> [ 46.166809] ? print_irqtrace_events+0x280/0x280
> [ 46.166817] ? print_irqtrace_events+0x280/0x280
> [ 46.166830] ? rcu_process_callbacks+0xc5e/0x12d0
> [ 46.166838] ? kvm_clock_read+0x1f/0x30
> [ 46.166857] ? mark_held_locks+0xd5/0x170
> [ 46.166867] ? net_rx_action+0x2aa/0x10e0
> [ 46.166882] net_rx_action+0x4bc/0x10e0
> [ 46.166906] ? napi_complete_done+0x480/0x480
> [ 46.166925] ? print_irqtrace_events+0x280/0x280
> [ 46.166935] ? sched_clock+0x5/0x10
> [ 46.166952] ? __lock_is_held+0xcb/0x1a0
> [ 46.166982] __do_softirq+0x2c4/0xdf4
> [ 46.167010] do_softirq_own_stack+0x2a/0x40
> [ 46.167031] </IRQ>
> [ 46.167038] ? virtnet_napi_enable+0x37/0xa0 [virtio_net]
> [ 46.167044] do_softirq.part.11+0x69/0x70
> [ 46.167065] __local_bh_enable_ip+0x1d9/0x250
> [ 46.167076] virtnet_open+0x13c/0x440 [virtio_net]
> [ 46.167099] __dev_open+0x1cf/0x390
> [ 46.167108] ? dev_set_rx_mode+0x30/0x30
> [ 46.167113] ? __local_bh_enable_ip+0xf7/0x250
> [ 46.167124] ? trace_hardirqs_on_caller+0x38d/0x6c0
> [ 46.167130] ? __dev_change_flags+0x18d/0x630
> [ 46.167142] __dev_change_flags+0x469/0x630
> [ 46.167152] ? dev_set_allmulti+0x10/0x10
> [ 46.167157] ? __lock_acquire+0x9c1/0x4b50
> [ 46.167166] ? print_irqtrace_events+0x280/0x280
> [ 46.167174] ? kvm_clock_read+0x1f/0x30
> [ 46.167191] ? rtnetlink_put_metrics+0x530/0x530
> [ 46.167205] dev_change_flags+0x8b/0x160
> [ 46.167236] do_setlink+0xa17/0x39f0
> [ 46.167248] ? sched_clock_cpu+0x18/0x2b0
> [ 46.167267] ? rtnl_dump_ifinfo+0xd20/0xd20
> [ 46.167277] ? print_irqtrace_events+0x280/0x280
> [ 46.167285] ? kvm_clock_read+0x1f/0x30
> [ 46.167316] ? debug_show_all_locks+0x3b0/0x3b0
> [ 46.167321] ? kvm_sched_clock_read+0x5/0x10
> [ 46.167327] ? sched_clock+0x5/0x10
> [ 46.167333] ? sched_clock_cpu+0x18/0x2b0
> [ 46.167382] ? memset+0x1f/0x40
> [ 46.167408] ? nla_parse+0x8c/0x3f0
> [ 46.167419] ? rtnetlink_put_metrics+0x530/0x530
> [ 46.167427] ? kvm_sched_clock_read+0x5/0x10
> [ 46.167433] ? sched_clock+0x5/0x10
> [ 46.167439] ? sched_clock_cpu+0x18/0x2b0
> [ 46.167457] rtnl_newlink+0x9dc/0x13a0
> [ 46.167484] ? rtnl_link_unregister+0x2b0/0x2b0
> [ 46.167513] ? kvm_clock_read+0x1f/0x30
> [ 46.167538] ? print_irqtrace_events+0x280/0x280
> [ 46.167546] ? kvm_clock_read+0x1f/0x30
> [ 46.167551] ? kvm_sched_clock_read+0x5/0x10
> [ 46.167557] ? sched_clock+0x5/0x10
> [ 46.167562] ? sched_clock_cpu+0x18/0x2b0
> [ 46.167567] ? kvm_clock_read+0x1f/0x30
> [ 46.167598] ? __lock_acquire+0x9c1/0x4b50
> [ 46.167640] ? debug_show_all_locks+0x3b0/0x3b0
> [ 46.167646] ? kvm_clock_read+0x1f/0x30
> [ 46.167651] ? kvm_sched_clock_read+0x5/0x10
> [ 46.167673] ? debug_show_all_locks+0x3b0/0x3b0
> [ 46.167698] ? is_bpf_text_address+0x87/0x130
> [ 46.167707] ? print_irqtrace_events+0x280/0x280
> [ 46.167714] ? kvm_clock_read+0x1f/0x30
> [ 46.167718] ? kvm_sched_clock_read+0x5/0x10
> [ 46.167723] ? sched_clock+0x5/0x10
> [ 46.167728] ? sched_clock_cpu+0x18/0x2b0
> [ 46.167753] ? get_lock_stats+0x18/0x160
> [ 46.167877] ? __lock_is_held+0xcb/0x1a0
> [ 46.167908] rtnetlink_rcv_msg+0x575/0xaa0
> [ 46.167913] ? kvm_clock_read+0x1f/0x30
> [ 46.167925] ? validate_linkmsg+0x900/0x900
> [ 46.167945] ? netlink_deliver_tap+0x1cc/0xf30
> [ 46.167950] ? kvm_clock_read+0x1f/0x30
> [ 46.167965] netlink_rcv_skb+0x13c/0x3a0
> [ 46.167972] ? validate_linkmsg+0x900/0x900
> [ 46.167984] ? netlink_ack+0xcd0/0xcd0
> [ 46.168030] netlink_unicast+0x45a/0x6a0
> [ 46.168061] ? netlink_attachskb+0x770/0x770
> [ 46.168075] ? import_iovec+0xa8/0x460
> [ 46.168093] netlink_sendmsg+0x68e/0xdf0
> [ 46.168127] ? netlink_unicast+0x6a0/0x6a0
> [ 46.168133] ? copy_msghdr_from_user+0x216/0x350
> [ 46.168160] ? netlink_unicast+0x6a0/0x6a0
> [ 46.168168] sock_sendmsg+0xdb/0x160
> [ 46.168193] ___sys_sendmsg+0x6b3/0xbd0
> [ 46.168207] ? copy_msghdr_from_user+0x350/0x350
> [ 46.168221] ? do_raw_spin_unlock+0xae/0x310
> [ 46.168248] ? _raw_spin_unlock+0x2e/0x50
> [ 46.168257] ? __handle_mm_fault+0xb65/0x2e90
> [ 46.168278] ? handle_mm_fault+0x28f/0xa70
> [ 46.168284] ? kvm_clock_read+0x1f/0x30
> [ 46.168289] ? kvm_sched_clock_read+0x5/0x10
> [ 46.168303] ? __do_page_fault+0x549/0xd00
> [ 46.168308] ? kvm_clock_read+0x1f/0x30
> [ 46.168313] ? kvm_sched_clock_read+0x5/0x10
> [ 46.168318] ? sched_clock+0x5/0x10
> [ 46.168324] ? sched_clock_cpu+0x18/0x2b0
> [ 46.168336] ? __fget_light+0x5c/0x280
> [ 46.168357] ? __sys_sendmsg+0xd2/0x170
> [ 46.168362] __sys_sendmsg+0xd2/0x170
> [ 46.168371] ? __ia32_sys_shutdown+0x90/0x90
> [ 46.168382] ? handle_mm_fault+0x363/0xa70
> [ 46.168397] ? up_read+0x1c/0x130
> [ 46.168403] ? __do_page_fault+0x549/0xd00
> [ 46.168443] ? do_syscall_64+0x18/0x540
> [ 46.168459] do_syscall_64+0xa4/0x540
> [ 46.168470] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 46.168477] RIP: 0033:0x7fa59e680087
> [ 46.168481] Code: 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 80 00 00
> 00 00 8b 05 aa 97 2c 00 48 63 d2 48 63 ff 85 c0 75 18 b8 2e 00 00 00 0f
> 05 <48> 3d 00 f0 ff ff 77 59 f3 c3 0f 1f 80 00 00 00 00 53 48 89 f3 48
> [ 46.168717] RSP: 002b:00007ffe83f2fef8 EFLAGS: 00000246 ORIG_RAX:
> 000000000000002e
> [ 46.168726] RAX: ffffffffffffffda RBX: 00000000006744c0 RCX:
> 00007fa59e680087
> [ 46.168731] RDX: 0000000000000000 RSI: 00007ffe83f2ff40 RDI:
> 0000000000000003
> [ 46.168735] RBP: 000000005b5d727c R08: 0000000000000001 R09:
> fefefeff77686d74
> [ 46.168740] R10: 0000000000000006 R11: 0000000000000246 R12:
> 00007ffe83f38000
> [ 46.168744] R13: 0000000000000000 R14: 00007ffe83f38728 R15:
> 00007ffe83f37fd8
>
> [ 46.168778] Allocated by task 499:
> [ 46.168784] kasan_kmalloc+0xa0/0xd0
> [ 46.168789] __kmalloc+0x191/0x3a0
> [ 46.168795] mpi_powm+0x956/0x2360
> [ 46.168801] rsa_enc+0x1f0/0x3a0
> [ 46.168806] pkcs1pad_verify+0x4c4/0x750
> [ 46.168815] public_key_verify_signature+0x58b/0xac0
> [ 46.168821] pkcs7_validate_trust+0x3bd/0x710
> [ 46.168830] verify_pkcs7_signature+0xe8/0x1b0
> [ 46.168837] mod_verify_sig+0x1d4/0x2a0
> [ 46.168842] load_module+0x1689/0x6590
> [ 46.168847] __do_sys_finit_module+0x192/0x1c0
> [ 46.168852] do_syscall_64+0xa4/0x540
> [ 46.168857] entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> [ 46.168864] Freed by task 499:
> [ 46.168869] __kasan_slab_free+0x11d/0x160
> [ 46.168874] kfree+0x151/0x650
> [ 46.168878] mpi_powm+0x621/0x2360
> [ 46.168883] rsa_enc+0x1f0/0x3a0
> [ 46.168887] pkcs1pad_verify+0x4c4/0x750
> [ 46.168892] public_key_verify_signature+0x58b/0xac0
> [ 46.168897] pkcs7_validate_trust+0x3bd/0x710
> [ 46.168902] verify_pkcs7_signature+0xe8/0x1b0
> [ 46.168906] mod_verify_sig+0x1d4/0x2a0
> [ 46.168911] load_module+0x1689/0x6590
> [ 46.168916] __do_sys_finit_module+0x192/0x1c0
> [ 46.168921] do_syscall_64+0xa4/0x540
> [ 46.168925] entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> [ 46.168933] The buggy address belongs to the object at ffff8803400da588
> which belongs to the cache kmalloc-2048 of size 2048
> [ 46.168938] The buggy address is located 128 bytes inside of
> 2048-byte region [ffff8803400da588, ffff8803400dad88)
> [ 46.168942] The buggy address belongs to the page:
> [ 46.168947] page:ffffea000d003600 count:1 mapcount:0
> mapping:ffff880355011540 index:0x0 compound_mapcount: 0
> [ 46.169272] flags: 0x2fffff80008100(slab|head)
> [ 46.169358] raw: 002fffff80008100 ffffea000d13a608 ffffea000d43e608
> ffff880355011540
> [ 46.169364] raw: 0000000000000000 00000000000d000d 00000001ffffffff
> 0000000000000000
> [ 46.169369] page dumped because: kasan: bad access detected
>
> [ 46.169377] Memory state around the buggy address:
> [ 46.169383] ffff8803400da500: fc fc fc fc fc fc fc fc fc fc fc fc fc
> fc fc fc
> [ 46.169388] ffff8803400da580: fc fb fb fb fb fb fb fb fb fb fb fb fb
> fb fb fb
> [ 46.169394] >ffff8803400da600: fb fb fb fb fb fb fb fb fb fb fb fb fb
> fb fb fb
> [ 46.169398] ^
> [ 46.169403] ffff8803400da680: fb fb fb fb fb fb fb fb fb fb fb fb fb
> fb fb fb
> [ 46.169408] ffff8803400da700: fb fb fb fb fb fb fb fb fb fb fb fb fb
> fb fb fb
> [ 46.169427]
> ==================================================================
> [ 46.169431] Disabling lock debugging due to kernel taint
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH] net: Remove some unneeded semicolon
From: zhong jiang @ 2018-08-05 13:29 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: davem, wensong, horms, ja, netdev, linux-kernel
In-Reply-To: <a274184c-c8e8-37de-492c-596f038337d0@cogentembedded.com>
On 2018/8/5 2:08, Sergei Shtylyov wrote:
> On 08/04/2018 02:41 PM, zhong jiang wrote:
>
>> That semicolon is not unneeded , Just remove them.
> s/un//, right? ;-)
> That and you suddenly switch from singular to plural.
:-[ I guess that David has corrected this.
Thanks
zhong jiang
>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> MBR, Sergei
>
>
^ permalink raw reply
* Re: [PATCH net] l2tp: fix missing refcount drop in pppol2tp_tunnel_ioctl()
From: Guillaume Nault @ 2018-08-05 11:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jchapman
In-Reply-To: <20180803.124222.615955511660952852.davem@davemloft.net>
On Fri, Aug 03, 2018 at 12:42:22PM -0700, David Miller wrote:
> From: Guillaume Nault <g.nault@alphalink.fr>
> Date: Fri, 3 Aug 2018 17:00:11 +0200
>
> > If 'session' is not NULL and is not a PPP pseudo-wire, then we fail to
> > drop the reference taken by l2tp_session_get().
> >
> > Fixes: ecd012e45ab5 ("l2tp: filter out non-PPP sessions in pppol2tp_tunnel_ioctl()")
> > Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
> > ---
> > Sorry for the stupid mistake. I guess I got blinded by the apparent
> > simplicity of the bug when I wrote the original patch.
>
> Applied, thanks.
>
> I'm pretty sure I backported the commit this fixes, so I'm queueing
> this up for -stable as well.
>
Well, I think it wasn't. I didn't receive any notification from the
stable team about it and I don't see it in Greg's stable queue nor
in any -stable tree.
Also, we'd have to queue 90904ff5f958 ("l2tp: fix pseudo-wire type for
sessions created by pppol2tp_connect()") first, which is necessary for
properly identifying PPP sessions.
To recapitulate, three patches are needed to fix the original bug:
* 90904ff5f958 ("l2tp: fix pseudo-wire type for sessions created by
pppol2tp_connect()"): allows later patches to check if a session is
PPP.
* ecd012e45ab5 ("l2tp: filter out non-PPP sessions in
pppol2tp_tunnel_ioctl()"): refuses calling pppol2tp_session_ioctl()
on non-PPP sessions. This fixes an invalid pointer dereference when
the session is Ethernet. Unfortunately it fails to drop the
reference it takes on the session.
* f664e37dcc52 ("l2tp: fix missing refcount drop in
pppol2tp_tunnel_ioctl()"): fixes the memory leak introduced by the
previous patch.
^ permalink raw reply
* Re: [PATCH net-next 0/6] virtio_net: Add ethtool stat items
From: Tariq Toukan @ 2018-08-05 13:15 UTC (permalink / raw)
To: David Miller, mst, toshiaki.makita1, makita.toshiaki
Cc: ranro, netdev, Eran Ben Elisha, virtualization, Maor Gottlieb
In-Reply-To: <20180725.125909.840615930497803596.davem@davemloft.net>
On 25/07/2018 10:59 PM, David Miller wrote:
> From: "Michael S. Tsirkin" <mst@redhat.com>
> Date: Wed, 25 Jul 2018 12:40:12 +0300
>
>> On Mon, Jul 23, 2018 at 11:36:03PM +0900, Toshiaki Makita wrote:
>>> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>>
>>> Add some ethtool stat items useful for performance analysis.
>>>
>>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>
>> Series:
>>
>> Acked-by: Michael S. Tsirkin <mst@redhat.com>
>
> Series applied.
>
>> Patch 1 seems appropriate for stable, even though it's minor.
>
> Ok, I'll put patch #1 also into 'net' and queue it up for -stable.
>
> Thanks.
>
Hi,
Our verification team encountered the following degradation, introduced
by this series. Please check KASAN bug report below.
We tested before and after the series, but didn't bisect within it. We
can do if necessary.
Thanks,
Tariq
[ 46.166544] BUG: KASAN: use-after-free in virtnet_poll+0xd9c/0xfd1
[virtio_net]
[ 46.166593] Read of size 8 at addr ffff8803400da608 by task ip/1013
[ 46.166603] CPU: 3 PID: 1013 Comm: ip Not tainted
4.18.0-rc6-for-upstream-dbg-2018-07-26_19-45-52-64 #1
[ 46.166606] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.10.2-1ubuntu1 04/01/2014
[ 46.166609] Call Trace:
[ 46.166613] <IRQ>
[ 46.166624] dump_stack+0xf0/0x17b
[ 46.166647] ? show_regs_print_info+0x5/0x5
[ 46.166654] ? printk+0x9c/0xc3
[ 46.166661] ? kmsg_dump_rewind_nolock+0xf5/0xf5
[ 46.166677] ? virtnet_poll+0xd9c/0xfd1 [virtio_net]
[ 46.166685] print_address_description+0xea/0x380
[ 46.166701] ? virtnet_poll+0xd9c/0xfd1 [virtio_net]
[ 46.166711] kasan_report+0x1dd/0x460
[ 46.166727] ? virtnet_poll+0xd9c/0xfd1 [virtio_net]
[ 46.166743] virtnet_poll+0xd9c/0xfd1 [virtio_net]
[ 46.166767] ? receive_buf+0x2e30/0x2e30 [virtio_net]
[ 46.166796] ? sched_clock_cpu+0x18/0x2b0
[ 46.166809] ? print_irqtrace_events+0x280/0x280
[ 46.166817] ? print_irqtrace_events+0x280/0x280
[ 46.166830] ? rcu_process_callbacks+0xc5e/0x12d0
[ 46.166838] ? kvm_clock_read+0x1f/0x30
[ 46.166857] ? mark_held_locks+0xd5/0x170
[ 46.166867] ? net_rx_action+0x2aa/0x10e0
[ 46.166882] net_rx_action+0x4bc/0x10e0
[ 46.166906] ? napi_complete_done+0x480/0x480
[ 46.166925] ? print_irqtrace_events+0x280/0x280
[ 46.166935] ? sched_clock+0x5/0x10
[ 46.166952] ? __lock_is_held+0xcb/0x1a0
[ 46.166982] __do_softirq+0x2c4/0xdf4
[ 46.167010] do_softirq_own_stack+0x2a/0x40
[ 46.167031] </IRQ>
[ 46.167038] ? virtnet_napi_enable+0x37/0xa0 [virtio_net]
[ 46.167044] do_softirq.part.11+0x69/0x70
[ 46.167065] __local_bh_enable_ip+0x1d9/0x250
[ 46.167076] virtnet_open+0x13c/0x440 [virtio_net]
[ 46.167099] __dev_open+0x1cf/0x390
[ 46.167108] ? dev_set_rx_mode+0x30/0x30
[ 46.167113] ? __local_bh_enable_ip+0xf7/0x250
[ 46.167124] ? trace_hardirqs_on_caller+0x38d/0x6c0
[ 46.167130] ? __dev_change_flags+0x18d/0x630
[ 46.167142] __dev_change_flags+0x469/0x630
[ 46.167152] ? dev_set_allmulti+0x10/0x10
[ 46.167157] ? __lock_acquire+0x9c1/0x4b50
[ 46.167166] ? print_irqtrace_events+0x280/0x280
[ 46.167174] ? kvm_clock_read+0x1f/0x30
[ 46.167191] ? rtnetlink_put_metrics+0x530/0x530
[ 46.167205] dev_change_flags+0x8b/0x160
[ 46.167236] do_setlink+0xa17/0x39f0
[ 46.167248] ? sched_clock_cpu+0x18/0x2b0
[ 46.167267] ? rtnl_dump_ifinfo+0xd20/0xd20
[ 46.167277] ? print_irqtrace_events+0x280/0x280
[ 46.167285] ? kvm_clock_read+0x1f/0x30
[ 46.167316] ? debug_show_all_locks+0x3b0/0x3b0
[ 46.167321] ? kvm_sched_clock_read+0x5/0x10
[ 46.167327] ? sched_clock+0x5/0x10
[ 46.167333] ? sched_clock_cpu+0x18/0x2b0
[ 46.167382] ? memset+0x1f/0x40
[ 46.167408] ? nla_parse+0x8c/0x3f0
[ 46.167419] ? rtnetlink_put_metrics+0x530/0x530
[ 46.167427] ? kvm_sched_clock_read+0x5/0x10
[ 46.167433] ? sched_clock+0x5/0x10
[ 46.167439] ? sched_clock_cpu+0x18/0x2b0
[ 46.167457] rtnl_newlink+0x9dc/0x13a0
[ 46.167484] ? rtnl_link_unregister+0x2b0/0x2b0
[ 46.167513] ? kvm_clock_read+0x1f/0x30
[ 46.167538] ? print_irqtrace_events+0x280/0x280
[ 46.167546] ? kvm_clock_read+0x1f/0x30
[ 46.167551] ? kvm_sched_clock_read+0x5/0x10
[ 46.167557] ? sched_clock+0x5/0x10
[ 46.167562] ? sched_clock_cpu+0x18/0x2b0
[ 46.167567] ? kvm_clock_read+0x1f/0x30
[ 46.167598] ? __lock_acquire+0x9c1/0x4b50
[ 46.167640] ? debug_show_all_locks+0x3b0/0x3b0
[ 46.167646] ? kvm_clock_read+0x1f/0x30
[ 46.167651] ? kvm_sched_clock_read+0x5/0x10
[ 46.167673] ? debug_show_all_locks+0x3b0/0x3b0
[ 46.167698] ? is_bpf_text_address+0x87/0x130
[ 46.167707] ? print_irqtrace_events+0x280/0x280
[ 46.167714] ? kvm_clock_read+0x1f/0x30
[ 46.167718] ? kvm_sched_clock_read+0x5/0x10
[ 46.167723] ? sched_clock+0x5/0x10
[ 46.167728] ? sched_clock_cpu+0x18/0x2b0
[ 46.167753] ? get_lock_stats+0x18/0x160
[ 46.167877] ? __lock_is_held+0xcb/0x1a0
[ 46.167908] rtnetlink_rcv_msg+0x575/0xaa0
[ 46.167913] ? kvm_clock_read+0x1f/0x30
[ 46.167925] ? validate_linkmsg+0x900/0x900
[ 46.167945] ? netlink_deliver_tap+0x1cc/0xf30
[ 46.167950] ? kvm_clock_read+0x1f/0x30
[ 46.167965] netlink_rcv_skb+0x13c/0x3a0
[ 46.167972] ? validate_linkmsg+0x900/0x900
[ 46.167984] ? netlink_ack+0xcd0/0xcd0
[ 46.168030] netlink_unicast+0x45a/0x6a0
[ 46.168061] ? netlink_attachskb+0x770/0x770
[ 46.168075] ? import_iovec+0xa8/0x460
[ 46.168093] netlink_sendmsg+0x68e/0xdf0
[ 46.168127] ? netlink_unicast+0x6a0/0x6a0
[ 46.168133] ? copy_msghdr_from_user+0x216/0x350
[ 46.168160] ? netlink_unicast+0x6a0/0x6a0
[ 46.168168] sock_sendmsg+0xdb/0x160
[ 46.168193] ___sys_sendmsg+0x6b3/0xbd0
[ 46.168207] ? copy_msghdr_from_user+0x350/0x350
[ 46.168221] ? do_raw_spin_unlock+0xae/0x310
[ 46.168248] ? _raw_spin_unlock+0x2e/0x50
[ 46.168257] ? __handle_mm_fault+0xb65/0x2e90
[ 46.168278] ? handle_mm_fault+0x28f/0xa70
[ 46.168284] ? kvm_clock_read+0x1f/0x30
[ 46.168289] ? kvm_sched_clock_read+0x5/0x10
[ 46.168303] ? __do_page_fault+0x549/0xd00
[ 46.168308] ? kvm_clock_read+0x1f/0x30
[ 46.168313] ? kvm_sched_clock_read+0x5/0x10
[ 46.168318] ? sched_clock+0x5/0x10
[ 46.168324] ? sched_clock_cpu+0x18/0x2b0
[ 46.168336] ? __fget_light+0x5c/0x280
[ 46.168357] ? __sys_sendmsg+0xd2/0x170
[ 46.168362] __sys_sendmsg+0xd2/0x170
[ 46.168371] ? __ia32_sys_shutdown+0x90/0x90
[ 46.168382] ? handle_mm_fault+0x363/0xa70
[ 46.168397] ? up_read+0x1c/0x130
[ 46.168403] ? __do_page_fault+0x549/0xd00
[ 46.168443] ? do_syscall_64+0x18/0x540
[ 46.168459] do_syscall_64+0xa4/0x540
[ 46.168470] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 46.168477] RIP: 0033:0x7fa59e680087
[ 46.168481] Code: 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 80 00 00
00 00 8b 05 aa 97 2c 00 48 63 d2 48 63 ff 85 c0 75 18 b8 2e 00 00 00 0f
05 <48> 3d 00 f0 ff ff 77 59 f3 c3 0f 1f 80 00 00 00 00 53 48 89 f3 48
[ 46.168717] RSP: 002b:00007ffe83f2fef8 EFLAGS: 00000246 ORIG_RAX:
000000000000002e
[ 46.168726] RAX: ffffffffffffffda RBX: 00000000006744c0 RCX:
00007fa59e680087
[ 46.168731] RDX: 0000000000000000 RSI: 00007ffe83f2ff40 RDI:
0000000000000003
[ 46.168735] RBP: 000000005b5d727c R08: 0000000000000001 R09:
fefefeff77686d74
[ 46.168740] R10: 0000000000000006 R11: 0000000000000246 R12:
00007ffe83f38000
[ 46.168744] R13: 0000000000000000 R14: 00007ffe83f38728 R15:
00007ffe83f37fd8
[ 46.168778] Allocated by task 499:
[ 46.168784] kasan_kmalloc+0xa0/0xd0
[ 46.168789] __kmalloc+0x191/0x3a0
[ 46.168795] mpi_powm+0x956/0x2360
[ 46.168801] rsa_enc+0x1f0/0x3a0
[ 46.168806] pkcs1pad_verify+0x4c4/0x750
[ 46.168815] public_key_verify_signature+0x58b/0xac0
[ 46.168821] pkcs7_validate_trust+0x3bd/0x710
[ 46.168830] verify_pkcs7_signature+0xe8/0x1b0
[ 46.168837] mod_verify_sig+0x1d4/0x2a0
[ 46.168842] load_module+0x1689/0x6590
[ 46.168847] __do_sys_finit_module+0x192/0x1c0
[ 46.168852] do_syscall_64+0xa4/0x540
[ 46.168857] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 46.168864] Freed by task 499:
[ 46.168869] __kasan_slab_free+0x11d/0x160
[ 46.168874] kfree+0x151/0x650
[ 46.168878] mpi_powm+0x621/0x2360
[ 46.168883] rsa_enc+0x1f0/0x3a0
[ 46.168887] pkcs1pad_verify+0x4c4/0x750
[ 46.168892] public_key_verify_signature+0x58b/0xac0
[ 46.168897] pkcs7_validate_trust+0x3bd/0x710
[ 46.168902] verify_pkcs7_signature+0xe8/0x1b0
[ 46.168906] mod_verify_sig+0x1d4/0x2a0
[ 46.168911] load_module+0x1689/0x6590
[ 46.168916] __do_sys_finit_module+0x192/0x1c0
[ 46.168921] do_syscall_64+0xa4/0x540
[ 46.168925] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 46.168933] The buggy address belongs to the object at ffff8803400da588
which belongs to the cache kmalloc-2048 of size 2048
[ 46.168938] The buggy address is located 128 bytes inside of
2048-byte region [ffff8803400da588, ffff8803400dad88)
[ 46.168942] The buggy address belongs to the page:
[ 46.168947] page:ffffea000d003600 count:1 mapcount:0
mapping:ffff880355011540 index:0x0 compound_mapcount: 0
[ 46.169272] flags: 0x2fffff80008100(slab|head)
[ 46.169358] raw: 002fffff80008100 ffffea000d13a608 ffffea000d43e608
ffff880355011540
[ 46.169364] raw: 0000000000000000 00000000000d000d 00000001ffffffff
0000000000000000
[ 46.169369] page dumped because: kasan: bad access detected
[ 46.169377] Memory state around the buggy address:
[ 46.169383] ffff8803400da500: fc fc fc fc fc fc fc fc fc fc fc fc fc
fc fc fc
[ 46.169388] ffff8803400da580: fc fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb
[ 46.169394] >ffff8803400da600: fb fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb
[ 46.169398] ^
[ 46.169403] ffff8803400da680: fb fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb
[ 46.169408] ffff8803400da700: fb fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb
[ 46.169427]
==================================================================
[ 46.169431] Disabling lock debugging due to kernel taint
^ permalink raw reply
* Re: linux-lora.git and LoRaWAN (was: [RFC net-next 00/15] net: A socket API for LoRa)
From: Jian-Hong Pan @ 2018-08-05 12:49 UTC (permalink / raw)
To: Andreas Färber
Cc: Ben Whitten, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jiri Pirko,
Marcel Holtmann, David S. Miller, Matthias Brugger, Janus Piwek,
Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm,
Jan Jongboom, contact-GpjyyWaKhplWk0Htik3J/w@public.gmane.org,
Brian Ray
In-Reply-To: <6dda350b-66ab-b5ab-41ed-319b27e4e28c-l3A5Bk7waGM@public.gmane.org>
Hi Andreas,
2018-08-03 16:44 GMT+08:00 Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>:
> Hi Jian-Hong,
>
> Am 02.08.2018 um 09:52 schrieb Jian-Hong Pan:
>> 2018-07-18 19:28 GMT+08:00 Ben Whitten <Ben.Whitten-xJ1y+ldTOs21Z/+hSey0Gg@public.gmane.org>:
>>>> 1) PF_LORA/AF_LORA and associated identifiers are
>>>> proposed to represent
>>>> this technology. While for an SX1276 [...] it
>>>> might work to
>>>> layer LoRaWAN as a protocol option for PF_LORA and
>> add
>>>> LoRaWAN address
>>>> fields to the union in my sockaddr_lora, how would that
>>>> work for devices
>>>> that only support LoRaWAN but not pure LoRa? Do we
>>>> need both AF_LORA and
>>>> AF_LORAWAN, or just a separate ETH_P_LORAWAN or
>>>> ARPHRD_LORAWAN?
> [...]
>>>> Meanwhile my attempt to play with netlink during SUSE
>>>> Hackweek has been
>>>> going slow and I could use some guidance or a volunteer to
>>>> contribute: I
>>>> have a bare skeleton of registration, commands, attributes
>>>> and multicast
>>>> groups, but no plan yet how to connect that to the actual
>>>> drivers to
>>>> query or apply the settings...
>>>
>>> Happy to help, I will be starting from zero on netlink but I can contribute my existing work incorporating Marks comments for sx1301 etal.
>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/li
>>>> nux-lora.git/tree/net/lora/netlink.c?h=lora-next
>>
>> Is this the repository used for the LoRa subsystem now?!!!
>> If it is, than great!
>
> Yes, my linux-lora.git contains this RFC patchset (modulo SX1276 fixes
> spotted by kbuild bot) plus a new serdev driver for another module and
> ongoing work by Ben and me for refactoring SX1301. It's monitored by the
> 0-day test service (kbuild bot).
>
> As this patchset was an RFC and does not have any Acked-bys from
> maintainers, the tree does not have a for-next branch integrated into
> linux-next on basis of 4.18-rc1, but instead (like my personal GitHub
> tree before) has a lora-next branch that rebases as patch queue on top
> of linux-next for now.
>
> The intent is to allow collaboration on getting things into a state that
> I can later submit a clean (squashed) RFC v2 for review, with all issues
> raised for this v1 addressed.
>
> For contributing patches to my linux-lora.git I suggest to use
> --subject-prefix="PATCH lora-next" to distinguish from net-next.
> And I just realize I should add a MAINTAINERS entry in my tree to make
> sure patches CC me, too. (I do monitor netdev for patches with subject
> "lora", but chances are someone might omit that.)
>
>> As the previous mails, I am trying to implement the LoRaWAN
>> specification as the soft MAC as the MAC layer over LoRa PHY.
>> This is the the talk about LoRaWAN class module I gave in Netdev Conf
>> https://www.slideshare.net/chienhungpan/lorawan-class-module-and-subsystem
>>
>> The expectation is:
>>
>> socket APIs:
>> send and receive the data
>> ------------------------------------------------------------
>> LoRaWAN class module implements MAC:
>> append the header/footer, encryption/decryption, timing slot and MAC commands
>> ------------------------------------------------------------
>> LoRa device drivers:
>> send and receive the messages for MAC layer
>> ------------------------------------------------------------
>> LoRa devices
>
> Thanks for sharing your slides. We seem to be in alignment for the
> abstract concept above. The devil is in the implementation details. ^.-
>
>> Is it possible that combine the LoRaWAN class module I implemented?
>
> Yes, as stated in this cover letter, I would love if you could help
> merge your LoRaWAN implementation with my driver framework. Comparing
> 802.15.4 and 802.11, I think MAC code should go into net/maclorawan/ and
> then is a fairly independent module, with you as maintainer.
>
>> I start from the simplest class A end device's behavior, especially
>> the timing slot.
>> Also the encryption/decryption for uplink/downlink data messages.
>> I can send it as patches.
>>
>> However, I have 2 problems right now.
>> 1. Which Address and Protocol Family should we use? PF_LORA or PF_LORAWAN?
>
> That was one of the questions I raised above. I now think we need both.
> I'm not yet too deep into LoRaWAN, but from the AT command interfaces
> I've seen there's confirmed and unconfirmed transmission modes that with
> PF_LORAWAN might be mapped to SOCK_STREAM and SOCK_DGRAM. Or do you see
> a way of doing both on a single PF_LORA SOCK_LORAWAN socket?
>
>> 2. To test the LoRaWAN class module, adding more procedures in LoRa
>> device drivers to register as a LoRaWAN device is needed.
>
> No, I don't think so. There are (at least) two types of devices, LoRaWAN
> and LoRa devices. The SX1276 is a pure LoRa device and thus should only
> expose a LoRa network device. It'll be the task of the maclorawan module
> to translate between the two layers, not the business of the device
> driver; SX1276 should receive a ready-to-send LoRa skb. For Ethernet,
> PF_INET and PF_INET6 don't need separate devices either, both use eth0.
>
> What I do think we need is your struct lora_hw, maybe renamed to
> lora_phy. That could be the missing piece for registration of the device
> drivers with nllora module?
> Note that similarly we'll also need an nllorawan module that needs to
> work both with your maclorawan and with some of my device drivers that
> implement the MAC in an MCU.
Let me think these twice.
> Additionally I've been looking into socket options at PF_LORA dgram
> layer for some radio options, but discarded that again for lack of
> precedence. Basically I wondered whether we could allow to choose SF,
> bandwidth, etc. on socket level and then apply those settings before
> sending one packet rather than expecting a global netlink operation that
> affects all sockets for that interface.
According to the LoRaWAN Regional Parameters, we should have the APIs
to set the SF, frequency, bandwidth ...
The idea is: LoRaWAN class module gets the region of this device and
the device's abilities. Then LoRaWAN class module calls the callback
functions to set the related parameters: SF, frequency, bandwidth ...
And of course, the setting actions only happen in the idle, standby or
stop status.
1. Interface is being startup.
2. Requested by MAC command.
But let start from simple case and add more features and complexity in
the future.
By the way, I am rearranging the module's code and try to make it
could be patches.
Regards,
Jian-Hong Pan
^ 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