Re: INFO: rcu detected stall in tasklet_action_common

On Wed, Dec 9, 2020 at 10:53 PM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:b3298500 Merge tag 'for-5.10/dm-fixes' of git://git.kernel.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=135a07ab50 > kernel config:

Re: UBSAN: shift-out-of-bounds in ext4_fill_super

On Thu, Dec 10, 2020 at 4:50 AM syzbot wrote: > > Hello, > > syzbot tried to test the proposed patch but the build/boot failed: > > failed to checkout kernel repo > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git on commit > e360ba58d067a30a4e3e7d55ebdd919885a058d6: failed to run

Re: linux-next: build warning after merge of the akpm tree

On Mon, Dec 7, 2020 at 1:52 PM Marco Elver wrote: > > On Mon, 7 Dec 2020 at 13:38, 'Dmitry Vyukov' via kasan-dev > wrote: > > On Mon, Dec 7, 2020 at 1:08 PM Dmitry Vyukov wrote: > > > > > Hi all, > > > > > > > > > > Af

[PATCH] kcov: don't instrument with UBSAN

that gcc uses 'long' on 64-bit arches and 'long long' on 32-bit arches, while kernel type is always 'long long'. Reported-by: Stephen Rothwell Suggested-by: Marco Elver Signed-off-by: Dmitry Vyukov --- kernel/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/Makefile b

Re: BUG: MAX_LOCKDEP_KEYS too low!

On Sun, Oct 27, 2019 at 4:31 AM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:65921376 Merge branch 'net-fix-nested-device-bugs' > git tree: net > console output: https://syzkaller.appspot.com/x/log.txt?x=1637fdc0e0 > kernel config:

BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!

This stopped happening a while ago, let's close this to get notifications about new instances. One of likely candidates: #syz fix: net: partially revert dynamic lockdep key changes

Re: memory leak in generic_parse_monolithic [+PATCH]

On Wed, Dec 9, 2020 at 12:15 AM Randy Dunlap wrote: > > On 12/8/20 2:54 PM, David Howells wrote: > > Randy Dunlap wrote: > > > >>> Now the backtrace only shows what the state was when the string was > >>> allocated; > >>> it doesn't show what happened to it after that, so another possibility is

Re: BUG: unable to handle kernel paging request in bpf_lru_populate

On Mon, Dec 7, 2020 at 12:43 PM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:bcd684aa net/nfc/nci: Support NCI 2.x initial sequence > git tree: net-next > console output: https://syzkaller.appspot.com/x/log.txt?x=12001bd350 > kernel config:

Re: KASAN: vmalloc-out-of-bounds Write in pcpu_freelist_populate

On Mon, Dec 7, 2020 at 9:03 PM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:34da8721 selftests/bpf: Test bpf_sk_storage_get in tcp ite.. > git tree: bpf-next > console output: https://syzkaller.appspot.com/x/log.txt?x=10c3b83750 > kernel config:

Re: INFO: rcu detected stall in __se_sys_mount

On Mon, Dec 7, 2020 at 9:06 PM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit 1d0e850a49a5b56f8f3cb51e74a11e2fedb96be6 > Author: David Howells > Date: Fri Oct 16 12:21:14 2020 + > > afs: Fix cell removal > > bisection log:

Re: WARNING: filesystem loop0 was created with 512 inodes, the real maximum is 511, mounting anyway

On Mon, Sep 28, 2020 at 11:08 AM Tigran Aivazian wrote: > > On Mon, 28 Sep 2020 at 09:29, Dmitry Vyukov wrote: > > On Mon, Sep 28, 2020 at 10:23 AM Tigran Aivazian > > > No, this is not an issue. In the latest change to BFS I added the > > > following comment to

Re: WARNING: filesystem loop1 was created with 512 inodes, the real maximum is 511, mounting anyway

#syz fix: bfs: don't use WARNING: string when it's just info. On Mon, Sep 28, 2020 at 8:10 PM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:c9c9e6a4 Merge tag 'trace-v5.9-rc5-2' of git://git.kernel... > git tree: upstream > console output:

Re: WARNING: filesystem loop4 was created with 512 inodes, the real maximum is 511, mounting anyway

#syz fix: bfs: don't use WARNING: string when it's just info. On Sat, Nov 21, 2020 at 8:33 AM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:09162bc3 Linux 5.10-rc4 > git tree: upstream > console output:

Re: WARNING: filesystem loop2 was created with 512 inodes, the real maximum is 511, mounting anyway

#syz fix: bfs: don't use WARNING: string when it's just info. On Sat, Nov 21, 2020 at 8:33 AM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:09162bc3 Linux 5.10-rc4 > git tree: upstream > console output:

Re: WARNING: filesystem loop3 was created with 512 inodes, the real maximum is 511, mounting anyway

