drm: WARNING in ioremap_wc

On Mon, Aug 29, 2016 at 8:05 AM, Daniel Vetter wrote: > On Sun, Aug 28, 2016 at 07:36:59PM +0200, Dmitry Vyukov wrote: >> Hello, >> >> The following program triggers WARNING in ioremap_wc: > > Yup, that should also be fixed in linux-next. Probably better to not >

drm: NULL pointer dereference in drm_mode_object_find()

On Fri, Aug 19, 2016 at 7:10 PM, Alexander Potapenko wrote: > Hello, > > the program below triggers a NULL deref in DRM code when ran on QEMU: > > === > BUG: unable to handle kernel NULL pointer dereference at (null) > IP: [< inline

drm: GPF in drm_getcap

Hello, The following program triggers GPF in drm_getcap: // autogenerated by syzkaller (http://github.com/google/syzkaller) #include #include #include #include #include #include #include #include int main() { int fd = open("/dev/dri/card0", O_RDONLY); uint64_t data[2] = {0x11,

[PATCH v2] drivers/gpu/vga: allocate vga_arb_write() buffer on stack

Size of kmalloc() in vga_arb_write() is controlled by user. Too large kmalloc() size triggers WARNING message on console. Allocate the buffer on stack to avoid the WARNING. The string must be small (e.g "target PCI:domain:bus:dev.fn"). Signed-off-by: Dmitry Vyukov Reviewed-by: Vill

[PATCH] drivers/gpu/vga: allocate vga_arb_write() buffer on stack

On Fri, Oct 14, 2016 at 3:06 PM, Ville Syrjälä wrote: > On Fri, Oct 14, 2016 at 02:54:59PM +0200, Dmitry Vyukov wrote: >> Size of kmalloc() in vga_arb_write() is controlled by user. >> Too large kmalloc() size triggers WARNING message on console. >> Allocate the buf

[PATCH] drivers/gpu/vga: allocate vga_arb_write() buffer on stack

Size of kmalloc() in vga_arb_write() is controlled by user. Too large kmalloc() size triggers WARNING message on console. Allocate the buffer on stack to avoid the WARNING. The string must be small (e.g "target PCI:domain:bus:dev.fn"). Signed-off-by: Dmitry Vyukov Cc: Dave Airlie

[PATCH v2] drivers/gpu/vga: allocate vga_arb_write() buffer on stack

On Fri, Oct 14, 2016 at 3:22 PM, Dmitry Vyukov wrote: > Size of kmalloc() in vga_arb_write() is controlled by user. > Too large kmalloc() size triggers WARNING message on console. > Allocate the buffer on stack to avoid the WARNING. > The string must be small (e.g "target PCI:

drm: GPF in drm_getcap

On Fri, Sep 9, 2016 at 1:56 PM, Dmitry Vyukov wrote: > Hello, > > The following program triggers GPF in drm_getcap: > > // autogenerated by syzkaller (http://github.com/google/syzkaller) > #include > #include > #include > #include > #include > #include >

drm: GPF in drm_getcap

Hi > > On Sat, Nov 26, 2016 at 6:50 PM, Dmitry Vyukov wrote: >> On Sat, Nov 26, 2016 at 6:35 PM, David Herrmann >> wrote: >>> Hi >>> >>> On Sat, Nov 26, 2016 at 6:17 PM, Dmitry Vyukov >>> wrote: >>>> On Fri, Sep 9, 2016 at 1:56

drm: GPF in drm_getcap

On Sat, Nov 26, 2016 at 6:35 PM, David Herrmann wrote: > Hi > > On Sat, Nov 26, 2016 at 6:17 PM, Dmitry Vyukov wrote: >> On Fri, Sep 9, 2016 at 1:56 PM, Dmitry Vyukov wrote: >>> Hello, >>> >>> The following program triggers GPF in drm_getcap: &

drm: GPF in drm_getcap

On Mon, Nov 28, 2016 at 8:14 AM, Michel Dänzer wrote: > On 28/11/16 03:55 PM, Daniel Vetter wrote: >> On Sat, Nov 26, 2016 at 7:22 PM, David Herrmann >> wrote: >>> On Sat, Nov 26, 2016 at 7:07 PM, Dmitry Vyukov >>> wrote: >>>> grep &quo

gpu: kmalloc size WARNING in vga_arb_write

Hello, I've hit the following warning while running syzkaller fuzzer: [ cut here ] WARNING: CPU: 2 PID: 29322 at mm/page_alloc.c:2999 __alloc_pages_nodemask+0x7d2/0x1760() Modules linked in: CPU: 2 PID: 29322 Comm: syz-executor Tainted: GB 4.5.0-rc1+ #283

drm: WARNING in drm_irq_by_busid

Hello, I've got the following WARNING while running syzkaller fuzzer: [ cut here ] WARNING: CPU: 1 PID: 16092 at drivers/gpu/drm/drm_pci.c:182 drm_irq_by_busid+0x3c0/0x4a0 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 16092 Comm: syz-executor Not tainted

drm: WARNING in ioremap_wc

Hello, The following program triggers WARNING in ioremap_wc: [ cut here ] LoadPin: kernel-module denied obj="/memfd: (deleted)" pid=12061 cmdline="/tmp/syz-executor" WARNING: CPU: 1 PID: 12056 at arch/x86/mm/ioremap.c:121[< none >] __ioremap_caller+0x348/0x6b0

dri: WARNING in idr_remove

Hello, The following program causes a WARNING in idr_remove: [ cut here ] WARNING: CPU: 3 PID: 26766 at lib/idr.c:505 idr_remove called for id=1 which is not allocated. CPU: 3 PID: 26766 Comm: syz-executor Not tainted 4.8.0-rc3+ #33 Hardware name: QEMU Standard PC (i440FX

drm: GPF in drm_legacy_lock_free

Hello, The following program trigger GPF in drm_legacy_lock_free: general protection fault: [#1] SMP DEBUG_PAGEALLOC KASAN Modules linked in: CPU: 2 PID: 3379 Comm: syz-executor Not tainted 4.8.0-rc3+ #35 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task:

drm: GPF in drm_context_switch_complete

Hello, The following program triggers GPF in drm_context_switch_complete: kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] SMP DEBUG_PAGEALLOC KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 1 PID: 1965 Comm:

[PATCH] drivers/gpu/vga: use __GFP_NOWARN for user-controlled kmalloc

Size of kmalloc() in vga_arb_write() is controlled by user. Too large kmalloc() size triggers WARNING message on console. Use GFP_USER | __GFP_NOWARN for this kmalloc() to not scare admins. Signed-off-by: Dmitry Vyukov --- Example WARNING: WARNING: CPU: 2 PID: 29322 at mm/page_alloc.c:2999

[PATCH] drivers/gpu/vga: use __GFP_NOWARN for user-controlled kmalloc

On Thu, Feb 4, 2016 at 5:59 PM, Ville Syrjälä wrote: > On Thu, Feb 04, 2016 at 05:37:49PM +0100, Dmitry Vyukov wrote: >> On Thu, Feb 4, 2016 at 5:32 PM, Ville Syrjälä >> wrote: >> > On Thu, Feb 04, 2016 at 04:49:49PM +0100, Dmitry Vyukov wrote: >> >>

[PATCH] drivers/gpu/vga: use __GFP_NOWARN for user-controlled kmalloc

On Thu, Feb 4, 2016 at 5:32 PM, Ville Syrjälä wrote: > On Thu, Feb 04, 2016 at 04:49:49PM +0100, Dmitry Vyukov wrote: >> Size of kmalloc() in vga_arb_write() is controlled by user. >> Too large kmalloc() size triggers WARNING message on console. >> >>

Re: d17a1d97dc ("x86/mm/kasan: don't use vmemmap_populate() to initialize shadow"): BUG: KASAN: use-after-scope in __drm_mm_interval_first

rd Biesheuvel <ard.biesheu...@linaro.org> > Cc: Catalin Marinas <catalin.mari...@arm.com> > Cc: Christian Borntraeger <borntrae...@de.ibm.com> > Cc: David S. Miller <da...@davemloft.net> > Cc: Dmitry Vyukov <dvyu...@google.com> > Cc:

Re: WARNING in drm_modeset_lock_all

On Tue, Oct 31, 2017 at 3:45 PM, Chris Wilson wrote: > Quoting syzbot (2017-10-27 09:09:50) >> This bug is generated by a dumb bot. It may contain errors. >> See https://goo.gl/tpsmEJ for details. >> Direct all questions to syzkal...@googlegroups.com. >> >> syzbot will

Re: WARNING in drm_modeset_lock_all

On Tue, Oct 31, 2017 at 2:03 PM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Tue, Oct 31, 2017 at 3:45 PM, Chris Wilson <ch...@chris-wilson.co.uk> > wrote: >> Quoting syzbot (2017-10-27 09:09:50) >>> This bug is generated by a dumb bot. It may contain erro

Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)

On Wed, Aug 1, 2018 at 12:23 PM, Eric Dumazet wrote: > On 08/01/2018 02:03 AM, Andrey Ryabinin wrote: > >> I can't think of any advantage in not having the constructor. > > I can't see any advantage adding another indirect call, > in RETPOLINE world. Can you please elaborate what's the problem

Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)

On Wed, Aug 1, 2018 at 1:28 PM, Eric Dumazet wrote: > On 08/01/2018 03:34 AM, Dmitry Vyukov wrote: >> On Wed, Aug 1, 2018 at 12:23 PM, Eric Dumazet wrote: >>> On 08/01/2018 02:03 AM, Andrey Ryabinin wrote: >>> >>>> I can't think of any advantage in not havi

Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)

On Wed, Aug 1, 2018 at 6:25 PM, Eric Dumazet wrote: > On 08/01/2018 09:22 AM, Christopher Lameter wrote: >> On Wed, 1 Aug 2018, Eric Dumazet wrote: >> >>> The idea of having a ctor() would only be a win if all the fields that >>> can be initialized in the ctor are contiguous and fill an integral

Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)

On Wed, Aug 1, 2018 at 3:46 PM, Florian Westphal wrote: > Dmitry Vyukov wrote: >> If that scenario is possible that a fix would be to make > > Looks possible. > >> __nf_conntrack_find_get ever return NULL iff it got NULL from >> nf_conntrack_find (not if any of

Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)

On Wed, Aug 1, 2018 at 10:46 AM, Dmitry Vyukov wrote: > On Tue, Jul 31, 2018 at 8:51 PM, Linus Torvalds > wrote: >> On Tue, Jul 31, 2018 at 10:49 AM Linus Torvalds >> wrote: >>> >>> So the re-use might initialize the fields lazily, not necessarily us

Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)

On Wed, Aug 1, 2018 at 5:37 PM, Eric Dumazet wrote: > On Wed, Aug 1, 2018 at 8:15 AM Christopher Lameter wrote: >> >> On Wed, 1 Aug 2018, Dmitry Vyukov wrote: >> >> > But we are trading 1 indirect call for comparable overhead removed >> > from much mor

Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)

On Wed, Aug 1, 2018 at 12:35 PM, Florian Westphal wrote: > Dmitry Vyukov wrote: >> Still can't grasp all details. >> There is state that we read without taking ct->ct_general.use ref >> first, namely ct->state and what's used by nf_ct_key_equal. >> So le

Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)

On Tue, Jul 31, 2018 at 7:41 PM, Eric Dumazet wrote: > On Tue, Jul 31, 2018 at 10:36 AM Christopher Lameter wrote: > >> >> If there is refcounting going on then why use SLAB_TYPESAFE_BY_RCU? > > To allow fast reuse of objects, without going through call_rcu() and > reducing cache efficiency. > >

Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)

On Wed, Aug 1, 2018 at 1:40 PM, Florian Westphal wrote: > Dmitry Vyukov wrote: >> On Wed, Aug 1, 2018 at 12:35 PM, Florian Westphal wrote: >> > Dmitry Vyukov wrote: >> >> Still can't grasp all details. >> >> There is state that we read without taking

Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)

On Tue, Jul 31, 2018 at 8:51 PM, Linus Torvalds wrote: > On Tue, Jul 31, 2018 at 10:49 AM Linus Torvalds > wrote: >> >> So the re-use might initialize the fields lazily, not necessarily using a >> ctor. > > In particular, the pattern that nf_conntrack uses looks like it is safe. > > If you have

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

On Thu, Oct 25, 2018 at 9:18 PM, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:bd6bf7c10484 Merge tag 'pci-v4.20-changes' of git://git.ke.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1448a68340 > kernel config:

Re: WARNING: lock held when returning to user space! (3)

On Wed, Jan 2, 2019 at 11:59 AM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:903b77c63167 Merge tag 'linux-kselftest-4.21-rc1' of git:/.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1424673b40 > kernel config:

Re: WARNING: lock held when returning to user space in set_property_atomic

On Thu, Jan 3, 2019 at 9:55 AM Maarten Lankhorst wrote: > > Op 30-12-2018 om 07:21 schreef syzbot: > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit:903b77c63167 Merge tag 'linux-kselftest-4.21-rc1' of git:/.. > > git tree: upstream > > console output:

Re: [PATCH] drm/vkms: fix use-after-free when drm_gem_handle_create() fails

On Tue, Mar 5, 2019 at 12:23 AM Rodrigo Siqueira wrote: > > On 02/28, Dmitry Vyukov wrote: > > On Thu, Feb 28, 2019 at 12:12 AM Rodrigo Siqueira > > wrote: > > > > > > On 02/26, Eric Biggers wrote: > > > > From: Eric Biggers > > > >

Re: [PATCH] drm/vkms: fix use-after-free when drm_gem_handle_create() fails

On Thu, Feb 28, 2019 at 12:12 AM Rodrigo Siqueira wrote: > > On 02/26, Eric Biggers wrote: > > From: Eric Biggers > > > > If drm_gem_handle_create() fails in vkms_gem_create(), then the > > vkms_gem_object is freed twice: once when the reference is dropped by > > drm_gem_object_put_unlocked(),

Re: INFO: rcu detected stall in sys_sendfile64 (2)

On Tue, Mar 12, 2019 at 5:08 AM Al Viro wrote: > > On Mon, Mar 11, 2019 at 08:59:00PM -0700, syzbot wrote: > > syzbot has bisected this bug to: > > > > commit 34e07e42c55aeaa78e93b057a6664e2ecde3fadb > > Author: Chris Wilson > > Date: Thu Feb 8 10:54:48 2018 + > > > > drm/i915: Add

Re: WARNING in vkms_vblank_simulate

On Mon, Mar 11, 2019 at 1:28 PM syzbot wrote: > > syzbot has bisected this bug to: > > commit 09ef09b4ab95dc405ad4171ec2cd8a4ff5227108 > Author: Shayenne Moura > Date: Wed Feb 6 20:08:13 2019 + > > drm/vkms: WARN when hrtimer_forward_now fails +Shayenne This should have been

Re: WARNING in bpf_jit_free

On Tue, Jun 11, 2019 at 10:04 AM Daniel Vetter wrote: > > On Sat, Jun 08, 2019 at 04:22:06AM -0700, syzbot wrote: > > syzbot has found a reproducer for the following crash on: > > > > HEAD commit:79c3ba32 Merge tag 'drm-fixes-2019-06-07-1' of git://anong.. > > git tree: upstream > >

Re: WARNING in bpf_jit_free

On Tue, Jun 11, 2019 at 11:01 AM Daniel Vetter wrote: > > On Tue, Jun 11, 2019 at 10:51:23AM +0200, Daniel Vetter wrote: > > On Tue, Jun 11, 2019 at 10:33:21AM +0200, Dmitry Vyukov wrote: > > > On Tue, Jun 11, 2019 at 10:04 AM Daniel Vetter wrote: > > > > >

Re: kernel panic: stack is corrupted in pointer

On Wed, Jul 17, 2019 at 10:58 AM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:1438cde7 Add linux-next specific files for 20190716 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=1398805860 > kernel config:

Re: memory leak in dma_buf_ioctl

On Wed, Jul 24, 2019 at 11:48 AM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:abdfd52a Merge tag 'armsoc-defconfig' of git://git.kernel... > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=131441d060 > kernel

Re: kernel panic: stack is corrupted in pointer

On Tue, Jul 23, 2019 at 7:26 PM John Fastabend wrote: > > Dmitry Vyukov wrote: > > On Wed, Jul 17, 2019 at 10:58 AM syzbot > > wrote: > > > > > > Hello, > > > > > > syzbot found the following crash on: > > > > > > HEAD commi

Re: WARNING in drm_mode_createblob_ioctl

On Wed, Nov 6, 2019 at 4:30 PM Daniel Vetter wrote: > > On Wed, Nov 6, 2019 at 4:20 PM syzbot > wrote: > > > > syzbot has bisected this bug to: > > > > commit 9e5a64c71b2f70ba530f8156046dd7dfb8a7a0ba > > Author: Kees Cook > > Date: Mon Nov 4 22:57:23 2019 + > > > > uaccess: disallow

Re: WARNING in drm_mode_createblob_ioctl

On Wed, Nov 6, 2019 at 4:28 PM Daniel Vetter wrote: > > On Wed, Nov 6, 2019 at 4:23 PM Daniel Vetter wrote: > > > > On Wed, Nov 6, 2019 at 4:20 PM syzbot > > wrote: > > > > > > syzbot has bisected this bug to: > > > > > > commit 9e5a64c71b2f70ba530f8156046dd7dfb8a7a0ba > > > Author: Kees Cook

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

On Tue, Dec 3, 2019 at 11:37 PM Daniel Vetter wrote: > > On Tue, Dec 3, 2019 at 11:25 PM syzbot > wrote: > > > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit:76bb8b05 Merge tag 'kbuild-v5.5' of git://git.kernel.org/p.. > > git tree: upstream > > console

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

On Fri, Dec 6, 2019 at 5:34 PM syzbot wrote: > > syzbot has bisected this bug to: > > commit 2de50e9674fc4ca3c6174b04477f69eb26b4ee31 > Author: Russell Currey > Date: Mon Feb 8 04:08:20 2016 + > > powerpc/powernv: Remove support for p5ioc2 Another weird one, I must be missing

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

On Thu, Dec 5, 2019 at 11:13 AM Paolo Bonzini wrote: > > On 04/12/19 22:41, syzbot wrote: > > syzbot has bisected this bug to: > > > > commit 2de50e9674fc4ca3c6174b04477f69eb26b4ee31 > > Author: Russell Currey > > Date: Mon Feb 8 04:08:20 2016 + > > > > powerpc/powernv: Remove support

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

On Thu, Dec 5, 2019 at 11:53 AM Paolo Bonzini wrote: > > On 05/12/19 11:31, Dmitry Vyukov wrote: > >> Ah, and because the machine is a KVM guest, kvm_wait appears in a lot of > >> backtrace and I get to share syzkaller's joy every time. :) > > I don't see any mentio

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

On Thu, Dec 5, 2019 at 11:41 AM Tetsuo Handa wrote: > > On 2019/12/05 19:22, Paolo Bonzini wrote: > > Ah, and because the machine is a KVM guest, kvm_wait appears in a lot of > > backtrace and I get to share syzkaller's joy every time. :) > > > > This bisect result is bogus, though Tetsuo found

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

On Thu, Dec 5, 2019 at 11:22 AM Paolo Bonzini wrote: > > On 05/12/19 11:16, Dmitry Vyukov wrote: > > On Thu, Dec 5, 2019 at 11:13 AM Paolo Bonzini wrote: > >> > >> On 04/12/19 22:41, syzbot wrote: > >>> syzbot has bisected this bug to: > >>>

Re: INFO: task hung in fb_open

On Thu, Dec 5, 2019 at 3:05 PM Daniel Vetter wrote: > > On Thu, Dec 5, 2019 at 2:38 PM syzbot > wrote: > > > > syzbot has bisected this bug to: > > > > commit 979c11ef39cee79d6f556091a357890962be2580 > > Author: Ayan Kumar Halder > > Date: Tue Jul 17 17:13:46 2018 + > > > >

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

On Thu, Dec 5, 2019 at 11:41 AM Tetsuo Handa wrote: > > On 2019/12/05 19:22, Paolo Bonzini wrote: > > Ah, and because the machine is a KVM guest, kvm_wait appears in a lot of > > backtrace and I get to share syzkaller's joy every time. :) > > > > This bisect result is bogus, though Tetsuo found

