* [PATCH net-next v2 4/4] cxgb4: fetch stats for offloaded tc flower flows
From: Rahul Lakkireddy @ 2017-09-21 18:11 UTC (permalink / raw)
To: netdev; +Cc: davem, kumaras, ganeshgr, nirranjan, indranil, Rahul Lakkireddy
In-Reply-To: <cover.1506015856.git.rahul.lakkireddy@chelsio.com>
From: Kumar Sanghvi <kumaras@chelsio.com>
Add support to retrieve stats from hardware for offloaded tc flower
flows. Also, poll for the stats of offloaded flows via timer callback.
Signed-off-by: Kumar Sanghvi <kumaras@chelsio.com>
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
v2:
- No changes.
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c | 76 +++++++++++++++++++++
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 1 +
.../net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c | 79 +++++++++++++++++++++-
.../net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.h | 3 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h | 2 +
6 files changed, 161 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 26eac599ab2c..8a94d97df025 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -907,6 +907,7 @@ struct adapter {
/* TC flower offload */
DECLARE_HASHTABLE(flower_anymatch_tbl, 9);
+ struct timer_list flower_stats_timer;
};
/* Support for "sched-class" command to allow a TX Scheduling Class to be
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
index a1f644eb0cec..bdedf3dce51a 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
@@ -148,6 +148,82 @@ static int get_filter_steerq(struct net_device *dev,
return iq;
}
+static int get_filter_count(struct adapter *adapter, unsigned int fidx,
+ u64 *pkts, u64 *bytes)
+{
+ unsigned int tcb_base, tcbaddr;
+ unsigned int word_offset;
+ struct filter_entry *f;
+ __be64 be64_byte_count;
+ int ret;
+
+ tcb_base = t4_read_reg(adapter, TP_CMM_TCB_BASE_A);
+ if ((fidx != (adapter->tids.nftids + adapter->tids.nsftids - 1)) &&
+ fidx >= adapter->tids.nftids)
+ return -E2BIG;
+
+ f = &adapter->tids.ftid_tab[fidx];
+ if (!f->valid)
+ return -EINVAL;
+
+ tcbaddr = tcb_base + f->tid * TCB_SIZE;
+
+ spin_lock(&adapter->win0_lock);
+ if (is_t4(adapter->params.chip)) {
+ __be64 be64_count;
+
+ /* T4 doesn't maintain byte counts in hw */
+ *bytes = 0;
+
+ /* Get pkts */
+ word_offset = 4;
+ ret = t4_memory_rw(adapter, MEMWIN_NIC, MEM_EDC0,
+ tcbaddr + (word_offset * sizeof(__be32)),
+ sizeof(be64_count),
+ (__be32 *)&be64_count,
+ T4_MEMORY_READ);
+ if (ret < 0)
+ goto out;
+ *pkts = be64_to_cpu(be64_count);
+ } else {
+ __be32 be32_count;
+
+ /* Get bytes */
+ word_offset = 4;
+ ret = t4_memory_rw(adapter, MEMWIN_NIC, MEM_EDC0,
+ tcbaddr + (word_offset * sizeof(__be32)),
+ sizeof(be64_byte_count),
+ &be64_byte_count,
+ T4_MEMORY_READ);
+ if (ret < 0)
+ goto out;
+ *bytes = be64_to_cpu(be64_byte_count);
+
+ /* Get pkts */
+ word_offset = 6;
+ ret = t4_memory_rw(adapter, MEMWIN_NIC, MEM_EDC0,
+ tcbaddr + (word_offset * sizeof(__be32)),
+ sizeof(be32_count),
+ &be32_count,
+ T4_MEMORY_READ);
+ if (ret < 0)
+ goto out;
+ *pkts = (u64)be32_to_cpu(be32_count);
+ }
+
+out:
+ spin_unlock(&adapter->win0_lock);
+ return ret;
+}
+
+int cxgb4_get_filter_counters(struct net_device *dev, unsigned int fidx,
+ u64 *hitcnt, u64 *bytecnt)
+{
+ struct adapter *adapter = netdev2adap(dev);
+
+ return get_filter_count(adapter, fidx, hitcnt, bytecnt);
+}
+
int cxgb4_get_free_ftid(struct net_device *dev, int family)
{
struct adapter *adap = netdev2adap(dev);
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 3ba4e1ff8486..d634098d52ab 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -4637,6 +4637,7 @@ static void free_some_resources(struct adapter *adapter)
kvfree(adapter->l2t);
t4_cleanup_sched(adapter);
kvfree(adapter->tids.tid_tab);
+ cxgb4_cleanup_tc_flower(adapter);
cxgb4_cleanup_tc_u32(adapter);
kfree(adapter->sge.egr_map);
kfree(adapter->sge.ingr_map);
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
index e42d2efc9ea2..a36bd66d2834 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
@@ -39,9 +39,12 @@
#include "cxgb4.h"
#include "cxgb4_tc_flower.h"
+#define STATS_CHECK_PERIOD (HZ / 2)
+
static struct ch_tc_flower_entry *allocate_flower_entry(void)
{
struct ch_tc_flower_entry *new = kzalloc(sizeof(*new), GFP_KERNEL);
+ spin_lock_init(&new->lock);
return new;
}
@@ -363,13 +366,87 @@ int cxgb4_tc_flower_destroy(struct net_device *dev,
return ret;
}
+void ch_flower_stats_cb(unsigned long data)
+{
+ struct adapter *adap = (struct adapter *)data;
+ struct ch_tc_flower_entry *flower_entry;
+ struct ch_tc_flower_stats *ofld_stats;
+ unsigned int i;
+ u64 packets;
+ u64 bytes;
+ int ret;
+
+ rcu_read_lock();
+ hash_for_each_rcu(adap->flower_anymatch_tbl, i, flower_entry, link) {
+ ret = cxgb4_get_filter_counters(adap->port[0],
+ flower_entry->filter_id,
+ &packets, &bytes);
+ if (!ret) {
+ spin_lock(&flower_entry->lock);
+ ofld_stats = &flower_entry->stats;
+
+ if (ofld_stats->prev_packet_count != packets) {
+ ofld_stats->prev_packet_count = packets;
+ ofld_stats->last_used = jiffies;
+ }
+ spin_unlock(&flower_entry->lock);
+ }
+ }
+ rcu_read_unlock();
+ mod_timer(&adap->flower_stats_timer, jiffies + STATS_CHECK_PERIOD);
+}
+
int cxgb4_tc_flower_stats(struct net_device *dev,
struct tc_cls_flower_offload *cls)
{
- return -EOPNOTSUPP;
+ struct adapter *adap = netdev2adap(dev);
+ struct ch_tc_flower_stats *ofld_stats;
+ struct ch_tc_flower_entry *ch_flower;
+ u64 packets;
+ u64 bytes;
+ int ret;
+
+ ch_flower = ch_flower_lookup(adap, cls->cookie);
+ if (!ch_flower) {
+ ret = -ENOENT;
+ goto err;
+ }
+
+ ret = cxgb4_get_filter_counters(dev, ch_flower->filter_id,
+ &packets, &bytes);
+ if (ret < 0)
+ goto err;
+
+ spin_lock_bh(&ch_flower->lock);
+ ofld_stats = &ch_flower->stats;
+ if (ofld_stats->packet_count != packets) {
+ if (ofld_stats->prev_packet_count != packets)
+ ofld_stats->last_used = jiffies;
+ tcf_exts_stats_update(cls->exts, bytes - ofld_stats->byte_count,
+ packets - ofld_stats->packet_count,
+ ofld_stats->last_used);
+
+ ofld_stats->packet_count = packets;
+ ofld_stats->byte_count = bytes;
+ ofld_stats->prev_packet_count = packets;
+ }
+ spin_unlock_bh(&ch_flower->lock);
+ return 0;
+
+err:
+ return ret;
}
void cxgb4_init_tc_flower(struct adapter *adap)
{
hash_init(adap->flower_anymatch_tbl);
+ setup_timer(&adap->flower_stats_timer, ch_flower_stats_cb,
+ (unsigned long)adap);
+ mod_timer(&adap->flower_stats_timer, jiffies + STATS_CHECK_PERIOD);
+}
+
+void cxgb4_cleanup_tc_flower(struct adapter *adap)
+{
+ if (adap->flower_stats_timer.function)
+ del_timer_sync(&adap->flower_stats_timer);
}
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.h
index 6145a9e056eb..604feffc752e 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.h
@@ -38,6 +38,7 @@
#include <net/pkt_cls.h>
struct ch_tc_flower_stats {
+ u64 prev_packet_count;
u64 packet_count;
u64 byte_count;
u64 last_used;
@@ -49,6 +50,7 @@ struct ch_tc_flower_entry {
unsigned long tc_flower_cookie;
struct hlist_node link;
struct rcu_head rcu;
+ spinlock_t lock; /* lock for stats */
u32 filter_id;
};
@@ -60,4 +62,5 @@ int cxgb4_tc_flower_stats(struct net_device *dev,
struct tc_cls_flower_offload *cls);
void cxgb4_init_tc_flower(struct adapter *adap);
+void cxgb4_cleanup_tc_flower(struct adapter *adap);
#endif /* __CXGB4_TC_FLOWER_H */
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h
index 88487095d14f..52324c77a4fe 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h
@@ -221,6 +221,8 @@ int __cxgb4_del_filter(struct net_device *dev, int filter_id,
int cxgb4_set_filter(struct net_device *dev, int filter_id,
struct ch_filter_specification *fs);
int cxgb4_del_filter(struct net_device *dev, int filter_id);
+int cxgb4_get_filter_counters(struct net_device *dev, unsigned int fidx,
+ u64 *hitcnt, u64 *bytecnt);
static inline void set_wr_txq(struct sk_buff *skb, int prio, int queue)
{
--
2.14.1
^ permalink raw reply related
* [PATCH iproute2] man: fix documentation for range of route table ID
From: Thomas Haller @ 2017-09-21 18:14 UTC (permalink / raw)
To: Stephen Hemminger, netdev; +Cc: Thomas Haller
Signed-off-by: Thomas Haller <thaller@redhat.com>
---
man/man8/ip-route.8.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/man/man8/ip-route.8.in b/man/man8/ip-route.8.in
index 803de3b9..9717b959 100644
--- a/man/man8/ip-route.8.in
+++ b/man/man8/ip-route.8.in
@@ -322,7 +322,7 @@ normal routing tables.
.P
.B Route tables:
Linux-2.x can pack routes into several routing tables identified
-by a number in the range from 1 to 2^31 or by name from the file
+by a number in the range from 0 to 2^32-1 or by name from the file
.B @SYSCONFDIR@/rt_tables
By default all normal routes are inserted into the
.B main
--
2.13.5
^ permalink raw reply related
* Re: usb/net/p54: trying to register non-static key in p54_unregister_leds
From: Andrey Konovalov @ 2017-09-21 18:22 UTC (permalink / raw)
To: Johannes Berg
Cc: Christian Lamparter, Kalle Valo, linux-wireless, netdev, LKML,
Dmitry Vyukov, Kostya Serebryany, syzkaller, Stephen Boyd,
Tejun Heo, Yong Zhang
In-Reply-To: <1505937307.3026.20.camel@sipsolutions.net>
On Wed, Sep 20, 2017 at 9:55 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2017-09-20 at 21:27 +0200, Christian Lamparter wrote:
>
>> It seems this is caused as a result of:
>> -> lock_map_acquire(&work->lockdep_map);
>> lock_map_release(&work->lockdep_map);
>>
>> in flush_work() [0]
>
> Agree.
>
>> This was added by:
>>
>> commit 0976dfc1d0cd80a4e9dfaf87bd8744612bde475a
>> Author: Stephen Boyd <sboyd@codeaurora.org>
>> Date: Fri Apr 20 17:28:50 2012 -0700
>>
>> workqueue: Catch more locking problems with flush_work()
>
> Yes, but that doesn't matter.
>
>> Looking at the Stephen's patch, it's clear that it was made
>> with "static DECLARE_WORK(work, my_work)" in mind. However
>> p54's led_work is "per-device", hence it is stored in the
>> devices context p54_common, which is dynamically allocated.
>> So, maybe revert Stephen's patch?
>
> I disagree - as the lockdep warning says:
>
>> > INFO: trying to register non-static key.
>> > the code is fine but needs lockdep annotation.
>> > turning off the locking correctness validator.
>
> What it needs is to actually correctly go through initializing the work
> at least once.
>
> Without more information, I can't really say what's going on, but I
> assume that something is failing and p54_unregister_leds() is getting
> invoked without p54_init_leds() having been invoked, so essentially
> it's trying to flush a work that was never initialized?
>
> INIT_DELAYED_WORK() does, after all, initialize the lockdep map
> properly via __INIT_WORK().
Since I'm able to reproduce this, please let me know if you need me to
collect some debug traces to help with the triage.
Thanks!
>
> johannes
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches
From: Kees Cook @ 2017-09-21 18:26 UTC (permalink / raw)
To: Christopher Lameter
Cc: LKML, David Windsor, Pekka Enberg, David Rientjes, Joonsoo Kim,
Andrew Morton, Linux-MM, linux-xfs, linux-fsdevel@vger.kernel.org,
Network Development, kernel-hardening@lists.openwall.com
In-Reply-To: <alpine.DEB.2.20.1709211102320.14742@nuc-kabylake>
On Thu, Sep 21, 2017 at 9:04 AM, Christopher Lameter <cl@linux.com> wrote:
> On Thu, 21 Sep 2017, Kees Cook wrote:
>
>> > So what is the point of this patch?
>>
>> The DMA kmalloc caches are not whitelisted:
>
> The DMA kmalloc caches are pretty obsolete and mostly there for obscure
> drivers.
>
> ??
They may be obsolete, but they're still in the kernel, and they aren't
copied to userspace, so we can mark them.
>> >> kmalloc_dma_caches[i] = create_kmalloc_cache(n,
>> >> - size, SLAB_CACHE_DMA | flags);
>> >> + size, SLAB_CACHE_DMA | flags, 0, 0);
>>
>> So this is creating the distinction between the kmallocs that go to
>> userspace and those that don't. The expectation is that future work
>> can start to distinguish between "for userspace" and "only kernel"
>> kmalloc allocations, as is already done here for DMA.
>
> The creation of the kmalloc caches in earlier patches already setup the
> "whitelisting". Why do it twice?
Patch 1 is to allow for things to mark their whitelists. Patch 30
disables the full whitelisting, since then we've defined them all, so
the kmalloc caches need to mark themselves as whitelisted.
Patch 1 leaves unmarked things whitelisted so we can progressively
tighten the restriction and have a bisectable series. (i.e. if there
is something wrong with one of the whitelists in the series, it will
bisect to that one, not the one that removes the global whitelist from
patch 1.)
-Kees
--
Kees Cook
Pixel Security
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH iproute2] man: fix documentation for range of route table ID
From: Phil Sutter @ 2017-09-21 18:26 UTC (permalink / raw)
To: Thomas Haller; +Cc: Stephen Hemminger, netdev
In-Reply-To: <20170921181411.17720-1-thaller@redhat.com>
On Thu, Sep 21, 2017 at 08:14:11PM +0200, Thomas Haller wrote:
> Signed-off-by: Thomas Haller <thaller@redhat.com>
Fixes: 4ec1933dfddfc ("Update ip.8 man page to describe route table id values")
(So that bug is over 7 years old. :)
Cheers, Phil
^ permalink raw reply
* Re: [PATCH 1/7] net: qrtr: Invoke sk_error_report() after setting sk_err
From: Chris Lew @ 2017-09-21 18:27 UTC (permalink / raw)
To: Bjorn Andersson, David S. Miller; +Cc: netdev, linux-kernel, linux-arm-msm
In-Reply-To: <20170907060329.32402-2-bjorn.andersson@linaro.org>
On 9/6/2017 11:03 PM, Bjorn Andersson wrote:
> Rather than manually waking up any context sleeping on the sock to
> signal an error we should call sk_error_report(). This has the added
> benefit that in-kernel consumers can override this notificatino with
> its own callback.
>
Typo with notification.
Thanks,
Chris
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 00/64] use setup_timer() helper function.
From: David Miller @ 2017-09-21 18:39 UTC (permalink / raw)
To: allen.lkml
Cc: netdev, linux-kernel, m.grzeschik, dmitry.tarnyagin, wg, mkl,
mark.einon, linux, pcnet32, f.fainelli, bcm-kernel-feedback-list,
venza, ajk, jes, romieu, khc, simon, linux-can,
adi-buildroot-devel
In-Reply-To: <1506013525-29291-1-git-send-email-allen.lkml@gmail.com>
From: Allen Pais <allen.lkml@gmail.com>
Date: Thu, 21 Sep 2017 22:34:21 +0530
> This series uses setup_timer() helper function. The series
> addresses the files under drivers/net/*.
I've reviewed this series and will apply it to net-next.
But please send out smaller chunks next time, maybe 10-15
in a bunch? 64 patches at once makes it really hard for
reviewiers.
Thanks.
^ permalink raw reply
* Re: [Patch net] net_sched: remove cls_flower idr on failure
From: Cong Wang @ 2017-09-21 18:47 UTC (permalink / raw)
To: Linux Kernel Network Developers; +Cc: Cong Wang, Chris Mi, Jiri Pirko
In-Reply-To: <20170920161845.28753-1-xiyou.wangcong@gmail.com>
On Wed, Sep 20, 2017 at 9:18 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> +errout_idr:
> + if (fnew->handle)
> + idr_remove_ext(&head->handle_idr, fnew->handle);
Hmm, I should check fold instead of fnew->handle here.
I will update this patch.
^ permalink raw reply
* Re: [Patch net] net_sched: remove cls_flower idr on failure
From: Cong Wang @ 2017-09-21 18:50 UTC (permalink / raw)
To: Linux Kernel Network Developers; +Cc: Cong Wang, Chris Mi, Jiri Pirko
In-Reply-To: <CAM_iQpX2QHqPFJ-vZz+6M4oDW2UgTbYdRuCxtNLm14S4sRVONg@mail.gmail.com>
On Thu, Sep 21, 2017 at 11:47 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Wed, Sep 20, 2017 at 9:18 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> +errout_idr:
>> + if (fnew->handle)
>> + idr_remove_ext(&head->handle_idr, fnew->handle);
>
> Hmm, I should check fold instead of fnew->handle here.
> I will update this patch.
Never mind, it should be the same logic. If fold is non-NULL,
then fnew->handle == 0.
It can be applied as it is.
^ permalink raw reply
* Re: [PATCH net v2] l2tp: fix race condition in l2tp_tunnel_delete
From: David Miller @ 2017-09-21 18:53 UTC (permalink / raw)
To: sd; +Cc: netdev, g.nault, lucien.xin, tparkin
In-Reply-To: <6bfc5aceda47773af4c75fe7e0e3c0d255a2342d.1505828155.git.sd@queasysnail.net>
From: Sabrina Dubroca <sd@queasysnail.net>
Date: Tue, 19 Sep 2017 15:40:40 +0200
> If we try to delete the same tunnel twice, the first delete operation
> does a lookup (l2tp_tunnel_get), finds the tunnel, calls
> l2tp_tunnel_delete, which queues it for deletion by
> l2tp_tunnel_del_work.
>
> The second delete operation also finds the tunnel and calls
> l2tp_tunnel_delete. If the workqueue has already fired and started
> running l2tp_tunnel_del_work, then l2tp_tunnel_delete will queue the
> same tunnel a second time, and try to free the socket again.
>
> Add a dead flag to prevent firing the workqueue twice. Then we can
> remove the check of queue_work's result that was meant to prevent that
> race but doesn't.
>
> Also check the flag in the tunnel lookup functions, to avoid returning a
> tunnel that is already scheduled for destruction.
Sabrina, please respond to Guillaume's feedback.
Thank you.
^ permalink raw reply
* Re: [PATCH] net_sched: always reset qdisc backlog in qdisc_reset()
From: David Miller @ 2017-09-21 18:57 UTC (permalink / raw)
To: khlebnikov; +Cc: netdev, xiyou.wangcong, jiri, jhs
In-Reply-To: <150591153693.113604.8604505743746410801.stgit@buzz>
From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date: Wed, 20 Sep 2017 15:45:36 +0300
> SKB stored in qdisc->gso_skb also counted into backlog.
>
> Some qdiscs don't reset backlog to zero in ->reset(),
> for example sfq just dequeue and free all queued skb.
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> Fixes: 2ccccf5fb43f ("net_sched: update hierarchical backlog too")
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH] net_sched/hfsc: fix curve activation in hfsc_change_class()
From: David Miller @ 2017-09-21 18:57 UTC (permalink / raw)
To: khlebnikov; +Cc: netdev, xiyou.wangcong, jiri, jhs
In-Reply-To: <150591157194.113686.4485981339195559372.stgit@buzz>
From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date: Wed, 20 Sep 2017 15:46:11 +0300
> If real-time or fair-share curves are enabled in hfsc_change_class()
> class isn't inserted into rb-trees yet. Thus init_ed() and init_vf()
> must be called in place of update_ed() and update_vf().
>
> Remove isn't required because for now curves cannot be disabled.
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Applied.
^ permalink raw reply
* Re: [PATCH v4 0/4] Add cross-compilation support to eBPF samples
From: David Miller @ 2017-09-21 18:59 UTC (permalink / raw)
To: joelaf
Cc: linux-kernel, netdev, alison, juri.lelli, fengc, daniel, ast,
kernel-team
In-Reply-To: <20170920160436.24689-1-joelaf@google.com>
From: Joel Fernandes <joelaf@google.com>
Date: Wed, 20 Sep 2017 09:04:32 -0700
> These patches fix issues seen when cross-compiling eBPF samples on arm64.
> Compared to [1], I dropped the controversial inline-asm patch and exploring
> other options to fix it. However these patches are a step in the right
> direction and I look forward to getting them into -next and the merge window.
>
> Changes since v3:
> - just a repost with acks
>
> [1] https://lkml.org/lkml/2017/8/7/417
Series applied with typo in patch #4 corrected.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] bpf/verifier: improve disassembly of BPF_END instructions
From: Daniel Borkmann @ 2017-09-21 19:29 UTC (permalink / raw)
To: Edward Cree, Y Song; +Cc: Alexei Starovoitov, David Miller, netdev
In-Reply-To: <207ecd4c-b1b4-3dcd-62a6-30824c19dbf7@solarflare.com>
On 09/21/2017 06:58 PM, Edward Cree wrote:
> On 21/09/17 17:40, Y Song wrote:
>> On Thu, Sep 21, 2017 at 9:24 AM, Edward Cree <ecree@solarflare.com> wrote:
>>> On 21/09/17 16:52, Alexei Starovoitov wrote:
>>>> imo
>>>> (u16) r4 endian be
>>>> isn't intuitive.
>>>> Can we come up with some better syntax?
>>>> Like
>>>> bswap16be r4
>>>> bswap32le r4
>>> Hmm, I don't like these, since bswapbe is a swap on *le* and a nop on be.
Agree, a bit too much 'swap' semantics in the name that could be
confusing perhaps, at least the be/le could be missed easily.
>>>> or
>>>>
>>>> to_be16 r4
>>>> to_le32 r4
>>> And the problem here is that it's not just to_be, it's also from_be.
More intuitive, but agree on the from_be/le. Maybe we should
just drop the "to_" prefix altogether, and leave the rest as is since
it's not surrounded by braces, it's also not a cast but rather an op.
>> Could you explain what is "from_be" here? Do not quite understand.
> Taking the example of a little-endian processor:
> cpu_to_be16() is a byte-swap, converting a u16 (cpu-endian) to a __be16.
> be16_to_cpu(), to convert a __be16 to a u16, is *also* a byte-swap.
> Meanwhile, cpu_to_le16() and le16_to_cpu() are both no-ops.
>
> More generally, the conversions between cpu-endian and fixed-endian for
> any given size are self-inverses. eBPF takes advantage of this by only
> having a single opcode for both the "to" and "from" direction. So to
> specify an endianness conversion, you need only the size and the fixed
> endianness (le or be), not the to/from direction. Conversely, when
> disassembling one of these instructions, you don't know whether it's a
> cpu_to_be16() or a be16_to_cpu(), because they both look the same at an
> instruction level (they only differ in what types the programmer thought
> of the register as holding before and after).
Yeah, exactly to the point. :)
^ permalink raw reply
* Re: [v2,1/3] can: m_can: Make hclk optional
From: Franklin S Cooper Jr @ 2017-09-21 19:35 UTC (permalink / raw)
To: Sekhar Nori, linux-kernel, devicetree, netdev, linux-can, wg, mkl,
robh+dt, quentin.schulz
Cc: Kristo, Tero, Tony Lindgren, Linux OMAP List
In-Reply-To: <895ab55a-fede-3a67-27aa-1ac1af9843d7@ti.com>
On 09/21/2017 09:08 AM, Sekhar Nori wrote:
> On Thursday 21 September 2017 06:01 AM, Franklin S Cooper Jr wrote:
>>
>>
>> On 08/24/2017 03:00 AM, Sekhar Nori wrote:
>>> + some OMAP folks and Linux OMAP list
>>>
>>> On Tuesday 25 July 2017 04:21 AM, Franklin Cooper wrote:
>>>> Hclk is the MCAN's interface clock. However, for OMAP based devices such as
>>>> DRA7 SoC family the interface clock is handled by hwmod. Therefore, this
>>>> interface clock is managed by hwmod driver via pm_runtime_get and
>>>> pm_runtime_put calls. Therefore, this interface clock isn't defined in DT
>>>> and thus the driver shouldn't fail if this clock isn't found.
>>>
>>> I agree that hclk is defined as interface clock for M_CAN IP on DRA76x.
>>>
>>> However, there may be a need for the driver to know the value of hclk to
>>> properly configure the RAM watchdog register which has a counter
>>> counting down using hclk. Looks like the driver does not use the RAM
>>> watchdog today. But if there is a need to configure it in future, it
>>> might be a problem.
>>
>> Honestly the RAM watchdog seems like a fundamental design problem.
>> This RAM watchdog seems to be used in case a request to access the
>> message ram is made but it hangs for what ever reason. Its even more
>> complicated since the Message RAM is external to the MCAN IP so its
>> implementation or how its handled probably differs from device to
>> device. From example say you do have this error it isn't clear how you
>> would recover from it. A logically answer would be to reset the entire
>> IP but that also assumes that Message RAM will be reset along with the
>> ip which likely depends on each SoC.
>>
>> But if a readl/writel command hangs will the kernel eventually throw an
>> error on its on or will the driver just hang? If it does hang can a
>> driver in the ISR do something to properly terminate the driver or even
>> recover from it?
>>>
>>> Is there a restriction in OMAP architecture against passing the
>>> interface clock also in the 'clocks' property in DT. I have not tried it
>>> myself, but wonder if you hit an issue that led to this patch.
>>
>> No but not passing the interface clock is typical.
>
> Okay, then it sounds like it will just be easier to pass the hclk too?
>
> So it can be used if needed in future and also so that the driver can
> stay the same as today.
That is fine. For now I can just drop this patch unless I discover when
enabling it on DRA76x I am unable to add the interface clock to dt.
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* Re: [PATCH net-next] bpf/verifier: improve disassembly of BPF_END instructions
From: Alexei Starovoitov @ 2017-09-21 19:44 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Edward Cree, Y Song, David Miller, netdev
In-Reply-To: <59C4131D.8050003@iogearbox.net>
On Thu, Sep 21, 2017 at 09:29:33PM +0200, Daniel Borkmann wrote:
> On 09/21/2017 06:58 PM, Edward Cree wrote:
> > On 21/09/17 17:40, Y Song wrote:
> > > On Thu, Sep 21, 2017 at 9:24 AM, Edward Cree <ecree@solarflare.com> wrote:
> > > > On 21/09/17 16:52, Alexei Starovoitov wrote:
> > > > > imo
> > > > > (u16) r4 endian be
> > > > > isn't intuitive.
> > > > > Can we come up with some better syntax?
> > > > > Like
> > > > > bswap16be r4
> > > > > bswap32le r4
> > > > Hmm, I don't like these, since bswapbe is a swap on *le* and a nop on be.
>
> Agree, a bit too much 'swap' semantics in the name that could be
> confusing perhaps, at least the be/le could be missed easily.
>
> > > > > or
> > > > >
> > > > > to_be16 r4
> > > > > to_le32 r4
> > > > And the problem here is that it's not just to_be, it's also from_be.
>
> More intuitive, but agree on the from_be/le. Maybe we should
> just drop the "to_" prefix altogether, and leave the rest as is since
> it's not surrounded by braces, it's also not a cast but rather an op.
'be16 r4' is ambiguous regarding upper bits.
what about my earlier suggestion:
r4 = (be16) (u16) r4
r4 = (le64) (u64) r4
It will be pretty clear what instruction is doing (that upper bits become zero).
^ permalink raw reply
* Re: [PATCH net-next] bpf/verifier: improve disassembly of BPF_END instructions
From: Edward Cree @ 2017-09-21 19:58 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann; +Cc: Y Song, David Miller, netdev
In-Reply-To: <20170921194426.tnd5xos5irm3gred@ast-mbp>
On 21/09/17 20:44, Alexei Starovoitov wrote:
> On Thu, Sep 21, 2017 at 09:29:33PM +0200, Daniel Borkmann wrote:
>> More intuitive, but agree on the from_be/le. Maybe we should
>> just drop the "to_" prefix altogether, and leave the rest as is since
>> it's not surrounded by braces, it's also not a cast but rather an op.
That works for me.
> 'be16 r4' is ambiguous regarding upper bits.
>
> what about my earlier suggestion:
> r4 = (be16) (u16) r4
> r4 = (le64) (u64) r4
>
> It will be pretty clear what instruction is doing (that upper bits become zero).
Trouble with that is that's very *not* what C will do with those casts
and it doesn't really capture the bidirectional/symmetry thing. The
closest I could see with that is something like `r4 = (be16/u16) r4`,
but that's quite an ugly mongrel.
I think Daniel's idea of `be16`, `le32` etc one-arg opcodes is the
cleanest and clearest. Should it be
r4 = be16 r4
or just
be16 r4
? Personally I incline towards the latter, but admit it doesn't really
match the syntax of other opcodes.
To shed a few more bikes, I did also wonder about the BPF_NEG opcode,
which (if I'm reading the code correctly) currently renders as
r4 = neg r4 0
(u32) r4 = neg (u32) r4 0
That printing of the insn->imm, while harmless, is needless and
potentially confusing. Should we get rid of it?
^ permalink raw reply
* net: macb: fail when there's no PHY
From: Grant Edwards @ 2017-09-21 19:59 UTC (permalink / raw)
To: netdev
Several years back (circa 2.6.33) I had to hack up macb.c to work on
an at91 board that didn't have a PHY connected to the macb controller.
Now I might need to get a recent kernel version running on that board.
It looks like the macb driver still can't handle boards that don't
have a PHY. Is that correct?
What's the right way to deal with this?
With the older macb driver, I ended up adding code to macb.c that
presented a "fake" PHY that discarded MDIO writes and returned some
hard-wired values for MDIO reads. That seemed like a pretty ugly way
to deal with the situation, so I never bothered to submit a patch.
--
Grant Edwards
grant.b.edwards@gmail.com
^ permalink raw reply
* Re: net: macb: fail when there's no PHY
From: Florian Fainelli @ 2017-09-21 20:05 UTC (permalink / raw)
To: Grant Edwards, netdev
In-Reply-To: <20170921195905.GA29873@grante>
On 09/21/2017 12:59 PM, Grant Edwards wrote:
> Several years back (circa 2.6.33) I had to hack up macb.c to work on
> an at91 board that didn't have a PHY connected to the macb controller.
> Now I might need to get a recent kernel version running on that board.
>
> It looks like the macb driver still can't handle boards that don't
> have a PHY. Is that correct?
Not since:
dacdbb4dfc1a1a1378df8ebc914d4fe82259ed46 ("net: macb: add fixed-link
node support")
>
> What's the right way to deal with this?
Declaring a fixed PHY that will present an emulated link UP, with a
fixed speed/duplex etc. is the way to go.
>
> With the older macb driver, I ended up adding code to macb.c that
> presented a "fake" PHY that discarded MDIO writes and returned some
> hard-wired values for MDIO reads. That seemed like a pretty ugly way
> to deal with the situation, so I never bothered to submit a patch.
>
Yeah, no :)
--
Florian
^ permalink raw reply
* Re: net: macb: fail when there's no PHY
From: Grant Edwards @ 2017-09-21 20:36 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev
In-Reply-To: <66c0a032-4d20-69f1-deb4-6c65af6ec740@gmail.com>
On Thu, Sep 21, 2017 at 01:05:57PM -0700, Florian Fainelli wrote:
>> It looks like the macb driver still can't handle boards that don't
>> have a PHY. Is that correct?
>
> Not since:
>
> dacdbb4dfc1a1a1378df8ebc914d4fe82259ed46 ("net: macb: add fixed-link
> node support")
Yep, it's obvious now that I've got the diff in front of me.
Thanks!
[I just started working with device tree for the first time yesterday,
and I must say it's way better than the "old days" which required all
sorts of ugly to produce a kernel that could work on two slightly
different boards.]
--
Grant
^ permalink raw reply
* [PATCH] net: use 32-bit arithmetic while allocating net device
From: Alexey Dobriyan @ 2017-09-21 20:33 UTC (permalink / raw)
To: davem; +Cc: netdev
Private part of allocation is never big enough to warrant size_t.
Space savings:
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-10 (-10)
function old new delta
alloc_netdev_mqs 1120 1110 -10
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -7989,7 +7989,7 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
unsigned int txqs, unsigned int rxqs)
{
struct net_device *dev;
- size_t alloc_size;
+ unsigned int alloc_size;
struct net_device *p;
BUG_ON(strlen(name) >= sizeof(dev->name));
^ permalink raw reply
* [PATCH 1/5] xfrm: make aead_len() return unsigned int
From: Alexey Dobriyan @ 2017-09-21 20:45 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, davem, netdev
Key lengths can't be negative.
Comparison with nla_len() is left signed just in case negative value
can sneak in there.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
include/net/xfrm.h | 2 +-
net/xfrm/xfrm_user.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1764,7 +1764,7 @@ static inline int xfrm_acquire_is_on(struct net *net)
}
#endif
-static inline int aead_len(struct xfrm_algo_aead *alg)
+static inline unsigned int aead_len(struct xfrm_algo_aead *alg)
{
return sizeof(*alg) + ((alg->alg_key_len + 7) / 8);
}
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -84,7 +84,7 @@ static int verify_aead(struct nlattr **attrs)
return 0;
algp = nla_data(rt);
- if (nla_len(rt) < aead_len(algp))
+ if (nla_len(rt) < (int)aead_len(algp))
return -EINVAL;
algp->alg_name[sizeof(algp->alg_name) - 1] = '\0';
^ permalink raw reply
* [PATCH 2/5] xfrm: make xfrm_alg_len() return unsigned int
From: Alexey Dobriyan @ 2017-09-21 20:46 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, davem, netdev
In-Reply-To: <20170921204543.GB13550@avx2>
Key lengths can't be negative.
Comparison with nla_len() is left signed just in case negative value
can sneak in there.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
include/net/xfrm.h | 2 +-
net/xfrm/xfrm_user.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1769,7 +1769,7 @@ static inline unsigned int aead_len(struct xfrm_algo_aead *alg)
return sizeof(*alg) + ((alg->alg_key_len + 7) / 8);
}
-static inline int xfrm_alg_len(const struct xfrm_algo *alg)
+static inline unsigned int xfrm_alg_len(const struct xfrm_algo *alg)
{
return sizeof(*alg) + ((alg->alg_key_len + 7) / 8);
}
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -42,7 +42,7 @@ static int verify_one_alg(struct nlattr **attrs, enum xfrm_attr_type_t type)
return 0;
algp = nla_data(rt);
- if (nla_len(rt) < xfrm_alg_len(algp))
+ if (nla_len(rt) < (int)xfrm_alg_len(algp))
return -EINVAL;
switch (type) {
^ permalink raw reply
* [PATCH 3/5] xfrm: make xfrm_alg_auth_len() return unsigned int
From: Alexey Dobriyan @ 2017-09-21 20:47 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, davem, netdev
In-Reply-To: <20170921204543.GB13550@avx2>
Key lengths can't be negative.
Comparison with nla_len() is left signed just in case negative value
can sneak in there.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
include/net/xfrm.h | 2 +-
net/xfrm/xfrm_user.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1774,7 +1774,7 @@ static inline unsigned int xfrm_alg_len(const struct xfrm_algo *alg)
return sizeof(*alg) + ((alg->alg_key_len + 7) / 8);
}
-static inline int xfrm_alg_auth_len(const struct xfrm_algo_auth *alg)
+static inline unsigned int xfrm_alg_auth_len(const struct xfrm_algo_auth *alg)
{
return sizeof(*alg) + ((alg->alg_key_len + 7) / 8);
}
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -68,7 +68,7 @@ static int verify_auth_trunc(struct nlattr **attrs)
return 0;
algp = nla_data(rt);
- if (nla_len(rt) < xfrm_alg_auth_len(algp))
+ if (nla_len(rt) < (int)xfrm_alg_auth_len(algp))
return -EINVAL;
algp->alg_name[sizeof(algp->alg_name) - 1] = '\0';
^ permalink raw reply
* [PATCH 4/5] xfrm: make xfrm_replay_state_esn_len() return unsigned int
From: Alexey Dobriyan @ 2017-09-21 20:47 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, davem, netdev
In-Reply-To: <20170921204543.GB13550@avx2>
Replay detection bitmaps can't have negative length.
Comparisons with nla_len() are left signed just in case negative value
can sneak in there.
Propagate unsignedness for code size savings:
add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-38 (-38)
function old new delta
xfrm_state_construct 1802 1800 -2
xfrm_update_ae_params 295 289 -6
xfrm_state_migrate 1345 1339 -6
xfrm_replay_notify_esn 349 337 -12
xfrm_replay_notify_bmp 345 333 -12
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
include/net/xfrm.h | 2 +-
net/xfrm/xfrm_user.c | 10 +++++-----
2 files changed, 6 insertions(+), 6 deletions(-)
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1779,7 +1779,7 @@ static inline unsigned int xfrm_alg_auth_len(const struct xfrm_algo_auth *alg)
return sizeof(*alg) + ((alg->alg_key_len + 7) / 8);
}
-static inline int xfrm_replay_state_esn_len(struct xfrm_replay_state_esn *replay_esn)
+static inline unsigned int xfrm_replay_state_esn_len(struct xfrm_replay_state_esn *replay_esn)
{
return sizeof(*replay_esn) + replay_esn->bmp_len * sizeof(__u32);
}
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -130,7 +130,7 @@ static inline int verify_replay(struct xfrm_usersa_info *p,
if (rs->bmp_len > XFRMA_REPLAY_ESN_MAX / sizeof(rs->bmp[0]) / 8)
return -EINVAL;
- if (nla_len(rt) < xfrm_replay_state_esn_len(rs) &&
+ if (nla_len(rt) < (int)xfrm_replay_state_esn_len(rs) &&
nla_len(rt) != sizeof(*rs))
return -EINVAL;
}
@@ -404,7 +404,7 @@ static inline int xfrm_replay_verify_len(struct xfrm_replay_state_esn *replay_es
struct nlattr *rp)
{
struct xfrm_replay_state_esn *up;
- int ulen;
+ unsigned int ulen;
if (!replay_esn || !rp)
return 0;
@@ -414,7 +414,7 @@ static inline int xfrm_replay_verify_len(struct xfrm_replay_state_esn *replay_es
/* Check the overall length and the internal bitmap length to avoid
* potential overflow. */
- if (nla_len(rp) < ulen ||
+ if (nla_len(rp) < (int)ulen ||
xfrm_replay_state_esn_len(replay_esn) != ulen ||
replay_esn->bmp_len != up->bmp_len)
return -EINVAL;
@@ -430,14 +430,14 @@ static int xfrm_alloc_replay_state_esn(struct xfrm_replay_state_esn **replay_esn
struct nlattr *rta)
{
struct xfrm_replay_state_esn *p, *pp, *up;
- int klen, ulen;
+ unsigned int klen, ulen;
if (!rta)
return 0;
up = nla_data(rta);
klen = xfrm_replay_state_esn_len(up);
- ulen = nla_len(rta) >= klen ? klen : sizeof(*up);
+ ulen = nla_len(rta) >= (int)klen ? klen : sizeof(*up);
p = kzalloc(klen, GFP_KERNEL);
if (!p)
^ 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