#syz fix: bfs: don't use WARNING: string when it's just info. On Thu, Sep 24, 2020 at 11:40 AM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:98477740 Merge branch 'rcu/urgent' of git://git.kernel.org.. > git tree: upstream > console output:

Re: WARNING: filesystem loop0 was created with 512 inodes, the real maximum is 511, mounting anywa

#syz fix: bfs: don't use WARNING: string when it's just info. On Mon, Dec 7, 2020 at 1:53 PM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:34816d20 Merge tag 'gfs2-v5.10-rc5-fixes' of git://git.ker.. > git tree: upstream > console output:

Re: linux-next: build warning after merge of the akpm tree

On Mon, Dec 7, 2020 at 1:08 PM Dmitry Vyukov wrote: > > > Hi all, > > > > > > After merging the akpm tree, today's linux-next build (powerpc > > > allyesconfig) produced warnings like this: > > > > > > kernel/kcov.c:29

Re: linux-next: build warning after merge of the akpm tree

On Sat, Dec 5, 2020 at 6:19 AM Andrew Morton wrote: > > On Fri, 4 Dec 2020 21:00:00 +1100 Stephen Rothwell > wrote: > > > Hi all, > > > > After merging the akpm tree, today's linux-next build (powerpc > > allyesconfig) produced warnings like this: > > > > kernel/kcov.c:296:14: warning:

Re: KASAN: slab-out-of-bounds Read in btrfs_scan_one_device

On Mon, Dec 7, 2020 at 10:34 AM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit 0697d9a610998b8bdee6b2390836cb2391d8fd1a > Author: Johannes Thumshirn > Date: Wed Nov 18 09:03:26 2020 + > > btrfs: don't access possibly stale fs_info data for printing

Re: WARN_ON_ONCE

On Sat, Dec 5, 2020 at 1:05 PM Michael Ellerman wrote: > > Alexey Kardashevskiy writes: > > On 04/12/2020 12:25, Michael Ellerman wrote: > >> Dmitry Vyukov writes: > >>> On Thu, Dec 3, 2020 at 10:19 AM Dmitry Vyukov wrote: > >>>> On T

Re: WARNING: filesystem loop5 was created with 512 inodes, the real maximum is 511, mounting anyway

On Thu, Dec 3, 2020 at 1:55 PM Dmitry Vyukov wrote: > > On Thu, Dec 3, 2020 at 5:15 AM Randy Dunlap wrote: > > > > On 12/1/20 1:17 PM, Randy Dunlap wrote: > > > On 11/30/20 11:47 PM, Dmitry Vyukov wrote: > > >> On Tue, Dec 1, 2020 at 2:03 AM Randy Dunlap

Re: WARNING: filesystem loop5 was created with 512 inodes, the real maximum is 511, mounting anyway

On Thu, Dec 3, 2020 at 5:15 AM Randy Dunlap wrote: > > On 12/1/20 1:17 PM, Randy Dunlap wrote: > > On 11/30/20 11:47 PM, Dmitry Vyukov wrote: > >> On Tue, Dec 1, 2020 at 2:03 AM Randy Dunlap wrote: > >>> > >>> On 11/30/20 12:43 AM, Dmitry Vyukov

Re: WARN_ON_ONCE

On Thu, Dec 3, 2020 at 10:19 AM Dmitry Vyukov wrote: > > On Thu, Dec 3, 2020 at 10:10 AM Alexey Kardashevskiy wrote: > > > > Hi! > > > > Syzkaller triggered WARN_ON_ONCE at > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

Re: [PATCH v5 0/4] kasan: add workqueue stack for generic KASAN

On Thu, Dec 3, 2020 at 3:21 AM Walter Wu wrote: > > Syzbot reports many UAF issues for workqueue, see [1]. > In some of these access/allocation happened in process_one_work(), > we see the free stack is useless in KASAN report, it doesn't help > programmers to solve UAF for workqueue issue. > >

Re: [PATCH v3 1/1] kasan: fix object remain in offline per-cpu quarantine

t_module_slab: Slab cache still has > objects > > Register a cpu hotplug function to remove all objects in the offline > per-cpu quarantine when cpu is going offline. Set a per-cpu variable > to indicate this cpu is offline. > > Signed-off-by: Kuan-Ying Lee > Suggested-by:

Re: WARNING: filesystem loop5 was created with 512 inodes, the real maximum is 511, mounting anyway

On Tue, Dec 1, 2020 at 10:17 PM Randy Dunlap wrote: > > On 11/30/20 11:47 PM, Dmitry Vyukov wrote: > > On Tue, Dec 1, 2020 at 2:03 AM Randy Dunlap wrote: > >> > >> On 11/30/20 12:43 AM, Dmitry Vyukov wrote: > >>> On Mon, Nov 30, 2020 at 5:29 AM Randy Du

Re: [PATCH v4 0/6] kasan: add workqueue and timer stack for generic KASAN

On Tue, Dec 1, 2020 at 3:13 PM Thomas Gleixner wrote: > >> > Syzbot reports many UAF issues for workqueue or timer, see [1] and [2]. > >> > In some of these access/allocation happened in process_one_work(), > >> > we see the free stack is useless in KASAN report, it doesn't help > >> >

Re: [PATCH v4 0/6] kasan: add workqueue and timer stack for generic KASAN

On Tue, Dec 1, 2020 at 12:17 PM Walter Wu wrote: > > Hi Dmitry, > > On Tue, 2020-12-01 at 08:59 +0100, 'Dmitry Vyukov' via kasan-dev wrote: > > On Wed, Sep 30, 2020 at 5:29 PM Thomas Gleixner wrote: > > > > > > On Thu, Sep 24 2020 at 12:01, Walter Wu wrote: &g

Re: [PATCH v4 0/6] kasan: add workqueue and timer stack for generic KASAN

On Wed, Sep 30, 2020 at 5:29 PM Thomas Gleixner wrote: > > On Thu, Sep 24 2020 at 12:01, Walter Wu wrote: > > Syzbot reports many UAF issues for workqueue or timer, see [1] and [2]. > > In some of these access/allocation happened in process_one_work(), > > we see the free stack is useless in

Re: WARNING: filesystem loop5 was created with 512 inodes, the real maximum is 511, mounting anyway

On Tue, Dec 1, 2020 at 2:03 AM Randy Dunlap wrote: > > On 11/30/20 12:43 AM, Dmitry Vyukov wrote: > > On Mon, Nov 30, 2020 at 5:29 AM Randy Dunlap wrote: > >> > >> On 11/27/20 4:32 AM, syzbot wrote: > >>> Hello, > >>> > >>

Re: BUG: rwlock bad magic on CPU, kworker/0:LINE/NUM, ADDR

On Mon, Nov 30, 2020 at 12:33 PM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:90cf87d1 enetc: Let the hardware auto-advance the taprio b.. > git tree: net > console output: https://syzkaller.appspot.com/x/log.txt?x=135479b350 > kernel config:

Re: WARNING: filesystem loop5 was created with 512 inodes, the real maximum is 511, mounting anyway

On Mon, Nov 30, 2020 at 5:29 AM Randy Dunlap wrote: > > On 11/27/20 4:32 AM, syzbot wrote: > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit:418baf2c Linux 5.10-rc5 > > git tree: upstream > > console output:

Re: [PATCH v3] lockdep: Allow tuning tracing capacity constants.

On Sun, Nov 22, 2020 at 2:56 AM Tetsuo Handa wrote: > > On 2020/11/20 18:27, Dmitry Vyukov wrote: > > Peter, so far it looks like just a very large, but normal graph to me. > > The cheapest from an engineering point of view solution would be just > > to increase the

Re: BUG: receive list entry not found for dev vxcan1, id 002, mask C00007FF

On Wed, Nov 25, 2020 at 5:04 PM Oliver Hartkopp wrote: > > Hello all, > > AFAICS the problems are caused by the WARN() statement here: > > https://elixir.bootlin.com/linux/v5.10-rc4/source/net/can/af_can.c#L546 > > The idea was to check whether CAN protocol implementations work > correctly on

Re: [PATCH] rcu: kasan: record and print kvfree_call_rcu call stack

On Fri, Nov 20, 2020 at 3:34 PM Paul E. McKenney wrote: > > On Fri, Nov 20, 2020 at 09:51:15AM +0100, Dmitry Vyukov wrote: > > On Thu, Nov 19, 2020 at 10:49 PM Paul E. McKenney > > wrote: > > > > > > On Wed, Nov 18, 2020 at 11:53:09AM +0800, qiang.zh...@windr

Re: [PATCH] rcu: kasan: record and print kvfree_call_rcu call stack

On Fri, Nov 20, 2020 at 12:59 PM Uladzislau Rezki wrote: > > On Thu, Nov 19, 2020 at 01:49:34PM -0800, Paul E. McKenney wrote: > > On Wed, Nov 18, 2020 at 11:53:09AM +0800, qiang.zh...@windriver.com wrote: > > > From: Zqiang > > > > > > Add kasan_record_aux_stack function for kvfree_call_rcu

Re: [PATCH v3] lockdep: Allow tuning tracing capacity constants.

On Fri, Nov 20, 2020 at 10:22 AM Dmitry Vyukov wrote: > > On Thu, Nov 19, 2020 at 7:08 PM Dmitry Vyukov wrote: > > > > > On Thu, Nov 19, 2020 at 2:45 PM Tetsuo Handa > > > > > wrote: > > > > > > > > > > > > On 2020/11/19 2

