* [RFC -next v0 1/3] bpf: modular maps
From: Aaron Conole @ 2018-11-25 18:09 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, netfilter-devel, coreteam, Alexei Starovoitov,
Daniel Borkmann, Pablo Neira Ayuso, Jozsef Kadlecsik,
Florian Westphal, John Fastabend, Jesper Brouer, David S . Miller,
Andy Gospodarek, Rony Efraim, Simon Horman, Marcelo Leitner
In-Reply-To: <20181125180919.13996-1-aconole@bytheb.org>
This commit allows for map operations to be loaded by an lkm, rather than
needing to be baked into the kernel at compile time.
Signed-off-by: Aaron Conole <aconole@bytheb.org>
---
include/linux/bpf.h | 6 +++++
init/Kconfig | 8 +++++++
kernel/bpf/syscall.c | 57 +++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 70 insertions(+), 1 deletion(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 33014ae73103..bf4531f076ca 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -553,6 +553,7 @@ static inline int bpf_map_attr_numa_node(const union bpf_attr *attr)
struct bpf_prog *bpf_prog_get_type_path(const char *name, enum bpf_prog_type type);
int array_map_alloc_check(union bpf_attr *attr);
+void bpf_map_insert_ops(size_t id, const struct bpf_map_ops *ops);
#else /* !CONFIG_BPF_SYSCALL */
static inline struct bpf_prog *bpf_prog_get(u32 ufd)
@@ -665,6 +666,11 @@ static inline struct bpf_prog *bpf_prog_get_type_path(const char *name,
{
return ERR_PTR(-EOPNOTSUPP);
}
+
+static inline void bpf_map_insert_ops(size_t id,
+ const struct bpf_map_ops *ops)
+{
+}
#endif /* CONFIG_BPF_SYSCALL */
static inline struct bpf_prog *bpf_prog_get_type(u32 ufd,
diff --git a/init/Kconfig b/init/Kconfig
index a4112e95724a..aa4eb98af656 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1489,6 +1489,14 @@ config BPF_JIT_ALWAYS_ON
Enables BPF JIT and removes BPF interpreter to avoid
speculative execution of BPF instructions by the interpreter
+config BPF_LOADABLE_MAPS
+ bool "Allow map types to be loaded with modules"
+ depends on BPF_SYSCALL && MODULES
+ help
+ Enables BPF map types to be provided by loadable modules
+ instead of always compiled in. Maps provided dynamically
+ may only be used by super users.
+
config USERFAULTFD
bool "Enable userfaultfd() system call"
select ANON_INODES
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index cf5040fd5434..fa1db9ab81e1 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -49,6 +49,8 @@ static DEFINE_SPINLOCK(map_idr_lock);
int sysctl_unprivileged_bpf_disabled __read_mostly;
+const struct bpf_map_ops loadable_map = {};
+
static const struct bpf_map_ops * const bpf_map_types[] = {
#define BPF_PROG_TYPE(_id, _ops)
#define BPF_MAP_TYPE(_id, _ops) \
@@ -58,6 +60,15 @@ static const struct bpf_map_ops * const bpf_map_types[] = {
#undef BPF_MAP_TYPE
};
+static const struct bpf_map_ops * bpf_loadable_map_types[] = {
+#define BPF_PROG_TYPE(_id, _ops)
+#define BPF_MAP_TYPE(_id, _ops) \
+ [_id] = NULL,
+#include <linux/bpf_types.h>
+#undef BPF_PROG_TYPE
+#undef BPF_MAP_TYPE
+};
+
/*
* If we're handed a bigger struct than we know of, ensure all the unknown bits
* are 0 - i.e. new user-space does not rely on any kernel feature extensions
@@ -105,6 +116,48 @@ const struct bpf_map_ops bpf_map_offload_ops = {
.map_check_btf = map_check_no_btf,
};
+/*
+ * Fills in the modular ops map, provided that the entry is not already
+ * filled, and that the caller has CAP_SYS_ADMIN. */
+void bpf_map_insert_ops(size_t id, const struct bpf_map_ops *ops)
+{
+#ifdef CONFIG_BPF_LOADABLE_MAPS
+ if (!capable(CAP_SYS_ADMIN))
+ return;
+
+ if (id >= ARRAY_SIZE(bpf_loadable_map_types))
+ return;
+
+ id = array_index_nospec(id, ARRAY_SIZE(bpf_loadable_map_types));
+ if (bpf_loadable_map_types[id] == NULL)
+ bpf_loadable_map_types[id] = ops;
+#endif
+}
+EXPORT_SYMBOL_GPL(bpf_map_insert_ops);
+
+static const struct bpf_map_ops *find_loadable_ops(u32 type)
+{
+ struct user_struct *user = get_current_user();
+ const struct bpf_map_ops *ops = NULL;
+
+ if (user->uid.val)
+ goto done;
+
+#ifdef CONFIG_BPF_LOADABLE_MAPS
+ if (!capable(CAP_SYS_ADMIN))
+ goto done;
+
+ if (type >= ARRAY_SIZE(bpf_loadable_map_types))
+ goto done;
+ type = array_index_nospec(type, ARRAY_SIZE(bpf_loadable_map_types));
+ ops = bpf_loadable_map_types[type];
+#endif
+
+done:
+ free_uid(user);
+ return ops;
+}
+
static struct bpf_map *find_and_alloc_map(union bpf_attr *attr)
{
const struct bpf_map_ops *ops;
@@ -115,7 +168,8 @@ static struct bpf_map *find_and_alloc_map(union bpf_attr *attr)
if (type >= ARRAY_SIZE(bpf_map_types))
return ERR_PTR(-EINVAL);
type = array_index_nospec(type, ARRAY_SIZE(bpf_map_types));
- ops = bpf_map_types[type];
+ ops = (bpf_map_types[type] != &loadable_map) ? bpf_map_types[type] :
+ find_loadable_ops(type);
if (!ops)
return ERR_PTR(-EINVAL);
@@ -180,6 +234,7 @@ int bpf_map_precharge_memlock(u32 pages)
return -EPERM;
return 0;
}
+EXPORT_SYMBOL_GPL(bpf_map_precharge_memlock);
static int bpf_charge_memlock(struct user_struct *user, u32 pages)
{
--
2.19.1
^ permalink raw reply related
* [PATCH][V2] net: bridge: remove redundant checks for null p->dev and p->br
From: Colin King @ 2018-11-25 16:08 UTC (permalink / raw)
To: Roopa Prabhu, Nikolay Aleksandrov, David S . Miller, bridge,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
A recent change added a null check on p->dev after p->dev was being
dereferenced by the ns_capable check on p->dev. It turns out that
neither the p->dev and p->br null checks are necessary, and can be
removed, which cleans up a static analyis warning.
As Nikolay Aleksandrov noted, these checks can be removed because:
"My reasoning of why it shouldn't be possible:
- On port add new_nbp() sets both p->dev and p->br before creating
kobj/sysfs
- On port del (trickier) del_nbp() calls kobject_del() before call_rcu()
to destroy the port which in turn calls sysfs_remove_dir() which uses
kernfs_remove() which deactivates (shouldn't be able to open new
files) and calls kernfs_drain() to drain current open/mmaped files in
the respective dir before continuing, thus making it impossible to
open a bridge port sysfs file with p->dev and p->br equal to NULL.
So I think it's safe to remove those checks altogether. It'd be nice to
get a second look over my reasoning as I might be missing something in
sysfs/kernfs call path."
Thanks to Nikolay Aleksandrov's suggestion to remove the check and
David Miller for sanity checking this.
Detected by CoverityScan, CID#751490 ("Dereference before null check")
Fixes: a5f3ea54f3cc ("net: bridge: add support for raw sysfs port options")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
V2: remove checks instead of moving them before the dereference of
p->dev.
---
net/bridge/br_sysfs_if.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/bridge/br_sysfs_if.c b/net/bridge/br_sysfs_if.c
index 7c87a2fe5248..88715edb119a 100644
--- a/net/bridge/br_sysfs_if.c
+++ b/net/bridge/br_sysfs_if.c
@@ -320,9 +320,6 @@ static ssize_t brport_store(struct kobject *kobj,
if (!rtnl_trylock())
return restart_syscall();
- if (!p->dev || !p->br)
- goto out_unlock;
-
if (brport_attr->store_raw) {
char *buf_copy;
--
2.19.1
^ permalink raw reply related
* Re: [PATCH 3/8] socket: Disentangle SOCK_RCVTSTAMPNS from SOCK_RCVTSTAMP
From: Deepa Dinamani @ 2018-11-25 5:06 UTC (permalink / raw)
To: willemdebruijn.kernel
Cc: David S. Miller, Linux Kernel Mailing List,
Linux Network Devel Mailing List, Alexander Viro, Arnd Bergmann,
y2038 Mailman List
In-Reply-To: <CAF=yD-JGh23sA_6eUtBq8=wSZ5g=nipmhdr1WwjP5th51qEtiQ@mail.gmail.com>
On Sat, Nov 24, 2018 at 7:59 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> On Sat, Nov 24, 2018 at 3:59 AM Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> >
> > SOCK_RCVTSTAMPNS is never set alone. SOCK_RCVTSTAMP
> > is always set along with SOCK_RCVTSTAMPNS. This leads to
> > checking for two flag states whenever we need to check for
> > SOCK_RCVTSTAMPS.
> >
> > Also SOCK_RCVTSTAMPS was the only flag that needed to be
> > checked in order to verify if either of the two flags are
> > set. But, the two features are not actually dependent on
> > each other. This artificial dependency creates more
> > confusion.
>
> This is done so that the hot path only has to check one flag
> in the common case where no timestamp is requested.
In that case we could just check it this way:
if (newsk->sk_flags & SK_FLAGS_TIMESTAMP)
We are already doing this in many places.
I do not see any other reason for the two timestamps to be intertwined.
Do you have any objections to using this patch and replacing the
checks as above?
-Deepa
^ permalink raw reply
* RE: [PATCH net-next v2 0/4] qed* enhancements series
From: Kalluru, Sudarsana @ 2018-11-25 4:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, Elior, Ariel, Kalderon, Michal
In-Reply-To: <20181124.173224.535712742739403734.davem@davemloft.net>
-----Original Message-----
From: David Miller [mailto:davem@davemloft.net]
Sent: 25 November 2018 07:02
To: Kalluru, Sudarsana <Sudarsana.Kalluru@cavium.com>
Cc: netdev@vger.kernel.org; Elior, Ariel <Ariel.Elior@cavium.com>; Kalderon, Michal <Michal.Kalderon@cavium.com>
Subject: Re: [PATCH net-next v2 0/4] qed* enhancements series
External Email
From: Sudarsana Reddy Kalluru <sudarsana.kalluru@cavium.com>
Date: Fri, 23 Nov 2018 23:42:29 -0800
> v2: Use __set_bit()/__clear_bit() where data access doesn't need to be
> atomic.
Wait.
How does this interact with the clear_bit_unlock() used by the qede PTP code?
You can't really mix atomic and non-atomic accesses to edev->flags .
Hi Dave,
I missed this point, thanks a lot for your help/info. Will revert it to use set/clear_bit() respectively and, send the V3 version of the series.
Thanks,
Sudarsana
^ permalink raw reply
* Re: [PATCH 2/8] sockopt: Rename SO_TIMESTAMP* to SO_TIMESTAMP*_OLD
From: Willem de Bruijn @ 2018-11-25 3:58 UTC (permalink / raw)
To: Deepa Dinamani
Cc: David Miller, LKML, Network Development, Al Viro, Arnd Bergmann,
y2038 Mailman List, Helge Deller, David Howells, jejb, ralf, rth,
linux-afs, linux-alpha, linux-arch, linux-mips, linux-parisc,
linux-rdma, sparclinux
In-Reply-To: <20181124022035.17519-3-deepa.kernel@gmail.com>
On Sat, Nov 24, 2018 at 3:58 AM Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>
> SO_TIMESTAMP, SO_TIMESTAMPNS and SO_TIMESTAMPING options, the
> way they are currently defined, are not y2038 safe.
> Subsequent patches in the series add new y2038 safe versions
> of these options which provide 64 bit timestamps on all
> architectures uniformly.
> Hence, rename existing options with OLD tag suffixes.
Why do the existing interfaces have to be renamed when new interfaces are added?
^ permalink raw reply
* Re: [PATCH 7/8] socket: Add SO_TIMESTAMP[NS]_NEW
From: Willem de Bruijn @ 2018-11-25 14:38 UTC (permalink / raw)
To: Deepa Dinamani
Cc: David Miller, LKML, Network Development, Al Viro, Arnd Bergmann,
y2038 Mailman List, jejb, ralf, rth, linux-alpha, linux-mips,
linux-parisc, linux-rdma, sparclinux
In-Reply-To: <CABeXuvr6fi9UPwMvuafx7MwEta-Sx1TLNN0KQ8HQHhn=vAne5Q@mail.gmail.com>
> > > > Same for the tcp case above, really, and in the case of the next patch
> > > > for SO_TIMESTAMPING_NEW
> > >
> > > That naming convention, ..._2038, is not the nicest, of course. That
> > > is not the relevant bit in the above comment.
>
> it could be __sock_recv_timestamp64().
> But, these timestamps should be doing exactly the same thing as the
> old ones and I thought it would be nicer to keep the same code path.
> I can change it to as per above.
Please minimize code changes. It breaks git blame and longer patches
are harder to review.
In this specific case, from a readability point of view, I find new functions
that map one-to-one onto the new interfaces also more readable than
deeper nested branches in place.
> > So we introduce new y2038 safe timestamp options for 32 bit ABIs. We
> > assume that 32 bit applications will switch to new ABIs at some point,
> > but leave the older timestamps as is.
> > I can update the commit text as per above.
>
> We have been avoiding adding timeval64 timestamps to discourage users
> from using these types in the interfaces.
> We want to keep all the uapi time interfaces to use __kernel_*
> interfaces. And, we already provide __kernel_timespec interface for
> such instances.
> But, in this case we do not have an option. So we introduce a type
> specific to sockets.
This structure just holds a timestamp. It does not seem socket specific.
I don't mean to bikeshed the naming point too much, but timeval_ll or
so may be more representative than tying it to a socket.
As for the general naming, xxx64 or xxx2038 are more descriptive than xxx_NEW.
^ permalink raw reply
* Re: [PATCH 7/8] socket: Add SO_TIMESTAMP[NS]_NEW
From: Willem de Bruijn @ 2018-11-25 14:33 UTC (permalink / raw)
To: Deepa Dinamani
Cc: linux-mips, linux-parisc, Arnd Bergmann, y2038 Mailman List,
Network Development, LKML, ralf, jejb, linux-rdma, Al Viro,
linux-alpha, sparclinux, David Miller, rth
In-Reply-To: <CABeXuvoDPvT45CCt2L0TReqtb1Q_-E8+toYu6qjiP0cxfdQNdA@mail.gmail.com>
On Sun, Nov 25, 2018 at 12:28 AM Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>
> > > > + if (type == SO_TIMESTAMP_NEW || type == SO_TIMESTAMPNS_NEW)
> > > > + sock_set_flag(sk, SOCK_TSTAMP_NEW);
> > > > + else
> > > > + sock_reset_flag(sk, SOCK_TSTAMP_NEW);
> > > > +
> > >
> > > if adding a boolean whether the socket uses new or old-style
> > > timestamps, perhaps fail hard if a process tries to set a new-style
> > > option while an old-style is already set and vice versa. Also include
> > > SO_TIMESTAMPING_NEW as it toggles the same option.
>
> I do not think this is a problem.
> Consider this example, if there is a user application with updated
> socket timestamps is linking into a library that is yet to be updated.
Also consider applications that do not use libraries.
> Besides, the old timestamps should work perfectly fine on 64 bit
> arches even beyond 2038.
In that case, can we structure the code to not add branching on 64-bit
platforms.
For instance, structure
if (sock_flag(sk, SOCK_TSTAMP_NEW))
__sock_recv_timestamp_2038(msg, sk, skb);
instead as a boolean function that
if (__sock_recv_timestamp_2038(msg, sk, skb))
and have that function's contents wrapped in an ifdef that removes
it on 64-bit platforms and simply returns false?
Or more rigorously restrict these extensions to a 32-bit compat layer.
> So failing here means adding a bunch of ifdef's to verify it is not
> executing on 64 bit arch or something like x32.
The code as is adds branches on platforms that do not need it. Ifdefs
are ugly, but if they can be contained to the few helper functions needed
for the _2038 variants of cmsg_put, that is acceptable in my opinion.
> > > > /*
> > > > * called from sock_recv_timestamp() if sock_flag(sk, SOCK_RCVTSTAMP)
> > > > * or sock_flag(sk, SOCK_RCVTSTAMPNS)
> > > > @@ -719,19 +751,8 @@ void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk,
> > > > false_tstamp = 1;
> > > > }
> > > > - if (need_software_tstamp) {
> > >
> > > Considerably less code churn if adding __sock_recv_timestamp_2038 and
> > > calling that here:
> > >
> > > if (sock_flag(sk, SOCK_TSTAMP_NEW))
> > > __sock_recv_timestamp_2038(msg, sk, skb);
> > > else if ...
> > >
> > > Same for the tcp case above, really, and in the case of the next patch
> > > for SO_TIMESTAMPING_NEW
> >
> > That naming convention, ..._2038, is not the nicest, of course. That
> > is not the relevant bit in the above comment.
> >
> > Come to think of it, and related to my question in patch 2 why the
> > need to rename at all, could all new structs, constants and functions
> > be named consistently with 64 suffix? __sock_recv_timestamp64,
> > SO_TIMESTAMPING64 and timeval64 (instead of sock_timeval,
> > it isn't really a sock specific struct)?
> >
> > I guess that there is a good reason for the renaming exercise and
> > conditional mapping of SO_TIMESTAMP onto old or new interface.
> > Please elucidate in the commit message.
>
> I think there is some confusion here.
Yes, I know this socket timestamping code, but am less familiar with the
wider discusson on 2038 timestamp conversion. It would be helpful if this
patchset can be self-describing without that context or point to the
discussion (unfortunately, I had miss Arnd's talk at LPC).
> The existing timestamp options: SO_TIMESTAMP* fail to provide proper
> timestamps beyond year 2038 on 32 bit ABIs.
> But, these work fine on 64 bit native ABIs.
> So now we need a way of updating these timestamps so that we do not
> break existing userspace: 64 bit ABIs should not have to change
> userspace, 32 bit ABIs should work as is until 2038 after which they
> have bad timestamps.
> So we introduce new y2038 safe timestamp options for 32 bit ABIs. We
> assume that 32 bit applications will switch to new ABIs at some point,
> but leave the older timestamps as is.
> I can update the commit text as per above.
So on 32-bit platforms SO_TIMESTAMP_NEW introduces a new struct
sock_timeval with both 64-bit fields.
Does this not break existing applications that compile against SO_TIMESTAMP
and expect struct timeval? For one example, the selftests under tools/testing.
The kernel will now convert SO_TIMESTAMP (previously constant 29) to
different SO_TIMESTAMP_NEW (62) and returns a different struct. Perhaps
with a library like libc in the middle this can be fixed up
transparently, but for
applications that don't have a more recent libc or use a library at
all, it breaks
the ABI.
I suspect that these finer ABI points may have been discussed outside the
narrow confines of socket timestamping. But on its own, this does worry me.
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* Re: [PATCH 3/8] socket: Disentangle SOCK_RCVTSTAMPNS from SOCK_RCVTSTAMP
From: Willem de Bruijn @ 2018-11-25 14:18 UTC (permalink / raw)
To: Deepa Dinamani
Cc: David Miller, LKML, Network Development, Al Viro, Arnd Bergmann,
y2038 Mailman List
In-Reply-To: <CABeXuvqgPE_Cft+T0fSw8zT09uCKWQGUB+bVNqQDk6fOinn8rA@mail.gmail.com>
On Sun, Nov 25, 2018 at 12:06 AM Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>
> On Sat, Nov 24, 2018 at 7:59 PM Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
> >
> > On Sat, Nov 24, 2018 at 3:59 AM Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> > >
> > > SOCK_RCVTSTAMPNS is never set alone. SOCK_RCVTSTAMP
> > > is always set along with SOCK_RCVTSTAMPNS. This leads to
> > > checking for two flag states whenever we need to check for
> > > SOCK_RCVTSTAMPS.
> > >
> > > Also SOCK_RCVTSTAMPS was the only flag that needed to be
> > > checked in order to verify if either of the two flags are
> > > set. But, the two features are not actually dependent on
> > > each other. This artificial dependency creates more
> > > confusion.
> >
> > This is done so that the hot path only has to check one flag
> > in the common case where no timestamp is requested.
>
> In that case we could just check it this way:
>
> if (newsk->sk_flags & SK_FLAGS_TIMESTAMP)
>
> We are already doing this in many places.
>
> I do not see any other reason for the two timestamps to be intertwined.
>
> Do you have any objections to using this patch and replacing the
> checks as above?
The existing logic is as is for a reason. There is no need to change
it to satisfy the main purpose of your patchset?
It is structured as one bit to test whether a timestamp is requested
and another to select among two variants usec/nsec. Just add another
layer of branching between new/old in cases where this distinction is
needed.
Please avoid code churn unless needed.
^ permalink raw reply
* KASAN: slab-out-of-bounds Write in queue_stack_map_push_elem
From: syzbot @ 2018-11-25 13:50 UTC (permalink / raw)
To: ast, daniel, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: e195ca6cb6f2 Merge branch 'for-linus' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12af0d33400000
kernel config: https://syzkaller.appspot.com/x/.config?x=73e2bc0cb6463446
dashboard link: https://syzkaller.appspot.com/bug?extid=36cf9e58446a643bfa14
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12baac5d400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1471df7b400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+36cf9e58446a643bfa14@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:352 [inline]
BUG: KASAN: slab-out-of-bounds in queue_stack_map_push_elem+0x185/0x290
kernel/bpf/queue_stack_maps.c:230
Write of size 262146 at addr ffff8881cce14448 by task syz-executor005/6050
CPU: 1 PID: 6050 Comm: syz-executor005 Not tainted 4.20.0-rc3+ #348
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x244/0x39d lib/dump_stack.c:113
print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
memcpy+0x37/0x50 mm/kasan/kasan.c:303
memcpy include/linux/string.h:352 [inline]
queue_stack_map_push_elem+0x185/0x290 kernel/bpf/queue_stack_maps.c:230
map_update_elem+0x605/0xf60 kernel/bpf/syscall.c:865
__do_sys_bpf kernel/bpf/syscall.c:2495 [inline]
__se_sys_bpf kernel/bpf/syscall.c:2466 [inline]
__x64_sys_bpf+0x32d/0x520 kernel/bpf/syscall.c:2466
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4400e9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffc7a0f28d8 EFLAGS: 00000213 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004400e9
RDX: 0000000000000020 RSI: 0000000020000040 RDI: 0000000000000002
RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
R10: 0000000000000000 R11: 0000000000000213 R12: 0000000000401970
R13: 0000000000401a00 R14: 0000000000000000 R15: 0000000000000000
Allocated by task 6050:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
__do_kmalloc_node mm/slab.c:3684 [inline]
__kmalloc_node+0x50/0x70 mm/slab.c:3691
kmalloc_node include/linux/slab.h:589 [inline]
bpf_map_area_alloc+0x3f/0x90 kernel/bpf/syscall.c:147
queue_stack_map_alloc+0x192/0x290 kernel/bpf/queue_stack_maps.c:84
find_and_alloc_map kernel/bpf/syscall.c:129 [inline]
map_create+0x3bd/0x1110 kernel/bpf/syscall.c:509
__do_sys_bpf kernel/bpf/syscall.c:2489 [inline]
__se_sys_bpf kernel/bpf/syscall.c:2466 [inline]
__x64_sys_bpf+0x303/0x520 kernel/bpf/syscall.c:2466
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 3716:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xcf/0x230 mm/slab.c:3817
skb_free_head+0x99/0xc0 net/core/skbuff.c:550
skb_release_data+0x70c/0x9a0 net/core/skbuff.c:570
skb_release_all+0x4a/0x60 net/core/skbuff.c:627
__kfree_skb net/core/skbuff.c:641 [inline]
consume_skb+0x1ae/0x570 net/core/skbuff.c:701
skb_free_datagram+0x1a/0xf0 net/core/datagram.c:329
unix_dgram_recvmsg+0xd6d/0x1b10 net/unix/af_unix.c:2181
sock_recvmsg_nosec net/socket.c:794 [inline]
sock_recvmsg+0xd0/0x110 net/socket.c:801
__sys_recvfrom+0x311/0x5d0 net/socket.c:1845
__do_sys_recvfrom net/socket.c:1863 [inline]
__se_sys_recvfrom net/socket.c:1859 [inline]
__x64_sys_recvfrom+0xe1/0x1a0 net/socket.c:1859
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8881cce14300
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 328 bytes inside of
512-byte region [ffff8881cce14300, ffff8881cce14500)
The buggy address belongs to the page:
page:ffffea0007338500 count:1 mapcount:0 mapping:ffff8881da800940
index:0xffff8881cce14580
flags: 0x2fffc0000000200(slab)
raw: 02fffc0000000200 ffffea0006e31bc8 ffffea00071b4608 ffff8881da800940
raw: ffff8881cce14580 ffff8881cce14080 0000000100000005 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8881cce14380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8881cce14400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff8881cce14480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff8881cce14500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8881cce14580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH net-next] selftests/net: add txring_overwrite
From: David Miller @ 2018-11-25 2:22 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: netdev, willemb
In-Reply-To: <20181125020926.79688-1-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Sat, 24 Nov 2018 21:09:26 -0500
> From: Willem de Bruijn <willemb@google.com>
>
> Packet sockets with PACKET_TX_RING send skbs with user data in frags.
>
> Before commit 5cd8d46ea156 ("packet: copy user buffers before orphan
> or clone") ring slots could be released prematurely, possibly allowing
> a process to overwrite data still in flight.
>
> This test opens two packet sockets, one to send and one to read.
> The sender has a tx ring of one slot. It sends two packets with
> different payload, then reads both and verifies their payload.
>
> Before the above commit, both receive calls return the same data as
> the send calls use the same buffer. From the commit, the clone
> needed for looping onto a packet socket triggers an skb_copy_ubufs
> to create a private copy. The separate sends each arrive correctly.
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Thanks for following up on this, applied.
^ permalink raw reply
* Re: [PATCH net-next 1/2] udp: msg_zerocopy
From: Willem de Bruijn @ 2018-11-25 2:13 UTC (permalink / raw)
To: David Miller; +Cc: Network Development, Willem de Bruijn
In-Reply-To: <20181124.175826.1565485862310427469.davem@davemloft.net>
On Sat, Nov 24, 2018 at 8:58 PM David Miller <davem@davemloft.net> wrote:
>
> From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> Date: Sat, 24 Nov 2018 14:24:30 -0500
>
> > diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
> > index c09219e7f230..2d1e4b67a1e8 100644
> > --- a/net/ipv4/ip_output.c
> > +++ b/net/ipv4/ip_output.c
> > @@ -868,6 +868,7 @@ static int __ip_append_data(struct sock *sk,
> > {
> > struct inet_sock *inet = inet_sk(sk);
> > struct sk_buff *skb;
> > + struct ubuf_info *uarg = NULL;
>
> Reverse christmas tree, please.
Oh right, sorry.
Will wait with v2 for a day or two, in case anyone else has comments.
Thanks for the quick review!
^ permalink raw reply
* [PATCH net-next] selftests/net: add txring_overwrite
From: Willem de Bruijn @ 2018-11-25 2:09 UTC (permalink / raw)
To: netdev; +Cc: davem, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
Packet sockets with PACKET_TX_RING send skbs with user data in frags.
Before commit 5cd8d46ea156 ("packet: copy user buffers before orphan
or clone") ring slots could be released prematurely, possibly allowing
a process to overwrite data still in flight.
This test opens two packet sockets, one to send and one to read.
The sender has a tx ring of one slot. It sends two packets with
different payload, then reads both and verifies their payload.
Before the above commit, both receive calls return the same data as
the send calls use the same buffer. From the commit, the clone
needed for looping onto a packet socket triggers an skb_copy_ubufs
to create a private copy. The separate sends each arrive correctly.
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
tools/testing/selftests/net/.gitignore | 1 +
tools/testing/selftests/net/Makefile | 2 +-
tools/testing/selftests/net/run_afpackettests | 10 +
.../testing/selftests/net/txring_overwrite.c | 180 ++++++++++++++++++
4 files changed, 192 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/net/txring_overwrite.c
diff --git a/tools/testing/selftests/net/.gitignore b/tools/testing/selftests/net/.gitignore
index 8cf22b3c2563..7f57b916e6b2 100644
--- a/tools/testing/selftests/net/.gitignore
+++ b/tools/testing/selftests/net/.gitignore
@@ -14,4 +14,5 @@ udpgso_bench_rx
udpgso_bench_tx
tcp_inq
tls
+txring_overwrite
ip_defrag
diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
index eec359895feb..7aebbcaa91bf 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -11,7 +11,7 @@ TEST_PROGS += udpgro_bench.sh udpgro.sh
TEST_PROGS_EXTENDED := in_netns.sh
TEST_GEN_FILES = socket
TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy
-TEST_GEN_FILES += tcp_mmap tcp_inq psock_snd
+TEST_GEN_FILES += tcp_mmap tcp_inq psock_snd txring_overwrite
TEST_GEN_FILES += udpgso udpgso_bench_tx udpgso_bench_rx ip_defrag
TEST_GEN_PROGS = reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa
TEST_GEN_PROGS += reuseport_dualstack reuseaddr_conflict tls
diff --git a/tools/testing/selftests/net/run_afpackettests b/tools/testing/selftests/net/run_afpackettests
index bea079edc278..2dc95fda7ef7 100755
--- a/tools/testing/selftests/net/run_afpackettests
+++ b/tools/testing/selftests/net/run_afpackettests
@@ -25,3 +25,13 @@ if [ $? -ne 0 ]; then
else
echo "[PASS]"
fi
+
+echo "--------------------"
+echo "running txring_overwrite test"
+echo "--------------------"
+./in_netns.sh ./txring_overwrite
+if [ $? -ne 0 ]; then
+ echo "[FAIL]"
+else
+ echo "[PASS]"
+fi
diff --git a/tools/testing/selftests/net/txring_overwrite.c b/tools/testing/selftests/net/txring_overwrite.c
new file mode 100644
index 000000000000..530a0638055b
--- /dev/null
+++ b/tools/testing/selftests/net/txring_overwrite.c
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Verify that consecutive sends over packet tx_ring are mirrored
+ * with their original content intact.
+ */
+
+#define _GNU_SOURCE
+
+#include <arpa/inet.h>
+#include <assert.h>
+#include <error.h>
+#include <errno.h>
+#include <fcntl.h>
+#include <linux/filter.h>
+#include <linux/if_packet.h>
+#include <net/ethernet.h>
+#include <net/if.h>
+#include <netinet/in.h>
+#include <netinet/ip.h>
+#include <netinet/udp.h>
+#include <poll.h>
+#include <pthread.h>
+#include <sched.h>
+#include <sys/ioctl.h>
+#include <sys/mman.h>
+#include <sys/socket.h>
+#include <sys/time.h>
+#include <sys/types.h>
+#include <sys/utsname.h>
+#include <stdbool.h>
+#include <stdint.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+
+const int eth_off = TPACKET_HDRLEN - sizeof(struct sockaddr_ll);
+const int cfg_frame_size = 1000;
+
+static void build_packet(void *buffer, size_t blen, char payload_char)
+{
+ struct udphdr *udph;
+ struct ethhdr *eth;
+ struct iphdr *iph;
+ size_t off = 0;
+
+ memset(buffer, 0, blen);
+
+ eth = buffer;
+ eth->h_proto = htons(ETH_P_IP);
+
+ off += sizeof(*eth);
+ iph = buffer + off;
+ iph->ttl = 8;
+ iph->ihl = 5;
+ iph->version = 4;
+ iph->saddr = htonl(INADDR_LOOPBACK);
+ iph->daddr = htonl(INADDR_LOOPBACK + 1);
+ iph->protocol = IPPROTO_UDP;
+ iph->tot_len = htons(blen - off);
+ iph->check = 0;
+
+ off += sizeof(*iph);
+ udph = buffer + off;
+ udph->dest = htons(8000);
+ udph->source = htons(8001);
+ udph->len = htons(blen - off);
+ udph->check = 0;
+
+ off += sizeof(*udph);
+ memset(buffer + off, payload_char, blen - off);
+}
+
+static int setup_rx(void)
+{
+ int fdr;
+
+ fdr = socket(PF_PACKET, SOCK_RAW, htons(ETH_P_IP));
+ if (fdr == -1)
+ error(1, errno, "socket r");
+
+ return fdr;
+}
+
+static int setup_tx(char **ring)
+{
+ struct sockaddr_ll laddr = {};
+ struct tpacket_req req = {};
+ int fdt;
+
+ fdt = socket(PF_PACKET, SOCK_RAW, 0);
+ if (fdt == -1)
+ error(1, errno, "socket t");
+
+ laddr.sll_family = AF_PACKET;
+ laddr.sll_protocol = htons(0);
+ laddr.sll_ifindex = if_nametoindex("lo");
+ if (!laddr.sll_ifindex)
+ error(1, errno, "if_nametoindex");
+
+ if (bind(fdt, (void *)&laddr, sizeof(laddr)))
+ error(1, errno, "bind fdt");
+
+ req.tp_block_size = getpagesize();
+ req.tp_block_nr = 1;
+ req.tp_frame_size = getpagesize();
+ req.tp_frame_nr = 1;
+
+ if (setsockopt(fdt, SOL_PACKET, PACKET_TX_RING,
+ (void *)&req, sizeof(req)))
+ error(1, errno, "setsockopt ring");
+
+ *ring = mmap(0, req.tp_block_size * req.tp_block_nr,
+ PROT_READ | PROT_WRITE, MAP_SHARED, fdt, 0);
+ if (!*ring)
+ error(1, errno, "mmap");
+
+ return fdt;
+}
+
+static void send_pkt(int fdt, void *slot, char payload_char)
+{
+ struct tpacket_hdr *header = slot;
+ int ret;
+
+ while (header->tp_status != TP_STATUS_AVAILABLE)
+ usleep(1000);
+
+ build_packet(slot + eth_off, cfg_frame_size, payload_char);
+
+ header->tp_len = cfg_frame_size;
+ header->tp_status = TP_STATUS_SEND_REQUEST;
+
+ ret = sendto(fdt, NULL, 0, 0, NULL, 0);
+ if (ret == -1)
+ error(1, errno, "kick tx");
+}
+
+static int read_verify_pkt(int fdr, char payload_char)
+{
+ char buf[100];
+ int ret;
+
+ ret = read(fdr, buf, sizeof(buf));
+ if (ret != sizeof(buf))
+ error(1, errno, "read");
+
+ if (buf[60] != payload_char) {
+ printf("wrong pattern: 0x%x != 0x%x\n", buf[60], payload_char);
+ return 1;
+ }
+
+ printf("read: %c (0x%x)\n", buf[60], buf[60]);
+ return 0;
+}
+
+int main(int argc, char **argv)
+{
+ const char payload_patterns[] = "ab";
+ char *ring;
+ int fdr, fdt, ret = 0;
+
+ fdr = setup_rx();
+ fdt = setup_tx(&ring);
+
+ send_pkt(fdt, ring, payload_patterns[0]);
+ send_pkt(fdt, ring, payload_patterns[1]);
+
+ ret |= read_verify_pkt(fdr, payload_patterns[0]);
+ ret |= read_verify_pkt(fdr, payload_patterns[1]);
+
+ if (close(fdt))
+ error(1, errno, "close t");
+ if (close(fdr))
+ error(1, errno, "close r");
+
+ return ret;
+}
+
--
2.20.0.rc0.387.gc7a69e6b6c-goog
^ permalink raw reply related
* Re: [PATCH net-next 1/2] udp: msg_zerocopy
From: David Miller @ 2018-11-25 1:58 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: netdev, willemb
In-Reply-To: <20181124192431.32037-2-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Sat, 24 Nov 2018 14:24:30 -0500
> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
> index c09219e7f230..2d1e4b67a1e8 100644
> --- a/net/ipv4/ip_output.c
> +++ b/net/ipv4/ip_output.c
> @@ -868,6 +868,7 @@ static int __ip_append_data(struct sock *sk,
> {
> struct inet_sock *inet = inet_sk(sk);
> struct sk_buff *skb;
> + struct ubuf_info *uarg = NULL;
Reverse christmas tree, please.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/2] udp msg_zerocopy
From: David Miller @ 2018-11-25 1:57 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: netdev, willemb
In-Reply-To: <20181124192431.32037-1-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Sat, 24 Nov 2018 14:24:29 -0500
> From: Willem de Bruijn <willemb@google.com>
>
> Enable MSG_ZEROCOPY for udp sockets
>
> Patch 1/2 is the main patch, a rebase from RFC patch
> http://patchwork.ozlabs.org/patch/899630/
> more details in the patch commit message
>
> Patch 2/2 runs the already existing udp zerocopy tests
> as part of kselftest
>
> See also recent Linux Plumbers presentation
> https://linuxplumbersconf.org/event/2/contributions/106/attachments/104/128/willemdebruijn-lpc2018-udpgso-presentation-20181113.pdf
Series looks good, just one coding style to fix up, I'll reply to patch #1.
^ permalink raw reply
* Re: [PATCH net-next 2/2] r8169: make use of xmit_more and __netdev_sent_queue
From: David Miller @ 2018-11-25 1:55 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <8d1e7760-e94b-a9b5-826b-27f342673fa2@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sun, 25 Nov 2018 00:14:58 +0100
> Make use of xmit_more and add the functionality introduced with
> 3e59020abf0f ("net: bql: add __netdev_tx_sent_queue()").
> I used the mlx4 driver as template.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Series looks great, but please fix the reverse christmas tree:
> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
> index 5ee684f9e..7a979c1e5 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -6070,6 +6070,7 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
> dma_addr_t mapping;
> u32 opts[2], len;
> int frags;
> + bool stop_queue;
here, thanks.
^ permalink raw reply
* Re: [PATCH net] net: always initialize pagedlen
From: Willem de Bruijn @ 2018-11-25 1:48 UTC (permalink / raw)
To: David Miller; +Cc: Network Development, Willem de Bruijn
In-Reply-To: <20181124.174336.2013396951281875471.davem@davemloft.net>
On Sat, Nov 24, 2018 at 8:43 PM David Miller <davem@davemloft.net> wrote:
>
> From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> Date: Sat, 24 Nov 2018 14:21:16 -0500
>
> > From: Willem de Bruijn <willemb@google.com>
> >
> > In ip packet generation, pagedlen is initialized for each skb at the
> > start of the loop in __ip(6)_append_data, before label alloc_new_skb.
> >
> > Depending on compiler options, code can be generated that jumps to
> > this label, triggering use of an an uninitialized variable.
> >
> > In practice, at -O2, the generated code moves the initialization below
> > the label. But the code should not rely on that for correctness.
> >
> > Fixes: 15e36f5b8e98 ("udp: paged allocation with gso")
> > Signed-off-by: Willem de Bruijn <willemb@google.com>
> >
> > ---
> >
> > Noticed when rebasing udp zerocopy. I considered merging as part of
> > that patchset, but this seemed like it should go to net, even if it
> > does not trigger in practice.
> >
> > Merged net with this patch onto net-next with udp zerocopy to verify
> > that there is no merge conflict.
>
> Ok, applied, but not queued for -stable.
>
> Let me know if I should -stable this.
Thanks, David. No, that's not needed.
^ permalink raw reply
* [PATCH iproute2-next] man: tc: update man page for fq packet scheduler
From: Eric Dumazet @ 2018-11-25 1:44 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, Eric Dumazet, Eric Dumazet
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
man/man8/tc-fq.8 | 37 ++++++++++++++++++++++++++-----------
1 file changed, 26 insertions(+), 11 deletions(-)
diff --git a/man/man8/tc-fq.8 b/man/man8/tc-fq.8
index f058a05a531716093d5b3d7d6f2fe4d41577078d..1febe62bb3a6cc1e47b9116881d22986dfa16806 100644
--- a/man/man8/tc-fq.8
+++ b/man/man8/tc-fq.8
@@ -15,23 +15,28 @@ BYTES ] [
.B maxrate
RATE ] [
.B buckets
-NUMBER ] [
+NUMBER ] [
+.B orphan_mask
+NUMBER ] [
.B pacing
|
.B nopacing
-]
+] [
+.B ce_threshold
+TIME ]
.SH DESCRIPTION
FQ (Fair Queue) is a classless packet scheduler meant to be mostly
used for locally generated traffic. It is designed to achieve per flow pacing.
FQ does flow separation, and is able to respect pacing requirements set by TCP stack.
All packets belonging to a socket are considered as a 'flow'.
-For non local packets (router workload), packet rxhash is used as fallback.
+For non local packets (router workload), packet hash is used as fallback.
An application can specify a maximum pacing rate using the
.B SO_MAX_PACING_RATE
setsockopt call. This packet scheduler adds delay between packets to
-respect rate limitation set by TCP stack.
+respect rate limitation set on each socket. Note that after linux-4.20, linux adopted EDT (Earliest Departure Time)
+and TCP directly sets the appropriate Departure Time for each skb.
Dequeueing happens in a round-robin fashion.
A special FIFO queue is reserved for high priority packets (
@@ -72,18 +77,28 @@ is ignored only if it is larger than this value.
The size of the hash table used for flow lookups. Each bucket is assigned a
red-black tree for efficient collision sorting.
Default: 1024.
+.SS orphan_mask
+For packets not owned by a socket, fq is able to mask a part of skb->hash
+and reduce number of buckets associated with the traffic. This is a DDOS
+prevention mechanism, and the default is 1023 (meaning no more than 1024 flows
+are allocated for these packets)
.SS [no]pacing
Enable or disable flow pacing. Default is enabled.
+.SS ce_threshold
+sets a threshold above which all packets are marked with ECN Congestion
+Experienced. This is useful for DCTCP-style congestion control algorithms that
+require marking at very shallow queueing thresholds.
+
.SH EXAMPLES
-#tc qdisc add dev eth0 root fq
+#tc qdisc add dev eth0 root est 1sec 4sec fq ce_threshold 4ms
.br
-#tc -s -d qdisc
+#tc -s -d qdisc sh dev eth0
.br
-qdisc fq 8003: dev eth0 root refcnt 2 limit 10000p flow_limit 100p buckets 1024 quantum 3028 initial_quantum 15140
- Sent 503727981 bytes 1146972 pkt (dropped 0, overlimits 0 requeues 54452)
- backlog 0b 0p requeues 54452
- 1289 flows (1289 inactive, 0 throttled)
- 0 gc, 31 highprio, 27411 throttled
+qdisc fq 800e: root refcnt 9 limit 10000p flow_limit 1000p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms ce_threshold 4.0ms
+ Sent 533368436185 bytes 352296695 pkt (dropped 0, overlimits 0 requeues 1339864)
+ rate 39220Mbit 3238202pps backlog 12417828b 358p requeues 1339864
+ 1052 flows (852 inactive, 0 throttled)
+ 112 gc, 0 highprio, 212 throttled, 21501 ns latency, 470241 ce_mark
.br
.SH SEE ALSO
.BR tc (8),
--
2.20.0.rc0.387.gc7a69e6b6c-goog
^ permalink raw reply related
* Re: [PATCH net] net: always initialize pagedlen
From: David Miller @ 2018-11-25 1:43 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: netdev, willemb
In-Reply-To: <20181124192116.27941-1-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Sat, 24 Nov 2018 14:21:16 -0500
> From: Willem de Bruijn <willemb@google.com>
>
> In ip packet generation, pagedlen is initialized for each skb at the
> start of the loop in __ip(6)_append_data, before label alloc_new_skb.
>
> Depending on compiler options, code can be generated that jumps to
> this label, triggering use of an an uninitialized variable.
>
> In practice, at -O2, the generated code moves the initialization below
> the label. But the code should not rely on that for correctness.
>
> Fixes: 15e36f5b8e98 ("udp: paged allocation with gso")
> Signed-off-by: Willem de Bruijn <willemb@google.com>
>
> ---
>
> Noticed when rebasing udp zerocopy. I considered merging as part of
> that patchset, but this seemed like it should go to net, even if it
> does not trigger in practice.
>
> Merged net with this patch onto net-next with udp zerocopy to verify
> that there is no merge conflict.
Ok, applied, but not queued for -stable.
Let me know if I should -stable this.
^ permalink raw reply
* Re: [PATCH net] tcp: address problems caused by EDT misshaps
From: David Miller @ 2018-11-25 1:42 UTC (permalink / raw)
To: edumazet; +Cc: netdev, ncardwell, ycheng, eric.dumazet
In-Reply-To: <20181124171224.28565-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Sat, 24 Nov 2018 09:12:24 -0800
> When a qdisc setup including pacing FQ is dismantled and recreated,
> some TCP packets are sent earlier than instructed by TCP stack.
>
> TCP can be fooled when ACK comes back, because the following
> operation can return a negative value.
>
> tcp_time_stamp(tp) - tp->rx_opt.rcv_tsecr;
>
> Some paths in TCP stack were not dealing properly with this,
> this patch addresses four of them.
>
> Fixes: ab408b6dc744 ("tcp: switch tcp and sch_fq to new earliest departure time model")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: Can decnet be deprecated?
From: David Ahern @ 2018-11-25 1:35 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20181124.172509.1739636063027441678.davem@davemloft.net>
On 11/24/18 6:25 PM, David Miller wrote:
> From: David Ahern <dsahern@gmail.com>
> Date: Sat, 24 Nov 2018 17:12:48 -0700
>
>> IPX was moved to staging at the end of last year. Can decnet follow
>> suit? git log seems to indicate no active development in a very long time.
>
> Last time I tried to do that someone immediately said on the list
> "Don't, we're using that!"
>
Ugh, I was afraid of that response. I guess I will have to work around
it for the neighbor changes.
^ permalink raw reply
* Re: [PATCH] net: fixup type in netdev_start_xmit()
From: David Miller @ 2018-11-25 1:33 UTC (permalink / raw)
To: adobriyan; +Cc: netdev
In-Reply-To: <20181124090141.GA10626@avx2>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Sat, 24 Nov 2018 12:01:41 +0300
> Return code should be formally "netdev_tx_t".
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net-next v2 0/4] qed* enhancements series
From: David Miller @ 2018-11-25 1:32 UTC (permalink / raw)
To: sudarsana.kalluru; +Cc: netdev, Ariel.Elior, Michal.Kalderon
In-Reply-To: <20181124074233.4077-1-sudarsana.kalluru@cavium.com>
From: Sudarsana Reddy Kalluru <sudarsana.kalluru@cavium.com>
Date: Fri, 23 Nov 2018 23:42:29 -0800
> v2: Use __set_bit()/__clear_bit() where data access doesn't need to be
> atomic.
Wait.
How does this interact with the clear_bit_unlock() used by the qede PTP code?
You can't really mix atomic and non-atomic accesses to edev->flags
.
^ permalink raw reply
* Re: Can decnet be deprecated?
From: David Miller @ 2018-11-25 1:25 UTC (permalink / raw)
To: dsahern; +Cc: netdev
In-Reply-To: <2c63cb14-ddba-dda3-4ef6-79b31101f162@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Sat, 24 Nov 2018 17:12:48 -0700
> IPX was moved to staging at the end of last year. Can decnet follow
> suit? git log seems to indicate no active development in a very long time.
Last time I tried to do that someone immediately said on the list
"Don't, we're using that!"
^ permalink raw reply
* Re: [PATCH net] ixgbe: recognize 1000BaseLX SFP modules as 1Gbps
From: Bjørn Mork @ 2018-11-25 11:07 UTC (permalink / raw)
To: Josh Elsasser
Cc: intel-wired-lan, Jeff Kirsher, David S. Miller, netdev,
linux-kernel
In-Reply-To: <20181124205801.67828-1-jelsasser@appneta.com>
Josh Elsasser <jelsasser@appneta.com> writes:
> Fixes: 6a14ee0cfb19 ("ixgbe: Add X550 support function pointers")
Not that it matters much I guess, but I think LX SFPs were unsupported
at that time. The LX support appears to have been added under the radar
while refactoring ixgbe_setup_sfp_modules_X550em in commit e23f33367882
("ixgbe: Fix 1G and 10G link stability for X550EM_x SFP+")
Bjørn
^ permalink raw reply
* Can decnet be deprecated?
From: David Ahern @ 2018-11-25 0:12 UTC (permalink / raw)
To: netdev@vger.kernel.org, David Miller
IPX was moved to staging at the end of last year. Can decnet follow
suit? git log seems to indicate no active development in a very long time.
David
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox