* Re: [PATCH 2/2] Drivers: Isdn: sc: Fixed coding style & spelling mistakes.
From: David Miller @ 2015-01-18 5:28 UTC (permalink / raw)
To: akash0x53s; +Cc: isdn, netdev, linux-kernel
In-Reply-To: <1421415762-21596-1-git-send-email-akash0x53s@gmail.com>
From: Akash Shende <akash0x53s@gmail.com>
Date: Fri, 16 Jan 2015 19:12:42 +0530
> Fix some spelling mistakes, coding style and don't assign value to static var.
>
> Signed-off-by: Akash Shende <akash0x53s@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [net-next PATCH v3 1/1] atm: remove deprecated use of pci api
From: David Miller @ 2015-01-18 5:28 UTC (permalink / raw)
To: chas; +Cc: David.Laight, lambert.quentin, linux-atm-general, netdev,
linux-kernel
In-Reply-To: <20150116085721.56aa8075@thirdoffive.cmf.nrl.navy.mil>
From: chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Date: Fri, 16 Jan 2015 08:57:21 -0500
> Signed-off-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Applied, thanks Chas.
^ permalink raw reply
* Re: [PATCH] netlink: make nlmsg_end() and genlmsg_end() void
From: David Miller @ 2015-01-18 6:04 UTC (permalink / raw)
To: johannes; +Cc: netdev, johannes.berg
In-Reply-To: <1421442540-10244-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 16 Jan 2015 22:09:00 +0100
...
> Remove this, and make the functions void. This removes a bunch of dead
> code as described above. The patch adds lines because I did
>
> - return nlmsg_end(...);
> + nlmsg_end(...);
> + return 0;
>
> I could have preserved all the function's return values by returning
> skb->len, but instead I've audited all the places calling the affected
> functions and found that none cared. A few places actually compared
> the return value with <= 0 in dump functionality, but that could just
> be changed to < 0 with no change in behaviour, so I opted for the more
> efficient version.
>
> One instance of the error I've made numerous times now is also present
> in net/phonet/pn_netlink.c in the route_dumpit() function - it didn't
> check for <0 or <=0 and thus broke out of the loop every single time.
> I've preserved this since it will (I think) have caused the messages to
> userspace to be formatted differently with just a single message for
> every SKB returned to userspace. It's possible that this isn't needed
> for the tools that actually use this, but I don't even know what they
> are so couldn't test that changing this behaviour would be acceptable.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
I like this, applied, thanks Johannes.
You know, I would even be willing to apply a patch adjusting that phonet
case. So feel free to submit that.
^ permalink raw reply
* Re: [patch-net-next v3 1/2] net: ethernet: cpsw: unroll IRQ request loop
From: David Miller @ 2015-01-18 6:07 UTC (permalink / raw)
To: balbi; +Cc: tony, linux-omap, mugunthanvnm, netdev
In-Reply-To: <1421424672-19323-1-git-send-email-balbi@ti.com>
From: Felipe Balbi <balbi@ti.com>
Date: Fri, 16 Jan 2015 10:11:11 -0600
> This patch is in preparation for a nicer IRQ
> handling scheme where we use different IRQ
> handlers for each IRQ line (as it should be).
>
> Later, we will also drop IRQs offset 0 and 3
> because they are always disabled in this driver.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
Applied.
^ permalink raw reply
* Re: [patch-net-next v3 2/2] net: ethernet: cpsw: don't requests IRQs we don't use
From: David Miller @ 2015-01-18 6:07 UTC (permalink / raw)
To: balbi; +Cc: tony, linux-omap, mugunthanvnm, netdev
In-Reply-To: <1421424672-19323-2-git-send-email-balbi@ti.com>
From: Felipe Balbi <balbi@ti.com>
Date: Fri, 16 Jan 2015 10:11:12 -0600
> CPSW never uses RX_THRESHOLD or MISC interrupts. In
> fact, they are always kept masked in their appropriate
> IRQ Enable register.
>
> Instead of allocating an IRQ that never fires, it's best
> to remove that code altogether and let future patches
> implement it if anybody needs those.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
Applied.
^ permalink raw reply
* RE: [net-next v2 13/15] i40e: limit WoL and link settings to partition 1
From: Yuval Mintz @ 2015-01-18 6:10 UTC (permalink / raw)
To: Jeff Kirsher, David Miller
Cc: Shannon Nelson, netdev, nhorman@redhat.com, sassmann@redhat.com,
jogreene@redhat.com
In-Reply-To: <1421179093-10932-14-git-send-email-jeffrey.t.kirsher@intel.com>
>From: Shannon Nelson <shannon.nelson@intel.com>
>When in multi-function mode, e.g. Dell's NPAR, only partition 1
>of each MAC is allowed to set WoL, speed, and flow control.
Isn't it problematic? I mean, in bnx2x we address ~same issue -
but due to symmetry we prevent ALL interfaces from changing
the link configuration.
How can user be aware of this 'private' behavior? via system logs?
documentation?
How does it interact with Physical Device Assignment of the first
partition?
Cheers,
Yuval
^ permalink raw reply
* Re: [net-next PATCH v2 04/12] net: flow_table: create a set of common headers and actions
From: Scott Feldman @ 2015-01-18 6:34 UTC (permalink / raw)
To: John Fastabend
Cc: Thomas Graf, simon.horman@netronome.com, Netdev, gerlitz.or,
Jamal Hadi Salim, Andy Gospodarek, David S. Miller
In-Reply-To: <20150113213645.13874.24934.stgit@nitbit.x32>
On Tue, Jan 13, 2015 at 1:36 PM, John Fastabend
<john.fastabend@gmail.com> wrote:
> This adds common headers and actions that drivers can use.
>
> I have not yet moved the header graphs into the common header
> because I'm not entirely convinced its re-usable. The devices
> I have been looking at have different enough header graphs that
> they wouldn't be re-usable. However possibly many 40Gbp NICs
> for example could share a common header graph. When we get
> multiple implementations we can move this into the common file
> if it makes sense.
>
> And table structures seem to be unique enough that there is
> little value in putting each devices table layout into the
> common file so its left for device specific implementation.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ---
> include/linux/if_flow_common.h | 257 ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 257 insertions(+)
> create mode 100644 include/linux/if_flow_common.h
>
> diff --git a/include/linux/if_flow_common.h b/include/linux/if_flow_common.h
> new file mode 100644
> index 0000000..d4dd749
> --- /dev/null
> +++ b/include/linux/if_flow_common.h
> @@ -0,0 +1,257 @@
> +#ifndef _IF_FLOW_COMMON_H_
> +#define _IF_FLOW_COMMON_H_
> +
> +#include <linux/if_flow.h>
> +
> +/* Common header definition this section provides a set of common or
> + * standard headers that device driver writers may use to simplify the
> + * driver creation. We do not want vendor or driver specific headers
> + * here though. Driver authors can keep these contained to their driver
> + *
> + * Driver authors may use unique IDs greater than HEADER_MAX_UID it is
> + * guaranteed to be larger than any unique IDs used here.
> + */
> +#define HEADER_MAX_UID 100
> +
> +enum net_flow_headers {
> + HEADER_UNSPEC,
> + HEADER_ETHERNET,
> + HEADER_VLAN,
> + HEADER_IPV4,
> +};
> +
> +enum net_flow_ethernet_fields_ids {
> + HEADER_ETHERNET_UNSPEC,
> + HEADER_ETHERNET_SRC_MAC,
> + HEADER_ETHERNET_DST_MAC,
> + HEADER_ETHERNET_ETHERTYPE,
> +};
> +
> +struct net_flow_field net_flow_ethernet_fields[] = {
> + { .name = "src_mac", .uid = HEADER_ETHERNET_SRC_MAC, .bitwidth = 48},
> + { .name = "dst_mac", .uid = HEADER_ETHERNET_DST_MAC, .bitwidth = 48},
> + { .name = "ethertype",
> + .uid = HEADER_ETHERNET_ETHERTYPE,
> + .bitwidth = 16},
> +};
All of these code chunks get repeated in each module that includes
if_flow_common.h, regardless if the module needs all of them.
Maybe #define would be better?
> +struct net_flow_field net_flow_ipv4_fields[14] = {
net_flow_ipv4_fields[]. more like this...
-scott
^ permalink raw reply
* Re: [net-next PATCH v2 06/12] net: rocker: add pipeline model for rocker switch
From: Scott Feldman @ 2015-01-18 6:39 UTC (permalink / raw)
To: John Fastabend
Cc: Thomas Graf, simon.horman@netronome.com, Netdev, gerlitz.or,
Jamal Hadi Salim, Andy Gospodarek, David S. Miller
In-Reply-To: <20150113213739.13874.37091.stgit@nitbit.x32>
On Tue, Jan 13, 2015 at 1:37 PM, John Fastabend
<john.fastabend@gmail.com> wrote:
> This adds rocker support for the net_flow_get_* operations. With this
> we can interrogate rocker.
>
> Here we see that for static configurations enabling the get operations
> is simply a matter of defining a pipeline model and returning the
> structures for the core infrastructure to encapsulate into netlink
> messages.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ---
> drivers/net/ethernet/rocker/rocker.c | 65 ++++
> drivers/net/ethernet/rocker/rocker_pipeline.h | 451 +++++++++++++++++++++++++
> 2 files changed, 516 insertions(+)
> create mode 100644 drivers/net/ethernet/rocker/rocker_pipeline.h
>
> diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c
> index 2f398fa..d2ea451 100644
> --- a/drivers/net/ethernet/rocker/rocker.c
> +++ b/drivers/net/ethernet/rocker/rocker.c
> @@ -36,6 +36,7 @@
> #include <generated/utsrelease.h>
>
> #include "rocker.h"
> +#include "rocker_pipeline.h"
>
> static const char rocker_driver_name[] = "rocker";
>
> @@ -3781,6 +3782,56 @@ static int rocker_port_switch_port_stp_update(struct net_device *dev, u8 state)
> return rocker_port_stp_update(rocker_port, state);
> }
>
> +static void rocker_destroy_flow_tables(struct rocker_port *rocker_port)
> +{
> + int i;
> +
> + for (i = 0; rocker_table_list[i]; i++)
> + net_flow_destroy_cache(rocker_table_list[i]);
> +}
> +
> +static int rocker_init_flow_tables(struct rocker_port *rocker_port)
> +{
> + int i, err;
> +
> + for (i = 0; rocker_table_list[i]; i++) {
> + err = net_flow_init_cache(rocker_table_list[i]);
> + if (err) {
> + rocker_destroy_flow_tables(rocker_port);
> + return err;
> + }
> + }
> +
> + return 0;
> +}
Can these be moved up above drivers? They don't seem driver or device
specific. Call .ndo_flow_get_tbls to get table list.
> +
> +#ifdef CONFIG_NET_FLOW_TABLES
> +static struct net_flow_tbl **rocker_get_tables(struct net_device *d)
> +{
> + return rocker_table_list;
> +}
> +
> +static struct net_flow_hdr **rocker_get_headers(struct net_device *d)
> +{
> + return rocker_header_list;
> +}
> +
> +static struct net_flow_action **rocker_get_actions(struct net_device *d)
> +{
> + return rocker_action_list;
> +}
> +
> +static struct net_flow_tbl_node **rocker_get_tgraph(struct net_device *d)
> +{
> + return rocker_table_nodes;
> +}
> +
> +static struct net_flow_hdr_node **rocker_get_hgraph(struct net_device *d)
> +{
> + return rocker_header_nodes;
> +}
> +#endif
Do these need to be functions since they all just return static pointer lists?
> static const struct net_device_ops rocker_port_netdev_ops = {
> .ndo_open = rocker_port_open,
> .ndo_stop = rocker_port_stop,
> @@ -3795,6 +3846,13 @@ static const struct net_device_ops rocker_port_netdev_ops = {
> .ndo_bridge_getlink = rocker_port_bridge_getlink,
> .ndo_switch_parent_id_get = rocker_port_switch_parent_id_get,
> .ndo_switch_port_stp_update = rocker_port_switch_port_stp_update,
> +#ifdef CONFIG_NET_FLOW_TABLES
> + .ndo_flow_get_tbls = rocker_get_tables,
> + .ndo_flow_get_hdrs = rocker_get_headers,
> + .ndo_flow_get_actions = rocker_get_actions,
> + .ndo_flow_get_tbl_graph = rocker_get_tgraph,
> + .ndo_flow_get_hdr_graph = rocker_get_hgraph,
Please keep the rocker_port_xxx for .ndo_xxx naming convention.
> +#endif
> };
>
> /********************
> @@ -3960,6 +4018,7 @@ static void rocker_remove_ports(struct rocker *rocker)
> rocker_port = rocker->ports[i];
> rocker_port_ig_tbl(rocker_port, ROCKER_OP_FLAG_REMOVE);
> unregister_netdev(rocker_port->dev);
> + rocker_destroy_flow_tables(rocker_port);
> }
> kfree(rocker->ports);
> }
> @@ -4023,6 +4082,12 @@ static int rocker_probe_port(struct rocker *rocker, unsigned int port_number)
> goto err_port_ig_tbl;
> }
>
> + err = rocker_init_flow_tables(rocker_port);
> + if (err) {
> + dev_err(&pdev->dev, "install flow table failed\n");
s/table/tables/
> + goto err_port_ig_tbl;
Need to rocker_port_ig_tbl(rocker_port, ROCKER_OP_FLAG_REMOVE) to clean up.
-scott
^ permalink raw reply
* Re: [PATCH] net: rocker: Add basic netdev counters - v2
From: David Miller @ 2015-01-18 6:56 UTC (permalink / raw)
To: sfeldma; +Cc: dsahern, netdev, jiri
In-Reply-To: <CAE4R7bA3QG4LDvVQywDsRuJzJYv4mBq3=OXi2L=qGDfa4a8ykw@mail.gmail.com>
From: Scott Feldman <sfeldma@gmail.com>
Date: Fri, 16 Jan 2015 15:41:41 -0800
> On Fri, Jan 16, 2015 at 1:22 PM, David Ahern <dsahern@gmail.com> wrote:
>> Add packet and byte counters for RX and TX paths.
>>
>> $ ifconfig eth1
>> eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
>> inet6 fe80::5054:ff:fe12:3501 prefixlen 64 scopeid 0x20<link>
>> ether 52:54:00:12:35:01 txqueuelen 1000 (Ethernet)
>> RX packets 63 bytes 15813 (15.4 KiB)
>> RX errors 1 dropped 0 overruns 0 frame 0
>> TX packets 79 bytes 17991 (17.5 KiB)
>> TX errors 7 dropped 0 overruns 0 carrier 0 collisions 0
>>
>> Rx / Tx errors tested by injecting faults in qemu's hardware model for Rocker.
>>
>> v2:
>> - moved counter locations to avoid potential use after free per Florian's comment
>>
>> Signed-off-by: David Ahern <dsahern@gmail.com>
>> Cc: Scott Feldman <sfeldma@gmail.com>
>> Cc: Jiri Pirko <jiri@resnulli.us>
>
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
>
> Thanks David. I think this is good enough for first pass. Longer
> term, I'd like to see this replaced by stats read from device for each
> port.
Ok, applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH v3 net-next 1/1] ip_tunnel: Create percpu gro_cell
From: David Miller @ 2015-01-18 6:57 UTC (permalink / raw)
To: kafai; +Cc: netdev, eric.dumazet, kernel-team
In-Reply-To: <1421431860-1960597-2-git-send-email-kafai@fb.com>
From: Martin KaFai Lau <kafai@fb.com>
Date: Fri, 16 Jan 2015 10:11:00 -0800
> In the ipip tunnel, the skb->queue_mapping is lost in ipip_rcv().
> All skb will be queued to the same cell->napi_skbs. The
> gro_cell_poll is pinned to one core under load. In production traffic,
> we also see severe rx_dropped in the tunl iface and it is probably due to
> this limit: skb_queue_len(&cell->napi_skbs) > netdev_max_backlog.
>
> This patch is trying to alloc_percpu(struct gro_cell) and schedule
> gro_cell_poll to process the skb in the same core.
>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/7] net: wireless: wcn36xx: get chip type from platform ops
From: Pat Erley @ 2015-01-18 8:36 UTC (permalink / raw)
To: Andy Green, Kalle Valo, Eugene Krasnikov
Cc: wcn36xx-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150118051049.31866.47265.stgit-FDDIDLfWL9/T9rR/E2HzMujRB4CPm7EUkgzjau31qRg@public.gmane.org>
On 01/17/2015 11:10 PM, Andy Green wrote:
> 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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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);
> };
>
(This all assumes this driver is currently actually being used)
Doesn't this change break any current users of wcn36xx? Couldn't you
just take the old wcn36xx_detect_chip_version and either add the check
for get_chip_type to the beginning and make it use it and return, or
fall back to the old 'broken' way?
Another alternative would be to update wcn36xx_detect_chip_version to
behave like you expect get_chip_type to, and make it the default and let
platforms override it.
--
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: [RFC PATCH net-next] bridge: ability to disable forwarding on a port
From: roopa @ 2015-01-18 8:48 UTC (permalink / raw)
To: Arad, Ronen
Cc: 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,
wkok@cumulusnetworks.com, gospo@cumulusnetworks.com
In-Reply-To: <E4CD12F19ABA0C4D8729E087A761DC3505DF57DB@ORSMSX101.amr.corp.intel.com>
On 1/17/15, 1:14 PM, Arad, Ronen wrote:
>
>> -----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.
Even with the offload feature flag, there are a few bridge port
attributes that can be set
from userspace which can be different for sw and hw. So, with this patch
I was
trying to see if making it similar to the other existing flags would be
better.
> The alternatives suggested (offload flag or skb flag) are better.
Glad to know your opinion.
>
> 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?
This patch places it in __br_forward to just make sure all the paths
including the netfilter
hook is traversed for these packets. And plus it was written with
minimal changes in mind.
We have not measured it but the extra overhead for these pkts that hit
the kernel has been negligible. But, I will look at the code to see if
it can be avoided.
Thanks,
Roopa
^ permalink raw reply
* Re: [RFC PATCH net-next] bridge: ability to disable forwarding on a port
From: roopa @ 2015-01-18 9:10 UTC (permalink / raw)
To: Scott Feldman
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: <CAE4R7bBeNojtj3Zyd6+zSJFGRjG4vejBObnS1XUFAfJDZJZYow@mail.gmail.com>
On 1/17/15, 5:05 PM, Scott Feldman wrote:
> 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?
Not sure. I don't know the use case, but I think I might have heard that
there could be a case
where a switch port could be bridged with a vm's port running on the
switch. (?)
>
>> 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.
yes, that thought crossed my mind too. I had BR_FORWARDING initially and
to make it sound less like
STP changed it to BR_FORWARD. :)
> 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 */
That's a good idea. So, unknown unicast and broadcast will be covered
with that.
Am afraid there might be other packets, like the acl LOG packet hitting
the CPU/kernel (?)
I will check if there are others.
>
>> +#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.
This patch strategically places it in __br_forward to catch all forwards
(due to floods or no floods ..with direct call to br_foward)
with minimal code changes in mind. Will see if the clone can be avoided.
>
> Also, the above code is skipping some vlan checks (br_handle_vlan).
The br_handle_vlan checks seemed not necessary for a packet getting dropped.
But, will check and fix if its needed while the packet traverses the
netfilter hook and before it gets dropped.
Thanks,
Roopa
^ permalink raw reply
* Re: [PATCH net-next] iproute2: bridge: support vlan range
From: roopa @ 2015-01-18 9:11 UTC (permalink / raw)
To: Scott Feldman; +Cc: Netdev, shemminger, vyasevic@redhat.com, Wilson Kok
In-Reply-To: <CAE4R7bA2VHepe8CCYuubH8teXMvRry10jnpsisYq+7Qv+gXzHQ@mail.gmail.com>
On 1/17/15, 5:35 PM, Scott Feldman wrote:
> 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"?
correct ..
# bridge vlan add vid 10- dev dummy0
Invalid VLAN range "10-0"
>
> Is "vid -15" same as "vid 0-15"?
correct
# bridge vlan add vid -10 dev dummy0
root@net-next:~/iproute2# bridge vlan show
port vlan ids
br0 1 PVID Egress Untagged
dummy0 0 PVID
1
2
3
4
5
6
7
8
9
10
dummy1 1 PVID Egress Untagged
maybe vlan 0 should not be allowed. Will check
>
> What is "vid -"?
>
> Does the "-" char mess up shells? I don't know the answer; just asking.
No it does not :)
# bridge vlan add vid -
Device and VLAN ID are required arguments.
>
>> + 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.
>
There is already a "memset(&vinfo, 0, sizeof(vinfo));" in the code in
the beginning of the function.
And the code is already using vinfo for flags. That's the reason i
decided to use vinfo here.
Thanks,
Roopa
^ permalink raw reply
* [patch net-next] switchdev: fix typo in inline function definition
From: Jiri Pirko @ 2015-01-18 9:25 UTC (permalink / raw)
To: netdev; +Cc: davem, sfeldma
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
include/net/switchdev.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/switchdev.h b/include/net/switchdev.h
index 201120e..205e636 100644
--- a/include/net/switchdev.h
+++ b/include/net/switchdev.h
@@ -69,7 +69,7 @@ static inline int unregister_netdev_switch_notifier(struct notifier_block *nb)
}
static inline int call_netdev_switch_notifiers(unsigned long val, struct net_device *dev,
- struct netdev_switch_notifier_info *info);
+ struct netdev_switch_notifier_info *info)
{
return NOTIFY_DONE;
}
--
1.9.3
^ permalink raw reply related
* Bridge code in net-next does not compile
From: Marcel Holtmann @ 2015-01-18 10:33 UTC (permalink / raw)
To: Network Development, David S. Miller
Hi,
when compiling net-next, the bridge code fails to compile:
CC net/bridge/br.o
In file included from net/bridge/br.c:22:0:
include/net/switchdev.h:73:1: error: expected identifier or ‘(’ before ‘{’ token
{
^
include/net/switchdev.h:71:90: warning: ‘call_netdev_switch_notifiers’ declared ‘static’ but never defined [-Wunused-function]
static inline int call_netdev_switch_notifiers(unsigned long val, struct net_device *dev,
^
I bisecting this to this commit:
commit 03bf0c281234028388108d0aee720954f5fe6924
Author: Jiri Pirko <jiri@resnulli.us>
Date: Thu Jan 15 23:49:36 2015 +0100
switchdev: introduce switchdev notifier
This patch introduces new notifier for purposes of exposing events which happen
on switch driver side. The consumers of the event messages are mainly involved
masters, namely bridge and ovs.
Suggested-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Regards
Marcel
^ permalink raw reply
* Re: Bridge code in net-next does not compile
From: Jiri Pirko @ 2015-01-18 10:39 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Network Development, David S. Miller
In-Reply-To: <D49DF51C-D713-4D2C-9CB0-F7C21403F68A@holtmann.org>
Sun, Jan 18, 2015 at 11:33:24AM CET, marcel@holtmann.org wrote:
>Hi,
>
>when compiling net-next, the bridge code fails to compile:
>
> CC net/bridge/br.o
>In file included from net/bridge/br.c:22:0:
>include/net/switchdev.h:73:1: error: expected identifier or ‘(’ before ‘{’ token
> {
> ^
>include/net/switchdev.h:71:90: warning: ‘call_netdev_switch_notifiers’ declared ‘static’ but never defined [-Wunused-function]
> static inline int call_netdev_switch_notifiers(unsigned long val, struct net_device *dev,
Hi, I already sent fix:
http://patchwork.ozlabs.org/patch/430160/
> ^
>
>I bisecting this to this commit:
>
>commit 03bf0c281234028388108d0aee720954f5fe6924
>Author: Jiri Pirko <jiri@resnulli.us>
>Date: Thu Jan 15 23:49:36 2015 +0100
>
> switchdev: introduce switchdev notifier
>
> This patch introduces new notifier for purposes of exposing events which happen
> on switch driver side. The consumers of the event messages are mainly involved
> masters, namely bridge and ovs.
>
> Suggested-by: Thomas Graf <tgraf@suug.ch>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
>Regards
>
>Marcel
>
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Bridge code in net-next does not compile
From: Marcel Holtmann @ 2015-01-18 10:45 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Network Development, David S. Miller
In-Reply-To: <20150118103938.GA1944@nanopsycho.orion>
Hi Jiri,
>> when compiling net-next, the bridge code fails to compile:
>>
>> CC net/bridge/br.o
>> In file included from net/bridge/br.c:22:0:
>> include/net/switchdev.h:73:1: error: expected identifier or ‘(’ before ‘{’ token
>> {
>> ^
>> include/net/switchdev.h:71:90: warning: ‘call_netdev_switch_notifiers’ declared ‘static’ but never defined [-Wunused-function]
>> static inline int call_netdev_switch_notifiers(unsigned long val, struct net_device *dev,
>
> Hi, I already sent fix:
>
> http://patchwork.ozlabs.org/patch/430160/
good. I was just building the same fix for it. Except with an actual commit message showing the error.
Next time please compile test your patches with CONFIG_NET_SWITCHDEV=n. You were adding code that depends on a kernel config option. So that should have been something obvious to actually compile test.
Dave, if you prefer a commit message with the error, then I can send my patch.
Regards
Marcel
^ permalink raw reply
* Re: Wireless scanning while turning off the radio problem..
From: Arend van Spriel @ 2015-01-18 10:55 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Berg, David Miller, Linux Wireless List,
Network Development
In-Reply-To: <CA+55aFyr9LC7oLoJeyFwK4KRURbbUyO63jznTTAkQF+9LBAsfg@mail.gmail.com>
On 01/18/15 04:25, Linus Torvalds wrote:
> 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?
If I am not mistaken the "iwl N7260 thing" is a PCIe device.
iwl_pcie_irq_handler
iwl_trans_pcie_rf_kill
if (iwl_op_mode_hw_rf_kill)
iwl_trans_pcie_stop_device
The function iwl_trans_pcie_stop_device() put device in low-power and
resets the cpu on the device. So iwl_op_mode_hw_rf_kill ends up in
iwl_mvm_set_hw_rfkill_state which schedules cfg80211_rfkill_sync_work
and returns true if firmware is running. The patch below might work.
Regards,
Arend
diff --git a/drivers/net/wireless/iwlwifi/mvm/ops.c
b/drivers/net/wireless/iwlwi
index 97dfba5..685217a 100644
--- a/drivers/net/wireless/iwlwifi/mvm/ops.c
+++ b/drivers/net/wireless/iwlwifi/mvm/ops.c
@@ -779,6 +779,9 @@ static bool iwl_mvm_set_hw_rfkill_state(struct
iwl_op_mode *
if (calibrating)
iwl_abort_notification_waits(&mvm->notif_wait);
+ /* stop scheduled scan */
+ iwl_mvm_scan_offload_stop(mvm, true);
+
/*
* Stop the device if we run OPERATIONAL firmware or if we are
in the
* middle of the calibrations.
^ permalink raw reply related
* Re: Wireless scanning while turning off the radio problem..
From: Emmanuel Grumbach @ 2015-01-18 11:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Berg, David Miller, Linux Wireless List,
Network Development
In-Reply-To: <CA+55aFyr9LC7oLoJeyFwK4KRURbbUyO63jznTTAkQF+9LBAsfg@mail.gmail.com>
Hi Linus,
On Sun, Jan 18, 2015 at 5:25 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> 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?
>
we have different scan flows based on the firmware version you have,
so it would help if you could tell me what firmware you have. iwlwifi
prints the firmware version when it loads it:
loaded firmware version X.X.X.X op_mode iwl_mvm.
I'll compile your tree to try to reproduce tonight.
> 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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Problem with patch "make nlmsg_end() and genlmsg_end() void"
From: Marcel Holtmann @ 2015-01-18 11:44 UTC (permalink / raw)
To: Network Development, Johannes Berg; +Cc: David S. Miller, Tom Gundersen
Hi Johannes,
your commit 053c095a82cf773075e83d7233b5cc19a1f73ece is causing problems with systemd-networkd.
I have an up-to-date Arch Linux installation in a KVM and your change causes massive problems. It makes systemd-networkd to run out of memory.
systemd-fsck[84]: /dev/vda1: clean, 53283/131072 files, 409813/524032 blocks
Out of memory: Kill process 142 (systemd-network) score 923 or sacrifice child
Killed process 142 (systemd-network) total-vm:478416kB, anon-rss:463472kB, file-rss:460kB
[FAILED] Failed to start Network Service.
See "systemctl status systemd-networkd.service" for details.
Stopping Network Service...
[ OK ] Stopped Network Service.
Starting Network Service...
Arch Linux 3.19.0-rc4-devel+ (ttyS0)
marcel login: Out of memory: Kill process 154 (systemd-network) score 932 or sacrifice child
Killed process 154 (systemd-network) total-vm:540784kB, anon-rss:468380kB, file-rss:132kB
Out of memory: Kill process 158 (systemd-network) score 932 or sacrifice child
Killed process 158 (systemd-network) total-vm:540388kB, anon-rss:468528kB, file-rss:48kB
Out of memory: Kill process 160 (systemd-network) score 932 or sacrifice child
Killed process 160 (systemd-network) total-vm:540916kB, anon-rss:468528kB, file-rss:4kB
Out of memory: Kill process 162 (systemd-network) score 931 or sacrifice child
Killed process 162 (systemd-network) total-vm:540916kB, anon-rss:468104kB, file-rss:76kB
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 5/7] net: wireless: wcn36xx: swallow two wcn3620 IND messages
From: Sergei Shtylyov @ 2015-01-18 11:47 UTC (permalink / raw)
To: Andy Green, Kalle Valo, Eugene Krasnikov
Cc: wcn36xx-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150118051105.31866.43889.stgit-FDDIDLfWL9/T9rR/E2HzMujRB4CPm7EUkgzjau31qRg@public.gmane.org>
Hello.
On 1/18/2015 8:11 AM, Andy Green wrote:
> 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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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
[...]
> @@ -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;
Can't you merge these 2 cases, so that there's only one *break*?
[...]
WBR, Sergei
--
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 5/7] net: wireless: wcn36xx: swallow two wcn3620 IND messages
From: Andy Green @ 2015-01-18 12:59 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Kalle Valo, Eugene Krasnikov, wcn36xx, linux-wireless, netdev
In-Reply-To: <54BB9D3C.90306@cogentembedded.com>
On 18 January 2015 at 19:47, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Hello.
>
> On 1/18/2015 8:11 AM, Andy Green wrote:
>
>> 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
>
> [...]
>>
>> @@ -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;
>
>
> Can't you merge these 2 cases, so that there's only one *break*?
Yes will do.
-Andy
> [...]
>
> WBR, Sergei
>
^ permalink raw reply
* Re: [PATCH] isdn:gigaset:Remove unneeded TODO comment for the function,gigaset_procinfo in capi.c
From: Tilman Schmidt @ 2015-01-18 13:09 UTC (permalink / raw)
To: Nicholas Krause, hjlipp; +Cc: isdn, gigaset307x-common, netdev, linux-kernel
In-Reply-To: <1421519027-22410-1-git-send-email-xerofoify@gmail.com>
Am 17.01.2015 um 19:23 schrieb Nicholas Krause:
> This removes the no longer needed TODO comment for questioning if
> the function,gigaset_procinfo needs to do more work internally. This
> comment is no longer needed due to the function's intended use to be
> returning the name of the structure pointer passed to this function
> of type,capi_ctr. In addition due to this the function's comments
> related to it's intended job are changed to state it returns rather
> then builds the description for the structure and also that the
> function doesn't build the name string but returns the already
> generated one passed to gigaset_procinfo by the structure passed
> to this function.
>
> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
Acked-by: Tilman Schmidt <tilman@imap.cc>
Thanks,
Tilman
> ---
> drivers/isdn/gigaset/capi.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/isdn/gigaset/capi.c b/drivers/isdn/gigaset/capi.c
> index ccec777..c4d666e 100644
> --- a/drivers/isdn/gigaset/capi.c
> +++ b/drivers/isdn/gigaset/capi.c
> @@ -2336,14 +2336,14 @@ static u16 gigaset_send_message(struct capi_ctr *ctr, struct sk_buff *skb)
> }
>
> /**
> - * gigaset_procinfo() - build single line description for controller
> + * gigaset_procinfo() - return single line description for controller
> * @ctr: controller descriptor structure.
> *
> - * Return value: pointer to generated string (null terminated)
> + * Return value: pointer to already generated string (null terminated)
> */
> static char *gigaset_procinfo(struct capi_ctr *ctr)
> {
> - return ctr->name; /* ToDo: more? */
> + return ctr->name;
> }
>
> static int gigaset_proc_show(struct seq_file *m, void *v)
>
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
^ permalink raw reply
* Re: [PATCH] netlink: make nlmsg_end() and genlmsg_end() void
From: Johannes Berg @ 2015-01-18 13:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20150118.010446.405197490184285420.davem@davemloft.net>
On Sun, 2015-01-18 at 01:04 -0500, David Miller wrote:
> I like this, applied, thanks Johannes.
>
> You know, I would even be willing to apply a patch adjusting that phonet
> case. So feel free to submit that.
I can do that - I agree that it's probably fine (you'd have to be not
using libnl and writing bad code to get it wrong) but didn't really want
to do it in that patch.
Anyway it looks like I broke some dump (as reported by Marcel) so I'll
have to dig into that first.
johannes
^ 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