* [linux-next:master 13028/13492] drivers/net/ethernet/ti/davinci_cpdma.c:725:5: sparse: sparse: symbol 'cpdma_chan_split_pool' was not declared. Should it be static?
From: kbuild test robot @ 2019-07-09 19:32 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: kbuild-all, Grygorii Strashko, Andrew Lunn, Ilias Apalodimas,
linux-omap, netdev, linux-kernel
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next.git master
head: 4608a726c66807c27bc7d91bdf8a288254e29985
commit: 962fb618909ef64e0c89af5b79ba0fed910b78e3 [13028/13492] net: ethernet: ti: davinci_cpdma: allow desc split while down
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-rc1-7-g2b96cd8-dirty
git checkout 962fb618909ef64e0c89af5b79ba0fed910b78e3
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
sparse warnings: (new ones prefixed by >>)
>> drivers/net/ethernet/ti/davinci_cpdma.c:725:5: sparse: sparse: symbol 'cpdma_chan_split_pool' was not declared. Should it be static?
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [RFC PATCH linux-next] net: ethernet: ti: davinci_cpdma: cpdma_chan_split_pool() can be static
From: kbuild test robot @ 2019-07-09 19:32 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: kbuild-all, Grygorii Strashko, Andrew Lunn, Ilias Apalodimas,
linux-omap, netdev, linux-kernel
In-Reply-To: <201907100329.bQl3UgMB%lkp@intel.com>
Fixes: 962fb618909e ("net: ethernet: ti: davinci_cpdma: allow desc split while down")
Signed-off-by: kbuild test robot <lkp@intel.com>
---
davinci_cpdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c
index 0ca2a1a..1f6065b 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -722,7 +722,7 @@ static void cpdma_chan_set_descs(struct cpdma_ctlr *ctlr,
* cpdma_chan_split_pool - Splits ctrl pool between all channels.
* Has to be called under ctlr lock
*/
-int cpdma_chan_split_pool(struct cpdma_ctlr *ctlr)
+static int cpdma_chan_split_pool(struct cpdma_ctlr *ctlr)
{
int tx_per_ch_desc = 0, rx_per_ch_desc = 0;
int free_rx_num = 0, free_tx_num = 0;
^ permalink raw reply related
* [RFC PATCH net-next 3/3] net: use listified RX for handling GRO_NORMAL skbs
From: Edward Cree @ 2019-07-09 19:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eric Dumazet
In-Reply-To: <7920e85c-439e-0622-46f8-0602cf37e306@solarflare.com>
When GRO decides not to coalesce a packet, in napi_frags_finish(), instead
of passing it to the stack immediately, place it on a list in the napi
struct. Then, at flush time (napi_complete_done() or napi_poll()), call
netif_receive_skb_list_internal() on the list. We'd like to do that in
napi_gro_flush(), but it's not called if !napi->gro_bitmask, so we have to
do it in the callers instead. (There are a handful of drivers that call
napi_gro_flush() themselves, but it's not clear why, or whether this will
affect them.)
Because a full 64 packets is an inefficiently large batch, also consume the
list whenever it exceeds gro_normal_batch, a new net/core sysctl that
defaults to 8.
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
include/linux/netdevice.h | 3 +++
net/core/dev.c | 32 ++++++++++++++++++++++++++++++--
net/core/sysctl_net_core.c | 8 ++++++++
3 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 88292953aa6f..55ac223553f8 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -332,6 +332,8 @@ struct napi_struct {
struct net_device *dev;
struct gro_list gro_hash[GRO_HASH_BUCKETS];
struct sk_buff *skb;
+ struct list_head rx_list; /* Pending GRO_NORMAL skbs */
+ int rx_count; /* length of rx_list */
struct hrtimer timer;
struct list_head dev_list;
struct hlist_node napi_hash_node;
@@ -4239,6 +4241,7 @@ extern int dev_weight_rx_bias;
extern int dev_weight_tx_bias;
extern int dev_rx_weight;
extern int dev_tx_weight;
+extern int gro_normal_batch;
bool netdev_has_upper_dev(struct net_device *dev, struct net_device *upper_dev);
struct net_device *netdev_upper_get_next_dev_rcu(struct net_device *dev,
diff --git a/net/core/dev.c b/net/core/dev.c
index fc676b2610e3..4b6f2ec67fbc 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3963,6 +3963,8 @@ int dev_weight_rx_bias __read_mostly = 1; /* bias for backlog weight */
int dev_weight_tx_bias __read_mostly = 1; /* bias for output_queue quota */
int dev_rx_weight __read_mostly = 64;
int dev_tx_weight __read_mostly = 64;
+/* Maximum number of GRO_NORMAL skbs to batch up for list-RX */
+int gro_normal_batch __read_mostly = 8;
/* Called with irq disabled */
static inline void ____napi_schedule(struct softnet_data *sd,
@@ -5742,6 +5744,26 @@ struct sk_buff *napi_get_frags(struct napi_struct *napi)
}
EXPORT_SYMBOL(napi_get_frags);
+/* Pass the currently batched GRO_NORMAL SKBs up to the stack. */
+static void gro_normal_list(struct napi_struct *napi)
+{
+ if (!napi->rx_count)
+ return;
+ netif_receive_skb_list_internal(&napi->rx_list);
+ INIT_LIST_HEAD(&napi->rx_list);
+ napi->rx_count = 0;
+}
+
+/* Queue one GRO_NORMAL SKB up for list processing. If batch size exceeded,
+ * pass the whole batch up to the stack.
+ */
+static void gro_normal_one(struct napi_struct *napi, struct sk_buff *skb)
+{
+ list_add_tail(&skb->list, &napi->rx_list);
+ if (++napi->rx_count >= gro_normal_batch)
+ gro_normal_list(napi);
+}
+
static gro_result_t napi_frags_finish(struct napi_struct *napi,
struct sk_buff *skb,
gro_result_t ret)
@@ -5751,8 +5773,8 @@ static gro_result_t napi_frags_finish(struct napi_struct *napi,
case GRO_HELD:
__skb_push(skb, ETH_HLEN);
skb->protocol = eth_type_trans(skb, skb->dev);
- if (ret == GRO_NORMAL && netif_receive_skb_internal(skb))
- ret = GRO_DROP;
+ if (ret == GRO_NORMAL)
+ gro_normal_one(napi, skb);
break;
case GRO_DROP:
@@ -6029,6 +6051,8 @@ bool napi_complete_done(struct napi_struct *n, int work_done)
NAPIF_STATE_IN_BUSY_POLL)))
return false;
+ gro_normal_list(n);
+
if (n->gro_bitmask) {
unsigned long timeout = 0;
@@ -6267,6 +6291,8 @@ void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
napi->timer.function = napi_watchdog;
init_gro_hash(napi);
napi->skb = NULL;
+ INIT_LIST_HEAD(&napi->rx_list);
+ napi->rx_count = 0;
napi->poll = poll;
if (weight > NAPI_POLL_WEIGHT)
netdev_err_once(dev, "%s() called with weight %d\n", __func__,
@@ -6363,6 +6389,8 @@ static int napi_poll(struct napi_struct *n, struct list_head *repoll)
goto out_unlock;
}
+ gro_normal_list(n);
+
if (n->gro_bitmask) {
/* flush too old packets
* If HZ < 1000, flush all packets.
diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index f9204719aeee..dba52f53eace 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -569,6 +569,14 @@ static struct ctl_table net_core_table[] = {
.mode = 0644,
.proc_handler = proc_do_static_key,
},
+ {
+ .procname = "gro_normal_batch",
+ .data = &gro_normal_batch,
+ .maxlen = sizeof(unsigned int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &one,
+ },
{ }
};
^ permalink raw reply related
* [RFC PATCH net-next 2/3] sfc: falcon: don't score irq moderation points for GRO
From: Edward Cree @ 2019-07-09 19:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eric Dumazet
In-Reply-To: <7920e85c-439e-0622-46f8-0602cf37e306@solarflare.com>
Same rationale as for sfc, except that this wasn't performance-tested.
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
drivers/net/ethernet/sfc/falcon/rx.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/sfc/falcon/rx.c b/drivers/net/ethernet/sfc/falcon/rx.c
index fd850d3d8ec0..05ea3523890a 100644
--- a/drivers/net/ethernet/sfc/falcon/rx.c
+++ b/drivers/net/ethernet/sfc/falcon/rx.c
@@ -424,7 +424,6 @@ ef4_rx_packet_gro(struct ef4_channel *channel, struct ef4_rx_buffer *rx_buf,
unsigned int n_frags, u8 *eh)
{
struct napi_struct *napi = &channel->napi_str;
- gro_result_t gro_result;
struct ef4_nic *efx = channel->efx;
struct sk_buff *skb;
@@ -460,9 +459,7 @@ ef4_rx_packet_gro(struct ef4_channel *channel, struct ef4_rx_buffer *rx_buf,
skb_record_rx_queue(skb, channel->rx_queue.core_index);
- gro_result = napi_gro_frags(napi);
- if (gro_result != GRO_DROP)
- channel->irq_mod_score += 2;
+ napi_gro_frags(napi);
}
/* Allocate and construct an SKB around page fragments */
^ permalink raw reply related
* [RFC PATCH net-next 1/3] sfc: don't score irq moderation points for GRO
From: Edward Cree @ 2019-07-09 19:28 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eric Dumazet
In-Reply-To: <7920e85c-439e-0622-46f8-0602cf37e306@solarflare.com>
We already scored points when handling the RX event, no-one else does this,
and looking at the history it appears this was originally meant to only
score on merges, not on GRO_NORMAL. Moreover, it gets in the way of
changing GRO to not immediately pass GRO_NORMAL skbs to the stack.
Performance testing with four TCP streams received on a single CPU (where
throughput was line rate of 9.4Gbps in all tests) showed a 13.7% reduction
in RX CPU usage (n=6, p=0.03).
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
drivers/net/ethernet/sfc/rx.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/sfc/rx.c b/drivers/net/ethernet/sfc/rx.c
index d5db045535d3..85ec07f5a674 100644
--- a/drivers/net/ethernet/sfc/rx.c
+++ b/drivers/net/ethernet/sfc/rx.c
@@ -412,7 +412,6 @@ efx_rx_packet_gro(struct efx_channel *channel, struct efx_rx_buffer *rx_buf,
unsigned int n_frags, u8 *eh)
{
struct napi_struct *napi = &channel->napi_str;
- gro_result_t gro_result;
struct efx_nic *efx = channel->efx;
struct sk_buff *skb;
@@ -449,9 +448,7 @@ efx_rx_packet_gro(struct efx_channel *channel, struct efx_rx_buffer *rx_buf,
skb_record_rx_queue(skb, channel->rx_queue.core_index);
- gro_result = napi_gro_frags(napi);
- if (gro_result != GRO_DROP)
- channel->irq_mod_score += 2;
+ napi_gro_frags(napi);
}
/* Allocate and construct an SKB around page fragments */
^ permalink raw reply related
* [RFC PATCH net-next 0/3] net: batched receive in GRO path
From: Edward Cree @ 2019-07-09 19:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eric Dumazet
This series listifies part of GRO processing, in a manner which allows those
packets which are not GROed (i.e. for which dev_gro_receive returns
GRO_NORMAL) to be passed on to the listified regular receive path.
dev_gro_receive() itself is not listified, nor the per-protocol GRO
callback, since GRO's need to hold packets on lists under napi->gro_hash
makes keeping the packets on other lists awkward, and since the GRO control
block state of held skbs can refer only to one 'new' skb at a time.
Instead, when napi_frags_finish() handles a GRO_NORMAL result, stash the skb
onto a list in the napi struct, which is received at the end of the napi
poll or when its length exceeds the (new) sysctl net.core.gro_normal_batch.
Unlike my previous design ([1]), this does not require changes in drivers,
and also does not prevent the re-use of napi->skb after GRO_MERGED_FREE or
GRO_DROP.
Performance figures with this series, collected on a back-to-back pair of
Solarflare sfn8522-r2 NICs with 120-second NetPerf tests. In the stats,
sample size n for old and new code is 6 runs each; p is from a Welch t-test.
Tests were run both with GRO enabled and disabled, the latter simulating
uncoalesceable packets (e.g. due to IP or TCP options). The receive side
(which was the device under test) had the NetPerf process pinned to one CPU,
and the device interrupts pinned to a second CPU. CPU utilisation figures
(used in cases of line-rate performance) are summed across all CPUs.
Where not specified (as batch=), net.core.gro_normal_batch was set to 8.
The net-next baseline used for these tests was commit 7d30a7f6424e.
TCP 4 streams, GRO on: all results line rate (9.415Gbps)
net-next: 210.3% cpu
after #1: 181.5% cpu (-13.7%, p=0.031 vs net-next)
after #3: 191.7% cpu (- 8.9%, p=0.102 vs net-next)
TCP 4 streams, GRO off:
after #1: 7.785 Gbps
after #3: 8.387 Gbps (+ 7.7%, p=0.215 vs #1, but note *)
TCP 1 stream, GRO on: all results line rate & ~200% cpu.
TCP 1 stream, GRO off:
after #1: 6.444 Gbps
after #3: 7.363 Gbps (+14.3%, p=0.003 vs #1)
batch=16: 7.199 Gbps
batch= 4: 7.354 Gbps
batch= 0: 5.899 Gbps
TCP 100 RR, GRO off:
net-next: 995.083 us
after #1: 969.167 us (- 2.6%, p=0.204 vs net-next)
after #3: 976.433 us (- 1.9%, p=0.254 vs net-next)
(*) These tests produced a mixture of line-rate and below-line-rate results,
meaning that statistically speaking the results were 'censored' by the
upper bound, and were thus not normally distributed, making a Welch t-test
mathematically invalid. I therefore also calculated estimators according
to [2], which gave the following:
after #1: 8.155 Gbps
after #3: 8.716 Gbps (+ 6.9%, p=0.291 vs #1)
(though my procedure for determining ν wasn't mathematically well-founded
either, so take that p-value with a grain of salt).
Conclusion:
* Patch #1 is a fairly unambiguous improvement.
* Patch #3 has no statistically significant effect when GRO is active.
* Any effect of patch #3 on latency is within statistical noise.
* When GRO is inactive, patch #3 improves bandwidth, though for multiple
streams the effect is smaller (possibly owing to the line-rate limit).
* The optimal batch size for this setup appears to be around 8.
* Setting the batch size to zero gives worse performance than before the
patch; perhaps a static key is needed?
* Drivers which, unlike sfc, pass UDP traffic to GRO would expect to see a
benefit from gaining access to batching.
Notes for future thought: in principle if we passed the napi pointer to
napi_gro_complete(), it could add its superframe skb to napi->rx_list,
rather than immediately netif_receive_skb_internal()ing it. Without that
I'm not sure if there's a possibility of OoO between normal and GROed SKBs
on the same flow.
[1]: http://patchwork.ozlabs.org/cover/997844/
[2]: Cohen 1959, doi: 10.1080/00401706.1959.10489859
Edward Cree (3):
sfc: don't score irq moderation points for GRO
sfc: falcon: don't score irq moderation points for GRO
net: use listified RX for handling GRO_NORMAL skbs
drivers/net/ethernet/sfc/falcon/rx.c | 5 +----
drivers/net/ethernet/sfc/rx.c | 5 +----
include/linux/netdevice.h | 3 +++
net/core/dev.c | 32 ++++++++++++++++++++++++++--
net/core/sysctl_net_core.c | 8 +++++++
5 files changed, 43 insertions(+), 10 deletions(-)
^ permalink raw reply
* RE: [PATCH net-next v6 0/5] devlink: Introduce PCI PF, VF ports and attributes
From: Parav Pandit @ 2019-07-09 19:21 UTC (permalink / raw)
To: David Miller, jakub.kicinski@netronome.com
Cc: jiri@resnulli.us, netdev@vger.kernel.org, Jiri Pirko,
Saeed Mahameed
In-Reply-To: <20190709.120336.1987683013901804676.davem@davemloft.net>
Hi Dave,
> -----Original Message-----
> From: David Miller <davem@davemloft.net>
> Sent: Wednesday, July 10, 2019 12:34 AM
> To: jakub.kicinski@netronome.com
> Cc: jiri@resnulli.us; Parav Pandit <parav@mellanox.com>;
> netdev@vger.kernel.org; Jiri Pirko <jiri@mellanox.com>; Saeed Mahameed
> <saeedm@mellanox.com>
> Subject: Re: [PATCH net-next v6 0/5] devlink: Introduce PCI PF, VF ports and
> attributes
>
> From: Jakub Kicinski <jakub.kicinski@netronome.com>
> Date: Tue, 9 Jul 2019 11:20:58 -0700
>
> > On Tue, 9 Jul 2019 08:17:11 +0200, Jiri Pirko wrote:
> >> >But I'll leave it to Jiri and Dave to decide if its worth a respin
> >> >:) Functionally I think this is okay.
> >>
> >> I'm happy with the set as it is right now.
> >
> > To be clear, I am happy enough as well. Hence the review tag.
>
> Series applied, thanks everyone.
>
> >> Anyway, if you want your concerns to be addresses, you should write
> >> them to the appropriate code. This list is hard to follow.
> >
> > Sorry, I was trying to be concise.
>
> Jiri et al., if Jakub put forth the time and effort to make the list and give you
> feedback you can put forth the effort to go through the list and address his
> feedback with follow-up patches. You cannot dictate how people give
> feedback to your changes, thank you.
I will be happy to write follow up patches.
mostly in kernel 5.4, I will be adding mdev (mediated device) port flavour as discussed in past.
I will possibly write up follow up patch or two before posting them or have it in that series, as it will extend this devlink code further.
^ permalink raw reply
* Re: [PATCH net-next v4 0/3] net: stmmac: Some improvements and a fix
From: David Miller @ 2019-07-09 19:20 UTC (permalink / raw)
To: Jose.Abreu
Cc: netdev, Joao.Pinto, peppe.cavallaro, alexandre.torgue,
mcoquelin.stm32, maxime.ripard, wens, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <cover.1562659012.git.joabreu@synopsys.com>
From: Jose Abreu <Jose.Abreu@synopsys.com>
Date: Tue, 9 Jul 2019 10:02:57 +0200
> Some performace improvements (01/03 and 03/03) and a fix (02/03),
> all for -next.
Series applied, thanks Jose.
^ permalink raw reply
* Re: [PATCH net-next] bnxt_en: Add page_pool_destroy() during RX ring cleanup.
From: David Miller @ 2019-07-09 19:18 UTC (permalink / raw)
To: michael.chan; +Cc: netdev, ilias.apalodimas, gospo
In-Reply-To: <1562658607-30048-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Tue, 9 Jul 2019 03:50:07 -0400
> Add page_pool_destroy() in bnxt_free_rx_rings() during normal RX ring
> cleanup, as Ilias has informed us that the following commit has been
> merged:
>
> 1da4bbeffe41 ("net: core: page_pool: add user refcnt and reintroduce page_pool_destroy")
>
> The special error handling code to call page_pool_free() can now be
> removed. bnxt_free_rx_rings() will always be called during normal
> shutdown or any error paths.
>
> Fixes: 322b87ca55f2 ("bnxt_en: add page_pool support")
> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> Cc: Andy Gospodarek <gospo@broadcom.com>
> Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v6 0/4] net/sched: Introduce tc connection tracking
From: David Miller @ 2019-07-09 19:14 UTC (permalink / raw)
To: paulb
Cc: jiri, roid, yossiku, ozsh, marcelo.leitner, netdev, aconole,
wangzhike, ronye, nst-kernel, john.hurley, simon.horman, jpettit
In-Reply-To: <1562657451-20819-1-git-send-email-paulb@mellanox.com>
From: Paul Blakey <paulb@mellanox.com>
Date: Tue, 9 Jul 2019 10:30:47 +0300
> This patch series add connection tracking capabilities in tc sw datapath.
> It does so via a new tc action, called act_ct, and new tc flower classifier matching
> on conntrack state, mark and label.
...
Ok, I applied this, but two things:
1) You owe Cong Wang an explanation, a real detailed one, about the L2
vs L3 design of this feature. I did not see you address his feedback,
but if you did I apologize.
2) Because the MPLS changes went in first, TCA_ID_CT ended up in a
different spot in the enumeration and therefore the value is
different.
Thanks.
^ permalink raw reply
* Re: [PATCH v3 net-next 19/19] ionic: Add basic devlink interface
From: Shannon Nelson @ 2019-07-09 19:13 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev
In-Reply-To: <20190709065620.GJ2282@nanopsycho.orion>
On 7/8/19 11:56 PM, Jiri Pirko wrote:
> Tue, Jul 09, 2019 at 12:58:00AM CEST, snelson@pensando.io wrote:
>> On 7/8/19 1:03 PM, Jiri Pirko wrote:
>>> Mon, Jul 08, 2019 at 09:58:09PM CEST, snelson@pensando.io wrote:
>>>> On 7/8/19 12:34 PM, Jiri Pirko wrote:
>>>>> Mon, Jul 08, 2019 at 09:25:32PM CEST, snelson@pensando.io wrote:
>>>>>> +
>>>>>> +static const struct devlink_ops ionic_dl_ops = {
>>>>>> + .info_get = ionic_dl_info_get,
>>>>>> +};
>>>>>> +
>>>>>> +int ionic_devlink_register(struct ionic *ionic)
>>>>>> +{
>>>>>> + struct devlink *dl;
>>>>>> + struct ionic **ip;
>>>>>> + int err;
>>>>>> +
>>>>>> + dl = devlink_alloc(&ionic_dl_ops, sizeof(struct ionic *));
>>>>> Oups. Something is wrong with your flow. The devlink alloc is allocating
>>>>> the structure that holds private data (per-device data) for you. This is
>>>>> misuse :/
>>>>>
>>>>> You are missing one parent device struct apparently.
>>>>>
>>>>> Oh, I think I see something like it. The unused "struct ionic_devlink".
>>>> If I'm not mistaken, the alloc is only allocating enough for a pointer, not
>>>> the whole per device struct, and a few lines down from here the pointer to
>>>> the new devlink struct is assigned to ionic->dl. This was based on what I
>>>> found in the qed driver's qed_devlink_register(), and it all seems to work.
>>> I'm not saying your code won't work. What I say is that you should have
>>> a struct for device that would be allocated by devlink_alloc()
>> Is there a particular reason why? I appreciate that devlink_alloc() can give
>> you this device specific space, just as alloc_etherdev_mq() can, but is there
> Yes. Devlink manipulates with the whole device. However,
> alloc_etherdev_mq() allocates only net_device. These are 2 different
> things. devlink port relates 1:1 to net_device. However, devlink
> instance can have multiple ports. What I say is do it correctly.
So what you are saying is that anyone who wants to add even the smallest
devlink feature to their driver needs to rework their basic device
memory setup to do it the devlink way. I can see where some folks may
have a problem with this.
>
>
>> a specific reason why this should be used instead of setting up simply a
>> pointer to a space that has already been allocated? There are several
>> drivers that are using it the way I've setup here, which happened to be the
>> first examples I followed - are they doing something different that makes
>> this valid for them?
> Nope. I'll look at that and fix.
>
>
>>> The ionic struct should be associated with devlink_port. That you are
>>> missing too.
>> We don't support any of devlink_port features at this point, just the simple
>> device information.
> No problem, you can still register devlink_port. You don't have to do
> much in order to do so.
Is there any write-up to help guide developers new to devlink in using
the interface correctly? I haven't found much yet, but perhaps I've
missed something. The manpages are somewhat useful in showing what the
user might do, but they really don't help much in guiding the developer
through these details.
sln
^ permalink raw reply
* Reminder: 29 open syzbot bugs in bluetooth subsystem
From: Eric Biggers @ 2019-07-09 19:07 UTC (permalink / raw)
To: linux-bluetooth, netdev, Marcel Holtmann, Johan Hedberg,
David S. Miller, Loic Poulain, Benjamin Herrenschmidt,
Ben Young Tae Kim
Cc: linux-kernel, syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 29 of them as possibly being bugs in the bluetooth subsystem. I've
listed these reports below, sorted by an algorithm that tries to list first the
reports most likely to be still valid, important, and actionable.
Of these 29 bugs, 5 were seen in mainline in the last week.
Of these 29 bugs, 4 were bisected to commits from the following people:
Loic Poulain <loic.poulain@intel.com>
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Ben Young Tae Kim <ytkim@qca.qualcomm.com>
If you believe a bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed a bug to the bluetooth subsystem, please let me
know, and if possible forward the report to the correct people or mailing list.
Here are the bugs:
--------------------------------------------------------------------------------
Title: WARNING: refcount bug in kobject_get
Last occurred: 5 days ago
Reported: 302 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=06c8522152c9325bf0f1a3dc5b33d1b95a47431f
Original thread: https://lkml.kernel.org/lkml/00000000000037743205757f33ac@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+b74b8b6e712f33454561@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000037743205757f33ac@google.com
--------------------------------------------------------------------------------
Title: WARNING in kernfs_get
Last occurred: 0 days ago
Reported: 302 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=b52dec65c1aaaec9b3893458b13a3304303de321
Original thread: https://lkml.kernel.org/lkml/000000000000f921ae05757f567c@google.com/T/#u
This bug has a C reproducer.
The original thread for this bug received 1 reply, 251 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+3dcb532381f98c86aeb1@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000f921ae05757f567c@google.com
--------------------------------------------------------------------------------
Title: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
Last occurred: 0 days ago
Reported: 125 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=381cb436fe60dc03d7fd2a092b46d7f09542a72a
Original thread: https://lkml.kernel.org/lkml/000000000000b7fd51058370d0d9@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 1 reply, 88 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+91fd909b6e62ebe06131@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000b7fd51058370d0d9@google.com
--------------------------------------------------------------------------------
Title: WARNING in tty_set_termios
Last occurred: 7 days ago
Reported: 177 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=2410d22f1d8e5984217329dd0884b01d99e3e48d
Original thread: https://lkml.kernel.org/lkml/000000000000bcd434057f4eb905@google.com/T/#u
This bug has a C reproducer.
This bug was bisected to:
commit 162f812f23bab583f5d514ca0e4df67797ac9cdf
Author: Loic Poulain <loic.poulain@intel.com>
Date: Mon Sep 19 14:29:27 2016 +0000
Bluetooth: hci_uart: Add Marvell support
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+a950165cbb86bdd023a4@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000bcd434057f4eb905@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in hci_cmd_timeout
Last occurred: 6 days ago
Reported: 63 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=cb23ebfc8f304f510fb717cb783fe8b496c7ffb1
Original thread: https://lkml.kernel.org/lkml/00000000000035c756058848954a@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+19a9f729f05272857487@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000035c756058848954a@google.com
--------------------------------------------------------------------------------
Title: WARNING: refcount bug in kobject_add_internal
Last occurred: 8 days ago
Reported: 8 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=1d709c7eaa63a2bf50387e15d8c0173acc9c9972
Original thread: https://lkml.kernel.org/lkml/0000000000009b1944058ca3e4a8@google.com/T/#u
This bug has a C reproducer.
This bug was bisected to:
commit 726e41097920a73e4c7c33385dcc0debb1281e18
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Tue Jul 10 00:29:10 2018 +0000
drivers: core: Remove glue dirs from sysfs earlier
The original thread for this bug has received 2 replies; the last was 7 days
ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+32259bb9bc1a487ad206@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread, which had activity only 7 days ago. For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at https://lkml.kernel.org/r/0000000000009b1944058ca3e4a8@google.com
--------------------------------------------------------------------------------
Title: memory leak in get_device_parent
Last occurred: 7 days ago
Reported: 42 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=63d2295ec374cc088d03cc83ad9c7a372a3d02e9
Original thread: https://lkml.kernel.org/lkml/0000000000009b950f0589e804b3@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+02e97e2ad931a981e568@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000009b950f0589e804b3@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in rfcomm_dlc_exists
Last occurred: 7 days ago
Reported: 350 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=93ca265e594ab40b3d0e819cf24ba39e75d71fd6
Original thread: https://lkml.kernel.org/lkml/00000000000026c18a0571b9b0de@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+728bead095cef3335bb6@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000026c18a0571b9b0de@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in kfree_skb (3)
Last occurred: 16 days ago
Reported: 63 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=db842327c655eab57b1755f661f1ab677d94e0bb
Original thread: https://lkml.kernel.org/lkml/0000000000002f9ef4058848f26d@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+dcb1305dd05699c40640@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000002f9ef4058848f26d@google.com
--------------------------------------------------------------------------------
Title: general protection fault in kernfs_add_one
Last occurred: 10 days ago
Reported: 296 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=c10f2ca5722a78c613e9ccd45af7877f5debf0ad
Original thread: https://lkml.kernel.org/lkml/000000000000bf6bd30575fec528@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+db1637662f412ac0d556@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000bf6bd30575fec528@google.com
--------------------------------------------------------------------------------
Title: general protection fault in skb_put
Last occurred: 12 days ago
Reported: 155 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=9abc0fdcdea0effb7b27984dbc1f336155cdad3f
Original thread: https://lkml.kernel.org/lkml/000000000000b9e68e0581142f19@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 4 replies; the last was 118 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+65788f9af9d54844389e@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000b9e68e0581142f19@google.com
--------------------------------------------------------------------------------
Title: memory leak in h4_recv_buf
Last occurred: 9 days ago
Reported: 15 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=32811c498b542bcef1950494eed33021cc91fd5f
Original thread: https://lkml.kernel.org/lkml/0000000000006b1779058c0cbdda@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+97388eb9d31b997fe1d0@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000006b1779058c0cbdda@google.com
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Read in hci_event_packet
Last occurred: 11 days ago
Reported: 183 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=d708485af9edc3af35f3b4d554e827c6c8bf6b0f
Original thread: https://lkml.kernel.org/lkml/000000000000696949057ee26e44@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+cec7a50c412a2c03f8f5@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000696949057ee26e44@google.com
--------------------------------------------------------------------------------
Title: WARNING in kernfs_create_dir_ns
Last occurred: 10 days ago
Reported: 10 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=5124d1a0fef7e16146c1f5ea164ad3ddbdb3bb10
Original thread: https://lkml.kernel.org/lkml/0000000000003ec128058c7624ec@google.com/T/#u
This bug has a C reproducer.
The original thread for this bug has received 2 replies; the last was 21 hours
ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+38f5d5cf7ae88c46b11a@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread, which had activity only 21 hours ago. For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at https://lkml.kernel.org/r/0000000000003ec128058c7624ec@google.com
--------------------------------------------------------------------------------
Title: general protection fault in qca_setup
Last occurred: 148 days ago
Reported: 148 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=62aaa13b8b6bba7f5bca8c0defef34b9a1623135
Original thread: https://lkml.kernel.org/lkml/0000000000002996510581a1487e@google.com/T/#u
This bug has a C reproducer.
This bug was bisected to:
commit 0ff252c1976da5d80db1377eb39b551931e61826
Author: Ben Young Tae Kim <ytkim@qca.qualcomm.com>
Date: Mon Aug 10 21:24:17 2015 +0000
Bluetooth: hciuart: Add support QCA chipset for UART
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+8c0dbf8843bb75efaa05@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000002996510581a1487e@google.com
--------------------------------------------------------------------------------
Title: BUG: unable to handle kernel NULL pointer dereference in hci_uart_set_flow_control
Last occurred: 110 days ago
Reported: 110 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=1b42faa2848963564a5b1b7f8c837ea7b55ffa50
Original thread: https://lkml.kernel.org/lkml/00000000000017690505849d6b3c@google.com/T/#u
This bug has a C reproducer.
This bug was bisected to:
commit 162f812f23bab583f5d514ca0e4df67797ac9cdf
Author: Loic Poulain <loic.poulain@intel.com>
Date: Mon Sep 19 14:29:27 2016 +0000
Bluetooth: hci_uart: Add Marvell support
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+79337b501d6aa974d0f6@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000017690505849d6b3c@google.com
--------------------------------------------------------------------------------
Title: KMSAN: uninit-value in hci_event_packet
Last occurred: 73 days ago
Reported: 86 days ago
Branches: Mainline (with KMSAN patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=fac3d7b25f0e5f3899e4b0dcec32bb3177c95718
Original thread: https://lkml.kernel.org/lkml/0000000000005bb0ae05867271c1@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+4918ee47ac82d51de00d@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000005bb0ae05867271c1@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Write in hci_sock_release
Last occurred: 186 days ago
Reported: 259 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=47befb59c610a69f024db20b927dea80c88fc045
Original thread: https://lkml.kernel.org/lkml/0000000000003692760578e651dd@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 3 replies; the last was 106 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+b364ed862aa07c74bc62@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000003692760578e651dd@google.com
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Read in bacpy
Last occurred: 68 days ago
Reported: 183 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=3acd1155d48a5acc5d76711568b04926945a6885
Original thread: https://lkml.kernel.org/lkml/0000000000008a1bce057ede3d13@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 6 replies; the last was 111 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+660883c56e2fa65d4497@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000008a1bce057ede3d13@google.com
--------------------------------------------------------------------------------
Title: general protection fault in idr_remove
Last occurred: 12 days ago
Reported: 146 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=669469483cd7be33607ad681073484750f6f4c60
Original thread: https://lkml.kernel.org/lkml/00000000000023a7e70581b71894@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+3d07f0ffd652af4f49e6@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000023a7e70581b71894@google.com
--------------------------------------------------------------------------------
Title: WARNING: ODEBUG bug in rfcomm_dlc_free
Last occurred: 61 days ago
Reported: 343 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=97b7072a02091741ffc58f97884ab91565fd97ce
Original thread: https://lkml.kernel.org/lkml/00000000000086f39e057245c3ac@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+1f6d4ad860c650c2f215@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000086f39e057245c3ac@google.com
--------------------------------------------------------------------------------
Title: INFO: trying to register non-static key in hci_uart_send_frame
Last occurred: 82 days ago
Reported: 130 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=8aa05f314c1391e788221378935286690d49f482
Original thread: https://lkml.kernel.org/lkml/0000000000001913600582f91f5b@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+a8587ba69fc78395d947@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000001913600582f91f5b@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in rfcomm_dlc_open (2)
Last occurred: 49 days ago
Reported: 77 days ago
Branches: net and net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=19321b91aa70d43289d580eb8cbf21e6aecef64f
Original thread: https://lkml.kernel.org/lkml/000000000000876c89058734fc71@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+0b0fd24d40f358830891@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000876c89058734fc71@google.com
--------------------------------------------------------------------------------
Title: WARNING in kernfs_activate
Last occurred: 84 days ago
Reported: 63 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=059379fb4ac22ac01d4f2d658aaa6043ff021f42
Original thread: https://lkml.kernel.org/lkml/000000000000fd5e300588491545@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+1202f8882e4f4881d814@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000fd5e300588491545@google.com
--------------------------------------------------------------------------------
Title: INFO: trying to register non-static key in hci_uart_flush
Last occurred: 148 days ago
Reported: 148 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=9b359a901fde7f3eacc17249cbd613d35612e9aa
Original thread: https://lkml.kernel.org/lkml/0000000000006941590581a15637@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+e8cd9d8b4dfedf394390@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000006941590581a15637@google.com
--------------------------------------------------------------------------------
Title: WARNING: ODEBUG bug in hci_uart_tty_close
Last occurred: 142 days ago
Reported: 141 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=94b6786a5d26079c82301b2ec235ca4717884f4e
Original thread: https://lkml.kernel.org/lkml/0000000000005455bf058225e9c0@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+9fd324c8c2176a6022d3@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000005455bf058225e9c0@google.com
--------------------------------------------------------------------------------
Title: general protection fault in rfcomm_dlc_exists
Last occurred: 67 days ago
Reported: 63 days ago
Branches: net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=1c4e5c426ab13696077aa6d0c67596e074605ffd
Original thread: https://lkml.kernel.org/lkml/0000000000009c83b005884900cf@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+362be51217ce29d215bc@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000009c83b005884900cf@google.com
--------------------------------------------------------------------------------
Title: general protection fault in rfcomm_dlc_open
Last occurred: 68 days ago
Reported: 63 days ago
Branches: net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=05e856115d50ca3d56e1fbea58b612a78877be65
Unfortunately, this bug does not have a reproducer.
For some reason the syzbot dashboard doesn't contain a link to the original
thread for this bug, so my script couldn't provide a link to it in this
reminder. Try searching for the bug title.
--------------------------------------------------------------------------------
Title: WARNING in lockdep_register_key
Last occurred: 113 days ago
Reported: 129 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=5f34c586def64408fb57ee0fd898da67efda36c3
Original thread: https://lkml.kernel.org/lkml/000000000000baab660583172b5c@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+072814ec793ff1946da1@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000baab660583172b5c@google.com
^ permalink raw reply
* Re: [PATCH v3 net-next 19/19] ionic: Add basic devlink interface
From: Shannon Nelson @ 2019-07-09 19:06 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev
In-Reply-To: <20190708182654.72446be5@cakuba.netronome.com>
On 7/8/19 6:26 PM, Jakub Kicinski wrote:
> On Mon, 8 Jul 2019 12:25:32 -0700, Shannon Nelson wrote:
>> Add a devlink interface for access to information that isn't
>> normally available through ethtool or the iplink interface.
>>
>> Example:
>> $ ./devlink -j -p dev info pci/0000:b6:00.0
>> {
>> "info": {
>> "pci/0000:b6:00.0": {
>> "driver": "ionic",
>> "serial_number": "FLM18420073",
>> "versions": {
>> "fixed": {
>> "fw_version": "0.11.0-50",
> Hm. Fixed is for hardware components. Seeing FW version reported as
> fixed seems counter intuitive. You probably want "running"?
Sure.
>
>> "fw_status": "0x1",
> I don't think this is the right interface to report status-like
> information. Perhaps devlink health reporters?
>
>> "fw_heartbeat": "0x716ce",
> Ditto, perhaps best to report it in health stuff?
I haven't dug too far into the health stuff, but on the surface it looks
like a lot of infrastructure for a couple of simple values. I'm tempted
to put them back into debugfs for the moment rather than add that much
more interface goo.
>
>> "asic_type": "0x0",
>> "asic_rev": "0x0"
> These seem like legit "fixed" versions 👍
>
>> }
>> }
>> }
>> }
>> }
>>
>> Signed-off-by: Shannon Nelson <snelson@pensando.io>
> Isn't this a new patch? Perhaps you'd be best off upstreaming the
> first batch of support and add features later? It'd be easier on
> reviewers so we don't have to keep re-checking the first 16 patches..
Yes, and I commented about this in v2 notes: in the tension between
trying to address comments, keep the line count down, keep the basic
feature set, and keep the patches self-consistent and simple, I added
this one patch for the devlink goodies that were requested. At least the
total line count went down.
sln
^ permalink raw reply
* Re: [PATCH net-next v6 0/5] devlink: Introduce PCI PF, VF ports and attributes
From: David Miller @ 2019-07-09 19:03 UTC (permalink / raw)
To: jakub.kicinski; +Cc: jiri, parav, netdev, jiri, saeedm
In-Reply-To: <20190709112058.7ffe61d3@cakuba.netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Tue, 9 Jul 2019 11:20:58 -0700
> On Tue, 9 Jul 2019 08:17:11 +0200, Jiri Pirko wrote:
>> >But I'll leave it to Jiri and Dave to decide if its worth a respin :)
>> >Functionally I think this is okay.
>>
>> I'm happy with the set as it is right now.
>
> To be clear, I am happy enough as well. Hence the review tag.
Series applied, thanks everyone.
>> Anyway, if you want your concerns to be addresses, you should write
>> them to the appropriate code. This list is hard to follow.
>
> Sorry, I was trying to be concise.
Jiri et al., if Jakub put forth the time and effort to make the list
and give you feedback you can put forth the effort to go through the
list and address his feedback with follow-up patches. You cannot
dictate how people give feedback to your changes, thank you.
^ permalink raw reply
* [PATCH] [net-next] net: dsa: vsc73xx: fix NET_DSA and OF dependencies
From: Arnd Bergmann @ 2019-07-09 18:55 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, David S. Miller
Cc: Arnd Bergmann, Pawel Dembicki, Linus Walleij, netdev,
linux-kernel
The restructuring of the driver got the dependencies wrong: without
CONFIG_NET_DSA we get this build failure:
WARNING: unmet direct dependencies detected for NET_DSA_VITESSE_VSC73XX
Depends on [n]: NETDEVICES [=y] && HAVE_NET_DSA [=y] && OF [=y] && NET_DSA [=n]
Selected by [m]:
- NET_DSA_VITESSE_VSC73XX_PLATFORM [=m] && NETDEVICES [=y] && HAVE_NET_DSA [=y] && HAS_IOMEM [=y]
ERROR: "dsa_unregister_switch" [drivers/net/dsa/vitesse-vsc73xx-core.ko] undefined!
ERROR: "dsa_switch_alloc" [drivers/net/dsa/vitesse-vsc73xx-core.ko] undefined!
ERROR: "dsa_register_switch" [drivers/net/dsa/vitesse-vsc73xx-core.ko] undefined!
Add the appropriate dependencies.
Fixes: 95711cd5f0b4 ("net: dsa: vsc73xx: Split vsc73xx driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/dsa/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index cf9dbd15dd2d..f6232ce8481f 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -111,6 +111,8 @@ config NET_DSA_VITESSE_VSC73XX
config NET_DSA_VITESSE_VSC73XX_SPI
tristate "Vitesse VSC7385/7388/7395/7398 SPI mode support"
+ depends on OF
+ depends on NET_DSA
depends on SPI
select NET_DSA_VITESSE_VSC73XX
---help---
@@ -119,6 +121,8 @@ config NET_DSA_VITESSE_VSC73XX_SPI
config NET_DSA_VITESSE_VSC73XX_PLATFORM
tristate "Vitesse VSC7385/7388/7395/7398 Platform mode support"
+ depends on OF
+ depends on NET_DSA
depends on HAS_IOMEM
select NET_DSA_VITESSE_VSC73XX
---help---
--
2.20.0
^ permalink raw reply related
* Re: WARNING in mark_chain_precision
From: Andrii Nakryiko @ 2019-07-09 18:55 UTC (permalink / raw)
To: syzbot
Cc: aaron.f.brown, Alexei Starovoitov, bpf, Daniel Borkmann,
David S. Miller, hawk, intel-wired-lan, Jakub Kicinski,
jeffrey.t.kirsher, john fastabend, Martin Lau, open list,
Networking, sasha.neftin, Song Liu, syzkaller-bugs, xdp-newbies,
Yonghong Song
In-Reply-To: <000000000000a94981058d37f1a4@google.com>
Original reproducer is almost identical to the one that is fixed by
https://patchwork.ozlabs.org/patch/1129479/.
bpf_prog_free_deferred bug that's undeterministically exposed after
this fix seems to be the cause of a bunch of other bug reports and is
not related to verifier precision tracking.
#syz dup: WARNING in __mark_chain_precision
^ permalink raw reply
* Re: [PATCH net-next] bnxt_en: Add page_pool_destroy() during RX ring cleanup.
From: Ilias Apalodimas @ 2019-07-09 18:55 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: Michael Chan, davem, netdev
In-Reply-To: <20190709163154.GO87269@C02RW35GFVH8.dhcp.broadcom.net>
On Tue, Jul 09, 2019 at 12:31:54PM -0400, Andy Gospodarek wrote:
> On Tue, Jul 09, 2019 at 06:20:57PM +0300, Ilias Apalodimas wrote:
> > Hi,
> >
> > > > Add page_pool_destroy() in bnxt_free_rx_rings() during normal RX ring
> > > > cleanup, as Ilias has informed us that the following commit has been
> > > > merged:
> > > >
> > > > 1da4bbeffe41 ("net: core: page_pool: add user refcnt and reintroduce page_pool_destroy")
> > > >
> > > > The special error handling code to call page_pool_free() can now be
> > > > removed. bnxt_free_rx_rings() will always be called during normal
> > > > shutdown or any error paths.
> > > >
> > > > Fixes: 322b87ca55f2 ("bnxt_en: add page_pool support")
> > > > Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > > > Cc: Andy Gospodarek <gospo@broadcom.com>
> > > > Signed-off-by: Michael Chan <michael.chan@broadcom.com>
> > > > ---
> > > > drivers/net/ethernet/broadcom/bnxt/bnxt.c | 8 ++------
> > > > 1 file changed, 2 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> > > > index e9d3bd8..2b5b0ab 100644
> > > > --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> > > > +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> > > > @@ -2500,6 +2500,7 @@ static void bnxt_free_rx_rings(struct bnxt *bp)
> > > > if (xdp_rxq_info_is_reg(&rxr->xdp_rxq))
> > > > xdp_rxq_info_unreg(&rxr->xdp_rxq);
> > > >
> > > > + page_pool_destroy(rxr->page_pool);
> > > > rxr->page_pool = NULL;
> > > >
> > > > kfree(rxr->rx_tpa);
> > > > @@ -2560,19 +2561,14 @@ static int bnxt_alloc_rx_rings(struct bnxt *bp)
> > > > return rc;
> > > >
> > > > rc = xdp_rxq_info_reg(&rxr->xdp_rxq, bp->dev, i);
> > > > - if (rc < 0) {
> > > > - page_pool_free(rxr->page_pool);
> > > > - rxr->page_pool = NULL;
> > > > + if (rc < 0)
> > > > return rc;
> > > > - }
> > > >
> > > > rc = xdp_rxq_info_reg_mem_model(&rxr->xdp_rxq,
> > > > MEM_TYPE_PAGE_POOL,
> > > > rxr->page_pool);
> > > > if (rc) {
> > > > xdp_rxq_info_unreg(&rxr->xdp_rxq);
> > > > - page_pool_free(rxr->page_pool);
> > > > - rxr->page_pool = NULL;
> > >
> > > Rather than deleting these lines it would also be acceptable to do:
> > >
> > > if (rc) {
> > > xdp_rxq_info_unreg(&rxr->xdp_rxq);
> > > - page_pool_free(rxr->page_pool);
> > > + page_pool_destroy(rxr->page_pool);
> > > rxr->page_pool = NULL;
> > > return rc;
> > > }
> > >
> > > but anytime there is a failure to bnxt_alloc_rx_rings the driver will
> > > immediately follow it up with a call to bnxt_free_rx_rings, so
> > > page_pool_destroy will be called.
> > >
> > > Thanks for pushing this out so quickly!
> > >
> >
> > I also can't find page_pool_release_page() or page_pool_put_page() called when
> > destroying the pool. Can you try to insmod -> do some traffic -> rmmod ?
> > If there's stale buffers that haven't been unmapped properly you'll get a
> > WARN_ON for them.
>
> I did that test a few times with a few different bpf progs but I do not
> see any WARN messages. Of course this does not mean that the code we
> have is 100% correct.
>
I'll try to have a closer look as well
> Presumably you are talking about one of these messages, right?
>
> 215 /* The distance should not be able to become negative */
> 216 WARN(inflight < 0, "Negative(%d) inflight packet-pages", inflight);
>
> or
>
> 356 /* Drivers should fix this, but only problematic when DMA is used */
> 357 WARN(1, "Still in-flight pages:%d hold:%u released:%u",
> 358 distance, hold_cnt, release_cnt);
>
Yea particularly the second one. There's a counter we increase everytime you
alloc a fresh page which needs to be decresed before freeing the whole pool.
page_pool_release_page will do that for example
>
> > This part was added later on in the API when Jesper fixed in-flight packet
> > handling
Thanks
/Ilias
^ permalink raw reply
* Re: [PATCH net-next v6 0/5] devlink: Introduce PCI PF, VF ports and attributes
From: Jakub Kicinski @ 2019-07-09 18:20 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Parav Pandit, netdev, jiri, saeedm
In-Reply-To: <20190709061711.GH2282@nanopsycho.orion>
On Tue, 9 Jul 2019 08:17:11 +0200, Jiri Pirko wrote:
> >But I'll leave it to Jiri and Dave to decide if its worth a respin :)
> >Functionally I think this is okay.
>
> I'm happy with the set as it is right now.
To be clear, I am happy enough as well. Hence the review tag.
> Anyway, if you want your concerns to be addresses, you should write
> them to the appropriate code. This list is hard to follow.
Sorry, I was trying to be concise.
> >Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
^ permalink raw reply
* Re: [net-next:master 342/422] drivers/net/dsa/qca8k.c:1050:21: error: implicit declaration of function 'devm_gpiod_get_optional'; did you mean 'devm_gpio_request_one'?
From: Christian Lamparter @ 2019-07-09 18:17 UTC (permalink / raw)
To: kbuild test robot; +Cc: kbuild-all, Netdev
In-Reply-To: <201907081633.62bX7tN5%lkp@intel.com>
(let's hope that the gmail web interface doesn't mangle this too much)
On Mon, Jul 8, 2019 at 10:16 AM kbuild test robot <lkp@intel.com> wrote:
>
> tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/davem/net-next.git master
> head: 61a582be1a668a0c1407a46f779965bfeff88784
> commit: a653f2f538f9d3e2d1f1445f74a47bfdace85c2e [342/422] net: dsa: qca8k: introduce reset via gpio feature
> config: x86_64-randconfig-s2-07081539 (attached as .config)
> compiler: gcc-7 (Debian 7.4.0-9) 7.4.0
> reproduce:
> git checkout a653f2f538f9d3e2d1f1445f74a47bfdace85c2e
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
> drivers/net/dsa/qca8k.c: In function 'qca8k_sw_probe':
> >> drivers/net/dsa/qca8k.c:1050:21: error: implicit declaration of function 'devm_gpiod_get_optional'; did you mean 'devm_gpio_request_one'? [-Werror=implicit-function-declaration]
> priv->reset_gpio = devm_gpiod_get_optional(priv->dev, "reset",
> ^~~~~~~~~~~~~~~~~~~~~~~
> devm_gpio_request_one
> >> drivers/net/dsa/qca8k.c:1051:10: error: 'GPIOD_ASIS' undeclared (first use in this function); did you mean 'GPIOF_IN'?
> GPIOD_ASIS);
> ^~~~~~~~~~
> GPIOF_IN
> drivers/net/dsa/qca8k.c:1051:10: note: each undeclared identifier is reported only once for each function it appears in
> >> drivers/net/dsa/qca8k.c:1056:3: error: implicit declaration of function 'gpiod_set_value_cansleep'; did you mean 'gpio_set_value_cansleep'? [-Werror=implicit-function-declaration]
> gpiod_set_value_cansleep(priv->reset_gpio, 1);
> ^~~~~~~~~~~~~~~~~~~~~~~~
> gpio_set_value_cansleep
> cc1: some warnings being treated as errors
>
> vim +1050 drivers/net/dsa/qca8k.c
Ok, I think that just the
#include <linux/gpio/consumer.h>
is needed. I can make a patch for this no issue. I'll download
net-next over the next days
(currently I'm just on a 3G/EDGE connection, so the 1.53 GiB will have
to wait until the
weekend.)
Regards,
Christian
^ permalink raw reply
* [PATCH bpf-next v8 2/2] selftests/bpf: Add selftests for bpf_perf_event_output
From: Allan Zhang @ 2019-07-09 18:00 UTC (permalink / raw)
To: netdev, bpf, songliubraving, daniel; +Cc: ast, allanzhang
In-Reply-To: <20190709180005.33406-1-allanzhang@google.com>
From: allanzhang <allanzhang@google.com>
Software event output is only enabled by a few prog types.
This test is to ensure that all supported types are enabled for
bpf_perf_event_output successfully.
Signed-off-by: Allan Zhang <allanzhang@google.com>
---
tools/testing/selftests/bpf/test_verifier.c | 12 ++-
.../selftests/bpf/verifier/event_output.c | 94 +++++++++++++++++++
2 files changed, 105 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/bpf/verifier/event_output.c
diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c
index c5514daf8865..5e98d7c37eb7 100644
--- a/tools/testing/selftests/bpf/test_verifier.c
+++ b/tools/testing/selftests/bpf/test_verifier.c
@@ -50,7 +50,7 @@
#define MAX_INSNS BPF_MAXINSNS
#define MAX_TEST_INSNS 1000000
#define MAX_FIXUPS 8
-#define MAX_NR_MAPS 18
+#define MAX_NR_MAPS 19
#define MAX_TEST_RUNS 8
#define POINTER_VALUE 0xcafe4all
#define TEST_DATA_LEN 64
@@ -84,6 +84,7 @@ struct bpf_test {
int fixup_map_array_wo[MAX_FIXUPS];
int fixup_map_array_small[MAX_FIXUPS];
int fixup_sk_storage_map[MAX_FIXUPS];
+ int fixup_map_event_output[MAX_FIXUPS];
const char *errstr;
const char *errstr_unpriv;
uint32_t retval, retval_unpriv, insn_processed;
@@ -627,6 +628,7 @@ static void do_test_fixup(struct bpf_test *test, enum bpf_prog_type prog_type,
int *fixup_map_array_wo = test->fixup_map_array_wo;
int *fixup_map_array_small = test->fixup_map_array_small;
int *fixup_sk_storage_map = test->fixup_sk_storage_map;
+ int *fixup_map_event_output = test->fixup_map_event_output;
if (test->fill_helper) {
test->fill_insns = calloc(MAX_TEST_INSNS, sizeof(struct bpf_insn));
@@ -788,6 +790,14 @@ static void do_test_fixup(struct bpf_test *test, enum bpf_prog_type prog_type,
fixup_sk_storage_map++;
} while (*fixup_sk_storage_map);
}
+ if (*fixup_map_event_output) {
+ map_fds[18] = __create_map(BPF_MAP_TYPE_PERF_EVENT_ARRAY,
+ sizeof(int), sizeof(int), 1, 0);
+ do {
+ prog[*fixup_map_event_output].imm = map_fds[18];
+ fixup_map_event_output++;
+ } while (*fixup_map_event_output);
+ }
}
static int set_admin(bool admin)
diff --git a/tools/testing/selftests/bpf/verifier/event_output.c b/tools/testing/selftests/bpf/verifier/event_output.c
new file mode 100644
index 000000000000..130553e19eca
--- /dev/null
+++ b/tools/testing/selftests/bpf/verifier/event_output.c
@@ -0,0 +1,94 @@
+/* instructions used to output a skb based software event, produced
+ * from code snippet:
+ * struct TMP {
+ * uint64_t tmp;
+ * } tt;
+ * tt.tmp = 5;
+ * bpf_perf_event_output(skb, &connection_tracking_event_map, 0,
+ * &tt, sizeof(tt));
+ * return 1;
+ *
+ * the bpf assembly from llvm is:
+ * 0: b7 02 00 00 05 00 00 00 r2 = 5
+ * 1: 7b 2a f8 ff 00 00 00 00 *(u64 *)(r10 - 8) = r2
+ * 2: bf a4 00 00 00 00 00 00 r4 = r10
+ * 3: 07 04 00 00 f8 ff ff ff r4 += -8
+ * 4: 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r2 = 0ll
+ * 6: b7 03 00 00 00 00 00 00 r3 = 0
+ * 7: b7 05 00 00 08 00 00 00 r5 = 8
+ * 8: 85 00 00 00 19 00 00 00 call 25
+ * 9: b7 00 00 00 01 00 00 00 r0 = 1
+ * 10: 95 00 00 00 00 00 00 00 exit
+ *
+ * The reason I put the code here instead of fill_helpers is that map fixup
+ * is against the insns, instead of filled prog.
+ */
+
+#define __PERF_EVENT_INSNS__ \
+ BPF_MOV64_IMM(BPF_REG_2, 5), \
+ BPF_STX_MEM(BPF_DW, BPF_REG_10, BPF_REG_2, -8), \
+ BPF_MOV64_REG(BPF_REG_4, BPF_REG_10), \
+ BPF_ALU64_IMM(BPF_ADD, BPF_REG_4, -8), \
+ BPF_LD_MAP_FD(BPF_REG_2, 0), \
+ BPF_MOV64_IMM(BPF_REG_3, 0), \
+ BPF_MOV64_IMM(BPF_REG_5, 8), \
+ BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, \
+ BPF_FUNC_perf_event_output), \
+ BPF_MOV64_IMM(BPF_REG_0, 1), \
+ BPF_EXIT_INSN(),
+{
+ "perfevent for sockops",
+ .insns = { __PERF_EVENT_INSNS__ },
+ .prog_type = BPF_PROG_TYPE_SOCK_OPS,
+ .fixup_map_event_output = { 4 },
+ .result = ACCEPT,
+ .retval = 1,
+},
+{
+ "perfevent for tc",
+ .insns = { __PERF_EVENT_INSNS__ },
+ .prog_type = BPF_PROG_TYPE_SCHED_CLS,
+ .fixup_map_event_output = { 4 },
+ .result = ACCEPT,
+ .retval = 1,
+},
+{
+ "perfevent for lwt out",
+ .insns = { __PERF_EVENT_INSNS__ },
+ .prog_type = BPF_PROG_TYPE_LWT_OUT,
+ .fixup_map_event_output = { 4 },
+ .result = ACCEPT,
+ .retval = 1,
+},
+{
+ "perfevent for xdp",
+ .insns = { __PERF_EVENT_INSNS__ },
+ .prog_type = BPF_PROG_TYPE_XDP,
+ .fixup_map_event_output = { 4 },
+ .result = ACCEPT,
+ .retval = 1,
+},
+{
+ "perfevent for socket filter",
+ .insns = { __PERF_EVENT_INSNS__ },
+ .prog_type = BPF_PROG_TYPE_SOCKET_FILTER,
+ .fixup_map_event_output = { 4 },
+ .result = ACCEPT,
+ .retval = 1,
+},
+{
+ "perfevent for sk_skb",
+ .insns = { __PERF_EVENT_INSNS__ },
+ .prog_type = BPF_PROG_TYPE_SK_SKB,
+ .fixup_map_event_output = { 4 },
+ .result = ACCEPT,
+ .retval = 1,
+},
+{
+ "perfevent for cgroup skb",
+ .insns = { __PERF_EVENT_INSNS__ },
+ .prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+ .fixup_map_event_output = { 4 },
+ .result = ACCEPT,
+ .retval = 1,
+},
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH bpf-next v8 1/2] bpf: Allow bpf_skb_event_output for a few prog types
From: Allan Zhang @ 2019-07-09 18:00 UTC (permalink / raw)
To: netdev, bpf, songliubraving, daniel; +Cc: ast, allanzhang
In-Reply-To: <20190709180005.33406-1-allanzhang@google.com>
From: allanzhang <allanzhang@google.com>
Software event output is only enabled by a few prog types right now (TC,
LWT out, XDP, sockops). Many other skb based prog types need
bpf_skb_event_output to produce software event.
Added socket_filter, cg_skb, sk_skb prog types to generate sw event.
Test bpf code is generated from code snippet:
struct TMP {
uint64_t tmp;
} tt;
tt.tmp = 5;
bpf_perf_event_output(skb, &connection_tracking_event_map, 0,
&tt, sizeof(tt));
return 1;
the bpf assembly from llvm is:
0: b7 02 00 00 05 00 00 00 r2 = 5
1: 7b 2a f8 ff 00 00 00 00 *(u64 *)(r10 - 8) = r2
2: bf a4 00 00 00 00 00 00 r4 = r10
3: 07 04 00 00 f8 ff ff ff r4 += -8
4: 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r2 = 0ll
6: b7 03 00 00 00 00 00 00 r3 = 0
7: b7 05 00 00 08 00 00 00 r5 = 8
8: 85 00 00 00 19 00 00 00 call 25
9: b7 00 00 00 01 00 00 00 r0 = 1
10: 95 00 00 00 00 00 00 00 exit
Signed-off-by: Allan Zhang <allanzhang@google.com>
---
net/core/filter.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/core/filter.c b/net/core/filter.c
index 2014d76e0d2a..b75fcf412628 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -5958,6 +5958,8 @@ sk_filter_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
return &bpf_get_socket_cookie_proto;
case BPF_FUNC_get_socket_uid:
return &bpf_get_socket_uid_proto;
+ case BPF_FUNC_perf_event_output:
+ return &bpf_skb_event_output_proto;
default:
return bpf_base_func_proto(func_id);
}
@@ -5978,6 +5980,8 @@ cg_skb_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
return &bpf_sk_storage_get_proto;
case BPF_FUNC_sk_storage_delete:
return &bpf_sk_storage_delete_proto;
+ case BPF_FUNC_perf_event_output:
+ return &bpf_skb_event_output_proto;
#ifdef CONFIG_SOCK_CGROUP_DATA
case BPF_FUNC_skb_cgroup_id:
return &bpf_skb_cgroup_id_proto;
@@ -6226,6 +6230,8 @@ sk_skb_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
return &bpf_sk_redirect_map_proto;
case BPF_FUNC_sk_redirect_hash:
return &bpf_sk_redirect_hash_proto;
+ case BPF_FUNC_perf_event_output:
+ return &bpf_skb_event_output_proto;
#ifdef CONFIG_INET
case BPF_FUNC_sk_lookup_tcp:
return &bpf_sk_lookup_tcp_proto;
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH bpf-next v8 0/2] bpf: Allow bpf_skb_event_output for more prog types
From: Allan Zhang @ 2019-07-09 18:00 UTC (permalink / raw)
To: netdev, bpf, songliubraving, daniel; +Cc: ast, Allan Zhang
Software event output is only enabled by a few prog types right now (TC,
LWT out, XDP, sockops). Many other skb based prog types need
bpf_skb_event_output to produce software event.
More prog types are enabled to access bpf_skb_event_output in this
patch.
v8 changes:
No actual change, just cc to netdev@vger.kernel.org and
bpf@vger.kernel.org.
v7 patches are acked by Song Liu.
v7 changes:
Reformat from hints by scripts/checkpatch.pl, including Song's comment
on signed-off-by name to captical case in cover letter.
3 of hints are ignored:
1. new file mode.
2. SPDX-License-Identifier for event_output.c since all files under
this dir have no such line.
3. "Macros ... enclosed in parentheses" for macro in event_output.c
due to code's nature.
Change patch 02 subject "bpf:..." to "selftests/bpf:..."
v6 changes:
Fix Signed-off-by, fix fixup map creation.
v5 changes:
Fix typos, reformat comments in event_output.c, move revision history to
cover letter.
v4 changes:
Reformating log message.
v3 changes:
Reformating log message.
v2 changes:
Reformating log message.
Allan Zhang (2):
bpf: Allow bpf_skb_event_output for a few prog types
selftests/bpf: Add selftests for bpf_perf_event_output
net/core/filter.c | 6 ++
tools/testing/selftests/bpf/test_verifier.c | 12 ++-
.../selftests/bpf/verifier/event_output.c | 94 +++++++++++++++++++
3 files changed, 111 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/bpf/verifier/event_output.c
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply
* Re: [PATCH bpf] selftests/bpf: fix bpf_target_sparc check
From: Andrii Nakryiko @ 2019-07-09 17:56 UTC (permalink / raw)
To: Ilya Leoshkevich; +Cc: bpf, Networking
In-Reply-To: <20190709152126.37853-1-iii@linux.ibm.com>
On Tue, Jul 9, 2019 at 8:22 AM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
>
> bpf_helpers.h fails to compile on sparc: the code should be checking
> for defined(bpf_target_sparc), but checks simply for bpf_target_sparc.
>
> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
> ---
> tools/testing/selftests/bpf/bpf_helpers.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/bpf/bpf_helpers.h b/tools/testing/selftests/bpf/bpf_helpers.h
> index 5f6f9e7aba2a..a8fea087aa90 100644
> --- a/tools/testing/selftests/bpf/bpf_helpers.h
> +++ b/tools/testing/selftests/bpf/bpf_helpers.h
> @@ -443,7 +443,7 @@ static int (*bpf_skb_adjust_room)(void *ctx, __s32 len_diff, __u32 mode,
> #ifdef bpf_target_powerpc
While at it, can you please also fix this one?
> #define BPF_KPROBE_READ_RET_IP(ip, ctx) ({ (ip) = (ctx)->link; })
> #define BPF_KRETPROBE_READ_RET_IP BPF_KPROBE_READ_RET_IP
> -#elif bpf_target_sparc
> +#elif defined(bpf_target_sparc)
> #define BPF_KPROBE_READ_RET_IP(ip, ctx) ({ (ip) = PT_REGS_RET(ctx); })
> #define BPF_KRETPROBE_READ_RET_IP BPF_KPROBE_READ_RET_IP
> #else
> --
> 2.21.0
>
^ permalink raw reply
* Re: [PATCHv2] tools bpftool: Fix json dump crash on powerpc
From: Jiri Olsa @ 2019-07-09 17:53 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Quentin Monnet, Jakub Kicinski, Jiri Olsa, Alexei Starovoitov,
Michael Petlan, netdev, bpf, Martin KaFai Lau
In-Reply-To: <5168f635-a23c-eac3-479d-747e55adfc4c@iogearbox.net>
On Sat, Jul 06, 2019 at 12:00:44AM +0200, Daniel Borkmann wrote:
> On 07/05/2019 07:26 PM, Quentin Monnet wrote:
> > 2019-07-05 10:24 UTC-0700 ~ Jakub Kicinski <jakub.kicinski@netronome.com>
> >> On Fri, 5 Jul 2019 14:10:31 +0200, Jiri Olsa wrote:
> >>> Michael reported crash with by bpf program in json mode on powerpc:
> >>>
> >>> # bpftool prog -p dump jited id 14
> >>> [{
> >>> "name": "0xd00000000a9aa760",
> >>> "insns": [{
> >>> "pc": "0x0",
> >>> "operation": "nop",
> >>> "operands": [null
> >>> ]
> >>> },{
> >>> "pc": "0x4",
> >>> "operation": "nop",
> >>> "operands": [null
> >>> ]
> >>> },{
> >>> "pc": "0x8",
> >>> "operation": "mflr",
> >>> Segmentation fault (core dumped)
> >>>
> >>> The code is assuming char pointers in format, which is not always
> >>> true at least for powerpc. Fixing this by dumping the whole string
> >>> into buffer based on its format.
> >>>
> >>> Please note that libopcodes code does not check return values from
> >>> fprintf callback, but as per Jakub suggestion returning -1 on allocation
> >>> failure so we do the best effort to propagate the error.
> >>>
> >>> Reported-by: Michael Petlan <mpetlan@redhat.com>
> >>> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> >>
> >> Thanks, let me repost all the tags (Quentin, please shout if you're
> >> not ok with this :)):
> >
> > I confirm it's all good for me, thanks :)
> >
> >> Fixes: 107f041212c1 ("tools: bpftool: add JSON output for `bpftool prog dump jited *` command")
> >> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
> >> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>
> Given merge window coming up, I've applied this to bpf-next, thanks everyone!
>
> P.s.: Jiri, please repost full/proper patch next time instead of inline reply.
will do, thanks
jirka
^ permalink raw reply
* Re: [PATCH v3 bpf-next 0/4] selftests/bpf: fix compiling loop{1,2,3}.c on s390
From: Andrii Nakryiko @ 2019-07-09 17:50 UTC (permalink / raw)
To: Ilya Leoshkevich
Cc: bpf, Networking, Stanislav Fomichev, Y Song, David S. Miller,
Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <20190709151809.37539-1-iii@linux.ibm.com>
On Tue, Jul 9, 2019 at 8:18 AM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
>
> Use PT_REGS_RC(ctx) instead of ctx->rax, which is not present on s390.
>
> This patch series consists of three preparatory commits, which make it
> possible to use PT_REGS_RC in BPF selftests, followed by the actual fix.
>
> Since the last time, I've tested it with x86_64-linux-gnu-,
> aarch64-linux-gnu-, arm-linux-gnueabihf-, mips64el-linux-gnuabi64-,
> powerpc64le-linux-gnu-, s390x-linux-gnu- and sparc64-linux-gnu-
> compilers, and found that I also need to add arm64 support.
>
> Like s390, arm64 exports user_pt_regs instead of struct pt_regs to
> userspace.
>
> I've also made fixes for a few unrelated build problems, which I will
> post separately.
>
> v1->v2: Split into multiple patches.
> v2->v3: Added arm64 support.
>
> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
>
>
Acked-by: Andrii Nakryiko <andriin@fb.com>
^ 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