* Re: [PATCH v2 bpf-next 03/10] bpf: introduce per-cpu cgroup local storage
From: Roman Gushchin @ 2018-09-26 8:42 UTC (permalink / raw)
To: Song Liu
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Kernel Team,
Daniel Borkmann, Alexei Starovoitov
In-Reply-To: <27B81458-17C5-4840-9679-D1F5FBF6E805@fb.com>
On Tue, Sep 25, 2018 at 11:54:33AM -0700, Song Liu wrote:
>
>
> > On Sep 25, 2018, at 8:21 AM, Roman Gushchin <guro@fb.com> wrote:
> >
> > This commit introduced per-cpu cgroup local storage.
> >
> > Per-cpu cgroup local storage is very similar to simple cgroup storage
> > (let's call it shared), except all the data is per-cpu.
> >
> > The main goal of per-cpu variant is to implement super fast
> > counters (e.g. packet counters), which don't require neither
> > lookups, neither atomic operations.
> >
> > From userspace's point of view, accessing a per-cpu cgroup storage
> > is similar to other per-cpu map types (e.g. per-cpu hashmaps and
> > arrays).
> >
> > Writing to a per-cpu cgroup storage is not atomic, but is performed
> > by copying longs, so some minimal atomicity is here, exactly
> > as with other per-cpu maps.
> >
> > Signed-off-by: Roman Gushchin <guro@fb.com>
> > Cc: Daniel Borkmann <daniel@iogearbox.net>
> > Cc: Alexei Starovoitov <ast@kernel.org>
> > ---
> > include/linux/bpf-cgroup.h | 20 ++++-
> > include/linux/bpf.h | 1 +
> > include/linux/bpf_types.h | 1 +
> > include/uapi/linux/bpf.h | 1 +
> > kernel/bpf/helpers.c | 8 +-
> > kernel/bpf/local_storage.c | 148 ++++++++++++++++++++++++++++++++-----
> > kernel/bpf/syscall.c | 11 ++-
> > kernel/bpf/verifier.c | 15 +++-
> > 8 files changed, 177 insertions(+), 28 deletions(-)
> >
> > diff --git a/include/linux/bpf-cgroup.h b/include/linux/bpf-cgroup.h
> > index 7e0c9a1d48b7..9bd907657f9b 100644
> > --- a/include/linux/bpf-cgroup.h
> > +++ b/include/linux/bpf-cgroup.h
> > @@ -37,7 +37,10 @@ struct bpf_storage_buffer {
> > };
> >
> > struct bpf_cgroup_storage {
> > - struct bpf_storage_buffer *buf;
> > + union {
> > + struct bpf_storage_buffer *buf;
> > + char __percpu *percpu_buf;
>
> "char *" here looks weird. Did you mean to use "void *"?
Fair enough. It's probably a leftover from (previously used) char[0].
>
> > + };
> > struct bpf_cgroup_storage_map *map;
> > struct bpf_cgroup_storage_key key;
> > struct list_head list;
> > @@ -109,6 +112,9 @@ int __cgroup_bpf_check_dev_permission(short dev_type, u32 major, u32 minor,
> > static inline enum bpf_cgroup_storage_type cgroup_storage_type(
> > struct bpf_map *map)
> > {
> > + if (map->map_type == BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE)
> > + return BPF_CGROUP_STORAGE_PERCPU;
> > +
> > return BPF_CGROUP_STORAGE_SHARED;
> > }
> >
> > @@ -131,6 +137,10 @@ void bpf_cgroup_storage_unlink(struct bpf_cgroup_storage *storage);
> > int bpf_cgroup_storage_assign(struct bpf_prog *prog, struct bpf_map *map);
> > void bpf_cgroup_storage_release(struct bpf_prog *prog, struct bpf_map *map);
> >
> > +int bpf_percpu_cgroup_storage_copy(struct bpf_map *map, void *key, void *value);
> > +int bpf_percpu_cgroup_storage_update(struct bpf_map *map, void *key,
> > + void *value, u64 flags);
> > +
> > /* Wrappers for __cgroup_bpf_run_filter_skb() guarded by cgroup_bpf_enabled. */
> > #define BPF_CGROUP_RUN_PROG_INET_INGRESS(sk, skb) \
> > ({ \
> > @@ -285,6 +295,14 @@ static inline struct bpf_cgroup_storage *bpf_cgroup_storage_alloc(
> > struct bpf_prog *prog, enum bpf_cgroup_storage_type stype) { return 0; }
> > static inline void bpf_cgroup_storage_free(
> > struct bpf_cgroup_storage *storage) {}
> > +static inline int bpf_percpu_cgroup_storage_copy(struct bpf_map *map, void *key,
> > + void *value) {
> > + return 0;
> > +}
> > +static inline int bpf_percpu_cgroup_storage_update(struct bpf_map *map,
> > + void *key, void *value, u64 flags) {
> > + return 0;
> > +}
> >
> > #define cgroup_bpf_enabled (0)
> > #define BPF_CGROUP_PRE_CONNECT_ENABLED(sk) (0)
> > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > index b457fbe7b70b..018299a595c8 100644
> > --- a/include/linux/bpf.h
> > +++ b/include/linux/bpf.h
> > @@ -274,6 +274,7 @@ struct bpf_prog_offload {
> >
> > enum bpf_cgroup_storage_type {
> > BPF_CGROUP_STORAGE_SHARED,
> > + BPF_CGROUP_STORAGE_PERCPU,
> > __BPF_CGROUP_STORAGE_MAX
> > };
> >
> > diff --git a/include/linux/bpf_types.h b/include/linux/bpf_types.h
> > index c9bd6fb765b0..5432f4c9f50e 100644
> > --- a/include/linux/bpf_types.h
> > +++ b/include/linux/bpf_types.h
> > @@ -43,6 +43,7 @@ BPF_MAP_TYPE(BPF_MAP_TYPE_CGROUP_ARRAY, cgroup_array_map_ops)
> > #endif
> > #ifdef CONFIG_CGROUP_BPF
> > BPF_MAP_TYPE(BPF_MAP_TYPE_CGROUP_STORAGE, cgroup_storage_map_ops)
> > +BPF_MAP_TYPE(BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE, cgroup_storage_map_ops)
> > #endif
> > BPF_MAP_TYPE(BPF_MAP_TYPE_HASH, htab_map_ops)
> > BPF_MAP_TYPE(BPF_MAP_TYPE_PERCPU_HASH, htab_percpu_map_ops)
> > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > index aa5ccd2385ed..e2070d819e04 100644
> > --- a/include/uapi/linux/bpf.h
> > +++ b/include/uapi/linux/bpf.h
> > @@ -127,6 +127,7 @@ enum bpf_map_type {
> > BPF_MAP_TYPE_SOCKHASH,
> > BPF_MAP_TYPE_CGROUP_STORAGE,
> > BPF_MAP_TYPE_REUSEPORT_SOCKARRAY,
> > + BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE,
> > };
> >
> > enum bpf_prog_type {
> > diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> > index e42f8789b7ea..1f21ef1c4ad3 100644
> > --- a/kernel/bpf/helpers.c
> > +++ b/kernel/bpf/helpers.c
> > @@ -206,10 +206,16 @@ BPF_CALL_2(bpf_get_local_storage, struct bpf_map *, map, u64, flags)
> > */
> > enum bpf_cgroup_storage_type stype = cgroup_storage_type(map);
> > struct bpf_cgroup_storage *storage;
> > + void *ptr = NULL;
>
> Not necessary to initialize to NULL.
Fixed.
>
> >
> > storage = this_cpu_read(bpf_cgroup_storage[stype]);
> >
> > - return (unsigned long)&READ_ONCE(storage->buf)->data[0];
> > + if (stype == BPF_CGROUP_STORAGE_SHARED)
> > + ptr = &READ_ONCE(storage->buf)->data[0];
> > + else
> > + ptr = this_cpu_ptr(storage->percpu_buf);
> > +
> > + return (unsigned long)ptr;
> > }
> >
> > const struct bpf_func_proto bpf_get_local_storage_proto = {
> > diff --git a/kernel/bpf/local_storage.c b/kernel/bpf/local_storage.c
> > index 6742292fb39e..d991355b5b46 100644
> > --- a/kernel/bpf/local_storage.c
> > +++ b/kernel/bpf/local_storage.c
> > @@ -152,6 +152,71 @@ static int cgroup_storage_update_elem(struct bpf_map *map, void *_key,
> > return 0;
> > }
> >
> > +int bpf_percpu_cgroup_storage_copy(struct bpf_map *_map, void *_key,
> > + void *value)
> > +{
> > + struct bpf_cgroup_storage_map *map = map_to_storage(_map);
> > + struct bpf_cgroup_storage_key *key = _key;
> > + struct bpf_cgroup_storage *storage;
> > + int cpu, off = 0;
> > + u32 size;
> > +
> > + rcu_read_lock();
> > + storage = cgroup_storage_lookup(map, key, false);
> > + if (!storage) {
> > + rcu_read_unlock();
> > + return -ENOENT;
> > + }
> > +
> > + /* per_cpu areas are zero-filled and bpf programs can only
> > + * access 'value_size' of them, so copying rounded areas
> > + * will not leak any kernel data
> > + */
> > + size = round_up(_map->value_size, 8);
> > + for_each_possible_cpu(cpu) {
> > + bpf_long_memcpy(value + off,
> > + per_cpu_ptr(storage->percpu_buf, cpu), size);
> > + off += size;
> > + }
> > + rcu_read_unlock();
> > + return 0;
> > +}
> > +
> > +int bpf_percpu_cgroup_storage_update(struct bpf_map *_map, void *_key,
> > + void *value, u64 map_flags)
> > +{
> > + struct bpf_cgroup_storage_map *map = map_to_storage(_map);
> > + struct bpf_cgroup_storage_key *key = _key;
> > + struct bpf_cgroup_storage *storage;
> > + int cpu, off = 0;
> > + u32 size;
> > +
> > + if (unlikely(map_flags & BPF_EXIST))
> > + return -EINVAL;
> > +
> > + rcu_read_lock();
> > + storage = cgroup_storage_lookup(map, key, false);
> > + if (!storage) {
> > + rcu_read_unlock();
> > + return -ENOENT;
> > + }
> > +
> > + /* the user space will provide round_up(value_size, 8) bytes that
> > + * will be copied into per-cpu area. bpf programs can only access
> > + * value_size of it. During lookup the same extra bytes will be
> > + * returned or zeros which were zero-filled by percpu_alloc,
> > + * so no kernel data leaks possible
> > + */
> > + size = round_up(_map->value_size, 8);
> > + for_each_possible_cpu(cpu) {
> > + bpf_long_memcpy(per_cpu_ptr(storage->percpu_buf, cpu),
> > + value + off, size);
> > + off += size;
> > + }
> > + rcu_read_unlock();
> > + return 0;
> > +}
> > +
> > static int cgroup_storage_get_next_key(struct bpf_map *_map, void *_key,
> > void *_next_key)
> > {
> > @@ -292,55 +357,98 @@ struct bpf_cgroup_storage *bpf_cgroup_storage_alloc(struct bpf_prog *prog,
> > {
> > struct bpf_cgroup_storage *storage;
> > struct bpf_map *map;
> > + gfp_t flags;
> > + size_t size;
> > u32 pages;
> >
> > map = prog->aux->cgroup_storage[stype];
> > if (!map)
> > return NULL;
> >
> > - pages = round_up(sizeof(struct bpf_cgroup_storage) +
> > - sizeof(struct bpf_storage_buffer) +
> > - map->value_size, PAGE_SIZE) >> PAGE_SHIFT;
> > + if (stype == BPF_CGROUP_STORAGE_SHARED) {
> > + size = sizeof(struct bpf_storage_buffer) + map->value_size;
> > + pages = round_up(sizeof(struct bpf_cgroup_storage) + size,
> > + PAGE_SIZE) >> PAGE_SHIFT;
> > + } else {
> > + size = map->value_size;
> > + pages = round_up(round_up(size, 8) * num_possible_cpus(),
> > + PAGE_SIZE) >> PAGE_SHIFT;
> > + }
> > +
> > if (bpf_map_charge_memlock(map, pages))
> > return ERR_PTR(-EPERM);
> >
> > storage = kmalloc_node(sizeof(struct bpf_cgroup_storage),
> > __GFP_ZERO | GFP_USER, map->numa_node);
> > - if (!storage) {
> > - bpf_map_uncharge_memlock(map, pages);
> > - return ERR_PTR(-ENOMEM);
> > - }
> > + if (!storage)
> > + goto enomem;
> >
> > - storage->buf = kmalloc_node(sizeof(struct bpf_storage_buffer) +
> > - map->value_size, __GFP_ZERO | GFP_USER,
> > - map->numa_node);
> > - if (!storage->buf) {
> > - bpf_map_uncharge_memlock(map, pages);
> > - kfree(storage);
> > - return ERR_PTR(-ENOMEM);
> > + flags = __GFP_ZERO | GFP_USER;
> > +
> > + if (stype == BPF_CGROUP_STORAGE_SHARED) {
> > + storage->buf = kmalloc_node(size, flags, map->numa_node);
> > + if (!storage->buf)
> > + goto enomem;
> > + } else {
> > + storage->percpu_buf = __alloc_percpu_gfp(size, 8, flags);
> > + if (!storage->percpu_buf)
> > + goto enomem;
> > }
> >
> > storage->map = (struct bpf_cgroup_storage_map *)map;
> >
> > return storage;
> > +
> > +enomem:
> > + bpf_map_uncharge_memlock(map, pages);
> > + kfree(storage);
> > + return ERR_PTR(-ENOMEM);
> > +}
> > +
> > +static void free_cgroup_storage_rcu(struct rcu_head *rcu)
>
> Maybe rename as free_shared_cgroup_storage_rcu()?
Yeah, might be more clear.
Thank you for the review!
Will send v3 with these changes and your acks soon.
Thanks!
^ permalink raw reply
* Re: [PATCH net RFT] bnxt_en: Fix TX timeout during netpoll.
From: Eric Dumazet @ 2018-09-26 2:25 UTC (permalink / raw)
To: Michael Chan; +Cc: Eric Dumazet, Song Liu, David Miller, netdev
In-Reply-To: <CACKFLimKTzseP34wyZ+SyASG6-2Zn=KF611PY=LO23pJLq4nNg@mail.gmail.com>
On Tue, Sep 25, 2018 at 7:15 PM Michael Chan <michael.chan@broadcom.com> wrote:
>
> On Tue, Sep 25, 2018 at 4:11 PM Michael Chan <michael.chan@broadcom.com> wrote:
> >
> > On Tue, Sep 25, 2018 at 3:15 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > >
> > > It seems bnx2 should have a similar issue ?
> > >
> >
> > Yes, I think so. The MSIX mode in bnx2 is also auto-masking, meaning
> > that MSIX will only assert once after it is ARMed. If we return from
> > ->poll() when budget of 0 is reached without ARMing, we may not get
> > another MSIX.
> >
>
> On second thought, I think bnx2 is ok. If netpoll is polling on the
> TX packets and reaching budget of 0 and returning, the INT_ACK_CMD
> register is untouched. bnx2 uses the status block for events and the
> producers/consumers are cumulative. So there is no need to ACK the
> status block unless ARMing for interrupts. If there is an IRQ about
> to be fired, it won't be affected by the polling done by netpoll.
>
> In the case of bnxt, a completion ring is used for the events. The
> polling done by netpoll will cause the completion ring to be ACKed as
> entries are processed. ACKing the completion ring without ARMing may
> cause future IRQs to be disabled for that ring.
About bnxt : Are you sure it is all about IRQ problems ?
What if the whole ring buffer is is filled, then all entries
are processed from netpoll.
If cp_raw_cons becomes too high without the NIC knowing its (updated)
value, maybe no IRQ can be generated anymore because
of some wrapping issue (based on ring size)
I guess that in order to test this, we would need something bursting
16000 messages while holding napi->poll_owner.
The (single) IRQ would set/grab the SCHED bit but the cpu responsible
to service this (soft)irq would spin for the whole test,
and no more IRQ should be fired really.
^ permalink raw reply
* Re: [PATCH net RFT] bnxt_en: Fix TX timeout during netpoll.
From: Michael Chan @ 2018-09-26 2:14 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Song Liu, Eric Dumazet, David Miller, Netdev
In-Reply-To: <CACKFLik_gNs2MOfKSFARMxqKRJ2UCJ6KgbJ+wSgu6wRvDN3saQ@mail.gmail.com>
On Tue, Sep 25, 2018 at 4:11 PM Michael Chan <michael.chan@broadcom.com> wrote:
>
> On Tue, Sep 25, 2018 at 3:15 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> >
> > It seems bnx2 should have a similar issue ?
> >
>
> Yes, I think so. The MSIX mode in bnx2 is also auto-masking, meaning
> that MSIX will only assert once after it is ARMed. If we return from
> ->poll() when budget of 0 is reached without ARMing, we may not get
> another MSIX.
>
On second thought, I think bnx2 is ok. If netpoll is polling on the
TX packets and reaching budget of 0 and returning, the INT_ACK_CMD
register is untouched. bnx2 uses the status block for events and the
producers/consumers are cumulative. So there is no need to ACK the
status block unless ARMing for interrupts. If there is an IRQ about
to be fired, it won't be affected by the polling done by netpoll.
In the case of bnxt, a completion ring is used for the events. The
polling done by netpoll will cause the completion ring to be ACKed as
entries are processed. ACKing the completion ring without ARMing may
cause future IRQs to be disabled for that ring.
^ permalink raw reply
* RE: [PATCH net-next] tls: Fix socket mem accounting error under async encryption
From: Vakul Garg @ 2018-09-26 1:54 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, borisp@mellanox.com, aviadye@mellanox.com,
davejwatson@fb.com, doronrk@fb.com
In-Reply-To: <20180925.104416.341573509848387687.davem@davemloft.net>
> -----Original Message-----
> From: David Miller <davem@davemloft.net>
> Sent: Tuesday, September 25, 2018 11:14 PM
> To: Vakul Garg <vakul.garg@nxp.com>
> Cc: netdev@vger.kernel.org; borisp@mellanox.com;
> aviadye@mellanox.com; davejwatson@fb.com; doronrk@fb.com
> Subject: Re: [PATCH net-next] tls: Fix socket mem accounting error under
> async encryption
>
> From: Vakul Garg <vakul.garg@nxp.com>
> Date: Tue, 25 Sep 2018 16:26:17 +0530
>
> > Current async encryption implementation sometimes showed up socket
> > memory accounting error during socket close. This results in kernel
> > warning calltrace. The root cause of the problem is that socket var
> > sk_forward_alloc gets corrupted due to access in sk_mem_charge() and
> > sk_mem_uncharge() being invoked from multiple concurrent contexts in
> > multicore processor. The apis sk_mem_charge() and sk_mem_uncharge()
> > are called from functions alloc_plaintext_sg(), free_sg() etc. It is
> > required that memory accounting apis are called under a socket lock.
> >
> > The plaintext sg data sent for encryption is freed using free_sg() in
> > tls_encryption_done(). It is wrong to call free_sg() from this function.
> > This is because this function may run in irq context. We cannot
> > acquire socket lock in this function.
> >
> > We remove calling of function free_sg() for plaintext data from
> > tls_encryption_done() and defer freeing up of plaintext data to the
> > time when the record is picked up from tx_list and transmitted/freed.
> > When
> > tls_tx_records() gets called, socket is already locked and thus there
> > is no concurrent access problem.
> >
> > Fixes: a42055e8d2c3 ("net/tls: Add support for async encryption")
> > Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
>
> Applied.
I don't find this patch and one other ("tls: Fixed a memory leak during socket close")
in linux-net-next. Could you please kindly check? Regards.
^ permalink raw reply
* KASAN: global-out-of-bounds Read in __aa_lookupn_ns
From: syzbot @ 2018-09-26 7:54 UTC (permalink / raw)
To: davem, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 02214bfc89c7 Merge tag 'media/v4.19-2' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1456f8a1400000
kernel config: https://syzkaller.appspot.com/x/.config?x=22a62640793a83c9
dashboard link: https://syzkaller.appspot.com/bug?extid=71b6643475f707f93fdc
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+71b6643475f707f93fdc@syzkaller.appspotmail.com
sock_common_setsockopt+0x9a/0xe0 net/core/sock.c:3038
__sys_setsockopt+0x1ba/0x3c0 net/socket.c:1902
__do_sys_setsockopt net/socket.c:1913 [inline]
__se_sys_setsockopt net/socket.c:1910 [inline]
__x64_sys_setsockopt+0xbe/0x150 net/socket.c:1910
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
==================================================================
BUG: KASAN: global-out-of-bounds in memcmp+0xe3/0x160 lib/string.c:861
Read of size 1 at addr ffffffff88000008 by task syz-executor0/10914
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457579
Code: 1d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 eb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f4c14533c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00007f4c14533c90 RCX: 0000000000457579
RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 000000000072bf00 R08: 0000000000000004 R09: 0000000000000000
R10: 0000000020000080 R11: 0000000000000246 R12: 00007f4c145346d4
R13: 00000000004c3ed9 R14: 00000000004d6260 R15: 0000000000000004
CPU: 0 PID: 10914 Comm: syz-executor0 Not tainted 4.19.0-rc5+ #252
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+0x1c4/0x2b4 lib/dump_stack.c:113
print_address_description.cold.8+0x58/0x1ff mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
__asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430
memcmp+0xe3/0x160 lib/string.c:861
strnstr+0x4b/0x70 lib/string.c:934
__aa_lookupn_ns+0xc1/0x570 security/apparmor/policy_ns.c:209
aa_lookupn_ns+0x88/0x1e0 security/apparmor/policy_ns.c:240
aa_fqlookupn_profile+0x1b9/0x1010 security/apparmor/policy.c:468
fqlookupn_profile+0x80/0xc0 security/apparmor/label.c:1844
aa_label_strn_parse+0xa3a/0x1230 security/apparmor/label.c:1908
aa_label_parse+0x42/0x50 security/apparmor/label.c:1943
aa_change_profile+0x513/0x3510 security/apparmor/domain.c:1362
apparmor_setprocattr+0xa8b/0x1150 security/apparmor/lsm.c:656
security_setprocattr+0x66/0xc0 security/security.c:1298
proc_pid_attr_write+0x301/0x540 fs/proc/base.c:2555
__vfs_write+0x119/0x9f0 fs/read_write.c:485
vfs_write+0x1fc/0x560 fs/read_write.c:549
ksys_write+0x101/0x260 fs/read_write.c:598
__do_sys_write fs/read_write.c:610 [inline]
__se_sys_write fs/read_write.c:607 [inline]
__x64_sys_write+0x73/0xb0 fs/read_write.c:607
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457579
Code: 1d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 eb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f5a92ec2c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457579
RDX: 000000000000002c RSI: 00000000200000c0 RDI: 0000000000000004
RBP: 000000000072bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f5a92ec36d4
R13: 00000000004c5454 R14: 00000000004d8c78 R15: 00000000ffffffff
CPU: 1 PID: 10921 Comm: syz-executor3 Not tainted 4.19.0-rc5+ #252
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
The buggy address belongs to the variable:
__start_rodata+0x8/0x1000
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
Memory state around the buggy address:
ffffffff87ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffffffff87ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
fail_dump lib/fault-inject.c:51 [inline]
should_fail.cold.4+0xa/0x17 lib/fault-inject.c:149
> ffffffff88000000: 00 fa fa fa fa fa fa fa 00 01 fa fa fa fa fa fa
^
ffffffff88000080: 00 00 00 07 fa fa fa fa 00 04 fa fa fa fa fa fa
ffffffff88000100: 05 fa fa fa fa fa fa fa 00 00 00 00 05 fa fa fa
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* Re: general protection fault in integrity_inode_free
From: Dmitry Vyukov @ 2018-09-26 7:53 UTC (permalink / raw)
To: syzbot, James Morris, Serge E. Hallyn, zohar, Matthew Garrett,
Dmitry Kasatkin, sudeep.holla, jlayton, linux-security-module
Cc: David Miller, LKML, netdev, syzkaller-bugs
In-Reply-To: <0000000000009581bf0576c16d3a@google.com>
On Wed, Sep 26, 2018 at 9:47 AM, syzbot
<syzbot+4c0fa7d385ea5af34e91@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 846e8dd47c26 Merge tag 'scsi-fixes' of git://git.kernel.or..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=12a59d56400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=dfb440e26f0a6f6f
> dashboard link: https://syzkaller.appspot.com/bug?extid=4c0fa7d385ea5af34e91
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+4c0fa7d385ea5af34e91@syzkaller.appspotmail.com
This was misattributed to net, +IMA maintainers.
> __do_sys_sendmsg net/socket.c:2163 [inline]
> __se_sys_sendmsg net/socket.c:2161 [inline]
> __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2161
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> general protection fault: 0000 [#1] PREEMPT SMP KASAN
> RIP: 0033:0x457579
> CPU: 0 PID: 8727 Comm: syz-executor3 Not tainted 4.19.0-rc5+ #33
> Code: 1d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 eb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RSP: 002b:00007f07f2e4bc78 EFLAGS: 00000246
> RIP: 0010:__rb_erase_augmented include/linux/rbtree_augmented.h:168 [inline]
> RIP: 0010:rb_erase+0x306/0x3710 lib/rbtree.c:459
> ORIG_RAX: 000000000000002e
> Code: c7 81 28 01 00 00 f2 f2 f2 f2 c7 81 2c 01 00 00 00 f2 f2 f2 48 89 f9
> 65 48 8b 1c 25 28 00 00 00 48 89 5d d0 31 db 48 c1 e9 03 <42> 80 3c 01 00 0f
> 85 41 1c 00 00 4c 8d 48 10 4c 8b 78 08 48 b9 00
> RAX: ffffffffffffffda RBX: 00007f07f2e4bc90 RCX: 0000000000457579
> RSP: 0018:ffff88018620e918 EFLAGS: 00010202
> RDX: 0000000000000000 RSI: 000000002000b000 RDI: 0000000000000003
> RBP: 000000000072bf00 R08: 0000000000000000 R09: 0000000000000000
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f07f2e4c6d4
> RDX: 1ffff10030c41d2b RSI: ffffffff8b5a08a0 RDI: 0000000000000008
> R13: 00000000004c38e1 R14: 00000000004d5730 R15: 0000000000000004
> RBP: ffff88018620f320 R08: dffffc0000000000 R09: fffffbfff135d5c8
> kobject: 'loop5' (00000000eac6d22a): kobject_uevent_env
> R10: fffffbfff135d5c8 R11: ffffffff89aeae43 R12: ffff8801bacb38f0
> R13: dffffc0000000000 R14: ffff88018620f2f8 R15: ffff88018620f438
> overlayfs: unrecognized mount option "smackfstransmute=upperdir" or missing
> value
> FS: 00007ff9677ec700(0000) GS:ffff8801dac00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000001b31324000 CR3: 00000001c2773000 CR4: 00000000001406f0
> Call Trace:
> integrity_inode_free+0x12f/0x320 security/integrity/iint.c:150
> security_inode_free+0x19/0x90 security/security.c:453
> __destroy_inode+0x328/0x820 fs/inode.c:238
> destroy_inode+0xda/0x200 fs/inode.c:265
> evict+0x5e0/0x980 fs/inode.c:575
> iput_final fs/inode.c:1547 [inline]
> iput+0x679/0xa90 fs/inode.c:1573
> swap_inode_boot_loader fs/ext4/ioctl.c:188 [inline]
> ext4_ioctl+0x236f/0x4210 fs/ext4/ioctl.c:865
> vfs_ioctl fs/ioctl.c:46 [inline]
> file_ioctl fs/ioctl.c:501 [inline]
> do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
> ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
> __do_sys_ioctl fs/ioctl.c:709 [inline]
> __se_sys_ioctl fs/ioctl.c:707 [inline]
> __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x457579
> Code: 1d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 eb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007ff9677ebc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 0000000000457579
> RDX: 0000000000000000 RSI: 0000000000006611 RDI: 0000000000000003
> RBP: 000000000072c040 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007ff9677ec6d4
> R13: 00000000004bf626 R14: 00000000004cf4c0 R15: 00000000ffffffff
> Modules linked in:
> ---[ end trace 6d41a32e43d56085 ]---
> RIP: 0010:__rb_erase_augmented include/linux/rbtree_augmented.h:168 [inline]
> RIP: 0010:rb_erase+0x306/0x3710 lib/rbtree.c:459
> Code: c7 81 28 01 00 00 f2 f2 f2 f2 c7 81 2c 01 00 00 00 f2 f2 f2 48 89 f9
> 65 48 8b 1c 25 28 00 00 00 48 89 5d d0 31 db 48 c1 e9 03 <42> 80 3c 01 00 0f
> 85 41 1c 00 00 4c 8d 48 10 4c 8b 78 08 48 b9 00
> RSP: 0018:ffff88018620e918 EFLAGS: 00010202
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001
> RDX: 1ffff10030c41d2b RSI: ffffffff8b5a08a0 RDI: 0000000000000008
> RBP: ffff88018620f320 R08: dffffc0000000000 R09: fffffbfff135d5c8
> R10: fffffbfff135d5c8 R11: ffffffff89aeae43 R12: ffff8801bacb38f0
> R13: dffffc0000000000 R14: ffff88018620f2f8 R15: ffff88018620f438
> FS: 00007ff9677ec700(0000) GS:ffff8801dac00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000001b31324000 CR3: 00000001c2773000 CR4: 00000000001406f0
>
>
> ---
> 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.
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/0000000000009581bf0576c16d3a%40google.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH resend] can: rcar_can: convert to SPDX identifiers
From: Kuninori Morimoto @ 2018-09-26 1:41 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde
Cc: Linux-Renesas, Linux-Net, linux-can
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
This patch updates license to use SPDX-License-Identifier
instead of verbose license text.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
---
Wolfgang, Marc
2 weeks past, resend patch
drivers/net/can/rcar/Kconfig | 1 +
drivers/net/can/rcar/Makefile | 1 +
drivers/net/can/rcar/rcar_can.c | 6 +-----
drivers/net/can/rcar/rcar_canfd.c | 6 +-----
4 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/net/can/rcar/Kconfig b/drivers/net/can/rcar/Kconfig
index 7b03a3a..bd5a8fc 100644
--- a/drivers/net/can/rcar/Kconfig
+++ b/drivers/net/can/rcar/Kconfig
@@ -1,3 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
config CAN_RCAR
tristate "Renesas R-Car CAN controller"
depends on ARCH_RENESAS || ARM
diff --git a/drivers/net/can/rcar/Makefile b/drivers/net/can/rcar/Makefile
index 08de36a..c9185b0 100644
--- a/drivers/net/can/rcar/Makefile
+++ b/drivers/net/can/rcar/Makefile
@@ -1,3 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
#
# Makefile for the Renesas R-Car CAN & CAN FD controller drivers
#
diff --git a/drivers/net/can/rcar/rcar_can.c b/drivers/net/can/rcar/rcar_can.c
index 11662f4..06f90a0 100644
--- a/drivers/net/can/rcar/rcar_can.c
+++ b/drivers/net/can/rcar/rcar_can.c
@@ -1,12 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0+
/* Renesas R-Car CAN device driver
*
* Copyright (C) 2013 Cogent Embedded, Inc. <source@cogentembedded.com>
* Copyright (C) 2013 Renesas Solutions Corp.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
*/
#include <linux/module.h>
diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
index 602c19e..0541000 100644
--- a/drivers/net/can/rcar/rcar_canfd.c
+++ b/drivers/net/can/rcar/rcar_canfd.c
@@ -1,11 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0+
/* Renesas R-Car CAN FD device driver
*
* Copyright (C) 2015 Renesas Electronics Corp.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
*/
/* The R-Car CAN FD controller can operate in either one of the below two modes
--
2.7.4
^ permalink raw reply related
* KASAN: use-after-free Read in vhost_transport_cancel_pkt
From: syzbot @ 2018-09-26 7:50 UTC (permalink / raw)
To: jasowang, kvm, linux-kernel, mst, netdev, stefanha,
syzkaller-bugs, virtualization
Hello,
syzbot found the following crash on:
HEAD commit: 4ca719a338d5 Merge branch 'linus' of git://git.kernel.org/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16861f99400000
kernel config: https://syzkaller.appspot.com/x/.config?x=5fa12be50bca08d8
dashboard link: https://syzkaller.appspot.com/bug?extid=e3e074963495f92a89ed
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
userspace arch: i386
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+e3e074963495f92a89ed@syzkaller.appspotmail.com
QAT: Invalid ioctl
==================================================================
BUG: KASAN: use-after-free in perf_trace_lock_acquire+0x66b/0x800
include/trace/events/lock.h:13
Read of size 8 at addr ffff880196f584e8 by task syz-executor1/30556
CPU: 1 PID: 30556 Comm: syz-executor1 Not tainted 4.19.0-rc4+ #148
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+0x1c4/0x2b4 lib/dump_stack.c:113
print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
perf_trace_lock_acquire+0x66b/0x800 include/trace/events/lock.h:13
trace_lock_acquire include/trace/events/lock.h:13 [inline]
lock_acquire+0x385/0x520 kernel/locking/lockdep.c:3899
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
_raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168
spin_lock_bh include/linux/spinlock.h:334 [inline]
vhost_transport_cancel_pkt+0x15e/0x910 drivers/vhost/vsock.c:244
vsock_transport_cancel_pkt net/vmw_vsock/af_vsock.c:1114 [inline]
vsock_stream_connect+0x903/0xe40 net/vmw_vsock/af_vsock.c:1241
__sys_connect+0x37d/0x4c0 net/socket.c:1664
__do_sys_connect net/socket.c:1675 [inline]
__se_sys_connect net/socket.c:1672 [inline]
__ia32_sys_connect+0x72/0xb0 net/socket.c:1672
do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline]
do_fast_syscall_32+0x34d/0xfb2 arch/x86/entry/common.c:397
entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
RIP: 0023:0xf7f8fca9
Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 0c 24 c3 8b 1c 24 c3 90 90
90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90
90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 002b:00000000f5f280cc EFLAGS: 00000296 ORIG_RAX: 000000000000016a
RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 0000000020000080
RDX: 0000000000000010 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Allocated by task 30547:
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:3682 [inline]
__kmalloc_node+0x47/0x70 mm/slab.c:3689
kmalloc_node include/linux/slab.h:555 [inline]
kvmalloc_node+0xb9/0xf0 mm/util.c:423
QAT: Invalid ioctl
kvmalloc include/linux/mm.h:577 [inline]
vhost_vsock_dev_open+0xa2/0x5a0 drivers/vhost/vsock.c:511
misc_open+0x3ca/0x560 drivers/char/misc.c:141
chrdev_open+0x25a/0x710 fs/char_dev.c:417
do_dentry_open+0x499/0x1250 fs/open.c:771
vfs_open+0xa0/0xd0 fs/open.c:880
do_last fs/namei.c:3418 [inline]
path_openat+0x12bf/0x5160 fs/namei.c:3534
do_filp_open+0x255/0x380 fs/namei.c:3564
do_sys_open+0x568/0x700 fs/open.c:1063
__do_compat_sys_openat fs/open.c:1109 [inline]
__se_compat_sys_openat fs/open.c:1107 [inline]
__ia32_compat_sys_openat+0x98/0xf0 fs/open.c:1107
do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline]
do_fast_syscall_32+0x34d/0xfb2 arch/x86/entry/common.c:397
entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
Freed by task 30546:
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:3813
kvfree+0x61/0x70 mm/util.c:452
vhost_vsock_free drivers/vhost/vsock.c:499 [inline]
vhost_vsock_dev_release+0x4f4/0x720 drivers/vhost/vsock.c:604
__fput+0x385/0xa30 fs/file_table.c:278
____fput+0x15/0x20 fs/file_table.c:309
task_work_run+0x1e8/0x2a0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:193 [inline]
exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
do_syscall_32_irqs_on arch/x86/entry/common.c:341 [inline]
do_fast_syscall_32+0xcd5/0xfb2 arch/x86/entry/common.c:397
entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
The buggy address belongs to the object at ffff880196f4f7c0
which belongs to the cache kmalloc-65536 of size 65536
The buggy address is located 36136 bytes inside of
65536-byte region [ffff880196f4f7c0, ffff880196f5f7c0)
The buggy address belongs to the page:
page:ffffea00065bd000 count:1 mapcount:0 mapping:ffff8801da802500 index:0x0
compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffffea00071cf008 ffffea0007199808 ffff8801da802500
raw: 0000000000000000 ffff880196f4f7c0 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff880196f58380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff880196f58400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff880196f58480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff880196f58500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff880196f58580: 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.
^ permalink raw reply
* general protection fault in integrity_inode_free
From: syzbot @ 2018-09-26 7:47 UTC (permalink / raw)
To: davem, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 846e8dd47c26 Merge tag 'scsi-fixes' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12a59d56400000
kernel config: https://syzkaller.appspot.com/x/.config?x=dfb440e26f0a6f6f
dashboard link: https://syzkaller.appspot.com/bug?extid=4c0fa7d385ea5af34e91
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+4c0fa7d385ea5af34e91@syzkaller.appspotmail.com
__do_sys_sendmsg net/socket.c:2163 [inline]
__se_sys_sendmsg net/socket.c:2161 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2161
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
entry_SYSCALL_64_after_hwframe+0x49/0xbe
general protection fault: 0000 [#1] PREEMPT SMP KASAN
RIP: 0033:0x457579
CPU: 0 PID: 8727 Comm: syz-executor3 Not tainted 4.19.0-rc5+ #33
Code: 1d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 eb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RSP: 002b:00007f07f2e4bc78 EFLAGS: 00000246
RIP: 0010:__rb_erase_augmented include/linux/rbtree_augmented.h:168 [inline]
RIP: 0010:rb_erase+0x306/0x3710 lib/rbtree.c:459
ORIG_RAX: 000000000000002e
Code: c7 81 28 01 00 00 f2 f2 f2 f2 c7 81 2c 01 00 00 00 f2 f2 f2 48 89 f9
65 48 8b 1c 25 28 00 00 00 48 89 5d d0 31 db 48 c1 e9 03 <42> 80 3c 01 00
0f 85 41 1c 00 00 4c 8d 48 10 4c 8b 78 08 48 b9 00
RAX: ffffffffffffffda RBX: 00007f07f2e4bc90 RCX: 0000000000457579
RSP: 0018:ffff88018620e918 EFLAGS: 00010202
RDX: 0000000000000000 RSI: 000000002000b000 RDI: 0000000000000003
RBP: 000000000072bf00 R08: 0000000000000000 R09: 0000000000000000
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f07f2e4c6d4
RDX: 1ffff10030c41d2b RSI: ffffffff8b5a08a0 RDI: 0000000000000008
R13: 00000000004c38e1 R14: 00000000004d5730 R15: 0000000000000004
RBP: ffff88018620f320 R08: dffffc0000000000 R09: fffffbfff135d5c8
kobject: 'loop5' (00000000eac6d22a): kobject_uevent_env
R10: fffffbfff135d5c8 R11: ffffffff89aeae43 R12: ffff8801bacb38f0
R13: dffffc0000000000 R14: ffff88018620f2f8 R15: ffff88018620f438
overlayfs: unrecognized mount option "smackfstransmute=upperdir" or missing
value
FS: 00007ff9677ec700(0000) GS:ffff8801dac00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b31324000 CR3: 00000001c2773000 CR4: 00000000001406f0
Call Trace:
integrity_inode_free+0x12f/0x320 security/integrity/iint.c:150
security_inode_free+0x19/0x90 security/security.c:453
__destroy_inode+0x328/0x820 fs/inode.c:238
destroy_inode+0xda/0x200 fs/inode.c:265
evict+0x5e0/0x980 fs/inode.c:575
iput_final fs/inode.c:1547 [inline]
iput+0x679/0xa90 fs/inode.c:1573
swap_inode_boot_loader fs/ext4/ioctl.c:188 [inline]
ext4_ioctl+0x236f/0x4210 fs/ext4/ioctl.c:865
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:501 [inline]
do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
__do_sys_ioctl fs/ioctl.c:709 [inline]
__se_sys_ioctl fs/ioctl.c:707 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457579
Code: 1d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 eb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ff9677ebc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 0000000000457579
RDX: 0000000000000000 RSI: 0000000000006611 RDI: 0000000000000003
RBP: 000000000072c040 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ff9677ec6d4
R13: 00000000004bf626 R14: 00000000004cf4c0 R15: 00000000ffffffff
Modules linked in:
---[ end trace 6d41a32e43d56085 ]---
RIP: 0010:__rb_erase_augmented include/linux/rbtree_augmented.h:168 [inline]
RIP: 0010:rb_erase+0x306/0x3710 lib/rbtree.c:459
Code: c7 81 28 01 00 00 f2 f2 f2 f2 c7 81 2c 01 00 00 00 f2 f2 f2 48 89 f9
65 48 8b 1c 25 28 00 00 00 48 89 5d d0 31 db 48 c1 e9 03 <42> 80 3c 01 00
0f 85 41 1c 00 00 4c 8d 48 10 4c 8b 78 08 48 b9 00
RSP: 0018:ffff88018620e918 EFLAGS: 00010202
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001
RDX: 1ffff10030c41d2b RSI: ffffffff8b5a08a0 RDI: 0000000000000008
RBP: ffff88018620f320 R08: dffffc0000000000 R09: fffffbfff135d5c8
R10: fffffbfff135d5c8 R11: ffffffff89aeae43 R12: ffff8801bacb38f0
R13: dffffc0000000000 R14: ffff88018620f2f8 R15: ffff88018620f438
FS: 00007ff9677ec700(0000) GS:ffff8801dac00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b31324000 CR3: 00000001c2773000 CR4: 00000000001406f0
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* WARNING in pfkey_sock_destruct
From: syzbot @ 2018-09-26 7:41 UTC (permalink / raw)
To: davem, herbert, linux-kernel, netdev, steffen.klassert,
syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 10dc890d4228 Merge tag 'pinctrl-v4.19-3' of git://git.kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=126e7111400000
kernel config: https://syzkaller.appspot.com/x/.config?x=5fa12be50bca08d8
dashboard link: https://syzkaller.appspot.com/bug?extid=4acf0d9092f91bb60431
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+4acf0d9092f91bb60431@syzkaller.appspotmail.com
WARNING: CPU: 1 PID: 18415 at net/key/af_key.c:111
pfkey_sock_destruct+0x574/0x610 net/key/af_key.c:111
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 18415 Comm: syz-executor3 Not tainted 4.19.0-rc4+ #28
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+0x1c4/0x2b4 lib/dump_stack.c:113
panic+0x238/0x4e7 kernel/panic.c:184
__warn.cold.8+0x163/0x1ba kernel/panic.c:536
report_bug+0x254/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:993
RIP: 0010:pfkey_sock_destruct+0x574/0x610 net/key/af_key.c:111
Code: 00 48 c7 c7 a0 14 b4 88 c6 05 9e 48 40 03 01 e8 6d bc 80 fa e9 70 fc
ff ff e8 78 69 9e fa 0f 0b e9 a8 fe ff ff e8 6c 69 9e fa <0f> 0b e9 ed fd
ff ff 48 89 c7 e8 2d ca e1 fa e9 40 fe ff ff 4c 89
RSP: 0018:ffff880199627660 EFLAGS: 00010293
RAX: ffff88011e2a0680 RBX: ffff8801c5053100 RCX: ffffffff86e078fa
RDX: 0000000000000000 RSI: ffffffff86e07b14 RDI: 0000000000000005
RBP: ffff880199627770 R08: ffff88011e2a0680 R09: ffffed0038a0a65b
R10: ffffed0038a0a65b R11: ffff8801c50532db R12: 1ffff100332c4ecd
R13: ffff880199627748 R14: 1ffff100332c4ed1 R15: ffff8801cd7d4b40
__sk_destruct+0x115/0xbd0 net/core/sock.c:1560
sk_destruct+0x78/0x90 net/core/sock.c:1595
__sk_free+0xcf/0x300 net/core/sock.c:1606
sk_free+0x42/0x50 net/core/sock.c:1617
sock_put include/net/sock.h:1691 [inline]
pfkey_release+0x409/0x570 net/key/af_key.c:194
__sock_release+0xd7/0x250 net/socket.c:579
sock_close+0x19/0x20 net/socket.c:1141
__fput+0x385/0xa30 fs/file_table.c:278
____fput+0x15/0x20 fs/file_table.c:309
task_work_run+0x1e8/0x2a0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:193 [inline]
exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x411151
Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 34 19 00 00 c3 48
83 ec 08 e8 0a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48
89 c2 e8 53 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01
kobject: 'loop4' (000000003d24b0c2): kobject_uevent_env
RSP: 002b:00007ffd93469000 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
kobject: 'loop4' (000000003d24b0c2): fill_kobj_path: path
= '/devices/virtual/block/loop4'
RAX: 0000000000000000 RBX: 0000000000000006 RCX: 0000000000411151
RDX: 0000000000000000 RSI: 00000000007317f8 RDI: 0000000000000005
RBP: 0000000000000000 R08: 00000000000000a0 R09: ffffffffffffffff
R10: 000000000072bfa0 R11: 0000000000000293 R12: 000000000000000b
R13: 000000000006a9d7 R14: 0000000000000167 R15: badc0ffeebadface
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* Re: Grant-
From: M. M. Fridman @ 2018-09-25 21:25 UTC (permalink / raw)
To: Recipients
I, Mikhail Fridman have selected you specifically as one of my beneficiaries
for my Charitable Donation, just as I have declared on 23rd of May 2016 to give
my fortune to charity.
Check the link below for confirmation:
https://www.rt.com/business/343781-mikhail-fridman-will-charity/
Reply as soon as possible with further directives.
Best Regards,
Mikhail Fridman.
^ permalink raw reply
* Re: [PATCH 2/2] net-ipv4: remove 2 always zero parameters from ipv4_redirect()
From: David Ahern @ 2018-09-26 0:52 UTC (permalink / raw)
To: Maciej Żenczykowski, Maciej Żenczykowski,
David S . Miller, Eric Dumazet
Cc: netdev
In-Reply-To: <20180926004137.163699-2-zenczykowski@gmail.com>
On 9/25/18 6:41 PM, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski <maze@google.com>
A summary here of which 2 parameters are always 0 would be nice.
>
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
> ---
> include/net/route.h | 3 +--
> net/ipv4/ah4.c | 2 +-
> net/ipv4/esp4.c | 2 +-
> net/ipv4/icmp.c | 2 +-
> net/ipv4/ip_gre.c | 4 ++--
> net/ipv4/ip_vti.c | 2 +-
> net/ipv4/ipcomp.c | 2 +-
> net/ipv4/ipip.c | 2 +-
> net/ipv4/route.c | 4 ++--
> net/ipv6/sit.c | 4 ++--
> net/xfrm/xfrm_interface.c | 2 +-
> 11 files changed, 14 insertions(+), 15 deletions(-)
Reviewed-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: [PATCH 1/2] net-ipv4: remove 2 always zero parameters from ipv4_update_pmtu()
From: David Ahern @ 2018-09-26 0:52 UTC (permalink / raw)
To: Maciej Żenczykowski, Maciej Żenczykowski,
David S . Miller, Eric Dumazet
Cc: netdev
In-Reply-To: <20180926004137.163699-1-zenczykowski@gmail.com>
On 9/25/18 6:41 PM, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski <maze@google.com>
>
A summary here of which 2 parameters are always 0 would be nice.
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
> ---
> include/net/route.h | 2 +-
> net/ipv4/ah4.c | 2 +-
> net/ipv4/esp4.c | 2 +-
> net/ipv4/icmp.c | 2 +-
> net/ipv4/ip_gre.c | 2 +-
> net/ipv4/ip_vti.c | 2 +-
> net/ipv4/ipcomp.c | 2 +-
> net/ipv4/ipip.c | 3 +--
> net/ipv4/route.c | 8 +++-----
> net/ipv6/sit.c | 2 +-
> net/netfilter/ipvs/ip_vs_core.c | 3 +--
> net/xfrm/xfrm_interface.c | 2 +-
> 12 files changed, 14 insertions(+), 18 deletions(-)
>
Reviewed-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* [PATCH 2/2] net-ipv4: remove 2 always zero parameters from ipv4_redirect()
From: Maciej Żenczykowski @ 2018-09-26 0:41 UTC (permalink / raw)
To: Maciej Żenczykowski, David S . Miller, Eric Dumazet; +Cc: netdev
In-Reply-To: <20180926004137.163699-1-zenczykowski@gmail.com>
From: Maciej Żenczykowski <maze@google.com>
Signed-off-by: Maciej Żenczykowski <maze@google.com>
---
include/net/route.h | 3 +--
net/ipv4/ah4.c | 2 +-
net/ipv4/esp4.c | 2 +-
net/ipv4/icmp.c | 2 +-
net/ipv4/ip_gre.c | 4 ++--
net/ipv4/ip_vti.c | 2 +-
net/ipv4/ipcomp.c | 2 +-
net/ipv4/ipip.c | 2 +-
net/ipv4/route.c | 4 ++--
net/ipv6/sit.c | 4 ++--
net/xfrm/xfrm_interface.c | 2 +-
11 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/include/net/route.h b/include/net/route.h
index 73c605bdd6d8..9883dc82f723 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -203,8 +203,7 @@ static inline int ip_route_input(struct sk_buff *skb, __be32 dst, __be32 src,
void ipv4_update_pmtu(struct sk_buff *skb, struct net *net, u32 mtu, int oif,
u8 protocol);
void ipv4_sk_update_pmtu(struct sk_buff *skb, struct sock *sk, u32 mtu);
-void ipv4_redirect(struct sk_buff *skb, struct net *net, int oif, u32 mark,
- u8 protocol, int flow_flags);
+void ipv4_redirect(struct sk_buff *skb, struct net *net, int oif, u8 protocol);
void ipv4_sk_redirect(struct sk_buff *skb, struct sock *sk);
void ip_rt_send_redirect(struct sk_buff *skb);
diff --git a/net/ipv4/ah4.c b/net/ipv4/ah4.c
index 8811fe30282a..c01fa791260d 100644
--- a/net/ipv4/ah4.c
+++ b/net/ipv4/ah4.c
@@ -463,7 +463,7 @@ static int ah4_err(struct sk_buff *skb, u32 info)
if (icmp_hdr(skb)->type == ICMP_DEST_UNREACH)
ipv4_update_pmtu(skb, net, info, 0, IPPROTO_AH);
else
- ipv4_redirect(skb, net, 0, 0, IPPROTO_AH, 0);
+ ipv4_redirect(skb, net, 0, IPPROTO_AH);
xfrm_state_put(x);
return 0;
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 2d0274441923..071533dd33c2 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -822,7 +822,7 @@ static int esp4_err(struct sk_buff *skb, u32 info)
if (icmp_hdr(skb)->type == ICMP_DEST_UNREACH)
ipv4_update_pmtu(skb, net, info, 0, IPPROTO_ESP);
else
- ipv4_redirect(skb, net, 0, 0, IPPROTO_ESP, 0);
+ ipv4_redirect(skb, net, 0, IPPROTO_ESP);
xfrm_state_put(x);
return 0;
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index 8013b37b598f..d832beed6e3a 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -1100,7 +1100,7 @@ void icmp_err(struct sk_buff *skb, u32 info)
if (type == ICMP_DEST_UNREACH && code == ICMP_FRAG_NEEDED)
ipv4_update_pmtu(skb, net, info, 0, IPPROTO_ICMP);
else if (type == ICMP_REDIRECT)
- ipv4_redirect(skb, net, 0, 0, IPPROTO_ICMP, 0);
+ ipv4_redirect(skb, net, 0, IPPROTO_ICMP);
}
/*
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 83b80fafd8f2..38befe829caf 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -243,8 +243,8 @@ static void gre_err(struct sk_buff *skb, u32 info)
return;
}
if (type == ICMP_REDIRECT) {
- ipv4_redirect(skb, dev_net(skb->dev), skb->dev->ifindex, 0,
- IPPROTO_GRE, 0);
+ ipv4_redirect(skb, dev_net(skb->dev), skb->dev->ifindex,
+ IPPROTO_GRE);
return;
}
diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index 1b5571cb3282..de31b302d69c 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -320,7 +320,7 @@ static int vti4_err(struct sk_buff *skb, u32 info)
if (icmp_hdr(skb)->type == ICMP_DEST_UNREACH)
ipv4_update_pmtu(skb, net, info, 0, protocol);
else
- ipv4_redirect(skb, net, 0, 0, protocol, 0);
+ ipv4_redirect(skb, net, 0, protocol);
xfrm_state_put(x);
return 0;
diff --git a/net/ipv4/ipcomp.c b/net/ipv4/ipcomp.c
index 04049d1330a2..9119d012ba46 100644
--- a/net/ipv4/ipcomp.c
+++ b/net/ipv4/ipcomp.c
@@ -50,7 +50,7 @@ static int ipcomp4_err(struct sk_buff *skb, u32 info)
if (icmp_hdr(skb)->type == ICMP_DEST_UNREACH)
ipv4_update_pmtu(skb, net, info, 0, IPPROTO_COMP);
else
- ipv4_redirect(skb, net, 0, 0, IPPROTO_COMP, 0);
+ ipv4_redirect(skb, net, 0, IPPROTO_COMP);
xfrm_state_put(x);
return 0;
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index 6ff008e5818d..e65287c27e3d 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -180,7 +180,7 @@ static int ipip_err(struct sk_buff *skb, u32 info)
}
if (type == ICMP_REDIRECT) {
- ipv4_redirect(skb, net, t->parms.link, 0, iph->protocol, 0);
+ ipv4_redirect(skb, net, t->parms.link, iph->protocol);
goto out;
}
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 7bbe3fc80b90..dce2ed66ebe1 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1130,14 +1130,14 @@ void ipv4_sk_update_pmtu(struct sk_buff *skb, struct sock *sk, u32 mtu)
EXPORT_SYMBOL_GPL(ipv4_sk_update_pmtu);
void ipv4_redirect(struct sk_buff *skb, struct net *net,
- int oif, u32 mark, u8 protocol, int flow_flags)
+ int oif, u8 protocol)
{
const struct iphdr *iph = (const struct iphdr *) skb->data;
struct flowi4 fl4;
struct rtable *rt;
__build_flow_key(net, &fl4, NULL, iph, oif,
- RT_TOS(iph->tos), protocol, mark, flow_flags);
+ RT_TOS(iph->tos), protocol, 0, 0);
rt = __ip_route_output_key(net, &fl4);
if (!IS_ERR(rt)) {
__ip_do_redirect(rt, skb, &fl4, false);
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 085c588ebfe0..51c9f75f34b9 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -539,8 +539,8 @@ static int ipip6_err(struct sk_buff *skb, u32 info)
goto out;
}
if (type == ICMP_REDIRECT) {
- ipv4_redirect(skb, dev_net(skb->dev), t->parms.link, 0,
- iph->protocol, 0);
+ ipv4_redirect(skb, dev_net(skb->dev), t->parms.link,
+ iph->protocol);
err = 0;
goto out;
}
diff --git a/net/xfrm/xfrm_interface.c b/net/xfrm/xfrm_interface.c
index 16bc5ecb7869..4b4ef4f662d9 100644
--- a/net/xfrm/xfrm_interface.c
+++ b/net/xfrm/xfrm_interface.c
@@ -471,7 +471,7 @@ static int xfrmi4_err(struct sk_buff *skb, u32 info)
if (icmp_hdr(skb)->type == ICMP_DEST_UNREACH)
ipv4_update_pmtu(skb, net, info, 0, protocol);
else
- ipv4_redirect(skb, net, 0, 0, protocol, 0);
+ ipv4_redirect(skb, net, 0, protocol);
xfrm_state_put(x);
return 0;
--
2.19.0.605.g01d371f741-goog
^ permalink raw reply related
* [PATCH 1/2] net-ipv4: remove 2 always zero parameters from ipv4_update_pmtu()
From: Maciej Żenczykowski @ 2018-09-26 0:41 UTC (permalink / raw)
To: Maciej Żenczykowski, David S . Miller, Eric Dumazet; +Cc: netdev
From: Maciej Żenczykowski <maze@google.com>
Signed-off-by: Maciej Żenczykowski <maze@google.com>
---
include/net/route.h | 2 +-
net/ipv4/ah4.c | 2 +-
net/ipv4/esp4.c | 2 +-
net/ipv4/icmp.c | 2 +-
net/ipv4/ip_gre.c | 2 +-
net/ipv4/ip_vti.c | 2 +-
net/ipv4/ipcomp.c | 2 +-
net/ipv4/ipip.c | 3 +--
net/ipv4/route.c | 8 +++-----
net/ipv6/sit.c | 2 +-
net/netfilter/ipvs/ip_vs_core.c | 3 +--
net/xfrm/xfrm_interface.c | 2 +-
12 files changed, 14 insertions(+), 18 deletions(-)
diff --git a/include/net/route.h b/include/net/route.h
index bb53cdba38dc..73c605bdd6d8 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -201,7 +201,7 @@ static inline int ip_route_input(struct sk_buff *skb, __be32 dst, __be32 src,
}
void ipv4_update_pmtu(struct sk_buff *skb, struct net *net, u32 mtu, int oif,
- u32 mark, u8 protocol, int flow_flags);
+ u8 protocol);
void ipv4_sk_update_pmtu(struct sk_buff *skb, struct sock *sk, u32 mtu);
void ipv4_redirect(struct sk_buff *skb, struct net *net, int oif, u32 mark,
u8 protocol, int flow_flags);
diff --git a/net/ipv4/ah4.c b/net/ipv4/ah4.c
index 4dd95cdd8070..8811fe30282a 100644
--- a/net/ipv4/ah4.c
+++ b/net/ipv4/ah4.c
@@ -461,7 +461,7 @@ static int ah4_err(struct sk_buff *skb, u32 info)
return 0;
if (icmp_hdr(skb)->type == ICMP_DEST_UNREACH)
- ipv4_update_pmtu(skb, net, info, 0, 0, IPPROTO_AH, 0);
+ ipv4_update_pmtu(skb, net, info, 0, IPPROTO_AH);
else
ipv4_redirect(skb, net, 0, 0, IPPROTO_AH, 0);
xfrm_state_put(x);
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 97689012b357..2d0274441923 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -820,7 +820,7 @@ static int esp4_err(struct sk_buff *skb, u32 info)
return 0;
if (icmp_hdr(skb)->type == ICMP_DEST_UNREACH)
- ipv4_update_pmtu(skb, net, info, 0, 0, IPPROTO_ESP, 0);
+ ipv4_update_pmtu(skb, net, info, 0, IPPROTO_ESP);
else
ipv4_redirect(skb, net, 0, 0, IPPROTO_ESP, 0);
xfrm_state_put(x);
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index 695979b7ef6d..8013b37b598f 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -1098,7 +1098,7 @@ void icmp_err(struct sk_buff *skb, u32 info)
}
if (type == ICMP_DEST_UNREACH && code == ICMP_FRAG_NEEDED)
- ipv4_update_pmtu(skb, net, info, 0, 0, IPPROTO_ICMP, 0);
+ ipv4_update_pmtu(skb, net, info, 0, IPPROTO_ICMP);
else if (type == ICMP_REDIRECT)
ipv4_redirect(skb, net, 0, 0, IPPROTO_ICMP, 0);
}
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index c3385a84f8ff..83b80fafd8f2 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -239,7 +239,7 @@ static void gre_err(struct sk_buff *skb, u32 info)
if (type == ICMP_DEST_UNREACH && code == ICMP_FRAG_NEEDED) {
ipv4_update_pmtu(skb, dev_net(skb->dev), info,
- skb->dev->ifindex, 0, IPPROTO_GRE, 0);
+ skb->dev->ifindex, IPPROTO_GRE);
return;
}
if (type == ICMP_REDIRECT) {
diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index f38cb21d773d..1b5571cb3282 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -318,7 +318,7 @@ static int vti4_err(struct sk_buff *skb, u32 info)
return 0;
if (icmp_hdr(skb)->type == ICMP_DEST_UNREACH)
- ipv4_update_pmtu(skb, net, info, 0, 0, protocol, 0);
+ ipv4_update_pmtu(skb, net, info, 0, protocol);
else
ipv4_redirect(skb, net, 0, 0, protocol, 0);
xfrm_state_put(x);
diff --git a/net/ipv4/ipcomp.c b/net/ipv4/ipcomp.c
index d97f4f2787f5..04049d1330a2 100644
--- a/net/ipv4/ipcomp.c
+++ b/net/ipv4/ipcomp.c
@@ -48,7 +48,7 @@ static int ipcomp4_err(struct sk_buff *skb, u32 info)
return 0;
if (icmp_hdr(skb)->type == ICMP_DEST_UNREACH)
- ipv4_update_pmtu(skb, net, info, 0, 0, IPPROTO_COMP, 0);
+ ipv4_update_pmtu(skb, net, info, 0, IPPROTO_COMP);
else
ipv4_redirect(skb, net, 0, 0, IPPROTO_COMP, 0);
xfrm_state_put(x);
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index c891235b4966..6ff008e5818d 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -175,8 +175,7 @@ static int ipip_err(struct sk_buff *skb, u32 info)
}
if (type == ICMP_DEST_UNREACH && code == ICMP_FRAG_NEEDED) {
- ipv4_update_pmtu(skb, net, info, t->parms.link, 0,
- iph->protocol, 0);
+ ipv4_update_pmtu(skb, net, info, t->parms.link, iph->protocol);
goto out;
}
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index b678466da451..7bbe3fc80b90 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1040,17 +1040,15 @@ static void ip_rt_update_pmtu(struct dst_entry *dst, struct sock *sk,
}
void ipv4_update_pmtu(struct sk_buff *skb, struct net *net, u32 mtu,
- int oif, u32 mark, u8 protocol, int flow_flags)
+ int oif, u8 protocol)
{
const struct iphdr *iph = (const struct iphdr *) skb->data;
struct flowi4 fl4;
struct rtable *rt;
-
- if (!mark)
- mark = IP4_REPLY_MARK(net, skb->mark);
+ u32 mark = IP4_REPLY_MARK(net, skb->mark);
__build_flow_key(net, &fl4, NULL, iph, oif,
- RT_TOS(iph->tos), protocol, mark, flow_flags);
+ RT_TOS(iph->tos), protocol, mark, 0);
rt = __ip_route_output_key(net, &fl4);
if (!IS_ERR(rt)) {
__ip_rt_update_pmtu(rt, &fl4, mtu);
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index e9400ffa7875..085c588ebfe0 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -534,7 +534,7 @@ static int ipip6_err(struct sk_buff *skb, u32 info)
if (type == ICMP_DEST_UNREACH && code == ICMP_FRAG_NEEDED) {
ipv4_update_pmtu(skb, dev_net(skb->dev), info,
- t->parms.link, 0, iph->protocol, 0);
+ t->parms.link, iph->protocol);
err = 0;
goto out;
}
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index 7ca926a03b81..fe9abf3cc10a 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -1686,8 +1686,7 @@ ip_vs_in_icmp(struct netns_ipvs *ipvs, struct sk_buff *skb, int *related,
skb_reset_network_header(skb);
IP_VS_DBG(12, "ICMP for IPIP %pI4->%pI4: mtu=%u\n",
&ip_hdr(skb)->saddr, &ip_hdr(skb)->daddr, mtu);
- ipv4_update_pmtu(skb, ipvs->net,
- mtu, 0, 0, 0, 0);
+ ipv4_update_pmtu(skb, ipvs->net, mtu, 0, 0);
/* Client uses PMTUD? */
if (!(frag_off & htons(IP_DF)))
goto ignore_ipip;
diff --git a/net/xfrm/xfrm_interface.c b/net/xfrm/xfrm_interface.c
index 31acc6f33d98..16bc5ecb7869 100644
--- a/net/xfrm/xfrm_interface.c
+++ b/net/xfrm/xfrm_interface.c
@@ -469,7 +469,7 @@ static int xfrmi4_err(struct sk_buff *skb, u32 info)
}
if (icmp_hdr(skb)->type == ICMP_DEST_UNREACH)
- ipv4_update_pmtu(skb, net, info, 0, 0, protocol, 0);
+ ipv4_update_pmtu(skb, net, info, 0, protocol);
else
ipv4_redirect(skb, net, 0, 0, protocol, 0);
xfrm_state_put(x);
--
2.19.0.605.g01d371f741-goog
^ permalink raw reply related
* [PATCH] net-tcp: /proc/sys/net/ipv4/tcp_probe_interval is a u32 not int
From: Maciej Żenczykowski @ 2018-09-26 0:41 UTC (permalink / raw)
To: Maciej Żenczykowski, David S . Miller, Eric Dumazet; +Cc: netdev
From: Maciej Żenczykowski <maze@google.com>
(fix documentation and sysctl access to treat it as such)
Signed-off-by: Maciej Żenczykowski <maze@google.com>
---
Documentation/networking/ip-sysctl.txt | 2 +-
net/ipv4/sysctl_net_ipv4.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 8313a636dd53..960de8fe3f40 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -425,7 +425,7 @@ tcp_mtu_probing - INTEGER
1 - Disabled by default, enabled when an ICMP black hole detected
2 - Always enabled, use initial MSS of tcp_base_mss.
-tcp_probe_interval - INTEGER
+tcp_probe_interval - UNSIGNED INTEGER
Controls how often to start TCP Packetization-Layer Path MTU
Discovery reprobe. The default is reprobing every 10 minutes as
per RFC4821.
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index b92f422f2fa8..c8fa935c3cdb 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -745,9 +745,9 @@ static struct ctl_table ipv4_net_table[] = {
{
.procname = "tcp_probe_interval",
.data = &init_net.ipv4.sysctl_tcp_probe_interval,
- .maxlen = sizeof(int),
+ .maxlen = sizeof(u32),
.mode = 0644,
- .proc_handler = proc_dointvec,
+ .proc_handler = proc_douintvec,
},
{
.procname = "igmp_link_local_mcast_reports",
--
2.19.0.605.g01d371f741-goog
^ permalink raw reply related
* ASAP
From: Margaret Kwan Wing Han @ 2018-09-26 0:05 UTC (permalink / raw)
To: Westnet Support
I have a deal for you reply for more details.
Kind Regards,
Ms Margaret KWAN Wing Han
^ permalink raw reply
* Re: [PATCH net 00/15] netpoll: avoid capture effects for NAPI drivers
From: Song Liu @ 2018-09-25 23:36 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, michael.chan@broadcom.com, Ariel Elior,
Eric Dumazet, Tariq Toukan, Saeed Mahameed, Jeff Kirsher,
jakub.kicinski@netronome.com, Jay Vosburgh, Veaceslav Falico,
Andy Gospodarek
In-Reply-To: <CANn89i+8mngtTLs8gzmEFjreW9ie64MPmZWaUDV+KRR7wgNfMA@mail.gmail.com>
> On Sep 24, 2018, at 8:30 AM, Eric Dumazet <edumazet@google.com> wrote:
>
> On Sun, Sep 23, 2018 at 10:04 PM David Miller <davem@davemloft.net> wrote:
>>
>> Series applied, thanks Eric.
>
> Thanks David.
>
> Song, would you please this additional patch ?
>
> diff --git a/net/core/netpoll.c b/net/core/netpoll.c
> index 3219a2932463096566ce8ff336ecdf699422dd65..2ad45babe621b2c979ad5496b7df4342e4efbaa6
> 100644
> --- a/net/core/netpoll.c
> +++ b/net/core/netpoll.c
> @@ -150,13 +150,6 @@ static void poll_one_napi(struct napi_struct *napi)
> {
> int work = 0;
>
> - /* net_rx_action's ->poll() invocations and our's are
> - * synchronized by this test which is only made while
> - * holding the napi->poll_lock.
> - */
> - if (!test_bit(NAPI_STATE_SCHED, &napi->state))
> - return;
> -
> /* If we set this bit but see that it has already been set,
> * that indicates that napi has been disabled and we need
> * to abort this operation
Reviewed-and-tested-by: Song Liu <songliubraving@fb.com>
^ permalink raw reply
* Re: [PATCH net RFT] bnxt_en: Fix TX timeout during netpoll.
From: Song Liu @ 2018-09-25 23:35 UTC (permalink / raw)
To: Michael Chan
Cc: edumazet@google.com, davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <1537911099-4073-1-git-send-email-michael.chan@broadcom.com>
Thanks Michael!
This works well in my tests.
Reviewed-and-tested-by: Song Liu <songliubraving@fb.com>
> On Sep 25, 2018, at 2:31 PM, Michael Chan <michael.chan@broadcom.com> wrote:
>
> The current netpoll implementation in the bnxt_en driver has problems
> that may miss TX completion events. bnxt_poll_work() in effect is
> only handling at most 1 TX packet before exiting. In addition,
> there may be in flight TX completions that ->poll() may miss even
> after we fix bnxt_poll_work() to handle all visible TX completions.
> netpoll may not call ->poll() again and HW may not generate IRQ
> because the driver does not ARM the IRQ when the budget (0 for netpoll)
> is reached.
>
> We fix it by handling all TX completions and to always ARM the IRQ
> when we exit ->poll() with 0 budget.
>
> Reported-by: Song Liu <songliubraving@fb.com>
> Signed-off-by: Michael Chan <michael.chan@broadcom.com>
> ---
> drivers/net/ethernet/broadcom/bnxt/bnxt.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> index 61957b0..c981b53 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> @@ -1913,7 +1913,7 @@ static int bnxt_poll_work(struct bnxt *bp, struct bnxt_napi *bnapi, int budget)
> }
> raw_cons = NEXT_RAW_CMP(raw_cons);
>
> - if (rx_pkts == budget)
> + if (rx_pkts && rx_pkts == budget)
> break;
> }
>
> @@ -2027,8 +2027,12 @@ static int bnxt_poll(struct napi_struct *napi, int budget)
> while (1) {
> work_done += bnxt_poll_work(bp, bnapi, budget - work_done);
>
> - if (work_done >= budget)
> + if (work_done >= budget) {
> + if (!budget)
> + BNXT_CP_DB_REARM(cpr->cp_doorbell,
> + cpr->cp_raw_cons);
> break;
> + }
>
> if (!bnxt_has_work(bp, cpr)) {
> if (napi_complete_done(napi, work_done))
> --
> 2.5.1
>
^ permalink raw reply
* Re: [PATCH net RFT] bnxt_en: Fix TX timeout during netpoll.
From: Michael Chan @ 2018-09-25 23:11 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Song Liu, Eric Dumazet, David Miller, Netdev
In-Reply-To: <c496aa4a-0fc1-9305-abfa-c287680e944a@gmail.com>
On Tue, Sep 25, 2018 at 3:15 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> It seems bnx2 should have a similar issue ?
>
Yes, I think so. The MSIX mode in bnx2 is also auto-masking, meaning
that MSIX will only assert once after it is ARMed. If we return from
->poll() when budget of 0 is reached without ARMing, we may not get
another MSIX.
I can work on a similar patch but I don't have bnx2 cards to test with
anymore. Thanks.
^ permalink raw reply
* [PATCH bpf-next] bpftool: Fix bpftool net output
From: Andrey Ignatov @ 2018-09-25 22:20 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, yhs
Print `bpftool net` output to stdout instead of stderr. Only errors
should be printed to stderr. Regular output should go to stdout and this
is what all other subcommands of bpftool do, including --json and
--pretty formats of `bpftool net` itself.
Fixes: commit f6f3bac08ff9 ("tools/bpf: bpftool: add net support")
Signed-off-by: Andrey Ignatov <rdna@fb.com>
Acked-by: Yonghong Song <yhs@fb.com>
---
tools/bpf/bpftool/netlink_dumper.h | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/tools/bpf/bpftool/netlink_dumper.h b/tools/bpf/bpftool/netlink_dumper.h
index 0788cfbbed0e..e3516b586a34 100644
--- a/tools/bpf/bpftool/netlink_dumper.h
+++ b/tools/bpf/bpftool/netlink_dumper.h
@@ -16,7 +16,7 @@
jsonw_name(json_wtr, name); \
jsonw_start_object(json_wtr); \
} else { \
- fprintf(stderr, "%s {", name); \
+ fprintf(stdout, "%s {", name); \
} \
}
@@ -25,7 +25,7 @@
if (json_output) \
jsonw_start_object(json_wtr); \
else \
- fprintf(stderr, "{"); \
+ fprintf(stdout, "{"); \
}
#define NET_END_OBJECT_NESTED \
@@ -33,7 +33,7 @@
if (json_output) \
jsonw_end_object(json_wtr); \
else \
- fprintf(stderr, "}"); \
+ fprintf(stdout, "}"); \
}
#define NET_END_OBJECT \
@@ -47,7 +47,7 @@
if (json_output) \
jsonw_end_object(json_wtr); \
else \
- fprintf(stderr, "\n"); \
+ fprintf(stdout, "\n"); \
}
#define NET_START_ARRAY(name, fmt_str) \
@@ -56,7 +56,7 @@
jsonw_name(json_wtr, name); \
jsonw_start_array(json_wtr); \
} else { \
- fprintf(stderr, fmt_str, name); \
+ fprintf(stdout, fmt_str, name); \
} \
}
@@ -65,7 +65,7 @@
if (json_output) \
jsonw_end_array(json_wtr); \
else \
- fprintf(stderr, "%s", endstr); \
+ fprintf(stdout, "%s", endstr); \
}
#define NET_DUMP_UINT(name, fmt_str, val) \
@@ -73,7 +73,7 @@
if (json_output) \
jsonw_uint_field(json_wtr, name, val); \
else \
- fprintf(stderr, fmt_str, val); \
+ fprintf(stdout, fmt_str, val); \
}
#define NET_DUMP_STR(name, fmt_str, str) \
@@ -81,7 +81,7 @@
if (json_output) \
jsonw_string_field(json_wtr, name, str);\
else \
- fprintf(stderr, fmt_str, str); \
+ fprintf(stdout, fmt_str, str); \
}
#define NET_DUMP_STR_ONLY(str) \
@@ -89,7 +89,7 @@
if (json_output) \
jsonw_string(json_wtr, str); \
else \
- fprintf(stderr, "%s ", str); \
+ fprintf(stdout, "%s ", str); \
}
#endif
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net RFT] bnxt_en: Fix TX timeout during netpoll.
From: Eric Dumazet @ 2018-09-25 22:15 UTC (permalink / raw)
To: Michael Chan, songliubraving, edumazet, davem; +Cc: netdev
In-Reply-To: <1537911099-4073-1-git-send-email-michael.chan@broadcom.com>
On 09/25/2018 02:31 PM, Michael Chan wrote:
> The current netpoll implementation in the bnxt_en driver has problems
> that may miss TX completion events. bnxt_poll_work() in effect is
> only handling at most 1 TX packet before exiting. In addition,
> there may be in flight TX completions that ->poll() may miss even
> after we fix bnxt_poll_work() to handle all visible TX completions.
> netpoll may not call ->poll() again and HW may not generate IRQ
> because the driver does not ARM the IRQ when the budget (0 for netpoll)
> is reached.
>
> We fix it by handling all TX completions and to always ARM the IRQ
> when we exit ->poll() with 0 budget.
>
> Reported-by: Song Liu <songliubraving@fb.com>
> Signed-off-by: Michael Chan <michael.chan@broadcom.com>
> ---
> drivers/net/ethernet/broadcom/bnxt/bnxt.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> index 61957b0..c981b53 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> @@ -1913,7 +1913,7 @@ static int bnxt_poll_work(struct bnxt *bp, struct bnxt_napi *bnapi, int budget)
> }
> raw_cons = NEXT_RAW_CMP(raw_cons);
>
> - if (rx_pkts == budget)
> + if (rx_pkts && rx_pkts == budget)
> break;
> }
>
> @@ -2027,8 +2027,12 @@ static int bnxt_poll(struct napi_struct *napi, int budget)
> while (1) {
> work_done += bnxt_poll_work(bp, bnapi, budget - work_done);
>
> - if (work_done >= budget)
> + if (work_done >= budget) {
> + if (!budget)
> + BNXT_CP_DB_REARM(cpr->cp_doorbell,
> + cpr->cp_raw_cons);
> break;
> + }
>
> if (!bnxt_has_work(bp, cpr)) {
> if (napi_complete_done(napi, work_done))
>
Hi Michael, thanks for the patch.
It seems bnx2 should have a similar issue ?
^ permalink raw reply
* Dobrodelna loterija zmagovalec.
From: Welch, Michael K @ 2018-09-25 21:59 UTC (permalink / raw)
Dobrodelna loterija zmagovalec.
Vaš e-poštni naslov je pravkar zmaga (One Hundred in petdeset tisoč. Evrov) € 150.000,00 v programu UPLIFT International Charity. Zap: SP / 229 / 0-01 / 07 / 5-02 / EC. Lucky št: 9/11/13/24/40.
Za dodatne informacije in zahtevek stiku postopku;
CAPITAL CLAIM AGENCY
Mr. John Carlos.
E-pošta: infocapitas@aim.com
Tel: + 34-634-027-588 (Govorite samo v angleščini)
S svojim polnim imenom, naslovom, starost, poklic, telefonske številke.
Pošlji odgovor na to E-pošta: infocapitas@aim.com
Opomba: To je mednarodni program loteriji. To sporočilo je bilo samodejno prevedena iz angleščine v Sloveniji.
Čestitke!!!.
-----------------------------------------------------------
Winner.
Your email address has just won € 150,000.00 (One Hundred and Fifty Thousand Euros) in the Uplift International Charity Lottery Program. Reference No: Sp / 229 / 0-01 / 07 / 5-02 / ES. Lucky No: 9/11/13/24/40.
For more information and claim procedure contact below.
CAPITAL CLAIM AGENCY
Mr. John Carlos.
Email: infocapitas@aim.com
Tel: + 34-634-027-588.
Your full name, address, age, occupation, phone numbers
Submit Reply to Email: infocapitas@aim.com
Congratulations!!!.
^ permalink raw reply
* Re: [net 1/1] tipc: lock wakeup & inputq at tipc_link_reset()
From: David Miller @ 2018-09-26 3:49 UTC (permalink / raw)
To: jon.maloy; +Cc: netdev, tipc-discussion
In-Reply-To: <1537906150-30955-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Tue, 25 Sep 2018 22:09:10 +0200
> From: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
>
> In tipc_link_reset() we copy the wakeup queue to input queue using
> skb_queue_splice_init(link->wakeupq, link->inputq).
> This is performed without holding any locks. The lists might be
> simultaneously be accessed by other cpu threads in tipc_sk_rcv(),
> something leading to to random missing packets.
>
> Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied.
^ permalink raw reply
* Re: [net 1/1] tipc: reset bearer if device carrier not ok
From: David Miller @ 2018-09-26 3:49 UTC (permalink / raw)
To: jon.maloy; +Cc: netdev, tipc-discussion
In-Reply-To: <1537905417-30804-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Tue, 25 Sep 2018 21:56:57 +0200
> From: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
>
> If we detect that under lying carrier detects errors and goes down,
> we reset the bearer.
>
> Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied.
^ 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