* [PATCH 5/7] net: wireless: wcn36xx: swallow two wcn3620 IND messages
From: Andy Green @ 2015-01-18 5:11 UTC (permalink / raw)
To: Kalle Valo, Eugene Krasnikov; +Cc: wcn36xx, linux-wireless, netdev
In-Reply-To: <20150118050741.31866.36490.stgit@114-36-241-182.dynamic.hinet.net>
WCN3620 can asynchronously send two new kinds of indication message,
since we can't handle them just accept them quietly.
Signed-off-by: Andy Green <andy.green@linaro.org>
---
drivers/net/wireless/ath/wcn36xx/smd.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c b/drivers/net/wireless/ath/wcn36xx/smd.c
index 6398693..819741c 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -2061,6 +2061,8 @@ static void wcn36xx_smd_rsp_process(struct wcn36xx *wcn, void *buf, size_t len)
complete(&wcn->hal_rsp_compl);
break;
+ case WCN36XX_HAL_COEX_IND:
+ case WCN36XX_HAL_AVOID_FREQ_RANGE_IND:
case WCN36XX_HAL_OTA_TX_COMPL_IND:
case WCN36XX_HAL_MISSED_BEACON_IND:
case WCN36XX_HAL_DELETE_STA_CONTEXT_IND:
@@ -2107,6 +2109,10 @@ static void wcn36xx_ind_smd_work(struct work_struct *work)
msg_header = (struct wcn36xx_hal_msg_header *)hal_ind_msg->msg;
switch (msg_header->msg_type) {
+ case WCN36XX_HAL_COEX_IND:
+ break;
+ case WCN36XX_HAL_AVOID_FREQ_RANGE_IND:
+ break;
case WCN36XX_HAL_OTA_TX_COMPL_IND:
wcn36xx_smd_tx_compl_ind(wcn,
hal_ind_msg->msg,
^ permalink raw reply related
* [PATCH 4/7] net: wireless: wcn36xx: introduce WCN36XX_HAL_AVOID_FREQ_RANGE_IND
From: Andy Green @ 2015-01-18 5:11 UTC (permalink / raw)
To: Kalle Valo, Eugene Krasnikov; +Cc: wcn36xx, linux-wireless, netdev
In-Reply-To: <20150118050741.31866.36490.stgit@114-36-241-182.dynamic.hinet.net>
WCN3620 firmware introduces a new async indication, we need to
add it as a known message type so we can accept it
Signed-off-by: Andy Green <andy.green@linaro.org>
---
drivers/net/wireless/ath/wcn36xx/hal.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/ath/wcn36xx/hal.h b/drivers/net/wireless/ath/wcn36xx/hal.h
index a1f1127..b947de0 100644
--- a/drivers/net/wireless/ath/wcn36xx/hal.h
+++ b/drivers/net/wireless/ath/wcn36xx/hal.h
@@ -345,6 +345,8 @@ enum wcn36xx_hal_host_msg_type {
WCN36XX_HAL_DHCP_START_IND = 189,
WCN36XX_HAL_DHCP_STOP_IND = 190,
+ WCN36XX_HAL_AVOID_FREQ_RANGE_IND = 233,
+
WCN36XX_HAL_MSG_MAX = WCN36XX_HAL_MSG_TYPE_MAX_ENUM_SIZE
};
^ permalink raw reply related
* [PATCH 3/7] net: wireless: wcn36xx: use 3680 dxe regs for 3620
From: Andy Green @ 2015-01-18 5:10 UTC (permalink / raw)
To: Kalle Valo, Eugene Krasnikov; +Cc: wcn36xx, linux-wireless, netdev
In-Reply-To: <20150118050741.31866.36490.stgit@114-36-241-182.dynamic.hinet.net>
Between 3620, 3660 and 3680, only 3660 has a different dxe register
Signed-off-by: Andy Green <andy.green@linaro.org>
---
drivers/net/wireless/ath/wcn36xx/dxe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/dxe.c b/drivers/net/wireless/ath/wcn36xx/dxe.c
index 73f12f1..334f265 100644
--- a/drivers/net/wireless/ath/wcn36xx/dxe.c
+++ b/drivers/net/wireless/ath/wcn36xx/dxe.c
@@ -46,7 +46,7 @@ static void wcn36xx_dxe_write_register(struct wcn36xx *wcn, int addr, int data)
#define wcn36xx_dxe_write_register_x(wcn, reg, reg_data) \
do { \
- if (wcn->chip_version == WCN36XX_CHIP_3680) \
+ if (wcn->chip_version != WCN36XX_CHIP_3660) \
wcn36xx_dxe_write_register(wcn, reg ## _3680, reg_data); \
else \
wcn36xx_dxe_write_register(wcn, reg ## _3660, reg_data); \
^ permalink raw reply related
* [PATCH 2/7] net: wireless: wcn36xx: get chip type from platform ops
From: Andy Green @ 2015-01-18 5:10 UTC (permalink / raw)
To: Kalle Valo, Eugene Krasnikov; +Cc: wcn36xx, linux-wireless, netdev
In-Reply-To: <20150118050741.31866.36490.stgit@114-36-241-182.dynamic.hinet.net>
Autodetecting the chip type does not work well.
Stop attempting to do it and require a platform op
that tells us what the chip is.
Signed-off-by: Andy Green <andy.green@linaro.org>
---
drivers/net/wireless/ath/wcn36xx/main.c | 18 +++++-------------
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 1 +
2 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c b/drivers/net/wireless/ath/wcn36xx/main.c
index 7dd8873..c4178c7 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -221,17 +221,6 @@ static void wcn36xx_feat_caps_info(struct wcn36xx *wcn)
}
}
-static void wcn36xx_detect_chip_version(struct wcn36xx *wcn)
-{
- if (get_feat_caps(wcn->fw_feat_caps, DOT11AC)) {
- wcn36xx_info("Chip is 3680\n");
- wcn->chip_version = WCN36XX_CHIP_3680;
- } else {
- wcn36xx_info("Chip is 3660\n");
- wcn->chip_version = WCN36XX_CHIP_3660;
- }
-}
-
static int wcn36xx_start(struct ieee80211_hw *hw)
{
struct wcn36xx *wcn = hw->priv;
@@ -286,8 +275,6 @@ static int wcn36xx_start(struct ieee80211_hw *hw)
wcn36xx_feat_caps_info(wcn);
}
- wcn36xx_detect_chip_version(wcn);
-
/* DMA channel initialization */
ret = wcn36xx_dxe_init(wcn);
if (ret) {
@@ -1023,6 +1010,11 @@ static int wcn36xx_probe(struct platform_device *pdev)
wcn->hw = hw;
wcn->dev = &pdev->dev;
wcn->ctrl_ops = pdev->dev.platform_data;
+ if (!wcn->ctrl_ops->get_chip_type) {
+ dev_err(&pdev->dev, "Missing ops->get_chip_type\n");
+ return -EINVAL;
+ }
+ wcn->chip_version = wcn->ctrl_ops->get_chip_type();
mutex_init(&wcn->hal_mutex);
diff --git a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
index a5366b6..04793c6 100644
--- a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
+++ b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
@@ -110,6 +110,7 @@ struct wcn36xx_platform_ctrl_ops {
void (*close)(void);
int (*tx)(char *buf, size_t len);
int (*get_hw_mac)(u8 *addr);
+ int (*get_chip_type)(void);
int (*smsm_change_state)(u32 clear_mask, u32 set_mask);
};
^ permalink raw reply related
* [PATCH 1/7] net: wireless: wcn36xx: add wcn3620 chip type definition
From: Andy Green @ 2015-01-18 5:10 UTC (permalink / raw)
To: Kalle Valo, Eugene Krasnikov
Cc: wcn36xx-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150118050741.31866.36490.stgit-FDDIDLfWL9/T9rR/E2HzMujRB4CPm7EUkgzjau31qRg@public.gmane.org>
Convert the list of chip types to an enum, add the default
UNKNOWN type and a type for WCN3620 chip
Signed-off-by: Andy Green <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
index f0fb81d..a5366b6 100644
--- a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
+++ b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
@@ -93,6 +93,13 @@ struct nv_data {
u8 table;
};
+enum wcn36xx_chip_type {
+ WCN36XX_CHIP_UNKNOWN,
+ WCN36XX_CHIP_3660,
+ WCN36XX_CHIP_3680,
+ WCN36XX_CHIP_3620,
+};
+
/* Interface for platform control path
*
* @open: hook must be called when wcn36xx wants to open control channel.
@@ -179,7 +186,7 @@ struct wcn36xx {
u8 fw_minor;
u8 fw_major;
u32 fw_feat_caps[WCN36XX_HAL_CAPS_SIZE];
- u32 chip_version;
+ enum wcn36xx_chip_type chip_version;
/* extra byte for the NULL termination */
u8 crm_version[WCN36XX_HAL_VERSION_LENGTH + 1];
@@ -227,9 +234,6 @@ struct wcn36xx {
};
-#define WCN36XX_CHIP_3660 0
-#define WCN36XX_CHIP_3680 1
^ permalink raw reply related
* [PATCH 0/7] net: wireless: wcn36xx: add basic wcn3620 support
From: Andy Green @ 2015-01-18 5:10 UTC (permalink / raw)
To: Kalle Valo, Eugene Krasnikov
Cc: wcn36xx-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
The following series adds some basic wcn3620 support to the
mainline wcn36xx driver.
- modify the chip detection to be told which chip from
platform ops, which can get it from Device Tree... the
existing detection is just assume it's a wcn3680 if it
has AC mode which is not enough
- Adapt the DXE register selection to use 3680 mode for
3620 as well
- Add a couple of async "indication" messages which can
appear down smd on 3620, just accept and ignore
- Accept a modified form of trigger_ba response that is
sent by the wcn3620 firmware, if device is a 3620
- Disable powersaving mode if 3620
With these the 3620 can associate and work for a while
before needing to be forcibly reassociated again.
It's tested on an msm8916-QRD "phone" dev platform that
includes wcn3620.
---
Andy Green (7):
net: wireless: wcn36xx: add wcn3620 chip type definition
net: wireless: wcn36xx: get chip type from platform ops
net: wireless: wcn36xx: use 3680 dxe regs for 3620
net: wireless: wcn36xx: introduce WCN36XX_HAL_AVOID_FREQ_RANGE_IND
net: wireless: wcn36xx: swallow two wcn3620 IND messages
net: wireless: wcn36xx: remove powersaving for wcn3620
net: wireless: wcn36xx: handle new trigger_ba format
drivers/net/wireless/ath/wcn36xx/dxe.c | 2 +-
drivers/net/wireless/ath/wcn36xx/hal.h | 2 ++
drivers/net/wireless/ath/wcn36xx/main.c | 22 +++++++-----------
drivers/net/wireless/ath/wcn36xx/smd.c | 34 ++++++++++++++++++++++++++--
drivers/net/wireless/ath/wcn36xx/smd.h | 9 +++++++
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 13 +++++++----
6 files changed, 62 insertions(+), 20 deletions(-)
--
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] niu: remove one compound_head() call
From: David Miller @ 2015-01-18 4:59 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1421415570.11734.130.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 16 Jan 2015 05:39:30 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> After a "page = alloc_page(mask);", we do not need to use
> compound_head() : page already points to the right place.
>
> This would be true even if using alloc_pages().
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] socket: use ki_nbytes instead of iov_length()
From: David Miller @ 2015-01-18 4:58 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: viro, netdev
In-Reply-To: <1421415309-4639-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Fri, 16 Jan 2015 14:35:09 +0100
> This field already contains the length of the iovec, no need to calculate it
> again.
>
> Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/5] s390: network patches for net-next
From: David Miller @ 2015-01-18 4:55 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, ursula.braun
In-Reply-To: <1421413549-56937-1-git-send-email-ubraun@linux.vnet.ibm.com>
From: Ursula Braun <ubraun@linux.vnet.ibm.com>
Date: Fri, 16 Jan 2015 14:05:44 +0100
> here are some s390 related patches for net-next
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net] net: sctp: fix race for one-to-many sockets in sendmsg's auto associate
From: David Miller @ 2015-01-18 4:53 UTC (permalink / raw)
To: dborkman; +Cc: vyasevich, netdev, linux-sctp
In-Reply-To: <1421336075-25061-1-git-send-email-dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Thu, 15 Jan 2015 16:34:35 +0100
...
> The fix defers waiting after sctp_primitive_ASSOCIATE() and
> sctp_primitive_SEND() succeeded, so that DATA chunks cooked up
> from sctp_sendmsg() have already been placed into the output
> queue through the side-effect interpreter, and therefore can then
> be bundeled together with COOKIE_ECHO control chunks.
...
> Looks like this bug is from the pre-git history museum. ;)
>
> Fixes: 08707d5482df ("lksctp-2_5_31-0_5_1.patch")
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [patch net-next v5 2/2] tc: cls_bpf: rename bpf_len to bpf_num_ops
From: David Miller @ 2015-01-18 4:51 UTC (permalink / raw)
To: jiri; +Cc: netdev, jhs, dborkman, ast, hannes, gaofeng
In-Reply-To: <1421311960-14744-2-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 15 Jan 2015 09:52:40 +0100
> It was suggested by DaveM to change the name as "len" might indicate
> unit bytes.
>
> Suggested-by: David Miller <davem@davemloft.net>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> Acked-by: Daniel Borkmann <dborkman@redhat.com>
Applied.
^ permalink raw reply
* Re: [patch net-next v5 1/2] tc: add BPF based action
From: David Miller @ 2015-01-18 4:51 UTC (permalink / raw)
To: jiri; +Cc: netdev, jhs, dborkman, ast, hannes, gaofeng
In-Reply-To: <1421311960-14744-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 15 Jan 2015 09:52:39 +0100
> This action provides a possibility to exec custom BPF code.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2] bridge: fix setlink/dellink notifications
From: David Miller @ 2015-01-18 4:50 UTC (permalink / raw)
To: roopa
Cc: netdev, shemminger, vyasevic, john.fastabend, tgraf, jhs, sfeldma,
jiri, wkok, ronen.arad
In-Reply-To: <1421294545-52467-1-git-send-email-roopa@cumulusnetworks.com>
From: roopa@cumulusnetworks.com
Date: Wed, 14 Jan 2015 20:02:25 -0800
> problems with bridge getlink/setlink notifications today:
> - bridge setlink generates two notifications to userspace
> - one from the bridge driver
> - one from rtnetlink.c (rtnl_bridge_notify)
> - dellink generates one notification from rtnetlink.c. Which
> means bridge setlink and dellink notifications are not
> consistent
>
> - Looking at the code it appears,
> If both BRIDGE_FLAGS_MASTER and BRIDGE_FLAGS_SELF were set,
> the size calculation in rtnl_bridge_notify can be wrong.
> Example: if you set both BRIDGE_FLAGS_MASTER and BRIDGE_FLAGS_SELF
> in a setlink request to rocker dev, rtnl_bridge_notify will
> allocate skb for one set of bridge attributes, but,
> both the bridge driver and rocker dev will try to add
> attributes resulting in twice the number of attributes
> being added to the skb. (rocker dev calls ndo_dflt_bridge_getlink)
>
> There are multiple options:
> 1) Generate one notification including all attributes from master and self:
> But, I don't think it will work, because both master and self may use
> the same attributes/policy. Cannot pack the same set of attributes in a
> single notification from both master and slave (duplicate attributes).
>
> 2) Generate one notification from master and the other notification from
> self (This seems to be ideal):
> For master: the master driver will send notification (bridge in this
> example)
> For self: the self driver will send notification (rocker in the above
> example. It can use helpers from rtnetlink.c to do so. Like the
> ndo_dflt_bridge_getlink api).
>
> This patch implements 2) (leaving the 'rtnl_bridge_notify' around to be used
> with 'self').
...
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Applied, thanks.
^ permalink raw reply
* Wireless scanning while turning off the radio problem..
From: Linus Torvalds @ 2015-01-18 3:25 UTC (permalink / raw)
To: Johannes Berg, David Miller; +Cc: Linux Wireless List, Network Development
So there seems to be some issue with unlucky timing when turning off
wireless while the driver is busy scanning. I can't reproduce this, so
it's a one-off, but it's not just ugly warnings, the kernel woudln't
scan any wireless on that device afterwards and I had to reboot to get
networking back, so there is some long-term damage.
This is with Intel wireless (iwlwifi, it's a iwl N7260 thing, rev
0x144 if anybody cares) , but the warning callbacks don't seem to be
iwl-specific.
This was a recent top-of-git kernel (3.19.0-rc4-00241-gfc7f0dd38172 to
be exact).
Anybody have any ideas? Anything in particular I should try out to
help possibly get more information?
Linus
---
[ 204.361145] iwlwifi 0000:01:00.0: RF_KILL bit toggled to disable radio.
[ 204.362358] ------------[ cut here ]------------
[ 204.362383] WARNING: CPU: 0 PID: 37 at net/wireless/core.c:1011
cfg80211_netdev_notifier_call+0x491/0x500 [cfg80211]()
[ 204.362385] Modules linked in: ccm rfcomm fuse ip6t_rpfilter
ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_nat
ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle
ip6table_security ip6table_raw ip6table_filter ip6_tables
iptable_mangle iptable_security iptable_raw bnep arc4 vfat fat
x86_pkg_temp_thermal pn544_mei mei_phy pn544 coretemp hci kvm_intel
nfc iTCO_wdt iTCO_vendor_support kvm iwlmvm uvcvideo
snd_hda_codec_realtek microcode snd_hda_codec_generic
snd_hda_codec_hdmi mac80211 videobuf2_vmalloc videobuf2_memops
videobuf2_core v4l2_common snd_hda_intel videodev snd_hda_controller
joydev btusb media hid_multitouch i2c_i801 snd_hda_codec serio_raw
iwlwifi bluetooth snd_hwdep snd_seq cfg80211 snd_seq_device
[ 204.362432] snd_pcm sony_laptop rfkill mei_me snd_timer mei snd
lpc_ich mfd_core shpchp soundcore dm_crypt i915 crct10dif_pclmul
crc32_pclmul crc32c_intel i2c_algo_bit ghash_clmulni_intel
drm_kms_helper drm i2c_core video
[ 204.362453] CPU: 0 PID: 37 Comm: kworker/0:1 Not tainted
3.19.0-rc4-00241-gfc7f0dd38172 #14
[ 204.362455] Hardware name: Sony Corporation SVP11213CXB/VAIO, BIOS
R0270V7 05/17/2013
[ 204.362464] Workqueue: events cfg80211_rfkill_sync_work [cfg80211]
[ 204.362467] 0000000000000000 ffffffffc0375870 ffffffff815eb39a
0000000000000000
[ 204.362471] ffffffff8106c357 ffff8800d3b12890 ffff8800d9e08260
0000000000000002
[ 204.362475] ffff8800d3b12000 ffff8800d9e08000 ffffffffc0350161
ffff8800d365dc00
[ 204.362479] Call Trace:
[ 204.362490] [<ffffffff815eb39a>] ? dump_stack+0x40/0x50
[ 204.362496] [<ffffffff8106c357>] ? warn_slowpath_common+0x77/0xb0
[ 204.362506] [<ffffffffc0350161>] ?
cfg80211_netdev_notifier_call+0x491/0x500 [cfg80211]
[ 204.362513] [<ffffffff814f3769>] ? __dev_remove_pack+0x39/0xa0
[ 204.362538] [<ffffffff815d9d0c>] ? __unregister_prot_hook+0xcc/0xd0
[ 204.362542] [<ffffffff815da89c>] ? packet_notifier+0x15c/0x1b0
[ 204.362549] [<ffffffff81086e65>] ? notifier_call_chain+0x45/0x70
[ 204.362552] [<ffffffff814f41a9>] ? dev_close_many+0xb9/0x110
[ 204.362556] [<ffffffff814f65da>] ? dev_close.part.87+0x2a/0x40
[ 204.362559] [<ffffffff814f6609>] ? dev_close+0x19/0x20
[ 204.362569] [<ffffffffc034f76d>] ?
cfg80211_shutdown_all_interfaces+0x3d/0xb0 [cfg80211]
[ 204.362577] [<ffffffffc034f809>] ?
cfg80211_rfkill_sync_work+0x29/0x30 [cfg80211]
[ 204.362580] [<ffffffff81081335>] ? process_one_work+0x135/0x370
[ 204.362585] [<ffffffff8107e927>] ? pwq_activate_delayed_work+0x27/0x40
[ 204.362589] [<ffffffff810818c3>] ? worker_thread+0x63/0x480
[ 204.362592] [<ffffffff81081860>] ? rescuer_thread+0x2f0/0x2f0
[ 204.362596] [<ffffffff8108606e>] ? kthread+0xce/0xf0
[ 204.362600] [<ffffffff81085fa0>] ? kthread_create_on_node+0x180/0x180
[ 204.362605] [<ffffffff815f0eac>] ? ret_from_fork+0x7c/0xb0
[ 204.362609] [<ffffffff81085fa0>] ? kthread_create_on_node+0x180/0x180
[ 204.362612] ---[ end trace d0ac2826f7d2747f ]---
[ 204.362614] ------------[ cut here ]------------
[ 204.362628] WARNING: CPU: 0 PID: 37 at net/mac80211/driver-ops.h:12
ieee80211_request_sched_scan_stop+0xdd/0xf0 [mac80211]()
[ 204.362630] wlp1s0: Failed check-sdata-in-driver check, flags: 0x4
[ 204.362631] Modules linked in: ccm rfcomm fuse ip6t_rpfilter
ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_nat
ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle
ip6table_security ip6table_raw ip6table_filter ip6_tables
iptable_mangle iptable_security iptable_raw bnep arc4 vfat fat
x86_pkg_temp_thermal pn544_mei mei_phy pn544 coretemp hci kvm_intel
nfc iTCO_wdt iTCO_vendor_support kvm iwlmvm uvcvideo
snd_hda_codec_realtek microcode snd_hda_codec_generic
snd_hda_codec_hdmi mac80211 videobuf2_vmalloc videobuf2_memops
videobuf2_core v4l2_common snd_hda_intel videodev snd_hda_controller
joydev btusb media hid_multitouch i2c_i801 snd_hda_codec serio_raw
iwlwifi bluetooth snd_hwdep snd_seq cfg80211 snd_seq_device
[ 204.362677] snd_pcm sony_laptop rfkill mei_me snd_timer mei snd
lpc_ich mfd_core shpchp soundcore dm_crypt i915 crct10dif_pclmul
crc32_pclmul crc32c_intel i2c_algo_bit ghash_clmulni_intel
drm_kms_helper drm i2c_core video
[ 204.362695] CPU: 0 PID: 37 Comm: kworker/0:1 Tainted: G W
3.19.0-rc4-00241-gfc7f0dd38172 #14
[ 204.362697] Hardware name: Sony Corporation SVP11213CXB/VAIO, BIOS
R0270V7 05/17/2013
[ 204.362703] Workqueue: events cfg80211_rfkill_sync_work [cfg80211]
[ 204.362705] 0000000000000000 ffffffffc04e3491 ffffffff815eb39a
ffff88011a697c18
[ 204.362709] ffffffff8106c357 ffff8800d9e08660 ffff8800d3b12880
00000000fffffffb
[ 204.362713] ffff8800d9e09618 ffff8800d9e08000 ffffffff8106c3d5
ffffffffc04e0e78
[ 204.362717] Call Trace:
[ 204.362723] [<ffffffff815eb39a>] ? dump_stack+0x40/0x50
[ 204.362726] [<ffffffff8106c357>] ? warn_slowpath_common+0x77/0xb0
[ 204.362730] [<ffffffff8106c3d5>] ? warn_slowpath_fmt+0x45/0x50
[ 204.362743] [<ffffffffc049374d>] ?
ieee80211_request_sched_scan_stop+0xdd/0xf0 [mac80211]
[ 204.362755] [<ffffffffc0357a33>] ?
__cfg80211_stop_sched_scan+0x73/0xb0 [cfg80211]
[ 204.362763] [<ffffffffc035016b>] ?
cfg80211_netdev_notifier_call+0x49b/0x500 [cfg80211]
[ 204.362768] [<ffffffff814f3769>] ? __dev_remove_pack+0x39/0xa0
[ 204.362772] [<ffffffff815d9d0c>] ? __unregister_prot_hook+0xcc/0xd0
[ 204.362776] [<ffffffff815da89c>] ? packet_notifier+0x15c/0x1b0
[ 204.362781] [<ffffffff81086e65>] ? notifier_call_chain+0x45/0x70
[ 204.362785] [<ffffffff814f41a9>] ? dev_close_many+0xb9/0x110
[ 204.362788] [<ffffffff814f65da>] ? dev_close.part.87+0x2a/0x40
[ 204.362792] [<ffffffff814f6609>] ? dev_close+0x19/0x20
[ 204.362800] [<ffffffffc034f76d>] ?
cfg80211_shutdown_all_interfaces+0x3d/0xb0 [cfg80211]
[ 204.362807] [<ffffffffc034f809>] ?
cfg80211_rfkill_sync_work+0x29/0x30 [cfg80211]
[ 204.362811] [<ffffffff81081335>] ? process_one_work+0x135/0x370
[ 204.362815] [<ffffffff8107e927>] ? pwq_activate_delayed_work+0x27/0x40
[ 204.362819] [<ffffffff810818c3>] ? worker_thread+0x63/0x480
[ 204.362822] [<ffffffff81081860>] ? rescuer_thread+0x2f0/0x2f0
[ 204.362826] [<ffffffff8108606e>] ? kthread+0xce/0xf0
[ 204.362830] [<ffffffff81085fa0>] ? kthread_create_on_node+0x180/0x180
[ 204.362834] [<ffffffff815f0eac>] ? ret_from_fork+0x7c/0xb0
[ 204.362838] [<ffffffff81085fa0>] ? kthread_create_on_node+0x180/0x180
[ 204.362840] ---[ end trace d0ac2826f7d27480 ]---
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re:
From: luiz.malaquias @ 2015-01-17 23:32 UTC (permalink / raw)
To: Recipients
I have a business worth $24.5 for you to handle for me.
^ permalink raw reply
* Re: [PATCH net-next] iproute2: bridge: support vlan range
From: Scott Feldman @ 2015-01-18 1:35 UTC (permalink / raw)
To: Roopa Prabhu; +Cc: Netdev, shemminger, vyasevic@redhat.com, Wilson Kok
In-Reply-To: <1421391147-35021-1-git-send-email-roopa@cumulusnetworks.com>
On Thu, Jan 15, 2015 at 10:52 PM, <roopa@cumulusnetworks.com> wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> This patch adds vlan range support to bridge command
> using the newly added vinfo flags BRIDGE_VLAN_INFO_RANGE_BEGIN and
> BRIDGE_VLAN_INFO_RANGE_END.
>
> $bridge vlan show
> port vlan ids
> br0 1 PVID Egress Untagged
>
> dummy0 1 PVID Egress Untagged
>
> $bridge vlan add vid 10-15 dev dummy0
> port vlan ids
> br0 1 PVID Egress Untagged
>
> dummy0 1 PVID Egress Untagged
> 10
> 11
> 12
> 13
> 14
> 15
>
> $bridge vlan del vid 14 dev dummy0
>
> $bridge vlan show
> port vlan ids
> br0 1 PVID Egress Untagged
>
> dummy0 1 PVID Egress Untagged
> 10
> 11
> 12
> 13
> 15
>
> $bridge vlan del vid 10-15 dev dummy0
>
> $bridge vlan show
> port vlan ids
> br0 1 PVID Egress Untagged
>
> dummy0 1 PVID Egress Untagged
>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
> Signed-off-by: Wilson Kok <wkok@cumulusnetworks.com>
> ---
> bridge/vlan.c | 46 ++++++++++++++++++++++++++++++++++++++-------
> include/linux/if_bridge.h | 2 ++
> 2 files changed, 41 insertions(+), 7 deletions(-)
>
> diff --git a/bridge/vlan.c b/bridge/vlan.c
> index 3bd7b0d..90b3b6b 100644
> --- a/bridge/vlan.c
> +++ b/bridge/vlan.c
> @@ -32,6 +32,7 @@ static int vlan_modify(int cmd, int argc, char **argv)
> } req;
> char *d = NULL;
> short vid = -1;
> + short vid_end = -1;
> struct rtattr *afspec;
> struct bridge_vlan_info vinfo;
> unsigned short flags = 0;
> @@ -49,8 +50,18 @@ static int vlan_modify(int cmd, int argc, char **argv)
> NEXT_ARG();
> d = *argv;
> } else if (strcmp(*argv, "vid") == 0) {
> + char *p;
> NEXT_ARG();
> - vid = atoi(*argv);
> + p = strchr(*argv, '-');
> + if (p) {
> + *p = '\0';
> + p++;
> + vinfo.vid = atoi(*argv);
> + vid_end = atoi(p);
Is "vid 10-" same as "vid 10-0"?
Is "vid -15" same as "vid 0-15"?
What is "vid -"?
Does the "-" char mess up shells? I don't know the answer; just asking.
> + vinfo.flags |= BRIDGE_VLAN_INFO_RANGE_BEGIN;
> + } else {
> + vinfo.vid = atoi(*argv);
> + }
> } else if (strcmp(*argv, "self") == 0) {
> flags |= BRIDGE_FLAGS_SELF;
> } else if (strcmp(*argv, "master") == 0) {
> @@ -67,7 +78,7 @@ static int vlan_modify(int cmd, int argc, char **argv)
> argc--; argv++;
> }
>
> - if (d == NULL || vid == -1) {
> + if (d == NULL || vinfo.vid == -1) {
Where was vinfo.vid initialized to -1? Maybe use vid rather than
vinfo.vid in the code above where parsing the arg, and continue using
vid and vid_end until final put of vinfo.
-scott
^ permalink raw reply
* Re: [net-next v2 00/17][pull request] Intel Wired LAN Driver Updates 2015-01-16
From: David Miller @ 2015-01-18 1:34 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <1421414946-22179-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 16 Jan 2015 05:28:49 -0800
> This series contains updates to i40e and i40evf.
...
> v2:
> - Dropped patch 10 "i40e: clean up PTP log messages" based on feedback
> from David Laight and David Miller
> - Split up the original patch 13 "i40e: AQ API updates for new commands"
> into 2 patches (now #12 & #13) based on feedback from Or Gerlitz
Pulled, thanks a lot Jeff.
^ permalink raw reply
* Re: [RFC PATCH net-next] bridge: ability to disable forwarding on a port
From: Scott Feldman @ 2015-01-18 1:05 UTC (permalink / raw)
To: Roopa Prabhu
Cc: stephen@networkplumber.org, David S. Miller, Jamal Hadi Salim,
Jiří Pírko, Arad, Ronen, Thomas Graf,
john fastabend, vyasevic@redhat.com, Netdev, Wilson Kok,
Andy Gospodarek
In-Reply-To: <1421479975-62049-1-git-send-email-roopa@cumulusnetworks.com>
On Fri, Jan 16, 2015 at 11:32 PM, <roopa@cumulusnetworks.com> wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> On a Linux bridge with bridge forwarding offloaded to a switch ASIC,
> there is a need to not re-forward the frames that come up to the
> kernel in software.
>
> Typically these are broadcast or multicast packets forwarded by the
> hardware to multiple destination ports including sending a copy of
> the packet to the kernel (e.g. an arp broadcast).
> The bridge driver will try to forward the packet again, resulting in
> two copies of the same packet.
>
> These packets can also come up to the kernel for logging when they hit
> a LOG acl in hardware.
>
> This patch makes forwarding a flag on the port similar to
> learn and flood and drops the packet just before forwarding.
> (The forwarding disable on a bridge is tested to work on our boxes.
> The bridge port flag addition is only compile tested.
> This will need to be further refined to cover cases where a non-switch port
> is bridged to a switch port etc. We will submit more patches to cover
> all cases if we agree on this approach).
Good topic to bring up, thanks for proposing a patch. There is indeed
duplicate pkts sent out in the case where both the bridge and the
offloaded device are flooding these non-unicast pkts, such as ARP
requests. We do have per-port control today over unicast flooding
using BR_FLOOD (IFLA_BRPORT_UNICAST_FLOOD).
As you point out, this doesn't solve the case for non-offloaded ports
bridged with switch ports. If this port setting is enabled on an
offloaded switch port, for example, the non-offloaded port can't get
an ARP request resolved, if the MAC is behind the offloaded switch
port. But do we care? Is there a use-case for this one, mixing
offloaded and non-offloaded ports in a bridge?
>
> Other ways to solve the same problem could be to:
> - use the offload feature flag on these switch ports to avoid the
> re-forward:
> https://www.marc.info/?l=linux-netdev&m=141820235010603&w=2
>
> - Or the switch driver can mark or set a flag in the skb, which the bridge
> driver can use to avoid a re-forward.
>
> Signed-off-by: Wilson Kok <wkok@cumulusnetworks.com>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
> ---
> include/linux/if_bridge.h | 3 ++-
> include/uapi/linux/if_link.h | 1 +
> net/bridge/br_forward.c | 13 +++++++++++++
> net/bridge/br_if.c | 2 +-
> net/bridge/br_netlink.c | 4 +++-
> net/bridge/br_sysfs_if.c | 1 +
> net/core/rtnetlink.c | 4 +++-
> 7 files changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
> index 0a8ce76..c79f4eb 100644
> --- a/include/linux/if_bridge.h
> +++ b/include/linux/if_bridge.h
> @@ -40,10 +40,11 @@ struct br_ip_list {
> #define BR_ADMIN_COST BIT(4)
> #define BR_LEARNING BIT(5)
> #define BR_FLOOD BIT(6)
> -#define BR_AUTO_MASK (BR_FLOOD | BR_LEARNING)
> #define BR_PROMISC BIT(7)
> #define BR_PROXYARP BIT(8)
> #define BR_LEARNING_SYNC BIT(9)
> +#define BR_FORWARD BIT(10)
The name BR_FORWARD might confuse people thinking this is related to
STP FORWARDING state. We have BR_FLOOD for unknown unicast flooding.
How about renaming BR_FLOOD to BR_FLOOD_UNICAST and add
BR_FLOOD_BROADCAST? So you would have:
IFLA_BRPORT_UNICAST_FLOOD BR_FLOOD_UNICAST /* flood
unknown unicast traffic to port */
IFLA_BRPORT_BROADCAST_FLOOD BR_FLOOD_BROADCAST /* flood
bcast/mcast traffic to port */
> +#define BR_AUTO_MASK (BR_FLOOD | BR_LEARNING | BR_FORWARD)
>
> extern void brioctl_set(int (*ioctl_hook)(struct net *, unsigned int, void __user *));
>
> diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
> index f7d0d2d..d394625 100644
> --- a/include/uapi/linux/if_link.h
> +++ b/include/uapi/linux/if_link.h
> @@ -246,6 +246,7 @@ enum {
> IFLA_BRPORT_UNICAST_FLOOD, /* flood unicast traffic */
> IFLA_BRPORT_PROXYARP, /* proxy ARP */
> IFLA_BRPORT_LEARNING_SYNC, /* mac learning sync from device */
> + IFLA_BRPORT_FORWARD, /* enable forwarding on a device */
> __IFLA_BRPORT_MAX
> };
> #define IFLA_BRPORT_MAX (__IFLA_BRPORT_MAX - 1)
> diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
> index f96933a..98c41c8 100644
> --- a/net/bridge/br_forward.c
> +++ b/net/bridge/br_forward.c
> @@ -81,10 +81,23 @@ static void __br_deliver(const struct net_bridge_port *to, struct sk_buff *skb)
> br_forward_finish);
> }
>
> +int br_hw_forward_finish(struct sk_buff *skb)
> +{
> + kfree_skb(skb);
> +
> + return 0;
> +}
> +
> static void __br_forward(const struct net_bridge_port *to, struct sk_buff *skb)
> {
> struct net_device *indev;
>
> + if (!(to->flags & BR_FORWARD)) {
> + NF_HOOK(NFPROTO_BRIDGE, NF_BR_FORWARD, skb, skb->dev, to->dev,
> + br_hw_forward_finish);
> + return;
> + }
> +
Seems you should make the (flags & BR_FORWARD) check earlier, before
skb cloning, in br_flood(), alongside the (flags & BR_FLOOD) check.
Also, the above code is skipping some vlan checks (br_handle_vlan).
-scott
^ permalink raw reply
* Re: [PATCH net-next 1/2] udp: Do not require sock in udp_tunnel_xmit_skb
From: Jesse Gross @ 2015-01-17 23:45 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Thomas Graf, netdev
In-Reply-To: <1421518700-22460-2-git-send-email-therbert@google.com>
On Sat, Jan 17, 2015 at 10:18 AM, Tom Herbert <therbert@google.com> wrote:
> The UDP tunnel transmit functions udp_tunnel_xmit_skb and
> udp_tunnel6_xmit_skb include a socket argument. The socket being
> passed to the functions (from VXLAN) is a UDP created for receive
> side. The only thing that the socket is used for in the transmit
> functions is to get the setting for checksum (enabled or zero).
> This patch removes the argument and and adds a nocheck argument
> for checksum setting. This eliminates the unnecessary dependency
> on a UDP socket for UDP tunnel transmit.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
I think you need to update Geneve as well:
net/ipv4/geneve.c:139:38: warning: incorrect type in argument 1
(different base types)
net/ipv4/geneve.c:139:38: expected struct rtable *rt
net/ipv4/geneve.c:139:38: got struct socket *sock
net/ipv4/geneve.c:139:46: warning: incorrect type in argument 2
(different base types)
net/ipv4/geneve.c:139:46: expected struct sk_buff *skb
net/ipv4/geneve.c:139:46: got struct rtable *rt
net/ipv4/geneve.c:139:50: warning: incorrect type in argument 3
(different base types)
net/ipv4/geneve.c:139:50: expected restricted __be32 [usertype] src
net/ipv4/geneve.c:139:50: got struct sk_buff *[assigned] skb
net/ipv4/geneve.c:139:60: warning: incorrect type in argument 5
(different base types)
net/ipv4/geneve.c:139:60: expected unsigned char [unsigned] [usertype] tos
net/ipv4/geneve.c:139:60: got restricted __be32 [usertype] dst
net/ipv4/geneve.c:140:41: warning: incorrect type in argument 7
(different base types)
net/ipv4/geneve.c:140:41: expected restricted __be16 [usertype] df
net/ipv4/geneve.c:140:41: got unsigned char [unsigned] [usertype] ttl
net/ipv4/geneve.c:140:60: warning: incorrect type in argument 10
(different base types)
net/ipv4/geneve.c:140:60: expected bool [unsigned] [usertype] xnet
net/ipv4/geneve.c:140:60: got restricted __be16 [usertype] dst_port
^ permalink raw reply
* RE: [RFC PATCH net-next] bridge: ability to disable forwarding on a port
From: Arad, Ronen @ 2015-01-17 21:14 UTC (permalink / raw)
To: roopa@cumulusnetworks.com, stephen@networkplumber.org,
davem@davemloft.net, jhs@mojatatu.com, netdev@vger.kernel.org,
sfeldma@gmail.com, jiri@resnulli.us, tgraf@suug.ch,
john.fastabend@gmail.com, vyasevic@redhat.com
Cc: wkok@cumulusnetworks.com, gospo@cumulusnetworks.com
In-Reply-To: <1421479975-62049-1-git-send-email-roopa@cumulusnetworks.com>
>-----Original Message-----
>From: roopa@cumulusnetworks.com [mailto:roopa@cumulusnetworks.com]
>Sent: Friday, January 16, 2015 11:33 PM
>To: stephen@networkplumber.org; davem@davemloft.net; jhs@mojatatu.com;
>sfeldma@gmail.com; jiri@resnulli.us; Arad, Ronen; tgraf@suug.ch;
>john.fastabend@gmail.com; vyasevic@redhat.com
>Cc: netdev@vger.kernel.org; wkok@cumulusnetworks.com;
>gospo@cumulusnetworks.com
>Subject: [RFC PATCH net-next] bridge: ability to disable forwarding on a port
>
>From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
>On a Linux bridge with bridge forwarding offloaded to a switch ASIC,
>there is a need to not re-forward the frames that come up to the
>kernel in software.
>
>Typically these are broadcast or multicast packets forwarded by the
>hardware to multiple destination ports including sending a copy of
>the packet to the kernel (e.g. an arp broadcast).
>The bridge driver will try to forward the packet again, resulting in
>two copies of the same packet.
>
>These packets can also come up to the kernel for logging when they hit
>a LOG acl in hardware.
>
>This patch makes forwarding a flag on the port similar to
>learn and flood and drops the packet just before forwarding.
>(The forwarding disable on a bridge is tested to work on our boxes.
>The bridge port flag addition is only compile tested.
>This will need to be further refined to cover cases where a non-switch port
>is bridged to a switch port etc. We will submit more patches to cover
>all cases if we agree on this approach).
>
>Other ways to solve the same problem could be to:
>- use the offload feature flag on these switch ports to avoid the
>re-forward:
>https://www.marc.info/?l=linux-netdev&m=141820235010603&w=2
>
>- Or the switch driver can mark or set a flag in the skb, which the bridge
>driver can use to avoid a re-forward.
>
The proposed patch does not go along with the offload feature flag.
The premise of the offload feature flag is that offloading is driven by the
switch port driver without user intervention. This patch requires different
setting for BR_FLOOD in the software bridge port and the switch port driver.
The alternatives suggested (offload flag or skb flag) are better.
The proposed patch avoids re-forward but not without cost. For example in the
case of unicast flood with local destination, the skb is cloned for each port
before the forward avoidance in __br_forward. Is it acceptable overhead?
[...]
^ permalink raw reply
* Re: [patch net-next 2/2] net: replace br_fdb_external_learn_* calls with switchdev notifier events
From: David Miller @ 2015-01-17 20:28 UTC (permalink / raw)
To: jiri; +Cc: sfeldma, netdev, jhs, sfeldma, stephen, linus.luessing, tgraf
In-Reply-To: <20150117083112.GB1891@nanopsycho.orion>
From: Jiri Pirko <jiri@resnulli.us>
Date: Sat, 17 Jan 2015 09:31:12 +0100
>>> @@ -3026,11 +3026,17 @@ static void rocker_port_fdb_learn_work(struct work_struct *work)
>>> container_of(work, struct rocker_fdb_learn_work, work);
>>> bool removing = (lw->flags & ROCKER_OP_FLAG_REMOVE);
>>> bool learned = (lw->flags & ROCKER_OP_FLAG_LEARNED);
>>> + struct netdev_switch_notifier_fdb_info info;
>>> +
>>> + info.addr = lw->addr;
>>> + info.vid = lw->vid;
>>
>>If you respin patch, use initializer to zero out other members, just
>>to future proof it.
>
> There are no other members :)
That's why he said "future proof", he knows there are no other members
(currently) too.
^ permalink raw reply
* [PATCH net-next 2/2] vxlan: Eliminate dependency on UDP socket in transmit path
From: Tom Herbert @ 2015-01-17 18:18 UTC (permalink / raw)
To: davem, tgraf, netdev
In-Reply-To: <1421518700-22460-1-git-send-email-therbert@google.com>
In the vxlan transmit path there is no need to reference the socket
for a tunnel which is needed for the receive side. We do, however,
need the vxlan_dev flags. This patch eliminate references
to the socket in the transmit path, and changes VXLAN_F_UNSHAREABLE
to be VXLAN_F_RCV_FLAGS. This mask is used to store the flags
applicable to receive (GBP, CSUM6_RX, and REMCSUM_RX) in the
vxlan_sock flags.
Signed-off-by: Tom Herbert <therbert@google.com>
---
drivers/net/vxlan.c | 60 ++++++++++++++++++++-----------------------
include/net/vxlan.h | 13 ++++++----
net/openvswitch/vport-vxlan.c | 6 ++---
3 files changed, 38 insertions(+), 41 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 4fb4205..fb7805b 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -270,12 +270,13 @@ static struct vxlan_sock *vxlan_find_sock(struct net *net, sa_family_t family,
__be16 port, u32 flags)
{
struct vxlan_sock *vs;
- u32 match_flags = flags & VXLAN_F_UNSHAREABLE;
+
+ flags &= VXLAN_F_RCV_FLAGS;
hlist_for_each_entry_rcu(vs, vs_head(net, port), hlist) {
if (inet_sk(vs->sock->sk)->inet_sport == port &&
inet_sk(vs->sock->sk)->sk.sk_family == family &&
- (vs->flags & VXLAN_F_UNSHAREABLE) == match_flags)
+ vs->flags == flags)
return vs;
}
return NULL;
@@ -1668,7 +1669,7 @@ static bool route_shortcircuit(struct net_device *dev, struct sk_buff *skb)
return false;
}
-static void vxlan_build_gbp_hdr(struct vxlanhdr *vxh, struct vxlan_sock *vs,
+static void vxlan_build_gbp_hdr(struct vxlanhdr *vxh, u32 vxflags,
struct vxlan_metadata *md)
{
struct vxlanhdr_gbp *gbp;
@@ -1686,21 +1687,20 @@ static void vxlan_build_gbp_hdr(struct vxlanhdr *vxh, struct vxlan_sock *vs,
}
#if IS_ENABLED(CONFIG_IPV6)
-static int vxlan6_xmit_skb(struct vxlan_sock *vs,
- struct dst_entry *dst, struct sk_buff *skb,
+static int vxlan6_xmit_skb(struct dst_entry *dst, struct sk_buff *skb,
struct net_device *dev, struct in6_addr *saddr,
struct in6_addr *daddr, __u8 prio, __u8 ttl,
__be16 src_port, __be16 dst_port,
- struct vxlan_metadata *md, bool xnet)
+ struct vxlan_metadata *md, bool xnet, u32 vxflags)
{
struct vxlanhdr *vxh;
int min_headroom;
int err;
- bool udp_sum = !udp_get_no_check6_tx(vs->sock->sk);
+ bool udp_sum = !(vxflags & VXLAN_F_UDP_ZERO_CSUM6_TX);
int type = udp_sum ? SKB_GSO_UDP_TUNNEL_CSUM : SKB_GSO_UDP_TUNNEL;
u16 hdrlen = sizeof(struct vxlanhdr);
- if ((vs->flags & VXLAN_F_REMCSUM_TX) &&
+ if ((vxflags & VXLAN_F_REMCSUM_TX) &&
skb->ip_summed == CHECKSUM_PARTIAL) {
int csum_start = skb_checksum_start_offset(skb);
@@ -1758,14 +1758,14 @@ static int vxlan6_xmit_skb(struct vxlan_sock *vs,
}
}
- if (vs->flags & VXLAN_F_GBP)
- vxlan_build_gbp_hdr(vxh, vs, md);
+ if (vxflags & VXLAN_F_GBP)
+ vxlan_build_gbp_hdr(vxh, vxflags, md);
skb_set_inner_protocol(skb, htons(ETH_P_TEB));
udp_tunnel6_xmit_skb(dst, skb, dev, saddr, daddr, prio,
ttl, src_port, dst_port,
- udp_get_no_check6_tx(vs->sock->sk));
+ !!(vxflags & VXLAN_F_UDP_ZERO_CSUM6_TX));
return 0;
err:
dst_release(dst);
@@ -1773,20 +1773,19 @@ err:
}
#endif
-int vxlan_xmit_skb(struct vxlan_sock *vs,
- struct rtable *rt, struct sk_buff *skb,
+int vxlan_xmit_skb(struct rtable *rt, struct sk_buff *skb,
__be32 src, __be32 dst, __u8 tos, __u8 ttl, __be16 df,
__be16 src_port, __be16 dst_port,
- struct vxlan_metadata *md, bool xnet)
+ struct vxlan_metadata *md, bool xnet, u32 vxflags)
{
struct vxlanhdr *vxh;
int min_headroom;
int err;
- bool udp_sum = !vs->sock->sk->sk_no_check_tx;
+ bool udp_sum = !!(vxflags & VXLAN_F_UDP_CSUM);
int type = udp_sum ? SKB_GSO_UDP_TUNNEL_CSUM : SKB_GSO_UDP_TUNNEL;
u16 hdrlen = sizeof(struct vxlanhdr);
- if ((vs->flags & VXLAN_F_REMCSUM_TX) &&
+ if ((vxflags & VXLAN_F_REMCSUM_TX) &&
skb->ip_summed == CHECKSUM_PARTIAL) {
int csum_start = skb_checksum_start_offset(skb);
@@ -1838,14 +1837,14 @@ int vxlan_xmit_skb(struct vxlan_sock *vs,
}
}
- if (vs->flags & VXLAN_F_GBP)
- vxlan_build_gbp_hdr(vxh, vs, md);
+ if (vxflags & VXLAN_F_GBP)
+ vxlan_build_gbp_hdr(vxh, vxflags, md);
skb_set_inner_protocol(skb, htons(ETH_P_TEB));
return udp_tunnel_xmit_skb(rt, skb, src, dst, tos,
ttl, df, src_port, dst_port, xnet,
- vs->sock->sk->sk_no_check_tx);
+ !(vxflags & VXLAN_F_UDP_CSUM));
}
EXPORT_SYMBOL_GPL(vxlan_xmit_skb);
@@ -1977,10 +1976,11 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct net_device *dev,
md.vni = htonl(vni << 8);
md.gbp = skb->mark;
- err = vxlan_xmit_skb(vxlan->vn_sock, rt, skb,
- fl4.saddr, dst->sin.sin_addr.s_addr,
- tos, ttl, df, src_port, dst_port, &md,
- !net_eq(vxlan->net, dev_net(vxlan->dev)));
+ err = vxlan_xmit_skb(rt, skb, fl4.saddr,
+ dst->sin.sin_addr.s_addr, tos, ttl, df,
+ src_port, dst_port, &md,
+ !net_eq(vxlan->net, dev_net(vxlan->dev)),
+ vxlan->flags);
if (err < 0) {
/* skb is already freed. */
skb = NULL;
@@ -2036,10 +2036,10 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct net_device *dev,
md.vni = htonl(vni << 8);
md.gbp = skb->mark;
- err = vxlan6_xmit_skb(vxlan->vn_sock, ndst, skb,
- dev, &fl6.saddr, &fl6.daddr, 0, ttl,
- src_port, dst_port, &md,
- !net_eq(vxlan->net, dev_net(vxlan->dev)));
+ err = vxlan6_xmit_skb(ndst, skb, dev, &fl6.saddr, &fl6.daddr,
+ 0, ttl, src_port, dst_port, &md,
+ !net_eq(vxlan->net, dev_net(vxlan->dev)),
+ vxlan->flags);
#endif
}
@@ -2511,15 +2511,11 @@ static struct socket *vxlan_create_sock(struct net *net, bool ipv6,
if (ipv6) {
udp_conf.family = AF_INET6;
- udp_conf.use_udp6_tx_checksums =
- !(flags & VXLAN_F_UDP_ZERO_CSUM6_TX);
udp_conf.use_udp6_rx_checksums =
!(flags & VXLAN_F_UDP_ZERO_CSUM6_RX);
} else {
udp_conf.family = AF_INET;
udp_conf.local_ip.s_addr = INADDR_ANY;
- udp_conf.use_udp_checksums =
- !!(flags & VXLAN_F_UDP_CSUM);
}
udp_conf.local_udp_port = port;
@@ -2563,7 +2559,7 @@ static struct vxlan_sock *vxlan_socket_create(struct net *net, __be16 port,
atomic_set(&vs->refcnt, 1);
vs->rcv = rcv;
vs->data = data;
- vs->flags = flags;
+ vs->flags = (flags & VXLAN_F_RCV_FLAGS);
/* Initialize the vxlan udp offloads structure */
vs->udp_offloads.port = port;
diff --git a/include/net/vxlan.h b/include/net/vxlan.h
index 7be8c34..2927d62 100644
--- a/include/net/vxlan.h
+++ b/include/net/vxlan.h
@@ -129,8 +129,12 @@ struct vxlan_sock {
#define VXLAN_F_REMCSUM_RX 0x400
#define VXLAN_F_GBP 0x800
-/* These flags must match in order for a socket to be shareable */
-#define VXLAN_F_UNSHAREABLE VXLAN_F_GBP
+/* Flags that are used in the receive patch. These flags must match in
+ * order for a socket to be shareable
+ */
+#define VXLAN_F_RCV_FLAGS (VXLAN_F_GBP | \
+ VXLAN_F_UDP_ZERO_CSUM6_RX | \
+ VXLAN_F_REMCSUM_RX)
struct vxlan_sock *vxlan_sock_add(struct net *net, __be16 port,
vxlan_rcv_t *rcv, void *data,
@@ -138,11 +142,10 @@ struct vxlan_sock *vxlan_sock_add(struct net *net, __be16 port,
void vxlan_sock_release(struct vxlan_sock *vs);
-int vxlan_xmit_skb(struct vxlan_sock *vs,
- struct rtable *rt, struct sk_buff *skb,
+int vxlan_xmit_skb(struct rtable *rt, struct sk_buff *skb,
__be32 src, __be32 dst, __u8 tos, __u8 ttl, __be16 df,
__be16 src_port, __be16 dst_port, struct vxlan_metadata *md,
- bool xnet);
+ bool xnet, u32 vxflags);
static inline netdev_features_t vxlan_features_check(struct sk_buff *skb,
netdev_features_t features)
diff --git a/net/openvswitch/vport-vxlan.c b/net/openvswitch/vport-vxlan.c
index 8a2d54c..3cc983b 100644
--- a/net/openvswitch/vport-vxlan.c
+++ b/net/openvswitch/vport-vxlan.c
@@ -252,12 +252,10 @@ static int vxlan_tnl_send(struct vport *vport, struct sk_buff *skb)
md.vni = htonl(be64_to_cpu(tun_key->tun_id) << 8);
md.gbp = vxlan_ext_gbp(skb);
- err = vxlan_xmit_skb(vxlan_port->vs, rt, skb,
- fl.saddr, tun_key->ipv4_dst,
+ err = vxlan_xmit_skb(rt, skb, fl.saddr, tun_key->ipv4_dst,
tun_key->ipv4_tos, tun_key->ipv4_ttl, df,
src_port, dst_port,
- &md,
- false);
+ &md, false, vxlan_port->exts);
if (err < 0)
ip_rt_put(rt);
return err;
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH net-next 1/2] udp: Do not require sock in udp_tunnel_xmit_skb
From: Tom Herbert @ 2015-01-17 18:18 UTC (permalink / raw)
To: davem, tgraf, netdev
In-Reply-To: <1421518700-22460-1-git-send-email-therbert@google.com>
The UDP tunnel transmit functions udp_tunnel_xmit_skb and
udp_tunnel6_xmit_skb include a socket argument. The socket being
passed to the functions (from VXLAN) is a UDP created for receive
side. The only thing that the socket is used for in the transmit
functions is to get the setting for checksum (enabled or zero).
This patch removes the argument and and adds a nocheck argument
for checksum setting. This eliminates the unnecessary dependency
on a UDP socket for UDP tunnel transmit.
Signed-off-by: Tom Herbert <therbert@google.com>
---
drivers/net/vxlan.c | 10 ++++++----
include/net/udp_tunnel.h | 16 ++++++++--------
net/ipv4/udp_tunnel.c | 12 ++++++------
net/ipv6/ip6_udp_tunnel.c | 12 ++++++------
4 files changed, 26 insertions(+), 24 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 6b6b456..4fb4205 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -1763,8 +1763,9 @@ static int vxlan6_xmit_skb(struct vxlan_sock *vs,
skb_set_inner_protocol(skb, htons(ETH_P_TEB));
- udp_tunnel6_xmit_skb(vs->sock, dst, skb, dev, saddr, daddr, prio,
- ttl, src_port, dst_port);
+ udp_tunnel6_xmit_skb(dst, skb, dev, saddr, daddr, prio,
+ ttl, src_port, dst_port,
+ udp_get_no_check6_tx(vs->sock->sk));
return 0;
err:
dst_release(dst);
@@ -1842,8 +1843,9 @@ int vxlan_xmit_skb(struct vxlan_sock *vs,
skb_set_inner_protocol(skb, htons(ETH_P_TEB));
- return udp_tunnel_xmit_skb(vs->sock, rt, skb, src, dst, tos,
- ttl, df, src_port, dst_port, xnet);
+ return udp_tunnel_xmit_skb(rt, skb, src, dst, tos,
+ ttl, df, src_port, dst_port, xnet,
+ vs->sock->sk->sk_no_check_tx);
}
EXPORT_SYMBOL_GPL(vxlan_xmit_skb);
diff --git a/include/net/udp_tunnel.h b/include/net/udp_tunnel.h
index 2a50a70..1a20d33 100644
--- a/include/net/udp_tunnel.h
+++ b/include/net/udp_tunnel.h
@@ -77,17 +77,17 @@ void setup_udp_tunnel_sock(struct net *net, struct socket *sock,
struct udp_tunnel_sock_cfg *sock_cfg);
/* Transmit the skb using UDP encapsulation. */
-int udp_tunnel_xmit_skb(struct socket *sock, struct rtable *rt,
- struct sk_buff *skb, __be32 src, __be32 dst,
- __u8 tos, __u8 ttl, __be16 df, __be16 src_port,
- __be16 dst_port, bool xnet);
+int udp_tunnel_xmit_skb(struct rtable *rt, struct sk_buff *skb,
+ __be32 src, __be32 dst, __u8 tos, __u8 ttl,
+ __be16 df, __be16 src_port, __be16 dst_port,
+ bool xnet, bool nocheck);
#if IS_ENABLED(CONFIG_IPV6)
-int udp_tunnel6_xmit_skb(struct socket *sock, struct dst_entry *dst,
- struct sk_buff *skb, struct net_device *dev,
- struct in6_addr *saddr, struct in6_addr *daddr,
+int udp_tunnel6_xmit_skb(struct dst_entry *dst, struct sk_buff *skb,
+ struct net_device *dev, struct in6_addr *saddr,
+ struct in6_addr *daddr,
__u8 prio, __u8 ttl, __be16 src_port,
- __be16 dst_port);
+ __be16 dst_port, bool nocheck);
#endif
void udp_tunnel_sock_release(struct socket *sock);
diff --git a/net/ipv4/udp_tunnel.c b/net/ipv4/udp_tunnel.c
index 9996e63..c83b354 100644
--- a/net/ipv4/udp_tunnel.c
+++ b/net/ipv4/udp_tunnel.c
@@ -75,10 +75,10 @@ void setup_udp_tunnel_sock(struct net *net, struct socket *sock,
}
EXPORT_SYMBOL_GPL(setup_udp_tunnel_sock);
-int udp_tunnel_xmit_skb(struct socket *sock, struct rtable *rt,
- struct sk_buff *skb, __be32 src, __be32 dst,
- __u8 tos, __u8 ttl, __be16 df, __be16 src_port,
- __be16 dst_port, bool xnet)
+int udp_tunnel_xmit_skb(struct rtable *rt, struct sk_buff *skb,
+ __be32 src, __be32 dst, __u8 tos, __u8 ttl,
+ __be16 df, __be16 src_port, __be16 dst_port,
+ bool xnet, bool nocheck)
{
struct udphdr *uh;
@@ -90,9 +90,9 @@ int udp_tunnel_xmit_skb(struct socket *sock, struct rtable *rt,
uh->source = src_port;
uh->len = htons(skb->len);
- udp_set_csum(sock->sk->sk_no_check_tx, skb, src, dst, skb->len);
+ udp_set_csum(nocheck, skb, src, dst, skb->len);
- return iptunnel_xmit(sock->sk, rt, skb, src, dst, IPPROTO_UDP,
+ return iptunnel_xmit(skb->sk, rt, skb, src, dst, IPPROTO_UDP,
tos, ttl, df, xnet);
}
EXPORT_SYMBOL_GPL(udp_tunnel_xmit_skb);
diff --git a/net/ipv6/ip6_udp_tunnel.c b/net/ipv6/ip6_udp_tunnel.c
index 8db6c98..32d9b26 100644
--- a/net/ipv6/ip6_udp_tunnel.c
+++ b/net/ipv6/ip6_udp_tunnel.c
@@ -62,14 +62,14 @@ error:
}
EXPORT_SYMBOL_GPL(udp_sock_create6);
-int udp_tunnel6_xmit_skb(struct socket *sock, struct dst_entry *dst,
- struct sk_buff *skb, struct net_device *dev,
- struct in6_addr *saddr, struct in6_addr *daddr,
- __u8 prio, __u8 ttl, __be16 src_port, __be16 dst_port)
+int udp_tunnel6_xmit_skb(struct dst_entry *dst, struct sk_buff *skb,
+ struct net_device *dev, struct in6_addr *saddr,
+ struct in6_addr *daddr,
+ __u8 prio, __u8 ttl, __be16 src_port,
+ __be16 dst_port, bool nocheck)
{
struct udphdr *uh;
struct ipv6hdr *ip6h;
- struct sock *sk = sock->sk;
__skb_push(skb, sizeof(*uh));
skb_reset_transport_header(skb);
@@ -85,7 +85,7 @@ int udp_tunnel6_xmit_skb(struct socket *sock, struct dst_entry *dst,
| IPSKB_REROUTED);
skb_dst_set(skb, dst);
- udp6_set_csum(udp_get_no_check6_tx(sk), skb, saddr, daddr, skb->len);
+ udp6_set_csum(nocheck, skb, saddr, daddr, skb->len);
__skb_push(skb, sizeof(*ip6h));
skb_reset_network_header(skb);
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH net-next 0/2] vxlan: Don't use UDP socket for transmit
From: Tom Herbert @ 2015-01-17 18:18 UTC (permalink / raw)
To: davem, tgraf, netdev
UDP socket is not pertinent to transmit for UDP tunnels, checksum
enablement can be done with a socket. This patch set eliminates
reference to a socket in udp_tunnel_xmit functions and in VXLAN
trnasmit.
Also, make GBP, RCO, can CSUM6_RX flags visible to receive socket
and only match these for shareable socket.
Tom Herbert (2):
udp: Do not require sock in udp_tunnel_xmit_skb
vxlan: Eliminate dependency on UDP socket in transmit path
drivers/net/vxlan.c | 66 +++++++++++++++++++++----------------------
include/net/udp_tunnel.h | 16 +++++------
include/net/vxlan.h | 13 +++++----
net/ipv4/udp_tunnel.c | 12 ++++----
net/ipv6/ip6_udp_tunnel.c | 12 ++++----
net/openvswitch/vport-vxlan.c | 6 ++--
6 files changed, 62 insertions(+), 63 deletions(-)
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply
* Re: [RFC PATCH v2 1/2] net: af_packet support for direct ring access in user space
From: John Fastabend @ 2015-01-17 17:35 UTC (permalink / raw)
To: David Miller
Cc: netdev, danny.zhou, nhorman, dborkman, john.ronciak, hannes,
brouer
In-Reply-To: <20150114.153509.1264618607573705890.davem@davemloft.net>
On 01/14/2015 12:35 PM, David Miller wrote:
> From: John Fastabend <john.fastabend@gmail.com>
> Date: Mon, 12 Jan 2015 20:35:11 -0800
>
>> + if ((region.direction != DMA_BIDIRECTIONAL) &&
>> + (region.direction != DMA_TO_DEVICE) &&
>> + (region.direction != DMA_FROM_DEVICE))
>> + return -EFAULT;
> ...
>> + if ((umem->nmap == npages) &&
>> + (0 != dma_map_sg(dev->dev.parent, umem->sglist,
>> + umem->nmap, region.direction))) {
>> + region.iova = sg_dma_address(umem->sglist) + offset;
>
> I am having trouble seeing how this can work.
>
> dma_map_{single,sg}() mappings need synchronization after a DMA
> transfer takes place.
>
> For example if the DMA occurs to the device, then that region can
> be cached in the PCI controller's internal caches and thus future
> cpu writes into that memory region will not be seen, until a
> dma_sync_*() is invoked.
>
> That isn't going to happen when the device transmit queue is
> being completely managed in userspace.
>
> And this takes us back to the issue of protection, I don't think
> it is addressed properly yet.
>
> CAP_NET_ADMIN privileges do not mean "can crap all over memory"
> yet with this feature that can still happen.
>
> If we are dealing with a device which cannot provide strict protection
> to only the process's locked local pages, you have to do something
> to implement that protection.
>
> And you have _exactly_ one option to do that, abstracting the page
> addresses and eating a system call to trigger the sends, so that you
> can read from the user's (fake) descriptors and write into the real
> descriptors (translating the DMA addresses along the way) and
> triggering the TX doorbell.
OK, I think this brings us back to some of the original designs/ideas
we were thinking about with Daniel/Neil. We are going to take a look
at this. At least on the RX side we can have the af_packet logic give
us a set of DMA addresses'. I wonder if we can also make the busy
poll logic per queue and use it.
>
> I am not going to consider seriously an implementation that says "yeah
> sometimes the user can crap onto other people's memory", this isn't
> MS-DOS, it's a system where proper memory protections are mandatory
> rather than optional.
>
More to sort out on our side. Thanks for looking at the patches.
.John
--
John Fastabend Intel Corporation
^ 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