* Re: [PATCH net-next v2 4/4] gve: Add ethtool support
From: Stephen Hemminger @ 2019-06-28 18:10 UTC (permalink / raw)
To: Catherine Sullivan
Cc: netdev, Sagi Shahar, Jon Olson, Willem de Bruijn, Luigi Rizzo
In-Reply-To: <20190628175633.143501-5-csully@google.com>
On Fri, 28 Jun 2019 10:56:33 -0700
Catherine Sullivan <csully@google.com> wrote:
> +static void
> +gve_get_ethtool_stats(struct net_device *netdev,
> + struct ethtool_stats *stats, u64 *data)
> +{
> + struct gve_priv *priv = netdev_priv(netdev);
> + u64 rx_pkts, rx_bytes, tx_pkts, tx_bytes;
> + int ring;
> + int i;
> +
> + ASSERT_RTNL();
> +
> + for (rx_pkts = 0, rx_bytes = 0, ring = 0;
> + ring < priv->rx_cfg.num_queues; ring++) {
> + if (priv->rx) {
> + rx_pkts += priv->rx[ring].rpackets;
> + rx_bytes += priv->rx[ring].rbytes;
> + }
> + }
> + for (tx_pkts = 0, tx_bytes = 0, ring = 0;
> + ring < priv->tx_cfg.num_queues; ring++) {
> + if (priv->tx) {
> + tx_pkts += priv->tx[ring].pkt_done;
> + tx_bytes += priv->tx[ring].bytes_done;
> + }
> + }
> + memset(data, 0, GVE_MAIN_STATS_LEN * sizeof(*data));
memset here is unnecessary since ethtool_get_stats allocates
and zeros the memory already.
^ permalink raw reply
* Re: [PATCH v3 bpf-next 3/9] libbpf: add ability to attach/detach BPF program to perf event
From: Stanislav Fomichev @ 2019-06-28 18:14 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Andrii Nakryiko, Alexei Starovoitov, Daniel Borkmann, Networking,
bpf, Kernel Team
In-Reply-To: <CAEf4BzZ_1-uSNRco91yZ4OJ2dV+G-yZ_uFPTbQDmPHoNLX9sPw@mail.gmail.com>
On 06/28, Andrii Nakryiko wrote:
> On Fri, Jun 28, 2019 at 11:00 AM Stanislav Fomichev <sdf@fomichev.me> wrote:
> >
> > On 06/27, Andrii Nakryiko wrote:
> > > bpf_program__attach_perf_event allows to attach BPF program to existing
> > > perf event hook, providing most generic and most low-level way to attach BPF
> > > programs. It returns struct bpf_link, which should be passed to
> > > bpf_link__destroy to detach and free resources, associated with a link.
> > >
> > > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > > ---
> > > tools/lib/bpf/libbpf.c | 58 ++++++++++++++++++++++++++++++++++++++++
> > > tools/lib/bpf/libbpf.h | 3 +++
> > > tools/lib/bpf/libbpf.map | 1 +
> > > 3 files changed, 62 insertions(+)
> > >
> > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > > index 455795e6f8af..606705f878ba 100644
> > > --- a/tools/lib/bpf/libbpf.c
> > > +++ b/tools/lib/bpf/libbpf.c
> > > @@ -32,6 +32,7 @@
> > > #include <linux/limits.h>
> > > #include <linux/perf_event.h>
> > > #include <linux/ring_buffer.h>
> > > +#include <sys/ioctl.h>
> > > #include <sys/stat.h>
> > > #include <sys/types.h>
> > > #include <sys/vfs.h>
> > > @@ -3958,6 +3959,63 @@ int bpf_link__destroy(struct bpf_link *link)
> > > return err;
> > > }
> > >
> > > +struct bpf_link_fd {
> > > + struct bpf_link link; /* has to be at the top of struct */
> > > + int fd; /* hook FD */
> > > +};
> > > +
> > > +static int bpf_link__destroy_perf_event(struct bpf_link *link)
> > > +{
> > > + struct bpf_link_fd *l = (void *)link;
> > > + int err;
> > > +
> > > + if (l->fd < 0)
> > > + return 0;
> > > +
> > > + err = ioctl(l->fd, PERF_EVENT_IOC_DISABLE, 0);
> > > + close(l->fd);
> > > + return err;
> > Why not return -errno from ioctl here (as you do elsewhere)?
>
> Good catch, will fix, thanks!
>
> As an aside, this whole returning error on close/destroy is a bit
> moot, as there is little one can do if any of teardown steps fail
> (except crash, which is not great response :) ). So the strategy would
> be to still free all memory and try to close all FDs, before returning
> error (again, which one, first, last? eh..).
Agreed, it's like nobody cares about close() return code. So don't
bother with this fix unless you'd do another respin for a different
reason.
> > > +}
> > > +
> > > +struct bpf_link *bpf_program__attach_perf_event(struct bpf_program *prog,
> > > + int pfd)
> > > +{
> > > + char errmsg[STRERR_BUFSIZE];
> > > + struct bpf_link_fd *link;
> > > + int bpf_fd, err;
> > > +
> > > + bpf_fd = bpf_program__fd(prog);
> > > + if (bpf_fd < 0) {
> > > + pr_warning("program '%s': can't attach before loaded\n",
> > > + bpf_program__title(prog, false));
> > > + return ERR_PTR(-EINVAL);
> > > + }
> > > +
> > > + link = malloc(sizeof(*link));
> > > + if (!link)
> > > + return ERR_PTR(-ENOMEM);
> > > + link->link.destroy = &bpf_link__destroy_perf_event;
> > > + link->fd = pfd;
> > > +
> > > + if (ioctl(pfd, PERF_EVENT_IOC_SET_BPF, bpf_fd) < 0) {
> > > + err = -errno;
> > > + free(link);
> > > + pr_warning("program '%s': failed to attach to pfd %d: %s\n",
> > > + bpf_program__title(prog, false), pfd,
> > > + libbpf_strerror_r(err, errmsg, sizeof(errmsg)));
> > > + return ERR_PTR(err);
> > > + }
> > > + if (ioctl(pfd, PERF_EVENT_IOC_ENABLE, 0) < 0) {
> > > + err = -errno;
> > > + free(link);
> > > + pr_warning("program '%s': failed to enable pfd %d: %s\n",
> > > + bpf_program__title(prog, false), pfd,
> > > + libbpf_strerror_r(err, errmsg, sizeof(errmsg)));
> > > + return ERR_PTR(err);
> > > + }
> > > + return (struct bpf_link *)link;
> > > +}
> > > +
> > > enum bpf_perf_event_ret
> > > bpf_perf_event_read_simple(void *mmap_mem, size_t mmap_size, size_t page_size,
> > > void **copy_mem, size_t *copy_size,
> > > diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> > > index 5082a5ebb0c2..1bf66c4a9330 100644
> > > --- a/tools/lib/bpf/libbpf.h
> > > +++ b/tools/lib/bpf/libbpf.h
> > > @@ -169,6 +169,9 @@ struct bpf_link;
> > >
> > > LIBBPF_API int bpf_link__destroy(struct bpf_link *link);
> > >
> > > +LIBBPF_API struct bpf_link *
> > > +bpf_program__attach_perf_event(struct bpf_program *prog, int pfd);
> > > +
> > > struct bpf_insn;
> > >
> > > /*
> > > diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> > > index 3cde850fc8da..756f5aa802e9 100644
> > > --- a/tools/lib/bpf/libbpf.map
> > > +++ b/tools/lib/bpf/libbpf.map
> > > @@ -169,6 +169,7 @@ LIBBPF_0.0.4 {
> > > global:
> > > bpf_link__destroy;
> > > bpf_object__load_xattr;
> > > + bpf_program__attach_perf_event;
> > > btf_dump__dump_type;
> > > btf_dump__free;
> > > btf_dump__new;
> > > --
> > > 2.17.1
> > >
^ permalink raw reply
* Re: [PATCH v3 bpf-next 3/9] libbpf: add ability to attach/detach BPF program to perf event
From: Andrii Nakryiko @ 2019-06-28 18:15 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Andrii Nakryiko, Alexei Starovoitov, Daniel Borkmann, Networking,
bpf, Kernel Team
In-Reply-To: <20190628181414.GC24308@mini-arch>
On Fri, Jun 28, 2019 at 11:14 AM Stanislav Fomichev <sdf@fomichev.me> wrote:
>
> On 06/28, Andrii Nakryiko wrote:
> > On Fri, Jun 28, 2019 at 11:00 AM Stanislav Fomichev <sdf@fomichev.me> wrote:
> > >
> > > On 06/27, Andrii Nakryiko wrote:
> > > > bpf_program__attach_perf_event allows to attach BPF program to existing
> > > > perf event hook, providing most generic and most low-level way to attach BPF
> > > > programs. It returns struct bpf_link, which should be passed to
> > > > bpf_link__destroy to detach and free resources, associated with a link.
> > > >
> > > > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > > > ---
> > > > tools/lib/bpf/libbpf.c | 58 ++++++++++++++++++++++++++++++++++++++++
> > > > tools/lib/bpf/libbpf.h | 3 +++
> > > > tools/lib/bpf/libbpf.map | 1 +
> > > > 3 files changed, 62 insertions(+)
> > > >
> > > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > > > index 455795e6f8af..606705f878ba 100644
> > > > --- a/tools/lib/bpf/libbpf.c
> > > > +++ b/tools/lib/bpf/libbpf.c
> > > > @@ -32,6 +32,7 @@
> > > > #include <linux/limits.h>
> > > > #include <linux/perf_event.h>
> > > > #include <linux/ring_buffer.h>
> > > > +#include <sys/ioctl.h>
> > > > #include <sys/stat.h>
> > > > #include <sys/types.h>
> > > > #include <sys/vfs.h>
> > > > @@ -3958,6 +3959,63 @@ int bpf_link__destroy(struct bpf_link *link)
> > > > return err;
> > > > }
> > > >
> > > > +struct bpf_link_fd {
> > > > + struct bpf_link link; /* has to be at the top of struct */
> > > > + int fd; /* hook FD */
> > > > +};
> > > > +
> > > > +static int bpf_link__destroy_perf_event(struct bpf_link *link)
> > > > +{
> > > > + struct bpf_link_fd *l = (void *)link;
> > > > + int err;
> > > > +
> > > > + if (l->fd < 0)
> > > > + return 0;
> > > > +
> > > > + err = ioctl(l->fd, PERF_EVENT_IOC_DISABLE, 0);
> > > > + close(l->fd);
> > > > + return err;
> > > Why not return -errno from ioctl here (as you do elsewhere)?
> >
> > Good catch, will fix, thanks!
> >
> > As an aside, this whole returning error on close/destroy is a bit
> > moot, as there is little one can do if any of teardown steps fail
> > (except crash, which is not great response :) ). So the strategy would
> > be to still free all memory and try to close all FDs, before returning
> > error (again, which one, first, last? eh..).
> Agreed, it's like nobody cares about close() return code. So don't
> bother with this fix unless you'd do another respin for a different
> reason.
I still want something more meaningful than -1 :) Will renamed bpf_fd as well.
>
> > > > +}
> > > > +
> > > > +struct bpf_link *bpf_program__attach_perf_event(struct bpf_program *prog,
> > > > + int pfd)
> > > > +{
> > > > + char errmsg[STRERR_BUFSIZE];
> > > > + struct bpf_link_fd *link;
> > > > + int bpf_fd, err;
> > > > +
> > > > + bpf_fd = bpf_program__fd(prog);
> > > > + if (bpf_fd < 0) {
> > > > + pr_warning("program '%s': can't attach before loaded\n",
> > > > + bpf_program__title(prog, false));
> > > > + return ERR_PTR(-EINVAL);
> > > > + }
> > > > +
> > > > + link = malloc(sizeof(*link));
> > > > + if (!link)
> > > > + return ERR_PTR(-ENOMEM);
> > > > + link->link.destroy = &bpf_link__destroy_perf_event;
> > > > + link->fd = pfd;
> > > > +
> > > > + if (ioctl(pfd, PERF_EVENT_IOC_SET_BPF, bpf_fd) < 0) {
> > > > + err = -errno;
> > > > + free(link);
> > > > + pr_warning("program '%s': failed to attach to pfd %d: %s\n",
> > > > + bpf_program__title(prog, false), pfd,
> > > > + libbpf_strerror_r(err, errmsg, sizeof(errmsg)));
> > > > + return ERR_PTR(err);
> > > > + }
> > > > + if (ioctl(pfd, PERF_EVENT_IOC_ENABLE, 0) < 0) {
> > > > + err = -errno;
> > > > + free(link);
> > > > + pr_warning("program '%s': failed to enable pfd %d: %s\n",
> > > > + bpf_program__title(prog, false), pfd,
> > > > + libbpf_strerror_r(err, errmsg, sizeof(errmsg)));
> > > > + return ERR_PTR(err);
> > > > + }
> > > > + return (struct bpf_link *)link;
> > > > +}
> > > > +
> > > > enum bpf_perf_event_ret
> > > > bpf_perf_event_read_simple(void *mmap_mem, size_t mmap_size, size_t page_size,
> > > > void **copy_mem, size_t *copy_size,
> > > > diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> > > > index 5082a5ebb0c2..1bf66c4a9330 100644
> > > > --- a/tools/lib/bpf/libbpf.h
> > > > +++ b/tools/lib/bpf/libbpf.h
> > > > @@ -169,6 +169,9 @@ struct bpf_link;
> > > >
> > > > LIBBPF_API int bpf_link__destroy(struct bpf_link *link);
> > > >
> > > > +LIBBPF_API struct bpf_link *
> > > > +bpf_program__attach_perf_event(struct bpf_program *prog, int pfd);
> > > > +
> > > > struct bpf_insn;
> > > >
> > > > /*
> > > > diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> > > > index 3cde850fc8da..756f5aa802e9 100644
> > > > --- a/tools/lib/bpf/libbpf.map
> > > > +++ b/tools/lib/bpf/libbpf.map
> > > > @@ -169,6 +169,7 @@ LIBBPF_0.0.4 {
> > > > global:
> > > > bpf_link__destroy;
> > > > bpf_object__load_xattr;
> > > > + bpf_program__attach_perf_event;
> > > > btf_dump__dump_type;
> > > > btf_dump__free;
> > > > btf_dump__new;
> > > > --
> > > > 2.17.1
> > > >
^ permalink raw reply
* Re: [PATCH v4 03/13] dt-bindings: net: Add a YAML schemas for the generic MDIO options
From: Rob Herring @ 2019-06-28 18:17 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, Frank Rowand, David S . Miller, Chen-Yu Tsai,
Maxime Coquelin, Alexandre Torgue, netdev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
devicetree, linux-stm32, Maxime Chevallier, Antoine Ténart,
Andrew Lunn, Florian Fainelli, Heiner Kallweit
In-Reply-To: <20190628134553.l445r5idtejwlryl@flea>
On Fri, Jun 28, 2019 at 7:46 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Thu, Jun 27, 2019 at 10:06:57AM -0600, Rob Herring wrote:
> > On Thu, Jun 27, 2019 at 9:57 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > > > +
> > > > > + reset-gpios = <&gpio2 5 1>;
> > > > > + reset-delay-us = <2>;
> > > > > +
> > > > > + ethphy0: ethernet-phy@1 {
> > > > > + reg = <1>;
> > > >
> > > > Need a child node schema to validate the unit-address and reg property.
> > >
> > > This should be already covered by the ethernet-phy.yaml schemas
> > > earlier in this series.
> >
> > Partially, yes.
> >
> > > Were you expecting something else?
> >
> > That would not prevent having a child node such as 'foo {};' or
> > 'foo@bad {};'. It would also not check valid nodes named something
> > other than 'ethernet-phy'.
>
> Right, but listing the nodes won't either, since we can't enable
> additionalProperties in that schema. So any node that wouldn't match
> ethernet-phy@.* wouldn't be validated, but wouldn't generate a warning
> either.
Perhaps I wasn't clear, but it was missing or incorrect 'reg' property
and unit-address format checks that I was thinking about. Just like we
have for SPI.
Rob
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/4] libbpf: capture value in BTF type info for BTF-defined map defs
From: Song Liu @ 2019-06-28 18:17 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Andrii Nakryiko, Alexei Starovoitov, Daniel Borkmann,
bpf@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20190628152539.3014719-2-andriin@fb.com>
> On Jun 28, 2019, at 8:25 AM, Andrii Nakryiko <andriin@fb.com> wrote:
>
> Change BTF-defined map definitions to capture compile-time integer
> values as part of BTF type definition, to avoid split of key/value type
> information and actual type/size/flags initialization for maps.
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Song Liu <songliubraving@fb.com>
> ---
> tools/lib/bpf/libbpf.c | 58 ++++++++++++++++++++----------------------
> 1 file changed, 28 insertions(+), 30 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 6e6ebef11ba3..9e099ecb2c2b 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -1028,40 +1028,40 @@ static const struct btf_type *skip_mods_and_typedefs(const struct btf *btf,
> }
> }
>
> -static bool get_map_field_int(const char *map_name,
> - const struct btf *btf,
> +/*
> + * Fetch integer attribute of BTF map definition. Such attributes are
> + * represented using a pointer to an array, in which dimensionality of array
> + * encodes specified integer value. E.g., int (*type)[BPF_MAP_TYPE_ARRAY];
> + * encodes `type => BPF_MAP_TYPE_ARRAY` key/value pair completely using BTF
> + * type definition, while using only sizeof(void *) space in ELF data section.
> + */
> +static bool get_map_field_int(const char *map_name, const struct btf *btf,
> const struct btf_type *def,
> - const struct btf_member *m,
> - const void *data, __u32 *res) {
> + const struct btf_member *m, __u32 *res) {
> const struct btf_type *t = skip_mods_and_typedefs(btf, m->type);
> const char *name = btf__name_by_offset(btf, m->name_off);
> - __u32 int_info = *(const __u32 *)(const void *)(t + 1);
> + const struct btf_array *arr_info;
> + const struct btf_type *arr_t;
>
> - if (BTF_INFO_KIND(t->info) != BTF_KIND_INT) {
> - pr_warning("map '%s': attr '%s': expected INT, got %u.\n",
> + if (BTF_INFO_KIND(t->info) != BTF_KIND_PTR) {
> + pr_warning("map '%s': attr '%s': expected PTR, got %u.\n",
> map_name, name, BTF_INFO_KIND(t->info));
> return false;
> }
> - if (t->size != 4 || BTF_INT_BITS(int_info) != 32 ||
> - BTF_INT_OFFSET(int_info)) {
> - pr_warning("map '%s': attr '%s': expected 32-bit non-bitfield integer, "
> - "got %u-byte (%d-bit) one with bit offset %d.\n",
> - map_name, name, t->size, BTF_INT_BITS(int_info),
> - BTF_INT_OFFSET(int_info));
> - return false;
> - }
> - if (BTF_INFO_KFLAG(def->info) && BTF_MEMBER_BITFIELD_SIZE(m->offset)) {
> - pr_warning("map '%s': attr '%s': bitfield is not supported.\n",
> - map_name, name);
> +
> + arr_t = btf__type_by_id(btf, t->type);
> + if (!arr_t) {
> + pr_warning("map '%s': attr '%s': type [%u] not found.\n",
> + map_name, name, t->type);
> return false;
> }
> - if (m->offset % 32) {
> - pr_warning("map '%s': attr '%s': unaligned fields are not supported.\n",
> - map_name, name);
> + if (BTF_INFO_KIND(arr_t->info) != BTF_KIND_ARRAY) {
> + pr_warning("map '%s': attr '%s': expected ARRAY, got %u.\n",
> + map_name, name, BTF_INFO_KIND(arr_t->info));
> return false;
> }
> -
> - *res = *(const __u32 *)(data + m->offset / 8);
> + arr_info = (const void *)(arr_t + 1);
> + *res = arr_info->nelems;
> return true;
> }
>
> @@ -1074,7 +1074,6 @@ static int bpf_object__init_user_btf_map(struct bpf_object *obj,
> const struct btf_var_secinfo *vi;
> const struct btf_var *var_extra;
> const struct btf_member *m;
> - const void *def_data;
> const char *map_name;
> struct bpf_map *map;
> int vlen, i;
> @@ -1131,7 +1130,6 @@ static int bpf_object__init_user_btf_map(struct bpf_object *obj,
> pr_debug("map '%s': at sec_idx %d, offset %zu.\n",
> map_name, map->sec_idx, map->sec_offset);
>
> - def_data = data->d_buf + vi->offset;
> vlen = BTF_INFO_VLEN(def->info);
> m = (const void *)(def + 1);
> for (i = 0; i < vlen; i++, m++) {
> @@ -1144,19 +1142,19 @@ static int bpf_object__init_user_btf_map(struct bpf_object *obj,
> }
> if (strcmp(name, "type") == 0) {
> if (!get_map_field_int(map_name, obj->btf, def, m,
> - def_data, &map->def.type))
> + &map->def.type))
> return -EINVAL;
> pr_debug("map '%s': found type = %u.\n",
> map_name, map->def.type);
> } else if (strcmp(name, "max_entries") == 0) {
> if (!get_map_field_int(map_name, obj->btf, def, m,
> - def_data, &map->def.max_entries))
> + &map->def.max_entries))
> return -EINVAL;
> pr_debug("map '%s': found max_entries = %u.\n",
> map_name, map->def.max_entries);
> } else if (strcmp(name, "map_flags") == 0) {
> if (!get_map_field_int(map_name, obj->btf, def, m,
> - def_data, &map->def.map_flags))
> + &map->def.map_flags))
> return -EINVAL;
> pr_debug("map '%s': found map_flags = %u.\n",
> map_name, map->def.map_flags);
> @@ -1164,7 +1162,7 @@ static int bpf_object__init_user_btf_map(struct bpf_object *obj,
> __u32 sz;
>
> if (!get_map_field_int(map_name, obj->btf, def, m,
> - def_data, &sz))
> + &sz))
> return -EINVAL;
> pr_debug("map '%s': found key_size = %u.\n",
> map_name, sz);
> @@ -1207,7 +1205,7 @@ static int bpf_object__init_user_btf_map(struct bpf_object *obj,
> __u32 sz;
>
> if (!get_map_field_int(map_name, obj->btf, def, m,
> - def_data, &sz))
> + &sz))
> return -EINVAL;
> pr_debug("map '%s': found value_size = %u.\n",
> map_name, sz);
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v2 bpf-next 2/4] selftests/bpf: add __int and __type macro for BTF-defined maps
From: Song Liu @ 2019-06-28 18:17 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Andrii Nakryiko, Alexei Starovoitov, daniel@iogearbox.net,
bpf@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20190628152539.3014719-3-andriin@fb.com>
> On Jun 28, 2019, at 8:25 AM, Andrii Nakryiko <andriin@fb.com> wrote:
>
> Add simple __int and __type macro that hide details of how type and
> integer values are captured in BTF-defined maps.
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Song Liu <songliubraving@fb.com>
> ---
> tools/testing/selftests/bpf/bpf_helpers.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/tools/testing/selftests/bpf/bpf_helpers.h b/tools/testing/selftests/bpf/bpf_helpers.h
> index 1a5b1accf091..aa5ddf58c088 100644
> --- a/tools/testing/selftests/bpf/bpf_helpers.h
> +++ b/tools/testing/selftests/bpf/bpf_helpers.h
> @@ -8,6 +8,9 @@
> */
> #define SEC(NAME) __attribute__((section(NAME), used))
>
> +#define __int(name, val) int (*name)[val]
> +#define __type(name, val) val *name
> +
> /* helper macro to print out debug messages */
> #define bpf_printk(fmt, ...) \
> ({ \
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCHv2 next 0/3] blackhole device to invalidate dst
From: Michael Chan @ 2019-06-28 18:22 UTC (permalink / raw)
To: Mahesh Bandewar
Cc: Netdev, Eric Dumazet, David Miller, Daniel Axtens,
Mahesh Bandewar
In-Reply-To: <20190627194250.91296-1-maheshb@google.com>
On Thu, Jun 27, 2019 at 12:42 PM Mahesh Bandewar <maheshb@google.com> wrote:
> However, Michael Chan <michael.chan@broadcom.com> had a setup
> where these fixes helped him mitigate the issue and not cause
> the crash.
>
Our lab has finished testing these patches. The patches work in the
sense that no oversize packets are now passed to the driver with the
patches applied. But I'm not seeing these bad packets reaching the
blackhole device and getting dropped there. So they get dropped in
some other code paths. I believe we saw the same results with your
earlier patches.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 bpf-next 3/4] selftests/bpf: convert selftests using BTF-defined maps to new syntax
From: Song Liu @ 2019-06-28 18:25 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Andrii Nakryiko, Alexei Starovoitov, daniel@iogearbox.net,
bpf@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20190628152539.3014719-4-andriin@fb.com>
> On Jun 28, 2019, at 8:25 AM, Andrii Nakryiko <andriin@fb.com> wrote:
>
> Convert all the existing selftests that are already using BTF-defined
> maps to use new syntax (with no static data initialization).
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Song Liu <songliubraving@fb.com>
This looks cleaner!
> ---
> tools/testing/selftests/bpf/progs/bpf_flow.c | 28 +++----
> .../testing/selftests/bpf/progs/netcnt_prog.c | 20 ++---
> .../selftests/bpf/progs/socket_cookie_prog.c | 13 ++-
> .../selftests/bpf/progs/test_btf_newkv.c | 13 ++-
> .../bpf/progs/test_get_stack_rawtp.c | 39 ++++-----
> .../selftests/bpf/progs/test_global_data.c | 37 ++++-----
> tools/testing/selftests/bpf/progs/test_l4lb.c | 65 ++++++---------
> .../selftests/bpf/progs/test_l4lb_noinline.c | 65 ++++++---------
> .../selftests/bpf/progs/test_map_lock.c | 26 +++---
> .../bpf/progs/test_select_reuseport_kern.c | 67 ++++++---------
> .../bpf/progs/test_send_signal_kern.c | 26 +++---
> .../bpf/progs/test_sock_fields_kern.c | 78 +++++++-----------
> .../selftests/bpf/progs/test_spin_lock.c | 36 ++++-----
> .../bpf/progs/test_stacktrace_build_id.c | 55 +++++--------
> .../selftests/bpf/progs/test_stacktrace_map.c | 52 +++++-------
> .../selftests/bpf/progs/test_tcp_estats.c | 13 ++-
> .../selftests/bpf/progs/test_tcpbpf_kern.c | 26 +++---
> .../selftests/bpf/progs/test_tcpnotify_kern.c | 28 +++----
> tools/testing/selftests/bpf/progs/test_xdp.c | 26 +++---
> .../selftests/bpf/progs/test_xdp_noinline.c | 81 +++++++------------
> 20 files changed, 300 insertions(+), 494 deletions(-)
^ permalink raw reply
* Re: [PATCH v2 bpf-next 4/4] selftests/bpf: convert legacy BPF maps to BTF-defined ones
From: Song Liu @ 2019-06-28 18:26 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Andrii Nakryiko, Alexei Starovoitov, daniel@iogearbox.net,
bpf@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20190628152539.3014719-5-andriin@fb.com>
> On Jun 28, 2019, at 8:25 AM, Andrii Nakryiko <andriin@fb.com> wrote:
>
> Convert selftests that were originally left out and new ones added
> recently to consistently use BTF-defined maps.
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Song Liu <songliubraving@fb.com>
> ---
> .../selftests/bpf/progs/get_cgroup_id_kern.c | 26 ++---
> tools/testing/selftests/bpf/progs/pyperf.h | 90 +++++++-------
> .../selftests/bpf/progs/sample_map_ret0.c | 24 ++--
> .../bpf/progs/sockmap_verdict_prog.c | 48 ++++----
> .../testing/selftests/bpf/progs/strobemeta.h | 68 +++++------
> .../selftests/bpf/progs/test_map_in_map.c | 30 ++---
> .../testing/selftests/bpf/progs/test_obj_id.c | 12 +-
> .../selftests/bpf/progs/test_xdp_loop.c | 26 ++---
> .../selftests/bpf/progs/xdp_redirect_map.c | 12 +-
> .../testing/selftests/bpf/progs/xdping_kern.c | 12 +-
> .../selftests/bpf/test_queue_stack_map.h | 30 ++---
> .../testing/selftests/bpf/test_sockmap_kern.h | 110 +++++++++---------
> 12 files changed, 240 insertions(+), 248 deletions(-)
^ permalink raw reply
* [PATCH net-next 0/2] Fix batched event generation for mirred action
From: Roman Mashak @ 2019-06-28 18:30 UTC (permalink / raw)
To: davem; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri, Roman Mashak
When adding or deleting a batch of entries, the kernel sends upto
TCA_ACT_MAX_PRIO entries in an event to user space. However it does not
consider that the action sizes may vary and require different skb sizes.
For example :
% cat tc-batch.sh
TC="sudo /mnt/iproute2.git/tc/tc"
$TC actions flush action mirred
for i in `seq 1 $1`;
do
cmd="action mirred egress redirect dev lo index $i "
args=$args$cmd
done
$TC actions add $args
%
% ./tc-batch.sh 32
Error: Failed to fill netlink attributes while adding TC action.
We have an error talking to the kernel
%
patch 1 adds callback in tc_action_ops of mirred action, which calculates
the action size, and passes size to tcf_add_notify()/tcf_del_notify().
patch 2 updates the TDC test suite with relevant test cases.
Roman Mashak (2):
net sched: update mirred action for batched events operations
tc-testing: updated mirred action tests with batch create/delete
net/sched/act_mirred.c | 6 ++
.../tc-testing/tc-tests/actions/mirred.json | 94 ++++++++++++++++++++++
2 files changed, 100 insertions(+)
--
2.7.4
^ permalink raw reply
* [PATCH net-next 1/2] net sched: update mirred action for batched events operations
From: Roman Mashak @ 2019-06-28 18:30 UTC (permalink / raw)
To: davem; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri, Roman Mashak
In-Reply-To: <1561746618-29349-1-git-send-email-mrv@mojatatu.com>
Add get_fill_size() routine used to calculate the action size
when building a batch of events.
Signed-off-by: Roman Mashak <mrv@mojatatu.com>
---
net/sched/act_mirred.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index 58e7573dded4..2857c8dd4c04 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -411,6 +411,11 @@ static void tcf_mirred_put_dev(struct net_device *dev)
dev_put(dev);
}
+static size_t tcf_mirred_get_fill_size(const struct tc_action *act)
+{
+ return nla_total_size(sizeof(struct tc_mirred));
+}
+
static struct tc_action_ops act_mirred_ops = {
.kind = "mirred",
.id = TCA_ID_MIRRED,
@@ -422,6 +427,7 @@ static struct tc_action_ops act_mirred_ops = {
.init = tcf_mirred_init,
.walk = tcf_mirred_walker,
.lookup = tcf_mirred_search,
+ .get_fill_size = tcf_mirred_get_fill_size,
.size = sizeof(struct tcf_mirred),
.get_dev = tcf_mirred_get_dev,
.put_dev = tcf_mirred_put_dev,
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 2/2] tc-testing: updated mirred action tests with batch create/delete
From: Roman Mashak @ 2019-06-28 18:30 UTC (permalink / raw)
To: davem; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri, Roman Mashak
In-Reply-To: <1561746618-29349-1-git-send-email-mrv@mojatatu.com>
Signed-off-by: Roman Mashak <mrv@mojatatu.com>
---
.../tc-testing/tc-tests/actions/mirred.json | 94 ++++++++++++++++++++++
1 file changed, 94 insertions(+)
diff --git a/tools/testing/selftests/tc-testing/tc-tests/actions/mirred.json b/tools/testing/selftests/tc-testing/tc-tests/actions/mirred.json
index 6e5fb3d25681..2232b21e2510 100644
--- a/tools/testing/selftests/tc-testing/tc-tests/actions/mirred.json
+++ b/tools/testing/selftests/tc-testing/tc-tests/actions/mirred.json
@@ -459,5 +459,99 @@
"teardown": [
"$TC actions flush action mirred"
]
+ },
+ {
+ "id": "4749",
+ "name": "Add batch of 32 mirred redirect egress actions with cookie",
+ "category": [
+ "actions",
+ "mirred"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action mirred",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "bash -c \"for i in \\`seq 1 32\\`; do cmd=\\\"action mirred egress redirect dev lo index \\$i cookie aabbccddeeff112233445566778800a1 \\\"; args=\"\\$args\\$cmd\"; done && $TC actions add \\$args\"",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions list action mirred",
+ "matchPattern": "^[ \t]+index [0-9]+ ref",
+ "matchCount": "32",
+ "teardown": [
+ "$TC actions flush action mirred"
+ ]
+ },
+ {
+ "id": "5c69",
+ "name": "Delete batch of 32 mirred redirect egress actions",
+ "category": [
+ "actions",
+ "mirred"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action mirred",
+ 0,
+ 1,
+ 255
+ ],
+ "bash -c \"for i in \\`seq 1 32\\`; do cmd=\\\"action mirred egress redirect dev lo index \\$i \\\"; args=\\\"\\$args\\$cmd\\\"; done && $TC actions add \\$args\""
+ ],
+ "cmdUnderTest": "bash -c \"for i in \\`seq 1 32\\`; do cmd=\\\"action mirred index \\$i \\\"; args=\"\\$args\\$cmd\"; done && $TC actions del \\$args\"",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions list action mirred",
+ "matchPattern": "^[ \t]+index [0-9]+ ref",
+ "matchCount": "0",
+ "teardown": []
+ },
+ {
+ "id": "d3c0",
+ "name": "Add batch of 32 mirred mirror ingress actions with cookie",
+ "category": [
+ "actions",
+ "mirred"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action mirred",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "bash -c \"for i in \\`seq 1 32\\`; do cmd=\\\"action mirred ingress mirror dev lo index \\$i cookie aabbccddeeff112233445566778800a1 \\\"; args=\"\\$args\\$cmd\"; done && $TC actions add \\$args\"",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions list action mirred",
+ "matchPattern": "^[ \t]+index [0-9]+ ref",
+ "matchCount": "32",
+ "teardown": [
+ "$TC actions flush action mirred"
+ ]
+ },
+ {
+ "id": "e684",
+ "name": "Delete batch of 32 mirred mirror ingress actions",
+ "category": [
+ "actions",
+ "mirred"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action mirred",
+ 0,
+ 1,
+ 255
+ ],
+ "bash -c \"for i in \\`seq 1 32\\`; do cmd=\\\"action mirred ingress mirror dev lo index \\$i \\\"; args=\\\"\\$args\\$cmd\\\"; done && $TC actions add \\$args\""
+ ],
+ "cmdUnderTest": "bash -c \"for i in \\`seq 1 32\\`; do cmd=\\\"action mirred index \\$i \\\"; args=\"\\$args\\$cmd\"; done && $TC actions del \\$args\"",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions list action mirred",
+ "matchPattern": "^[ \t]+index [0-9]+ ref",
+ "matchCount": "0",
+ "teardown": []
}
]
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/2] tls: remove close callback sock unlock/lock and flush_sync
From: Jakub Kicinski @ 2019-06-28 18:31 UTC (permalink / raw)
To: John Fastabend; +Cc: daniel, ast, netdev, edumazet, bpf
In-Reply-To: <5d1620374694e_26962b1f6a4fa5c4f2@john-XPS-13-9370.notmuch>
On Fri, 28 Jun 2019 07:12:07 -0700, John Fastabend wrote:
> Yeah seems possible although never seen in my testing. So I'll
> move the test_bit() inside the lock and do a ctx check to ensure
> still have the reference.
>
> CPU 0 (free) CPU 1 (wq)
>
> lock(sk)
> lock(sk)
> set_bit()
> cancel_work()
> release
> ctx = tls_get_ctx(sk)
> unlikely(!ctx) <- we may have free'd
> test_bit()
> ...
> release()
>
> or
>
> CPU 0 (free) CPU 1 (wq)
>
> lock(sk)
> lock(sk)
> ctx = tls_get_ctx(sk)
> unlikely(!ctx)
> test_bit()
> ...
> release()
> set_bit()
> cancel_work()
> release
Hmm... perhaps it's cleanest to stop the work from scheduling before we
proceed?
close():
while (!test_and_set(SHED))
flush();
lock(sk);
...
We just need to move init work, no?
FWIW I never tested his async crypto stuff, I wonder if there is a way
to convince normal CPU crypto to pretend to be async?
^ permalink raw reply
* Re: [net-next 1/4] gve: Add basic driver framework for Compute Engine Virtual NIC
From: Jakub Kicinski @ 2019-06-28 18:46 UTC (permalink / raw)
To: Catherine Sullivan
Cc: netdev, Sagi Shahar, Jon Olson, Willem de Bruijn, Luigi Rizzo
In-Reply-To: <CAH_-1qzzWVKxDX3LaorsgYPjT5uhDgqdN3oMZtJ2p6AzDqRyXA@mail.gmail.com>
On Fri, 28 Jun 2019 10:52:27 -0700, Catherine Sullivan wrote:
> > > +if NET_VENDOR_GOOGLE
> > > +
> > > +config GVE
> > > + tristate "Google Virtual NIC (gVNIC) support"
> > > + depends on (PCI_MSI && X86)
> >
> > We usually prefer for drivers not to depend on the platform unless
> > really necessary, but IDK how that applies to the curious new world
> > of NICs nobody can buy :)
>
> This is the only platform it will ever need to run on so we would really
> prefer to not have to support others :)
I think the motivation is partially to force the uniform use of generic
APIs across the drivers, so that re-factoring of core code is easier.
Do you have any specific pain-points in mind where x86 dependency
simplifies things? If not I think it's a better default to not have it.
Not a big deal, though.
^ permalink raw reply
* Re: [PATCH V33 24/30] bpf: Restrict bpf when kernel lockdown is in confidentiality mode
From: Matthew Garrett @ 2019-06-28 18:47 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Stephen Smalley, James Morris, linux-security, LKML, Linux API,
David Howells, Alexei Starovoitov, Network Development,
Chun-Yi Lee, Daniel Borkmann, LSM List
In-Reply-To: <CALCETrXwt43w6rQY6zt0J_3HOaad=+E5PushJNdSOZDBuaYV+Q@mail.gmail.com>
On Thu, Jun 27, 2019 at 4:27 PM Andy Lutomirski <luto@kernel.org> wrote:
> They're really quite similar in my mind. Certainly some things in the
> "integrity" category give absolutely trivial control over the kernel
> (e.g. modules) while others make it quite challenging (ioperm), but
> the end result is very similar. And quite a few "confidentiality"
> things genuinely do allow all kernel memory to be read.
>
> I agree that finer-grained distinctions could be useful. My concern is
> that it's a tradeoff, and the other end of the tradeoff is an ABI
> stability issue. If someone decides down the road that some feature
> that is currently "integrity" can be split into a narrow "integrity"
> feature and a "confidentiality" feature then, if the user policy knows
> about the individual features, there's a risk of breaking people's
> systems. If we keep the fine-grained control, do we have a clear
> compatibility story?
My preference right now is to retain the fine-grained aspect of things
in the internal API, simply because it'll be more annoying to add it
back later if we want to. I don't want to expose it via the Lockdown
user facing API for the reasons you've described, but it's not
impossible that another LSM would find a way to do this reasonably.
Does it seem reasonable to punt this discussion out to the point where
another LSM tries to do something with this information, based on the
implementation they're attempting?
^ permalink raw reply
* Re: [PATCH net-next 02/12] net: hns3: enable DCB when TC num is one and pfc_en is non-zero
From: Willem de Bruijn @ 2019-06-28 18:47 UTC (permalink / raw)
To: Huazhong Tan
Cc: David Miller, Network Development, linux-kernel, salil.mehta,
yisen.zhuang, linuxarm, Yunsheng Lin, Peng Li
In-Reply-To: <1561722618-12168-3-git-send-email-tanhuazhong@huawei.com>
On Fri, Jun 28, 2019 at 7:53 AM Huazhong Tan <tanhuazhong@huawei.com> wrote:
>
> From: Yunsheng Lin <linyunsheng@huawei.com>
>
> Currently when TC num is one, the DCB will be disabled no matter if
> pfc_en is non-zero or not.
>
> This patch enables the DCB if pfc_en is non-zero, even when TC num
> is one.
>
> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> Signed-off-by: Peng Li <lipeng321@huawei.com>
> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
> index 9edae5f..cb2fb5a 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
> @@ -597,8 +597,10 @@ static void hclge_tm_tc_info_init(struct hclge_dev *hdev)
> hdev->tm_info.prio_tc[i] =
> (i >= hdev->tm_info.num_tc) ? 0 : i;
>
> - /* DCB is enabled if we have more than 1 TC */
> - if (hdev->tm_info.num_tc > 1)
> + /* DCB is enabled if we have more than 1 TC or pfc_en is
> + * non-zero.
> + */
> + if (hdev->tm_info.num_tc > 1 || hdev->tm_info.pfc_en)
small nit: comments that just repeat the condition are not very informative.
More helpful might be to explain why the DCB should be enabled in both
these cases. Though such detailed comments, if useful, are better left
to the commit message usually.
> hdev->flag |= HCLGE_FLAG_DCB_ENABLE;
> else
> hdev->flag &= ~HCLGE_FLAG_DCB_ENABLE;
> @@ -1388,6 +1390,19 @@ void hclge_tm_schd_info_update(struct hclge_dev *hdev, u8 num_tc)
> hclge_tm_schd_info_init(hdev);
> }
>
> +void hclge_tm_pfc_info_update(struct hclge_dev *hdev)
> +{
> + /* DCB is enabled if we have more than 1 TC or pfc_en is
> + * non-zero.
> + */
> + if (hdev->tm_info.num_tc > 1 || hdev->tm_info.pfc_en)
> + hdev->flag |= HCLGE_FLAG_DCB_ENABLE;
> + else
> + hdev->flag &= ~HCLGE_FLAG_DCB_ENABLE;
> +
> + hclge_pfc_info_init(hdev);
> +}
Avoid introducing this code duplication by defining a helper?
^ permalink raw reply
* Re: [PATCH 24/39] docs: driver-model: move it to the driver-api book
From: Jeff Kirsher @ 2019-06-28 18:53 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet,
Linus Walleij, Bartosz Golaszewski, Jean Delvare, Guenter Roeck,
Harry Wei, Alex Shi, Greg Kroah-Hartman, Rafael J. Wysocki,
David S. Miller, David Kershner, Julia Lawall, Gilles Muller,
Nicolas Palix, Michal Marek, linux-gpio, linux-hwmon,
intel-wired-lan, netdev, sparmaintainer, devel, cocci
In-Reply-To: <920ff36c66233113b1825ab504fe675ed5a5bd7b.1561724493.git.mchehab+samsung@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2907 bytes --]
On Fri, 2019-06-28 at 09:30 -0300, Mauro Carvalho Chehab wrote:
> The audience for the Kernel driver-model is clearly Kernel hackers.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
For the 'ice' driver changes.
> ---
> Documentation/{ => driver-api}/driver-model/binding.rst | 0
> Documentation/{ => driver-api}/driver-model/bus.rst | 0
> Documentation/{ => driver-api}/driver-model/class.rst | 0
> .../{ => driver-api}/driver-model/design-patterns.rst | 0
> Documentation/{ => driver-api}/driver-model/device.rst | 0
> Documentation/{ => driver-api}/driver-model/devres.rst | 0
> Documentation/{ => driver-api}/driver-model/driver.rst | 0
> Documentation/{ => driver-api}/driver-model/index.rst | 2 --
> Documentation/{ => driver-api}/driver-model/overview.rst | 0
> Documentation/{ => driver-api}/driver-model/platform.rst | 0
> Documentation/{ => driver-api}/driver-model/porting.rst | 2 +-
> Documentation/driver-api/gpio/driver.rst | 2 +-
> Documentation/driver-api/index.rst | 1 +
> Documentation/eisa.txt | 4 ++--
> Documentation/filesystems/sysfs.txt | 2 +-
> Documentation/hwmon/submitting-patches.rst | 2 +-
> Documentation/translations/zh_CN/filesystems/sysfs.txt | 2 +-
> drivers/base/platform.c | 2 +-
> drivers/gpio/gpio-cs5535.c | 2 +-
> drivers/net/ethernet/intel/ice/ice_main.c | 2 +-
> drivers/staging/unisys/Documentation/overview.txt | 4 ++--
> include/linux/device.h | 2 +-
> include/linux/platform_device.h | 2 +-
> scripts/coccinelle/free/devm_free.cocci | 2 +-
> 24 files changed, 16 insertions(+), 17 deletions(-)
> rename Documentation/{ => driver-api}/driver-model/binding.rst (100%)
> rename Documentation/{ => driver-api}/driver-model/bus.rst (100%)
> rename Documentation/{ => driver-api}/driver-model/class.rst (100%)
> rename Documentation/{ => driver-api}/driver-model/design-patterns.rst
> (100%)
> rename Documentation/{ => driver-api}/driver-model/device.rst (100%)
> rename Documentation/{ => driver-api}/driver-model/devres.rst (100%)
> rename Documentation/{ => driver-api}/driver-model/driver.rst (100%)
> rename Documentation/{ => driver-api}/driver-model/index.rst (96%)
> rename Documentation/{ => driver-api}/driver-model/overview.rst (100%)
> rename Documentation/{ => driver-api}/driver-model/platform.rst (100%)
> rename Documentation/{ => driver-api}/driver-model/porting.rst (99%)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] lpfc: reduce stack size with CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE
From: James Smart @ 2019-06-28 18:57 UTC (permalink / raw)
To: Arnd Bergmann, Kees Cook, Dick Kennedy, James E.J. Bottomley,
Martin K. Petersen
Cc: Larry Finger, Florian Schilhabel, Greg Kroah-Hartman,
David S . Miller, Wensong Zhang, Simon Horman, Julian Anastasov,
Pablo Neira Ayuso, James Morris, linux-scsi, linux-kernel, devel,
netdev, lvs-devel, netfilter-devel, coreteam, Ard Biesheuvel,
Hannes Reinecke, Willy Tarreau, Silvio Cesare
In-Reply-To: <20190628123819.2785504-2-arnd@arndb.de>
On 6/28/2019 5:37 AM, Arnd Bergmann wrote:
> The lpfc_debug_dump_all_queues() function repeatedly calls into
> lpfc_debug_dump_qe(), which has a temporary 128 byte buffer.
> This was fine before the introduction of CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE
> because each instance could occupy the same stack slot. However,
> now they each get their own copy, which leads to a huge increase
> in stack usage as seen from the compiler warning:
>
> drivers/scsi/lpfc/lpfc_debugfs.c: In function 'lpfc_debug_dump_all_queues':
> drivers/scsi/lpfc/lpfc_debugfs.c:6474:1: error: the frame size of 1712 bytes is larger than 100 bytes [-Werror=frame-larger-than=]
>
> Avoid this by not marking lpfc_debug_dump_qe() as inline so the
> compiler can choose to emit a static version of this function
> when it's needed or otherwise silently drop it. As an added benefit,
> not inlining multiple copies of this function means we save several
> kilobytes of .text section, reducing the file size from 47kb to 43.
>
> It is somewhat unusual to have a function that is static but not
> inline in a header file, but this does not cause problems here
> because it is only used by other inline functions. It would
> however seem reasonable to move all the lpfc_debug_dump_* functions
> into lpfc_debugfs.c and not mark them inline as a later cleanup.
I agree with this cleanup.
>
> Fixes: 81a56f6dcd20 ("gcc-plugins: structleak: Generalize to all variable types")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/scsi/lpfc/lpfc_debugfs.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
Reviewed-by: James Smart <james.smart@broadcom.com>
-- james
^ permalink raw reply
* Re: memory leak in pppoe_sendmsg
From: syzbot @ 2019-06-28 18:58 UTC (permalink / raw)
To: davem, linux-kernel, mostrows, netdev, syzkaller-bugs
In-Reply-To: <000000000000d981f1058a26e1a8@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: c84afab0 Merge git://git.kernel.org/pub/scm/linux/kernel/g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=164241d9a00000
kernel config: https://syzkaller.appspot.com/x/.config?x=1db8bd6825f9661c
dashboard link: https://syzkaller.appspot.com/bug?extid=6bdfd184eac7709e5cc9
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=126c5f8da00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17cdd4eba00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+6bdfd184eac7709e5cc9@syzkaller.appspotmail.com
executing program
BUG: memory leak
unreferenced object 0xffff888115942b00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.150s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888113199800 (size 512):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.150s)
hex dump (first 32 bytes):
00 00 aa aa aa aa aa 0a aa aa aa aa aa 0a 88 64 ...............d
11 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000059b95d3a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000059b95d3a>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000059b95d3a>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000059b95d3a>] kmem_cache_alloc_node_trace+0x15b/0x2a0
mm/slab.c:3597
[<00000000fb30d91c>] __do_kmalloc_node mm/slab.c:3619 [inline]
[<00000000fb30d91c>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3634
[<0000000021df94db>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:138
[<000000003bd62b3e>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:206
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881130b9e00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955399 (age 32.140s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881131dcf00 (size 224):
comm "syz-executor057", pid 7192, jiffies 4294955408 (age 32.050s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 20 2d 13 81 88 ff ff ......... -.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888115942b00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.220s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888113199800 (size 512):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.220s)
hex dump (first 32 bytes):
00 00 aa aa aa aa aa 0a aa aa aa aa aa 0a 88 64 ...............d
11 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000059b95d3a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000059b95d3a>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000059b95d3a>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000059b95d3a>] kmem_cache_alloc_node_trace+0x15b/0x2a0
mm/slab.c:3597
[<00000000fb30d91c>] __do_kmalloc_node mm/slab.c:3619 [inline]
[<00000000fb30d91c>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3634
[<0000000021df94db>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:138
[<000000003bd62b3e>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:206
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881130b9e00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955399 (age 32.210s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881131dcf00 (size 224):
comm "syz-executor057", pid 7192, jiffies 4294955408 (age 32.120s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 20 2d 13 81 88 ff ff ......... -.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888115942b00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.290s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888113199800 (size 512):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.290s)
hex dump (first 32 bytes):
00 00 aa aa aa aa aa 0a aa aa aa aa aa 0a 88 64 ...............d
11 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000059b95d3a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000059b95d3a>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000059b95d3a>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000059b95d3a>] kmem_cache_alloc_node_trace+0x15b/0x2a0
mm/slab.c:3597
[<00000000fb30d91c>] __do_kmalloc_node mm/slab.c:3619 [inline]
[<00000000fb30d91c>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3634
[<0000000021df94db>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:138
[<000000003bd62b3e>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:206
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881130b9e00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955399 (age 32.280s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881131dcf00 (size 224):
comm "syz-executor057", pid 7192, jiffies 4294955408 (age 32.190s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 20 2d 13 81 88 ff ff ......... -.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888115942b00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.350s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888113199800 (size 512):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.350s)
hex dump (first 32 bytes):
00 00 aa aa aa aa aa 0a aa aa aa aa aa 0a 88 64 ...............d
11 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000059b95d3a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000059b95d3a>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000059b95d3a>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000059b95d3a>] kmem_cache_alloc_node_trace+0x15b/0x2a0
mm/slab.c:3597
[<00000000fb30d91c>] __do_kmalloc_node mm/slab.c:3619 [inline]
[<00000000fb30d91c>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3634
[<0000000021df94db>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:138
[<000000003bd62b3e>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:206
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881130b9e00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955399 (age 32.340s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881131dcf00 (size 224):
comm "syz-executor057", pid 7192, jiffies 4294955408 (age 32.250s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 20 2d 13 81 88 ff ff ......... -.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888115942b00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.420s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888113199800 (size 512):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.420s)
hex dump (first 32 bytes):
00 00 aa aa aa aa aa 0a aa aa aa aa aa 0a 88 64 ...............d
11 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000059b95d3a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000059b95d3a>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000059b95d3a>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000059b95d3a>] kmem_cache_alloc_node_trace+0x15b/0x2a0
mm/slab.c:3597
[<00000000fb30d91c>] __do_kmalloc_node mm/slab.c:3619 [inline]
[<00000000fb30d91c>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3634
[<0000000021df94db>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:138
[<000000003bd62b3e>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:206
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881130b9e00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955399 (age 32.410s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881131dcf00 (size 224):
comm "syz-executor057", pid 7192, jiffies 4294955408 (age 32.320s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 20 2d 13 81 88 ff ff ......... -.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888115942b00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.480s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888113199800 (size 512):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.480s)
hex dump (first 32 bytes):
00 00 aa aa aa aa aa 0a aa aa aa aa aa 0a 88 64 ...............d
11 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000059b95d3a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000059b95d3a>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000059b95d3a>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000059b95d3a>] kmem_cache_alloc_node_trace+0x15b/0x2a0
mm/slab.c:3597
[<00000000fb30d91c>] __do_kmalloc_node mm/slab.c:3619 [inline]
[<00000000fb30d91c>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3634
[<0000000021df94db>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:138
[<000000003bd62b3e>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:206
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881130b9e00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955399 (age 32.470s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881131dcf00 (size 224):
comm "syz-executor057", pid 7192, jiffies 4294955408 (age 32.380s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 20 2d 13 81 88 ff ff ......... -.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888115942b00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.550s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888113199800 (size 512):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.550s)
hex dump (first 32 bytes):
00 00 aa aa aa aa aa 0a aa aa aa aa aa 0a 88 64 ...............d
11 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000059b95d3a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000059b95d3a>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000059b95d3a>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000059b95d3a>] kmem_cache_alloc_node_trace+0x15b/0x2a0
mm/slab.c:3597
[<00000000fb30d91c>] __do_kmalloc_node mm/slab.c:3619 [inline]
[<00000000fb30d91c>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3634
[<0000000021df94db>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:138
[<000000003bd62b3e>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:206
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881130b9e00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955399 (age 32.540s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881131dcf00 (size 224):
comm "syz-executor057", pid 7192, jiffies 4294955408 (age 32.450s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 20 2d 13 81 88 ff ff ......... -.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888115942b00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.610s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888113199800 (size 512):
comm "syz-executor057", pid 7184, jiffies 4294955398 (age 32.610s)
hex dump (first 32 bytes):
00 00 aa aa aa aa aa 0a aa aa aa aa aa 0a 88 64 ...............d
11 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000059b95d3a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000059b95d3a>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000059b95d3a>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000059b95d3a>] kmem_cache_alloc_node_trace+0x15b/0x2a0
mm/slab.c:3597
[<00000000fb30d91c>] __do_kmalloc_node mm/slab.c:3619 [inline]
[<00000000fb30d91c>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3634
[<0000000021df94db>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:138
[<000000003bd62b3e>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:206
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881130b9e00 (size 224):
comm "syz-executor057", pid 7184, jiffies 4294955399 (age 32.600s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 08 58 13 81 88 ff ff ..........X.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881131dcf00 (size 224):
comm "syz-executor057", pid 7192, jiffies 4294955408 (age 32.510s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 20 2d 13 81 88 ff ff ......... -.....
backtrace:
[<0000000025f85882>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000025f85882>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000025f85882>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000025f85882>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<000000005b601dc8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:194
[<000000003813d44c>] alloc_skb include/linux/skbuff.h:1054 [inline]
[<000000003813d44c>] sock_wmalloc+0x4f/0x80 net/core/sock.c:2071
[<000000003f8b1014>] pppoe_sendmsg+0xd0/0x250
drivers/net/ppp/pppoe.c:866
[<000000003841750c>] sock_sendmsg_nosec net/socket.c:646 [inline]
[<000000003841750c>] sock_sendmsg+0x54/0x70 net/socket.c:665
[<00000000f75dab14>] ___sys_sendmsg+0x194/0x3c0 net/socket.c:2286
[<000000004ca9b6e5>] __sys_sendmmsg+0xf4/0x270 net/socket.c:2381
[<00000000e008d506>] __do_sys_sendmmsg net/socket.c:2410 [inline]
[<00000000e008d506>] __se_sys_sendmmsg net/socket.c:2407 [inline]
[<00000000e008d506>] __x64_sys_sendmmsg+0x28/0x30 net/socket.c:2407
[<00000000f738b123>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000081d80325>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
^ permalink raw reply
* Re: [PATCH 24/43] docs: leds: convert to ReST
From: Jacek Anaszewski @ 2019-06-28 19:01 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet,
Vadim Pasternak, Pavel Machek, Dan Murphy, Pablo Neira Ayuso,
Jozsef Kadlecsik, Florian Westphal, David S. Miller, linux-leds,
netfilter-devel, coreteam, netdev
In-Reply-To: <2fecbe9a9cefda64771b43c5fc67495d897dd722.1561723980.git.mchehab+samsung@kernel.org>
Hi Mauro,
On 6/28/19 2:20 PM, Mauro Carvalho Chehab wrote:
> Rename the leds documentation files to ReST, add an
> index for them and adjust in order to produce a nice html
> output via the Sphinx build system.
>
> At its new index.rst, let's add a :orphan: while this is not linked to
> the main index.rst file, in order to avoid build warnings.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> Acked-by: Pavel Machek <pavel@ucw.cz>
> ---
> Documentation/laptops/thinkpad-acpi.txt | 4 +-
> Documentation/leds/index.rst | 25 ++
> .../leds/{leds-blinkm.txt => leds-blinkm.rst} | 64 ++---
> ...s-class-flash.txt => leds-class-flash.rst} | 49 ++--
> .../leds/{leds-class.txt => leds-class.rst} | 15 +-
> .../leds/{leds-lm3556.txt => leds-lm3556.rst} | 100 ++++++--
> .../leds/{leds-lp3944.txt => leds-lp3944.rst} | 23 +-
> Documentation/leds/leds-lp5521.rst | 115 +++++++++
> Documentation/leds/leds-lp5521.txt | 101 --------
> Documentation/leds/leds-lp5523.rst | 147 ++++++++++++
> Documentation/leds/leds-lp5523.txt | 130 ----------
> Documentation/leds/leds-lp5562.rst | 137 +++++++++++
> Documentation/leds/leds-lp5562.txt | 120 ----------
> Documentation/leds/leds-lp55xx.rst | 224 ++++++++++++++++++
> Documentation/leds/leds-lp55xx.txt | 194 ---------------
> Documentation/leds/leds-mlxcpld.rst | 118 +++++++++
> Documentation/leds/leds-mlxcpld.txt | 110 ---------
> ...edtrig-oneshot.txt => ledtrig-oneshot.rst} | 11 +-
> ...ig-transient.txt => ledtrig-transient.rst} | 63 +++--
> ...edtrig-usbport.txt => ledtrig-usbport.rst} | 11 +-
> Documentation/leds/{uleds.txt => uleds.rst} | 5 +-
> MAINTAINERS | 2 +-
> drivers/leds/trigger/Kconfig | 2 +-
> drivers/leds/trigger/ledtrig-transient.c | 2 +-
> net/netfilter/Kconfig | 2 +-
> 25 files changed, 996 insertions(+), 778 deletions(-)
> create mode 100644 Documentation/leds/index.rst
> rename Documentation/leds/{leds-blinkm.txt => leds-blinkm.rst} (57%)
> rename Documentation/leds/{leds-class-flash.txt => leds-class-flash.rst} (74%)
> rename Documentation/leds/{leds-class.txt => leds-class.rst} (92%)
> rename Documentation/leds/{leds-lm3556.txt => leds-lm3556.rst} (70%)
> rename Documentation/leds/{leds-lp3944.txt => leds-lp3944.rst} (78%)
> create mode 100644 Documentation/leds/leds-lp5521.rst
> delete mode 100644 Documentation/leds/leds-lp5521.txt
> create mode 100644 Documentation/leds/leds-lp5523.rst
> delete mode 100644 Documentation/leds/leds-lp5523.txt
> create mode 100644 Documentation/leds/leds-lp5562.rst
> delete mode 100644 Documentation/leds/leds-lp5562.txt
> create mode 100644 Documentation/leds/leds-lp55xx.rst
> delete mode 100644 Documentation/leds/leds-lp55xx.txt
> create mode 100644 Documentation/leds/leds-mlxcpld.rst
> delete mode 100644 Documentation/leds/leds-mlxcpld.txt
> rename Documentation/leds/{ledtrig-oneshot.txt => ledtrig-oneshot.rst} (90%)
> rename Documentation/leds/{ledtrig-transient.txt => ledtrig-transient.rst} (81%)
> rename Documentation/leds/{ledtrig-usbport.txt => ledtrig-usbport.rst} (86%)
> rename Documentation/leds/{uleds.txt => uleds.rst} (95%)
Patches 4/9 and 24/43 applied to the for-next branch of linux-leds.git.
Thanks!
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
From: Song Liu @ 2019-06-28 19:04 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Networking, bpf, Alexei Starovoitov, Daniel Borkmann, Kernel Team,
Lorenz Bauer, Jann Horn, Greg KH, linux-abi@vger.kernel.org,
kees@chromium.org
In-Reply-To: <21894f45-70d8-dfca-8c02-044f776c5e05@kernel.org>
Hi Andy,
> On Jun 27, 2019, at 4:40 PM, Andy Lutomirski <luto@kernel.org> wrote:
>
> On 6/27/19 1:19 PM, Song Liu wrote:
>> This patch introduce unprivileged BPF access. The access control is
>> achieved via device /dev/bpf. Users with write access to /dev/bpf are able
>> to call sys_bpf().
>> Two ioctl command are added to /dev/bpf:
>> The two commands enable/disable permission to call sys_bpf() for current
>> task. This permission is noted by bpf_permitted in task_struct. This
>> permission is inherited during clone(CLONE_THREAD).
>> Helper function bpf_capable() is added to check whether the task has got
>> permission via /dev/bpf.
>
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index 0e079b2298f8..79dc4d641cf3 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@ -9134,7 +9134,7 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr *attr,
>> env->insn_aux_data[i].orig_idx = i;
>> env->prog = *prog;
>> env->ops = bpf_verifier_ops[env->prog->type];
>> - is_priv = capable(CAP_SYS_ADMIN);
>> + is_priv = bpf_capable(CAP_SYS_ADMIN);
>
> Huh? This isn't a hardening measure -- the "is_priv" verifier mode allows straight-up leaks of private kernel state to user mode.
>
> (For that matter, the pending lockdown stuff should possibly consider this a "confidentiality" issue.)
>
>
> I have a bigger issue with this patch, though: it's a really awkward way to pretend to have capabilities. For bpf, it seems like you could make this be a *real* capability without too much pain since there's only one syscall there. Just find a way to pass an fd to /dev/bpf into the syscall. If this means you need a new bpf_with_cap() syscall that takes an extra argument, so be it. The old bpf() syscall can just translate to bpf_with_cap(..., -1).
>
> For a while, I've considered a scheme I call "implicit rights". There would be a directory in /dev called /dev/implicit_rights. This would either be part of devtmpfs or a whole new filesystem -- it would *not* be any other filesystem. The contents would be files that can't be read or written and exist only in memory. You create them with a privileged syscall. Certain actions that are sensitive but not at the level of CAP_SYS_ADMIN (use of large-attack-surface bpf stuff, creation of user namespaces, profiling the kernel, etc) could require an "implicit right". When you do them, if you don't have CAP_SYS_ADMIN, the kernel would do a path walk for, say, /dev/implicit_rights/bpf and, if the object exists, can be opened, and actually refers to the "bpf" rights object, then the action is allowed. Otherwise it's denied.
>
> This is extensible, and it doesn't require the rather ugly per-task state of whether it's enabled.
>
> For things like creation of user namespaces, there's an existing API, and the default is that it works without privilege. Switching it to an implicit right has the benefit of not requiring code changes to programs that already work as non-root.
>
> But, for BPF in particular, this type of compatibility issue doesn't exist now. You already can't use most eBPF functionality without privilege. New bpf-using programs meant to run without privilege are *new*, so they can use a new improved API. So, rather than adding this obnoxious ioctl, just make the API explicit, please.
>
> Also, please cc: linux-abi next time.
Thanks for your inputs.
I think we need to clarify the use case here. In this case, we are NOT
thinking about creating new tools for unprivileged users. Instead, we
would like to use existing tools without root. Currently, users of these
tools have to run them with root or sudo. But they would prefer not to.
On the kernel side, we are not planning provides a subset of safe
features for unprivileged users. The permission here is all-or-nothing.
Introducing bpf_with_cap() syscall means we need teach these tools to
manage the fd, and use the new API when necessary. This is clearly not
easy. On the other hand, current solution is easy to adopt for most
tools (see 4/4 of this set).
Also, for this use case, I don't see bpf_with_cap() more secure than
this patch.
Thanks,
Song
^ permalink raw reply
* Re: [PATCH net-next v2 06/10] net: stmmac: Do not disable interrupts when cleaning TX
From: Willem de Bruijn @ 2019-06-28 19:08 UTC (permalink / raw)
To: Jose Abreu
Cc: linux-kernel, Network Development, Joao Pinto, David S . Miller,
Giuseppe Cavallaro, Alexandre Torgue
In-Reply-To: <e4e9ee4cb9c3e7957fe0a09f88b20bc011e2bd4c.1561706801.git.joabreu@synopsys.com>
On Fri, Jun 28, 2019 at 3:30 AM Jose Abreu <Jose.Abreu@synopsys.com> wrote:
>
> This is a performance killer and anyways the interrupts are being
> disabled by RX NAPI so no need to disable them again.
By the
if ((status & handle_rx) && (chan < priv->plat->rx_queues_to_use)) {
stmmac_disable_dma_irq(priv, priv->ioaddr, chan);
napi_schedule_irqoff(&ch->rx_napi);
}
branch directly above? If so, is it possible to have fewer rx than tx
queues and miss this?
this logic seems more complex than needed?
if (status)
status |= handle_rx | handle_tx;
if ((status & handle_rx) && (chan < priv->plat->rx_queues_to_use)) {
}
if ((status & handle_tx) && (chan < priv->plat->tx_queues_to_use)) {
}
status & handle_rx implies status & handle_tx and vice versa.
>
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
> Cc: Joao Pinto <jpinto@synopsys.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 4a5941caaadc..e8f3e76889c8 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2061,10 +2061,8 @@ static int stmmac_napi_check(struct stmmac_priv *priv, u32 chan)
> napi_schedule_irqoff(&ch->rx_napi);
> }
>
> - if ((status & handle_tx) && (chan < priv->plat->tx_queues_to_use)) {
> - stmmac_disable_dma_irq(priv, priv->ioaddr, chan);
> + if ((status & handle_tx) && (chan < priv->plat->tx_queues_to_use))
> napi_schedule_irqoff(&ch->tx_napi);
> - }
>
> return status;
> }
> @@ -3570,8 +3568,8 @@ static int stmmac_napi_poll_tx(struct napi_struct *napi, int budget)
> work_done = stmmac_tx_clean(priv, DMA_TX_SIZE, chan);
> work_done = min(work_done, budget);
>
> - if (work_done < budget && napi_complete_done(napi, work_done))
> - stmmac_enable_dma_irq(priv, priv->ioaddr, chan);
> + if (work_done < budget)
> + napi_complete_done(napi, work_done);
It does seem odd that stmmac_napi_poll_rx and stmmac_napi_poll_tx both
call stmmac_enable_dma_irq(..) independent of the other. Shouldn't the
IRQ remain masked while either is active or scheduled? That is almost
what this patch does, though not exactly.
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
From: Song Liu @ 2019-06-28 19:10 UTC (permalink / raw)
To: Lorenz Bauer
Cc: Networking, bpf, Alexei Starovoitov, Daniel Borkmann, Kernel Team,
Jann Horn, gregkh@linuxfoundation.org
In-Reply-To: <CACAyw98RvDc+i3gpgnAtnM0ojAfQ-mHvzRXFRUcgkEPr3K4G-g@mail.gmail.com>
> On Jun 28, 2019, at 2:01 AM, Lorenz Bauer <lmb@cloudflare.com> wrote:
>
> On Thu, 27 Jun 2019 at 21:19, Song Liu <songliubraving@fb.com> wrote:
>>
>> This patch introduce unprivileged BPF access. The access control is
>> achieved via device /dev/bpf. Users with write access to /dev/bpf are able
>> to call sys_bpf().
>>
>> Two ioctl command are added to /dev/bpf:
>>
>> The two commands enable/disable permission to call sys_bpf() for current
>> task. This permission is noted by bpf_permitted in task_struct. This
>> permission is inherited during clone(CLONE_THREAD).
>
> If I understand it correctly, a process would have to open /dev/bpf before
> spawning other threads for this to work?
>
> That still wouldn't work for Go I'm afraid. The runtime creates and destroys
> threads on an ad-hoc basis, and there is no way to "initialize" in the
> first thread.
There should be a master thread, no? Can we do that from the master thread at
the beginning of the execution?
> With the API as is, any Go wrapper wishing to use this would have to do the
> following _for every BPF syscall_:
>
> 1. Use runtime.LockOSThread() to prevent the scheduler from moving the
> goroutine.
> 2. Open /dev/bpf to set the bit in current_task
> 3. Execute the syscall
> 4. Call runtime.UnlockOSThread()
>
> Note that calling into C code via CGo doesn't change this. Is it not possible to
> set the bit on all processes in the current thread group?
I think that's possible, with some extra work. And there will be overhead, as
we need to atomic operation for all these processes. I would rather not to this
path unless it is really necessary.
Thanks,
Song
^ permalink raw reply
* Re: [PATCH 1/1] net: dsa: b53: Disable all ports on setup
From: Vivien Didelot @ 2019-06-28 19:24 UTC (permalink / raw)
To: Florian Fainelli
Cc: Benedikt Spranger, netdev, Sebastian Andrzej Siewior,
Kurt Kanzenbach, Andrew Lunn
In-Reply-To: <d5df00f5-599c-56ce-f93e-31587d16145a@gmail.com>
On Fri, 28 Jun 2019 10:23:06 -0700, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 6/28/19 9:58 AM, Benedikt Spranger wrote:
> > A b53 device may configured through an external EEPROM like the switch
> > device on the Lamobo R1 router board. The configuration of a port may
> > therefore differ from the reset configuration of the switch.
> >
> > The switch configuration reported by the DSA subsystem is different until
> > the port is configured by DSA i.e. a port can be active, while the DSA
> > subsystem reports the port is inactive. Disable all ports and not only
> > the unused ones to put all ports into a well defined state.
> >
> > Signed-off-by: Benedikt Spranger <b.spranger@linutronix.de>
>
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Makes sense, in fact, that should probably be moved to the DSA core at
> some point (wink wink Vivien).
On it!
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: fix precision tracking
From: Andrii Nakryiko @ 2019-06-28 19:33 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Daniel Borkmann, Networking, bpf, Kernel Team
In-Reply-To: <20190628162409.2513499-1-ast@kernel.org>
On Fri, Jun 28, 2019 at 9:25 AM Alexei Starovoitov <ast@kernel.org> wrote:
>
> When equivalent state is found the current state needs to propagate precision marks.
> Otherwise the verifier will prune the search incorrectly.
>
> There is a price for correctness:
> before before broken fixed
> cnst spill precise precise
> bpf_lb-DLB_L3.o 1923 8128 1863 1898
> bpf_lb-DLB_L4.o 3077 6707 2468 2666
> bpf_lb-DUNKNOWN.o 1062 1062 544 544
> bpf_lxc-DDROP_ALL.o 166729 380712 22629 36823
> bpf_lxc-DUNKNOWN.o 174607 440652 28805 45325
> bpf_netdev.o 8407 31904 6801 7002
> bpf_overlay.o 5420 23569 4754 4858
> bpf_lxc_jit.o 39389 359445 50925 69631
> Overall precision tracking is still very effective.
>
> Fixes: b5dc0163d8fd ("bpf: precise scalar_value tracking")
> Reported-by: Lawrence Brakmo <brakmo@fb.com>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> ---
Acked-by: Andrii Nakryiko <andriin@fb.com>
> Sending the fix early w/o tests, since I'm traveling.
> Will add proper tests when I'm back.
> ---
> kernel/bpf/verifier.c | 121 +++++++++++++++++++++++++++++++++++++-----
> 1 file changed, 107 insertions(+), 14 deletions(-)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 6b5623d320f9..62afc4058ced 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -1659,16 +1659,18 @@ static void mark_all_scalars_precise(struct bpf_verifier_env *env,
> }
> }
>
> -static int mark_chain_precision(struct bpf_verifier_env *env, int regno)
> +static int __mark_chain_precision(struct bpf_verifier_env *env, int regno,
> + int spi)
> {
> struct bpf_verifier_state *st = env->cur_state;
> int first_idx = st->first_insn_idx;
> int last_idx = env->insn_idx;
> struct bpf_func_state *func;
> struct bpf_reg_state *reg;
> - u32 reg_mask = 1u << regno;
> - u64 stack_mask = 0;
> + u32 reg_mask = regno >= 0 ? 1u << regno : 0;
> + u64 stack_mask = spi >= 0 ? 1ull << spi : 0;
> bool skip_first = true;
> + bool new_marks = false;
> int i, err;
>
> if (!env->allow_ptr_leaks)
> @@ -1676,18 +1678,43 @@ static int mark_chain_precision(struct bpf_verifier_env *env, int regno)
> return 0;
>
> func = st->frame[st->curframe];
> - reg = &func->regs[regno];
> - if (reg->type != SCALAR_VALUE) {
> - WARN_ONCE(1, "backtracing misuse");
> - return -EFAULT;
> + if (regno >= 0) {
> + reg = &func->regs[regno];
> + if (reg->type != SCALAR_VALUE) {
> + WARN_ONCE(1, "backtracing misuse");
> + return -EFAULT;
> + }
> + if (!reg->precise)
> + new_marks = true;
> + else
> + reg_mask = 0;
> + reg->precise = true;
> }
> - if (reg->precise)
> - return 0;
> - func->regs[regno].precise = true;
>
> + while (spi >= 0) {
> + if (func->stack[spi].slot_type[0] != STACK_SPILL) {
> + stack_mask = 0;
> + break;
> + }
> + reg = &func->stack[spi].spilled_ptr;
> + if (reg->type != SCALAR_VALUE) {
> + stack_mask = 0;
> + break;
> + }
> + if (!reg->precise)
> + new_marks = true;
> + else
> + stack_mask = 0;
> + reg->precise = true;
> + break;
> + }
> +
> + if (!new_marks)
> + return 0;
> + if (!reg_mask && !stack_mask)
> + return 0;
> for (;;) {
> DECLARE_BITMAP(mask, 64);
> - bool new_marks = false;
> u32 history = st->jmp_history_cnt;
>
> if (env->log.level & BPF_LOG_LEVEL)
> @@ -1730,12 +1757,15 @@ static int mark_chain_precision(struct bpf_verifier_env *env, int regno)
> if (!st)
> break;
>
> + new_marks = false;
> func = st->frame[st->curframe];
> bitmap_from_u64(mask, reg_mask);
> for_each_set_bit(i, mask, 32) {
> reg = &func->regs[i];
> - if (reg->type != SCALAR_VALUE)
> + if (reg->type != SCALAR_VALUE) {
> + reg_mask &= ~(1u << i);
> continue;
> + }
> if (!reg->precise)
> new_marks = true;
> reg->precise = true;
> @@ -1756,11 +1786,15 @@ static int mark_chain_precision(struct bpf_verifier_env *env, int regno)
> return -EFAULT;
> }
>
> - if (func->stack[i].slot_type[0] != STACK_SPILL)
> + if (func->stack[i].slot_type[0] != STACK_SPILL) {
> + stack_mask &= ~(1ull << i);
> continue;
> + }
> reg = &func->stack[i].spilled_ptr;
> - if (reg->type != SCALAR_VALUE)
> + if (reg->type != SCALAR_VALUE) {
> + stack_mask &= ~(1ull << i);
> continue;
> + }
> if (!reg->precise)
> new_marks = true;
> reg->precise = true;
> @@ -1772,6 +1806,8 @@ static int mark_chain_precision(struct bpf_verifier_env *env, int regno)
> reg_mask, stack_mask);
> }
>
> + if (!reg_mask && !stack_mask)
> + break;
> if (!new_marks)
> break;
>
> @@ -1781,6 +1817,15 @@ static int mark_chain_precision(struct bpf_verifier_env *env, int regno)
> return 0;
> }
>
> +static int mark_chain_precision(struct bpf_verifier_env *env, int regno)
> +{
> + return __mark_chain_precision(env, regno, -1);
> +}
> +
> +static int mark_chain_precision_stack(struct bpf_verifier_env *env, int spi)
> +{
> + return __mark_chain_precision(env, -1, spi);
> +}
>
> static bool is_spillable_regtype(enum bpf_reg_type type)
> {
> @@ -7114,6 +7159,46 @@ static int propagate_liveness(struct bpf_verifier_env *env,
> return 0;
> }
>
> +/* find precise scalars in the previous equivalent state and
> + * propagate them into the current state
> + */
> +static int propagate_precision(struct bpf_verifier_env *env,
> + const struct bpf_verifier_state *old)
> +{
> + struct bpf_reg_state *state_reg;
> + struct bpf_func_state *state;
> + int i, err = 0;
> +
> + state = old->frame[old->curframe];
> + state_reg = state->regs;
> + for (i = 0; i < BPF_REG_FP; i++, state_reg++) {
> + if (state_reg->type != SCALAR_VALUE ||
> + !state_reg->precise)
> + continue;
> + if (env->log.level & BPF_LOG_LEVEL2)
> + verbose(env, "propagating r%d\n", i);
> + err = mark_chain_precision(env, i);
> + if (err < 0)
> + return err;
> + }
> +
> + for (i = 0; i < state->allocated_stack / BPF_REG_SIZE; i++) {
> + if (state->stack[i].slot_type[0] != STACK_SPILL)
> + continue;
> + state_reg = &state->stack[i].spilled_ptr;
> + if (state_reg->type != SCALAR_VALUE ||
> + !state_reg->precise)
> + continue;
> + if (env->log.level & BPF_LOG_LEVEL2)
> + verbose(env, "propagating fp%d\n",
> + (-i - 1) * BPF_REG_SIZE);
> + err = mark_chain_precision_stack(env, i);
> + if (err < 0)
> + return err;
> + }
> + return 0;
> +}
> +
> static bool states_maybe_looping(struct bpf_verifier_state *old,
> struct bpf_verifier_state *cur)
> {
> @@ -7206,6 +7291,14 @@ static int is_state_visited(struct bpf_verifier_env *env, int insn_idx)
> * this state and will pop a new one.
> */
> err = propagate_liveness(env, &sl->state, cur);
> +
> + /* if previous state reached the exit with precision and
> + * current state is equivalent to it (except precsion marks)
> + * the precision needs to be propagated back in
> + * the current state.
> + */
> + err = err ? : push_jmp_history(env, cur);
> + err = err ? : propagate_precision(env, &sl->state);
> if (err)
> return err;
> return 1;
> --
> 2.20.0
>
^ 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