Re: [PATCH] rcu: kasan: record and print kvfree_call_rcu call stack

kasan_record_aux_stack(ptr); > > success = kvfree_call_rcu_add_ptr_to_bulk(krcp, ptr); > > if (!success) { > > run_page_cache_worker(krcp); kvfree_call_rcu is intended to free objects, right? If so this is: Acked-by: Dmitry Vyukov

Re: [PATCH v3] lockdep: Allow tuning tracing capacity constants.

On Thu, Nov 19, 2020 at 3:30 PM Dmitry Vyukov wrote: > > > > On Thu, Nov 19, 2020 at 2:45 PM Tetsuo Handa > > wrote: > > > > > > On 2020/11/19 22:06, Dmitry Vyukov wrote: > > > >>>> > > > >>>> I am trying to reproduce

Re: [PATCH v3] lockdep: Allow tuning tracing capacity constants.

On Thu, Nov 19, 2020 at 2:45 PM Tetsuo Handa wrote: > > On 2020/11/19 22:06, Dmitry Vyukov wrote: > >>>> > >>>> I am trying to reproduce this locally first. syzbot caims it can > >>>> reproduce it with a number of very simpler reproducers

Re: [PATCH v3] lockdep: Allow tuning tracing capacity constants.

On Thu, Nov 19, 2020 at 1:49 PM Dmitry Vyukov wrote: > > On Thu, Nov 19, 2020 at 1:43 PM Dmitry Vyukov wrote: > > > On Wed, Nov 18, 2020 at 4:32 PM Tetsuo Handa > > > wrote: > > > > > > > > On 2020/11/19 0:10, Peter Zijlstra wrote: > >

Re: [PATCH v3] lockdep: Allow tuning tracing capacity constants.

On Thu, Nov 19, 2020 at 1:43 PM Dmitry Vyukov wrote: > > On Wed, Nov 18, 2020 at 4:32 PM Tetsuo Handa > > wrote: > > > > > > On 2020/11/19 0:10, Peter Zijlstra wrote: > > > > On Wed, Nov 18, 2020 at 11:30:05PM +0900, Tetsuo Handa wrote: > > >

Re: [PATCH v3] lockdep: Allow tuning tracing capacity constants.

On Thu, Nov 19, 2020 at 1:33 PM Dmitry Vyukov wrote: > > On Wed, Nov 18, 2020 at 4:32 PM Tetsuo Handa > wrote: > > > > On 2020/11/19 0:10, Peter Zijlstra wrote: > > > On Wed, Nov 18, 2020 at 11:30:05PM +0900, Tetsuo Handa wrote: > > >> The problem is th

Re: [PATCH v3] lockdep: Allow tuning tracing capacity constants.

lockdep* before terminating as > a crash as soon as encountering one of > > BUG: MAX_LOCKDEP_ENTRIES too low! > BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low! > BUG: MAX_LOCKDEP_CHAINS too low! > BUG: MAX_LOCKDEP_KEYS too low! > WARNING in print_bfs_bug > > messages? > > On 2020/09/

Re: Collecting both remote and "local" coverage with KCOV

On Wed, Nov 18, 2020 at 3:21 AM Alexander Bulekov wrote: > > On 201116 1805, Andrey Konovalov wrote: > > On Mon, Nov 16, 2020 at 9:35 AM Dmitry Vyukov wrote: > > > > > > On Mon, Nov 16, 2020 at 3:39 AM Alexander Bulekov wrote: > > > > > > > &

Re: [PATCH mm v3 17/19] kasan: clean up metadata allocation and usage

On Fri, Nov 13, 2020 at 11:20 PM Andrey Konovalov wrote: > > KASAN marks caches that are sanitized with the SLAB_KASAN cache flag. > Currently if the metadata that is appended after the object (stores e.g. > stack trace ids) doesn't fit into KMALLOC_MAX_SIZE (can only happen with > SLAB, see the

Re: [PATCH mm v3 19/19] kasan: update documentation

; in particular: defines what a memory granule is, mentions quarantine, > > makes Kunit section more readable. > > > > Signed-off-by: Andrey Konovalov > > Link: > > https://linux-review.googlesource.com/id/Ib1f83e91be273264b25f42b04448ac96b858849f >

Re: [PATCH mm v3 17/19] kasan: clean up metadata allocation and usage

On Tue, Nov 17, 2020 at 2:18 PM Marco Elver wrote: > > On Tue, 17 Nov 2020 at 14:12, Dmitry Vyukov wrote: > > > > +*/ > > > *(u8 *)kasan_mem_to_shadow(object) = KASAN_KMALLOC_FREE; > > > + > > > ___cache_free(cache, object, _

Re: [PATCH mm v3 18/19] kasan, mm: allow cache merging with no metadata

... so I was going to independently propose what Marco already proposed as simplification... until I looked at the patch in the email :) Reviewed-by: Dmitry Vyukov > --- > include/linux/kasan.h | 21 +++-- > mm/kasan/common.c | 11 +++ > mm/slab_common.c

Re: [PATCH mm v3 12/19] kasan, mm: check kasan_enabled in annotations

9451d3c96c97abbcbf714baabe6161c6f153e > > Reviewed-by: Marco Elver Also much nicer with kasan_enabled() now. Reviewed-by: Dmitry Vyukov > > --- > > include/linux/kasan.h | 213 -- > > include/linux/mm.h| 22 +++-- > >

Re: [PATCH mm v3 11/19] kasan: add and integrate kasan boot parameters

hat switching between these modes doesn't require > > rebuilding the kernel with different configs, as this is required by > > the Android GKI (Generic Kernel Image) initiative [1]. > > > > [1] > > https://source.android.com/devices/architecture/kernel/generic-kernel-ima

Re: [PATCH mm v3 08/19] kasan: inline random_tag for HW_TAGS

ned-off-by: Andrey Konovalov > Reviewed-by: Marco Elver Reviewed-by: Dmitry Vyukov > Link: > https://linux-review.googlesource.com/id/Iac5b2faf9a912900e16cca6834d621f5d4abf427 > --- > mm/kasan/hw_tags.c | 5 - > mm/kasan/kasan.h | 31 ++- >

Re: [PATCH mm v3 07/19] kasan: inline kasan_reset_tag for tag-based modes

inline function. Also remove the now unneeded reset_tag() internal KASAN > macro and use kasan_reset_tag() instead. > > Signed-off-by: Andrey Konovalov > Reviewed-by: Marco Elver Reviewed-by: Dmitry Vyukov > Link: > https://linux-review.googlesource.com/id/I4d2061a

suspicious capability check in ovl_ioctl_set_flags

Hi Miklos, We've detected a suspicious double-fetch of user-space data in ovl_ioctl_set_flags using a prototype tool (see report below [1]). It points to ovl_ioctl_set_flags that does a capability check using flags, but then the real ioctl double-fetches flags and uses potentially different

Re: [PATCH v2 1/1] kasan: fix object remain in offline per-cpu quarantine

On Tue, Nov 17, 2020 at 7:46 AM Kuan-Ying Lee wrote: > > On Mon, 2020-11-16 at 10:26 +0100, Dmitry Vyukov wrote: > > On Mon, Nov 16, 2020 at 7:30 AM Kuan-Ying Lee > > wrote: > > > > > > We hit this issue in our internal test. > > > When enabling gene

Re: [PATCH RFC v2 04/21] kasan: unpoison stack only with CONFIG_KASAN_STACK

On Mon, Nov 16, 2020 at 1:16 PM Catalin Marinas wrote: > > On Mon, Nov 16, 2020 at 12:50:00PM +0100, Marco Elver wrote: > > On Mon, 16 Nov 2020 at 11:59, Dmitry Vyukov wrote: > > > On Thu, Oct 29, 2020 at 8:57 PM 'Andrey Konovalov' via kasan-dev > > > wrote: > &

Re: KASAN: invalid-free in p9_client_create

On Mon, Nov 16, 2020 at 11:30 AM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:92edc4ae Add linux-next specific files for 20201113 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=142f881650 > kernel config:

Re: [PATCH mm v3 05/19] kasan: allow VMAP_STACK for HW_TAGS mode

t; > Signed-off-by: Andrey Konovalov > Reviewed-by: Marco Elver Reviewed-by: Dmitry Vyukov > Acked-by: Catalin Marinas > Link: > https://linux-review.googlesource.com/id/I3552cbc12321dec82cd7372676e9372a2eb452ac > --- > arch/Kconfig | 8 > 1 file changed, 4 inser

Re: [PATCH mm v3 04/19] kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK

> > Signed-off-by: Andrey Konovalov > Reviewed-by: Marco Elver Reviewed-by: Dmitry Vyukov > Acked-by: Catalin Marinas > Link: > https://linux-review.googlesource.com/id/If8a891e9fe01ea543e00b576852685afec0887e3 > --- > arch/arm64/kernel/sleep.S| 2 +- > ar

Re: [PATCH RFC v2 04/21] kasan: unpoison stack only with CONFIG_KASAN_STACK

On Thu, Oct 29, 2020 at 8:57 PM 'Andrey Konovalov' via kasan-dev wrote: > > On Tue, Oct 27, 2020 at 1:44 PM Dmitry Vyukov wrote: > > > > On Thu, Oct 22, 2020 at 3:19 PM Andrey Konovalov > > wrote: > > > > > > There's a config option CONFIG_KASAN_ST

Re: [PATCH v2 1/1] kasan: fix object remain in offline per-cpu quarantine

t_module_slab: Slab cache still has > objects > > Register a cpu hotplug function to remove all objects in the offline > per-cpu quarantine when cpu is going offline. Set a per-cpu variable > to indicate this cpu is offline. > > Signed-off-by: Kuan-Ying Lee > Suggested-by: Dmitry

Re: Collecting both remote and "local" coverage with KCOV

On Mon, Nov 16, 2020 at 3:39 AM Alexander Bulekov wrote: > > Hello, > I'm trying to collect coverage over the syscalls issued by my process, > as well as the kthreads spawned as a result of these syscalls > (eg coverage over vhost ioctls and the worker kthread). Is there a way > to collect

Re: bpf test error: BUG: sleeping function called from invalid context in sta_info_move_state

On Sat, Nov 14, 2020 at 9:42 AM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:96021828 MAINTAINERS/bpf: Update Andrii's entry. > git tree: bpf > console output: https://syzkaller.appspot.com/x/log.txt?x=102717be50 > kernel config:

Re: INFO: task hung in reboot

On Sat, Nov 14, 2020 at 2:42 PM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:e7018751 usb: host: ehci-mxc: Remove the driver > git tree: > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing > console output:

Re: KASAN: use-after-free Write in afs_manage_cell

On Sat, Nov 14, 2020 at 2:58 PM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit 1d0e850a49a5b56f8f3cb51e74a11e2fedb96be6 > Author: David Howells > Date: Fri Oct 16 12:21:14 2020 + > > afs: Fix cell removal > > bisection log:

Re: INFO: task can't die in nbd_ioctl

On Tue, Nov 3, 2020 at 8:21 AM Ming Lei wrote: > > On Sat, Oct 31, 2020 at 4:01 AM syzbot > wrote: > > > > syzbot has found a reproducer for the following issue on: > > > > HEAD commit:4e78c578 Add linux-next specific files for 20201030 > > git tree: linux-next > > console output:

Re: kernel panic: stack is corrupted in get_kernel_gp_address

On Fri, Nov 13, 2020 at 9:27 AM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit a49145acfb975d921464b84fe00279f99827d816 > Author: George Kennedy > Date: Tue Jul 7 19:26:03 2020 + > > fbmem: add margin check to fb_check_caps() > > bisection log:

Re: [PATCH 1/1] kasan: fix object remain in offline per-cpu quarantine

On Fri, Nov 13, 2020 at 3:32 AM Kuan-Ying Lee wrote: > > On Thu, 2020-11-12 at 09:39 +0100, Dmitry Vyukov wrote: > > On Thu, Nov 12, 2020 at 7:25 AM Kuan-Ying Lee > > wrote: > > > > > > We hit this issue in our internal test. > > > When enabling gene

Re: Process-wide watchpoints

On Thu, Nov 12, 2020 at 11:31 AM Peter Zijlstra wrote: > > On Thu, Nov 12, 2020 at 08:46:23AM +0100, Dmitry Vyukov wrote: > > > for sampling race detection), > > number of threads in the process can be up to, say, ~~10K and the > > watchpoint is intended to be set for

Re: WARNING in irqentry_exit

On Thu, Nov 12, 2020 at 3:01 AM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit 4d004099a668c41522242aa146a38cc4eb59cb1e > Author: Peter Zijlstra > Date: Fri Oct 2 09:04:21 2020 + > > lockdep: Fix lockdep recursion > > bisection log:

Re: [PATCH 1/1] kasan: fix object remain in offline per-cpu quarantine

On Thu, Nov 12, 2020 at 7:25 AM Kuan-Ying Lee wrote: > > We hit this issue in our internal test. > When enabling generic kasan, a kfree()'d object is put into per-cpu > quarantine first. If the cpu goes offline, object still remains in > the per-cpu quarantine. If we call kmem_cache_destroy()

Process-wide watchpoints

Hello perf maintainers, I have a wish for a particular kernel functionality related to watchpoints, and I would appreciate it if you can say how feasible/complex to add it is (mostly glueing existing infra pieces, or redesigning and adding lots of new code), or maybe it exists already and I am

Re: KASAN: vmalloc-out-of-bounds Read in bpf_trace_run3

On Mon, Nov 2, 2020 at 12:54 PM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:080b6f40 bpf: Don't rely on GCC __attribute__((optimize)) .. > git tree: bpf > console output: https://syzkaller.appspot.com/x/log.txt?x=1089d37c50 > kernel config:

Re: WARNING in wp_page_copy

On Tue, Mar 24, 2020 at 3:47 AM syzbot wrote: > > syzbot suspects this bug was fixed by commit: > > commit c3e5ea6ee574ae5e845a40ac8198de1fb63bb3ab > Author: Kirill A. Shutemov > Date: Fri Mar 6 06:28:32 2020 + > > mm: avoid data corruption on CoW fault into PFN-mapped VMA > >

Re: inconsistent lock state in icmp_send

On Mon, May 25, 2020 at 12:19 PM syzbot wrote: > > syzbot suspects this bug was fixed by commit: > > commit 1378817486d6860f6a927f573491afe65287abf1 > Author: Eric Dumazet > Date: Thu May 21 18:29:58 2020 + > > tipc: block BH before using dst_cache > > bisection log:

Re: INFO: task hung in ctrl_getfamily

On Mon, Sep 14, 2020 at 12:43 PM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit 47733f9daf4fe4f7e0eb9e273f21ad3a19130487 > Author: Cong Wang > Date: Sat Aug 15 23:29:15 2020 + > > tipc: fix uninit skb->data in tipc_nl_compat_dumpit() > > bisection log:

Re: WARNING: refcount bug in p9_req_put

On Sat, Aug 15, 2020 at 7:23 AM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit a39c46067c845a8a2d7144836e9468b7f072343e > Author: Christoph Hellwig > Date: Fri Jul 10 08:57:22 2020 + > > net/9p: validate fds in p9_fd_open > > bisection log:

Re: possible deadlock in mnt_want_write

On Sat, Nov 7, 2020 at 1:10 PM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit 146d62e5a5867fbf84490d82455718bfb10fe824 > Author: Amir Goldstein > Date: Thu Apr 18 14:42:08 2019 + > > ovl: detect overlapping layers > > bisection log:

Re: INFO: rcu detected stall in do_swap_page

On Thu, Nov 7, 2019 at 3:25 PM syzbot wrote: > > syzbot suspects this bug was fixed by commit: > > commit 32aaf0553df99cc4314f6e9f43216cd83afc6c20 > Author: Pengfei Li > Date: Mon Sep 23 22:36:58 2019 + > > mm/compaction.c: remove unnecessary zone parameter in > isolate_migratepages()

Re: INFO: task hung in flush_to_ldisc

On Tue, Mar 17, 2020 at 10:43 AM syzbot wrote: > > syzbot suspects this bug was fixed by commit: > > commit e8c75a30a23c6ba63f4ef6895cbf41fd42f21aa2 > Author: Jiri Slaby > Date: Fri Feb 28 11:54:06 2020 + > > vt: selection, push sel_lock up > > bisection log:

Re: WARNING in percpu_ref_exit (2)

On Wed, Nov 11, 2020 at 4:09 AM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit c1e2148f8ecb26863b899d402a823dab8e26efd1 > Author: Jens Axboe > Date: Wed Mar 4 14:25:50 2020 + > > io_uring: free fixed_file_data after RCU grace period > > bisection log:

Re: INFO: task hung in htable_put

On Fri, Mar 20, 2020 at 5:42 AM syzbot wrote: > > syzbot suspects this bug was fixed by commit: > > commit 99b79c3900d4627672c85d9f344b5b0f06bc2a4d > Author: Cong Wang > Date: Thu Feb 13 06:53:52 2020 + > > netfilter: xt_hashlimit: unregister proc file before releasing mutex > >

Re: WARNING: refcount bug in l2cap_chan_put

On Sun, Sep 6, 2020 at 3:07 AM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit b83764f9220a4a14525657466f299850bbc98de9 > Author: Miao-chen Chou > Date: Tue Jun 30 03:15:00 2020 + > > Bluetooth: Fix kernel oops triggered by hci_adv_monitors_clear() > >

Re: KASAN: use-after-free Write in refcount_warn_saturate

On Fri, Sep 4, 2020 at 4:44 PM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit b83764f9220a4a14525657466f299850bbc98de9 > Author: Miao-chen Chou > Date: Tue Jun 30 03:15:00 2020 + > > Bluetooth: Fix kernel oops triggered by hci_adv_monitors_clear() > >

Re: INFO: trying to register non-static key in uhid_dev_destroy

On Tue, Oct 6, 2020 at 6:54 AM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit bce1305c0ece3dc549663605e567655dd701752c > Author: Marc Zyngier > Date: Sat Aug 29 11:26:01 2020 + > > HID: core: Correctly handle ReportSize being zero > > bisection log:

Re: INFO: trying to register non-static key in uhid_char_release

On Wed, Oct 7, 2020 at 7:01 PM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit bce1305c0ece3dc549663605e567655dd701752c > Author: Marc Zyngier > Date: Sat Aug 29 11:26:01 2020 + > > HID: core: Correctly handle ReportSize being zero > > bisection log:

Re: general protection fault in tcf_action_destroy (2)

On Wed, Apr 29, 2020 at 5:03 AM syzbot wrote: > > syzbot suspects this bug was fixed by commit: > > commit 0d1c3530e1bd38382edef72591b78e877e0edcd3 > Author: Cong Wang > Date: Thu Mar 12 05:42:28 2020 + > > net_sched: keep alloc_hash updated after hash allocation > > bisection log:

Re: KASAN: use-after-free Write in tcindex_change

On Fri, Apr 17, 2020 at 9:05 PM syzbot wrote: > > syzbot suspects this bug was fixed by commit: > > commit 0d1c3530e1bd38382edef72591b78e877e0edcd3 > Author: Cong Wang > Date: Thu Mar 12 05:42:28 2020 + > > net_sched: keep alloc_hash updated after hash allocation > > bisection log:

Re: WARNING: refcount bug in do_enable_set

On Sun, Sep 6, 2020 at 7:31 AM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit b83764f9220a4a14525657466f299850bbc98de9 > Author: Miao-chen Chou > Date: Tue Jun 30 03:15:00 2020 + > > Bluetooth: Fix kernel oops triggered by hci_adv_monitors_clear() > >

Re: WARNING: suspicious RCU usage in ctrl_cmd_new_lookup

On Thu, Oct 22, 2020 at 2:40 PM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit a7809ff90ce6c48598d3c4ab54eb599bec1e9c42 > Author: Manivannan Sadhasivam > Date: Sat Sep 26 16:56:25 2020 + > > net: qrtr: ns: Protect radix_tree_deref_slot() using rcu read

Re: WARNING in rxrpc_recvmsg

On Thu, Aug 6, 2020 at 5:25 AM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit 65550098c1c4db528400c73acf3e46bfa78d9264 > Author: David Howells > Date: Tue Jul 28 23:03:56 2020 + > > rxrpc: Fix race between recvmsg and sendmsg on immediate call failure > >

Re: KASAN: use-after-free Read in __cfg8NUM_wpan_dev_from_attrs (2)

On Thu, Aug 6, 2020 at 9:00 AM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit bf64ff4c2aac65d680dc639a511c781cf6b6ec08 > Author: Cong Wang > Date: Sat Jun 27 07:12:24 2020 + > > genetlink: get rid of family->attrbuf > > bisection log:

Re: BUG: corrupted list in kobject_add_internal

On Sun, Nov 8, 2020 at 11:55 PM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit a46b7ed4d52d09bd6c7ab53b2217d04fc2f02c65 > Author: Sonny Sasaka > Date: Fri Aug 14 19:09:09 2020 + > > Bluetooth: Fix auto-creation of hci_conn at Conn Complete event > >

Re: INFO: task hung in io_uring_flush

On Thu, Sep 17, 2020 at 3:42 AM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit b7ddce3cbf010edbfac6c6d8cc708560a7bcd7a4 > Author: Pavel Begunkov > Date: Sat Sep 5 21:45:14 2020 + > > io_uring: fix cancel of deferred reqs with ->files > > bisection log:

Re: general protection fault in rt6_fill_node

On Thu, Oct 1, 2020 at 8:46 PM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit eeaac3634ee0e3f35548be35275efeca888e9b23 > Author: Nikolay Aleksandrov > Date: Sat Aug 22 12:06:36 2020 + > > net: nexthop: don't allow empty NHA_GROUP > > bisection log:

Re: WARNING: ODEBUG bug in exit_to_user_mode_prepare

On Fri, Aug 28, 2020 at 5:08 PM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:d012a719 Linux 5.9-rc2 > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=15e9e90e90 > kernel config:

Re: general protection fault in nexthop_is_blackhole

On Thu, Oct 1, 2020 at 5:34 PM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit eeaac3634ee0e3f35548be35275efeca888e9b23 > Author: Nikolay Aleksandrov > Date: Sat Aug 22 12:06:36 2020 + > > net: nexthop: don't allow empty NHA_GROUP > > bisection log:

Re: KASAN: use-after-free Read in delete_partition

On Thu, Oct 8, 2020 at 5:38 AM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit 08fc1ab6d748ab1a690fd483f41e2938984ce353 > Author: Christoph Hellwig > Date: Tue Sep 1 09:59:41 2020 + > > block: fix locking in bdev_del_partition > > bisection log:

Re: INFO: rcu detected stall in exit_group

On Mon, Nov 9, 2020 at 12:03 PM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit 1d0e850a49a5b56f8f3cb51e74a11e2fedb96be6 > Author: David Howells > Date: Fri Oct 16 12:21:14 2020 + > > afs: Fix cell removal > > bisection log:

Re: WARNING in syscall_exit_to_user_mode

On Sun, Nov 8, 2020 at 6:22 PM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit a49145acfb975d921464b84fe00279f99827d816 > Author: George Kennedy > Date: Tue Jul 7 19:26:03 2020 + > > fbmem: add margin check to fb_check_caps() > > bisection log:

<    1   2   3   4   5   6   7   8   9   10   >