* [PATCH net-next 13/14] net: sched: mq: request stats from offloads
From: Jakub Kicinski @ 2018-05-26 4:53 UTC (permalink / raw)
To: davem
Cc: jiri, xiyou.wangcong, john.fastabend, netdev, oss-drivers,
alexei.starovoitov, nogahf, yuvalm, gerlitz.or, Jakub Kicinski
In-Reply-To: <20180526045338.10993-1-jakub.kicinski@netronome.com>
MQ doesn't hold any statistics on its own, however, statistic
from offloads are requested starting from the root, hence MQ
will read the old values for its sums. Call into the drivers,
because of the additive nature of the stats drivers are aware
of how much "pending updates" they have to children of the MQ.
Since MQ reset its stats on every dump we can simply offset
the stats, predicting how stats of offloaded children will
change.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
include/net/pkt_cls.h | 2 ++
net/sched/sch_mq.c | 18 ++++++++++++++++++
2 files changed, 20 insertions(+)
diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
index 942f839dbca4..a3c1a2c47cd4 100644
--- a/include/net/pkt_cls.h
+++ b/include/net/pkt_cls.h
@@ -781,11 +781,13 @@ struct tc_qopt_offload_stats {
enum tc_mq_command {
TC_MQ_CREATE,
TC_MQ_DESTROY,
+ TC_MQ_STATS,
};
struct tc_mq_qopt_offload {
enum tc_mq_command command;
u32 handle;
+ struct tc_qopt_offload_stats stats;
};
enum tc_red_command {
diff --git a/net/sched/sch_mq.c b/net/sched/sch_mq.c
index 6ccf6daa2503..d6b8ae4ed7a3 100644
--- a/net/sched/sch_mq.c
+++ b/net/sched/sch_mq.c
@@ -38,6 +38,22 @@ static int mq_offload(struct Qdisc *sch, enum tc_mq_command cmd)
return dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_QDISC_MQ, &opt);
}
+static void mq_offload_stats(struct Qdisc *sch)
+{
+ struct net_device *dev = qdisc_dev(sch);
+ struct tc_mq_qopt_offload opt = {
+ .command = TC_MQ_STATS,
+ .handle = sch->handle,
+ .stats = {
+ .bstats = &sch->bstats,
+ .qstats = &sch->qstats,
+ },
+ };
+
+ if (tc_can_offload(dev) && dev->netdev_ops->ndo_setup_tc)
+ dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_QDISC_MQ, &opt);
+}
+
static void mq_destroy(struct Qdisc *sch)
{
struct net_device *dev = qdisc_dev(sch);
@@ -146,6 +162,7 @@ static int mq_dump(struct Qdisc *sch, struct sk_buff *skb)
sch->q.qlen += qdisc->q.qlen;
sch->bstats.bytes += qdisc->bstats.bytes;
sch->bstats.packets += qdisc->bstats.packets;
+ sch->qstats.qlen += qdisc->qstats.qlen;
sch->qstats.backlog += qdisc->qstats.backlog;
sch->qstats.drops += qdisc->qstats.drops;
sch->qstats.requeues += qdisc->qstats.requeues;
@@ -154,6 +171,7 @@ static int mq_dump(struct Qdisc *sch, struct sk_buff *skb)
spin_unlock_bh(qdisc_lock(qdisc));
}
+ mq_offload_stats(sch);
return 0;
}
--
2.17.0
^ permalink raw reply related
* [PATCH net-next 14/14] nfp: abm: report correct MQ stats
From: Jakub Kicinski @ 2018-05-26 4:53 UTC (permalink / raw)
To: davem
Cc: jiri, xiyou.wangcong, john.fastabend, netdev, oss-drivers,
alexei.starovoitov, nogahf, yuvalm, gerlitz.or, Jakub Kicinski
In-Reply-To: <20180526045338.10993-1-jakub.kicinski@netronome.com>
Report the stat diff to make sure MQ stats add up to child stats.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
drivers/net/ethernet/netronome/nfp/abm/main.c | 24 +++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/net/ethernet/netronome/nfp/abm/main.c b/drivers/net/ethernet/netronome/nfp/abm/main.c
index 21d5af1fb061..1561c2724c26 100644
--- a/drivers/net/ethernet/netronome/nfp/abm/main.c
+++ b/drivers/net/ethernet/netronome/nfp/abm/main.c
@@ -279,6 +279,28 @@ nfp_abm_setup_tc_red(struct net_device *netdev, struct nfp_abm_link *alink,
}
}
+static int
+nfp_abm_mq_stats(struct nfp_abm_link *alink, struct tc_mq_qopt_offload *opt)
+{
+ struct nfp_alink_stats stats;
+ unsigned int i;
+ int err;
+
+ for (i = 0; i < alink->num_qdiscs; i++) {
+ if (alink->qdiscs[i].handle == TC_H_UNSPEC)
+ continue;
+
+ err = nfp_abm_ctrl_read_q_stats(alink, i, &stats);
+ if (err)
+ return err;
+
+ nfp_abm_update_stats(&stats, &alink->qdiscs[i].stats,
+ &opt->stats);
+ }
+
+ return 0;
+}
+
static int
nfp_abm_setup_tc_mq(struct net_device *netdev, struct nfp_abm_link *alink,
struct tc_mq_qopt_offload *opt)
@@ -292,6 +314,8 @@ nfp_abm_setup_tc_mq(struct net_device *netdev, struct nfp_abm_link *alink,
if (opt->handle == alink->parent)
nfp_abm_reset_root(netdev, alink, TC_H_ROOT, 0);
return 0;
+ case TC_MQ_STATS:
+ return nfp_abm_mq_stats(alink, opt);
default:
return -EOPNOTSUPP;
}
--
2.17.0
^ permalink raw reply related
* Re: [bpf-next PATCH] bpf: sockhash fix race with bpf_tcp_close and map delete
From: Song Liu @ 2018-05-26 6:07 UTC (permalink / raw)
To: John Fastabend; +Cc: ast, daniel, netdev
In-Reply-To: <20180525173712.4004.70590.stgit@john-Precision-Tower-5810>
On Fri, May 25, 2018 at 10:37 AM, John Fastabend
<john.fastabend@gmail.com> wrote:
> syzbot reported two related splats, a use after free and null
> pointer dereference, when a TCP socket is closed while the map is
> also being removed.
>
> The psock keeps a reference to all map slots that have a reference
> to the sock so that when the sock is closed we can clean up any
> outstanding sock{map|hash} entries. This avoids pinning a sock
> forever if the map owner fails to do proper cleanup. However, the
> result is we have two paths that can free an entry in the map. Even
> the comment in the sock{map|hash} tear down function, sock_hash_free()
> notes this:
>
> At this point no update, lookup or delete operations can happen.
> However, be aware we can still get a socket state event updates,
> and data ready callbacks that reference the psock from sk_user_data.
>
> Both removal paths omitted taking the hash bucket lock resulting
> in the case where we have two references that are in the process
> of being free'd.
>
> Reported-by: syzbot+a761b81c211794fa1072@syzkaller.appspotmail.com
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Song Liu <songliubraving@fb.com>
> ---
> kernel/bpf/sockmap.c | 33 +++++++++++++++++++++------------
> 1 file changed, 21 insertions(+), 12 deletions(-)
>
> diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
> index 52a91d8..b508141f 100644
> --- a/kernel/bpf/sockmap.c
> +++ b/kernel/bpf/sockmap.c
> @@ -225,6 +225,16 @@ static void free_htab_elem(struct bpf_htab *htab, struct htab_elem *l)
> kfree_rcu(l, rcu);
> }
>
> +static inline struct bucket *__select_bucket(struct bpf_htab *htab, u32 hash)
> +{
> + return &htab->buckets[hash & (htab->n_buckets - 1)];
> +}
> +
> +static inline struct hlist_head *select_bucket(struct bpf_htab *htab, u32 hash)
> +{
> + return &__select_bucket(htab, hash)->head;
> +}
> +
> static void bpf_tcp_close(struct sock *sk, long timeout)
> {
> void (*close_fun)(struct sock *sk, long timeout);
> @@ -268,9 +278,15 @@ static void bpf_tcp_close(struct sock *sk, long timeout)
> smap_release_sock(psock, sk);
> }
> } else {
> + u32 hash = e->hash_link->hash;
> + struct bucket *b;
> +
> + b = __select_bucket(e->htab, hash);
> + raw_spin_lock_bh(&b->lock);
> hlist_del_rcu(&e->hash_link->hash_node);
> smap_release_sock(psock, e->hash_link->sk);
> free_htab_elem(e->htab, e->hash_link);
> + raw_spin_unlock_bh(&b->lock);
> }
> }
> write_unlock_bh(&sk->sk_callback_lock);
> @@ -2043,16 +2059,6 @@ static struct bpf_map *sock_hash_alloc(union bpf_attr *attr)
> return ERR_PTR(err);
> }
>
> -static inline struct bucket *__select_bucket(struct bpf_htab *htab, u32 hash)
> -{
> - return &htab->buckets[hash & (htab->n_buckets - 1)];
> -}
> -
> -static inline struct hlist_head *select_bucket(struct bpf_htab *htab, u32 hash)
> -{
> - return &__select_bucket(htab, hash)->head;
> -}
> -
> static void sock_hash_free(struct bpf_map *map)
> {
> struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
> @@ -2069,10 +2075,12 @@ static void sock_hash_free(struct bpf_map *map)
> */
> rcu_read_lock();
> for (i = 0; i < htab->n_buckets; i++) {
> - struct hlist_head *head = select_bucket(htab, i);
> + struct bucket *b = __select_bucket(htab, i);
> + struct hlist_head *head = &b->head;
> struct hlist_node *n;
> struct htab_elem *l;
>
> + raw_spin_lock_bh(&b->lock);
> hlist_for_each_entry_safe(l, n, head, hash_node) {
> struct sock *sock = l->sk;
> struct smap_psock *psock;
> @@ -2090,8 +2098,9 @@ static void sock_hash_free(struct bpf_map *map)
> smap_release_sock(psock, sock);
> }
> write_unlock_bh(&sock->sk_callback_lock);
> - kfree(l);
> + free_htab_elem(htab, l);
> }
> + raw_spin_unlock_bh(&b->lock);
> }
> rcu_read_unlock();
> bpf_map_area_free(htab->buckets);
>
^ permalink raw reply
* Re: [PATCH] net: netsec: reduce DMA mask to 40 bits
From: Ard Biesheuvel @ 2018-05-26 6:16 UTC (permalink / raw)
To: Jassi Brar
Cc: Robin Murphy, <netdev@vger.kernel.org>, David S. Miller,
Masahisa Kojima, Ilias Apalodimas, nd
In-Reply-To: <CAJe_ZhfJFdS-CWtGGuaejvVm=pb4i5YpYE9XUQPViO9ucbgkZA@mail.gmail.com>
On 26 May 2018 at 05:44, Jassi Brar <jaswinder.singh@linaro.org> wrote:
> On 26 May 2018 at 08:56, Jassi Brar <jaswinder.singh@linaro.org> wrote:
>> On 26 May 2018 at 01:07, Robin Murphy <robin.murphy@arm.com> wrote:
>>> On Sat, 26 May 2018 00:33:05 +0530
>>> Jassi Brar <jaswinder.singh@linaro.org> wrote:
>>>
>>>> On 25 May 2018 at 18:20, Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>>> wrote:
>>>> > The netsec network controller IP can drive 64 address bits for DMA,
>>>> > and the DMA mask is set accordingly in the driver. However, the
>>>> > SynQuacer SoC, which is the only silicon incorporating this IP at
>>>> > the moment, integrates this IP in a manner that leaves address bits
>>>> > [63:40] unconnected.
>>>> >
>>>> > Up until now, this has not resulted in any problems, given that the
>>>> > DDR controller doesn't decode those bits to begin with. However,
>>>> > recent firmware updates for platforms incorporating this SoC allow
>>>> > the IOMMU to be enabled, which does decode address bits [47:40],
>>>> > and allocates top down from the IOVA space, producing DMA addresses
>>>> > that have bits set that have been left unconnected.
>>>> >
>>>> > Both the DT and ACPI (IORT) descriptions of the platform take this
>>>> > into account, and only describe a DMA address space of 40 bits
>>>> > (using either dma-ranges DT properties, or DMA address limits in
>>>> > IORT named component nodes). However, even though our IOMMU and bus
>>>> > layers may take such limitations into account by setting a narrower
>>>> > DMA mask when creating the platform device, the netsec probe()
>>>> > entrypoint follows the common practice of setting the DMA mask
>>>> > uncondionally, according to the capabilities of the IP block itself
>>>> > rather than to its integration into the chip.
>>>> >
>>>> > It is currently unclear what the correct fix is here. We could hack
>>>> > around it by only setting the DMA mask if it deviates from its
>>>> > default value of DMA_BIT_MASK(32). However, this makes it
>>>> > impossible for the bus layer to use DMA_BIT_MASK(32) as the bus
>>>> > limit, and so it appears that a more comprehensive approach is
>>>> > required to take DMA limits imposed by the SoC as a whole into
>>>> > account.
>>>> >
>>>> > In the mean time, let's limit the DMA mask to 40 bits. Given that
>>>> > there is currently only one SoC that incorporates this IP, this is
>>>> > a reasonable approach that can be backported to -stable and buys us
>>>> > some time to come up with a proper fix going forward.
>>>> >
>>>> I am sure you already thought about it, but why not let the platform
>>>> specify the bit mask for the driver (via some "bus-width" property),
>>>> to override the default 64 bit mask?
>>>
>>> Because lack of a property to describe the integration is not the
>>> problem. There are already at least two ways: the general DT/IORT
>>> properties for describing DMA addressing - which it would be a bit
>>> ungainly for a driver to parse for this reason, but not impossible -
>> ....
>>
>>
>>> and inferring it from a SoC-specific compatible - which is more
>>> appropriate, and what we happen to be able to do here.
>>>
>> Sorry, I am not sure I follow. This patch changes from 64-bits default
>> to 40-bits capability without checking for the parent SoC. If the next
>> generation implements the full 64-bit or just 32-bit bus, we'll be
>> back in the pit again. No?
>>
> Probably you meant we'll change the ethernet compatible string for
> differently capable SoC. OK, but here it is more of integration issue
> than controller version.
>
> Which makes me realise the extant compatible property for netsec is
> not so correct (it embeds the platform name). So I am ok either way.
>
The platform in question has a dma-ranges DT property at the root
level that only describes 40 bits' worth of DMA. Also, the ACPI
description in the IORT table of the IOMMU integration of the netsec
controller limits DMA to 40 bits. In the latter case, we actually
enter netsec_probe() with the correct value already assigned to the
DMA mask fields. (In the former case, the DMA limit is ignored
entirely)
In other words, we can already describe these SoC limitations and
distinguish them from device limitations. The problem is that drivers
ignore the existing values of DMA mask.
Robin has volunteered to look into fixing this, but this cannot be
done in a way that is suitable for -stable. In the mean time, we have
a single platform using this network IP in the field that cannot
upgrade its firmware to a version that describes the IOMMU, because
the existing DMA layer code will start driving address bits that are
correctly described as unconnected by the DT/ACPI tables.
So as a a workaround, until Robin fixes things properly, let's reduce
the DMA mask to 40 bits.
^ permalink raw reply
* Re: aio poll and a new in-kernel poll API V13
From: Al Viro @ 2018-05-26 7:09 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180526001111.GL30522@ZenIV.linux.org.uk>
On Sat, May 26, 2018 at 01:11:11AM +0100, Al Viro wrote:
> On Wed, May 23, 2018 at 09:19:49PM +0200, Christoph Hellwig wrote:
> > Hi all,
> >
> > this series adds support for the IOCB_CMD_POLL operation to poll for the
> > readyness of file descriptors using the aio subsystem. The API is based
> > on patches that existed in RHAS2.1 and RHEL3, which means it already is
> > supported by libaio. To implement the poll support efficiently new
> > methods to poll are introduced in struct file_operations: get_poll_head
> > and poll_mask. The first one returns a wait_queue_head to wait on
> > (lifetime is bound by the file), and the second does a non-blocking
> > check for the POLL* events. This allows aio poll to work without
> > any additional context switches, unlike epoll.
> >
> > This series sits on top of the aio-fsync series that also includes
> > support for io_pgetevents.
>
> OK, I can live with that, except for one problem - the first patch shouldn't
> be sitting on top of arseloads of next window fodder.
>
> Please, rebase the rest of the series on top of merge of vfs.git#fixes
> (4faa99965e02) with your aio-fsync.4 and tell me what to pull.
UGH
You've based it on vfs.git#hch.aio (== your aio-fsync.4) + baf10564fbb6
(== vfs.git#fixes^), *and* started with cherry-pick of vfs.git#fixes
on top of that, followed by your series.
That makes no sense whatsoever. Please, take your aio-fsync.4, merge
vfs.git#fixes (== 4faa99965e02, "fix io_destroy()/aio_complete() race",
same change as your 4e79230e5254) into it and rebase the rest of your
branch on top of that (from "uapi: turn __poll_t sparse checkin
on by default" to "random: convert to ->poll_mask"). BTW, you probably
want s/checkin/checks/ in the first one of those...
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: [PATCH net-next v12 2/5] netvsc: refactor notifier/event handling code to use the failover framework
From: Samudrala, Sridhar @ 2018-05-26 7:22 UTC (permalink / raw)
To: Stephen Hemminger
Cc: mst, davem, netdev, virtualization, virtio-dev, jesse.brandeburg,
alexander.h.duyck, kubakici, jasowang, loseweigh, jiri,
aaron.f.brown, anjali.singhai
In-Reply-To: <20180525162839.3c7028e1@xeon-e3>
On 5/25/2018 4:28 PM, Stephen Hemminger wrote:
> On Fri, 25 May 2018 16:11:47 -0700
> "Samudrala, Sridhar" <sridhar.samudrala@intel.com> wrote:
>
>> On 5/25/2018 3:34 PM, Stephen Hemminger wrote:
>>> On Thu, 24 May 2018 09:55:14 -0700
>>> Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
>>>
>>>> --- a/drivers/net/hyperv/Kconfig
>>>> +++ b/drivers/net/hyperv/Kconfig
>>>> @@ -2,5 +2,6 @@ config HYPERV_NET
>>>> tristate "Microsoft Hyper-V virtual network driver"
>>>> depends on HYPERV
>>>> select UCS2_STRING
>>>> + select FAILOVER
>>> When I take a working kernel config, add the patches then do
>>> make oldconfig
>>>
>>> It is not autoselecting FAILOVER, it prompts me for it. This means
>>> if user says no then a non-working netvsc device is made.
>> I see
>> Generic failover module (FAILOVER) [M/y/?] (NEW)
>>
>> So the user is given an option to either build as a Module or part of the
>> kernel. 'n' is not an option.
> With most libraries there is no prompt at all.
Not sure what you meant by this.
Without any patches applied, i had a .config file with HYPERV_NET configured
as a module.
Then after applying the first 2 patches in this series, i did a
make oldconfig
and i see the above prompt.
Are you saying that on some distros, 'make oldconfig creates a .config
file without any prompt and FAILOVER is not getting selected even when HYPERV_NET
is enabled?
^ permalink raw reply
* Re: aio poll and a new in-kernel poll API V13
From: Christoph Hellwig @ 2018-05-26 7:23 UTC (permalink / raw)
To: Al Viro
Cc: Christoph Hellwig, Avi Kivity, linux-aio, linux-fsdevel, netdev,
linux-api, linux-kernel
In-Reply-To: <20180526070937.GA4188@ZenIV.linux.org.uk>
I'm still waking up..
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: [PATCH net-next] bpfilter: fix a build err
From: Yafang Shao @ 2018-05-26 7:41 UTC (permalink / raw)
To: YueHaibing; +Cc: Alexei Starovoitov, David Miller, ast, netdev, LKML
In-Reply-To: <176ee190-ecda-9b3e-5066-ecf3fbaf32bb@huawei.com>
On Sat, May 26, 2018 at 10:25 AM, YueHaibing <yuehaibing@huawei.com> wrote:
> On 2018/5/26 0:19, Alexei Starovoitov wrote:
>> On Fri, May 25, 2018 at 06:17:57PM +0800, YueHaibing wrote:
>>> gcc-7.3.0 report following err:
>>>
>>> HOSTCC net/bpfilter/main.o
>>> In file included from net/bpfilter/main.c:9:0:
>>> ./include/uapi/linux/bpf.h:12:10: fatal error: linux/bpf_common.h: No such file or directory
>>> #include <linux/bpf_common.h>
>>>
>>> remove it by adding a include path.
>>> Fixes: d2ba09c17a06 ("net: add skeleton of bpfilter kernel module")
>>>
>>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>>> ---
>>> net/bpfilter/Makefile | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/net/bpfilter/Makefile b/net/bpfilter/Makefile
>>> index 2af752c..3f3cb87 100644
>>> --- a/net/bpfilter/Makefile
>>> +++ b/net/bpfilter/Makefile
>>> @@ -5,7 +5,7 @@
>>>
>>> hostprogs-y := bpfilter_umh
>>> bpfilter_umh-objs := main.o
>>> -HOSTCFLAGS += -I. -Itools/include/
>>> +HOSTCFLAGS += -I. -Itools/include/ -Itools/include/uapi
>>
>> Strangely I don't see this error with gcc 7.3
>> I've tried this patch and it doesn't hurt,
>> but before it gets applied could you please try
>> the top two patches from this tree:
>> https://git.kernel.org/pub/scm/linux/kernel/git/ast/bpf.git/?h=ipt_bpf
>> in your environment?
>> These two patches add the actual meat of bpfilter and I'd like
>> to make sure the build setup is good for everyone before
>> we proceed too far.
>
> after applied these two patches on net-next, the err still here:
> bpfilter: rough bpfilter codegen example hack
> bpfilter: add iptable get/set parsing
>
> HOSTCC net/bpfilter/main.o
> In file included from net/bpfilter/main.c:13:0:
> ./include/uapi/linux/bpf.h:12:10: fatal error: linux/bpf_common.h: No such file or directory
> #include <linux/bpf_common.h>
> ^~~~~~~~~~~~~~~~~~~~
> compilation terminated.
> make[2]: *** [net/bpfilter/main.o] Error 1
> make[1]: *** [net/bpfilter] Error 2
> make: *** [net] Error 2
>
> Also I compile your tree, error is same
>
> my gcc version info as follow:
> [root@localhost net-next]# gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/home/yuehb/gcc-7.3.0-tools/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/lto-wrapper
> Target: x86_64-pc-linux-gnu
> Configured with: ../gcc-7.3.0/configure --enable-checking=release --enable-languages=c,c++
> --disable-multilib --prefix=/home/yuehb/gcc-7.3.0-tools
> Thread model: posix
> gcc version 7.3.0 (GCC)
>
>>
This error also occurs on gcc-4.8.5.
After applied Haibin's patch, this build error disapears.
Thanks
Yafang
^ permalink raw reply
* Re: [PATCH net-next v12 1/5] net: Introduce generic failover module
From: Jiri Pirko @ 2018-05-26 7:43 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Sridhar Samudrala, mst, davem, netdev, virtualization, virtio-dev,
jesse.brandeburg, alexander.h.duyck, kubakici, jasowang,
loseweigh, aaron.f.brown, anjali.singhai
In-Reply-To: <20180525153744.2b53c449@xeon-e3>
Sat, May 26, 2018 at 12:37:44AM CEST, stephen@networkplumber.org wrote:
>On Thu, 24 May 2018 09:55:13 -0700
>Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
>
>
>> + spin_lock(&failover_lock);
>
>Since register is not in fast path, this should be a mutex?
I don't get it. Why would you prefer mutex over spinlock here?
^ permalink raw reply
* Re: [PATCH net-next v12 2/5] netvsc: refactor notifier/event handling code to use the failover framework
From: Jiri Pirko @ 2018-05-26 7:51 UTC (permalink / raw)
To: Samudrala, Sridhar
Cc: alexander.h.duyck, virtio-dev, mst, kubakici, netdev,
virtualization, loseweigh, anjali.singhai, aaron.f.brown, davem
In-Reply-To: <cffe3c66-ae31-ae13-27ce-55f9be2d53d4@intel.com>
Sat, May 26, 2018 at 09:22:18AM CEST, sridhar.samudrala@intel.com wrote:
>On 5/25/2018 4:28 PM, Stephen Hemminger wrote:
>> On Fri, 25 May 2018 16:11:47 -0700
>> "Samudrala, Sridhar" <sridhar.samudrala@intel.com> wrote:
>>
>> > On 5/25/2018 3:34 PM, Stephen Hemminger wrote:
>> > > On Thu, 24 May 2018 09:55:14 -0700
>> > > Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
>> > > > --- a/drivers/net/hyperv/Kconfig
>> > > > +++ b/drivers/net/hyperv/Kconfig
>> > > > @@ -2,5 +2,6 @@ config HYPERV_NET
>> > > > tristate "Microsoft Hyper-V virtual network driver"
>> > > > depends on HYPERV
>> > > > select UCS2_STRING
>> > > > + select FAILOVER
>> > > When I take a working kernel config, add the patches then do
>> > > make oldconfig
>> > >
>> > > It is not autoselecting FAILOVER, it prompts me for it. This means
>> > > if user says no then a non-working netvsc device is made.
>> > I see
>> > Generic failover module (FAILOVER) [M/y/?] (NEW)
>> >
>> > So the user is given an option to either build as a Module or part of the
>> > kernel. 'n' is not an option.
>> With most libraries there is no prompt at all.
>
>Not sure what you meant by this.
>Without any patches applied, i had a .config file with HYPERV_NET configured
>as a module.
>Then after applying the first 2 patches in this series, i did a
> make oldconfig
>and i see the above prompt.
>
>Are you saying that on some distros, 'make oldconfig creates a .config
>file without any prompt and FAILOVER is not getting selected even when HYPERV_NET
>is enabled?
>
>
Well the thing is that for a user, it makes no sense to select
"FAILOVER" by hand. It is a lib, so it should be only select it by a
user. It has no sense to have it turned on by hand - no lib user.
You can achieve that by simply removing "help" for the Kconfig
item. Same thing for "NET_FAILOVER".
^ permalink raw reply
* Re: WARNING: ODEBUG bug in __sk_destruct
From: syzbot @ 2018-05-26 7:52 UTC (permalink / raw)
To: davem, linux-kernel, linux-s390, netdev, syzkaller-bugs, ubraun
In-Reply-To: <000000000000451f9d056aff4397@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: e52cde717093 net: dsa: dsa_loop: Make dynamic debugging he..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1424a4b7800000
kernel config: https://syzkaller.appspot.com/x/.config?x=e4078980b886800c
dashboard link: https://syzkaller.appspot.com/bug?extid=92209502e7aab127c75f
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1071bc2f800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16b51cb7800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+92209502e7aab127c75f@syzkaller.appspotmail.com
------------[ cut here ]------------
ODEBUG: free active (active state 0) object type: work_struct hint:
smc_tx_work+0x0/0x350 include/linux/compiler.h:188
WARNING: CPU: 0 PID: 5254 at lib/debugobjects.c:329
debug_print_object+0x16a/0x210 lib/debugobjects.c:326
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 5254 Comm: syz-executor351 Not tainted 4.17.0-rc6+ #64
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
panic+0x22f/0x4de kernel/panic.c:184
__warn.cold.8+0x163/0x1b3 kernel/panic.c:536
report_bug+0x252/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:debug_print_object+0x16a/0x210 lib/debugobjects.c:326
RSP: 0018:ffff8801c6f67158 EFLAGS: 00010082
RAX: 0000000000000059 RBX: 0000000000000003 RCX: ffffffff818435f8
RDX: 0000000000000000 RSI: ffffffff8160f2c1 RDI: 0000000000000001
RBP: ffff8801c6f67198 R08: ffff8801cb640580 R09: ffffed003b5c3eb2
R10: ffffed003b5c3eb2 R11: ffff8801dae1f597 R12: 0000000000000001
R13: ffffffff88d5f040 R14: ffffffff87fa2a00 R15: ffffffff814ccb10
__debug_check_no_obj_freed lib/debugobjects.c:783 [inline]
debug_check_no_obj_freed+0x3a6/0x584 lib/debugobjects.c:815
kmem_cache_free+0x216/0x2d0 mm/slab.c:3755
sk_prot_free net/core/sock.c:1516 [inline]
__sk_destruct+0x6fe/0xa40 net/core/sock.c:1600
sk_destruct+0x78/0x90 net/core/sock.c:1608
__sk_free+0xcf/0x300 net/core/sock.c:1619
sk_free+0x42/0x50 net/core/sock.c:1630
sock_put include/net/sock.h:1669 [inline]
smc_release+0x459/0x610 net/smc/af_smc.c:156
sock_release+0x96/0x1b0 net/socket.c:594
sock_close+0x16/0x20 net/socket.c:1149
__fput+0x34d/0x890 fs/file_table.c:209
____fput+0x15/0x20 fs/file_table.c:243
task_work_run+0x1e4/0x290 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x1aee/0x2730 kernel/exit.c:865
do_group_exit+0x16f/0x430 kernel/exit.c:968
__do_sys_exit_group kernel/exit.c:979 [inline]
__se_sys_exit_group kernel/exit.c:977 [inline]
__x64_sys_exit_group+0x3e/0x50 kernel/exit.c:977
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4424f9
RSP: 002b:00007ffcbea55c78 EFLAGS: 00000202 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 00000000000002c0 RCX: 00000000004424f9
RDX: 00000000004424f9 RSI: 0000000000000001 RDI: 0000000000000000
RBP: 00007ffcbea55db0 R08: 0000000300000000 R09: 00007ffcbea55cc0
R10: 0000000000000004 R11: 0000000000000202 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000001380 R15: 00007ffcbea55dd8
======================================================
WARNING: possible circular locking dependency detected
4.17.0-rc6+ #64 Not tainted
------------------------------------------------------
syz-executor351/5254 is trying to acquire lock:
(ptrval) ((console_sem).lock){-...}, at: down_trylock+0x13/0x70
kernel/locking/semaphore.c:136
but task is already holding lock:
(ptrval) (&obj_hash[i].lock){-.-.}, at: __debug_check_no_obj_freed
lib/debugobjects.c:774 [inline]
(ptrval) (&obj_hash[i].lock){-.-.}, at:
debug_check_no_obj_freed+0x159/0x584 lib/debugobjects.c:815
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (&obj_hash[i].lock){-.-.}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
__debug_object_init+0x11f/0x12c0 lib/debugobjects.c:381
debug_object_init+0x16/0x20 lib/debugobjects.c:429
debug_hrtimer_init kernel/time/hrtimer.c:410 [inline]
debug_init kernel/time/hrtimer.c:458 [inline]
hrtimer_init+0x8f/0x460 kernel/time/hrtimer.c:1308
init_dl_task_timer+0x1b/0x50 kernel/sched/deadline.c:1056
__sched_fork+0x2ae/0xc20 kernel/sched/core.c:2166
init_idle+0x75/0x7a0 kernel/sched/core.c:5402
sched_init+0xbeb/0xd10 kernel/sched/core.c:6100
start_kernel+0x475/0x92d init/main.c:601
x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:453
x86_64_start_kernel+0x76/0x79 arch/x86/kernel/head64.c:434
secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:242
-> #2 (&rq->lock){-.-.}:
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:144
rq_lock kernel/sched/sched.h:1799 [inline]
task_fork_fair+0x8a/0x660 kernel/sched/fair.c:9912
sched_fork+0x43e/0xb30 kernel/sched/core.c:2382
copy_process.part.38+0x1c18/0x6e90 kernel/fork.c:1764
copy_process kernel/fork.c:1607 [inline]
_do_fork+0x291/0x12a0 kernel/fork.c:2088
kernel_thread+0x34/0x40 kernel/fork.c:2147
rest_init+0x22/0xe4 init/main.c:407
start_kernel+0x906/0x92d init/main.c:737
x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:453
x86_64_start_kernel+0x76/0x79 arch/x86/kernel/head64.c:434
secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:242
-> #1 (&p->pi_lock){-.-.}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
try_to_wake_up+0xca/0x1190 kernel/sched/core.c:1966
wake_up_process+0x10/0x20 kernel/sched/core.c:2129
__up.isra.1+0x1b8/0x290 kernel/locking/semaphore.c:262
up+0x12f/0x1b0 kernel/locking/semaphore.c:187
__up_console_sem+0xbe/0x1b0 kernel/printk/printk.c:242
console_unlock+0x7d6/0x1100 kernel/printk/printk.c:2417
do_con_write+0x12b2/0x2280 drivers/tty/vt/vt.c:2437
con_write+0x25/0xc0 drivers/tty/vt/vt.c:2786
process_output_block drivers/tty/n_tty.c:579 [inline]
n_tty_write+0x6b9/0x1180 drivers/tty/n_tty.c:2308
do_tty_write drivers/tty/tty_io.c:958 [inline]
tty_write+0x3f1/0x880 drivers/tty/tty_io.c:1042
__vfs_write+0x10b/0x960 fs/read_write.c:485
vfs_write+0x1f8/0x560 fs/read_write.c:549
ksys_write+0xf9/0x250 fs/read_write.c:598
__do_sys_write fs/read_write.c:610 [inline]
__se_sys_write fs/read_write.c:607 [inline]
__x64_sys_write+0x73/0xb0 fs/read_write.c:607
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #0 ((console_sem).lock){-...}:
lock_acquire+0x1dc/0x520 kernel/locking/lockdep.c:3920
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
down_trylock+0x13/0x70 kernel/locking/semaphore.c:136
__down_trylock_console_sem+0xae/0x200 kernel/printk/printk.c:225
console_trylock+0x15/0xa0 kernel/printk/printk.c:2229
console_trylock_spinning kernel/printk/printk.c:1643 [inline]
vprintk_emit+0x694/0xdd0 kernel/printk/printk.c:1906
vprintk_default+0x28/0x30 kernel/printk/printk.c:1947
vprintk_func+0x7a/0xe7 kernel/printk/printk_safe.c:379
printk+0x9e/0xba kernel/printk/printk.c:1980
__warn_printk+0x83/0xd0 kernel/panic.c:590
debug_print_object+0x16a/0x210 lib/debugobjects.c:326
__debug_check_no_obj_freed lib/debugobjects.c:783 [inline]
debug_check_no_obj_freed+0x3a6/0x584 lib/debugobjects.c:815
kmem_cache_free+0x216/0x2d0 mm/slab.c:3755
sk_prot_free net/core/sock.c:1516 [inline]
__sk_destruct+0x6fe/0xa40 net/core/sock.c:1600
sk_destruct+0x78/0x90 net/core/sock.c:1608
__sk_free+0xcf/0x300 net/core/sock.c:1619
sk_free+0x42/0x50 net/core/sock.c:1630
sock_put include/net/sock.h:1669 [inline]
smc_release+0x459/0x610 net/smc/af_smc.c:156
sock_release+0x96/0x1b0 net/socket.c:594
sock_close+0x16/0x20 net/socket.c:1149
__fput+0x34d/0x890 fs/file_table.c:209
____fput+0x15/0x20 fs/file_table.c:243
task_work_run+0x1e4/0x290 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x1aee/0x2730 kernel/exit.c:865
do_group_exit+0x16f/0x430 kernel/exit.c:968
__do_sys_exit_group kernel/exit.c:979 [inline]
__se_sys_exit_group kernel/exit.c:977 [inline]
__x64_sys_exit_group+0x3e/0x50 kernel/exit.c:977
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
other info that might help us debug this:
Chain exists of:
(console_sem).lock --> &rq->lock --> &obj_hash[i].lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&obj_hash[i].lock);
lock(&rq->lock);
lock(&obj_hash[i].lock);
lock((console_sem).lock);
*** DEADLOCK ***
1 lock held by syz-executor351/5254:
#0: (ptrval) (&obj_hash[i].lock){-.-.}, at:
__debug_check_no_obj_freed lib/debugobjects.c:774 [inline]
#0: (ptrval) (&obj_hash[i].lock){-.-.}, at:
debug_check_no_obj_freed+0x159/0x584 lib/debugobjects.c:815
stack backtrace:
CPU: 0 PID: 5254 Comm: syz-executor351 Not tainted 4.17.0-rc6+ #64
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
print_circular_bug.isra.36.cold.54+0x1bd/0x27d
kernel/locking/lockdep.c:1223
check_prev_add kernel/locking/lockdep.c:1863 [inline]
check_prevs_add kernel/locking/lockdep.c:1976 [inline]
validate_chain kernel/locking/lockdep.c:2417 [inline]
__lock_acquire+0x343e/0x5140 kernel/locking/lockdep.c:3431
lock_acquire+0x1dc/0x520 kernel/locking/lockdep.c:3920
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
down_trylock+0x13/0x70 kernel/locking/semaphore.c:136
__down_trylock_console_sem+0xae/0x200 kernel/printk/printk.c:225
console_trylock+0x15/0xa0 kernel/printk/printk.c:2229
console_trylock_spinning kernel/printk/printk.c:1643 [inline]
vprintk_emit+0x694/0xdd0 kernel/printk/printk.c:1906
vprintk_default+0x28/0x30 kernel/printk/printk.c:1947
vprintk_func+0x7a/0xe7 kernel/printk/printk_safe.c:379
printk+0x9e/0xba kernel/printk/printk.c:1980
__warn_printk+0x83/0xd0 kernel/panic.c:590
debug_print_object+0x16a/0x210 lib/debugobjects.c:326
__debug_check_no_obj_freed lib/debugobjects.c:783 [inline]
debug_check_no_obj_freed+0x3a6/0x584 lib/debugobjects.c:815
kmem_cache_free+0x216/0x2d0 mm/slab.c:3755
sk_prot_free net/core/sock.c:1516 [inline]
__sk_destruct+0x6fe/0xa40 net/core/sock.c:1600
sk_destruct+0x78/0x90 net/core/sock.c:1608
__sk_free+0xcf/0x300 net/core/sock.c:1619
sk_free+0x42/0x50 net/core/sock.c:1630
sock_put include/net/sock.h:1669 [inline]
smc_release+0x459/0x610 net/smc/af_smc.c:156
sock_release+0x96/0x1b0 net/socket.c:594
sock_close+0x16/0x20 net/socket.c:1149
__fput+0x34d/0x890 fs/file_table.c:209
____fput+0x15/0x20 fs/file_table.c:243
task_work_run+0x1e4/0x290 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x1aee/0x2730 kernel/exit.c:865
do_group_exit+0x16f/0x430 kernel/exit.c:968
__do_sys_exit_group kernel/exit.c:979 [inline]
__se_sys_exit_group kernel/exit.c:977 [inline]
__x64_sys_exit_group+0x3e/0x50 kernel/exit.c:977
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4424f9
RSP: 002b:00007ffcbea55c78 EFLAGS: 00000202 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 00000000000002c0 RCX: 00000000004424f9
RDX: 00000000004424f9 RSI: 0000000000000001 RDI: 0000000000000000
RBP: 00007ffcbea55db0 R08: 000000030
Lost 2 message(s)!
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
^ permalink raw reply
* Re: [bpf-next PATCH] bpf: sockhash fix race with bpf_tcp_close and map delete
From: Daniel Borkmann @ 2018-05-26 8:30 UTC (permalink / raw)
To: John Fastabend, ast; +Cc: netdev
In-Reply-To: <20180525173712.4004.70590.stgit@john-Precision-Tower-5810>
Hi John,
On 05/25/2018 07:37 PM, John Fastabend wrote:
> syzbot reported two related splats, a use after free and null
> pointer dereference, when a TCP socket is closed while the map is
> also being removed.
>
> The psock keeps a reference to all map slots that have a reference
> to the sock so that when the sock is closed we can clean up any
> outstanding sock{map|hash} entries. This avoids pinning a sock
> forever if the map owner fails to do proper cleanup. However, the
> result is we have two paths that can free an entry in the map. Even
> the comment in the sock{map|hash} tear down function, sock_hash_free()
> notes this:
>
> At this point no update, lookup or delete operations can happen.
> However, be aware we can still get a socket state event updates,
> and data ready callbacks that reference the psock from sk_user_data.
>
> Both removal paths omitted taking the hash bucket lock resulting
> in the case where we have two references that are in the process
> of being free'd.
>
> Reported-by: syzbot+a761b81c211794fa1072@syzkaller.appspotmail.com
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Could you also shortly reply with a Fixes: tag so we can track all
fixes for the original commit.
Thanks,
Daniel
P.s.: still waiting on net-next to get fast-forwarded, then I'll
fast-forward bpf-next and process the queue.
^ permalink raw reply
* KASAN: use-after-free Read in bpf_tcp_close
From: syzbot @ 2018-05-26 8:54 UTC (permalink / raw)
To: ast, daniel, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 3fb48d881dbe Merge branch 'bpf-fib-mtu-check'
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=15fc1977800000
kernel config: https://syzkaller.appspot.com/x/.config?x=b632d8e2c2ab2c1
dashboard link: https://syzkaller.appspot.com/bug?extid=fce8f2462c403d02af98
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1310c857800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17de7177800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+fce8f2462c403d02af98@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in hlist_del_rcu include/linux/rculist.h:427
[inline]
BUG: KASAN: use-after-free in bpf_tcp_close+0xd7f/0xf80
kernel/bpf/sockmap.c:271
Read of size 8 at addr ffff8801c884cf90 by task syz-executor330/11778
CPU: 1 PID: 11778 Comm: syz-executor330 Not tainted 4.17.0-rc4+ #18
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
hlist_del_rcu include/linux/rculist.h:427 [inline]
bpf_tcp_close+0xd7f/0xf80 kernel/bpf/sockmap.c:271
inet_release+0x104/0x1f0 net/ipv4/af_inet.c:427
inet6_release+0x50/0x70 net/ipv6/af_inet6.c:459
sock_release+0x96/0x1b0 net/socket.c:594
sock_close+0x16/0x20 net/socket.c:1149
__fput+0x34d/0x890 fs/file_table.c:209
____fput+0x15/0x20 fs/file_table.c:243
task_work_run+0x1e4/0x290 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x1aee/0x2730 kernel/exit.c:865
do_group_exit+0x16f/0x430 kernel/exit.c:968
get_signal+0x886/0x1960 kernel/signal.c:2469
do_signal+0x98/0x2040 arch/x86/kernel/signal.c:810
exit_to_usermode_loop+0x28a/0x310 arch/x86/entry/common.c:162
prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
do_syscall_64+0x6ac/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445ed9
RSP: 002b:00007f0078c0adb8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: fffffffffffffe00 RBX: 00000000006dbc24 RCX: 0000000000445ed9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000006dbc24
RBP: 00000000006dbc20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffcd147dbef R14: 00007f0078c0b9c0 R15: 0000000000000007
Allocated by task 11787:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
__do_kmalloc_node mm/slab.c:3682 [inline]
__kmalloc_node+0x47/0x70 mm/slab.c:3689
kmalloc_node include/linux/slab.h:554 [inline]
alloc_sock_hash_elem kernel/bpf/sockmap.c:2114 [inline]
sock_hash_ctx_update_elem.isra.23+0xa57/0x1560 kernel/bpf/sockmap.c:2245
sock_hash_update_elem+0x14f/0x2d0 kernel/bpf/sockmap.c:2303
map_update_elem+0x5c4/0xc90 kernel/bpf/syscall.c:760
__do_sys_bpf kernel/bpf/syscall.c:2134 [inline]
__se_sys_bpf kernel/bpf/syscall.c:2105 [inline]
__x64_sys_bpf+0x32a/0x4f0 kernel/bpf/syscall.c:2105
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 8998:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xd9/0x260 mm/slab.c:3813
sock_hash_free+0x24e/0x6e0 kernel/bpf/sockmap.c:2093
bpf_map_free_deferred+0xba/0xf0 kernel/bpf/syscall.c:259
process_one_work+0xc1e/0x1b50 kernel/workqueue.c:2145
worker_thread+0x1cc/0x1440 kernel/workqueue.c:2279
kthread+0x345/0x410 kernel/kthread.c:238
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
The buggy address belongs to the object at ffff8801c884cf80
which belongs to the cache kmalloc-64 of size 64
The buggy address is located 16 bytes inside of
64-byte region [ffff8801c884cf80, ffff8801c884cfc0)
The buggy address belongs to the page:
page:ffffea0007221300 count:1 mapcount:0 mapping:ffff8801c884c000 index:0x0
flags: 0x2fffc0000000100(slab)
raw: 02fffc0000000100 ffff8801c884c000 0000000000000000 0000000100000020
raw: ffffea00072e08e0 ffffea0006e99660 ffff8801da800340 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801c884ce80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
ffff8801c884cf00: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
> ffff8801c884cf80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
^
ffff8801c884d000: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
ffff8801c884d080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* general protection fault in bpf_tcp_close
From: syzbot @ 2018-05-26 9:13 UTC (permalink / raw)
To: ast, daniel, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: fd0bfa8d6e04 Merge branch 'bpf-af-xdp-cleanups'
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=11da9427800000
kernel config: https://syzkaller.appspot.com/x/.config?x=b632d8e2c2ab2c1
dashboard link: https://syzkaller.appspot.com/bug?extid=0ce137753c78f7b6acc1
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+0ce137753c78f7b6acc1@syzkaller.appspotmail.com
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 12139 Comm: syz-executor2 Not tainted 4.17.0-rc4+ #17
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:__hlist_del include/linux/list.h:649 [inline]
RIP: 0010:hlist_del_rcu include/linux/rculist.h:427 [inline]
RIP: 0010:bpf_tcp_close+0x7d2/0xf80 kernel/bpf/sockmap.c:271
RSP: 0018:ffff8801a8f8ef70 EFLAGS: 00010a02
RAX: ffffed00351f1dfd RBX: dffffc0000000000 RCX: dead000000000200
RDX: 0000000000000000 RSI: 1bd5a00000000040 RDI: ffff8801cb710910
RBP: ffff8801a8f8f110 R08: ffffed003350ac9d R09: ffffed003350ac9c
R10: ffffed003350ac9c R11: ffff88019a8564e3 R12: ffff8801cb710380
R13: ffff8801b17ea6e0 R14: ffff8801cb710398 R15: ffff8801cb710900
FS: 00007f9890c43700(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fde1a668000 CR3: 000000019dca2000 CR4: 00000000001406f0
DR0: 00000000200001c0 DR1: 00000000200001c0 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
Call Trace:
inet_release+0x104/0x1f0 net/ipv4/af_inet.c:427
inet6_release+0x50/0x70 net/ipv6/af_inet6.c:459
sock_release+0x96/0x1b0 net/socket.c:594
sock_close+0x16/0x20 net/socket.c:1149
__fput+0x34d/0x890 fs/file_table.c:209
____fput+0x15/0x20 fs/file_table.c:243
task_work_run+0x1e4/0x290 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x1aee/0x2730 kernel/exit.c:865
do_group_exit+0x16f/0x430 kernel/exit.c:968
get_signal+0x886/0x1960 kernel/signal.c:2469
do_signal+0x98/0x2040 arch/x86/kernel/signal.c:810
exit_to_usermode_loop+0x28a/0x310 arch/x86/entry/common.c:162
prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
do_syscall_64+0x6ac/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x455a09
RSP: 002b:00007f9890c42ce8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: fffffffffffffe00 RBX: 000000000072bec8 RCX: 0000000000455a09
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000072bec8
RBP: 000000000072bec8 R08: 0000000000000000 R09: 000000000072bea0
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffcb48ac3ff R14: 00007f9890c439c0 R15: 0000000000000000
Code: ff 48 c1 e9 03 80 3c 19 00 0f 85 a9 05 00 00 49 8b 4f 18 48 8b 85 98
fe ff ff 48 89 ce c6 00 00 48 c1 ee 03 48 89 95 d8 fe ff ff <80> 3c 1e 00
0f 85 c6 05 00 00 48 8b 85 98 fe ff ff 48 85 d2 48
RIP: __hlist_del include/linux/list.h:649 [inline] RSP: ffff8801a8f8ef70
RIP: hlist_del_rcu include/linux/rculist.h:427 [inline] RSP:
ffff8801a8f8ef70
RIP: bpf_tcp_close+0x7d2/0xf80 kernel/bpf/sockmap.c:271 RSP:
ffff8801a8f8ef70
---[ end trace e81227e93c7e7b75 ]---
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* Re: [PATCH 1/2] batman-adv: Remove "default n" in Kconfig
From: Sergei Shtylyov @ 2018-05-26 9:13 UTC (permalink / raw)
To: Sven Eckelmann, davem; +Cc: netdev, b.a.t.m.a.n, a, sw, mareklindner, joe
In-Reply-To: <20180525194837.12589-1-sven@narfation.org>
On 5/25/2018 10:48 PM, Sven Eckelmann wrote:
> The "default n" is the default value for any bool or tristate Kconfig
> setting. It is therefore not necessary to add it to the an config entry.
^^^^^^
One article would be enough. And it's "a", not "an" in this case. :-)
> Reported-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Signed-off-by: Sven Eckelmann <sven@narfation.org>
[...]
MBR, Sergei
^ permalink raw reply
* general protection fault in sock_do_ioctl
From: syzbot @ 2018-05-26 9:14 UTC (permalink / raw)
To: davem, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 62c8a069b510 net: mvpp2: Add missing VLAN tag detection
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10ad5827800000
kernel config: https://syzkaller.appspot.com/x/.config?x=b632d8e2c2ab2c1
dashboard link: https://syzkaller.appspot.com/bug?extid=09b980aff7b322aac68d
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+09b980aff7b322aac68d@syzkaller.appspotmail.com
__sys_sendmsg+0x115/0x270 net/socket.c:2155
kasan: CONFIG_KASAN_INLINE enabled
__do_sys_sendmsg net/socket.c:2164 [inline]
__se_sys_sendmsg net/socket.c:2162 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2162
kasan: GPF could be caused by NULL-ptr deref or user memory access
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
general protection fault: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Modules linked in:
RIP: 0033:0x455a09
RSP: 002b:00007f7f8526bc68 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
CPU: 0 PID: 8176 Comm: syz-executor2 Not tainted 4.17.0-rc4+ #53
RAX: ffffffffffffffda RBX: 00007f7f8526c6d4 RCX: 0000000000455a09
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RDX: 0000000000000000 RSI: 00000000200019c0 RDI: 0000000000000013
RIP: 0010:smc_tx_prepared_sends net/smc/smc_tx.h:27 [inline]
RIP: 0010:smc_ioctl+0x6db/0x9f0 net/smc/af_smc.c:1506
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
RSP: 0018:ffff8801afe4f770 EFLAGS: 00010202
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000014
R13: 000000000000059b R14: 00000000006fc728 R15: 0000000000000005
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: dffffc0000000000
RDX: 0000000000000004 RSI: 1ffff10035fc9f0d RDI: 0000000000000020
RBP: ffff8801afe4f9d0 R08: ffffed0035fc9f0e R09: ffffed0035fc9f0d
R10: ffffed0035fc9f0d R11: ffff8801afe4f86f R12: 1ffff10035fc9ef1
R13: 00000000200003c0 R14: ffff8801afe4f868 R15: ffff8801afe4f828
FS: 00007f6710832700(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000007270dc CR3: 00000001c83ae000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
sock_do_ioctl+0xe4/0x3e0 net/socket.c:957
sock_ioctl+0x30d/0x680 net/socket.c:1081
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:500 [inline]
do_vfs_ioctl+0x1cf/0x16a0 fs/ioctl.c:684
ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
__do_sys_ioctl fs/ioctl.c:708 [inline]
__se_sys_ioctl fs/ioctl.c:706 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:706
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 1 PID: 8189 Comm: syz-executor5 Not tainted 4.17.0-rc4+ #53
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Call Trace:
RIP: 0033:0x455a09
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
RSP: 002b:00007f6710831c68 EFLAGS: 00000246
ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f67108326d4 RCX: 0000000000455a09
fail_dump lib/fault-inject.c:51 [inline]
should_fail.cold.4+0xa/0x1a lib/fault-inject.c:149
RDX: 00000000200003c0 RSI: 000000000000894b RDI: 0000000000000013
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 000000000000044c R14: 00000000006fa7c0 R15: 0000000000000000
Code:
f8
48
c1
e8
03
80
3c
10
00
0f
85
ed
01
00
00
48
8b
9b
__should_failslab+0x124/0x180 mm/failslab.c:32
90
should_failslab+0x9/0x14 mm/slab_common.c:1522
04
slab_pre_alloc_hook mm/slab.h:423 [inline]
slab_alloc mm/slab.c:3378 [inline]
kmem_cache_alloc+0x47/0x760 mm/slab.c:3552
00
00
48
kmem_cache_zalloc include/linux/slab.h:691 [inline]
fill_pool lib/debugobjects.c:134 [inline]
__debug_object_init+0xbc0/0x12c0 lib/debugobjects.c:377
b8
00
00
00
00
00 fc
ff
df
48
8d
7b
20
48
89
fa
48
c1
ea
03
<0f>
b6
04
02
84
c0
74
08
3c
03
debug_object_init+0x16/0x20 lib/debugobjects.c:429
0f
debug_timer_init kernel/time/timer.c:704 [inline]
debug_init kernel/time/timer.c:757 [inline]
init_timer_key+0xa1/0x470 kernel/time/timer.c:806
8e
b7
01
00
00
sctp_association_init net/sctp/associola.c:152 [inline]
sctp_association_new+0xa90/0x2170 net/sctp/associola.c:312
8b
43
20
49
8d
RIP: smc_tx_prepared_sends net/smc/smc_tx.h:27 [inline] RSP:
ffff8801afe4f770
RIP: smc_ioctl+0x6db/0x9f0 net/smc/af_smc.c:1506 RSP: ffff8801afe4f770
---[ end trace ed404e46621ff58c ]---
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* WARNING in bpf_int_jit_compile
From: syzbot @ 2018-05-26 9:14 UTC (permalink / raw)
To: ast, daniel, davem, hpa, kuznet, linux-kernel, mingo, netdev,
syzkaller-bugs, tglx, x86, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 203ec2fed17a Merge tag 'armsoc-fixes' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14f0d5a7800000
kernel config: https://syzkaller.appspot.com/x/.config?x=f3b4e30da84ec1ed
dashboard link: https://syzkaller.appspot.com/bug?extid=9e762b52dd17e616a7a5
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+9e762b52dd17e616a7a5@syzkaller.appspotmail.com
RAX: ffffffffffffffda RBX: 00007f9da107d6d4 RCX: 0000000000455a09
RDX: 0000000000000048 RSI: 000000002000e000 RDI: 0000000000000005
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000014
R13: 0000000000000046 R14: 00000000006f4730 R15: 0000000000000021
WARNING: CPU: 0 PID: 20757 at include/linux/filter.h:667
bpf_jit_binary_lock_ro include/linux/filter.h:667 [inline]
WARNING: CPU: 0 PID: 20757 at include/linux/filter.h:667
bpf_int_jit_compile+0xbf7/0xef7 arch/x86/net/bpf_jit_comp.c:1271
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 20757 Comm: syz-executor6 Not tainted 4.17.0-rc5+ #60
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
panic+0x22f/0x4de kernel/panic.c:184
__warn.cold.8+0x163/0x1b3 kernel/panic.c:536
report_bug+0x252/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:bpf_jit_binary_lock_ro include/linux/filter.h:667 [inline]
RIP: 0010:bpf_int_jit_compile+0xbf7/0xef7 arch/x86/net/bpf_jit_comp.c:1271
RSP: 0018:ffff8801b3fbf920 EFLAGS: 00010246
RAX: 0000000000040000 RBX: 0000000000000047 RCX: ffffc900050da000
RDX: 0000000000040000 RSI: ffffffff81444d37 RDI: 0000000000000005
RBP: ffff8801b3fbfa40 R08: ffff8801b4c18040 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90001932002
R13: ffff8801b3fbfa18 R14: 00000000fffffff4 R15: 0000000000000003
bpf_prog_select_runtime+0x131/0x640 kernel/bpf/core.c:1491
bpf_prog_load+0x16c2/0x2070 kernel/bpf/syscall.c:1333
__do_sys_bpf kernel/bpf/syscall.c:2073 [inline]
__se_sys_bpf kernel/bpf/syscall.c:2035 [inline]
__x64_sys_bpf+0x389/0x4c0 kernel/bpf/syscall.c:2035
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x455a09
RSP: 002b:00007f9da107cc68 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 00007f9da107d6d4 RCX: 0000000000455a09
RDX: 0000000000000048 RSI: 000000002000e000 RDI: 0000000000000005
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000014
R13: 0000000000000046 R14: 00000000006f4730 R15: 0000000000000021
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* Re: WARNING in bpf_int_jit_compile
From: syzbot @ 2018-05-26 9:29 UTC (permalink / raw)
To: ast, daniel, davem, hpa, kuznet, linux-kernel, mingo, netdev,
syzkaller-bugs, tglx, x86, yoshfuji
In-Reply-To: <0000000000003cdd01056d184e6e@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 62d18ecfa641 Merge tag 'arm64-fixes' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14c6bf57800000
kernel config: https://syzkaller.appspot.com/x/.config?x=982e2df1b9e60b02
dashboard link: https://syzkaller.appspot.com/bug?extid=9e762b52dd17e616a7a5
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=130e42b7800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+9e762b52dd17e616a7a5@syzkaller.appspotmail.com
RAX: ffffffffffffffda RBX: 0000000002542914 RCX: 0000000000455a09
RDX: 0000000000000048 RSI: 0000000020000240 RDI: 0000000000000005
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003
R13: 0000000000000046 R14: 00000000006f4730 R15: 0000000000000023
WARNING: CPU: 0 PID: 4752 at include/linux/filter.h:667
bpf_jit_binary_lock_ro include/linux/filter.h:667 [inline]
WARNING: CPU: 0 PID: 4752 at include/linux/filter.h:667
bpf_int_jit_compile+0xbf7/0xef7 arch/x86/net/bpf_jit_comp.c:1271
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 4752 Comm: syz-executor0 Not tainted 4.17.0-rc6+ #67
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
panic+0x22f/0x4de kernel/panic.c:184
__warn.cold.8+0x163/0x1b3 kernel/panic.c:536
report_bug+0x252/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:bpf_jit_binary_lock_ro include/linux/filter.h:667 [inline]
RIP: 0010:bpf_int_jit_compile+0xbf7/0xef7 arch/x86/net/bpf_jit_comp.c:1271
RSP: 0018:ffff8801d85ff920 EFLAGS: 00010293
RAX: ffff8801d78c40c0 RBX: 0000000000000046 RCX: ffffffff81445d89
RDX: 0000000000000000 RSI: ffffffff81445d97 RDI: 0000000000000005
RBP: ffff8801d85ffa40 R08: ffff8801d78c40c0 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffc9000194e002
R13: ffff8801d85ffa18 R14: 00000000fffffff4 R15: 0000000000000003
bpf_prog_select_runtime+0x131/0x640 kernel/bpf/core.c:1541
bpf_prog_load+0x16c2/0x2070 kernel/bpf/syscall.c:1333
__do_sys_bpf kernel/bpf/syscall.c:2073 [inline]
__se_sys_bpf kernel/bpf/syscall.c:2035 [inline]
__x64_sys_bpf+0x389/0x4c0 kernel/bpf/syscall.c:2035
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x455a09
RSP: 002b:00007ffec3da2868 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 0000000002542914 RCX: 0000000000455a09
RDX: 0000000000000048 RSI: 0000000020000240 RDI: 0000000000000005
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003
R13: 0000000000000046 R14: 00000000006f4730 R15: 0000000000000023
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
^ permalink raw reply
* Re: [PATCH] rtnetlink: Add more well known protocol values
From: Sergei Shtylyov @ 2018-05-26 9:37 UTC (permalink / raw)
To: Donald Sharp, netdev, dsahern
In-Reply-To: <20180525182050.26056-1-sharpd@cumulusnetworks.com>
Hello!
On 5/25/2018 9:20 PM, Donald Sharp wrote:
> FRRouting installs routes into the kernel associated with
> the originating protocol. Add these values to the well
> known values in rtnetlink.h.
>
> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
> ---
> include/uapi/linux/rtnetlink.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
> index cabb210c93af..81b33826f818 100644
> --- a/include/uapi/linux/rtnetlink.h
> +++ b/include/uapi/linux/rtnetlink.h
> @@ -254,6 +254,11 @@ enum {
> #define RTPROT_DHCP 16 /* DHCP client */
> #define RTPROT_MROUTED 17 /* Multicast daemon */
> #define RTPROT_BABEL 42 /* Babel daemon */
> +#define RTPROT_BGP 186 /* BGP Routes */
> +#define RTPROT_ISIS 187 /* ISIS Routes */
> +#define RTPROT_OSPF 188 /* OSPF Routes */
> +#define RTPROT_RIP 189 /* RIP Routes */
> +#define RTPROT_EIGRP 192 /* EIGRP Routes */
The preceding entries use tab to indent the value, yours use spaces. Not
good...
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH net-next] net: bpfilter: make function bpfilter_mbox_request() static
From: Wei Yongjun @ 2018-05-26 9:47 UTC (permalink / raw)
To: Alexey Kuznetsov, Hideaki YOSHIFUJI, Alexei Starovoitov
Cc: Wei Yongjun, netdev, kernel-janitors
Fixes the following sparse warnings:
net/ipv4/bpfilter/sockopt.c:13:5: warning:
symbol 'bpfilter_mbox_request' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
net/ipv4/bpfilter/sockopt.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/bpfilter/sockopt.c b/net/ipv4/bpfilter/sockopt.c
index 42a96d2..5e04ed2 100644
--- a/net/ipv4/bpfilter/sockopt.c
+++ b/net/ipv4/bpfilter/sockopt.c
@@ -10,8 +10,9 @@
unsigned int optlen, bool is_set);
EXPORT_SYMBOL_GPL(bpfilter_process_sockopt);
-int bpfilter_mbox_request(struct sock *sk, int optname, char __user *optval,
- unsigned int optlen, bool is_set)
+static int bpfilter_mbox_request(struct sock *sk, int optname,
+ char __user *optval,
+ unsigned int optlen, bool is_set)
{
if (!bpfilter_process_sockopt) {
int err = request_module("bpfilter");
^ permalink raw reply related
* [PATCH v2 1/2] batman-adv: Remove "default n" in Kconfig
From: Sven Eckelmann @ 2018-05-26 9:40 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, a, sw, mareklindner, joe, sergei.shtylyov,
Sven Eckelmann
The "default n" is the default value for any bool or tristate Kconfig
setting. It is therefore not necessary to add it to a config entry.
Reported-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
v2: changed "the an config entry" to "a config entry" in commit message
net/batman-adv/Kconfig | 5 -----
1 file changed, 5 deletions(-)
diff --git a/net/batman-adv/Kconfig b/net/batman-adv/Kconfig
index de8034d80623..41bb67d70c83 100644
--- a/net/batman-adv/Kconfig
+++ b/net/batman-adv/Kconfig
@@ -24,7 +24,6 @@ config BATMAN_ADV
depends on NET
select CRC16
select LIBCRC32C
- default n
help
B.A.T.M.A.N. (better approach to mobile ad-hoc networking) is
a routing protocol for multi-hop ad-hoc mesh networks. The
@@ -60,7 +59,6 @@ config BATMAN_ADV_BLA
config BATMAN_ADV_DAT
bool "Distributed ARP Table"
depends on BATMAN_ADV && INET
- default n
help
This option enables DAT (Distributed ARP Table), a DHT based
mechanism that increases ARP reliability on sparse wireless
@@ -70,7 +68,6 @@ config BATMAN_ADV_DAT
config BATMAN_ADV_NC
bool "Network Coding"
depends on BATMAN_ADV
- default n
help
This option enables network coding, a mechanism that aims to
increase the overall network throughput by fusing multiple
@@ -84,7 +81,6 @@ config BATMAN_ADV_NC
config BATMAN_ADV_MCAST
bool "Multicast optimisation"
depends on BATMAN_ADV && INET && !(BRIDGE=m && BATMAN_ADV=y)
- default n
help
This option enables the multicast optimisation which aims to
reduce the air overhead while improving the reliability of
@@ -94,7 +90,6 @@ config BATMAN_ADV_DEBUGFS
bool "batman-adv debugfs entries"
depends on BATMAN_ADV
depends on DEBUG_FS
- default n
help
Enable this to export routing related debug tables via debugfs.
The information for each soft-interface and used hard-interface can be
--
2.17.0
^ permalink raw reply related
* [PATCH v2 2/2] batman-adv: Drop "experimental" from BATMAN_V Kconfig
From: Sven Eckelmann @ 2018-05-26 9:40 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, a, sw, mareklindner, joe, sergei.shtylyov,
Sven Eckelmann
In-Reply-To: <20180526094032.10044-1-sven@narfation.org>
The Kconfig option BATMAN_ADV_BATMAN_V is now enabled by default when the
BATMAN_ADV is enabled. A feature which is enabled by default for a module
should not be considered experimental.
Reported-by: Joe Perches <joe@perches.com>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
v2: no change
net/batman-adv/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/batman-adv/Kconfig b/net/batman-adv/Kconfig
index 41bb67d70c83..da0b7aa98be9 100644
--- a/net/batman-adv/Kconfig
+++ b/net/batman-adv/Kconfig
@@ -32,7 +32,7 @@ config BATMAN_ADV
tools.
config BATMAN_ADV_BATMAN_V
- bool "B.A.T.M.A.N. V protocol (experimental)"
+ bool "B.A.T.M.A.N. V protocol"
depends on BATMAN_ADV && !(CFG80211=m && BATMAN_ADV=y)
default y
help
--
2.17.0
^ permalink raw reply related
* [PATCH net-next] netfilter: nat: make symbol nat_hook static
From: Wei Yongjun @ 2018-05-26 9:48 UTC (permalink / raw)
To: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal
Cc: Wei Yongjun, netfilter-devel, coreteam, netdev, kernel-janitors
Fixes the following sparse warning:
net/netfilter/nf_nat_core.c:1039:20: warning:
symbol 'nat_hook' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
net/netfilter/nf_nat_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/nf_nat_core.c b/net/netfilter/nf_nat_core.c
index 821f8d8..b7df32a 100644
--- a/net/netfilter/nf_nat_core.c
+++ b/net/netfilter/nf_nat_core.c
@@ -1036,7 +1036,7 @@ void nf_nat_unregister_fn(struct net *net, const struct nf_hook_ops *ops,
.size = sizeof(struct nat_net),
};
-struct nf_nat_hook nat_hook = {
+static struct nf_nat_hook nat_hook = {
.parse_nat_setup = nfnetlink_parse_nat_setup,
#ifdef CONFIG_XFRM
.decode_session = __nf_nat_decode_session,
^ permalink raw reply related
* Is it possible to get device information via CMSG?
From: Eric S. Raymond @ 2018-05-26 9:39 UTC (permalink / raw)
To: netdev
I'm trying to untangle some nasty code in the Mills implementation of
NTP. I could simplify it a lot if there were a way to query a packet
to find out the name of the network interface it arrived on. (At the
moment the code has to iterate over all interfaces checking for
traffic on each one just so it doesn't lose that information.)
This seems like the kind of thing the CMSG macros are intended to
support, but I can't find anywhere a specification of what cmsg_level
and cmsg_type values are valid and what their semantics are.
So I have two questions:
1. Is there a cmsg_level/cmsg_type combination that will return the
name of the device the packet arrived through?
2. Is the set of possible cmsg_level and cmsg_type values documented
anywhere? If not, how would one go about assemnbling such information?
(I would be willing to write a man page about this.)
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
You [should] not examine legislation in the light of the benefits it will
convey if properly administered, but in the light of the wrongs it
would do and the harm it would cause if improperly administered
-- Lyndon Johnson, former President of the U.S.
^ permalink raw reply
* Re: System hung for reg_check_changs_work()-> rtnl_lock()->mutex_lock()
From: Dmitry Vyukov @ 2018-05-26 10:19 UTC (permalink / raw)
To: Shawn Lin; +Cc: netdev, David S. Miller, syzkaller-bugs
In-Reply-To: <aa65282a-b7f9-757f-8690-64c27df44e90@rock-chips.com>
On Mon, May 21, 2018 at 5:47 AM, Shawn Lin <shawn.lin@rock-chips.com> wrote:
> Hi,
>
> I found this hung for several times these days, and seems syzbot already
> reported a similar problem. Is there any patch(es) for that?
>
> Successfully initialized wpa_supplicant
> [ 240.091941] INFO: task kworker/u8:1:39 blocked for more than 120 seconds.
> [ 240.092004] Not tainted 4.4.126 #1
> [ 240.092026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
> this message.
> [ 240.092047] kworker/u8:1 D ffffff8008084dfc 0 39 2
> 0x00000000
> [ 240.092116] Workqueue: events_power_efficient reg_check_chans_work
> [ 240.092153] Call trace:
> [ 240.092191] [<ffffff8008084dfc>] __switch_to+0x84/0xa0
> [ 240.092228] [<ffffff80086299f0>] __schedule+0x428/0x45c
> [ 240.092260] [<ffffff8008629a98>] schedule+0x74/0x94
> [ 240.092295] [<ffffff8008629e44>] schedule_preempt_disabled+0x20/0x38
> [ 240.092332] [<ffffff800862b13c>] __mutex_lock_slowpath+0xc0/0x138
> [ 240.092364] [<ffffff800862b1e0>] mutex_lock+0x2c/0x40
> [ 240.092399] [<ffffff80084eb820>] rtnl_lock+0x14/0x1c
> [ 240.092428] [<ffffff80085ce2a0>] reg_check_chans_work+0x2c/0x1f0
> [ 240.092463] [<ffffff80080abbac>] process_one_work+0x1b0/0x294
> [ 240.092494] [<ffffff80080ac904>] worker_thread+0x2d8/0x398
> [ 240.092524] [<ffffff80080b0f04>] kthread+0xc8/0xd8
> [ 240.092567] [<ffffff8008082e80>] ret_from_fork+0x10/0x50
> [ 240.092594] Kernel panic - not syncing: hung_task: blocked tasks
> [ 240.101163] CPU: 0 PID: 30 Comm: khungtaskd Not tainted 4.4.126 #1
> [ 240.101729] Hardware name: Rockchip RK3308 evb analog mic board (DT)
> [ 240.102302] Call trace:
> [ 240.102546] [<ffffff800808731c>] dump_backtrace+0x0/0x1c4
> [ 240.103044] [<ffffff80080874f4>] show_stack+0x14/0x1c
> [ 240.103521] [<ffffff800823f4b4>] dump_stack+0x94/0xbc
> [ 240.104000] [<ffffff800810a80c>] panic+0xd8/0x228
> [ 240.104446] [<ffffff80080fb228>] proc_dohung_task_timeout_secs+0x0/0x40
> [ 240.105050] [<ffffff80080b0f04>] kthread+0xc8/0xd8
> [ 240.105500] [<ffffff8008082e80>] ret_from_fork+0x10/0x50
> [ 240.106065] CPU1: stopping
> [ 240.106348] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.126 #1
Syzbot has reported whole bunch of hangs on rtnl lock, but there is no
resolution:
https://syzkaller.appspot.com/bug?id=2503c576cabb08d41812e732b390141f01a59545
I suspect this can be related to hangs in unregister_netdevice:
https://syzkaller.appspot.com/bug?id=1a97a5bd119fd97995f752819fd87840ab9479a9
They happen all the time too, there is no resolution for this either.
Also see this thread:
https://groups.google.com/d/msg/syzkaller/-06_laheMF0/xqezy58kAwAJ
^ 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