cirrusfb: divide errors in cirrusfb_check_var/cirrusfb_check_pixclock/cirrusfb_set_par_foo

Hello, syzkaller has found 3 of divide errors in the cirrusfb driver. Kernel is on c5db92909bedd Add linux-next specific files for 20191202. divide error: [#1] PREEMPT SMP KASAN CPU: 0 PID: 8133 Comm: syz-executor.5 Not tainted 5.4.0-next-20191202+ #13 Hardware name: QEMU Standard PC (Q35 +

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

On Sat, Nov 30, 2019 at 8:59 AM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:419593da Add linux-next specific files for 20191129 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=12bfd882e0 > kernel config:

Re: WARNING in drm_mode_createblob_ioctl

On Mon, Oct 14, 2019 at 11:39 AM syzbot wrote: > > Op 14-10-2019 om 11:16 schreef Daniel Vetter: > > On Sun, Oct 13, 2019 at 11:09:09PM -0700, syzbot wrote: > >> Hello, > >> > >> syzbot found the following crash on: > >> > >> HEAD commit:8ada228a Add linux-next specific files for 20191011 >

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

On Tue, Mar 31, 2020 at 11:57 AM Peter Zijlstra wrote: > > On Mon, Mar 30, 2020 at 10:01:12PM -0700, syzbot wrote: > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit:9420e8ad Merge tag 'for-linus' of git://git.kernel.org/pub.. > > git tree: upstream > > console

[PATCH] drm/vkms: fix misuse of WARN_ON

vkms_vblank_simulate() uses WARN_ON for timing-dependent condition (timer overrun). This is a mis-use of WARN_ON, WARN_ON must be used to denote kernel bugs. Use pr_warn() instead. Signed-off-by: Dmitry Vyukov Reported-by: syzbot+4fc21a003c8332eb0...@syzkaller.appspotmail.com Cc: Rodrigo

Re: [syzbot] WARNING in __dma_map_sg_attrs

On Tue, 8 Feb 2022 at 13:26, Daniel Vetter wrote: > > On Sat, Feb 05, 2022 at 12:18:23PM -0800, syzbot wrote: > > syzbot has found a reproducer for the following issue on: > > > > HEAD commit:0457e5153e0e Merge tag 'for-linus' of git://git.kernel.org.. > > git tree: upstream > > console

Re: [PATCH v2 14/16] kasan: Remove ksize()-related tests

On Fri, 23 Sept 2022 at 22:28, Kees Cook wrote: > > In preparation for no longer unpoisoning in ksize(), remove the behavioral > self-tests for ksize(). > > Cc: Andrey Ryabinin > Cc: Alexander Potapenko > Cc: Andrey Konovalov > Cc: Dmitry Vyukov > Cc: Vincenzo Fr

dealock in drm_fb_helper_damage_work

Hi, I am getting the following deadlock on reservation_ww_class_mutex while trying to boot next-2022 kernel: WARNING: possible recursive locking detected 6.1.0-rc4-next-2022 #193 Not tainted

Re: dealock in drm_fb_helper_damage_work

On Sun, 13 Nov 2022 at 21:42, Dmitry Vyukov wrote: > > Hi, > > I am getting the following deadlock on reservation_ww_class_mutex > while trying to boot next-2022 kernel: The code is recently added by this commit: commit 79e2cf2e7a193473dfb0da3b9b869682b43dc60f Author: Dmitry

Re: [syzbot] [dri?] general protection fault in drm_crtc_next_vblank_start

On Mon, 3 Apr 2023 at 18:26, Rob Clark wrote: > > On Mon, Apr 3, 2023 at 12:57 AM syzbot > wrote: > > > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit:a6d9e3034536 Add linux-next specific files for 20230330 > > git tree: linux-next > > console+strace:

Re: [syzbot] kernel BUG in vmf_insert_pfn_prot

On Tue, 13 Jun 2023 at 21:23, syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit a5b44c4adb1699661d22e5152fb26885f30a2e4c > Author: Thomas Zimmermann > Date: Mon Mar 20 15:07:44 2023 + > > drm/fbdev-generic: Always use shadow buffering > > bisection log: