Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH v3 11/11] net: sched: change action API to use array of pointers to actions
From: Vlad Buslov @ 2018-05-29 10:25 UTC (permalink / raw)
  To: Marcelo Ricardo Leitner
  Cc: jiri, netdev, jhs, xiyou.wangcong, davem, ast, daniel, kliteyn
In-Reply-To: <20180528213147.GF3787@localhost.localdomain>


On Mon 28 May 2018 at 21:31, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote:
> On Mon, May 28, 2018 at 12:17:29AM +0300, Vlad Buslov wrote:
> ...
>> -int tcf_action_destroy(struct list_head *actions, int bind)
>> +int tcf_action_destroy(struct tc_action *actions[], int bind)
>>  {
>>  	const struct tc_action_ops *ops;
>> -	struct tc_action *a, *tmp;
>> -	int ret = 0;
>> +	struct tc_action *a;
>> +	int ret = 0, i;
>>  
>> -	list_for_each_entry_safe(a, tmp, actions, list) {
>> +	for (i = 0; i < TCA_ACT_MAX_PRIO && actions[i]; i++) {
> ...
>> @@ -878,10 +881,9 @@ struct tc_action *tcf_action_init_1(struct net *net, struct tcf_proto *tp,
>>  	if (TC_ACT_EXT_CMP(a->tcfa_action, TC_ACT_GOTO_CHAIN)) {
>>  		err = tcf_action_goto_chain_init(a, tp);
>>  		if (err) {
>> -			LIST_HEAD(actions);
>> +			struct tc_action *actions[TCA_ACT_MAX_PRIO] = { a };
>
> Somewhat nit.. Considering tcf_action_destroy will stop at the first
> NULL, you need only 2 slots here.

Yes, I guess NULLing whole array when only first pointer is used, is
redundant. I didn't want to be too clever in this patch and made all
actions array of same size, but I don't see anything potentially
dangerous in reducing this one.

>
>>  
>> -			list_add_tail(&a->list, &actions);
>> -			tcf_action_destroy(&actions, bind);
>> +			tcf_action_destroy(actions, bind);
>>  			NL_SET_ERR_MSG(extack, "Failed to init TC action chain");
>>  			return ERR_PTR(err);
>>  		}

Thank you for reviewing my code!

^ permalink raw reply

* Re: [PATCH net-next v2 3/7] rocker: rocker_main: Ignore bridge VLAN events
From: Ilias Apalodimas @ 2018-05-29 10:25 UTC (permalink / raw)
  To: Petr Machata
  Cc: devel, f.fainelli, andrew, nikolay, netdev, bridge, idosch, jiri,
	razvan.stefanescu, gregkh, vivien.didelot, davem
In-Reply-To: <708f594ac6cef4a63a6f6a28759098c4d7922976.1527503302.git.petrm@mellanox.com>

Hi Petr, 

On Mon, May 28, 2018 at 12:50:09PM +0200, Petr Machata wrote:
> Ignore VLAN events where the orig_dev is the bridge device itself.
> 
> Signed-off-by: Petr Machata <petrm@mellanox.com>
> ---
>  drivers/net/ethernet/rocker/rocker_main.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/net/ethernet/rocker/rocker_main.c b/drivers/net/ethernet/rocker/rocker_main.c
> index e73e4fe..aeafdb9 100644
> --- a/drivers/net/ethernet/rocker/rocker_main.c
> +++ b/drivers/net/ethernet/rocker/rocker_main.c
> @@ -1632,6 +1632,9 @@ rocker_world_port_obj_vlan_add(struct rocker_port *rocker_port,
>  {
>  	struct rocker_world_ops *wops = rocker_port->rocker->wops;
>  
> +	if (netif_is_bridge_master(vlan->obj.orig_dev))
> +		return -EOPNOTSUPP;
> +
What will happen to the "bridge vlan add dev br0 vid X pvid untagged self" when
the lower level (the driver) returns -EOPNOTSUPP? Will it avoid adding a vlan on
the bridge ?

>  	if (!wops->port_obj_vlan_add)
>  		return -EOPNOTSUPP;
>  
> @@ -1647,6 +1650,9 @@ rocker_world_port_obj_vlan_del(struct rocker_port *rocker_port,
>  {
>  	struct rocker_world_ops *wops = rocker_port->rocker->wops;
>  
> +	if (netif_is_bridge_master(vlan->obj.orig_dev))
> +		return -EOPNOTSUPP;
> +
>  	if (!wops->port_obj_vlan_del)
>  		return -EOPNOTSUPP;
>  	return wops->port_obj_vlan_del(rocker_port, vlan);
> -- 
> 2.4.11
> 

^ permalink raw reply

* Re: [PATCH v3 00/11] Modify action API for implementing lockless actions
From: Vlad Buslov @ 2018-05-29 10:20 UTC (permalink / raw)
  To: Cong Wang
  Cc: Jiri Pirko, Linux Kernel Network Developers, Jamal Hadi Salim,
	David Miller, Alexei Starovoitov, Daniel Borkmann, kliteyn
In-Reply-To: <CAM_iQpVMcg3wb2MvChgTLuhEgH3zad5tJR2_FVWwuhkopABorw@mail.gmail.com>

On Tue 29 May 2018 at 04:26, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> Currently, all netlink protocol handlers for updating rules, actions and
>> qdiscs are protected with single global rtnl lock which removes any
>> possibility for parallelism. This patch set is a first step to remove
>> rtnl lock dependency from TC rules update path.
>>
>> Recently, new rtnl registration flag RTNL_FLAG_DOIT_UNLOCKED was added.
>> Handlers registered with this flag are called without RTNL taken. End
>> goal is to have rule update handlers(RTM_NEWTFILTER, RTM_DELTFILTER,
>> etc.) to be registered with UNLOCKED flag to allow parallel execution.
>> However, there is no intention to completely remove or split rtnl lock
>> itself. This patch set addresses specific problems in action API that
>> prevents it from being executed concurrently.
>
>
> Great, your goal is much clear now! So can I expect this patchset is to
> _completely_ get rid of RTNL lock from action update paths, correct?

No, this patch set is preparation only and deals with specific issues in
act API. I guess I should specify it in cover letter. There is one more
patch set that changes individual actions and...

>
> I ask because this is your first step, RTNL is still acquired on upper layer,
> that is, filter update paths.

... several more patch sets that update cls API, including filter update path.

>
>
>>
>> As a preparation for executing TC rules update handlers without rtnl
>> lock, action API code was audited to determine areas that assume
>> external synchronization with rtnl lock and must be changed to allow
>> safe concurrent access with following results:
>>
>> 1. Action idr is already protected with spinlock. However, some code
>>    paths assume that idr state is not changes between several
>>    consecutive tcf_idr_* function calls.
>> 2. tc_action reference and bind counters are implemented as plain
>>    integers. They purpose was to allow single actions to be shared
>>    between multiple filters, not to provide means for concurrent
>>    modification.
>> 3. tc_action 'cookie' pointer field is not protected against
>>    modification.
>> 4. Action API functions, that work with set of actions, use intrusive
>>    linked list, which cannot be used concurrently without additional
>>    synchronization.
>> 5. Action API functions don't take reference to actions while using
>>    them, assuming external synchronization with rtnl lock.
>
>
> Fair enough, thanks for the details, but some high-level things are still
> missing:
>
> 1. What lock protects action updates with your patches? Since you remove
> RTNL from these paths, I assume no lock at all except the existing spinlock?
> Please state here in your cover letter.

Next patch set updates every action implementation. However, it is safe
to apply this patchset without next one because I didn't re-register any
handlers with UNLOCKED flag yet, so all rules/actions update paths are
still synchronized with RTNL.

>
>
> 2. Assume 1) is correct, how do you guarantee an action update is atomic?
> Let's say I have action foo:
>
> struct act_foo
> {
>   int a;
>   int b;
> };
>
> With RTNL:
>
> rtnl_lock();
> act_foo->a = a;
> if (a == X)
>   act_foo->b = b;
> rtnl_unlock();
>
> Without any lock (as I assumed):
>
>
> act_foo->a = a;
> // fast path now reads new ->a but old ->b
> if (act_foo->a == X)
> // Other slow path may be changing ->a too
>   act_foo->b = b;
>
> If my assumption is correct, please explain the above question in your
> cover letter, it is very important for understanding your 11 patches.
>
> If my assumption is wrong, please be specific on which lock protects
> which paths here.

Your observation, that this patch is not enough and individual actions
must be updates in order to be executed concurrently, is correct. This
issue is dealt with in next patch set. For most of actions that require
additional synchronization, I used tcf_spinlock or rcu + atomic
exchange.

>
>
> 3. How are actions like act_mirred and act_ipt updated w/o RTNL?
>
> act_mirred requires to hold a refcnt for target device:
>
>         if (dev != NULL) {
>                 if (ret != ACT_P_CREATED)
>                         dev_put(rcu_dereference_protected(m->tcfm_dev, 1));
>                 dev_hold(dev);
>                 rcu_assign_pointer(m->tcfm_dev, dev);
>                 m->tcfm_mac_header_xmit = mac_header_xmit;
>         }
>
> Without RTNL, how is dev_put()+dev_hold() be atomic in !CREATED case?

Again, next set.

>
> act_ipt calls xt_request_find_target() and xt_check_target(), I guess both
> assumes RTNL?

Do they? Internally, target list is protected with mutex.
Anyway, third patch in this series adds 'rtnl_held' argument to action
init function, that allows actions to take(or release) rtnl lock when
necessary. It is intended to be used specifically in this kind of
situations when some external API requires caller to have rtnl lock. I
guess I should also add this info to cover letter. I have omitted it
because that argument is not used in this patch set.

>
> Or you just leave these exceptions as they are but make the rest actions
> lockless? If so, please list all of them here and describe why are they
> special.

All actions will be updated in next set, without exceptions.

>
>
> Last, since your end goal is to remove RTNL from filter update paths,
> how does it work if a tc filter block shared among different qdiscs?
> Assume a tc filter block can be shared by different qdiscs on different
> devs.

Basically, what I do with blocks in patch set, that changes
qdisc->block->chain->proto->filter tree to remove rtnl lock dependency,
is:
 - Change block reference counter type to refcount_t.
 - Take reference to block when using it in slow path.
 - Protect block idr in tcf_net with additional spinlock.
(Same approach that I employed in current patch set for actions and
action idr)

Anything specific that I'm missing? Could you describe potential issue
with shared blocks in more details?

>
>
> Thanks!

^ permalink raw reply

* Re: Unable to create ip alias on bridge interface
From: Akshat Kakkar @ 2018-05-29 10:09 UTC (permalink / raw)
  To: Michal Kubecek; +Cc: netdev
In-Reply-To: <CAA5aLPimhYWGLZY9g7x8UjHbY2_R8evkXpxaNZ8kAj1iKJztMQ@mail.gmail.com>

For following commands,
  ip addr add 10.10.10.1/24 brd +  dev br0
  ip addr add 10.10.10.2/24 brd +  dev br0
  ip addr add 20.20.20.1/24 brd +  dev br0
  ip addr add 20.20.20.2/24 brd +  dev br0

Both 10.10.10.1 and 20.20.20.1 becomes primary. Which one will be used
as source IP?

Is it nextHop of route that will decide?

And what about communication in local subnet, say ping to 10.10.10.200
and 20.20.20.200? Will source for both will change according to
destination IP?

On Mon, May 28, 2018 at 11:50 PM, Akshat Kakkar <akshat.1984@gmail.com> wrote:
> Thanks for clarifying that first ip will be used as primary ip.
> I have 2 further queries on this.
> 1. How can this survive across reboots without having a custom script
> on boot up? Like some ifcfg file,etc.
> 2. is there a way to tell to make a given ip as primary, irrespective of order?
>
> On Mon, May 28, 2018 at 5:35 PM, Michal Kubecek <mkubecek@suse.cz> wrote:
>> On Mon, May 28, 2018 at 02:35:41PM +0530, Akshat Kakkar wrote:
>>> I am having a bridge named br0 having ports eno1 and eno2 as members.
>>> I have given IP to br0 as 10.10.10.1/24
>>>
>>> Now I want to create alias on br0 as br0:1 and give IP as
>>> 10.10.10.2/24, but I am unable to.
>>>
>>> I know, we can add multiple IPs to br0 using "ip addr" command, but I
>>> dont want to do it that way as I want all outgoing connections from
>>> br0 to take src ip as 10.10.10.1. I know by providing option of "src"
>>> in all routes, things can work but this looks more like a hack and
>>> less of a solution.
>>
>> I don't understand. There are no actual aliases since kernel 2.2 and an
>> attempt to add "br0:1 with address 10.10.10.2/24" using ifconfig should
>> result in the same configuration as
>>
>>   ip addr add 10.10.10.2/24 brd + label br0:1 dev br0
>>
>> where the "label br0:1" part only adds a label which allows ifconfig to
>> see the new address.
>>
>> As both addresses share the same range, you don't even have to worry
>> about source address as primary address (10.10.10.1 - or first one added
>> in general) will be used unless specified otherwise.
>>
>> Michal Kubecek

^ permalink raw reply

* Re: [PATCH] mac80211_hwsim: add error check to call to rhashtable_init
From: Johannes Berg @ 2018-05-29 10:01 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: Colin King, Kalle Valo, David S . Miller, linux-wireless, netdev,
	kernel-janitors, linux-kernel
In-Reply-To: <20180529100049.up6wzjkzmd5a3v2q@mwanda>

On Tue, 2018-05-29 at 13:00 +0300, Dan Carpenter wrote:
> On Tue, May 29, 2018 at 11:17:08AM +0200, Johannes Berg wrote:
> > On Tue, 2018-05-29 at 10:14 +0100, Colin King wrote:
> > > 
> > > @@ -3573,7 +3573,9 @@ static int __init init_mac80211_hwsim(void)
> > >  	hwsim_wq = alloc_workqueue("hwsim_wq", 0, 0);
> > >  	if (!hwsim_wq)
> > >  		return -ENOMEM;
> > > -	rhashtable_init(&hwsim_radios_rht, &hwsim_rht_params);
> > > +	err = rhashtable_init(&hwsim_radios_rht, &hwsim_rht_params);
> > > +	if (err)
> > > +		return err;
> > 
> > That's missing a workqueue free, but I can fix that while applying if
> > you prefer.
> > 
> 
> And we don't free the hashtable on error either.

Heh. Ok, I guess I'll make a whole new commit to fix up all the things
here.

johannes

^ permalink raw reply

* Re: [PATCH] mac80211_hwsim: add error check to call to rhashtable_init
From: Dan Carpenter @ 2018-05-29 10:00 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Colin King, Kalle Valo, David S . Miller, linux-wireless, netdev,
	kernel-janitors, linux-kernel
In-Reply-To: <1527585428.6955.7.camel@sipsolutions.net>

On Tue, May 29, 2018 at 11:17:08AM +0200, Johannes Berg wrote:
> On Tue, 2018-05-29 at 10:14 +0100, Colin King wrote:
> > 
> > @@ -3573,7 +3573,9 @@ static int __init init_mac80211_hwsim(void)
> >  	hwsim_wq = alloc_workqueue("hwsim_wq", 0, 0);
> >  	if (!hwsim_wq)
> >  		return -ENOMEM;
> > -	rhashtable_init(&hwsim_radios_rht, &hwsim_rht_params);
> > +	err = rhashtable_init(&hwsim_radios_rht, &hwsim_rht_params);
> > +	if (err)
> > +		return err;
> 
> That's missing a workqueue free, but I can fix that while applying if
> you prefer.
> 

And we don't free the hashtable on error either.

regards,
dan carpenter

^ permalink raw reply

* [PATCH] bpfilter: fix building without CONFIG_INET
From: Arnd Bergmann @ 2018-05-29  9:55 UTC (permalink / raw)
  To: David S. Miller, Arnd Bergmann, Alexei Starovoitov; +Cc: netdev, linux-kernel

bpfilter_process_sockopt is a callback that gets called from
ip_setsockopt() and ip_getsockopt(). However, when CONFIG_INET is
disabled, it never gets called at all, and assigning a function to the
callback pointer results in a link failure:

net/bpfilter/bpfilter_kern.o: In function `__stop_umh':
bpfilter_kern.c:(.text.unlikely+0x3): undefined reference to `bpfilter_process_sockopt'
net/bpfilter/bpfilter_kern.o: In function `load_umh':
bpfilter_kern.c:(.init.text+0x73): undefined reference to `bpfilter_process_sockopt'

Since there is no caller in this configuration, I assume we can
simply make the assignment conditional.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
This happened on last week's linux-next tree. Since there hasn't
been an update since, it's possible that this is fixed in another
tree already.
---
 net/bpfilter/bpfilter_kern.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/net/bpfilter/bpfilter_kern.c b/net/bpfilter/bpfilter_kern.c
index 7596314b61c7..b13d058f8c34 100644
--- a/net/bpfilter/bpfilter_kern.c
+++ b/net/bpfilter/bpfilter_kern.c
@@ -33,7 +33,8 @@ static void shutdown_umh(struct umh_info *info)
 
 static void __stop_umh(void)
 {
-	if (bpfilter_process_sockopt) {
+	if (IS_ENABLED(CONFIG_INET) &&
+	    bpfilter_process_sockopt) {
 		bpfilter_process_sockopt = NULL;
 		shutdown_umh(&info);
 	}
@@ -98,7 +99,9 @@ static int __init load_umh(void)
 		stop_umh();
 		return -EFAULT;
 	}
-	bpfilter_process_sockopt = &__bpfilter_process_sockopt;
+	if (IS_ENABLED(CONFIG_INET))
+		bpfilter_process_sockopt = &__bpfilter_process_sockopt;
+
 	return 0;
 }
 
-- 
2.9.0

^ permalink raw reply related

* Re: Unable to create ip alias on bridge interface
From: Michal Kubecek @ 2018-05-29  9:32 UTC (permalink / raw)
  To: netdev; +Cc: Akshat Kakkar
In-Reply-To: <CAA5aLPimhYWGLZY9g7x8UjHbY2_R8evkXpxaNZ8kAj1iKJztMQ@mail.gmail.com>

On Mon, May 28, 2018 at 11:50:05PM +0530, Akshat Kakkar wrote:
> 1. How can this survive across reboots without having a custom script
> on boot up? Like some ifcfg file,etc.

Every reasonable distribution should provide a way to use more than one
address on an interface. But as there is no universal standard for
config files and their format, there is no universal standard for
listing multiple addresses either. You have to check the documentation
of your distribution.

> 2. is there a way to tell to make a given ip as primary, irrespective
> of order?

AFAIK there is no interface allowing to switch the primary address. It
only changes when you delete primary address and have promote_secondaries
enabled for the interface.

Also, don't forget that this primary/secondary distinction is only done
for addresses with the same range (which would create the same automatic
route), i.e. e.g. 10.0.1.42/24 and 10.0.1.43/24 but not if it's e.g.
10.0.1.42/24 and 10.0.2.42/24.

Michal Kubecek

^ permalink raw reply

* [PATCH net-next 1/1] qed*: Add link change count value to ethtool statistics display.
From: Sudarsana Reddy Kalluru @ 2018-05-29  9:31 UTC (permalink / raw)
  To: davem; +Cc: netdev, ariel.elior

This patch adds driver changes for capturing the link change count in
ethtool statistics display.

Please consider applying this to "net-next".

Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
---
 drivers/net/ethernet/qlogic/qed/qed_l2.c        | 12 ++++++++++--
 drivers/net/ethernet/qlogic/qede/qede.h         |  1 +
 drivers/net/ethernet/qlogic/qede/qede_ethtool.c |  2 ++
 drivers/net/ethernet/qlogic/qede/qede_main.c    |  1 +
 include/linux/qed/qed_if.h                      |  1 +
 5 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_l2.c b/drivers/net/ethernet/qlogic/qed/qed_l2.c
index 5e655c3..1e0254a 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_l2.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_l2.c
@@ -1852,6 +1852,11 @@ static void __qed_get_vport_port_stats(struct qed_hwfn *p_hwfn,
 		p_ah->tx_1519_to_max_byte_packets =
 		    port_stats.eth.u1.ah1.t1519_to_max;
 	}
+
+	p_common->link_change_count = qed_rd(p_hwfn, p_ptt,
+					     p_hwfn->mcp_info->port_addr +
+					     offsetof(struct public_port,
+						      link_change_count));
 }
 
 static void __qed_get_vport_stats(struct qed_hwfn *p_hwfn,
@@ -1959,11 +1964,14 @@ void qed_reset_vport_stats(struct qed_dev *cdev)
 
 	/* PORT statistics are not necessarily reset, so we need to
 	 * read and create a baseline for future statistics.
+	 * Link change stat is maintained by MFW, return its value as is.
 	 */
-	if (!cdev->reset_stats)
+	if (!cdev->reset_stats) {
 		DP_INFO(cdev, "Reset stats not allocated\n");
-	else
+	} else {
 		_qed_get_vport_stats(cdev, cdev->reset_stats);
+		cdev->reset_stats->common.link_change_count = 0;
+	}
 }
 
 static enum gft_profile_type
diff --git a/drivers/net/ethernet/qlogic/qede/qede.h b/drivers/net/ethernet/qlogic/qede/qede.h
index 2d3f09e..df791e2 100644
--- a/drivers/net/ethernet/qlogic/qede/qede.h
+++ b/drivers/net/ethernet/qlogic/qede/qede.h
@@ -87,6 +87,7 @@ struct qede_stats_common {
 	u64 coalesced_aborts_num;
 	u64 non_coalesced_pkts;
 	u64 coalesced_bytes;
+	u64 link_change_count;
 
 	/* port */
 	u64 rx_64_byte_packets;
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
index 8c6fdad..f374e18 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
@@ -170,6 +170,8 @@
 	QEDE_STAT(coalesced_aborts_num),
 	QEDE_STAT(non_coalesced_pkts),
 	QEDE_STAT(coalesced_bytes),
+
+	QEDE_STAT(link_change_count),
 };
 
 #define QEDE_NUM_STATS	ARRAY_SIZE(qede_stats_arr)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_main.c b/drivers/net/ethernet/qlogic/qede/qede_main.c
index 9e70f71..cbfe892 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_main.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_main.c
@@ -398,6 +398,7 @@ void qede_fill_by_demand_stats(struct qede_dev *edev)
 	p_common->brb_truncates = stats.common.brb_truncates;
 	p_common->brb_discards = stats.common.brb_discards;
 	p_common->tx_mac_ctrl_frames = stats.common.tx_mac_ctrl_frames;
+	p_common->link_change_count = stats.common.link_change_count;
 
 	if (QEDE_IS_BB(edev)) {
 		struct qede_stats_bb *p_bb = &edev->stats.bb;
diff --git a/include/linux/qed/qed_if.h b/include/linux/qed/qed_if.h
index 44af652..4444491 100644
--- a/include/linux/qed/qed_if.h
+++ b/include/linux/qed/qed_if.h
@@ -1179,6 +1179,7 @@ struct qed_eth_stats_common {
 	u64	tx_mac_mc_packets;
 	u64	tx_mac_bc_packets;
 	u64	tx_mac_ctrl_frames;
+	u64	link_change_count;
 };
 
 struct qed_eth_stats_bb {
-- 
1.8.3.1

^ permalink raw reply related

* Re: [PATCH] brcmfmac: stop watchdog before detach and free everything
From: Arend van Spriel @ 2018-05-29  9:25 UTC (permalink / raw)
  To: Michael Trimarchi
  Cc: Franky Lin, Hante Meuleman, Chi-Hsien Lin, Wright Feng,
	Kalle Valo, David S. Miller, Pieter-Paul Giesberts, Ian Molton,
	linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
	netdev, linux-kernel
In-Reply-To: <1527493857-2220-1-git-send-email-michael@amarulasolutions.com>

On 5/28/2018 9:50 AM, Michael Trimarchi wrote:
> Watchdog need to be stopped in brcmf_sdio_remove to avoid
> i
> The system is going down NOW!
> [ 1348.110759] Unable to handle kernel NULL pointer dereference at virtual address 000002f8
> Sent SIGTERM to all processes

[snip]

Please send a V2 with your configuration details to the commit message, 
ie. using built-in driver, no firmware in place, etc.

Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> ---
>   drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 7 +++++++
>   1 file changed, 7 insertions(+)

^ permalink raw reply

* Re: [PATCH] mac80211_hwsim: add error check to call to rhashtable_init
From: Colin Ian King @ 2018-05-29  9:23 UTC (permalink / raw)
  To: Johannes Berg, Kalle Valo, David S . Miller, linux-wireless,
	netdev
  Cc: kernel-janitors, linux-kernel
In-Reply-To: <1527585428.6955.7.camel@sipsolutions.net>

On 29/05/18 10:17, Johannes Berg wrote:
> On Tue, 2018-05-29 at 10:14 +0100, Colin King wrote:
>>
>> @@ -3573,7 +3573,9 @@ static int __init init_mac80211_hwsim(void)
>>  	hwsim_wq = alloc_workqueue("hwsim_wq", 0, 0);
>>  	if (!hwsim_wq)
>>  		return -ENOMEM;
>> -	rhashtable_init(&hwsim_radios_rht, &hwsim_rht_params);
>> +	err = rhashtable_init(&hwsim_radios_rht, &hwsim_rht_params);
>> +	if (err)
>> +		return err;
> 
> That's missing a workqueue free, but I can fix that while applying if
> you prefer.

Please do. Thanks
> 
> johannes
> 

^ permalink raw reply

* Re: [PATCH] brcmfmac: stop watchdog before detach and free everything
From: Arend van Spriel @ 2018-05-29  9:22 UTC (permalink / raw)
  To: Michael Nazzareno Trimarchi, Andy Shevchenko
  Cc: Franky Lin, Hante Meuleman, Chi-Hsien Lin, Wright Feng,
	Kalle Valo, David S. Miller, Pieter-Paul Giesberts, Ian Molton,
	open list:TI WILINK WIRELES...,
	open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
	brcm80211-dev-list, netdev, LKML
In-Reply-To: <CAOf5uwkLT_-esTkqj-Mhbsn_f-JETs+XF+vd8v=U+FQSoSPcQA@mail.gmail.com>

On 5/28/2018 5:33 PM, Michael Nazzareno Trimarchi wrote:
> Hi Andy
>
> The problem seems really easy to solve:
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> index 412a05b..ba60b151 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> @@ -4227,13 +4227,7 @@ struct brcmf_sdio *brcmf_sdio_probe(struct
> brcmf_sdio_dev *sdiodev)
>          timer_setup(&bus->timer, brcmf_sdio_watchdog, 0);
>          /* Initialize watchdog thread */
>          init_completion(&bus->watchdog_wait);
> -       bus->watchdog_tsk = kthread_run(brcmf_sdio_watchdog_thread,
> -                                       bus, "brcmf_wdog/%s",
> -                                       dev_name(&sdiodev->func1->dev));
> -       if (IS_ERR(bus->watchdog_tsk)) {
> -               pr_warn("brcmf_watchdog thread failed to start\n");
> -               bus->watchdog_tsk = NULL;
> -       }
> +
>          /* Initialize DPC thread */
>          bus->dpc_triggered = false;
>          bus->dpc_running = false;
> @@ -4281,6 +4275,14 @@ struct brcmf_sdio *brcmf_sdio_probe(struct
> brcmf_sdio_dev *sdiodev)
>                  goto fail;
>          }
>
> +       bus->watchdog_tsk = kthread_run(brcmf_sdio_watchdog_thread,
> +                                       bus, "brcmf_wdog/%s",
> +                                       dev_name(&sdiodev->func1->dev));
> +       if (IS_ERR(bus->watchdog_tsk)) {
> +               pr_warn("brcmf_watchdog thread failed to start\n");
> +               bus->watchdog_tsk = NULL;
> +       }
> +
>          return bus;

Hi Michael,

That makes no sense. Or are you saying the function 
brcmf_fw_get_firmwares() fails for you? Oh wait, you mentioned the 
driver was built-in, right? The above change does not solve the issue. 
It just makes it less likely to occur. So I think your initial fix is 
the best solution for this.

Regards,
Arend

^ permalink raw reply

* Re: [PATCH] mac80211_hwsim: add error check to call to rhashtable_init
From: Johannes Berg @ 2018-05-29  9:17 UTC (permalink / raw)
  To: Colin King, Kalle Valo, David S . Miller, linux-wireless, netdev
  Cc: kernel-janitors, linux-kernel
In-Reply-To: <20180529091412.8530-1-colin.king@canonical.com>

On Tue, 2018-05-29 at 10:14 +0100, Colin King wrote:
> 
> @@ -3573,7 +3573,9 @@ static int __init init_mac80211_hwsim(void)
>  	hwsim_wq = alloc_workqueue("hwsim_wq", 0, 0);
>  	if (!hwsim_wq)
>  		return -ENOMEM;
> -	rhashtable_init(&hwsim_radios_rht, &hwsim_rht_params);
> +	err = rhashtable_init(&hwsim_radios_rht, &hwsim_rht_params);
> +	if (err)
> +		return err;

That's missing a workqueue free, but I can fix that while applying if
you prefer.

johannes

^ permalink raw reply

* [PATCH] mac80211_hwsim: add error check to call to rhashtable_init
From: Colin King @ 2018-05-29  9:14 UTC (permalink / raw)
  To: Johannes Berg, Kalle Valo, David S . Miller, linux-wireless,
	netdev
  Cc: kernel-janitors, linux-kernel

From: Colin Ian King <colin.king@canonical.com>

The call to rhashtable_init is missing an error return check, it is
possible for this to fail various different ways, so fix this by adding
an error check.

Detected by: CoverityScan, CID#1469446 ("Unchecked return value")

Fixes: c6509cc3b3e8 ("mac80211_hwsim: add hashtable with mac address keys for faster lookup")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
 drivers/net/wireless/mac80211_hwsim.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 89fc22520d40..f4b4f5690b16 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3573,7 +3573,9 @@ static int __init init_mac80211_hwsim(void)
 	hwsim_wq = alloc_workqueue("hwsim_wq", 0, 0);
 	if (!hwsim_wq)
 		return -ENOMEM;
-	rhashtable_init(&hwsim_radios_rht, &hwsim_rht_params);
+	err = rhashtable_init(&hwsim_radios_rht, &hwsim_rht_params);
+	if (err)
+		return err;
 
 	err = register_pernet_device(&hwsim_net_ops);
 	if (err)
-- 
2.17.0

^ permalink raw reply related

* Re: [PATCH net-next] net: remove bypassed check in sch_direct_xmit()
From: Sergei Shtylyov @ 2018-05-29  8:58 UTC (permalink / raw)
  To: Song Liu, netdev
  Cc: kernel-team, John Fastabend, Alexei Starovoitov, David S . Miller
In-Reply-To: <20180528213632.1412353-1-songliubraving@fb.com>

Hello!

On 5/29/2018 12:36 AM, Song Liu wrote:

> Check sch_direct_xmit() at the end of sch_direct_xmit() will be bypassed.

    "Checking netif_xmit_frozen_or_stopped()", perhaps? Else it doesn't make 
much sense...

> This is because "ret" from sch_direct_xmit() will be either NETDEV_TX_OK
> or NETDEV_TX_BUSY, and only ret == NETDEV_TX_OK == 0 will reach the
> condition:
> 
>      if (ret && netif_xmit_frozen_or_stopped(txq))
>          return false;
> 
> This patch cleans up the code by removing  the whole condition.
> 
> For more discussion about this, please refer to
>     https://marc.info/?t=152727195700008
> 
> Signed-off-by: Song Liu <songliubraving@fb.com>
> Cc: John Fastabend <john.fastabend@gmail.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: David S. Miller <davem@davemloft.net>
[...]

MBR, Sergei

^ permalink raw reply

* Re: [PATCH 0/4 RFCv2] Realtek SMI RTL836x DSA driver
From: Linus Walleij @ 2018-05-29  8:49 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Vivien Didelot, Florian Fainelli, netdev,
	OpenWrt Development List, LEDE Development List
In-Reply-To: <20180528182037.GC27177@lunn.ch>

On Mon, May 28, 2018 at 8:20 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Mon, May 28, 2018 at 07:47:48PM +0200, Linus Walleij wrote:
>> This is a second RFC version of the DSA driver for Realtek
>> RTL8366x especially RTL8366RB.
>>
>> I've been beating my head against this one and I'm not really
>> clear on why my ethernet frames are not coming through to the
>> CPU port on the chip.
>>
>> It appears when using ethtool -S on the ports that packets
>> are passing fine into the router fabric and through to the
>> CPU port but the ethernet driver where the fixed link is
>> connected refuse to accept the packages.
>
> Hi Linus
>
> Have you played with RGMII delays?

No not like I changed them or anything... the SoC has some
set-up for skew and delay on the nanosecond level, but I used the
vendor defaults, verified to be the same in their custom
kernel tree.

It's this stuff from the DTS:

+                                       conf0 {
+                                               pins = "V8 GMAC0
RXDV", "T10 GMAC1 RXDV";
+                                               skew-delay = <0>;
+                                       };
+                                       conf1 {
+                                               pins = "Y7 GMAC0 RXC",
"Y11 GMAC1 RXC";
+                                               skew-delay = <15>;
+                                       };
+                                       conf2 {
+                                               pins = "T8 GMAC0
TXEN", "W11 GMAC1 TXEN";
+                                               skew-delay = <7>;
+                                       };
+                                       conf3 {
+                                               pins = "U8 GMAC0 TXC";
+                                               skew-delay = <11>;
+                                       };
+                                       conf4 {
+                                               pins = "V11 GMAC1 TXC";
+                                               skew-delay = <10>;
+                                       };

Yours,
Linus Walleij

^ permalink raw reply

* Re: [PATCH bpf-next v2 0/3] bpf: add boot parameters for sysctl knobs
From: Jesper Dangaard Brouer @ 2018-05-29  8:37 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: Eugene Syromiatnikov, netdev, linux-kernel, linux-doc, Kees Cook,
	Kai-Heng Feng, Daniel Borkmann, Alexei Starovoitov,
	Jonathan Corbet, Jiri Olsa, brouer
In-Reply-To: <20180525194359.qckwj3tnsbufyapz@ast-mbp>

On Fri, 25 May 2018 12:44:01 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:

> On Fri, May 25, 2018 at 06:50:09PM +0200, Eugene Syromiatnikov wrote:
> > On Thu, May 24, 2018 at 04:34:51PM -0700, Alexei Starovoitov wrote:  
> > > On Thu, May 24, 2018 at 09:41:08AM +0200, Jesper Dangaard Brouer wrote:  
> > > > On Wed, 23 May 2018 15:02:45 -0700
> > > > Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> > > >   
> > > > > On Wed, May 23, 2018 at 02:18:19PM +0200, Eugene Syromiatnikov wrote:  
> > > > > > Some BPF sysctl knobs affect the loading of BPF programs, and during
> > > > > > system boot/init stages these sysctls are not yet configured.
> > > > > > A concrete example is systemd, that has implemented loading of BPF
> > > > > > programs.
> > > > > > 
> > > > > > Thus, to allow controlling these setting at early boot, this patch set
> > > > > > adds the ability to change the default setting of these sysctl knobs
> > > > > > as well as option to override them via a boot-time kernel parameter
> > > > > > (in order to avoid rebuilding kernel each time a need of changing these
> > > > > > defaults arises).
> > > > > > 
> > > > > > The sysctl knobs in question are kernel.unprivileged_bpf_disable,
> > > > > > net.core.bpf_jit_harden, and net.core.bpf_jit_kallsyms.    
> > > > > 
> > > > > - systemd is root. today it only uses cgroup-bpf progs which require root,
> > > > >   so disabling unpriv during boot time makes no difference to systemd.
> > > > >   what is the actual reason to present time?  
> > systemd also runs a lot of code, some of which is unprivileged.  
> 
> systemd processes sysctl configs first. It's essential for system
> security to do so. If you have concerns in how systemd does that
> please bring it up with systemd folks.
> 
> > > > > - say in the future systemd wants to use so_reuseport+bpf for faster
> > > > >   networking. With unpriv disable during boot, it will force systemd
> > > > >   to do such networking from root, which will lower its security barrier.  
> > No, it will force systemd not to use SO_REUSEPORT BPF.  
> 
> sorry this argument makes no sense to me.
> 
> > > > > - bpf_jit_kallsyms sysctl has immediate effect on loaded programs.
> > > > >   Flipping it during the boot or right after or any time after
> > > > >   is the same thing. Why add such boot flag then?  
> > Well, that one was for completeness.  
> 
> Should we convert all sysctls to bootparams for 'completeness' ?

The bpf_jit_kallsyms option is not there for 'completeness', it is
there because I know Daniel talked about changing the default, and this
would provide an easy option for allowing changing this default (to on)
in different distros before flipping it on in some kernel release.


> > > > > - jit_harden can be turned on by systemd. so turning it during the boot
> > > > >   will make systemd progs to be constant blinded.
> > > > >   Constant blinding protects kernel from unprivileged JIT spraying.
> > > > >   Are you worried that systemd will attack the kernel with JIT spraying?  
> > I'm worried that systemd can be exploited for a JIT spraying attack.  
> 
> I'm afraid we're not on the same page with definition of 'JIT spraying attack'.
> 
> > Another thing I'm concerned with is that the generated code is different,
> > which introduces additional complication during debugging.  
> 
> specifically what kind of complication?
> 

I think kernel.unprivileged_bpf_disable is the best example, why we
need this facility.  Once kernel.unprivileged_bpf_disable is set to 1,
it cannot be turned back to 0.

It is a policy decision that I want unprivileged_bpf_disable=1.
Setting this policy in the sysctl step is too late, because as you
write above, you expect that e.g. systemd or other boot-scripts
want/can load bpf-progs in unpriv mode.  Thus, they can violate my
policy choice.

This also leads to the before mentioned inconsistency issue. The
init-script/systemd-service will during boot successfully load unpriv
bpf-prog, but when I afterwards when I reload (or stop/start) the
service, it will fail as it no longer can load the unpriv bpf program.

If a distribution makes this policy choice, then users cannot change it
back to unprivileged_bpf_disable=0 via sysctl.  Thus, we need a boot
param to allow users to change this policy.  If the disto didn't change
this default, then we still need the boot-param, to allow users to
enforce this policy choice towards init-scripts (as explained above).

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

^ permalink raw reply

* [PATCH net-next 3/3] bnxt_en: Implement .ndo_set_vf_queues().
From: Michael Chan @ 2018-05-29  8:18 UTC (permalink / raw)
  To: davem; +Cc: netdev
In-Reply-To: <1527581920-3778-1-git-send-email-michael.chan@broadcom.com>

Implement .ndo_set_vf_queues() on the PF driver to configure the queues
parameters for individual VFs.  This allows the admin. on the host to
increase or decrease queues for individual VFs.

Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
 drivers/net/ethernet/broadcom/bnxt/bnxt.c       |   1 +
 drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 130 ++++++++++++++++++++++++
 drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.h |   2 +
 3 files changed, 133 insertions(+)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index dfa0839..2ce9779 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -8373,6 +8373,7 @@ static int bnxt_swdev_port_attr_get(struct net_device *dev,
 	.ndo_set_vf_link_state	= bnxt_set_vf_link_state,
 	.ndo_set_vf_spoofchk	= bnxt_set_vf_spoofchk,
 	.ndo_set_vf_trust	= bnxt_set_vf_trust,
+	.ndo_set_vf_queues	= bnxt_set_vf_queues,
 #endif
 #ifdef CONFIG_NET_POLL_CONTROLLER
 	.ndo_poll_controller	= bnxt_poll_controller,
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
index 7a92125..a34a32f 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
@@ -138,6 +138,136 @@ int bnxt_set_vf_trust(struct net_device *dev, int vf_id, bool trusted)
 	return 0;
 }
 
+static bool bnxt_param_ok(int new, u16 curr, u16 avail)
+{
+	int delta;
+
+	if (new <= curr)
+		return true;
+
+	delta = new - curr;
+	if (delta <= avail)
+		return true;
+	return false;
+}
+
+static void bnxt_adjust_ring_resc(struct bnxt *bp, struct bnxt_vf_info *vf,
+				  struct hwrm_func_vf_resource_cfg_input *req)
+{
+	struct bnxt_hw_resc *hw_resc = &bp->hw_resc;
+	u16 avail_cp_rings, avail_stat_ctx;
+	u16 avail_vnics, avail_ring_grps;
+	u16 cp, grp, stat, vnic;
+	u16 min_tx, min_rx;
+
+	min_tx = le16_to_cpu(req->min_tx_rings);
+	min_rx = le16_to_cpu(req->min_rx_rings);
+	avail_cp_rings = hw_resc->max_cp_rings - bp->cp_nr_rings;
+	avail_stat_ctx = hw_resc->max_stat_ctxs - bp->num_stat_ctxs;
+	avail_ring_grps = hw_resc->max_hw_ring_grps - bp->rx_nr_rings;
+	avail_vnics = hw_resc->max_vnics - bp->nr_vnics;
+
+	cp = max_t(u16, 2 * min_tx, min_rx);
+	if (cp > vf->min_cp_rings)
+		cp = min_t(u16, cp, avail_cp_rings + vf->min_cp_rings);
+	grp = min_tx;
+	if (grp > vf->min_ring_grps)
+		grp = min_t(u16, grp, avail_ring_grps + vf->min_ring_grps);
+	stat = min_rx;
+	if (stat > vf->min_stat_ctxs)
+		stat = min_t(u16, stat, avail_stat_ctx + vf->min_stat_ctxs);
+	vnic = min_rx;
+	if (vnic > vf->min_vnics)
+		vnic = min_t(u16, vnic, avail_vnics + vf->min_vnics);
+
+	req->min_cmpl_rings = req->max_cmpl_rings = cpu_to_le16(cp);
+	req->min_hw_ring_grps = req->max_hw_ring_grps = cpu_to_le16(grp);
+	req->min_stat_ctx = req->max_stat_ctx = cpu_to_le16(stat);
+	req->min_vnics = req->max_vnics = cpu_to_le16(vnic);
+}
+
+static void bnxt_record_ring_resc(struct bnxt *bp, struct bnxt_vf_info *vf,
+				  struct hwrm_func_vf_resource_cfg_input *req)
+{
+	struct bnxt_hw_resc *hw_resc = &bp->hw_resc;
+
+	hw_resc->max_tx_rings += vf->min_tx_rings;
+	hw_resc->max_rx_rings += vf->min_rx_rings;
+	vf->min_tx_rings = le16_to_cpu(req->min_tx_rings);
+	vf->max_tx_rings = le16_to_cpu(req->max_tx_rings);
+	vf->min_rx_rings = le16_to_cpu(req->min_rx_rings);
+	vf->max_rx_rings = le16_to_cpu(req->max_rx_rings);
+	hw_resc->max_tx_rings -= vf->min_tx_rings;
+	hw_resc->max_rx_rings -= vf->min_rx_rings;
+	if (bp->pf.vf_resv_strategy == BNXT_VF_RESV_STRATEGY_MAXIMAL) {
+		hw_resc->max_cp_rings += vf->min_cp_rings;
+		hw_resc->max_hw_ring_grps += vf->min_ring_grps;
+		hw_resc->max_stat_ctxs += vf->min_stat_ctxs;
+		hw_resc->max_vnics += vf->min_vnics;
+		vf->min_cp_rings = le16_to_cpu(req->min_cmpl_rings);
+		vf->min_ring_grps = le16_to_cpu(req->min_hw_ring_grps);
+		vf->min_stat_ctxs = le16_to_cpu(req->min_stat_ctx);
+		vf->min_vnics = le16_to_cpu(req->min_vnics);
+		hw_resc->max_cp_rings -= vf->min_cp_rings;
+		hw_resc->max_hw_ring_grps -= vf->min_ring_grps;
+		hw_resc->max_stat_ctxs -= vf->min_stat_ctxs;
+		hw_resc->max_vnics -= vf->min_vnics;
+	}
+}
+
+int bnxt_set_vf_queues(struct net_device *dev, int vf_id, int min_txq,
+		       int max_txq, int min_rxq, int max_rxq)
+{
+	struct hwrm_func_vf_resource_cfg_input req = {0};
+	struct bnxt *bp = netdev_priv(dev);
+	u16 avail_tx_rings, avail_rx_rings;
+	struct bnxt_hw_resc *hw_resc;
+	struct bnxt_vf_info *vf;
+	int rc;
+
+	if (bnxt_vf_ndo_prep(bp, vf_id))
+		return -EINVAL;
+
+	if (!(bp->flags & BNXT_FLAG_NEW_RM) || bp->hwrm_spec_code < 0x10902)
+		return -EOPNOTSUPP;
+
+	vf = &bp->pf.vf[vf_id];
+	hw_resc = &bp->hw_resc;
+
+	avail_tx_rings = hw_resc->max_tx_rings - bp->tx_nr_rings;
+	if (bp->flags & BNXT_FLAG_AGG_RINGS)
+		avail_rx_rings = hw_resc->max_rx_rings - bp->rx_nr_rings * 2;
+	else
+		avail_rx_rings = hw_resc->max_rx_rings - bp->rx_nr_rings;
+
+	if (!bnxt_param_ok(min_txq, vf->min_tx_rings, avail_tx_rings))
+		return -ENOBUFS;
+	if (!bnxt_param_ok(min_rxq, vf->min_rx_rings, avail_rx_rings))
+		return -ENOBUFS;
+	if (!bnxt_param_ok(max_txq, vf->max_tx_rings, avail_tx_rings))
+		return -ENOBUFS;
+	if (!bnxt_param_ok(max_rxq, vf->max_rx_rings, avail_rx_rings))
+		return -ENOBUFS;
+
+	bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_FUNC_VF_RESOURCE_CFG, -1, -1);
+	memcpy(&req, &bp->vf_resc_cfg_input, sizeof(req));
+	req.vf_id = cpu_to_le16(vf->fw_fid);
+	req.min_tx_rings = cpu_to_le16(min_txq);
+	req.min_rx_rings = cpu_to_le16(min_rxq);
+	req.max_tx_rings = cpu_to_le16(max_txq);
+	req.max_rx_rings = cpu_to_le16(max_rxq);
+
+	if (bp->pf.vf_resv_strategy == BNXT_VF_RESV_STRATEGY_MAXIMAL)
+		bnxt_adjust_ring_resc(bp, vf, &req);
+
+	rc = hwrm_send_message(bp, &req, sizeof(req), HWRM_CMD_TIMEOUT);
+	if (rc)
+		return -EIO;
+
+	bnxt_record_ring_resc(bp, vf, &req);
+	return 0;
+}
+
 int bnxt_get_vf_config(struct net_device *dev, int vf_id,
 		       struct ifla_vf_info *ivi)
 {
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.h b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.h
index e9b20cd..325b412 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.h
@@ -35,6 +35,8 @@
 int bnxt_set_vf_link_state(struct net_device *, int, int);
 int bnxt_set_vf_spoofchk(struct net_device *, int, bool);
 int bnxt_set_vf_trust(struct net_device *dev, int vf_id, bool trust);
+int bnxt_set_vf_queues(struct net_device *dev, int vf_id, int min_txq,
+		       int max_txq, int min_rxq, int max_rxq);
 int bnxt_sriov_configure(struct pci_dev *pdev, int num_vfs);
 void bnxt_sriov_disable(struct bnxt *);
 void bnxt_hwrm_exec_fwd_req(struct bnxt *);
-- 
1.8.3.1

^ permalink raw reply related

* [PATCH net-next 2/3] bnxt_en: Store min/max tx/rx rings for individual VFs.
From: Michael Chan @ 2018-05-29  8:18 UTC (permalink / raw)
  To: davem; +Cc: netdev
In-Reply-To: <1527581920-3778-1-git-send-email-michael.chan@broadcom.com>

With new infrastructure to configure queues differently for each VF,
we need to store the current min/max rx/tx rings and other resources
for each VF.

Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
 drivers/net/ethernet/broadcom/bnxt/bnxt.h       |  9 +++++++++
 drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 27 +++++++++++++++++++++----
 2 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.h b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
index 9b14eb6..531c77d 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
@@ -837,6 +837,14 @@ struct bnxt_vf_info {
 	u32	func_flags; /* func cfg flags */
 	u32	min_tx_rate;
 	u32	max_tx_rate;
+	u16	min_tx_rings;
+	u16	max_tx_rings;
+	u16	min_rx_rings;
+	u16	max_rx_rings;
+	u16	min_cp_rings;
+	u16	min_stat_ctxs;
+	u16	min_ring_grps;
+	u16	min_vnics;
 	void	*hwrm_cmd_req_addr;
 	dma_addr_t	hwrm_cmd_req_dma_addr;
 };
@@ -1351,6 +1359,7 @@ struct bnxt {
 #ifdef CONFIG_BNXT_SRIOV
 	int			nr_vfs;
 	struct bnxt_vf_info	vf;
+	struct hwrm_func_vf_resource_cfg_input vf_resc_cfg_input;
 	wait_queue_head_t	sriov_cfg_wait;
 	bool			sriov_cfg;
 #define BNXT_SRIOV_CFG_WAIT_TMO	msecs_to_jiffies(10000)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
index a649108..7a92125 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
@@ -171,6 +171,10 @@ int bnxt_get_vf_config(struct net_device *dev, int vf_id,
 		ivi->linkstate = IFLA_VF_LINK_STATE_ENABLE;
 	else
 		ivi->linkstate = IFLA_VF_LINK_STATE_DISABLE;
+	ivi->min_tx_queues = vf->min_tx_rings;
+	ivi->max_tx_queues = vf->max_tx_rings;
+	ivi->min_rx_queues = vf->min_rx_rings;
+	ivi->max_rx_queues = vf->max_rx_rings;
 
 	return 0;
 }
@@ -498,6 +502,8 @@ static int bnxt_hwrm_func_vf_resc_cfg(struct bnxt *bp, int num_vfs)
 
 	mutex_lock(&bp->hwrm_cmd_lock);
 	for (i = 0; i < num_vfs; i++) {
+		struct bnxt_vf_info *vf = &pf->vf[i];
+
 		req.vf_id = cpu_to_le16(pf->first_vf_id + i);
 		rc = _hwrm_send_message(bp, &req, sizeof(req),
 					HWRM_CMD_TIMEOUT);
@@ -506,7 +512,15 @@ static int bnxt_hwrm_func_vf_resc_cfg(struct bnxt *bp, int num_vfs)
 			break;
 		}
 		pf->active_vfs = i + 1;
-		pf->vf[i].fw_fid = pf->first_vf_id + i;
+		vf->fw_fid = pf->first_vf_id + i;
+		vf->min_tx_rings = le16_to_cpu(req.min_tx_rings);
+		vf->max_tx_rings = vf_tx_rings;
+		vf->min_rx_rings = le16_to_cpu(req.min_rx_rings);
+		vf->max_rx_rings = vf_rx_rings;
+		vf->min_cp_rings = le16_to_cpu(req.min_cmpl_rings);
+		vf->min_stat_ctxs = le16_to_cpu(req.min_stat_ctx);
+		vf->min_ring_grps = le16_to_cpu(req.min_hw_ring_grps);
+		vf->min_vnics = le16_to_cpu(req.min_vnics);
 	}
 	mutex_unlock(&bp->hwrm_cmd_lock);
 	if (pf->active_vfs) {
@@ -521,6 +535,7 @@ static int bnxt_hwrm_func_vf_resc_cfg(struct bnxt *bp, int num_vfs)
 		hw_resc->max_stat_ctxs -= le16_to_cpu(req.min_stat_ctx) * n;
 		hw_resc->max_vnics -= le16_to_cpu(req.min_vnics) * n;
 
+		memcpy(&bp->vf_resc_cfg_input, &req, sizeof(req));
 		rc = pf->active_vfs;
 	}
 	return rc;
@@ -585,6 +600,7 @@ static int bnxt_hwrm_func_cfg(struct bnxt *bp, int num_vfs)
 
 	mutex_lock(&bp->hwrm_cmd_lock);
 	for (i = 0; i < num_vfs; i++) {
+		struct bnxt_vf_info *vf = &pf->vf[i];
 		int vf_tx_rsvd = vf_tx_rings;
 
 		req.fid = cpu_to_le16(pf->first_vf_id + i);
@@ -593,12 +609,15 @@ static int bnxt_hwrm_func_cfg(struct bnxt *bp, int num_vfs)
 		if (rc)
 			break;
 		pf->active_vfs = i + 1;
-		pf->vf[i].fw_fid = le16_to_cpu(req.fid);
-		rc = __bnxt_hwrm_get_tx_rings(bp, pf->vf[i].fw_fid,
-					      &vf_tx_rsvd);
+		vf->fw_fid = le16_to_cpu(req.fid);
+		rc = __bnxt_hwrm_get_tx_rings(bp, vf->fw_fid, &vf_tx_rsvd);
 		if (rc)
 			break;
 		total_vf_tx_rings += vf_tx_rsvd;
+		vf->min_tx_rings = vf_tx_rsvd;
+		vf->max_tx_rings = vf_tx_rsvd;
+		vf->min_rx_rings = vf_rx_rings;
+		vf->max_rx_rings = vf_rx_rings;
 	}
 	mutex_unlock(&bp->hwrm_cmd_lock);
 	if (rc)
-- 
1.8.3.1

^ permalink raw reply related

* [PATCH net-next 1/3] net: Add support to configure SR-IOV VF minimum and maximum queues.
From: Michael Chan @ 2018-05-29  8:18 UTC (permalink / raw)
  To: davem; +Cc: netdev
In-Reply-To: <1527581920-3778-1-git-send-email-michael.chan@broadcom.com>

VF Queue resources are always limited and there is currently no
infrastructure to allow the admin. on the host to add or reduce queue
resources for any particular VF.  With ever increasing number of VFs
being supported, it is desirable to allow the admin. to configure queue
resources differently for the VFs.  Some VFs may require more or fewer
queues due to different bandwidth requirements or different number of
vCPUs in the VM.  This patch adds the infrastructure to do that by
adding IFLA_VF_QUEUES netlink attribute and a new .ndo_set_vf_queues()
to the net_device_ops.

Four parameters are exposed for each VF:

o min_tx_queues - Guaranteed tx queues available to the VF.

o max_tx_queues - Maximum but not necessarily guaranteed tx queues
  available to the VF.

o min_rx_queues - Guaranteed rx queues available to the VF.

o max_rx_queues - Maximum but not necessarily guaranteed rx queues
  available to the VF.

The "ip link set" command will subsequently be patched to support the new
operation to set the above parameters.

After the admin. makes a change to the above parameters, the corresponding
VF will have a new range of channels to set using ethtool -L.  The VF may
have to go through IF down/up before the new queues will take effect.  Up
to the min values are guaranteed.  Up to the max values are possible but not
guaranteed.

Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
 include/linux/if_link.h      |  4 ++++
 include/linux/netdevice.h    |  6 ++++++
 include/uapi/linux/if_link.h |  9 +++++++++
 net/core/rtnetlink.c         | 32 +++++++++++++++++++++++++++++---
 4 files changed, 48 insertions(+), 3 deletions(-)

diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index 622658d..8e81121 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -29,5 +29,9 @@ struct ifla_vf_info {
 	__u32 rss_query_en;
 	__u32 trusted;
 	__be16 vlan_proto;
+	__u32 min_tx_queues;
+	__u32 max_tx_queues;
+	__u32 min_rx_queues;
+	__u32 max_rx_queues;
 };
 #endif /* _LINUX_IF_LINK_H */
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 8452f72..17f5892 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1023,6 +1023,8 @@ struct dev_ifalias {
  *      with PF and querying it may introduce a theoretical security risk.
  * int (*ndo_set_vf_rss_query_en)(struct net_device *dev, int vf, bool setting);
  * int (*ndo_get_vf_port)(struct net_device *dev, int vf, struct sk_buff *skb);
+ * int (*ndo_set_vf_queues)(struct net_device *dev, int vf, int min_txq,
+ *			    int max_txq, int min_rxq, int max_rxq);
  * int (*ndo_setup_tc)(struct net_device *dev, enum tc_setup_type type,
  *		       void *type_data);
  *	Called to setup any 'tc' scheduler, classifier or action on @dev.
@@ -1276,6 +1278,10 @@ struct net_device_ops {
 	int			(*ndo_set_vf_rss_query_en)(
 						   struct net_device *dev,
 						   int vf, bool setting);
+	int			(*ndo_set_vf_queues)(struct net_device *dev,
+						     int vf,
+						     int min_txq, int max_txq,
+						     int min_rxq, int max_rxq);
 	int			(*ndo_setup_tc)(struct net_device *dev,
 						enum tc_setup_type type,
 						void *type_data);
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index cf01b68..81bbc4e 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -659,6 +659,7 @@ enum {
 	IFLA_VF_IB_NODE_GUID,	/* VF Infiniband node GUID */
 	IFLA_VF_IB_PORT_GUID,	/* VF Infiniband port GUID */
 	IFLA_VF_VLAN_LIST,	/* nested list of vlans, option for QinQ */
+	IFLA_VF_QUEUES,		/* Min and Max TX/RX queues */
 	__IFLA_VF_MAX,
 };
 
@@ -749,6 +750,14 @@ struct ifla_vf_trust {
 	__u32 setting;
 };
 
+struct ifla_vf_queues {
+	__u32 vf;
+	__u32 min_tx_queues;	/* min guaranteed tx queues */
+	__u32 max_tx_queues;	/* max non guaranteed tx queues */
+	__u32 min_rx_queues;	/* min guaranteed rx queues */
+	__u32 max_rx_queues;	/* max non guaranteed rx queues */
+};
+
 /* VF ports management section
  *
  *	Nested layout of set/get msg is:
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 8080254..e21ab8a 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -921,7 +921,8 @@ static inline int rtnl_vfinfo_size(const struct net_device *dev,
 			 nla_total_size_64bit(sizeof(__u64)) +
 			 /* IFLA_VF_STATS_TX_DROPPED */
 			 nla_total_size_64bit(sizeof(__u64)) +
-			 nla_total_size(sizeof(struct ifla_vf_trust)));
+			 nla_total_size(sizeof(struct ifla_vf_trust)) +
+			 nla_total_size(sizeof(struct ifla_vf_queues)));
 		return size;
 	} else
 		return 0;
@@ -1181,6 +1182,7 @@ static noinline_for_stack int rtnl_fill_vfinfo(struct sk_buff *skb,
 	struct ifla_vf_vlan_info vf_vlan_info;
 	struct ifla_vf_spoofchk vf_spoofchk;
 	struct ifla_vf_tx_rate vf_tx_rate;
+	struct ifla_vf_queues vf_queues;
 	struct ifla_vf_stats vf_stats;
 	struct ifla_vf_trust vf_trust;
 	struct ifla_vf_vlan vf_vlan;
@@ -1198,6 +1200,10 @@ static noinline_for_stack int rtnl_fill_vfinfo(struct sk_buff *skb,
 	ivi.spoofchk = -1;
 	ivi.rss_query_en = -1;
 	ivi.trusted = -1;
+	ivi.min_tx_queues = -1;
+	ivi.max_tx_queues = -1;
+	ivi.min_rx_queues = -1;
+	ivi.max_rx_queues = -1;
 	/* The default value for VF link state is "auto"
 	 * IFLA_VF_LINK_STATE_AUTO which equals zero
 	 */
@@ -1217,7 +1223,8 @@ static noinline_for_stack int rtnl_fill_vfinfo(struct sk_buff *skb,
 		vf_spoofchk.vf =
 		vf_linkstate.vf =
 		vf_rss_query_en.vf =
-		vf_trust.vf = ivi.vf;
+		vf_trust.vf =
+		vf_queues.vf = ivi.vf;
 
 	memcpy(vf_mac.mac, ivi.mac, sizeof(ivi.mac));
 	vf_vlan.vlan = ivi.vlan;
@@ -1232,6 +1239,10 @@ static noinline_for_stack int rtnl_fill_vfinfo(struct sk_buff *skb,
 	vf_linkstate.link_state = ivi.linkstate;
 	vf_rss_query_en.setting = ivi.rss_query_en;
 	vf_trust.setting = ivi.trusted;
+	vf_queues.min_tx_queues = ivi.min_tx_queues;
+	vf_queues.max_tx_queues = ivi.max_tx_queues;
+	vf_queues.min_rx_queues = ivi.min_rx_queues;
+	vf_queues.max_rx_queues = ivi.max_rx_queues;
 	vf = nla_nest_start(skb, IFLA_VF_INFO);
 	if (!vf)
 		goto nla_put_vfinfo_failure;
@@ -1249,7 +1260,9 @@ static noinline_for_stack int rtnl_fill_vfinfo(struct sk_buff *skb,
 		    sizeof(vf_rss_query_en),
 		    &vf_rss_query_en) ||
 	    nla_put(skb, IFLA_VF_TRUST,
-		    sizeof(vf_trust), &vf_trust))
+		    sizeof(vf_trust), &vf_trust) ||
+	    nla_put(skb, IFLA_VF_QUEUES,
+		    sizeof(vf_queues), &vf_queues))
 		goto nla_put_vf_failure;
 	vfvlanlist = nla_nest_start(skb, IFLA_VF_VLAN_LIST);
 	if (!vfvlanlist)
@@ -1706,6 +1719,7 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb,
 	[IFLA_VF_TRUST]		= { .len = sizeof(struct ifla_vf_trust) },
 	[IFLA_VF_IB_NODE_GUID]	= { .len = sizeof(struct ifla_vf_guid) },
 	[IFLA_VF_IB_PORT_GUID]	= { .len = sizeof(struct ifla_vf_guid) },
+	[IFLA_VF_QUEUES]	= { .len = sizeof(struct ifla_vf_queues) },
 };
 
 static const struct nla_policy ifla_port_policy[IFLA_PORT_MAX+1] = {
@@ -2208,6 +2222,18 @@ static int do_setvfinfo(struct net_device *dev, struct nlattr **tb)
 		return handle_vf_guid(dev, ivt, IFLA_VF_IB_PORT_GUID);
 	}
 
+	if (tb[IFLA_VF_QUEUES]) {
+		struct ifla_vf_queues *ivq = nla_data(tb[IFLA_VF_QUEUES]);
+
+		err = -EOPNOTSUPP;
+		if (ops->ndo_set_vf_queues)
+			err = ops->ndo_set_vf_queues(dev, ivq->vf,
+					ivq->min_tx_queues, ivq->max_tx_queues,
+					ivq->min_rx_queues, ivq->max_rx_queues);
+		if (err < 0)
+			return err;
+	}
+
 	return err;
 }
 
-- 
1.8.3.1

^ permalink raw reply related

* [PATCH net-next 0/3] net: Add support to configure SR-IOV VF queues.
From: Michael Chan @ 2018-05-29  8:18 UTC (permalink / raw)
  To: davem; +Cc: netdev

VF Queue resources are always limited and there is currently no
infrastructure to allow the admin. on the host to add or reduce queue
resources for any particular VF.  This series adds the infrastructure
to do that and adds the functionality to the bnxt_en driver.

The "ip link set" command will subsequently be patched to support the new
operation.

v1:
- Changed the meaning of the min parameters to be strictly the minimum
guaranteed value, suggested by Jakub Kicinsky.
- More complete implementation in the bnxt_en driver.

Michael Chan (3):
  net: Add support to configure SR-IOV VF minimum and maximum queues.
  bnxt_en: Store min/max tx/rx rings for individual VFs.
  bnxt_en: Implement .ndo_set_vf_queues().

 drivers/net/ethernet/broadcom/bnxt/bnxt.c       |   1 +
 drivers/net/ethernet/broadcom/bnxt/bnxt.h       |   9 ++
 drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 157 +++++++++++++++++++++++-
 drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.h |   2 +
 include/linux/if_link.h                         |   4 +
 include/linux/netdevice.h                       |   6 +
 include/uapi/linux/if_link.h                    |   9 ++
 net/core/rtnetlink.c                            |  32 ++++-
 8 files changed, 213 insertions(+), 7 deletions(-)

-- 
1.8.3.1

^ permalink raw reply

* Re: [PATCH net-next 05/14] nfp: abm: add simple RED offload
From: Nogah Frankel @ 2018-05-29  7:53 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: davem, jiri, xiyou.wangcong, john.fastabend, netdev, oss-drivers,
	alexei.starovoitov, nogahf, yuvalm, gerlitz.or
In-Reply-To: <20180528160507.4a2ff81a@cakuba>

On 29-May-18 2:05 AM, Jakub Kicinski wrote:

Hi Jakub,

> Hi Nogah!
> 
> On Mon, 28 May 2018 18:49:51 +0300, Nogah Frankel wrote:
>>> +static int
>>> +nfp_abm_red_replace(struct net_device *netdev, struct nfp_abm_link *alink,
>>> +		    struct tc_red_qopt_offload *opt)
>>> +{
>>> +	struct nfp_port *port = nfp_port_from_netdev(netdev);
>>> +	int err;
>>> +
>>> +	if (opt->set.min != opt->set.max || !opt->set.is_ecn) {
>>
>> I am a bit worried about the min == max.
>> sch_red doesn't really support it. It will calculate incorrect delta
>> value. (And that only if tc_red_eval_P in iproute2 won't reject it).
>> You might maybe use max = min+1,  because in real life it will probably
>> act the same but without this problem.
> 
> I remember having a long think about this when I wrote the code.
> My conclusion was that the two would operate almost the same, and
> setting min == max may be most obvious to the user.

I agree.

> 
> If min + 1 == max sch_red would act probabilistically for qavg == min,
> which is not what the card would do.
> 
> Userspace now does this:
> 
> tc_red_eval_P() {
> 	int i = qmax - qmin;
>   
> 	if (!i)
> 		return 0;
> 	if (i < 0)
> 		return -1;
> 	...
> }
> 
> And you've fixed delta to be treated as 1 to avoid division by 0 in
> commit 5c472203421a ("net_sched: red: Avoid devision by zero"):
> 
> red_set_parms() {
> 	int delta = qth_max - qth_min;
> 	u32 max_p_delta;
> 
> 	p->qth_min	= qth_min << Wlog;
> 	p->qth_max	= qth_max << Wlog;
> 	p->Wlog		= Wlog;
> 	p->Plog		= Plog;
> 	if (delta <= 0)
> 		delta = 1;
> 	p->qth_delta	= delta;
> 	...
> }

I changes it to avoid division by 0, but I wasn't sure that the delta 
value of 1 will be good, just that it is better then 0.

> 
> So we should be safe.  Targets will match.  Probability adjustment for
> adaptive should work correctly.  Which doesn't matter anyway, since we
> will never use the probabilistic action...

That makes sense, and it is a better way to set this setup (DCTCP, I 
guess?) than before.

Thanks

Nogah


> 
>> Nogah Frankel
>> (from a new mail address)
> 
> Noted :)
> 

^ permalink raw reply

* (unknown), 
From: администратор @ 2018-05-29  7:26 UTC (permalink / raw)


пользователь веб-почты

Обратите внимание, что 95% ваших писем, полученных после последнего раза, когда вам нужно обновить сервер своей веб-почты в нашей базе данных, были отложены. Регулярно получать и отправлять свои сообщения. Техническая команда нашей электронной почты обновит вашу учетную запись в течение 3 рабочих дней. Если вы этого не сделаете, ваша учетная запись будет временно приостановлена нашими службами. Чтобы снова проверить свой почтовый ящик, пришлите следующую информацию:

обычный:
Имя пользователя:
пароль:
Подтвердите Пароль:

Предупреждение!! Если это откажется обновлять аккаунты в течение двух
дней с момента получения электронной почты, он навсегда потеряет счета
владельцы учетных записей электронной почты.

Спасибо за сотрудничество!

Copyright © 2017-2018 Служба технической поддержки WebMail, Inc.

^ permalink raw reply

* Re: rtlwifi: remove duplicate code
From: Kalle Valo @ 2018-05-29  7:28 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Ping-Ke Shih, David S. Miller,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Gustavo A. R. Silva
In-Reply-To: <20180524185450.GA2875-L1vi/lXTdts+Va1GwOuvDg@public.gmane.org>

"Gustavo A. R. Silva" <gustavo-L1vi/lXTdts+Va1GwOuvDg@public.gmane.org> wrote:

> Remove and refactor some code in order to avoid having identical code
> for different branches.
> 
> Notice that the logic has been there since 2014.
> 
> Addresses-Coverity-ID: 1426199 ("Identical code for different branches")
> Signed-off-by: Gustavo A. R. Silva <gustavo-L1vi/lXTdts+Va1GwOuvDg@public.gmane.org>

Patch applied to wireless-drivers-next.git, thanks.

06895b1627fe rtlwifi: remove duplicate code

-- 
https://patchwork.kernel.org/patch/10425379/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

^ permalink raw reply

* Re: mwifiex: mark expected switch fall-throughs
From: Kalle Valo @ 2018-05-29  7:26 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
	David S. Miller, linux-wireless, netdev, linux-kernel,
	Gustavo A. R. Silva
In-Reply-To: <20180525213854.GA13392@embeddedor.com>

"Gustavo A. R. Silva" <gustavo@embeddedor.com> wrote:

> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
> 
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>

Patch applied to wireless-drivers-next.git, thanks.

666cc438f369 mwifiex: mark expected switch fall-throughs

-- 
https://patchwork.kernel.org/patch/10428577/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox