* Re: [RFC PATCH ghak32 V2 13/13] debug audit: read container ID of a process
From: Paul Moore @ 2018-05-21 20:06 UTC (permalink / raw)
To: Eric W. Biederman, Steve Grubb, Richard Guy Briggs
Cc: simo, jlayton, linux-api, containers, LKML, Eric Paris, dhowells,
carlos, linux-audit, viro, luto, netdev, linux-fsdevel, cgroups,
serge
In-Reply-To: <87muwshl4z.fsf@xmission.com>
On Mon, May 21, 2018 at 3:19 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Steve Grubb <sgrubb@redhat.com> writes:
>
>> On Friday, March 16, 2018 5:00:40 AM EDT Richard Guy Briggs wrote:
>>> Add support for reading the container ID from the proc filesystem.
>>
>> I think this could be useful in general. Please consider this to be part of
>> the full patch set and not something merely used to debug the patches.
>
> Only with an audit specific name.
>
> As it is:
>
> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> The truth is the containerid name really stinks and is quite confusing
> and does not imply that the label applies only to audit. And little
> things like this make me extremely uncofortable with it.
It also makes the audit container ID (notice how I *always* call it
the *audit* container ID? that is not an accident) available for
userspace applications to abuse. Perhaps in the future we can look at
ways to make this more available to applications, but this patch is
not the answer.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* [PATCH net-next v2] net: sched: don't disable bh when accessing action idr
From: Vlad Buslov @ 2018-05-21 20:03 UTC (permalink / raw)
To: davem; +Cc: netdev, jhs, xiyou.wangcong, jiri, linux-kernel, Vlad Buslov
In-Reply-To: <20180519.230258.1374885458106197707.davem@davemloft.net>
Initial net_device implementation used ingress_lock spinlock to synchronize
ingress path of device. This lock was used in both process and bh context.
In some code paths action map lock was obtained while holding ingress_lock.
Commit e1e992e52faa ("[NET_SCHED] protect action config/dump from irqs")
modified actions to always disable bh, while using action map lock, in
order to prevent deadlock on ingress_lock in softirq. This lock was removed
from net_device, so disabling bh, while accessing action map, is no longer
necessary.
Replace all action idr spinlock usage with regular calls that do not
disable bh.
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
---
net/sched/act_api.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 72251241665a..3f4cf930f809 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -77,9 +77,9 @@ static void free_tcf(struct tc_action *p)
static void tcf_idr_remove(struct tcf_idrinfo *idrinfo, struct tc_action *p)
{
- spin_lock_bh(&idrinfo->lock);
+ spin_lock(&idrinfo->lock);
idr_remove(&idrinfo->action_idr, p->tcfa_index);
- spin_unlock_bh(&idrinfo->lock);
+ spin_unlock(&idrinfo->lock);
gen_kill_estimator(&p->tcfa_rate_est);
free_tcf(p);
}
@@ -156,7 +156,7 @@ static int tcf_dump_walker(struct tcf_idrinfo *idrinfo, struct sk_buff *skb,
struct tc_action *p;
unsigned long id = 1;
- spin_lock_bh(&idrinfo->lock);
+ spin_lock(&idrinfo->lock);
s_i = cb->args[0];
@@ -191,7 +191,7 @@ static int tcf_dump_walker(struct tcf_idrinfo *idrinfo, struct sk_buff *skb,
if (index >= 0)
cb->args[0] = index + 1;
- spin_unlock_bh(&idrinfo->lock);
+ spin_unlock(&idrinfo->lock);
if (n_i) {
if (act_flags & TCA_FLAG_LARGE_DUMP_ON)
cb->args[1] = n_i;
@@ -261,9 +261,9 @@ static struct tc_action *tcf_idr_lookup(u32 index, struct tcf_idrinfo *idrinfo)
{
struct tc_action *p = NULL;
- spin_lock_bh(&idrinfo->lock);
+ spin_lock(&idrinfo->lock);
p = idr_find(&idrinfo->action_idr, index);
- spin_unlock_bh(&idrinfo->lock);
+ spin_unlock(&idrinfo->lock);
return p;
}
@@ -323,7 +323,7 @@ int tcf_idr_create(struct tc_action_net *tn, u32 index, struct nlattr *est,
}
spin_lock_init(&p->tcfa_lock);
idr_preload(GFP_KERNEL);
- spin_lock_bh(&idrinfo->lock);
+ spin_lock(&idrinfo->lock);
/* user doesn't specify an index */
if (!index) {
index = 1;
@@ -331,7 +331,7 @@ int tcf_idr_create(struct tc_action_net *tn, u32 index, struct nlattr *est,
} else {
err = idr_alloc_u32(idr, NULL, &index, index, GFP_ATOMIC);
}
- spin_unlock_bh(&idrinfo->lock);
+ spin_unlock(&idrinfo->lock);
idr_preload_end();
if (err)
goto err3;
@@ -369,9 +369,9 @@ void tcf_idr_insert(struct tc_action_net *tn, struct tc_action *a)
{
struct tcf_idrinfo *idrinfo = tn->idrinfo;
- spin_lock_bh(&idrinfo->lock);
+ spin_lock(&idrinfo->lock);
idr_replace(&idrinfo->action_idr, a, a->tcfa_index);
- spin_unlock_bh(&idrinfo->lock);
+ spin_unlock(&idrinfo->lock);
}
EXPORT_SYMBOL(tcf_idr_insert);
--
2.7.5
^ permalink raw reply related
* Re: [PATCH bpf-next 1/7] bpf: Expose check_uarg_tail_zero()
From: Yonghong Song @ 2018-05-21 20:00 UTC (permalink / raw)
To: Martin KaFai Lau, netdev; +Cc: Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20180519001650.4043980-2-kafai@fb.com>
On 5/18/18 5:16 PM, Martin KaFai Lau wrote:
> This patch exposes check_uarg_tail_zero() which will
> be reused by a later BTF patch. Its name is changed to
> bpf_check_uarg_tail_zero().
>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Yonghong Song <yhs@fb.com>
^ permalink raw reply
* Re: [PATCH bpf v2 6/6] bpf: fix JITed dump for multi-function programs via syscall
From: Sandipan Das @ 2018-05-21 19:42 UTC (permalink / raw)
To: Daniel Borkmann
Cc: ast, netdev, linuxppc-dev, naveen.n.rao, mpe, jakub.kicinski
In-Reply-To: <654d4424-ad99-2b5e-dcbf-9e352aec75d6@iogearbox.net>
Hi Daniel,
On 05/18/2018 09:21 PM, Daniel Borkmann wrote:
> On 05/18/2018 02:50 PM, Sandipan Das wrote:
>> Currently, for multi-function programs, we cannot get the JITed
>> instructions using the bpf system call's BPF_OBJ_GET_INFO_BY_FD
>> command. Because of this, userspace tools such as bpftool fail
>> to identify a multi-function program as being JITed or not.
>>
>> With the JIT enabled and the test program running, this can be
>> verified as follows:
>>
>> # cat /proc/sys/net/core/bpf_jit_enable
>> 1
>>
>> Before applying this patch:
>>
>> # bpftool prog list
>> 1: kprobe name foo tag b811aab41a39ad3d gpl
>> loaded_at 2018-05-16T11:43:38+0530 uid 0
>> xlated 216B not jited memlock 65536B
>> ...
>>
>> # bpftool prog dump jited id 1
>> no instructions returned
>>
>> After applying this patch:
>>
>> # bpftool prog list
>> 1: kprobe name foo tag b811aab41a39ad3d gpl
>> loaded_at 2018-05-16T12:13:01+0530 uid 0
>> xlated 216B jited 308B memlock 65536B
>> ...
>
> That's really nice! One comment inline below:
>
>> # bpftool prog dump jited id 1
>> 0: nop
>> 4: nop
>> 8: mflr r0
>> c: std r0,16(r1)
>> 10: stdu r1,-112(r1)
>> 14: std r31,104(r1)
>> 18: addi r31,r1,48
>> 1c: li r3,10
>> ...
>>
>> Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
>> ---
>> kernel/bpf/syscall.c | 38 ++++++++++++++++++++++++++++++++------
>> 1 file changed, 32 insertions(+), 6 deletions(-)
>>
>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
>> index 54a72fafe57c..2430d159078c 100644
>> --- a/kernel/bpf/syscall.c
>> +++ b/kernel/bpf/syscall.c
>> @@ -1896,7 +1896,7 @@ static int bpf_prog_get_info_by_fd(struct bpf_prog *prog,
>> struct bpf_prog_info info = {};
>> u32 info_len = attr->info.info_len;
>> char __user *uinsns;
>> - u32 ulen;
>> + u32 ulen, i;
>> int err;
>>
>> err = check_uarg_tail_zero(uinfo, sizeof(info), info_len);
>> @@ -1922,7 +1922,6 @@ static int bpf_prog_get_info_by_fd(struct bpf_prog *prog,
>> ulen = min_t(u32, info.nr_map_ids, ulen);
>> if (ulen) {
>> u32 __user *user_map_ids = u64_to_user_ptr(info.map_ids);
>> - u32 i;
>>
>> for (i = 0; i < ulen; i++)
>> if (put_user(prog->aux->used_maps[i]->id,
>> @@ -1970,13 +1969,41 @@ static int bpf_prog_get_info_by_fd(struct bpf_prog *prog,
>> * for offload.
>> */
>> ulen = info.jited_prog_len;
>> - info.jited_prog_len = prog->jited_len;
>> + if (prog->aux->func_cnt) {
>> + info.jited_prog_len = 0;
>> + for (i = 0; i < prog->aux->func_cnt; i++)
>> + info.jited_prog_len += prog->aux->func[i]->jited_len;
>> + } else {
>> + info.jited_prog_len = prog->jited_len;
>> + }
>> +
>> if (info.jited_prog_len && ulen) {
>> if (bpf_dump_raw_ok()) {
>> uinsns = u64_to_user_ptr(info.jited_prog_insns);
>> ulen = min_t(u32, info.jited_prog_len, ulen);
>> - if (copy_to_user(uinsns, prog->bpf_func, ulen))
>> - return -EFAULT;
>> +
>> + /* for multi-function programs, copy the JITed
>> + * instructions for all the functions
>> + */
>> + if (prog->aux->func_cnt) {
>> + u32 len, free;
>> + u8 *img;
>> +
>> + free = ulen;
>> + for (i = 0; i < prog->aux->func_cnt; i++) {
>> + len = prog->aux->func[i]->jited_len;
>> + img = (u8 *) prog->aux->func[i]->bpf_func;
>> + if (len > free)
>> + break;
>> + if (copy_to_user(uinsns, img, len))
>> + return -EFAULT;
>> + uinsns += len;
>> + free -= len;
>
> Is there any way we can introduce a delimiter between the different
> images such that they could be more easily correlated with the call
> from the main (or other sub-)program instead of having one contiguous
> dump blob?
>
Can we have another member in bpf_prog_info that points to a list of the lengths of the
JITed images for each subprogram? We can use this information to split up the dump.
- Sandipan
>> + }
>> + } else {
>> + if (copy_to_user(uinsns, prog->bpf_func, ulen))
>> + return -EFAULT;
>> + }
>> } else {
>> info.jited_prog_insns = 0;
>> }
>> @@ -1987,7 +2014,6 @@ static int bpf_prog_get_info_by_fd(struct bpf_prog *prog,
>> if (info.nr_jited_ksyms && ulen) {
>> u64 __user *user_jited_ksyms = u64_to_user_ptr(info.jited_ksyms);
>> ulong ksym_addr;
>> - u32 i;
>>
>> /* copy the address of the kernel symbol corresponding to
>> * each function
>>
>
>
^ permalink raw reply
* [PATCH net 1/1] qed: Fix mask for physical address in ILT entry
From: Shahed Shaikh @ 2018-05-21 19:31 UTC (permalink / raw)
To: davem; +Cc: netdev, Ariel.Elior, Dept-EngEverestLinuxL2
ILT entry requires 12 bit right shifted physical address.
Existing mask for ILT entry of physical address i.e.
ILT_ENTRY_PHY_ADDR_MASK is not sufficient to handle 64bit
address because upper 8 bits of 64 bit address were getting
masked which resulted in completer abort error on
PCIe bus due to invalid address.
Fix that mask to handle 64bit physical address.
Fixes: fe56b9e6a8d9 ("qed: Add module with basic common support")
Signed-off-by: Shahed Shaikh <shahed.shaikh@cavium.com>
Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_cxt.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_cxt.c b/drivers/net/ethernet/qlogic/qed/qed_cxt.c
index 00f41c1..820b226 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_cxt.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_cxt.c
@@ -77,7 +77,7 @@
#define ILT_CFG_REG(cli, reg) PSWRQ2_REG_ ## cli ## _ ## reg ## _RT_OFFSET
/* ILT entry structure */
-#define ILT_ENTRY_PHY_ADDR_MASK 0x000FFFFFFFFFFFULL
+#define ILT_ENTRY_PHY_ADDR_MASK (~0ULL >> 12)
#define ILT_ENTRY_PHY_ADDR_SHIFT 0
#define ILT_ENTRY_VALID_MASK 0x1ULL
#define ILT_ENTRY_VALID_SHIFT 52
--
1.7.1
^ permalink raw reply related
* Re: [RFC PATCH ghak32 V2 13/13] debug audit: read container ID of a process
From: Eric W. Biederman @ 2018-05-21 19:19 UTC (permalink / raw)
To: Steve Grubb
Cc: simo-H+wXaHxf7aLQT0dZR+AlfA, jlayton-H+wXaHxf7aLQT0dZR+AlfA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, LKML,
eparis-FjpueFixGhCM4zKIHC2jIg, dhowells-H+wXaHxf7aLQT0dZR+AlfA,
carlos-H+wXaHxf7aLQT0dZR+AlfA, linux-audit-H+wXaHxf7aLQT0dZR+AlfA,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn,
luto-DgEjT+Ai2ygdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <3001737.MkQ41rgtZF@x2>
Steve Grubb <sgrubb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
> On Friday, March 16, 2018 5:00:40 AM EDT Richard Guy Briggs wrote:
>> Add support for reading the container ID from the proc filesystem.
>
> I think this could be useful in general. Please consider this to be part of
> the full patch set and not something merely used to debug the patches.
Only with an audit specific name.
As it is:
Nacked-by: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
The truth is the containerid name really stinks and is quite confusing
and does not imply that the label applies only to audit. And little
things like this make me extremely uncofortable with it.
Eric
^ permalink raw reply
* Re: [RFC PATCH ghak32 V2 03/13] audit: log container info of syscalls
From: Steve Grubb @ 2018-05-21 19:19 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: cgroups, containers, linux-api, Linux-Audit Mailing List,
linux-fsdevel, LKML, netdev, ebiederm, luto, jlayton, carlos,
dhowells, viro, simo, eparis, serge
In-Reply-To: <20180517214102.qhg4gofwrbsn2eru@madcap2.tricolour.ca>
On Thursday, May 17, 2018 5:41:02 PM EDT Richard Guy Briggs wrote:
> On 2018-05-17 17:09, Steve Grubb wrote:
> > On Fri, 16 Mar 2018 05:00:30 -0400
> >
> > Richard Guy Briggs <rgb@redhat.com> wrote:
> > > Create a new audit record AUDIT_CONTAINER_INFO to document the
> > > container ID of a process if it is present.
> >
> > As mentioned in a previous email, I think AUDIT_CONTAINER is more
> > suitable for the container record. One more comment below...
> >
> > > Called from audit_log_exit(), syscalls are covered.
> > >
> > > A sample raw event:
> > > type=SYSCALL msg=audit(1519924845.499:257): arch=c000003e syscall=257
> > > success=yes exit=3 a0=ffffff9c a1=56374e1cef30 a2=241 a3=1b6 items=2
> > > ppid=606 pid=635 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> > > sgid=0 fsgid=0 tty=pts0 ses=3 comm="bash" exe="/usr/bin/bash"
> > > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> > > key="tmpcontainerid" type=CWD msg=audit(1519924845.499:257):
> > > cwd="/root" type=PATH msg=audit(1519924845.499:257): item=0
> > > name="/tmp/" inode=13863 dev=00:27 mode=041777 ouid=0 ogid=0
> > > rdev=00:00 obj=system_u:object_r:tmp_t:s0 nametype= PARENT
> > > cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
> > > type=PATH msg=audit(1519924845.499:257): item=1
> > > name="/tmp/tmpcontainerid" inode=17729 dev=00:27 mode=0100644 ouid=0
> > > ogid=0 rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0
> > > nametype=CREATE cap_fp=0000000000000000 cap_fi=0000000000000000
> > > cap_fe=0 cap_fver=0 type=PROCTITLE msg=audit(1519924845.499:257):
> > > proctitle=62617368002D6300736C65657020313B206563686F2074657374203E202F7
> > > 46D702F746D70636F6E7461696E65726964 type=CONTAINER_INFO
> > > msg=audit(1519924845.499:257): op=task
> > > contid=123458
> > >
> > > See: https://github.com/linux-audit/audit-kernel/issues/32
> > > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > > ---
> > >
> > > include/linux/audit.h | 5 +++++
> > > include/uapi/linux/audit.h | 1 +
> > > kernel/audit.c | 20 ++++++++++++++++++++
> > > kernel/auditsc.c | 2 ++
> > > 4 files changed, 28 insertions(+)
> > >
> > > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > > index fe4ba3f..3acbe9d 100644
> > > --- a/include/linux/audit.h
> > > +++ b/include/linux/audit.h
> > > @@ -154,6 +154,8 @@ extern void
> > > audit_log_link_denied(const char *operation, extern int
> > > audit_log_task_context(struct audit_buffer *ab); extern void
> > > audit_log_task_info(struct audit_buffer *ab, struct task_struct *tsk);
> > > +extern int audit_log_container_info(struct task_struct *tsk,
> > > + struct audit_context *context);
> > >
> > > extern int audit_update_lsm_rules(void);
> > >
> > > @@ -205,6 +207,9 @@ static inline int audit_log_task_context(struct
> > > audit_buffer *ab) static inline void audit_log_task_info(struct
> > > audit_buffer *ab, struct task_struct *tsk)
> > >
> > > { }
> > >
> > > +static inline int audit_log_container_info(struct task_struct *tsk,
> > > + struct audit_context
> > > *context); +{ }
> > >
> > > #define audit_enabled 0
> > > #endif /* CONFIG_AUDIT */
> > >
> > > diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> > > index 921a71f..e83ccbd 100644
> > > --- a/include/uapi/linux/audit.h
> > > +++ b/include/uapi/linux/audit.h
> > > @@ -115,6 +115,7 @@
> > >
> > > #define AUDIT_REPLACE 1329 /* Replace auditd
> > >
> > > if this packet unanswerd */ #define AUDIT_KERN_MODULE
> > > 1330 /* Kernel Module events */ #define
> > > AUDIT_FANOTIFY 1331 /* Fanotify access decision
> > > */ +#define AUDIT_CONTAINER_INFO 1332 /* Container ID
> > > information */ #define AUDIT_AVC 1400 /* SE
> > > Linux avc denial or grant */ #define AUDIT_SELINUX_ERR
> > > 1401 /* Internal SE Linux Errors */ diff --git
> > > a/kernel/audit.c b/kernel/audit.c index 3f2f143..a12f21f 100644
> > > --- a/kernel/audit.c
> > > +++ b/kernel/audit.c
> > > @@ -2049,6 +2049,26 @@ void audit_log_session_info(struct
> > > audit_buffer *ab) audit_log_format(ab, " auid=%u ses=%u", auid,
> > > sessionid); }
> > >
> > > +/*
> > > + * audit_log_container_info - report container info
> > > + * @tsk: task to be recorded
> > > + * @context: task or local context for record
> > > + */
> > > +int audit_log_container_info(struct task_struct *tsk, struct
> > > audit_context *context) +{
> > > + struct audit_buffer *ab;
> > > +
> > > + if (!audit_containerid_set(tsk))
> > > + return 0;
> > > + /* Generate AUDIT_CONTAINER_INFO with container ID */
> > > + ab = audit_log_start(context, GFP_KERNEL,
> > > AUDIT_CONTAINER_INFO);
> > > + if (!ab)
> > > + return -ENOMEM;
> > > + audit_log_format(ab, "contid=%llu",
> > > audit_get_containerid(tsk));
> > > + audit_log_end(ab);
> > > + return 0;
> > > +}
> > > +
> > >
> > > void audit_log_key(struct audit_buffer *ab, char *key)
> > > {
> > >
> > > audit_log_format(ab, " key=");
> > >
> > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > index a6b0a52..65be110 100644
> > > --- a/kernel/auditsc.c
> > > +++ b/kernel/auditsc.c
> > > @@ -1453,6 +1453,8 @@ static void audit_log_exit(struct audit_context
> > > *context, struct task_struct *ts
> > >
> > > audit_log_proctitle(tsk, context);
> > >
> > > + audit_log_container_info(tsk, context);
> >
> > Would there be any problem moving audit_log_container_info before
> > audit_log_proctitle? There are some assumptions that proctitle is the
> > last record in some situations.
>
> I see no problem doing that.
Actually...just leave it as is. I have to fix things for simple events and
they do not have a proctitle record. So, leave it as you intended and I'll
work around this on my end.
Thanks,
-Steve
> > > /* Send end of event record to help user space know we are
> > >
> > > finished */ ab = audit_log_start(context, GFP_KERNEL, AUDIT_EOE);
> > >
> > > if (ab)
>
> - RGB
>
> --
> Richard Guy Briggs <rgb@redhat.com>
> Sr. S/W Engineer, Kernel Security, Base Operating Systems
> Remote, Ottawa, Red Hat Canada
> IRC: rgb, SunRaycer
> Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [RFC PATCH ghak32 V2 13/13] debug audit: read container ID of a process
From: Steve Grubb @ 2018-05-21 19:16 UTC (permalink / raw)
To: linux-audit
Cc: Richard Guy Briggs, cgroups, containers, linux-api, linux-fsdevel,
LKML, netdev, ebiederm, luto, jlayton, carlos, dhowells, viro,
simo, eparis, serge
In-Reply-To: <1081821010c124fe4e35984ec3dac1654453bb7c.1521179281.git.rgb@redhat.com>
On Friday, March 16, 2018 5:00:40 AM EDT Richard Guy Briggs wrote:
> Add support for reading the container ID from the proc filesystem.
I think this could be useful in general. Please consider this to be part of
the full patch set and not something merely used to debug the patches.
-Steve
> This is a read from the proc entry of the form /proc/PID/containerid
> where PID is the process ID of the task whose container ID is sought.
>
> The read expects up to a u64 value (unset: 18446744073709551615).
>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> fs/proc/base.c | 20 ++++++++++++++++++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index 6ce4fbe..f66d1e2 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -1300,6 +1300,21 @@ static ssize_t proc_sessionid_read(struct file *
> file, char __user * buf, .llseek = generic_file_llseek,
> };
>
> +static ssize_t proc_containerid_read(struct file *file, char __user *buf,
> + size_t count, loff_t *ppos)
> +{
> + struct inode *inode = file_inode(file);
> + struct task_struct *task = get_proc_task(inode);
> + ssize_t length;
> + char tmpbuf[TMPBUFLEN*2];
> +
> + if (!task)
> + return -ESRCH;
> + length = scnprintf(tmpbuf, TMPBUFLEN*2, "%llu",
> audit_get_containerid(task)); + put_task_struct(task);
> + return simple_read_from_buffer(buf, count, ppos, tmpbuf, length);
> +}
> +
> static ssize_t proc_containerid_write(struct file *file, const char __user
> *buf, size_t count, loff_t *ppos)
> {
> @@ -1330,6 +1345,7 @@ static ssize_t proc_containerid_write(struct file
> *file, const char __user *buf, }
>
> static const struct file_operations proc_containerid_operations = {
> + .read = proc_containerid_read,
> .write = proc_containerid_write,
> .llseek = generic_file_llseek,
> };
> @@ -2996,7 +3012,7 @@ static int proc_pid_patch_state(struct seq_file *m,
> struct pid_namespace *ns, #ifdef CONFIG_AUDITSYSCALL
> REG("loginuid", S_IWUSR|S_IRUGO, proc_loginuid_operations),
> REG("sessionid", S_IRUGO, proc_sessionid_operations),
> - REG("containerid", S_IWUSR, proc_containerid_operations),
> + REG("containerid", S_IWUSR|S_IRUSR, proc_containerid_operations),
> #endif
> #ifdef CONFIG_FAULT_INJECTION
> REG("make-it-fail", S_IRUGO|S_IWUSR, proc_fault_inject_operations),
> @@ -3391,7 +3407,7 @@ static int proc_tid_comm_permission(struct inode
> *inode, int mask) #ifdef CONFIG_AUDITSYSCALL
> REG("loginuid", S_IWUSR|S_IRUGO, proc_loginuid_operations),
> REG("sessionid", S_IRUGO, proc_sessionid_operations),
> - REG("containerid", S_IWUSR, proc_containerid_operations),
> + REG("containerid", S_IWUSR|S_IRUSR, proc_containerid_operations),
> #endif
> #ifdef CONFIG_FAULT_INJECTION
> REG("make-it-fail", S_IRUGO|S_IWUSR, proc_fault_inject_operations),
^ permalink raw reply
* Re: [PATCH 0/3] bpf: add boot parameters for sysctl knobs
From: Alexei Starovoitov @ 2018-05-21 18:58 UTC (permalink / raw)
To: Eugene Syromiatnikov
Cc: netdev, linux-kernel, linux-doc, Kees Cook, Kai-Heng Feng,
Daniel Borkmann, Alexei Starovoitov, Jonathan Corbet, Jiri Olsa,
Jesper Dangaard Brouer
In-Reply-To: <20180521122923.GA15717@asgard.redhat.com>
On Mon, May 21, 2018 at 02:29:30PM +0200, Eugene Syromiatnikov wrote:
> Hello.
>
> This patch set adds ability to set default values for
> kernel.unprivileged_bpf_disable, net.core.bpf_jit_harden,
> net.core.bpf_jit_kallsyms sysctl knobs as well as option to override
> them via a boot-time kernel parameter.
Commits log not only should explain 'what' is being done by the patch,
but 'why' as well.
^ permalink raw reply
* Re: [RFC feedback] AF_XDP and non-Intel hardware
From: Björn Töpel @ 2018-05-21 18:55 UTC (permalink / raw)
To: Mykyta Iziumtsev
Cc: Netdev, Björn Töpel, Karlsson, Magnus, Zhang, Qi Z,
Francois Ozog, Ilias Apalodimas, Brian Brooks,
Jesper Dangaard Brouer, andy, michael.chan, luke
In-Reply-To: <CAPvmOuHhoLDB+214_1BptHtUtyU0of=4_99cSXNyv8T-WYjvvg@mail.gmail.com>
2018-05-21 14:34 GMT+02:00 Mykyta Iziumtsev <mykyta.iziumtsev@linaro.org>:
> Hi Björn and Magnus,
>
> (This thread is a follow up to private dialogue. The intention is to
> let community know that AF_XDP can be enhanced further to make it
> compatible with wider range of NIC vendors).
>
Mykyta, thanks for doing the write-up and sending it to the netdev
list! The timing could not be better -- we need to settle on an uapi
that works for all vendors prior enabling it in the kernel.
> There are two NIC variations which don't fit well with current AF_XDP proposal.
>
> The first variation is represented by some NXP and Cavium NICs. AF_XDP
> expects NIC to put incoming frames into slots defined by UMEM area.
> Here slot size is set in XDP_UMEM_REG xdp_umem.reg.frame_size and
> slots available to NIC are communicated to the kernel via UMEM fill
> queue. While Intel NICs support only one slot size, NXP and Cavium
> support multiple slot sizes to optimize memory usage (e.g. { 128, 512,
> 2048 }, please refer to [1] for rationale). On frame reception the NIC
> pulls a slot from best fit pool based on frame size.
>
> The second variation is represented by e.g. Chelsio T5/T6 and Netcope
> NICs. As shown above, AF_XDP expects NIC to put incoming frames at
> predefined addresses. This is not the case here as the NIC is in
> charge of placing frames in memory based on it's own algorithm. For
> example, Chelsio T5/T6 is expecting to get whole pages from the driver
> and puts incoming frames on the page in a 'tape recorder' fashion.
> Assuming 'base' is page address and flen[N] is an array of frame
> lengths, the frame placement in memory will look like that:
> base + 0
> base + frame_len[0]
> base + frame_len[0] + frame_len[1]
> base + frame_len[0] + frame_len[1] + frame_len[2]
> ...
>
> To better support these two NIC variations I suggest to abandon 'frame
> size' structuring in UMEM and stick with 'pages' instead. The NIC
> kernel driver is then responsible for splitting provided pages into
> slots expected by underlying HW (or not splitting at all in case of
> Chelsio/Netcope).
>
Let's call the first variation "multi-pool" and the second
"type-writer" for simplicity. The type-writer model is very
interesting, and makes a lot of sense when the PCIe bus is a
constraint.
> On XDP_UMEM_REG the application needs to specify page_size. Then the
> application can pass empty pages to the kernel driver using UMEM
> 'fill' queue by specifying page offset within the UMEM area. xdp_desc
> format needs to be changed as well: frame location will be defined by
> offset from the beginning of UMEM area instead of frame index. As
> payload headroom can vary with AF_XDP we'll need to specify it in
> xdp_desc as well. Beside that it could be worth to consider changing
> payload length to u16 as 64k+ frames aren't very common in networking.
> The resulting xdp_desc would look like that:
>
> struct xdp_desc {
> __u64 offset;
> __u16 headroom;
> __u16 len;
> __u8 flags;
> __u8 padding[3];
> };
>
Let's expand a bit here; Instead of passing indicies to fixed sized
frames to the fill ring, we now pass a memory region. For simplicity,
let's say a page. The fill ring descriptor requires offset and
len. The offset is a global offset from an UMEM perspective, and len
is the size of the region.
On the Rx ring the descriptor, as you wrote, must be changed as well
to your suggestion above. Note, that headroom is still needed, since
XDP can change the size of a packet, so the fixed headroom stated in
UMEM registration is not sufficient.
This model is obviously more flexible, but then also a bit more
complex. E.g. a fixed-frame NIC (like ixgbe), what should the
behaviour be? Should the fill ring entry be used only for *one* frame,
or chopped up to multiple receive frames? Should it be configurable?
Driver specific?
Also, validating the entries in the fill queue require more work
(compared to the current index variant). Currently, we only skip
invalid indicies. What should we do when say, you pass a memory window
that is too narrow (say 128B) but correct from a UMEM
perspective. Going this path, we need to add pretty hard constraints
so we don't end up it too complex code -- because then it'll be too
slow.
> In current proposal you have a notion of 'frame ownership': 'owned by
> kernel' or 'owned by application'. The ownership is transferred by
> means of enqueueing frame index in UMEM 'fill' queue (from application
> to kernel) or in UMEM 'tx completion' queue (from kernel to
> application). If you decide to adopt 'page' approach this notion needs
> to be changed a bit. This is because in case of packet forwarding one
> and the same page can be used for RX (parts of it enqueued in HW 'free
> lists') and TX (forwarding of previously RXed packets).
>
> I propose to define 'ownership' as a right to manipulate the
> partitioning of the page into frames. Whenever application passes a
> page to the kernel via UMEM 'fill' queue -- the ownership is
> transferred to the kernel. The application can't allocate packets on
> this page until kernel is done with it, but it can change payload of
> RXed packets before forwarding them. The kernel can pass ownership
> back by means of 'end-of-page' in xdp_desc.flags.
>
I like the end-of-page mechanism.
> The pages are definitely supposed to be recycled sooner or later. Even
> if it's not part of kernel API and the housekeeping implementation
> resided completely in application I still would like to propose
> possible (hopefully, cost efficient) solution to that. The recycling
> could be achieved by keeping refcount on pages and recycling the page
> only when it's owned by application and refcount reaches 0.
>
> Whenever application transfers page ownership to the kernel the
> refcount shall be initialized to 0. With each incoming RX xdp_desc the
> corresponding page needs to be identified (xdp_desc.offset >>
> PAGE_SHIFT) and refcount incremented. When the packet gets freed the
> refcount shall be decremented. If packet is forwarded in TX xdp_desc
> -- the refcount gets decremented only on TX completion (again,
> tx_completion.desc >> PAGE_SHIFT). For packets originating from the
> application itself the payload buffers needs to be allocated from
> empty page owned by the application and refcount needs to be
> incremented as well.
>
Strictly speaking, we're not enforcing correctness in the current
solution. If the userspace application passes index 1 mulitple times
to the fill ring, and at the same time send index 1, things will
break. So, with the existing solution the userspace application
*still* needs to track the frames. With this new model, the
tracking/refcounting will be more complex. That might be a concern.
For the multi-pool NICs I think we can still just have one UMEM, and
let the driver decide where in which pool to place this certain chunk
of memory. Thoughts?
Now, how do we go forward? I think this is very important, and I will
hack a copy-mode version for this new API. I'm a bit worried that the
complexity/configuration space will grow and impact performance, but
let's see.
To prove that the API works for the NICs you mentioned, we need an
actual zero-copy implementation for them. Do you think Linaro could
work on a zero-copy variant for any of the NICs above?
Again thanks for bringing this up!
Björn
> [1] https://en.wikipedia.org/wiki/Internet_Mix
>
> With best regards,
> Mykyta
^ permalink raw reply
* [PATCH net-next 4/5] net: ethernet: davinci_emac: Fix printing of base address
From: Florian Fainelli @ 2018-05-21 18:45 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, Grygorii Strashko, David S. Miller,
Ivan Khoronzhuk, Andrew Morton, Keerthy, Bhumika Goyal,
Hernán Gonzalez, Richard Cochran, Lukas Wunner, Rob Herring,
open list:TI ETHERNET SWITCH DRIVER (CPSW), open list
In-Reply-To: <20180521184555.21555-1-f.fainelli@gmail.com>
Use %pa which is the correct formatter to print a physical address,
instead of %p which is just a pointer.
Fixes: a6286ee630f6 ("net: Add TI DaVinci EMAC driver")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/ti/davinci_emac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index abceea802ea1..be0fec17d95d 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1930,8 +1930,8 @@ static int davinci_emac_probe(struct platform_device *pdev)
if (netif_msg_probe(priv)) {
dev_notice(&pdev->dev, "DaVinci EMAC Probe found device "
- "(regs: %p, irq: %d)\n",
- (void *)priv->emac_base_phys, ndev->irq);
+ "(regs: %pa, irq: %d)\n",
+ &priv->emac_base_phys, ndev->irq);
}
pm_runtime_put(&pdev->dev);
--
2.14.1
^ permalink raw reply related
* [PATCH net-next 5/5] ti: ethernet: davinci: Fix cast to int warnings
From: Florian Fainelli @ 2018-05-21 18:45 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, Grygorii Strashko, David S. Miller,
Ivan Khoronzhuk, Andrew Morton, Keerthy, Bhumika Goyal,
Hernán Gonzalez, Richard Cochran, Lukas Wunner, Rob Herring,
open list:TI ETHERNET SWITCH DRIVER (CPSW), open list
In-Reply-To: <20180521184555.21555-1-f.fainelli@gmail.com>
Now that we can compile test this driver on 64-bit hosts, we get some
warnings about how a pointer/address is written/read to/from a register
(sw_token). Fix this by doing the appropriate conversions, we cannot
possibly have the driver work on 64-bit hosts the way the tokens are
managed though, since the registers being written to a 32-bit only.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/ti/davinci_cpdma.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c
index 9ec49213de5e..cdbddf16dd29 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -1080,7 +1080,7 @@ int cpdma_chan_submit(struct cpdma_chan *chan, void *token, void *data,
writel_relaxed(buffer, &desc->hw_buffer);
writel_relaxed(len, &desc->hw_len);
writel_relaxed(mode | len, &desc->hw_mode);
- writel_relaxed(token, &desc->sw_token);
+ writel_relaxed((uintptr_t)token, &desc->sw_token);
writel_relaxed(buffer, &desc->sw_buffer);
writel_relaxed(len, &desc->sw_len);
desc_read(desc, sw_len);
@@ -1121,15 +1121,15 @@ static void __cpdma_chan_free(struct cpdma_chan *chan,
struct cpdma_desc_pool *pool = ctlr->pool;
dma_addr_t buff_dma;
int origlen;
- void *token;
+ uintptr_t token;
- token = (void *)desc_read(desc, sw_token);
+ token = desc_read(desc, sw_token);
buff_dma = desc_read(desc, sw_buffer);
origlen = desc_read(desc, sw_len);
dma_unmap_single(ctlr->dev, buff_dma, origlen, chan->dir);
cpdma_desc_free(pool, desc, 1);
- (*chan->handler)(token, outlen, status);
+ (*chan->handler)((void *)token, outlen, status);
}
static int __cpdma_chan_process(struct cpdma_chan *chan)
--
2.14.1
^ permalink raw reply related
* [PATCH net-next 3/5] net: ethernet: ti: cpsw: Fix cpsw_add_ch_strings() printk format
From: Florian Fainelli @ 2018-05-21 18:45 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, Grygorii Strashko, David S. Miller,
Ivan Khoronzhuk, Andrew Morton, Keerthy, Bhumika Goyal,
Hernán Gonzalez, Richard Cochran, Lukas Wunner, Rob Herring,
open list:TI ETHERNET SWITCH DRIVER (CPSW), open list
In-Reply-To: <20180521184555.21555-1-f.fainelli@gmail.com>
When building on a 64-bit host we will get the following warning:
drivers/net/ethernet/ti/cpsw.c: In function 'cpsw_add_ch_strings':
drivers/net/ethernet/ti/cpsw.c:1284:19: warning: format '%d' expects
argument of type 'int', but argument 5 has type 'long unsigned int'
[-Wformat=]
"%s DMA chan %d: %s", rx_dir ? "Rx" : "Tx",
~^
%ld
Fix this by using an %ld format and casting to long.
Fixes: e05107e6b747 ("net: ethernet: ti: cpsw: add multi queue support")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/ti/cpsw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index a7285dddfd29..643cd2d9dfb6 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1281,8 +1281,8 @@ static void cpsw_add_ch_strings(u8 **p, int ch_num, int rx_dir)
for (i = 0; i < ch_stats_len; i++) {
line = i % CPSW_STATS_CH_LEN;
snprintf(*p, ETH_GSTRING_LEN,
- "%s DMA chan %d: %s", rx_dir ? "Rx" : "Tx",
- i / CPSW_STATS_CH_LEN,
+ "%s DMA chan %ld: %s", rx_dir ? "Rx" : "Tx",
+ (long)(i / CPSW_STATS_CH_LEN),
cpsw_gstrings_ch_stats[line].stat_string);
*p += ETH_GSTRING_LEN;
}
--
2.14.1
^ permalink raw reply related
* [PATCH net-next 2/5] net: ethernet: ti: cpts: Fix timestamp print
From: Florian Fainelli @ 2018-05-21 18:45 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, Grygorii Strashko, David S. Miller,
Ivan Khoronzhuk, Andrew Morton, Keerthy, Bhumika Goyal,
Hernán Gonzalez, Richard Cochran, Lukas Wunner, Rob Herring,
open list:TI ETHERNET SWITCH DRIVER (CPSW), open list
In-Reply-To: <20180521184555.21555-1-f.fainelli@gmail.com>
On 64-bit hosts we will get the following warning:
drivers/net/ethernet/ti/cpts.c: In function 'cpts_overflow_check':
drivers/net/ethernet/ti/cpts.c:297:11: warning: format '%lld' expects
argument of type 'long long int', but argument 3 has type
'__kernel_time_t {aka long int}' [-Wformat=]
pr_debug("cpts overflow check at %lld.%09lu\n", ts.tv_sec,
ts.tv_nsec);
Fix this by using an appropriate casting that works on all bit sizes.
Fixes: a5c79c26e168 ("ptp: cpts: convert to the 64 bit get/set time methods.")
Fixes: 87c0e764d43a ("cpts: introduce time stamping code and a PTP hardware clock.")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/ti/cpts.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/cpts.c b/drivers/net/ethernet/ti/cpts.c
index 7842f094f2ef..6f63c8729afc 100644
--- a/drivers/net/ethernet/ti/cpts.c
+++ b/drivers/net/ethernet/ti/cpts.c
@@ -294,7 +294,8 @@ static long cpts_overflow_check(struct ptp_clock_info *ptp)
delay = CPTS_SKB_TX_WORK_TIMEOUT;
spin_unlock_irqrestore(&cpts->lock, flags);
- pr_debug("cpts overflow check at %lld.%09lu\n", ts.tv_sec, ts.tv_nsec);
+ pr_debug("cpts overflow check at %lld.%09ld\n",
+ (long long)ts.tv_sec, ts.tv_nsec);
return (long)delay;
}
--
2.14.1
^ permalink raw reply related
* [PATCH net-next 1/5] ti: ethernet: cpdma: Use correct format for genpool_*
From: Florian Fainelli @ 2018-05-21 18:45 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, Grygorii Strashko, David S. Miller,
Ivan Khoronzhuk, Andrew Morton, Keerthy, Bhumika Goyal,
Hernán Gonzalez, Richard Cochran, Lukas Wunner, Rob Herring,
open list:TI ETHERNET SWITCH DRIVER (CPSW), open list
In-Reply-To: <20180521184555.21555-1-f.fainelli@gmail.com>
Now that we can compile davinci_cpdma.c on 64-bit hosts, we can see that
the format used for printing a size_t type is incorrect, use %zd
accordingly.
Fixes: aeec3021043b ("net: ethernet: ti: cpdma: remove used_desc counter")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/ti/davinci_cpdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c
index 31ae04117f0a..9ec49213de5e 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -191,7 +191,7 @@ static void cpdma_desc_pool_destroy(struct cpdma_ctlr *ctlr)
return;
WARN(gen_pool_size(pool->gen_pool) != gen_pool_avail(pool->gen_pool),
- "cpdma_desc_pool size %d != avail %d",
+ "cpdma_desc_pool size %zd != avail %zd",
gen_pool_size(pool->gen_pool),
gen_pool_avail(pool->gen_pool));
if (pool->cpumap)
--
2.14.1
^ permalink raw reply related
* [PATCH net-next 0/5] TI Ethernet driver warnings fixes
From: Florian Fainelli @ 2018-05-21 18:45 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, Grygorii Strashko, David S. Miller,
Ivan Khoronzhuk, Andrew Morton, Keerthy, Bhumika Goyal,
Hernán Gonzalez, Richard Cochran, Lukas Wunner, Rob Herring,
open list:TI ETHERNET SWITCH DRIVER (CPSW), open list
Hi all,
This patch series attempts to fix properly the warnings observed with turning
on COMPILE_TEST and TI Ethernet drivers on 64-bit hosts.
Since I don't have any of this hardware, please review carefully for possible
breakage!
Thank you!
Florian Fainelli (5):
ti: ethernet: cpdma: Use correct format for genpool_*
net: ethernet: ti: cpts: Fix timestamp print
net: ethernet: ti: cpsw: Fix cpsw_add_ch_strings() printk format
net: ethernet: davinci_emac: Fix printing of base address
ti: ethernet: davinci: Fix cast to int warnings
drivers/net/ethernet/ti/cpsw.c | 4 ++--
drivers/net/ethernet/ti/cpts.c | 3 ++-
drivers/net/ethernet/ti/davinci_cpdma.c | 10 +++++-----
drivers/net/ethernet/ti/davinci_emac.c | 4 ++--
4 files changed, 11 insertions(+), 10 deletions(-)
--
2.14.1
^ permalink raw reply
* Re: [PATCH net-next 0/8] tcp: default RACK loss recovery
From: hiren panchasara @ 2018-05-21 18:39 UTC (permalink / raw)
To: David Miller; +Cc: ycheng, netdev, edumazet, ncardwell, soheil, priyarjha
In-Reply-To: <20180517.154529.1714253947519146893.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]
On 05/17/18 at 03:45P, David Miller wrote:
> From: Yuchung Cheng <ycheng@google.com>
> Date: Wed, 16 May 2018 16:40:09 -0700
>
> > This patch set implements the features correspond to the
> > draft-ietf-tcpm-rack-03 version of the RACK draft.
> > https://datatracker.ietf.org/meeting/101/materials/slides-101-tcpm-update-on-tcp-rack-00
> >
> > 1. SACK: implement equivalent DUPACK threshold heuristic in RACK to
> > replace existing RFC6675 recovery (tcp_mark_head_lost).
> >
> > 2. Non-SACK: simplify RFC6582 NewReno implementation
> >
> > 3. RTO: apply RACK's time-based approach to avoid spuriouly
> > marking very recently sent packets lost.
> >
> > 4. with (1)(2)(3), make RACK the exclusive fast recovery mechanism to
> > mark losses based on time on S/ACK. Tail loss probe and F-RTO remain
> > enabled by default as complementary mechanisms to send probes in
> > CA_Open and CA_Loss states. The probes would solicit S/ACKs to trigger
> > RACK time-based loss detection.
> >
> > All Google web and internal servers have been running RACK-only mode
> > (4) for a while now. a/b experiments indicate RACK/TLP on average
> > reduces recovery latency by 10% compared to RFC6675. RFC6675
> > is default-off now but can be enabled by disabling RACK (sysctl
> > net.ipv4.tcp_recovery=0) for unseen issues.
>
> Series applied.
>
> These patches, the design of the ordering of changes in the patch series,
> and the commit messages themselves were more than a pleasure to read.
>
> Really, this patch series is a great model for others who want to
> improve the quality and reviewability of their submissions.
Second that as a maintainer of a non-linux stack. Thanks a ton for such
clear and crisp commit-log messages along with the actual changes.
Cheers,
Hiren
[-- Attachment #2: Type: application/pgp-signature, Size: 603 bytes --]
^ permalink raw reply
* Re: [PATCH net] ipmr: properly check rhltable_init() return value
From: Nikolay Aleksandrov @ 2018-05-21 18:24 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller; +Cc: netdev, Eric Dumazet, Yuval Mintz
In-Reply-To: <20180521175153.27484-1-edumazet@google.com>
On 05/21/2018 08:51 PM, Eric Dumazet wrote:
> commit 8fb472c09b9d ("ipmr: improve hash scalability")
> added a call to rhltable_init() without checking its return value.
>
> This problem was then later copied to IPv6 and factorized in commit
> 0bbbf0e7d0e7 ("ipmr, ip6mr: Unite creation of new mr_table")
>
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: 0000 [#1] SMP KASAN
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 31552 Comm: syz-executor7 Not tainted 4.17.0-rc5+ #60
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> RIP: 0010:rht_key_hashfn include/linux/rhashtable.h:277 [inline]
> RIP: 0010:__rhashtable_lookup include/linux/rhashtable.h:630 [inline]
> RIP: 0010:rhltable_lookup include/linux/rhashtable.h:716 [inline]
> RIP: 0010:mr_mfc_find_parent+0x2ad/0xbb0 net/ipv4/ipmr_base.c:63
> RSP: 0018:ffff8801826aef70 EFLAGS: 00010203
> RAX: 0000000000000001 RBX: 0000000000000001 RCX: ffffc90001ea0000
> RDX: 0000000000000079 RSI: ffffffff8661e859 RDI: 000000000000000c
> RBP: ffff8801826af1c0 R08: ffff8801b2212000 R09: ffffed003b5e46c2
> R10: ffffed003b5e46c2 R11: ffff8801daf23613 R12: dffffc0000000000
> R13: ffff8801826af198 R14: ffff8801cf8225c0 R15: ffff8801826af658
> FS: 00007ff7fa732700(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000003ffffff9c CR3: 00000001b0210000 CR4: 00000000001406e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> ip6mr_cache_find_parent net/ipv6/ip6mr.c:981 [inline]
> ip6mr_mfc_delete+0x1fe/0x6b0 net/ipv6/ip6mr.c:1221
> ip6_mroute_setsockopt+0x15c6/0x1d70 net/ipv6/ip6mr.c:1698
> do_ipv6_setsockopt.isra.9+0x422/0x4660 net/ipv6/ipv6_sockglue.c:163
> ipv6_setsockopt+0xbd/0x170 net/ipv6/ipv6_sockglue.c:922
> rawv6_setsockopt+0x59/0x140 net/ipv6/raw.c:1060
> sock_common_setsockopt+0x9a/0xe0 net/core/sock.c:3039
> __sys_setsockopt+0x1bd/0x390 net/socket.c:1903
> __do_sys_setsockopt net/socket.c:1914 [inline]
> __se_sys_setsockopt net/socket.c:1911 [inline]
> __x64_sys_setsockopt+0xbe/0x150 net/socket.c:1911
> do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Fixes: 8fb472c09b9d ("ipmr: improve hash scalability")
> Fixes: 0bbbf0e7d0e7 ("ipmr, ip6mr: Unite creation of new mr_table")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> Cc: Yuval Mintz <yuvalm@mellanox.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
> ---
> net/ipv4/ipmr_base.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
Oops :). Thanks!
Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
^ permalink raw reply
* Re: [PATCH net-next v13 3/7] sch_cake: Add optional ACK filter
From: Eric Dumazet @ 2018-05-21 18:17 UTC (permalink / raw)
To: Eric Dumazet, Toke Høiland-Jørgensen, Networking, cake,
Yuchung Cheng, Neal Cardwell
In-Reply-To: <cc55420f-e5c4-c699-7af9-ff273487ef18@gmail.com>
On 05/21/2018 11:08 AM, Eric Dumazet wrote:
>
>
> On 05/21/2018 10:35 AM, Toke Høiland-Jørgensen wrote:
>
>> Ah yes, sequence number wrapping. I was thinking I needed to deal with
>> that, and then got sidetracked and forgot about it. Will fix.
>>
>> Other than that, do you agree that this approach to SACK and header
>> handling can work?
>
> Unfortunately this does not handle dsack (RFC 2883, and 3708) properly, I believe.
>
Since I will be traveling for the next ~10 days, with possibly no Internet access,
or time to review patches, please CC other Google TCP experts for the next versions.
Thanks.
^ permalink raw reply
* RE: [PATCH v2] packet: track ring entry use using a shadow ring to prevent RX ring overrun
From: Jon Rosen (jrosen) @ 2018-05-21 18:16 UTC (permalink / raw)
To: Willem de Bruijn
Cc: David S. Miller, Willem de Bruijn, Eric Dumazet, Kees Cook,
David Windsor, Rosen, Rami, Reshetova, Elena, Mike Maloney,
Benjamin Poirier, Thomas Gleixner, Greg Kroah-Hartman,
open list:NETWORKING [GENERAL], open list
In-Reply-To: <CAF=yD-Kfto4jJYMFzn=PV8OYdhEmdNfW+aakDhRMzRBWhWY0UQ@mail.gmail.com>
On Monday, May 21, 2018 1:07 PM, Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>On Mon, May 21, 2018 at 8:57 AM, Jon Rosen (jrosen) <jrosen@cisco.com> wrote:
>> On Sunday, May 20, 2018 7:22 PM, Willem de Bruijn
>> <willemdebruijn.kernel@gmail.com> wrote:
>>> On Sun, May 20, 2018 at 6:51 PM, Willem de Bruijn
>>> <willemdebruijn.kernel@gmail.com> wrote:
>>>> On Sat, May 19, 2018 at 8:07 AM, Jon Rosen <jrosen@cisco.com> wrote:
>>>>> Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which
>>>>> casues the ring to get corrupted by allowing multiple kernel threads
>>>>> to claim ownership of the same ring entry. Track ownership in a shadow
>>>>> ring structure to prevent other kernel threads from reusing the same
>>>>> entry before it's fully filled in, passed to user space, and then
>>>>> eventually passed back to the kernel for use with a new packet.
>>>>>
>>>>> Signed-off-by: Jon Rosen <jrosen@cisco.com>
>>>>> ---
>>>>>
>>>>> There is a bug in net/packet/af_packet.c:tpacket_rcv in how it manages
>>>>> the PACKET_RX_RING for versions TPACKET_V1 and TPACKET_V2. This bug makes
>>>>> it possible for multiple kernel threads to claim ownership of the same
>>>>> ring entry, corrupting the ring and the corresponding packet(s).
>>>>>
>>>>> These diffs are the second proposed solution, previous proposal was described
>>>>> in https://www.mail-archive.com/netdev@vger.kernel.org/msg227468.html
>>>>> subject [RFC PATCH] packet: mark ring entry as in-use inside spin_lock
>>>>> to prevent RX ring overrun
>>>>>
>>>>> Those diffs would have changed the binary interface and have broken certain
>>>>> applications. Consensus was that such a change would be inappropriate.
>>>>>
>>>>> These new diffs use a shadow ring in kernel space for tracking intermediate
>>>>> state of an entry and prevent more than one kernel thread from simultaneously
>>>>> allocating a ring entry. This avoids any impact to the binary interface
>>>>> between kernel and userspace but comes at the additional cost of requiring a
>>>>> second spin_lock when passing ownership of a ring entry to userspace.
>>>>>
>>>>> Jon Rosen (1):
>>>>> packet: track ring entry use using a shadow ring to prevent RX ring
>>>>> overrun
>>>>>
>>>>> net/packet/af_packet.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>> net/packet/internal.h | 14 +++++++++++
>>>>> 2 files changed, 78 insertions(+)
>>>>>
>>>>
>>>>> @@ -2383,7 +2412,11 @@ static int tpacket_rcv(struct sk_buff *skb, struct net_device *dev,
>>>>> #endif
>>>>>
>>>>> if (po->tp_version <= TPACKET_V2) {
>>>>> + spin_lock(&sk->sk_receive_queue.lock);
>>>>> __packet_set_status(po, h.raw, status);
>>>>> + packet_rx_shadow_release(rx_shadow_ring_entry);
>>>>> + spin_unlock(&sk->sk_receive_queue.lock);
>>>>> +
>>>>> sk->sk_data_ready(sk);
>>>>
>>>> Thanks for continuing to look at this. I spent some time on it last time
>>>> around but got stuck, too.
>>>>
>>>> This version takes an extra spinlock in the hot path. That will be very
>>>> expensive. Once we need to accept that, we could opt for a simpler
>>>> implementation akin to the one discussed in the previous thread:
>>>>
>>>> stash a value in tp_padding or similar while tp_status remains
>>>> TP_STATUS_KERNEL to signal ownership to concurrent kernel
>>>> threads. The issue previously was that that field could not atomically
>>>> be cleared together with __packet_set_status. This is no longer
>>>> an issue when holding the queue lock.
>>>>
>>>> With a field like tp_padding, unlike tp_len, it is arguably also safe to
>>>> clear it after flipping status (userspace should treat it as undefined).
>>>>
>>>> With v1 tpacket_hdr, no explicit padding field is defined but due to
>>>> TPACKET_HDRLEN alignment it exists on both 32 and 64 bit
>>>> platforms.
>>>>
>>>> The danger with using padding is that a process may write to it
>>>> and cause deadlock, of course. There is no logical reason for doing
>>>> so.
>>>
>>> For the ring, there is no requirement to allocate exactly the amount
>>> specified by the user request. Safer than relying on shared memory
>>> and simpler than the extra allocation in this patch would be to allocate
>>> extra shadow memory at the end of the ring (and not mmap that).
>>>
>>> That still leaves an extra cold cacheline vs using tp_padding.
>>
>> Given my lack of experience and knowledge in writing kernel code
>> it was easier for me to allocate the shadow ring as a separate
>> structure. Of course it's not about me and my skills so if it's
>> more appropriate to allocate at the tail of the existing ring
>> then certainly I can look at doing that.
>>
>> I think the bigger issues as you've pointed out are the cost of
>> the additional spin lock and should the additional state be
>> stored in-band (fewer cache lines) or out-of band (less risk of
>> breaking due to unpredictable application behavior).
>
> We don't need the spinlock if clearing the shadow byte after
> setting the status to user.
>
> Worst case, user will set it back to kernel while the shadow
> byte is not cleared yet and the next producer will drop a packet.
> But next producers will make progress, so there is no deadlock
> or corruption.
I thought so too for a while but after spending more time than I
care to admit I relized the following sequence was occuring:
Core A Core B
------ ------
- Enter spin_lock
- Get tp_status of head (X)
tp_status == 0
- Check inuse
inuse == 0
- Allocate entry X
advance head (X+1)
set inuse=1
- Exit spin_lock
<very long delay>
<allocate N-1 entries
where N = size of ring>
- Enter spin_lock
- get tp_status of head (X+N)
tp_status == 0 (but slot
in use for X on core A)
- write tp_status of <--- trouble!
X = TP_STATUS_USER <--- trouble!
- write inuse=0 <--- trouble!
- Check inuse
inuse == 0
- Allocate entry X+N
advance head (X+N+1)
set inuse=1
- Exit spin_lock
At this point Core A just passed slot X to userspace with a
packet and Core B has just been assigned slot X+N (same slot as
X) for it's new packet. Both cores A and B end up filling in that
slot. Tracking ths donw was one of the reasons it took me a
while to produce these updated diffs.
>
> It probably does require a shadow structure as opposed to a
> padding byte to work with the long tail of (possibly broken)
> applications, sadly.
I agree.
>
> A setsockopt for userspace to signal a stricter interpretation of
> tp_status to elide the shadow hack could then be considered.
> It's not pretty. Either way, no full new version is required.
>
>> As much as I would like to find a solution that doesn't require
>> the spin lock I have yet to do so. Maybe the answer is that
>> existing applications will need to suffer the performance impact
>> but a new version or option for TPACKET_V1/V2 could be added to
>> indicate strict adherence of the TP_STATUS_USER bit and then the
>> original diffs could be used.
>>
>> There is another option I was considering but have yet to try
>> which would avoid needing a shadow ring by using counter(s) to
>> track maximum sequence number queued to userspace vs. the next
>> sequence number to be allocated in the ring. If the difference
>> is greater than the size of the ring then the ring can be
>> considered full and the allocation would fail. Of course this may
>> create an additional hotspot between cores, not sure if that
>> would be significant or not.
>
> Please do have a look, but I don't think that this will work in this
> case in practice. It requires tracking the producer tail. Updating
> the slowest writer requires probing each subsequent slot's status
> byte to find the new tail, which is a lot of (by then cold) cacheline
> reads.
I've thought about it a little more and am not convinced it's
workable but I'll spend a little more time on it before giving
up.
^ permalink raw reply
* Re: INFO: rcu detected stall in corrupted
From: David Ahern @ 2018-05-21 18:15 UTC (permalink / raw)
To: Eric Dumazet, David Miller, syzbot+f116bc1994efe725d51b
Cc: kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji, dsahern,
roopa
In-Reply-To: <f8d0d282-1e75-d86a-8872-e32b57a6ec14@gmail.com>
On 5/21/18 12:13 PM, Eric Dumazet wrote:
>
>
> On 05/21/2018 11:09 AM, David Miller wrote:
>> From: syzbot <syzbot+f116bc1994efe725d51b@syzkaller.appspotmail.com>
>> Date: Mon, 21 May 2018 11:05:02 -0700
>>
>>> find_match+0x244/0x13a0 net/ipv6/route.c:691
>>> find_rr_leaf net/ipv6/route.c:729 [inline]
>>> rt6_select net/ipv6/route.c:779 [inline]
>>
>> Hmmm, endless loop in find_rr_leaf or similar?
>>
>
>
> I do not think so, this really looks like SCTP specific
> , we now have dozens of traces all sharing :
>
> sctp_transport_route+0xad/0x450 net/sctp/transport.c:293
> sctp_packet_config+0xb89/0xfd0 net/sctp/output.c:123
> sctp_outq_flush+0x79c/0x4370 net/sctp/outqueue.c:894
> sctp_outq_uncork+0x6a/0x80 net/sctp/outqueue.c:776
> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1820 [inline]
> sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> sctp_do_sm+0x596/0x7160 net/sctp/sm_sideeffect.c:1191
> sctp_generate_heartbeat_event+0x218/0x450 net/sctp/sm_sideeffect.c:406
> call_timer_fn+0x230/0x940 kernel/time/timer.c:1326
>
>
> Some kind of infinite loop.
>
> When the hrtimer fires, it can point to any code that sits below but does not necessarily have a bug.
>
Just so we are looking at the right tree, the original message shows:
> HEAD commit: 771c577c23ba Linux 4.17-rc6
> git tree: upstream
I take that to mean this is Linus' tree.
^ permalink raw reply
* Re: INFO: rcu detected stall in corrupted
From: Eric Dumazet @ 2018-05-21 18:13 UTC (permalink / raw)
To: David Miller, syzbot+f116bc1994efe725d51b
Cc: kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji, dsahern,
roopa
In-Reply-To: <20180521.140924.2255125685012645769.davem@davemloft.net>
On 05/21/2018 11:09 AM, David Miller wrote:
> From: syzbot <syzbot+f116bc1994efe725d51b@syzkaller.appspotmail.com>
> Date: Mon, 21 May 2018 11:05:02 -0700
>
>> find_match+0x244/0x13a0 net/ipv6/route.c:691
>> find_rr_leaf net/ipv6/route.c:729 [inline]
>> rt6_select net/ipv6/route.c:779 [inline]
>
> Hmmm, endless loop in find_rr_leaf or similar?
>
I do not think so, this really looks like SCTP specific
, we now have dozens of traces all sharing :
sctp_transport_route+0xad/0x450 net/sctp/transport.c:293
sctp_packet_config+0xb89/0xfd0 net/sctp/output.c:123
sctp_outq_flush+0x79c/0x4370 net/sctp/outqueue.c:894
sctp_outq_uncork+0x6a/0x80 net/sctp/outqueue.c:776
sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1820 [inline]
sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
sctp_do_sm+0x596/0x7160 net/sctp/sm_sideeffect.c:1191
sctp_generate_heartbeat_event+0x218/0x450 net/sctp/sm_sideeffect.c:406
call_timer_fn+0x230/0x940 kernel/time/timer.c:1326
Some kind of infinite loop.
When the hrtimer fires, it can point to any code that sits below but does not necessarily have a bug.
^ permalink raw reply
* Re: INFO: rcu detected stall in corrupted
From: David Miller @ 2018-05-21 18:09 UTC (permalink / raw)
To: syzbot+f116bc1994efe725d51b
Cc: kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji, dsahern,
roopa
In-Reply-To: <00000000000007eb20056cbb245f@google.com>
From: syzbot <syzbot+f116bc1994efe725d51b@syzkaller.appspotmail.com>
Date: Mon, 21 May 2018 11:05:02 -0700
> find_match+0x244/0x13a0 net/ipv6/route.c:691
> find_rr_leaf net/ipv6/route.c:729 [inline]
> rt6_select net/ipv6/route.c:779 [inline]
Hmmm, endless loop in find_rr_leaf or similar?
^ permalink raw reply
* Re: [PATCH net-next v13 3/7] sch_cake: Add optional ACK filter
From: Eric Dumazet @ 2018-05-21 18:08 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, Eric Dumazet, netdev, cake
In-Reply-To: <87r2m4ykrc.fsf@toke.dk>
On 05/21/2018 10:35 AM, Toke Høiland-Jørgensen wrote:
> Ah yes, sequence number wrapping. I was thinking I needed to deal with
> that, and then got sidetracked and forgot about it. Will fix.
>
> Other than that, do you agree that this approach to SACK and header
> handling can work?
Unfortunately this does not handle dsack (RFC 2883, and 3708) properly, I believe.
^ permalink raw reply
* INFO: rcu detected stall in corrupted
From: syzbot @ 2018-05-21 18:05 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 771c577c23ba Linux 4.17-rc6
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17134357800000
kernel config: https://syzkaller.appspot.com/x/.config?x=982e2df1b9e60b02
dashboard link: https://syzkaller.appspot.com/bug?extid=f116bc1994efe725d51b
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
userspace arch: i386
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=14e5a7cf800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+f116bc1994efe725d51b@syzkaller.appspotmail.com
IPv6: ADDRCONF(NETDEV_UP): veth1: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
INFO: rcu_sched self-detected stall on CPU
INFO: rcu_sched detected stalls on CPUs/tasks:
0-...!: (124975 ticks this GP) idle=a36/1/4611686018427387906
softirq=14002/14002 fqs=10
0-...!: (124975 ticks this GP) idle=a36/1/4611686018427387906
softirq=14002/14002 fqs=10
(t=125002 jiffies g=7347 c=7346 q=349000)
(detected by 1, t=125002 jiffies, g=7347, c=7346, q=349000)
rcu_sched kthread starved for 124927 jiffies! g7347 c7346 f0x2
RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=1
Sending NMI from CPU 1 to CPUs 0:
RCU grace-period kthread stack dump:
NMI backtrace for cpu 0
CPU: 0 PID: 8 Comm: ksoftirqd/0 Not tainted 4.17.0-rc6+ #86
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:get_current arch/x86/include/asm/current.h:15 [inline]
RIP: 0010:write_comp_data+0xa/0x70 kernel/kcov.c:121
RSP: 0018:ffff8801dae06d30 EFLAGS: 00000006
RAX: 0000000000010105 RBX: 0000000000000006 RCX: ffffffff876bdc58
RDX: 0000000000000000 RSI: 0000000000000005 RDI: 0000000000000001
RBP: ffff8801dae06d68 R08: ffff8801d9a9c200 R09: fffffbfff14da4bc
R10: fffffbfff14da4bc R11: ffffffff8a6d25e0 R12: ffffffff88644220
R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000008
FS: 0000000000000000(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f595e194270 CR3: 00000001b09c2000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<IRQ>
vsnprintf+0x1b8/0x1b40 lib/vsprintf.c:2252
sprintf+0xa7/0xd0 lib/vsprintf.c:2498
print_time kernel/printk/printk.c:1223 [inline]
print_prefix+0x26a/0x3f0 kernel/printk/printk.c:1246
msg_print_text+0xca/0x1c0 kernel/printk/printk.c:1273
console_unlock+0x4f5/0x1100 kernel/printk/printk.c:2369
vprintk_emit+0x6ad/0xdd0 kernel/printk/printk.c:1907
vprintk_default+0x28/0x30 kernel/printk/printk.c:1947
vprintk_func+0x7a/0xe7 kernel/printk/printk_safe.c:379
printk+0x9e/0xba kernel/printk/printk.c:1980
rcu_check_gp_kthread_starvation+0x325/0x3a4 kernel/rcu/tree.c:1353
print_cpu_stall kernel/rcu/tree.c:1523 [inline]
check_cpu_stall.isra.61.cold.80+0x364/0x59a kernel/rcu/tree.c:1593
__rcu_pending kernel/rcu/tree.c:3356 [inline]
rcu_pending kernel/rcu/tree.c:3401 [inline]
rcu_check_callbacks+0x21b/0xad0 kernel/rcu/tree.c:2763
update_process_times+0x2d/0x70 kernel/time/timer.c:1636
tick_sched_handle+0x9f/0x180 kernel/time/tick-sched.c:164
tick_sched_timer+0x45/0x130 kernel/time/tick-sched.c:1274
__run_hrtimer kernel/time/hrtimer.c:1398 [inline]
__hrtimer_run_queues+0x3e3/0x10a0 kernel/time/hrtimer.c:1460
hrtimer_interrupt+0x2f3/0x750 kernel/time/hrtimer.c:1518
local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
smp_apic_timer_interrupt+0x15d/0x710 arch/x86/kernel/apic/apic.c:1050
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
</IRQ>
RIP: 0010:__sanitizer_cov_trace_pc+0x1/0x50 kernel/kcov.c:94
RSP: 0018:ffff8801d9aad680 EFLAGS: 00000293 ORIG_RAX: ffffffffffffff13
RAX: 0000000000000103 RBX: 0000000000000002 RCX: ffffffff867e02e0
RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000005
RBP: ffff8801d9aad7e0 R08: ffff8801d9a9c200 R09: ffff8801d9aadaf0
R10: ffffed003b5c46c2 R11: ffff8801dae23613 R12: ffff8801ce597c40
R13: 0000000000000000 R14: 0000000000000002 R15: 0000000000000000
find_match+0x244/0x13a0 net/ipv6/route.c:691
find_rr_leaf net/ipv6/route.c:729 [inline]
rt6_select net/ipv6/route.c:779 [inline]
ip6_pol_route+0x946/0x3d40 net/ipv6/route.c:1705
ip6_pol_route_output+0x54/0x70 net/ipv6/route.c:1969
fib6_rule_lookup+0x211/0x6d0 net/ipv6/fib6_rules.c:89
ip6_route_output_flags+0x2c5/0x350 net/ipv6/route.c:1997
ip6_dst_lookup_tail+0x47b/0x1b30 net/ipv6/ip6_output.c:995
ip6_dst_lookup_flow+0xc1/0x260 net/ipv6/ip6_output.c:1096
sctp_v6_get_dst+0x16b4/0x20b0 net/sctp/ipv6.c:327
sctp_transport_route+0xad/0x450 net/sctp/transport.c:293
sctp_packet_config+0xb89/0xfd0 net/sctp/output.c:123
sctp_outq_flush+0x79c/0x4370 net/sctp/outqueue.c:894
? trace_hardirqs_off
Lost 148 message(s)!
rcu_sched kthread starved for 124927 jiffies! g7347 c7346 f0x2
RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=1
rcu_sched R
RCU grace-period kthread stack dump:
rcu_sched R
running task
running task 23896 9 2 0x80000000
23896 9 2 0x80000000
Call Trace:
Call Trace:
context_switch kernel/sched/core.c:2859 [inline]
__schedule+0x801/0x1e30 kernel/sched/core.c:3501
context_switch kernel/sched/core.c:2859 [inline]
__schedule+0x801/0x1e30 kernel/sched/core.c:3501
schedule+0xef/0x430 kernel/sched/core.c:3545
schedule+0xef/0x430 kernel/sched/core.c:3545
schedule_timeout+0x138/0x240 kernel/time/timer.c:1801
schedule_timeout+0x138/0x240 kernel/time/timer.c:1801
rcu_gp_kthread+0x6b5/0x1940 kernel/rcu/tree.c:2231
rcu_gp_kthread+0x6b5/0x1940 kernel/rcu/tree.c:2231
kthread+0x345/0x410 kernel/kthread.c:240
kthread+0x345/0x410 kernel/kthread.c:240
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
NMI backtrace for cpu 0
CPU: 0 PID: 8 Comm: ksoftirqd/0 Not tainted 4.17.0-rc6+ #86
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103
nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62
arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline]
rcu_dump_cpu_stacks+0x175/0x1c2 kernel/rcu/tree.c:1376
print_cpu_stall kernel/rcu/tree.c:1525 [inline]
check_cpu_stall.isra.61.cold.80+0x36c/0x59a kernel/rcu/tree.c:1593
__rcu_pending kernel/rcu/tree.c:3356 [inline]
rcu_pending kernel/rcu/tree.c:3401 [inline]
rcu_check_callbacks+0x21b/0xad0 kernel/rcu/tree.c:2763
update_process_times+0x2d/0x70 kernel/time/timer.c:1636
tick_sched_handle+0x9f/0x180 kernel/time/tick-sched.c:164
tick_sched_timer+0x45/0x130 kernel/time/tick-sched.c:1274
__run_hrtimer kernel/time/hrtimer.c:1398 [inline]
__hrtimer_run_queues+0x3e3/0x10a0 kernel/time/hrtimer.c:1460
hrtimer_interrupt+0x2f3/0x750 kernel/time/hrtimer.c:1518
local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
smp_apic_timer_interrupt+0x15d/0x710 arch/x86/kernel/apic/apic.c:1050
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
</IRQ>
RIP: 0010:__sanitizer_cov_trace_pc+0x1/0x50 kernel/kcov.c:94
RSP: 0018:ffff8801d9aad680 EFLAGS: 00000293 ORIG_RAX: ffffffffffffff13
RAX: 0000000000000103 RBX: 0000000000000002 RCX: ffffffff867e02e0
RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000005
RBP: ffff8801d9aad7e0 R08: ffff8801d9a9c200 R09: ffff8801d9aadaf0
R10: ffffed003b5c46c2 R11: ffff8801dae23613 R12: ffff8801ce597c40
R13: 0000000000000000 R14: 0000000000000002 R15: 0000000000000000
find_match+0x244/0x13a0 net/ipv6/route.c:691
find_rr_leaf net/ipv6/route.c:729 [inline]
rt6_select net/ipv6/route.c:779 [inline]
ip6_pol_route+0x946/0x3d40 net/ipv6/route.c:1705
ip6_pol_route_output+0x54/0x70 net/ipv6/route.c:1969
fib6_rule_lookup+0x211/0x6d0 net/ipv6/fib6_rules.c:89
ip6_route_output_flags+0x2c5/0x350 net/ipv6/route.c:1997
ip6_dst_lookup_tail+0x47b/0x1b30 net/ipv6/ip6_output.c:995
ip6_dst_lookup_flow+0xc1/0x260 net/ipv6/ip6_output.c:1096
sctp_v6_get_dst+0x16b4/0x20b0 net/sctp/ipv6.c:327
sctp_transport_route+0xad/0x450 net/sctp/transport.c:293
sctp_packet_config+0xb89/0xfd0 net/sctp/output.c:123
sctp_outq_flush+0x79c/0x4370 net/sctp/outqueue.c:894
sctp_outq_uncork+0x6a/0x80 net/sctp/outqueue.c:776
sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1820 [inline]
sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
sctp_do_sm+0x596/0x7160 net/sctp/sm_sideeffect.c:1191
sctp_generate_heartbeat_event+0x218/0x450 net/sctp/sm_sideeffect.c:406
call_timer_fn+0x230/0x940 kernel/time/timer.c:1326
expire_timers kernel/time/timer.c:1363 [inline]
__run_timers+0x79e/0xc50 kernel/time/timer.c:1666
run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692
__do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
run_ksoftirqd+0x86/0x100 kernel/softirq.c:646
smpboot_thread_fn+0x417/0x870 kernel/smpboot.c:164
kthread+0x345/0x410 kernel/kthread.c:240
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
INFO: NMI handler (nmi_cpu_backtrace_handler) took too long to run: 1.929
msecs
BUG: workqueue lockup - pool cpus=0-1 flags=0x4 nice=0 stuck for 127s!
Showing busy workqueues and worker pools:
workqueue events: flags=0x0
pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=10/256
pending: pcpu_balance_workfn, defense_work_handler,
defense_work_handler, defense_work_handler, defense_work_handler,
defense_work_handler, defense_work_handler, check_corruption,
vmstat_shepherd, cache_reap
workqueue events_power_efficient: flags=0x80
pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
pending: check_lifetime
workqueue mm_percpu_wq: flags=0x8
pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
pending: vmstat_update
workqueue writeback: flags=0x4e
pwq 4: cpus=0-1 flags=0x4 nice=0 active=4/256
pending: wb_workfn, wb_workfn, wb_workfn, wb_workfn
workqueue kblockd: flags=0x18
pwq 1: cpus=0 node=0 flags=0x0 nice=-20 active=1/256
pending: blk_mq_timeout_work
workqueue ib_addr: flags=0xa0002
pwq 4: cpus=0-1 flags=0x4 nice=0 active=1/1
pending: process_req
workqueue gid-cache-wq: flags=0xa0002
pwq 4: cpus=0-1 flags=0x4 nice=0 active=1/1
pending: update_gid_event_work_handler
delayed: netdevice_event_work_handler
workqueue ipv6_addrconf: flags=0x40008
pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/1
pending: addrconf_dad_work
delayed: addrconf_dad_work, addrconf_dad_work, addrconf_dad_work,
addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work,
addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work,
addrconf_dad_work, addrconf_dad_work, addrconf_dad_work, addrconf_dad_work,
addrconf_dad_work, addrconf_dad_work, addrconf_dad_work
---
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
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