* Re: [PATCH] uapi: avoid namespace conflict in linux/posix_types.h
From: Linus Torvalds @ 2019-06-17 18:48 UTC (permalink / raw)
To: Florian Weimer
Cc: Joseph Myers, Arnd Bergmann, Linux API, linux-arch, Netdev,
Laura Abbott, Paul Burton, Deepa Dinamani,
Linux List Kernel Mailing
In-Reply-To: <87a7egdqgr.fsf@oldenburg2.str.redhat.com>
On Mon, Jun 17, 2019 at 11:19 AM Florian Weimer <fweimer@redhat.com> wrote:
> >
> > Unlike the "val[]" thing, I don't think anybody is supposed to access
> > those fields directly.
>
> Well, glibc already calls it __val …
Hmm. If user space already doesn't see the "val[]" array anyway, I
guess we could just do that in the kernel too.
Looking at the glibc headers I have for fds_bits, glibc seems to do
*both* fds_bits[] and __fds_bits[] depending on __USE_XOPEN or not.
Anyway, that all implies to me that we might as well just go the truly
mindless way, and just do the double underscores and not bother with
renaming any files.
I thought people actually might care about the "val[]" name because I
find that in documentation, but since apparently it's already not
visible to user space anyway, that can't be true.
I guess that makes the original patch acceptable, and we should just
do the same thing to fds_bits..
Linus
^ permalink raw reply
* RE: [PATCH net] hvsock: fix epollout hang from race condition
From: Sunil Muthuswamy @ 2019-06-17 18:47 UTC (permalink / raw)
To: David Miller, Dexuan Cui
Cc: KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
sashal@kernel.org, Michael Kelley, netdev@vger.kernel.org,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20190616.135445.822152500838073831.davem@davemloft.net>
> -----Original Message-----
> From: linux-hyperv-owner@vger.kernel.org <linux-hyperv-owner@vger.kernel.org> On Behalf Of David Miller
> Sent: Sunday, June 16, 2019 1:55 PM
> To: Dexuan Cui <decui@microsoft.com>
> Cc: Sunil Muthuswamy <sunilmut@microsoft.com>; KY Srinivasan <kys@microsoft.com>; Haiyang Zhang <haiyangz@microsoft.com>;
> Stephen Hemminger <sthemmin@microsoft.com>; sashal@kernel.org; Michael Kelley <mikelley@microsoft.com>;
> netdev@vger.kernel.org; linux-hyperv@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net] hvsock: fix epollout hang from race condition
>
> From: Dexuan Cui <decui@microsoft.com>
> Date: Sat, 15 Jun 2019 03:22:32 +0000
>
> > These warnings are not introduced by this patch from Sunil.
> >
> > I'm not sure why I didn't notice these warnings before.
> > Probably my gcc version is not new eought?
> >
> > Actually these warnings are bogus, as I checked the related functions,
> > which may confuse the compiler's static analysis.
> >
> > I'm going to make a patch to initialize the pointers to NULL to suppress
> > the warnings. My patch will be based on the latest's net.git + this patch
> > from Sunil.
>
> Sunil should then resubmit his patch against something that has the
> warning suppression patch applied.
David, Dexuan's patch to suppress the warnings seems to be applied now
to the 'net' branch. Can we please get this patch applied as well?
^ permalink raw reply
* Re: [RFC net-next 1/2] net: sched: refactor reinsert action
From: Edward Cree @ 2019-06-17 18:43 UTC (permalink / raw)
To: John Hurley, netdev
Cc: davem, fw, jhs, simon.horman, jakub.kicinski, oss-drivers
In-Reply-To: <1560522831-23952-2-git-send-email-john.hurley@netronome.com>
On 14/06/2019 15:33, John Hurley wrote:
> Instead of
> returning TC_ACT_REINSERT, change the type to the new TC_ACT_CONSUMED
> which tells the caller that the packet has been stolen by another process
> and that no consume call is required.
Possibly a dumb question, but why does this need a new CONSUMED rather
than, say, taking an additional ref and returning TC_ACT_STOLEN?
Apart from that, the series lgtm.
-Ed
^ permalink raw reply
* Re: [PATCH v2 0/2] Add macb support for SiFive FU540-C000
From: Alistair Francis @ 2019-06-17 18:42 UTC (permalink / raw)
To: paul.walmsley@sifive.com, troy.benjegerdes@sifive.com
Cc: jamez@wit.com, linux-riscv@lists.infradead.org,
davem@davemloft.net, schwab@suse.de, nicolas.ferre@microchip.com,
mark.rutland@arm.com, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, aou@eecs.berkeley.edu,
sachin.ghadi@sifive.com, netdev@vger.kernel.org, ynezz@true.cz,
palmer@sifive.com, yash.shah@sifive.com, robh+dt@kernel.org
In-Reply-To: <F48A4F7F-0B0D-4191-91AD-DC51686D1E78@sifive.com>
On Mon, 2019-06-17 at 09:14 -0500, Troy Benjegerdes wrote:
> > On Jun 17, 2019, at 6:34 AM, Paul Walmsley <
> > paul.walmsley@sifive.com> wrote:
> >
> > On Mon, 17 Jun 2019, Andreas Schwab wrote:
> >
> > > On Jun 17 2019, Paul Walmsley <paul.walmsley@sifive.com> wrote:
> > >
> > > > On Mon, 17 Jun 2019, Andreas Schwab wrote:
> > > >
> > > > > On Jun 17 2019, Paul Walmsley <paul.walmsley@sifive.com>
> > > > > wrote:
> > > > >
> > > > > > Looks to me that it shouldn't have an impact unless the DT
> > > > > > string is
> > > > > > present, and even then, the impact might simply be that the
> > > > > > MACB driver
> > > > > > may not work?
> > > > >
> > > > > If the macb driver doesn't work you have an unusable system,
> > > > > of course.
> > > >
> > > > Why?
> > >
> > > Because a system is useless without network.
> >
> > From an upstream Linux point of view, Yash's patches should be an
> > improvement over the current mainline kernel situation, since
> > there's
> > currently no upstream support for the (SiFive-specific) TX clock
> > switch
> > register. With the right DT data, and a bootloader that handles
> > the PHY
> > reset, I think networking should work after his patches are
> > upstream --
> > although I myself haven't tried this yet.
> >
>
> Have we documented this tx clock switch register in something with a
> direct URL link (rather than a PDF)?
>
> I’d like to update freedom-u-sdk (or yocto) to create bootable images
> with a working U-boot (upstream or not, I don’t care, as long as it
> works),
> and what I have right now is the old legacy HiFive U-boot[1] and a
> 4.19
> kernel with a bunch of extra patches.
Yocto/OpenEmbedded does this today. TFTP boot works with the 2019.04 U-
Boot (+ some patches ontop for SMP support). We use the latest 5.1
stable kernel plus 5 or so patches to boot on the Unleased. Networking,
display and audio are all working with the Microsemi expansion board as
well. Let me know if there is something else missing and I'll add it
in. There are probably documentation fixes that are needed as well.
I was thinking of skipping the 5.2 release though as I thought the DT
stuff wasn't going to make it [1]. I will probably re-evaluate that
decision though when 5.2 comes out as it looks like it's all going to
work :)
With U-boot 2017.09 and Linux 5.2/5.3 we should finally be upstream
only!
>
> The legacy M-mode U-boot handles the phy reset already, and I’ve been
> able to load upstream S-mode uboot as a payload via TFTP, and then
> load and boot a 4.19 kernel.
>
> It would be nice to get this all working with 5.x, however there are
> still
> several missing pieces to really have it work well.
Let me know what is still missing/doesn't work and I can add it. At the
moment the only known issue I know of is a missing SD card driver in U-
Boot.
1: https://github.com/riscv/meta-riscv/issues/143
Alistair
>
>
> [1] https://github.com/sifive/HiFive_U-Boot
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* Re: [PATCH v5 0/5] brcmfmac: sdio: Deal better w/ transmission errors related to idle
From: Ulf Hansson @ 2019-06-17 18:38 UTC (permalink / raw)
To: Douglas Anderson, Kalle Valo
Cc: Adrian Hunter, Arend van Spriel, brcm80211-dev-list.pdl,
open list:ARM/Rockchip SoC..., Double Lo, Brian Norris,
linux-wireless, Naveen Gupta, Madhan Mohan R, Matthias Kaehlcke,
Wright Feng, Chi-Hsien Lin, netdev, brcm80211-dev-list,
YueHaibing, Allison Randal, Thomas Gleixner, Hante Meuleman,
Greg Kroah-Hartman, Niklas Söderlund, Ritesh Harjani,
Michael Trimarchi, Wolfram Sang, Franky Lin, Ondrej Jirman,
Jiong Wu, David S. Miller, linux-mmc@vger.kernel.org,
Linux Kernel Mailing List, Avri Altman
In-Reply-To: <20190617175653.21756-1-dianders@chromium.org>
On Mon, 17 Jun 2019 at 19:57, Douglas Anderson <dianders@chromium.org> wrote:
>
> This series attempts to deal better with the expected transmission
> errors related to the idle states (handled by the Always-On-Subsystem
> or AOS) on the SDIO-based WiFi on rk3288-veyron-minnie,
> rk3288-veyron-speedy, and rk3288-veyron-mickey.
>
> Some details about those errors can be found in
> <https://crbug.com/960222>, but to summarize it here: if we try to
> send the wakeup command to the WiFi card at the same time it has
> decided to wake up itself then it will behave badly on the SDIO bus.
> This can cause timeouts or CRC errors.
>
> When I tested on 4.19 and 4.20 these CRC errors can be seen to cause
> re-tuning. Since I am currently developing on 4.19 this was the
> original problem I attempted to solve.
>
> On mainline it turns out that you don't see the retuning errors but
> you see tons of spam about timeouts trying to wakeup from sleep. I
> tracked down the commit that was causing that and have partially
> reverted it here. I have no real knowledge about Broadcom WiFi, but
> the commit that was causing problems sounds (from the descriptioin) to
> be a hack commit penalizing all Broadcom WiFi users because of a bug
> in a Cypress SD controller. I will let others comment if this is
> truly the case and, if so, what the right solution should be.
>
> For v3 of this series I have added 2 patches to the end of the series
> to address errors that would show up on systems with these same SDIO
> WiFi cards when used on controllers that do periodic retuning. These
> systems need an extra fix to prevent the retuning from happening when
> the card is asleep.
>
> I believe v5 of this series is all ready to go assuming Kalle Valo is
> good with it. I've added after-the-cut notes to patches awaiting his
> Ack and have added other tags collected so far.
>
> Changes in v5:
> - Add missing sdio_retune_crc_enable() in comments (Ulf).
> - /s/reneable/re-enable (Ulf).
> - Remove leftover prototypes: mmc_expect_errors_begin() / end() (Ulf).
> - Rewording of "sleep command" in commit message (Arend).
>
> Changes in v4:
> - Moved to SDIO API only (Adrian, Ulf).
> - Renamed to make it less generic, now retune_crc_disable (Ulf).
> - Function header makes it clear host must be claimed (Ulf).
> - No more WARN_ON (Ulf).
> - Adjust to API rename (Adrian, Ulf).
> - Moved retune hold/release to SDIO API (Adrian).
> - Adjust to API rename (Adrian).
>
> Changes in v3:
> - Took out the spinlock since I believe this is all in one context.
> - Expect errors for all of brcmf_sdio_kso_control() (Adrian).
> - ("mmc: core: Export mmc_retune_hold_now() mmc_retune_release()") new for v3.
> - ("brcmfmac: sdio: Don't tune while the card is off") new for v3.
>
> Changes in v2:
> - A full revert, not just a partial one (Arend). ...with explicit Cc.
> - Updated commit message to clarify based on discussion of v1.
>
> Douglas Anderson (5):
> Revert "brcmfmac: disable command decode in sdio_aos"
> mmc: core: API to temporarily disable retuning for SDIO CRC errors
> brcmfmac: sdio: Disable auto-tuning around commands expected to fail
> mmc: core: Add sdio_retune_hold_now() and sdio_retune_release()
> brcmfmac: sdio: Don't tune while the card is off
>
> drivers/mmc/core/core.c | 5 +-
> drivers/mmc/core/sdio_io.c | 77 +++++++++++++++++++
> .../broadcom/brcm80211/brcmfmac/sdio.c | 17 ++--
> include/linux/mmc/host.h | 1 +
> include/linux/mmc/sdio_func.h | 6 ++
> 5 files changed, 99 insertions(+), 7 deletions(-)
>
> --
> 2.22.0.410.gd8fdbe21b5-goog
>
Applied for fixes, thanks!
Some minor changes:
1) Dropped the a few "commit notes", that was more related to version
and practical information about the series.
2) Dropped fixes tags for patch 2->5, but instead put a stable tag
targeted for v4.18+.
Awaiting an ack from Kalle before sending the PR to Linus.
Kalle, perhaps you prefer to pick patch 1, as it could go separate.
Then please tell - and/or if there is anything else you want me to
change.
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH bpf-next 2/8] libbpf: extract BTF loading and simplify ELF parsing logic
From: Andrii Nakryiko @ 2019-06-17 18:35 UTC (permalink / raw)
To: Song Liu
Cc: Song Liu, Andrii Nakryiko, bpf, Networking, Alexei Starovoitov,
Daniel Borkmann, Kernel Team
In-Reply-To: <8F07D61C-2751-44A6-9E89-9BE6781FEF81@fb.com>
On Mon, Jun 17, 2019 at 11:07 AM Song Liu <songliubraving@fb.com> wrote:
>
>
>
> > On Jun 17, 2019, at 10:24 AM, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
> >
> > On Sat, Jun 15, 2019 at 1:26 PM Song Liu <liu.song.a23@gmail.com> wrote:
> >>
> >> On Mon, Jun 10, 2019 at 9:49 PM Andrii Nakryiko <andriin@fb.com> wrote:
> >>>
> >>> As a preparation for adding BTF-based BPF map loading, extract .BTF and
> >>> .BTF.ext loading logic. Also simplify error handling in
> >>> bpf_object__elf_collect() by returning early, as there is no common
> >>> clean up to be done.
> >>>
> >>> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> >>> ---
> >>> tools/lib/bpf/libbpf.c | 137 ++++++++++++++++++++++-------------------
> >>> 1 file changed, 75 insertions(+), 62 deletions(-)
> >>>
> >>> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> >>> index ba89d9727137..9e39a0a33aeb 100644
> >>> --- a/tools/lib/bpf/libbpf.c
> >>> +++ b/tools/lib/bpf/libbpf.c
> >>> @@ -1078,6 +1078,58 @@ static void bpf_object__sanitize_btf_ext(struct bpf_object *obj)
> >>> }
> >>> }
> >>>
> >>> +static int bpf_object__load_btf(struct bpf_object *obj,
> >>> + Elf_Data *btf_data,
> >>> + Elf_Data *btf_ext_data)
> >>> +{
> >>> + int err = 0;
> >>> +
> >>> + if (btf_data) {
> >>> + obj->btf = btf__new(btf_data->d_buf, btf_data->d_size);
> >>> + if (IS_ERR(obj->btf)) {
> >>> + pr_warning("Error loading ELF section %s: %d.\n",
> >>> + BTF_ELF_SEC, err);
> >>> + goto out;
> >>
> >> If we goto out here, we will return 0.
> >
> >
> > Yes, it's intentional. BTF is treated as optional, so if we fail to
> > load it, libbpf will emit warning, but will proceed as nothing
> > happened and no BTF was supposed to be loaded.
> >
> >>
> >>> + }
> >>> + err = btf__finalize_data(obj, obj->btf);
> >>> + if (err) {
> >>> + pr_warning("Error finalizing %s: %d.\n",
> >>> + BTF_ELF_SEC, err);
> >>> + goto out;
> >>> + }
> >>> + bpf_object__sanitize_btf(obj);
> >>> + err = btf__load(obj->btf);
> >>> + if (err) {
> >>> + pr_warning("Error loading %s into kernel: %d.\n",
> >>> + BTF_ELF_SEC, err);
> >>> + goto out;
> >>> + }
> >>> + }
> >>> + if (btf_ext_data) {
> >>> + if (!obj->btf) {
> >>> + pr_debug("Ignore ELF section %s because its depending ELF section %s is not found.\n",
> >>> + BTF_EXT_ELF_SEC, BTF_ELF_SEC);
> >>> + goto out;
> >>
> >> We will also return 0 when goto out here.
> >
> >
> > See above, it's original behavior of libbpf.
> >
> >>
> >>> + }
> >>> + obj->btf_ext = btf_ext__new(btf_ext_data->d_buf,
> >>> + btf_ext_data->d_size);
> >>> + if (IS_ERR(obj->btf_ext)) {
> >>> + pr_warning("Error loading ELF section %s: %ld. Ignored and continue.\n",
> >>> + BTF_EXT_ELF_SEC, PTR_ERR(obj->btf_ext));
> >>> + obj->btf_ext = NULL;
> >>> + goto out;
> >> And, here. And we will not free obj->btf.
> >
> > This is situation in which we successfully loaded .BTF, but failed to
> > load .BTF.ext. In that case we'll warn about .BTF.ext, but will drop
> > it and continue with .BTF only.
> >
>
> Yeah, that makes sense.
>
> Shall we let bpf_object__load_btf() return void? Since it always
> returns 0?
This is split into bpf_object__init_btf and
bpf_object__sanitize_and_load_btf in patch #6, both of which can
return errors. So probably not worth changing just for one patch.
>
> Thanks,
> Song
>
> <snip>
>
^ permalink raw reply
* Re: [PATCH bpf-next 6/8] libbpf: allow specifying map definitions using BTF
From: Andrii Nakryiko @ 2019-06-17 18:33 UTC (permalink / raw)
To: Song Liu
Cc: Andrii Nakryiko, bpf, Networking, Alexei Starovoitov,
Daniel Borkmann, Kernel Team
In-Reply-To: <CAPhsuW4-tmiBAji-=zx5gRRweioXTQM__EqaJGTPQ63SLphoUA@mail.gmail.com>
On Sat, Jun 15, 2019 at 3:01 PM Song Liu <liu.song.a23@gmail.com> wrote:
>
> On Mon, Jun 10, 2019 at 9:49 PM Andrii Nakryiko <andriin@fb.com> wrote:
> >
> > This patch adds support for a new way to define BPF maps. It relies on
> > BTF to describe mandatory and optional attributes of a map, as well as
> > captures type information of key and value naturally. This eliminates
> > the need for BPF_ANNOTATE_KV_PAIR hack and ensures key/value sizes are
> > always in sync with the key/value type.
> >
<snip>
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > ---
> > tools/lib/bpf/btf.h | 1 +
> > tools/lib/bpf/libbpf.c | 338 +++++++++++++++++++++++++++++++++++++++--
> > 2 files changed, 330 insertions(+), 9 deletions(-)
> >
> > diff --git a/tools/lib/bpf/btf.h b/tools/lib/bpf/btf.h
> > index ba4ffa831aa4..88a52ae56fc6 100644
> > --- a/tools/lib/bpf/btf.h
> > +++ b/tools/lib/bpf/btf.h
> > @@ -17,6 +17,7 @@ extern "C" {
> >
> > #define BTF_ELF_SEC ".BTF"
> > #define BTF_EXT_ELF_SEC ".BTF.ext"
> > +#define MAPS_ELF_SEC ".maps"
>
> How about .BTF.maps? Or maybe this doesn't realy matter?
That's not a good name, because it implies those maps are additional
part of BTF stuff (similar to as .BTF.ext is addition to .BTF). And
it's not, it uses BTF, but is not part of it.
I think .maps is good, because it's short and clear. Existing "maps"
used for bpf_map_def will eventually die out, leaving
"officially-looking" ;) .maps.
>
> >
> > struct btf;
> > struct btf_ext;
> > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > index 79a8143240d7..60713bcc2279 100644
> > --- a/tools/lib/bpf/libbpf.c
> > +++ b/tools/lib/bpf/libbpf.c
> > @@ -262,6 +262,7 @@ struct bpf_object {
> > } *reloc;
> > int nr_reloc;
> > int maps_shndx;
> > + int btf_maps_shndx;
> > int text_shndx;
> > int data_shndx;
> > int rodata_shndx;
> > @@ -514,6 +515,7 @@ static struct bpf_object *bpf_object__new(const char *path,
> > obj->efile.obj_buf = obj_buf;
> > obj->efile.obj_buf_sz = obj_buf_sz;
> > obj->efile.maps_shndx = -1;
> > + obj->efile.btf_maps_shndx = -1;
> > obj->efile.data_shndx = -1;
> > obj->efile.rodata_shndx = -1;
> > obj->efile.bss_shndx = -1;
> > @@ -1012,6 +1014,297 @@ static int bpf_object__init_user_maps(struct bpf_object *obj, bool strict)
> > return 0;
> > }
> >
> > +static const struct btf_type *skip_mods_and_typedefs(const struct btf *btf,
> > + __u32 id)
> > +{
> > + const struct btf_type *t = btf__type_by_id(btf, id);
> > +
> > + while (true) {
> > + switch (BTF_INFO_KIND(t->info)) {
> > + case BTF_KIND_VOLATILE:
> > + case BTF_KIND_CONST:
> > + case BTF_KIND_RESTRICT:
> > + case BTF_KIND_TYPEDEF:
> > + t = btf__type_by_id(btf, t->type);
> > + break;
> > + default:
> > + return t;
> > + }
> > + }
> > +}
> > +
> > +static bool get_map_attr_int(const char *map_name,
> > + const struct btf *btf,
> > + const struct btf_type *def,
> > + const struct btf_member *m,
> > + const void *data, __u32 *res) {
>
> Can we avoid output pointer by return 0 for invalid types?
Zero is valid value, so can't do that.
>
> > + 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);
> > +
> > + if (BTF_INFO_KIND(t->info) != BTF_KIND_INT) {
> > + pr_warning("map '%s': attr '%s': expected INT, 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);
> > + return false;
> > + }
> > + if (m->offset % 32) {
>
> Shall we just do "m->offset > 0" here?
No. m->offset == 0 is OK (first field of a struct), but any
non-aligned int is bad (e.g., bitfields are not supported). I could
have supported byte-aligned integer fields, but don't see much reason
to.
>
> > + pr_warning("map '%s': attr '%s': unaligned fields are not supported.\n",
> > + map_name, name);
> > + return false;
> > + }
> > +
> > + *res = *(const __u32 *)(data + m->offset / 8);
> > + return true;
> > +}
> > +
> > +static int bpf_object__init_user_btf_map(struct bpf_object *obj,
> > + const struct btf_type *sec,
> > + int var_idx, int sec_idx,
> > + const Elf_Data *data, bool strict)
> > +{
> > + const struct btf_type *var, *def, *t;
> > + 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;
> > +
> > + vi = (const struct btf_var_secinfo *)(const void *)(sec + 1) + var_idx;
> > + var = btf__type_by_id(obj->btf, vi->type);
> > + var_extra = (const void *)(var + 1);
> > + map_name = btf__name_by_offset(obj->btf, var->name_off);
> > + vlen = BTF_INFO_VLEN(var->info);
> > +
> > + if (map_name == NULL || map_name[0] == '\0') {
> > + pr_warning("map #%d: empty name.\n", var_idx);
> > + return -EINVAL;
> > + }
> > + if ((__u64)vi->offset + vi->size > data->d_size) {
> > + pr_warning("map '%s' BTF data is corrupted.\n", map_name);
> > + return -EINVAL;
> > + }
> > + if (BTF_INFO_KIND(var->info) != BTF_KIND_VAR) {
> > + pr_warning("map '%s': unexpected var kind %u.\n",
> > + map_name, BTF_INFO_KIND(var->info));
> > + return -EINVAL;
> > + }
> > + if (var_extra->linkage != BTF_VAR_GLOBAL_ALLOCATED &&
> > + var_extra->linkage != BTF_VAR_STATIC) {
> > + pr_warning("map '%s': unsupported var linkage %u.\n",
> > + map_name, var_extra->linkage);
> > + return -EOPNOTSUPP;
> > + }
> > +
> > + def = skip_mods_and_typedefs(obj->btf, var->type);
> > + if (BTF_INFO_KIND(def->info) != BTF_KIND_STRUCT) {
> > + pr_warning("map '%s': unexpected def kind %u.\n",
> > + map_name, BTF_INFO_KIND(var->info));
> > + return -EINVAL;
> > + }
> > + if (def->size > vi->size) {
> > + pr_warning("map '%s': invalid def size.\n", map_name);
> > + return -EINVAL;
> > + }
> > +
> > + map = bpf_object__add_map(obj);
> > + if (IS_ERR(map))
> > + return PTR_ERR(map);
> > + map->name = strdup(map_name);
> > + if (!map->name) {
> > + pr_warning("map '%s': failed to alloc map name.\n", map_name);
> > + return -ENOMEM;
> > + }
> > + map->libbpf_type = LIBBPF_MAP_UNSPEC;
> > + map->def.type = BPF_MAP_TYPE_UNSPEC;
> > + map->sec_idx = sec_idx;
> > + map->sec_offset = vi->offset;
> > + 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++) {
> > + const char *name = btf__name_by_offset(obj->btf, m->name_off);
> > +
>
> I guess we need to check name == NULL here?
Yep, will check, it can throw off pr_warning below.
>
> > + if (strcmp(name, "type") == 0) {
> > + if (!get_map_attr_int(map_name, obj->btf, def, m,
> > + def_data, &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_attr_int(map_name, obj->btf, def, m,
> > + def_data, &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_attr_int(map_name, obj->btf, def, m,
> > + def_data, &map->def.map_flags))
> > + return -EINVAL;
> > + pr_debug("map '%s': found map_flags = %u.\n",
> > + map_name, map->def.map_flags);
> > + } else if (strcmp(name, "key_size") == 0) {
> > + __u32 sz;
> > +
> > + if (!get_map_attr_int(map_name, obj->btf, def, m,
> > + def_data, &sz))
> > + return -EINVAL;
> > + pr_debug("map '%s': found key_size = %u.\n",
> > + map_name, sz);
> > + if (map->def.key_size && map->def.key_size != sz) {
> > + pr_warning("map '%s': conflictling key size %u != %u.\n",
> > + map_name, map->def.key_size, sz);
> > + return -EINVAL;
> > + }
> > + map->def.key_size = sz;
> > + } else if (strcmp(name, "key") == 0) {
> > + __s64 sz;
> > +
> > + t = btf__type_by_id(obj->btf, m->type);
> > + if (BTF_INFO_KIND(t->info) != BTF_KIND_PTR) {
>
> check t != NULL?
done
>
> > + pr_warning("map '%s': key spec is not PTR: %u.\n",
> > + map_name, BTF_INFO_KIND(t->info));
> > + return -EINVAL;
> > + }
> > + sz = btf__resolve_size(obj->btf, t->type);
> > + if (sz < 0) {
> > + pr_warning("map '%s': can't determine key size for type [%u]: %lld.\n",
> > + map_name, t->type, sz);
> > + return sz;
> > + }
> > + pr_debug("map '%s': found key [%u], sz = %lld.\n",
> > + map_name, t->type, sz);
> > + if (map->def.key_size && map->def.key_size != sz) {
> > + pr_warning("map '%s': conflictling key size %u != %lld.\n",
> > + map_name, map->def.key_size, sz);
> > + return -EINVAL;
> > + }
> > + map->def.key_size = sz;
> > + map->btf_key_type_id = t->type;
> > + } else if (strcmp(name, "value_size") == 0) {
> > + __u32 sz;
> > +
> > + if (!get_map_attr_int(map_name, obj->btf, def, m,
> > + def_data, &sz))
> > + return -EINVAL;
> > + pr_debug("map '%s': found value_size = %u.\n",
> > + map_name, sz);
> > + if (map->def.value_size && map->def.value_size != sz) {
> > + pr_warning("map '%s': conflictling value size %u != %u.\n",
> > + map_name, map->def.value_size, sz);
> > + return -EINVAL;
> > + }
> > + map->def.value_size = sz;
> > + } else if (strcmp(name, "value") == 0) {
> > + __s64 sz;
> > +
> > + t = btf__type_by_id(obj->btf, m->type);
>
> ditto.
yep
>
> > + if (BTF_INFO_KIND(t->info) != BTF_KIND_PTR) {
> > + pr_warning("map '%s': value spec is not PTR: %u.\n",
> > + map_name, BTF_INFO_KIND(t->info));
> > + return -EINVAL;
> > + }
<snip>
^ permalink raw reply
* Re: [PATCH net v4 1/8] ipv4/fib_frontend: Rename ip_valid_fib_dump_req, provide non-strict version
From: Stefano Brivio @ 2019-06-17 18:28 UTC (permalink / raw)
To: David Ahern
Cc: David Miller, Martin KaFai Lau, Jianlin Shi, Wei Wang,
Eric Dumazet, Matti Vaittinen, netdev
In-Reply-To: <43a9b0c7-27b4-733c-d3f2-60ad894e8aeb@gmail.com>
On Mon, 17 Jun 2019 11:06:51 -0600
David Ahern <dsahern@gmail.com> wrote:
> On 6/17/19 8:13 AM, Stefano Brivio wrote:
> >>
> >> With strict checking (5.0 and forward):
> >> - RTM_F_CLONED NOT set means dump only FIB entries
> >> - RTM_F_CLONED set means dump only exceptions
> >
> > Okay. Should we really ignore the RFC and NLM_F_MATCH though? If we add
> > field(s) to the filter, it comes almost for free, something like:
> >
> > if (nlh->nlmsg_flags & NLM_F_MATCH)
> > filter->dump_exceptions = rtm->rtm_flags & RTM_F_CLONED;
> >
> > instead of:
> >
> > filter->dump_exceptions = rtm->rtm_flags & RTM_F_CLONED;
>
> This is where you keep losing me. iproute2 has always set NLM_F_MATCH on
> dump requests, so that flag can not be used as a discriminator here.
iproute2 yes, but some other users (I'm not aware of any so I have no
examples) might *very* vaguely follow the RFC and expect consistent
results. That was my only point here. Most likely just a theoretical
one.
> >
> >> Without strict checking (old iproute2 on any kernel):
> >> - dump all, userspace has to sort
> >>
> >> Kernel side this can be handled with new field, dump_exceptions, in the
> >> filter that defaults to true and then is reset in the strict path if the
> >> flag is not set.
> >
> > I guess we need to add two fields, we'll need a 'dump_routes' too.
> >
> > Otherwise, the dump functions can't distinguish between the three cases
> > ('no strict checking', 'strict checking and RTM_F_CLONED', 'strict
> > checking and no RTM_F_CLONED'). How would you do this with a single
> > additional field?
> >
>
> sure, separate fields are needed for the pre-strict mode use case.
Well, they are needed, in general. They both start as true, non-strict
mode doesn't clear them, strict mode clears one. That's how I would do
it.
> So, I take it we are converging on this:
>
> 1. non-strict mode, dump both (FIB entries and exceptions). Userspace
> has to filter. This is the legacy behavior you are trying to restore.
>
> 2. strict mode:
> a. dump only FIB entries if RTM_F_CLONED is not set
> b. dump only exception entries if RTM_F_CLONED is set
>
> Agreed?
Agreed in general, maybe let me know what you think about the
NLM_F_MATCH point above though.
--
Stefano
^ permalink raw reply
* Re: [PATCH] net/mlx5e: reduce stack usage in mlx5_eswitch_termtbl_create
From: Mark Bloch @ 2019-06-17 18:24 UTC (permalink / raw)
To: Saeed Mahameed, davem@davemloft.net, arnd@arndb.de,
leon@kernel.org
Cc: linux-rdma@vger.kernel.org, Or Gerlitz, Oz Shlomo, Paul Blakey,
Maor Gottlieb, linux-kernel@vger.kernel.org, Eli Britstein,
netdev@vger.kernel.org
In-Reply-To: <9efb76f79369b8577ef425c7f6e694132719353e.camel@mellanox.com>
On 6/17/19 11:02 AM, Saeed Mahameed wrote:
> On Mon, 2019-06-17 at 13:08 +0200, Arnd Bergmann wrote:
>> Putting an empty 'mlx5_flow_spec' structure on the stack is a bit
>> wasteful and causes a warning on 32-bit architectures when building
>> with clang -fsanitize-coverage:
>>
>> drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c:
>> In function 'mlx5_eswitch_termtbl_create':
>> drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c:90
>> :1: error: the frame size of 1032 bytes is larger than 1024 bytes [-
>> Werror=frame-larger-than=]
>>
>> Since the structure is never written to, we can statically allocate
>> it to avoid the stack usage. To be on the safe side, mark all
>> subsequent function arguments that we pass it into as 'const'
>> as well.
>>
>> Fixes: 10caabdaad5a ("net/mlx5e: Use termination table for VLAN push
>> actions")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> .../mlx5/core/eswitch_offloads_termtbl.c | 2 +-
>> .../net/ethernet/mellanox/mlx5/core/fs_core.c | 20 +++++++++------
>> ----
>> include/linux/mlx5/fs.h | 2 +-
>> 3 files changed, 12 insertions(+), 12 deletions(-)
>>
>> diff --git
>> a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c
>> b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c
>> index cb7d8ebe2c95..171f3d4ef9ac 100644
>> ---
>> a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c
>> +++
>> b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c
>> @@ -50,7 +50,7 @@ mlx5_eswitch_termtbl_create(struct mlx5_core_dev
>> *dev,
>> struct mlx5_flow_act *flow_act)
>> {
>> struct mlx5_flow_namespace *root_ns;
>> - struct mlx5_flow_spec spec = {};
>> + static const struct mlx5_flow_spec spec = {};
>
> LGTM, just make sure please to have a reverse xmas tree here.
>
> Mark, please let me know if you are ok with such API constrain to flow
> steering (spec must be const).
I don't think the steering core layer should change the matching asked by the user.
Even without the frame size issue I like this change, thanks!
LGTM
Thanks,
Mark
>
> Thanks,
> Saeed.
>
>> int prio, flags;
>> int err;
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
>> b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
>> index fe76c6fd6d80..739123e1363b 100644
>> --- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
>> @@ -584,7 +584,7 @@ static int insert_fte(struct mlx5_flow_group *fg,
>> struct fs_fte *fte)
>> }
>>
>> static struct fs_fte *alloc_fte(struct mlx5_flow_table *ft,
>> - u32 *match_value,
>> + const u32 *match_value,
>> struct mlx5_flow_act *flow_act)
>> {
>> struct mlx5_flow_steering *steering = get_steering(&ft->node);
>> @@ -612,7 +612,7 @@ static void dealloc_flow_group(struct
>> mlx5_flow_steering *steering,
>>
>> static struct mlx5_flow_group *alloc_flow_group(struct
>> mlx5_flow_steering *steering,
>> u8
>> match_criteria_enable,
>> - void *match_criteria,
>> + const void
>> *match_criteria,
>> int start_index,
>> int end_index)
>> {
>> @@ -642,7 +642,7 @@ static struct mlx5_flow_group
>> *alloc_flow_group(struct mlx5_flow_steering *steer
>>
>> static struct mlx5_flow_group *alloc_insert_flow_group(struct
>> mlx5_flow_table *ft,
>> u8
>> match_criteria_enable,
>> - void
>> *match_criteria,
>> + const void
>> *match_criteria,
>> int start_index,
>> int end_index,
>> struct list_head
>> *prev)
>> @@ -1285,7 +1285,7 @@ add_rule_fte(struct fs_fte *fte,
>> }
>>
>> static struct mlx5_flow_group *alloc_auto_flow_group(struct
>> mlx5_flow_table *ft,
>> - struct
>> mlx5_flow_spec *spec)
>> + const struct
>> mlx5_flow_spec *spec)
>> {
>> struct list_head *prev = &ft->node.children;
>> struct mlx5_flow_group *fg;
>> @@ -1451,7 +1451,7 @@ static int check_conflicting_ftes(struct fs_fte
>> *fte, const struct mlx5_flow_act
>> }
>>
>> static struct mlx5_flow_handle *add_rule_fg(struct mlx5_flow_group
>> *fg,
>> - u32 *match_value,
>> + const u32 *match_value,
>> struct mlx5_flow_act
>> *flow_act,
>> struct
>> mlx5_flow_destination *dest,
>> int dest_num,
>> @@ -1536,7 +1536,7 @@ static void free_match_list(struct
>> match_list_head *head)
>>
>> static int build_match_list(struct match_list_head *match_head,
>> struct mlx5_flow_table *ft,
>> - struct mlx5_flow_spec *spec)
>> + const struct mlx5_flow_spec *spec)
>> {
>> struct rhlist_head *tmp, *list;
>> struct mlx5_flow_group *g;
>> @@ -1589,7 +1589,7 @@ static u64 matched_fgs_get_version(struct
>> list_head *match_head)
>>
>> static struct fs_fte *
>> lookup_fte_locked(struct mlx5_flow_group *g,
>> - u32 *match_value,
>> + const u32 *match_value,
>> bool take_write)
>> {
>> struct fs_fte *fte_tmp;
>> @@ -1622,7 +1622,7 @@ lookup_fte_locked(struct mlx5_flow_group *g,
>> static struct mlx5_flow_handle *
>> try_add_to_existing_fg(struct mlx5_flow_table *ft,
>> struct list_head *match_head,
>> - struct mlx5_flow_spec *spec,
>> + const struct mlx5_flow_spec *spec,
>> struct mlx5_flow_act *flow_act,
>> struct mlx5_flow_destination *dest,
>> int dest_num,
>> @@ -1715,7 +1715,7 @@ try_add_to_existing_fg(struct mlx5_flow_table
>> *ft,
>>
>> static struct mlx5_flow_handle *
>> _mlx5_add_flow_rules(struct mlx5_flow_table *ft,
>> - struct mlx5_flow_spec *spec,
>> + const struct mlx5_flow_spec *spec,
>> struct mlx5_flow_act *flow_act,
>> struct mlx5_flow_destination *dest,
>> int dest_num)
>> @@ -1823,7 +1823,7 @@ static bool fwd_next_prio_supported(struct
>> mlx5_flow_table *ft)
>>
>> struct mlx5_flow_handle *
>> mlx5_add_flow_rules(struct mlx5_flow_table *ft,
>> - struct mlx5_flow_spec *spec,
>> + const struct mlx5_flow_spec *spec,
>> struct mlx5_flow_act *flow_act,
>> struct mlx5_flow_destination *dest,
>> int num_dest)
>> diff --git a/include/linux/mlx5/fs.h b/include/linux/mlx5/fs.h
>> index 2ddaa97f2179..c0c029664527 100644
>> --- a/include/linux/mlx5/fs.h
>> +++ b/include/linux/mlx5/fs.h
>> @@ -200,7 +200,7 @@ struct mlx5_flow_act {
>> */
>> struct mlx5_flow_handle *
>> mlx5_add_flow_rules(struct mlx5_flow_table *ft,
>> - struct mlx5_flow_spec *spec,
>> + const struct mlx5_flow_spec *spec,
>> struct mlx5_flow_act *flow_act,
>> struct mlx5_flow_destination *dest,
>> int num_dest);
^ permalink raw reply
* Re: [PATCH] uapi: avoid namespace conflict in linux/posix_types.h
From: Florian Weimer @ 2019-06-17 18:19 UTC (permalink / raw)
To: Linus Torvalds
Cc: Joseph Myers, Arnd Bergmann, Linux API, linux-arch, Netdev,
Laura Abbott, Paul Burton, Deepa Dinamani,
Linux List Kernel Mailing
In-Reply-To: <CAHk-=wgiZNERDN7p-bsCzzYGRjeqTQw7kJxJnXAHVjqqO8PGrg@mail.gmail.com>
* Linus Torvalds:
> On Mon, Jun 17, 2019 at 11:03 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> There's also __kernel_fd_set in <linux/posix_types.h>. I may have
>> lumped this up with <asm/posix_types.h>, but it has the same problem.
>
> Hmm.
>
> That one we might be able to just fix by renaming "fds_bits" to "__fds_bits".
>
> Unlike the "val[]" thing, I don't think anybody is supposed to access
> those fields directly.
Well, glibc already calls it __val …
> I think fd_set and friends are now supposed to be in <sys/select.h>
> anyway, and the "it was in <sys/types.h>" is all legacy.
Do you suggest to create a <linux/select.h> header to mirror this?
Thanks,
Florian
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2019-06-17 18:17 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
Lots of bug fixes here:
1) Out of bounds access in __bpf_skc_lookup, from Lorenz Bauer.
2) Fix rate reporting in cfg80211_calculate_bitrate_he(), from
John Crispin.
3) Use after free in psock backlog workqueue, from John Fastabend.
4) Fix source port matching in fdb peer flow rule of mlx5, from
Raed Salem.
5) Use atomic_inc_not_zero() in fl6_sock_lookup(), from Eric Dumazet.
6) Network header needs to be set for packet redirect in nfp, from
John Hurley.
7) Fix udp zerocopy refcnt, from Willem de Bruijn.
8) Don't assume linear buffers in vxlan and geneve error handlers,
from Stefano Brivio.
9) Fix TOS matching in mlxsw, from Jiri Pirko.
10) More SCTP cookie memory leak fixes, from Neil Horman.
11) Fix VLAN filtering in rtl8366, from Linus Walluij.
12) Various TCP SACK payload size and fragmentation memory limit fixes
from Eric Dumazet.
13) Use after free in pneigh_get_next(), also from Eric Dumazet.
14) LAPB control block leak fix from Jeremy Sowden.
Please pull, thanks a lot!
The following changes since commit 1e1d926369545ea09c98c6c7f5d109aa4ee0cd0b:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2019-06-07 09:29:14 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to 4fddbf8a99ee5a65bdd31b3ebbf5a84b9395d496:
Merge branch 'tcp-fixes' (2019-06-17 10:39:56 -0700)
----------------------------------------------------------------
Alaa Hleihel (2):
net/mlx5: Avoid reloading already removed devices
net/mlx5e: Avoid detaching non-existing netdev under switchdev mode
Alakesh Haloi (1):
selftests: bpf: fix compiler warning in flow_dissector test
Alexander Dahl (1):
can: usb: Kconfig: Remove duplicate menu entry
Alexei Starovoitov (3):
Merge branch 'reuseport-fixes'
Merge branch 'fix-unconnected-udp'
bpf, x64: fix stack layout of JITed bpf code
Anders Roxell (1):
net: dsa: fix warning same module names
Andy Strohman (1):
nl80211: fix station_info pertid memory leak
Anssi Hannula (1):
can: xilinx_can: use correct bittiming_const for CAN FD core
Arthur Fabre (1):
bpf: Fix out of bounds memory access in bpf_sk_storage
Avraham Stern (1):
cfg80211: report measurement start TSF correctly
Björn Töpel (2):
bpf, riscv: clear target register high 32-bits for and/or/xor on ALU32
selftests: bpf: add zero extend checks for ALU32 and/or/xor
Chang-Hsien Tsai (1):
samples, bpf: fix to change the buffer size for read()
Chris Mi (1):
net/mlx5e: Add ndo_set_feature for uplink representor
Daniel Borkmann (8):
Merge branch 'bpf-subreg-tests'
bpf: fix unconnected udp hooks
bpf: sync tooling uapi header
bpf, libbpf: enable recvmsg attach types
bpf, bpftool: enable recvmsg attach types
bpf: more msg_name rewrite tests to test_sock_addr
bpf: expand section tests for test_section_names
Merge branch 'bpf-ppc-div-fix'
David S. Miller (14):
Merge tag 'wireless-drivers-for-davem-2019-06-07' of git://git.kernel.org/.../kvalo/wireless-drivers
Merge git://git.kernel.org/.../bpf/bpf
Merge tag 'linux-can-fixes-for-5.2-20190607' of git://git.kernel.org/.../mkl/linux-can
Merge tag 'mlx5-fixes-2019-06-07' of git://git.kernel.org/.../saeed/linux
Merge branch 'ibmvnic-Fixes-for-device-reset-handling'
Merge branch 'vxlan-geneve-linear'
Merge branch 'mlxsw-Various-fixes'
Merge branch 'net-mvpp2-prs-Fixes-for-VID-filtering'
Merge tag 'mac80211-for-davem-2019-06-14' of git://git.kernel.org/.../jberg/mac80211
Merge branch 'qmi_wwan-fix-QMAP-handling'
Merge branch 'tcp-add-three-static-keys'
Revert "net: phylink: set the autoneg state in phylink_phy_change"
Merge git://git.kernel.org/.../bpf/bpf
Merge branch 'tcp-fixes'
Dexuan Cui (1):
hv_sock: Suppress bogus "may be used uninitialized" warnings
Edward Srouji (1):
net/mlx5: Update pci error handler entries and command translation
Eli Britstein (1):
net/mlx5e: Support tagged tunnel over bond
Emmanuel Grumbach (1):
iwlwifi: fix load in rfkill flow for unified firmware
Enrico Weigelt (1):
net: ipv4: fib_semantics: fix uninitialized variable
Eric Biggers (1):
cfg80211: fix memory leak of wiphy device name
Eric Dumazet (12):
ipv6: flowlabel: fl6_sock_lookup() must use atomic_inc_not_zero
sysctl: define proc_do_static_key()
tcp: add tcp_rx_skb_cache sysctl
tcp: add tcp_tx_skb_cache sysctl
net: add high_order_alloc_disable sysctl/static key
tcp: limit payload size of sacked skbs
tcp: tcp_fragment() should apply sane memory limits
tcp: add tcp_min_snd_mss sysctl
tcp: enforce tcp_min_snd_mss in tcp_mtu_probing()
tcp: fix compile error if !CONFIG_SYSCTL
neigh: fix use-after-free read in pneigh_get_next
ax25: fix inconsistent lock state in ax25_destroy_timer
Eugen Hristev (1):
can: m_can: implement errata "Needless activation of MRAF irq"
Fabio Estevam (1):
can: flexcan: Remove unneeded registration message
George Wilkie (1):
mpls: fix warning with multi-label encap
Govindarajulu Varadarajan (1):
net: handle 802.1P vlan 0 packets properly
Gustavo A. R. Silva (1):
mac80211_hwsim: mark expected switch fall-through
Haiyang Zhang (1):
hv_netvsc: Set probe mode to sync
Hangbin Liu (1):
selftests/bpf: move test_lirc_mode2_user to TEST_GEN_PROGS_EXTENDED
Ido Schimmel (4):
mlxsw: spectrum: Use different seeds for ECMP and LAG hash
mlxsw: spectrum_router: Refresh nexthop neighbour when it becomes dead
selftests: mlxsw: Test nexthop offload indication
mlxsw: spectrum: Disallow prio-tagged packets when PVID is removed
Ilya Maximets (1):
xdp: check device pointer before clearing
Ioana Ciornei (1):
net: phylink: set the autoneg state in phylink_phy_change
Ivan Vecera (1):
be2net: Fix number of Rx queues used for flow hashing
Jakub Sitnicki (1):
bpf: sockmap, restore sk_write_space when psock gets dropped
Jeremy Sowden (1):
lapb: fixed leak of control-blocks.
Jia-Ju Bai (1):
iwlwifi: Fix double-free problems in iwl_req_fw_callback()
Jiong Wang (2):
selftests: bpf: move sub-register zero extension checks into subreg.c
selftests: bpf: complete sub-register zero extension checks
Jiri Pirko (2):
mlxsw: spectrum_flower: Fix TOS matching
selftests: tc_flower: Add TOS matching test
Joakim Zhang (1):
can: flexcan: fix timeout when set small bitrate
Johannes Berg (3):
nl80211: fill all policy .type entries
iwlwifi: mvm: remove d3_sram debugfs file
mac80211: drop robust management frames from unknown TA
John Crispin (1):
mac80211: fix rate reporting inside cfg80211_calculate_bitrate_he()
John Fastabend (2):
bpf: sockmap, fix use after free from sleep in psock backlog workqueue
net: tls, correctly account for copied bytes with multiple sk_msgs
John Hurley (1):
nfp: ensure skb network header is set for packet redirect
Jonathan Lemon (1):
bpf: lpm_trie: check left child of last leftmost node for NULL
Jouni Malinen (1):
mac80211: Do not use stack memory with scatterlist for GMAC
Krzesimir Nowak (1):
tools: bpftool: Fix JSON output when lookup fails
Linus Walleij (1):
net: dsa: rtl8366: Fix up VLAN filtering
Lior Cohen (1):
iwlwifi: mvm: change TLC config cmd sent by rs to be async
Lorenz Bauer (1):
bpf: fix out-of-bounds read in __bpf_skc_lookup
Luca Coelho (1):
cfg80211: use BIT_ULL in cfg80211_parse_mbssid_data()
Luke Nelson (1):
bpf, riscv: clear high 32 bits for ALU32 add/sub/neg/lsh/rsh/arsh
Manikanta Pubbisetty (1):
{nl,mac}80211: allow 4addr AP operation on crypto controlled devices
Martin KaFai Lau (4):
bpf: Check sk_fullsock() before returning from bpf_sk_lookup()
bpf: udp: ipv6: Avoid running reuseport's bpf_prog from __udp6_lib_err
bpf: udp: Avoid calling reuseport's bpf_prog from udp_gro
bpf: net: Set sk_bpf_storage back to NULL for cloned sk
Martynas Pumputis (2):
bpf: simplify definition of BPF_FIB_LOOKUP related flags
bpf: sync BPF_FIB_LOOKUP flag changes with BPF uapi
Masanari Iida (1):
linux-next: DOC: RDS: Fix a typo in rds.txt
Matt Chen (1):
iwlwifi: fix AX201 killer sku loading firmware issue
Matt Mullins (1):
bpf: fix nested bpf tracepoints with per-cpu data
Matteo Croce (3):
samples, bpf: suppress compiler warning
mpls: fix af_mpls dependencies
mpls: fix af_mpls dependencies for real
Maxim Mikityanskiy (1):
wireless: Skip directory when generating certificates
Maxime Chevallier (3):
net: ethtool: Allow matching on vlan DEI bit
net: mvpp2: prs: Fix parser range for VID filtering
net: mvpp2: prs: Use the correct helpers when removing all VID filters
Michael Schmitz (1):
net: phy: rename Asix Electronics PHY driver
Michal Rostecki (1):
libbpf: Return btf_fd for load_sk_storage_btf
Mordechay Goodstein (1):
cfg80211: util: fix bit count off by one
Naftali Goldstein (1):
mac80211: do not start any work during reconfigure flow
Nathan Chancellor (1):
rsi: Properly initialize data in rsi_sdio_ta_reset
Naveen N. Rao (2):
bpf: fix div64 overflow tests to properly detect errors
powerpc/bpf: use unsigned division instruction for 64-bit operations
Neil Horman (1):
sctp: Free cookie before we memdup a new one
Petr Machata (1):
mlxsw: spectrum_buffers: Reduce pool size on Spectrum-2
Pradeep Kumar Chitrapu (1):
mac80211: free peer keys before vif down in mesh
Raed Salem (1):
net/mlx5e: Fix source port matching in fdb peer flow rule
Randy Dunlap (1):
Documentation/networking: fix af_xdp.rst Sphinx warnings
Reinhard Speyerer (4):
qmi_wwan: add support for QMAP padding in the RX path
qmi_wwan: add network device usage statistics for qmimux devices
qmi_wwan: avoid RCU stalls on device disconnect when in QMAP mode
qmi_wwan: extend permitted QMAP mux_id value range
Robert Hancock (1):
net: dsa: microchip: Don't try to read stats for unused ports
Russell King - ARM Linux admin (1):
net: phylink: further mac_config documentation improvements
Sean Nyekjaer (2):
dt-bindings: can: mcp251x: add mcp25625 support
can: mcp251x: add support for mcp25625
Shahar S Matityahu (2):
iwlwifi: clear persistence bit according to device family
iwlwifi: print fseq info upon fw assert
Shay Agroskin (1):
net/mlx5e: Replace reciprocal_scale in TX select queue function
Stanislaw Gruszka (2):
rtw88: fix subscript above array bounds compiler warning
rtw88: avoid circular locking between local->iflist_mtx and rtwdev->mutex
Stefano Brivio (2):
vxlan: Don't assume linear buffers in error handler
geneve: Don't assume linear buffers in error handler
Stephen Barber (1):
vsock/virtio: set SOCK_DONE on peer shutdown
Stephen Suryaputra (1):
vrf: Increment Icmp6InMsgs on the original netdev
Taehee Yoo (1):
net: openvswitch: do not free vport if register_netdevice() is failed.
Takashi Iwai (3):
mwifiex: Fix possible buffer overflows at parsing bss descriptor
mwifiex: Abort at too short BSS descriptor element
mwifiex: Fix heap overflow in mwifiex_uap_parse_tail_ies()
Thomas Falcon (3):
ibmvnic: Do not close unopened driver during reset
ibmvnic: Refresh device multicast list after reset
ibmvnic: Fix unchecked return codes of memory allocations
Thomas Pedersen (1):
mac80211: mesh: fix RCU warning
Toshiaki Makita (3):
bpf, devmap: Fix premature entry free on destroying map
bpf, devmap: Add missing bulk queue free
bpf, devmap: Add missing RCU read lock on flush
Vlad Buslov (1):
net: sched: flower: don't call synchronize_rcu() on mask creation
Willem de Bruijn (2):
can: purge socket error queue on sock destruct
net: correct udp zerocopy refcnt also when zerocopy only on append
Xin Long (1):
tipc: purge deferredq list for each grp member in tipc_group_delete
Yan-Hsuan Chuang (1):
rtw88: fix unassigned rssi_level in rtw_sta_info
Yibo Zhao (1):
mac80211: only warn once on chanctx_conf being NULL
Young Xiao (1):
nfc: Ensure presence of required attributes in the deactivate_target handler
Yu Wang (1):
mac80211: handle deauthentication/disassociation from TDLS peer
Yuchung Cheng (1):
tcp: fix undo spurious SYNACK in passive Fast Open
YueHaibing (3):
mac80211: remove set but not used variable 'old'
rtw88: Make some symbols static
can: af_can: Fix error path of can_init()
Documentation/ABI/testing/sysfs-class-net-qmi | 4 +-
.../bindings/net/can/microchip,mcp251x.txt | 1 +
Documentation/networking/af_xdp.rst | 8 +-
Documentation/networking/ip-sysctl.txt | 16 +
Documentation/networking/rds.txt | 2 +-
arch/powerpc/include/asm/ppc-opcode.h | 1 +
arch/powerpc/net/bpf_jit.h | 2 +-
arch/powerpc/net/bpf_jit_comp64.c | 8 +-
arch/riscv/net/bpf_jit_comp.c | 24 +
arch/x86/net/bpf_jit_comp.c | 74 +--
drivers/net/can/flexcan.c | 5 +-
drivers/net/can/m_can/m_can.c | 21 +
drivers/net/can/spi/Kconfig | 5 +-
drivers/net/can/spi/mcp251x.c | 25 +-
drivers/net/can/usb/Kconfig | 6 -
drivers/net/can/xilinx_can.c | 2 +-
drivers/net/dsa/Makefile | 4 +-
drivers/net/dsa/microchip/ksz_common.c | 3 +
.../net/dsa/{realtek-smi.c => realtek-smi-core.c} | 2 +-
.../net/dsa/{realtek-smi.h => realtek-smi-core.h} | 0
drivers/net/dsa/rtl8366.c | 9 +-
drivers/net/dsa/rtl8366rb.c | 2 +-
drivers/net/ethernet/8390/Kconfig | 2 +-
drivers/net/ethernet/emulex/benet/be_ethtool.c | 2 +-
drivers/net/ethernet/ibm/ibmvnic.c | 19 +-
drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c | 23 +-
drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 8 +
drivers/net/ethernet/mellanox/mlx5/core/dev.c | 25 +-
drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 +
.../net/ethernet/mellanox/mlx5/core/en/tc_tun.c | 11 +-
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 9 +-
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 10 +-
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 3 -
drivers/net/ethernet/mellanox/mlx5/core/en_tx.c | 12 +-
drivers/net/ethernet/mellanox/mlxsw/reg.h | 2 +-
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 5 +-
.../net/ethernet/mellanox/mlxsw/spectrum_buffers.c | 4 +-
.../net/ethernet/mellanox/mlxsw/spectrum_flower.c | 4 +-
.../net/ethernet/mellanox/mlxsw/spectrum_router.c | 73 ++-
.../net/ethernet/netronome/nfp/nfp_net_common.c | 1 +
drivers/net/geneve.c | 2 +-
drivers/net/hyperv/netvsc_drv.c | 2 +-
drivers/net/phy/Kconfig | 2 +-
drivers/net/phy/Makefile | 2 +-
drivers/net/phy/{asix.c => ax88796b.c} | 0
drivers/net/usb/qmi_wwan.c | 103 +++-
drivers/net/vxlan.c | 2 +-
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 39 ++
drivers/net/wireless/intel/iwlwifi/fw/dbg.h | 2 +
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 1 -
drivers/net/wireless/intel/iwlwifi/iwl-prph.h | 22 +-
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 22 -
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 57 ---
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 23 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 20 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c | 3 +-
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 2 +
drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 2 +-
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 53 +-
drivers/net/wireless/mac80211_hwsim.c | 1 +
drivers/net/wireless/marvell/mwifiex/ie.c | 47 +-
drivers/net/wireless/marvell/mwifiex/scan.c | 19 +
drivers/net/wireless/realtek/rtw88/fw.c | 6 +-
drivers/net/wireless/realtek/rtw88/main.c | 3 +-
drivers/net/wireless/realtek/rtw88/phy.c | 22 +-
drivers/net/wireless/rsi/rsi_91x_sdio.c | 21 +-
include/linux/bpf-cgroup.h | 8 +
include/linux/bpf.h | 1 -
include/linux/phylink.h | 13 +-
include/linux/skmsg.h | 2 +
include/linux/sysctl.h | 3 +
include/linux/tcp.h | 4 +
include/net/addrconf.h | 16 +
include/net/cfg80211.h | 3 +-
include/net/flow_dissector.h | 1 +
include/net/netns/ipv4.h | 1 +
include/net/sock.h | 12 +-
include/net/tcp.h | 2 +
include/uapi/linux/bpf.h | 6 +-
include/uapi/linux/snmp.h | 1 +
kernel/bpf/core.c | 1 -
kernel/bpf/devmap.c | 9 +-
kernel/bpf/lpm_trie.c | 9 +-
kernel/bpf/syscall.c | 8 +
kernel/bpf/verifier.c | 12 +-
kernel/sysctl.c | 44 +-
kernel/trace/bpf_trace.c | 100 +++-
net/ax25/ax25_route.c | 2 +
net/can/af_can.c | 25 +-
net/core/bpf_sk_storage.c | 3 +-
net/core/dev.c | 30 +-
net/core/ethtool.c | 5 +
net/core/filter.c | 26 +-
net/core/neighbour.c | 7 +
net/core/skbuff.c | 1 +
net/core/sock.c | 7 +-
net/core/sysctl_net_core.c | 7 +
net/ipv4/fib_semantics.c | 2 +-
net/ipv4/ip_output.c | 2 +-
net/ipv4/proc.c | 1 +
net/ipv4/sysctl_net_ipv4.c | 23 +
net/ipv4/tcp.c | 6 +
net/ipv4/tcp_input.c | 28 +-
net/ipv4/tcp_ipv4.c | 1 +
net/ipv4/tcp_output.c | 10 +-
net/ipv4/tcp_timer.c | 1 +
net/ipv4/udp.c | 10 +-
net/ipv6/icmp.c | 17 +-
net/ipv6/ip6_flowlabel.c | 7 +-
net/ipv6/ip6_output.c | 2 +-
net/ipv6/reassembly.c | 4 +-
net/ipv6/udp.c | 8 +-
net/lapb/lapb_iface.c | 1 +
net/mac80211/ieee80211_i.h | 12 +-
net/mac80211/key.c | 2 -
net/mac80211/mesh.c | 6 +-
net/mac80211/mlme.c | 12 +-
net/mac80211/rx.c | 2 +
net/mac80211/tdls.c | 23 +
net/mac80211/util.c | 8 +-
net/mac80211/wpa.c | 7 +-
net/mpls/Kconfig | 1 +
net/mpls/mpls_iptunnel.c | 2 +-
net/nfc/netlink.c | 3 +-
net/openvswitch/vport-internal_dev.c | 18 +-
net/sched/cls_flower.c | 34 +-
net/sctp/sm_make_chunk.c | 8 +
net/tipc/group.c | 1 +
net/tls/tls_sw.c | 1 -
net/vmw_vsock/hyperv_transport.c | 4 +-
net/vmw_vsock/virtio_transport_common.c | 4 +-
net/wireless/Makefile | 1 +
net/wireless/core.c | 8 +-
net/wireless/nl80211.c | 99 +++-
net/wireless/pmsr.c | 4 +-
net/wireless/scan.c | 4 +-
net/wireless/util.c | 4 +-
net/xdp/xdp_umem.c | 11 +-
samples/bpf/bpf_load.c | 2 +-
samples/bpf/task_fd_query_user.c | 2 +-
tools/bpf/bpftool/Documentation/bpftool-cgroup.rst | 6 +-
tools/bpf/bpftool/Documentation/bpftool-prog.rst | 2 +-
tools/bpf/bpftool/bash-completion/bpftool | 5 +-
tools/bpf/bpftool/cgroup.c | 5 +-
tools/bpf/bpftool/map.c | 2 +
tools/bpf/bpftool/prog.c | 3 +-
tools/include/uapi/linux/bpf.h | 6 +-
tools/lib/bpf/libbpf.c | 32 +-
tools/lib/bpf/libbpf_internal.h | 4 +-
tools/lib/bpf/libbpf_probes.c | 13 +-
tools/testing/selftests/bpf/Makefile | 7 +-
.../selftests/bpf/prog_tests/flow_dissector.c | 1 +
tools/testing/selftests/bpf/test_lpm_map.c | 41 +-
tools/testing/selftests/bpf/test_section_names.c | 10 +
tools/testing/selftests/bpf/test_sock_addr.c | 213 +++++++-
.../testing/selftests/bpf/verifier/div_overflow.c | 14 +-
tools/testing/selftests/bpf/verifier/subreg.c | 533 +++++++++++++++++++++
.../selftests/drivers/net/mlxsw/rtnetlink.sh | 47 ++
.../testing/selftests/net/forwarding/tc_flower.sh | 36 +-
161 files changed, 2139 insertions(+), 539 deletions(-)
rename drivers/net/dsa/{realtek-smi.c => realtek-smi-core.c} (99%)
rename drivers/net/dsa/{realtek-smi.h => realtek-smi-core.h} (100%)
rename drivers/net/phy/{asix.c => ax88796b.c} (100%)
create mode 100644 tools/testing/selftests/bpf/verifier/subreg.c
^ permalink raw reply
* Re: [PATCH] uapi: avoid namespace conflict in linux/posix_types.h
From: Linus Torvalds @ 2019-06-17 18:16 UTC (permalink / raw)
To: Florian Weimer
Cc: Joseph Myers, Arnd Bergmann, Linux API, linux-arch, Netdev,
Laura Abbott, Paul Burton, Deepa Dinamani,
Linux List Kernel Mailing
In-Reply-To: <CAHk-=wgiZNERDN7p-bsCzzYGRjeqTQw7kJxJnXAHVjqqO8PGrg@mail.gmail.com>
On Mon, Jun 17, 2019 at 11:13 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> That one we might be able to just fix by renaming "fds_bits" to "__fds_bits".
That said, moving it to another file might be the better option anyway.
I think fd_set and friends are now supposed to be in <sys/select.h>
anyway, and the "it was in <sys/types.h>" is all legacy.
Linus
^ permalink raw reply
* Re: [RFC PATCH bpf-next 4/8] libbpf: identify maps by section index in addition to offset
From: Song Liu @ 2019-06-17 18:15 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Song Liu, Andrii Nakryiko, bpf, Networking, Alexei Starovoitov,
Daniel Borkmann, Kernel Team
In-Reply-To: <CAEf4BzYKtA9Hk5oswZVD_pZ-VxjXXd_OV_bRs+42cfgf8dqodw@mail.gmail.com>
> On Jun 17, 2019, at 11:06 AM, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>
> On Sat, Jun 15, 2019 at 2:08 PM Song Liu <liu.song.a23@gmail.com> wrote:
>>
>> On Mon, Jun 10, 2019 at 9:37 PM Andrii Nakryiko <andriin@fb.com> wrote:
>>>
>>> To support maps to be defined in multiple sections, it's important to
>>> identify map not just by offset within its section, but section index as
>>> well. This patch adds tracking of section index.
>>>
>>> For global data, we record section index of corresponding
>>> .data/.bss/.rodata ELF section for uniformity, and thus don't need
>>> a special value of offset for those maps.
>>>
>>> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
>>> ---
>>> tools/lib/bpf/libbpf.c | 42 ++++++++++++++++++++++++++----------------
>>> 1 file changed, 26 insertions(+), 16 deletions(-)
>>>
>
> <snip>
>
>>> @@ -3472,13 +3488,7 @@ bpf_object__find_map_fd_by_name(struct bpf_object *obj, const char *name)
>>> struct bpf_map *
>>> bpf_object__find_map_by_offset(struct bpf_object *obj, size_t offset)
>>> {
>>> - int i;
>>> -
>>> - for (i = 0; i < obj->nr_maps; i++) {
>>> - if (obj->maps[i].offset == offset)
>>> - return &obj->maps[i];
>>> - }
>>> - return ERR_PTR(-ENOENT);
>>> + return ERR_PTR(-ENOTSUP);
>>
>> I probably missed some discussion. But is it OK to stop supporting
>> this function?
>
> This function was added long time ago for some perf (the tool)
> specific use case. But I haven't found any uses of that in kernel
> code, as well as anywhere on github/internal FB code base. It appears
> it's not used anywhere.
>
> Also, this function makes bad assumption that map can be identified by
> single offset, while we are going to support maps in two (or more, if
> necessary) different ELF sections, so offset is not unique anymore.
> It's not clear what's the intended use case for this API is, looking
> up by name should be the way to do this. Given it's not used, but we
> still need to preserve ABI, I switched it to return -ENOTSUP.
Good survey of the use cases! Yeah, I agree returning -ENOTSUP is the
best option here.
Acked-by: Song Liu <songliubraving@fb.com>
^ permalink raw reply
* Re: [PATCH] uapi: avoid namespace conflict in linux/posix_types.h
From: Linus Torvalds @ 2019-06-17 18:13 UTC (permalink / raw)
To: Florian Weimer
Cc: Joseph Myers, Arnd Bergmann, Linux API, linux-arch, Netdev,
Laura Abbott, Paul Burton, Deepa Dinamani,
Linux List Kernel Mailing
In-Reply-To: <87k1dkdr9c.fsf@oldenburg2.str.redhat.com>
On Mon, Jun 17, 2019 at 11:03 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> There's also __kernel_fd_set in <linux/posix_types.h>. I may have
> lumped this up with <asm/posix_types.h>, but it has the same problem.
Hmm.
That one we might be able to just fix by renaming "fds_bits" to "__fds_bits".
Unlike the "val[]" thing, I don't think anybody is supposed to access
those fields directly.
Of course, "supposed to" and "does" are two very very different things ;)
Linus
^ permalink raw reply
* [PATCH net v2 2/2] net: netem: fix use after free and double free with packet corruption
From: Jakub Kicinski @ 2019-06-17 18:11 UTC (permalink / raw)
To: davem, xiyou.wangcong
Cc: stephen, jhs, jiri, netem, netdev, oss-drivers, edumazet, posk,
nhorman
In-Reply-To: <20190617181111.5025-1-jakub.kicinski@netronome.com>
Brendan reports that the use of netem's packet corruption capability
leads to strange crashes. This seems to be caused by
commit d66280b12bd7 ("net: netem: use a list in addition to rbtree")
which uses skb->next pointer to construct a fast-path queue of
in-order skbs.
Packet corruption code has to invoke skb_gso_segment() in case
of skbs in need of GSO. skb_gso_segment() returns a list of
skbs. If next pointers of the skbs on that list do not get cleared
fast path list may point to freed skbs or skbs which are also on
the RB tree.
Let's say skb gets segmented into 3 frames:
A -> B -> C
A gets hooked to the t_head t_tail list by tfifo_enqueue(), but it's
next pointer didn't get cleared so we have:
h t
|/
A -> B -> C
Now if B and C get also get enqueued successfully all is fine, because
tfifo_enqueue() will overwrite the list in order. IOW:
Enqueue B:
h t
| |
A -> B C
Enqueue C:
h t
| |
A -> B -> C
But if B and C get reordered we may end up with:
h t RB tree
|/ |
A -> B -> C B
\
C
Or if they get dropped just:
h t
|/
A -> B -> C
where A and B are already freed.
To reproduce either limit has to be set low to cause freeing of
segs or reorders have to happen (due to delay jitter).
Note that we only have to mark the first segment as not on the
list, "finish_segs" handling of other frags already does that.
Another caveat is that qdisc_drop_all() still has to free all
segments correctly in case of drop of first segment, therefore
we re-link segs before calling it.
v2:
- re-link before drop, v1 was leaking non-first segs if limit
was hit at the first seg
- better commit message which lead to discovering the above :)
Reported-by: Brendan Galloway <brendan.galloway@netronome.com>
Fixes: d66280b12bd7 ("net: netem: use a list in addition to rbtree")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
net/sched/sch_netem.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/net/sched/sch_netem.c b/net/sched/sch_netem.c
index 3b3e2d772c3b..b17f2ed970e2 100644
--- a/net/sched/sch_netem.c
+++ b/net/sched/sch_netem.c
@@ -493,17 +493,14 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch,
*/
if (q->corrupt && q->corrupt >= get_crandom(&q->corrupt_cor)) {
if (skb_is_gso(skb)) {
- segs = netem_segment(skb, sch, to_free);
- if (!segs)
+ skb = netem_segment(skb, sch, to_free);
+ if (!skb)
return rc_drop;
- qdisc_skb_cb(segs)->pkt_len = segs->len;
- } else {
- segs = skb;
+ segs = skb->next;
+ skb_mark_not_on_list(skb);
+ qdisc_skb_cb(skb)->pkt_len = skb->len;
}
- skb = segs;
- segs = segs->next;
-
skb = skb_unshare(skb, GFP_ATOMIC);
if (unlikely(!skb)) {
qdisc_qstats_drop(sch);
@@ -520,6 +517,8 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch,
}
if (unlikely(sch->q.qlen >= sch->limit)) {
+ /* re-link segs, so that qdisc_drop_all() frees them all */
+ skb->next = segs;
qdisc_drop_all(skb, sch, to_free);
return rc_drop;
}
--
2.21.0
^ permalink raw reply related
* [PATCH net v2 1/2] net: netem: fix backlog accounting for corrupted GSO frames
From: Jakub Kicinski @ 2019-06-17 18:11 UTC (permalink / raw)
To: davem, xiyou.wangcong
Cc: stephen, jhs, jiri, netem, netdev, oss-drivers, edumazet, posk,
nhorman
In-Reply-To: <20190617181111.5025-1-jakub.kicinski@netronome.com>
When GSO frame has to be corrupted netem uses skb_gso_segment()
to produce the list of frames, and re-enqueues the segments one
by one. The backlog length has to be adjusted to account for
new frames.
The current calculation is incorrect, leading to wrong backlog
lengths in the parent qdisc (both bytes and packets), and
incorrect packet backlog count in netem itself.
Parent backlog goes negative, netem's packet backlog counts
all non-first segments twice (thus remaining non-zero even
after qdisc is emptied).
Move the variables used to count the adjustment into local
scope to make 100% sure they aren't used at any stage in
backports.
Fixes: 6071bd1aa13e ("netem: Segment GSO packets on enqueue")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
net/sched/sch_netem.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/net/sched/sch_netem.c b/net/sched/sch_netem.c
index 956ff3da81f4..3b3e2d772c3b 100644
--- a/net/sched/sch_netem.c
+++ b/net/sched/sch_netem.c
@@ -439,8 +439,7 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch,
struct netem_skb_cb *cb;
struct sk_buff *skb2;
struct sk_buff *segs = NULL;
- unsigned int len = 0, last_len, prev_len = qdisc_pkt_len(skb);
- int nb = 0;
+ unsigned int prev_len = qdisc_pkt_len(skb);
int count = 1;
int rc = NET_XMIT_SUCCESS;
int rc_drop = NET_XMIT_DROP;
@@ -497,6 +496,7 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch,
segs = netem_segment(skb, sch, to_free);
if (!segs)
return rc_drop;
+ qdisc_skb_cb(segs)->pkt_len = segs->len;
} else {
segs = skb;
}
@@ -593,6 +593,11 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch,
finish_segs:
if (segs) {
+ unsigned int len, last_len;
+ int nb = 0;
+
+ len = skb->len;
+
while (segs) {
skb2 = segs->next;
skb_mark_not_on_list(segs);
@@ -608,9 +613,7 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch,
}
segs = skb2;
}
- sch->q.qlen += nb;
- if (nb > 1)
- qdisc_tree_reduce_backlog(sch, 1 - nb, prev_len - len);
+ qdisc_tree_reduce_backlog(sch, -nb, prev_len - len);
}
return NET_XMIT_SUCCESS;
}
--
2.21.0
^ permalink raw reply related
* [PATCH net v2 0/2] net: netem: fix issues with corrupting GSO frames
From: Jakub Kicinski @ 2019-06-17 18:11 UTC (permalink / raw)
To: davem, xiyou.wangcong
Cc: stephen, jhs, jiri, netem, netdev, oss-drivers, edumazet, posk,
nhorman
Hi!
Corrupting GSO frames currently leads to crashes, due to skb use
after free. These stem from the skb list handling - the segmented
skbs come back on a list, and this list is not properly unlinked
before enqueuing the segments. Turns out this condition is made
very likely to occur because of another bug - in backlog accounting.
Segments are counted twice, which means qdisc's limit gets reached
leading to drops and making the use after free very likely to happen.
The bugs are fixed in order in which they were added to the tree.
Jakub Kicinski (2):
net: netem: fix backlog accounting for corrupted GSO frames
net: netem: fix use after free and double free with packet corruption
net/sched/sch_netem.c | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
--
2.21.0
^ permalink raw reply
* Re: [PATCH bpf-next 2/8] libbpf: extract BTF loading and simplify ELF parsing logic
From: Song Liu @ 2019-06-17 18:07 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Song Liu, Andrii Nakryiko, bpf, Networking, Alexei Starovoitov,
Daniel Borkmann, Kernel Team
In-Reply-To: <CAEf4BzY_X9jPvwgcVQozS4RyonXEK9mkd58uvPVrjFi-Gvui3Q@mail.gmail.com>
> On Jun 17, 2019, at 10:24 AM, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>
> On Sat, Jun 15, 2019 at 1:26 PM Song Liu <liu.song.a23@gmail.com> wrote:
>>
>> On Mon, Jun 10, 2019 at 9:49 PM Andrii Nakryiko <andriin@fb.com> wrote:
>>>
>>> As a preparation for adding BTF-based BPF map loading, extract .BTF and
>>> .BTF.ext loading logic. Also simplify error handling in
>>> bpf_object__elf_collect() by returning early, as there is no common
>>> clean up to be done.
>>>
>>> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
>>> ---
>>> tools/lib/bpf/libbpf.c | 137 ++++++++++++++++++++++-------------------
>>> 1 file changed, 75 insertions(+), 62 deletions(-)
>>>
>>> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
>>> index ba89d9727137..9e39a0a33aeb 100644
>>> --- a/tools/lib/bpf/libbpf.c
>>> +++ b/tools/lib/bpf/libbpf.c
>>> @@ -1078,6 +1078,58 @@ static void bpf_object__sanitize_btf_ext(struct bpf_object *obj)
>>> }
>>> }
>>>
>>> +static int bpf_object__load_btf(struct bpf_object *obj,
>>> + Elf_Data *btf_data,
>>> + Elf_Data *btf_ext_data)
>>> +{
>>> + int err = 0;
>>> +
>>> + if (btf_data) {
>>> + obj->btf = btf__new(btf_data->d_buf, btf_data->d_size);
>>> + if (IS_ERR(obj->btf)) {
>>> + pr_warning("Error loading ELF section %s: %d.\n",
>>> + BTF_ELF_SEC, err);
>>> + goto out;
>>
>> If we goto out here, we will return 0.
>
>
> Yes, it's intentional. BTF is treated as optional, so if we fail to
> load it, libbpf will emit warning, but will proceed as nothing
> happened and no BTF was supposed to be loaded.
>
>>
>>> + }
>>> + err = btf__finalize_data(obj, obj->btf);
>>> + if (err) {
>>> + pr_warning("Error finalizing %s: %d.\n",
>>> + BTF_ELF_SEC, err);
>>> + goto out;
>>> + }
>>> + bpf_object__sanitize_btf(obj);
>>> + err = btf__load(obj->btf);
>>> + if (err) {
>>> + pr_warning("Error loading %s into kernel: %d.\n",
>>> + BTF_ELF_SEC, err);
>>> + goto out;
>>> + }
>>> + }
>>> + if (btf_ext_data) {
>>> + if (!obj->btf) {
>>> + pr_debug("Ignore ELF section %s because its depending ELF section %s is not found.\n",
>>> + BTF_EXT_ELF_SEC, BTF_ELF_SEC);
>>> + goto out;
>>
>> We will also return 0 when goto out here.
>
>
> See above, it's original behavior of libbpf.
>
>>
>>> + }
>>> + obj->btf_ext = btf_ext__new(btf_ext_data->d_buf,
>>> + btf_ext_data->d_size);
>>> + if (IS_ERR(obj->btf_ext)) {
>>> + pr_warning("Error loading ELF section %s: %ld. Ignored and continue.\n",
>>> + BTF_EXT_ELF_SEC, PTR_ERR(obj->btf_ext));
>>> + obj->btf_ext = NULL;
>>> + goto out;
>> And, here. And we will not free obj->btf.
>
> This is situation in which we successfully loaded .BTF, but failed to
> load .BTF.ext. In that case we'll warn about .BTF.ext, but will drop
> it and continue with .BTF only.
>
Yeah, that makes sense.
Shall we let bpf_object__load_btf() return void? Since it always
returns 0?
Thanks,
Song
<snip>
^ permalink raw reply
* Re: [RFC PATCH net-next 2/2] net: tls: export protocol version and cipher to socket diag
From: Jakub Kicinski @ 2019-06-17 18:07 UTC (permalink / raw)
To: Davide Caratti
Cc: David S. Miller, Dave Watson, Boris Pismenny, Aviad Yehezkel,
John Fastabend, Daniel Borkmann, netdev
In-Reply-To: <5ed5d6b3356c505ece2a354847e3aafd09fb82f3.camel@redhat.com>
On Mon, 17 Jun 2019 18:04:06 +0200, Davide Caratti wrote:
> On Wed, 2019-06-05 at 16:25 -0700, Jakub Kicinski wrote:
> > On Wed, 5 Jun 2019 17:39:23 +0200, Davide Caratti wrote:
> > We need some indication of the directions in which kTLS is active
> > (none, rx, tx, rx/tx).
> >
> > Also perhaps could you add TLS_SW vs TLS_HW etc. ? :)
>
> I can add a couple of u16 (or larger?) bitmasks to dump txconf and rxconf.
> do you think this is sufficient?
SGTM!
> > > + int err = 0;
> >
> > There should be no need to init this.
> >
> > > + if (sk->sk_state != TCP_ESTABLISHED)
> >
> > Hmm.. why this check? We never clean up the state once installed until
> > the socket dies completely (currently, pending John's unhash work).
>
> the goal was to ensure that we don't read ctx anymore after
> tls_sk_proto_close() has freed ctx, and I thought that a test on the value
> of sk_state was sufficient.
>
> If it's not, then we might invent something else. For example, we might
> defer freeing kTLS ctx, so that it's called as the very last thing with
> tcp_cleanup_ulp().
Mm.. I was hoping the user space can no longer access a socket once
it reaches sk_prot->close :S Perhaps I got this wrong. If it can
we need to make sure we don't free context before calling tcp_close()
otherwise the state may still be established, no?
In particular:
#ifdef CONFIG_TLS_DEVICE
if (ctx->rx_conf == TLS_HW)
tls_device_offload_cleanup_rx(sk);
if (ctx->tx_conf != TLS_HW && ctx->rx_conf != TLS_HW) {
#else
{
#endif
tls_ctx_free(ctx); <<< <<< <<< <<< kfree()
ctx = NULL;
}
skip_tx_cleanup:
release_sock(sk);
sk_proto_close(sk, timeout); <<< <<< <<< <<< tcp_close()
/* free ctx for TLS_HW_RECORD, used by tcp_set_state
* for sk->sk_prot->unhash [tls_hw_unhash]
*/
if (free_ctx)
tls_ctx_free(ctx);
^ permalink raw reply
* Re: [RFC PATCH bpf-next 4/8] libbpf: identify maps by section index in addition to offset
From: Andrii Nakryiko @ 2019-06-17 18:06 UTC (permalink / raw)
To: Song Liu
Cc: Andrii Nakryiko, bpf, Networking, Alexei Starovoitov,
Daniel Borkmann, Kernel Team
In-Reply-To: <CAPhsuW6iicoRN3Sk6Uv-ten4xjjmqG1qmfmXyKngqVSYC9qbEQ@mail.gmail.com>
On Sat, Jun 15, 2019 at 2:08 PM Song Liu <liu.song.a23@gmail.com> wrote:
>
> On Mon, Jun 10, 2019 at 9:37 PM Andrii Nakryiko <andriin@fb.com> wrote:
> >
> > To support maps to be defined in multiple sections, it's important to
> > identify map not just by offset within its section, but section index as
> > well. This patch adds tracking of section index.
> >
> > For global data, we record section index of corresponding
> > .data/.bss/.rodata ELF section for uniformity, and thus don't need
> > a special value of offset for those maps.
> >
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > ---
> > tools/lib/bpf/libbpf.c | 42 ++++++++++++++++++++++++++----------------
> > 1 file changed, 26 insertions(+), 16 deletions(-)
> >
<snip>
> > @@ -3472,13 +3488,7 @@ bpf_object__find_map_fd_by_name(struct bpf_object *obj, const char *name)
> > struct bpf_map *
> > bpf_object__find_map_by_offset(struct bpf_object *obj, size_t offset)
> > {
> > - int i;
> > -
> > - for (i = 0; i < obj->nr_maps; i++) {
> > - if (obj->maps[i].offset == offset)
> > - return &obj->maps[i];
> > - }
> > - return ERR_PTR(-ENOENT);
> > + return ERR_PTR(-ENOTSUP);
>
> I probably missed some discussion. But is it OK to stop supporting
> this function?
This function was added long time ago for some perf (the tool)
specific use case. But I haven't found any uses of that in kernel
code, as well as anywhere on github/internal FB code base. It appears
it's not used anywhere.
Also, this function makes bad assumption that map can be identified by
single offset, while we are going to support maps in two (or more, if
necessary) different ELF sections, so offset is not unique anymore.
It's not clear what's the intended use case for this API is, looking
up by name should be the way to do this. Given it's not used, but we
still need to preserve ABI, I switched it to return -ENOTSUP.
>
> Thanks,
> Song
>
> > }
> >
> > long libbpf_get_error(const void *ptr)
> > --
> > 2.17.1
> >
^ permalink raw reply
* Re: [PATCH] uapi: avoid namespace conflict in linux/posix_types.h
From: Florian Weimer @ 2019-06-17 18:02 UTC (permalink / raw)
To: Linus Torvalds
Cc: Joseph Myers, Arnd Bergmann, Linux API, linux-arch, Netdev,
Laura Abbott, Paul Burton, Deepa Dinamani,
Linux List Kernel Mailing
In-Reply-To: <CAHk-=wjCwnk0nfgCcMYqqX6o9bBrutDtut_fzZ-2VwiZR1y4kw@mail.gmail.com>
* Linus Torvalds:
>> A different approach would rename <asm/posix_types.h> to something more
>> basic, exclude the two structs, and move all internal #includes which do
>> need the structs to the new header.
>
> In fact, I wouldn't even rename <posix_types.h> at all, I'd just make
> sure it's namespace-clean.
>
> I _think_ the only thing causing problems is '__kernel_fsid_t' due to
> that "val[]" thing, so just remove ity entirely, and add it to
> <statfs.h> instead.
There's also __kernel_fd_set in <linux/posix_types.h>. I may have
lumped this up with <asm/posix_types.h>, but it has the same problem.
If it's okay to move them both to more natural places (maybe
<asm/statfs.h> and <linux/socket.h>), I think that should work well for
glibc.
However, application code may have to include additional header files.
I think the GCC/LLVM sanitizers currently get __kernel_fd_set from
<linux/posix_types.h> (but I think we discussed it before, they really
shouldn't use this type because it's misleading).
Thanks,
Florian
^ permalink raw reply
* Re: [PATCH] net/mlx5e: reduce stack usage in mlx5_eswitch_termtbl_create
From: Saeed Mahameed @ 2019-06-17 18:02 UTC (permalink / raw)
To: davem@davemloft.net, arnd@arndb.de, leon@kernel.org
Cc: linux-rdma@vger.kernel.org, Or Gerlitz, Oz Shlomo, Paul Blakey,
Mark Bloch, Maor Gottlieb, linux-kernel@vger.kernel.org,
Eli Britstein, netdev@vger.kernel.org
In-Reply-To: <20190617110855.2085326-1-arnd@arndb.de>
On Mon, 2019-06-17 at 13:08 +0200, Arnd Bergmann wrote:
> Putting an empty 'mlx5_flow_spec' structure on the stack is a bit
> wasteful and causes a warning on 32-bit architectures when building
> with clang -fsanitize-coverage:
>
> drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c:
> In function 'mlx5_eswitch_termtbl_create':
> drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c:90
> :1: error: the frame size of 1032 bytes is larger than 1024 bytes [-
> Werror=frame-larger-than=]
>
> Since the structure is never written to, we can statically allocate
> it to avoid the stack usage. To be on the safe side, mark all
> subsequent function arguments that we pass it into as 'const'
> as well.
>
> Fixes: 10caabdaad5a ("net/mlx5e: Use termination table for VLAN push
> actions")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> .../mlx5/core/eswitch_offloads_termtbl.c | 2 +-
> .../net/ethernet/mellanox/mlx5/core/fs_core.c | 20 +++++++++------
> ----
> include/linux/mlx5/fs.h | 2 +-
> 3 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git
> a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c
> b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c
> index cb7d8ebe2c95..171f3d4ef9ac 100644
> ---
> a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c
> +++
> b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c
> @@ -50,7 +50,7 @@ mlx5_eswitch_termtbl_create(struct mlx5_core_dev
> *dev,
> struct mlx5_flow_act *flow_act)
> {
> struct mlx5_flow_namespace *root_ns;
> - struct mlx5_flow_spec spec = {};
> + static const struct mlx5_flow_spec spec = {};
LGTM, just make sure please to have a reverse xmas tree here.
Mark, please let me know if you are ok with such API constrain to flow
steering (spec must be const).
Thanks,
Saeed.
> int prio, flags;
> int err;
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> index fe76c6fd6d80..739123e1363b 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> @@ -584,7 +584,7 @@ static int insert_fte(struct mlx5_flow_group *fg,
> struct fs_fte *fte)
> }
>
> static struct fs_fte *alloc_fte(struct mlx5_flow_table *ft,
> - u32 *match_value,
> + const u32 *match_value,
> struct mlx5_flow_act *flow_act)
> {
> struct mlx5_flow_steering *steering = get_steering(&ft->node);
> @@ -612,7 +612,7 @@ static void dealloc_flow_group(struct
> mlx5_flow_steering *steering,
>
> static struct mlx5_flow_group *alloc_flow_group(struct
> mlx5_flow_steering *steering,
> u8
> match_criteria_enable,
> - void *match_criteria,
> + const void
> *match_criteria,
> int start_index,
> int end_index)
> {
> @@ -642,7 +642,7 @@ static struct mlx5_flow_group
> *alloc_flow_group(struct mlx5_flow_steering *steer
>
> static struct mlx5_flow_group *alloc_insert_flow_group(struct
> mlx5_flow_table *ft,
> u8
> match_criteria_enable,
> - void
> *match_criteria,
> + const void
> *match_criteria,
> int start_index,
> int end_index,
> struct list_head
> *prev)
> @@ -1285,7 +1285,7 @@ add_rule_fte(struct fs_fte *fte,
> }
>
> static struct mlx5_flow_group *alloc_auto_flow_group(struct
> mlx5_flow_table *ft,
> - struct
> mlx5_flow_spec *spec)
> + const struct
> mlx5_flow_spec *spec)
> {
> struct list_head *prev = &ft->node.children;
> struct mlx5_flow_group *fg;
> @@ -1451,7 +1451,7 @@ static int check_conflicting_ftes(struct fs_fte
> *fte, const struct mlx5_flow_act
> }
>
> static struct mlx5_flow_handle *add_rule_fg(struct mlx5_flow_group
> *fg,
> - u32 *match_value,
> + const u32 *match_value,
> struct mlx5_flow_act
> *flow_act,
> struct
> mlx5_flow_destination *dest,
> int dest_num,
> @@ -1536,7 +1536,7 @@ static void free_match_list(struct
> match_list_head *head)
>
> static int build_match_list(struct match_list_head *match_head,
> struct mlx5_flow_table *ft,
> - struct mlx5_flow_spec *spec)
> + const struct mlx5_flow_spec *spec)
> {
> struct rhlist_head *tmp, *list;
> struct mlx5_flow_group *g;
> @@ -1589,7 +1589,7 @@ static u64 matched_fgs_get_version(struct
> list_head *match_head)
>
> static struct fs_fte *
> lookup_fte_locked(struct mlx5_flow_group *g,
> - u32 *match_value,
> + const u32 *match_value,
> bool take_write)
> {
> struct fs_fte *fte_tmp;
> @@ -1622,7 +1622,7 @@ lookup_fte_locked(struct mlx5_flow_group *g,
> static struct mlx5_flow_handle *
> try_add_to_existing_fg(struct mlx5_flow_table *ft,
> struct list_head *match_head,
> - struct mlx5_flow_spec *spec,
> + const struct mlx5_flow_spec *spec,
> struct mlx5_flow_act *flow_act,
> struct mlx5_flow_destination *dest,
> int dest_num,
> @@ -1715,7 +1715,7 @@ try_add_to_existing_fg(struct mlx5_flow_table
> *ft,
>
> static struct mlx5_flow_handle *
> _mlx5_add_flow_rules(struct mlx5_flow_table *ft,
> - struct mlx5_flow_spec *spec,
> + const struct mlx5_flow_spec *spec,
> struct mlx5_flow_act *flow_act,
> struct mlx5_flow_destination *dest,
> int dest_num)
> @@ -1823,7 +1823,7 @@ static bool fwd_next_prio_supported(struct
> mlx5_flow_table *ft)
>
> struct mlx5_flow_handle *
> mlx5_add_flow_rules(struct mlx5_flow_table *ft,
> - struct mlx5_flow_spec *spec,
> + const struct mlx5_flow_spec *spec,
> struct mlx5_flow_act *flow_act,
> struct mlx5_flow_destination *dest,
> int num_dest)
> diff --git a/include/linux/mlx5/fs.h b/include/linux/mlx5/fs.h
> index 2ddaa97f2179..c0c029664527 100644
> --- a/include/linux/mlx5/fs.h
> +++ b/include/linux/mlx5/fs.h
> @@ -200,7 +200,7 @@ struct mlx5_flow_act {
> */
> struct mlx5_flow_handle *
> mlx5_add_flow_rules(struct mlx5_flow_table *ft,
> - struct mlx5_flow_spec *spec,
> + const struct mlx5_flow_spec *spec,
> struct mlx5_flow_act *flow_act,
> struct mlx5_flow_destination *dest,
> int num_dest);
^ permalink raw reply
* Re: [RFC PATCH bpf-next 3/8] libbpf: refactor map initialization
From: Andrii Nakryiko @ 2019-06-17 18:01 UTC (permalink / raw)
To: Song Liu
Cc: Andrii Nakryiko, bpf, Networking, Alexei Starovoitov,
Daniel Borkmann, Kernel Team
In-Reply-To: <CAPhsuW7bowxNMr22UkCvTkq8VHYrNiEJtQSdZjausj_8d4oYUQ@mail.gmail.com>
On Sat, Jun 15, 2019 at 2:03 PM Song Liu <liu.song.a23@gmail.com> wrote:
>
> On Mon, Jun 10, 2019 at 9:35 PM Andrii Nakryiko <andriin@fb.com> wrote:
> >
> > User and global data maps initialization has gotten pretty complicated
> > and unnecessarily convoluted. This patch splits out the logic for global
> > data map and user-defined map initialization. It also removes the
> > restriction of pre-calculating how many maps will be initialized,
> > instead allowing to keep adding new maps as they are discovered, which
> > will be used later for BTF-defined map definitions.
> >
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > ---
> > tools/lib/bpf/libbpf.c | 244 ++++++++++++++++++++++-------------------
> > 1 file changed, 134 insertions(+), 110 deletions(-)
> >
> > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > index 9e39a0a33aeb..c931ee7e1fd2 100644
> > --- a/tools/lib/bpf/libbpf.c
> > +++ b/tools/lib/bpf/libbpf.c
> > @@ -234,6 +234,7 @@ struct bpf_object {
> > size_t nr_programs;
> > struct bpf_map *maps;
> > size_t nr_maps;
> > + size_t maps_cap;
> > struct bpf_secdata sections;
> >
> > bool loaded;
> > @@ -763,12 +764,38 @@ int bpf_object__variable_offset(const struct bpf_object *obj, const char *name,
> > return -ENOENT;
> > }
> >
> > -static bool bpf_object__has_maps(const struct bpf_object *obj)
> > +static struct bpf_map *bpf_object__add_map(struct bpf_object *obj)
> > {
> > - return obj->efile.maps_shndx >= 0 ||
> > - obj->efile.data_shndx >= 0 ||
> > - obj->efile.rodata_shndx >= 0 ||
> > - obj->efile.bss_shndx >= 0;
> > + struct bpf_map *new_maps;
> > + size_t new_cap;
> > + int i;
> > +
> > + if (obj->nr_maps + 1 <= obj->maps_cap)
> nit: how about if (obj->nr_maps < obj->maps_cap)
yep, will do
>
> > + return &obj->maps[obj->nr_maps++];
> > +
> > + new_cap = max(4ul, obj->maps_cap * 3 / 2);
> > + new_maps = realloc(obj->maps, new_cap * sizeof(*obj->maps));
> > + if (!new_maps) {
> > + pr_warning("alloc maps for object failed\n");
> > + return ERR_PTR(-ENOMEM);
> > + }
> > +
> > + obj->maps_cap = new_cap;
> > + obj->maps = new_maps;
> > +
> > + /* zero out new maps */
> > + memset(obj->maps + obj->nr_maps, 0,
> > + (obj->maps_cap - obj->nr_maps) * sizeof(*obj->maps));
> > + /*
> > + * fill all fd with -1 so won't close incorrect fd (fd=0 is stdin)
> > + * when failure (zclose won't close negative fd)).
> > + */
> > + for (i = obj->nr_maps; i < obj->maps_cap; i++) {
> > + obj->maps[i].fd = -1;
> > + obj->maps[i].inner_map_fd = -1;
> > + }
> > +
> > + return &obj->maps[obj->nr_maps++];
> > }
> >
> > static int
> > @@ -808,29 +835,68 @@ bpf_object__init_internal_map(struct bpf_object *obj, struct bpf_map *map,
> > return 0;
> > }
> >
> > -static int bpf_object__init_maps(struct bpf_object *obj, int flags)
> > +static int bpf_object__init_global_data_maps(struct bpf_object *obj)
> > +{
> > + struct bpf_map *map;
> > + int err;
> > +
> > + if (!obj->caps.global_data)
> > + return 0;
> > + /*
> > + * Populate obj->maps with libbpf internal maps.
> > + */
> > + if (obj->efile.data_shndx >= 0) {
> > + map = bpf_object__add_map(obj);
> > + if (IS_ERR(map))
> > + return PTR_ERR(map);
> > + err = bpf_object__init_internal_map(obj, map, LIBBPF_MAP_DATA,
> > + obj->efile.data,
> > + &obj->sections.data);
> > + if (err)
> > + return err;
> > + }
> > + if (obj->efile.rodata_shndx >= 0) {
> > + map = bpf_object__add_map(obj);
> > + if (IS_ERR(map))
> > + return PTR_ERR(map);
> > + err = bpf_object__init_internal_map(obj, map, LIBBPF_MAP_RODATA,
> > + obj->efile.rodata,
> > + &obj->sections.rodata);
> > + if (err)
> > + return err;
> > + }
> > + if (obj->efile.bss_shndx >= 0) {
> > + map = bpf_object__add_map(obj);
> > + if (IS_ERR(map))
> > + return PTR_ERR(map);
> > + err = bpf_object__init_internal_map(obj, map, LIBBPF_MAP_BSS,
> > + obj->efile.bss, NULL);
> > + if (err)
> > + return err;
> > + }
>
> These 3 if clause are a little too complicated. How about we call
> bpf_obj_add_map(obj) within bpf_object__init_internal_map()?
Yeah, totally, not sure why I did it this way :)
>
> > + return 0;
> > +}
> > +
> > +static int bpf_object__init_user_maps(struct bpf_object *obj, bool strict)
> > {
<snip>
^ permalink raw reply
* [PATCH bpf-next v6 9/9] bpftool: support cgroup sockopt
From: Stanislav Fomichev @ 2019-06-17 18:01 UTC (permalink / raw)
To: netdev, bpf
Cc: davem, ast, daniel, Stanislav Fomichev, Martin Lau,
Jakub Kicinski
In-Reply-To: <20190617180109.34950-1-sdf@google.com>
Support sockopt prog type and cgroup hooks in the bpftool.
Cc: Martin Lau <kafai@fb.com>
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Stanislav Fomichev <sdf@google.com>
---
tools/bpf/bpftool/Documentation/bpftool-cgroup.rst | 7 +++++--
tools/bpf/bpftool/Documentation/bpftool-prog.rst | 2 +-
tools/bpf/bpftool/bash-completion/bpftool | 8 +++++---
tools/bpf/bpftool/cgroup.c | 5 ++++-
tools/bpf/bpftool/main.h | 1 +
tools/bpf/bpftool/prog.c | 3 ++-
6 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst b/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
index 36807735e2a5..cac088a320a6 100644
--- a/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
+++ b/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
@@ -29,7 +29,8 @@ CGROUP COMMANDS
| *PROG* := { **id** *PROG_ID* | **pinned** *FILE* | **tag** *PROG_TAG* }
| *ATTACH_TYPE* := { **ingress** | **egress** | **sock_create** | **sock_ops** | **device** |
| **bind4** | **bind6** | **post_bind4** | **post_bind6** | **connect4** | **connect6** |
-| **sendmsg4** | **sendmsg6** | **sysctl** }
+| **sendmsg4** | **sendmsg6** | **sysctl** | **getsockopt** |
+| **setsockopt** }
| *ATTACH_FLAGS* := { **multi** | **override** }
DESCRIPTION
@@ -86,7 +87,9 @@ DESCRIPTION
unconnected udp4 socket (since 4.18);
**sendmsg6** call to sendto(2), sendmsg(2), sendmmsg(2) for an
unconnected udp6 socket (since 4.18);
- **sysctl** sysctl access (since 5.2).
+ **sysctl** sysctl access (since 5.2);
+ **getsockopt** call to getsockopt (since 5.3);
+ **setsockopt** call to setsockopt (since 5.3).
**bpftool cgroup detach** *CGROUP* *ATTACH_TYPE* *PROG*
Detach *PROG* from the cgroup *CGROUP* and attach type
diff --git a/tools/bpf/bpftool/Documentation/bpftool-prog.rst b/tools/bpf/bpftool/Documentation/bpftool-prog.rst
index 228a5c863cc7..c6bade35032c 100644
--- a/tools/bpf/bpftool/Documentation/bpftool-prog.rst
+++ b/tools/bpf/bpftool/Documentation/bpftool-prog.rst
@@ -40,7 +40,7 @@ PROG COMMANDS
| **lwt_seg6local** | **sockops** | **sk_skb** | **sk_msg** | **lirc_mode2** |
| **cgroup/bind4** | **cgroup/bind6** | **cgroup/post_bind4** | **cgroup/post_bind6** |
| **cgroup/connect4** | **cgroup/connect6** | **cgroup/sendmsg4** | **cgroup/sendmsg6** |
-| **cgroup/sysctl**
+| **cgroup/sysctl** | **cgroup/getsockopt** | **cgroup/setsockopt**
| }
| *ATTACH_TYPE* := {
| **msg_verdict** | **stream_verdict** | **stream_parser** | **flow_dissector**
diff --git a/tools/bpf/bpftool/bash-completion/bpftool b/tools/bpf/bpftool/bash-completion/bpftool
index 2725e27dfa42..7afb8b6fbaaa 100644
--- a/tools/bpf/bpftool/bash-completion/bpftool
+++ b/tools/bpf/bpftool/bash-completion/bpftool
@@ -378,7 +378,8 @@ _bpftool()
cgroup/connect4 cgroup/connect6 \
cgroup/sendmsg4 cgroup/sendmsg6 \
cgroup/post_bind4 cgroup/post_bind6 \
- cgroup/sysctl" -- \
+ cgroup/sysctl cgroup/getsockopt \
+ cgroup/setsockopt" -- \
"$cur" ) )
return 0
;;
@@ -688,7 +689,8 @@ _bpftool()
attach|detach)
local ATTACH_TYPES='ingress egress sock_create sock_ops \
device bind4 bind6 post_bind4 post_bind6 connect4 \
- connect6 sendmsg4 sendmsg6 sysctl'
+ connect6 sendmsg4 sendmsg6 sysctl getsockopt \
+ setsockopt'
local ATTACH_FLAGS='multi override'
local PROG_TYPE='id pinned tag'
case $prev in
@@ -698,7 +700,7 @@ _bpftool()
;;
ingress|egress|sock_create|sock_ops|device|bind4|bind6|\
post_bind4|post_bind6|connect4|connect6|sendmsg4|\
- sendmsg6|sysctl)
+ sendmsg6|sysctl|getsockopt|setsockopt)
COMPREPLY=( $( compgen -W "$PROG_TYPE" -- \
"$cur" ) )
return 0
diff --git a/tools/bpf/bpftool/cgroup.c b/tools/bpf/bpftool/cgroup.c
index 7e22f115c8c1..3083f2e4886e 100644
--- a/tools/bpf/bpftool/cgroup.c
+++ b/tools/bpf/bpftool/cgroup.c
@@ -25,7 +25,8 @@
" ATTACH_TYPE := { ingress | egress | sock_create |\n" \
" sock_ops | device | bind4 | bind6 |\n" \
" post_bind4 | post_bind6 | connect4 |\n" \
- " connect6 | sendmsg4 | sendmsg6 | sysctl }"
+ " connect6 | sendmsg4 | sendmsg6 | sysctl |\n" \
+ " getsockopt | setsockopt }"
static const char * const attach_type_strings[] = {
[BPF_CGROUP_INET_INGRESS] = "ingress",
@@ -42,6 +43,8 @@ static const char * const attach_type_strings[] = {
[BPF_CGROUP_UDP4_SENDMSG] = "sendmsg4",
[BPF_CGROUP_UDP6_SENDMSG] = "sendmsg6",
[BPF_CGROUP_SYSCTL] = "sysctl",
+ [BPF_CGROUP_GETSOCKOPT] = "getsockopt",
+ [BPF_CGROUP_SETSOCKOPT] = "setsockopt",
[__MAX_BPF_ATTACH_TYPE] = NULL,
};
diff --git a/tools/bpf/bpftool/main.h b/tools/bpf/bpftool/main.h
index 28a2a5857e14..9c5d9c80f71e 100644
--- a/tools/bpf/bpftool/main.h
+++ b/tools/bpf/bpftool/main.h
@@ -74,6 +74,7 @@ static const char * const prog_type_name[] = {
[BPF_PROG_TYPE_SK_REUSEPORT] = "sk_reuseport",
[BPF_PROG_TYPE_FLOW_DISSECTOR] = "flow_dissector",
[BPF_PROG_TYPE_CGROUP_SYSCTL] = "cgroup_sysctl",
+ [BPF_PROG_TYPE_CGROUP_SOCKOPT] = "cgroup_sockopt",
};
extern const char * const map_type_name[];
diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c
index 1f209c80d906..a201e1c83346 100644
--- a/tools/bpf/bpftool/prog.c
+++ b/tools/bpf/bpftool/prog.c
@@ -1070,7 +1070,8 @@ static int do_help(int argc, char **argv)
" sk_reuseport | flow_dissector | cgroup/sysctl |\n"
" cgroup/bind4 | cgroup/bind6 | cgroup/post_bind4 |\n"
" cgroup/post_bind6 | cgroup/connect4 | cgroup/connect6 |\n"
- " cgroup/sendmsg4 | cgroup/sendmsg6 }\n"
+ " cgroup/sendmsg4 | cgroup/sendmsg6 | cgroup/getsockopt |\n"
+ " cgroup/setsockopt }\n"
" ATTACH_TYPE := { msg_verdict | stream_verdict | stream_parser |\n"
" flow_dissector }\n"
" " HELP_SPEC_OPTIONS "\n"
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH bpf-next v6 8/9] bpf: add sockopt documentation
From: Stanislav Fomichev @ 2019-06-17 18:01 UTC (permalink / raw)
To: netdev, bpf; +Cc: davem, ast, daniel, Stanislav Fomichev, Martin Lau
In-Reply-To: <20190617180109.34950-1-sdf@google.com>
Provide user documentation about sockopt prog type and cgroup hooks.
v6:
* describe cgroup chaining, add example
v2:
* use return code 2 for kernel bypass
Cc: Martin Lau <kafai@fb.com>
Signed-off-by: Stanislav Fomichev <sdf@google.com>
---
Documentation/bpf/index.rst | 1 +
Documentation/bpf/prog_cgroup_sockopt.rst | 72 +++++++++++++++++++++++
2 files changed, 73 insertions(+)
create mode 100644 Documentation/bpf/prog_cgroup_sockopt.rst
diff --git a/Documentation/bpf/index.rst b/Documentation/bpf/index.rst
index d3fe4cac0c90..801a6ed3f2e5 100644
--- a/Documentation/bpf/index.rst
+++ b/Documentation/bpf/index.rst
@@ -42,6 +42,7 @@ Program types
.. toctree::
:maxdepth: 1
+ prog_cgroup_sockopt
prog_cgroup_sysctl
prog_flow_dissector
diff --git a/Documentation/bpf/prog_cgroup_sockopt.rst b/Documentation/bpf/prog_cgroup_sockopt.rst
new file mode 100644
index 000000000000..8b9d55a3e655
--- /dev/null
+++ b/Documentation/bpf/prog_cgroup_sockopt.rst
@@ -0,0 +1,72 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+============================
+BPF_PROG_TYPE_CGROUP_SOCKOPT
+============================
+
+``BPF_PROG_TYPE_CGROUP_SOCKOPT`` program type can be attached to two
+cgroup hooks:
+
+* ``BPF_CGROUP_GETSOCKOPT`` - called every time process executes ``getsockopt``
+ system call.
+* ``BPF_CGROUP_SETSOCKOPT`` - called every time process executes ``setsockopt``
+ system call.
+
+The context (``struct bpf_sockopt``) has associated socket (``sk``) and
+all input arguments: ``level``, ``optname``, ``optval`` and ``optlen``.
+
+BPF_CGROUP_SETSOCKOPT
+=====================
+
+``BPF_CGROUP_SETSOCKOPT`` has a read-only context and this hook has
+access to cgroup and socket local storage.
+
+BPF_CGROUP_GETSOCKOPT
+=====================
+
+``BPF_CGROUP_GETSOCKOPT`` has to fill in ``optval`` and adjust
+``optlen`` accordingly. Input ``optlen`` contains the maximum length
+of data that can be returned to the userspace. In other words, BPF
+program can't increase ``optlen``, it can only decrease it.
+
+Return Type
+===========
+
+* ``0`` - reject the syscall, ``EPERM`` will be returned to the userspace.
+* ``1`` - success: after returning from the BPF hook, kernel will also
+ handle this socket option.
+* ``2`` - success: after returning from the BPF hook, kernel will _not_
+ handle this socket option; control will be returned to the userspace
+ instead.
+
+Cgroup Inheritance
+==================
+
+Suppose, there is the following cgroup hierarchy where each cgroup
+has BPF_CGROUP_GETSOCKOPT attached at each level with
+BPF_F_ALLOW_MULTI flag::
+
+ A (root)
+ \
+ B
+ \
+ C
+
+When the application calls getsockopt syscall from the cgroup C,
+the programs are executed from the bottom up: C, B, A. As long as
+BPF programs in the chain return 1, the execution continues. If
+some program in the C, B, A chain returns 2 (bypass kernel) or
+0 (EPERM), the control is immediately passed passed back to the
+userspace. This is in contrast with any existing per-cgroup BPF
+hook where all programs are called, even if some of them return
+0 (EPERM).
+
+In the example above, if C returns 1 (continue) and then B returns
+0 (EPERM) or 2 (bypass kernel), the program attached to A will _not_
+be executed.
+
+Example
+=======
+
+See ``tools/testing/selftests/bpf/progs/sockopt_sk.c`` for an example
+of BPF program that handles socket options.
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
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