save/irqrestore from known
context")
Signed-off-by: Tetsuo Handa
---
drivers/dma-buf/sync_debug.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
index 101394f16930..237bce21d1e7 100644
--- a/drivers/dma-bu
#syz set subsystems: serial
include/linux/tty_ldisc.h says "struct tty_ldisc_ops"->write is allowed to
sleep.
include/linux/tty_driver.h says "struct tty_operations"->write is not allowed
to sleep.
drivers/tty/vt/vt.c implements do_con_write() from con_write() sleeping,
violating what
On 2023/09/14 6:08, Thomas Gleixner wrote:
> Maybe the VKMS people need to understand locking in the first place. The
> first thing I saw in this code is:
>
> static enum hrtimer_restart vkms_vblank_simulate(struct hrtimer *timer)
> {
>...
>mutex_unlock(>enabled_lock);
>
> What?
>
>
Hello. A deadlock was reported in drivers/gpu/drm/vkms/ .
It looks like this locking pattern remains as of 6.6-rc1. Please fix.
void drm_crtc_vblank_off(struct drm_crtc *crtc) {
spin_lock_irq(>event_lock);
drm_vblank_disable_and_save(dev, pipe) {
__disable_vblank(dev, pipe) {
On 2023/07/25 2:03, Geert Uytterhoeven wrote:
> The syzbot report turned out to be a false possitive, caused by a KMSAN
> problem. Indeed, after allocating the buffer, it is fully initialized
> using scr_memsetw(). Hence there is no point in allocating zeroed
> memory, while this does incur some
ork()
need to wait.
Therefore, for now let's start with blind/mechanical conversion within
the whole drivers/gpu/drm/i915/ directory, based on an assumption that
i915 does not need to wait for work items outside of this directory.
Link: https://lkml.kernel.org/r/87sfeita1p@intel.com
Signed-off-
ork()
need to wait.
Therefore, for now let's start with blind/mechanical conversion within
the whole drivers/gpu/drm/i915/ directory, based on an assumption that
i915 does not need to wait for work items outside of this directory.
Link: https://lkml.kernel.org/r/87sfeita1p@intel.com
Signed-off-
ork()
need to wait.
Therefore, for now let's start with blind/mechanical conversion within
the whole drivers/gpu/drm/i915/ directory, based on an assumption that
i915 does not need to wait for work items outside of this directory.
Link: https://lkml.kernel.org/r/87sfeita1p@intel.com
Signed-off-
On 2023/04/14 19:13, Jani Nikula wrote:
> On Fri, 14 Apr 2023, Tetsuo Handa wrote:
>> On 2023/03/15 19:47, Luca Coelho wrote:
>>> On Tue, 2023-03-14 at 20:21 +0900, Tetsuo Handa wrote:
>>>> Like commit c4f135d643823a86 ("workqueue: Wrap flush_wo
On 2023/03/15 19:47, Luca Coelho wrote:
> On Tue, 2023-03-14 at 20:21 +0900, Tetsuo Handa wrote:
>> Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a
>> macro") says, flush_scheduled_work() is dangerous and will be forbidden.
>&g
Commit c53e98934f93 ("mm: vmalloc: use rwsem, mutex for vmap_area_lock and
vmap_block->lock")
is broken. We can't take mutex (a sleeping lock) inside RCU read section (an
atomic context).
@@ -2183,7 +2184,7 @@ static void _vm_unmap_aliases(unsigned long start,
unsigned long end, int flush)
tory. Jani Nikula wants to use two workqueues in order to avoid
adding new module globals, but I'm not familiar enough to audit and
split into two workqueues.
Link: https://lkml.kernel.org/r/87sfeita1p@intel.com
Signed-off-by: Tetsuo Handa
Cc: Tvrtko Ursulin
Cc: Jani Nikula
Cc: Vil
On 2023/03/06 20:05, Jani Nikula wrote:
> On Fri, 03 Mar 2023, Tetsuo Handa wrote:
>> On 2023/03/03 19:11, Tetsuo Handa wrote:
>>> @@ -79,6 +81,7 @@ static int __init i915_init(void)
>>> {
>>> int err, i;
>>>
>>> + i915_wq = allo
On 2023/03/03 19:11, Tetsuo Handa wrote:
> @@ -79,6 +81,7 @@ static int __init i915_init(void)
> {
> int err, i;
>
> + i915_wq = alloc_workqueue("i915", 0, 0);
Oops. I forgot to add
if (!i915_wq)
return -ENOMEM;
here. But I'd like
.intel.com
[1]
Signed-off-by: Tetsuo Handa
Cc: Tvrtko Ursulin
Cc: Jani Nikula
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
drivers/gpu/drm/i915/display/intel_dmc.c | 2 +-
drivers/gpu/drm/i915/display/intel_dp.c| 2 +-
.../gp
On 2022/11/16 22:06, Ville Syrjälä wrote:
> On Wed, Nov 16, 2022 at 12:08:27PM +0200, Jani Nikula wrote:
>> On Sun, 06 Nov 2022, Tetsuo Handa wrote:
>>> Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a
>>> macro") says
On 2023/01/29 15:00, Zack Rusin wrote:
> On Sat, 2023-01-28 at 20:44 +0900, Tetsuo Handa wrote:
>> Hello.
>>
>> I noticed that a kernel built with vmwgfx driver fails to boot a Linux guest
>> on Oracle VM VirtualBox 7.0.4 on Windows 11 on DELL Inspiron 14 5420.
>>
Hello.
I noticed that a kernel built with vmwgfx driver fails to boot a Linux guest
on Oracle VM VirtualBox 7.0.4 on Windows 11 on DELL Inspiron 14 5420.
I didn't notice this problem when I booted an older kernel on an older version
of Oracle VM VirtualBox on Windows 8.1 on an older PC.
The
On 2023/01/05 22:22, Daniel Vetter wrote:
> Oh I was more asking about the fbdev patch. This here sounds a lot more
> something that needs to be discussed with kmsan people, that's definitely
> not my area.
> -Daniel
Commit a6a00d7e8ffd ("fbcon: Use kzalloc() in fbcon_prepare_logo()") was
On 2023/01/05 20:54, Daniel Vetter wrote:
>>> . Plain memset() in arch/x86/include/asm/string_64.h is redirected to
>>> __msan_memset()
>>> but memsetXX() are not redirected to __msan_memsetXX(). That is, memory
>>> initialization
>>> via memsetXX() results in KMSAN's shadow memory being not
On 2023/01/04 1:20, Felix Kuehling wrote:
>
> Am 2023-01-03 um 11:05 schrieb Waiman Long:
>> On 1/3/23 10:39, Felix Kuehling wrote:
>>> The regression point doesn't make sense. The kernel config doesn't enable
>>> CONFIG_DRM_AMDGPU, so there is no way that a change in AMDGPU could have
>>>
On 2022/12/15 18:36, Geert Uytterhoeven wrote:
> The next line is:
>
> scr_memsetw(save, erase, array3_size(logo_lines, new_cols, 2));
>
> So how can this turn out to be uninitialized later below?
>
> scr_memcpyw(q, save, array3_size(logo_lines, new_cols, 2));
>
> What am I
9abd498 [1]
Reported-by: syzbot
Signed-off-by: Tetsuo Handa
Tested-by: syzbot
Fixes: a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize()
failed")
---
drivers/video/fbdev/core/fbcon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/co
plug+0xbea/0xda0
drm_fbdev_generic_setup+0x65e/0x9d0
vkms_init+0x9f3/0xc76
(...snipped...)
CPU: 2 PID: 1 Comm: swapper/0 Not tainted 6.1.0-rc4-00356-g8f2975c2bb4c #924
Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
--
Signed-off-by: Te
Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a
macro") says, flush_scheduled_work() is dangerous and will be forbidden.
We are on the way for removing all flush_scheduled_work() callers from
the kernel, and there are only 4 callers remaining as of linux-20221104.
No response since 2022-06-10. Can somebody take this patch?
On 2022/07/28 10:40, Tetsuo Handa wrote:
> Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a
> macro") says, flush_scheduled_work() is dangerous and will be forbidden.
> We are on the w
hose "do nothing" for mhdp->hdcp.check_work and
mhdp->hdcp.prop_work. That is, I assume that flush_scheduled_work() in
cdns_mhdp_remove() needs to wait for only mhdp->hpd_work work.
Link:
https://lkml.kernel.org/r/943273cb-c2ec-24e3-5edb-64eacc6e2...@i-love.sakura.ne.jp
[1]
Si
On 2022/06/30 19:17, Tvrtko Ursulin wrote:
> Could you give more context on reasoning here please? What is the difference
> between using the system_wq and flushing it from a random context? Or concern
> is about flushing from specific contexts?
Excuse me, but I couldn't catch what you want.
On 2022/06/30 16:46, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 10/06/2022 15:57, Tetsuo Handa wrote:
>> Hello.
>>
>> Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using
>> a macro") explains, we are removing flush_scheduled_work(
Ping?
On 2022/06/13 22:57, Tetsuo Handa wrote:
> Thus, how do we want to handle this race window?
>
> flush_delayed_work(>hdcp.check_work) followed by
> flush_work(>hdcp.prop_work) (i.e. flush as much as possible) ?
>
> cancel_delayed_work_sync(&g
Ping?
On 2022/06/10 23:57, Tetsuo Handa wrote:
> Then, does this flush_scheduled_work() mean to wait all
> schedule_work()/schedule_delayed_work()
> calls inside drivers/gpu/drm/i915/ directory?
On 2022/06/10 23:35, Tetsuo Handa wrote:
> Use local wq in order to avoid flush_scheduled_work() usage.
>
> Signed-off-by: Tetsuo Handa
> ---
> Changes in v2:
> Replace flush_scheduled_work() with flush_workqueue().
>
> Please see commit c4f135d643823a86 ("wo
Hello.
Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using
a macro") explains, we are removing flush_scheduled_work() calls. And now
drivers/gpu/drm/i915/display/intel_display.c
drivers/gpu/drm/i915/gt/selftest_execlists.c
are the last flush_scheduled_work() callers which
Use local wq in order to avoid flush_scheduled_work() usage.
Signed-off-by: Tetsuo Handa
---
Changes in v2:
Replace flush_scheduled_work() with flush_workqueue().
Please see commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue()
using a macro") for background.
This is a blind
Use local wq in order to avoid flush_scheduled_work() usage.
Signed-off-by: Tetsuo Handa
---
Please see commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue()
using a macro") for background.
This is a blind conversion, and is only compile tested.
.../drm/bridge/cadence/cdn
On 2022/06/02 16:38, Arnd Bergmann wrote:
>> But let's cc the tomoyo and chelsio people.
>
> I think both of them work because the structures are always
> embedded inside of larger structures that have at least word
> alignment. This is the thing I was looking for, and the
> __packed attribute
Hello.
The Linux kernel provides kernel-global WQs (namely, system_wq,
system_highpri_wq,
system_long_wq, system_unbound_wq, system_freezable_wq,
system_power_efficient_wq
and system_freezable_power_efficient_wq). But since attempt to flush
kernel-global
WQs has possibility of deadlock, Tejun
On 2022/02/24 6:35, Tejun Heo wrote:
> Tetsuo, can you please revert the patch? The patch is incorrect in that it's
> triggering also on work item flushes, not just workqueue flushes.
OK. I removed these patches from my tree.
On 2022/02/09 6:08, Daniel Vetter wrote:
> @@ -714,6 +700,8 @@ static int con2fb_acquire_newinfo(struct vc_data *vc,
> struct fb_info *info,
> ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> if (!ops)
> err = -ENOMEM;
> +
> +
where multiplication
overflow happens, let's reject in the common path.
Link: https://syzkaller.appspot.com/bug?extid=04168c8063cfdde1db5e [1]
Reported-by: syzbot
Debugged-by: Randy Dunlap
Signed-off-by: Tetsuo Handa
Reviewed-by: Geert Uytterhoeven
---
Changes in v2:
Use check_mul_overflow(), sug
where multiplication
overflow happens, let's reject in the common path.
Link: https://syzkaller.appspot.com/bug?extid=04168c8063cfdde1db5e [1]
Reported-by: syzbot
Debugged-by: Randy Dunlap
Signed-off-by: Tetsuo Handa
---
Changes in v2:
Use check_mul_overflow(), suggested by Geert Uytter
On 2021/08/31 15:48, Geert Uytterhoeven wrote:
> Furthermore, this restricts the virtual frame buffer size on 64-bit,
> too, while graphics cards can have much more than 4 GiB of RAM.
Excuse me, but do you mean that some hardware allows allocating more than
UINT_MAX bytes of memory for kernel
needed.
Link: https://syzkaller.appspot.com/bug?extid=04168c8063cfdde1db5e [1]
Reported-by: syzbot
Debugged-by: Randy Dunlap
Signed-off-by: Tetsuo Handa
Tested-by: syzbot
---
drivers/video/fbdev/core/fbmem.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/video/fbdev/core/fbm
On 2021/08/30 23:30, Geert Uytterhoeven wrote:
> The highest possible value of maxmem inside vga16fb_check_var()
> is 65536.
Yes.
>
> So I believe
>
> if (array_size(vxres, vyres) > maxmem)
>
> should work fine.
My intent is to check at common path than individual module so that we don't
On 2021/08/30 22:47, Dan Carpenter wrote:
> On Mon, Aug 30, 2021 at 10:37:31PM +0900, Tetsuo Handa wrote:
>> On 2021/08/30 22:00, Dan Carpenter wrote:
>>>>> diff --git a/drivers/video/fbdev/vga16fb.c b/drivers/video/fbdev/vga16fb.c
>>>>> index e2757ff1c23d..
On 2021/08/30 22:00, Dan Carpenter wrote:
>>> diff --git a/drivers/video/fbdev/vga16fb.c b/drivers/video/fbdev/vga16fb.c
>>> index e2757ff1c23d..e483a3f5fd47 100644
>>> --- a/drivers/video/fbdev/vga16fb.c
>>> +++ b/drivers/video/fbdev/vga16fb.c
>>> @@ -403,7 +403,7 @@ static int
this value be passed to real_y
>> function, the ypos will be out of screen range.This is an out-of-bounds
>> write bug.
>> some driver will check xres and yres in fb_check_var callback,but some not
>> so we add a common check after that callback.
>>
>> Signed-off-by:
On 2021/08/30 9:24, Randy Dunlap wrote:
> Note that yres_virtual is set to 0x1000. Is there no practical limit
> (hence limit check) that can be used here?
>
> Also, in vga16fb_check_var(), beginning at line 404:
>
> 404 if (yres > vyres)
> 405 vyres = yres;
> 406
On 2021/05/15 1:19, Tetsuo Handa wrote:
> Even if it turns out to be safe to always call this
> callback, we will need to involve another callback via "struct fb_ops" for
> checking the upper limits from fbcon_resize(). As a result, we will need
> to modify
>
> dr
On 2021/05/15 5:25, Maciej W. Rozycki wrote:
> NB for fbcon the usual ioctl to resize the console is FBIOPUT_VSCREENINFO
> rather than VT_RESIZEX; fbset(8) uses it, and I actually experimented with
> it and a TGA-like (SFB+) framebuffer when at my lab last time, as Linux is
> kind enough to
B_PHYS_LEN) range.
[1] https://syzkaller.appspot.com/bug?extid=1f29e126cf461c4de3b3
Reported-by: syzbot
Signed-off-by: Tetsuo Handa
Tested-by: syzbot
---
drivers/video/fbdev/vga16fb.c | 54 +++
1 file changed, 36 insertions(+), 18 deletions(-)
diff --git a/dr
On 2021/05/03 22:41, Tetsuo Handa wrote:
> Therefore, I guess that the problem is that fbcon_putcs() from
> do_update_region() from
> redraw_screen() from vt_kdsetmode(KD_TEXT) from ioctl(fd, KDSETMODE, KD_TEXT)
> tries to
> redraw 2 x 16640 despite memory amount allocated fo
On 2021/05/02 10:53, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit 988d0763361bb65690d60e2bc53a6b72777040c3
> Author: Tetsuo Handa
> Date: Sun Sep 27 11:46:30 2020 +
>
> vt_ioctl: make VT_RESIZEX behave like VT_RESIZE
>
That com
ockdep annotation.
turning off the locking correctness validator.
Signed-off-by: Tetsuo Handa
Fixes: 8772c0bb58bbf98a ("drm/vmwgfx: Cleanup pci resource allocation")
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driver
On 2021/01/08 0:48, xuhuijie wrote:
> This commit 50145474f6ef(fbcon: remove soft scrollback code) remove soft
> scrollback in
> fbcon. So the shift+PageDown and shift+PageUp is missing. But PageUp is a
> vary important
> feature when system panic or reset. I can get log by PageUp before, but
On Wed, Dec 16, 2020 at 5:16 PM Paul E. McKenney wrote:
> In my experience, lockdep will indeed complain if an interrupt handler
> returns while in an RCU read-side critical section.
Can't we add lock status checks into the beginning and the end of interrupt
handler functions
(e.g. whether
On 2020/11/29 19:03, Thomas Zimmermann wrote:
> Am 28.11.20 um 23:40 schrieb Sam Ravnborg:
>> Replacing DPRINTK() statements with pr_debug fixes set but not used
>> warnings. And moves to a more standard logging setup at the same time.
>
> I guess this was added for quick debugging during
On 2020/09/29 2:59, Martin Hostettler wrote:
> On Sun, Sep 27, 2020 at 08:46:30PM +0900, Tetsuo Handa wrote:
>> VT_RESIZEX was introduced in Linux 1.3.3, but it is unclear that what
>> comes to the "+ more" part, and I couldn't find a user of VT_RESIZEX.
>>
A simplified reproducer and debug printk() patch shown below reported that
vc_font.height is increased to 9 via ioctl(VT_RESIZEX) after it was once
decreased from 16 to 2 via ioctl(PIO_FONT).
Since vc_resize() with v.v_rows == 0 preserves current vc->vc_rows value,
this reproducer is bypassing
ppspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3
Reported-by: syzbot
Reported-by: syzbot
Signed-off-by: Tetsuo Handa
---
drivers/tty/vt/vt_ioctl.c | 57 +++
1 file changed, 10 insertions(+), 47 deletions(-)
diff --git a/drivers/tty/vt/vt_ioctl.c b/d
Well, vt_io_ioctl(PIO_FONT) initializes "struct console_font_op op;" with
op.width = 8;
op.height = 0;
op.charcount = 256;
and calls con_font_set() from con_font_op(). But the "/* Need to guess font
height [compat] */"
chunk in con_font_set() guesses font's height due to being initialized
On 2020/09/27 4:39, Peilin Ye wrote:
> On Sun, Sep 27, 2020 at 01:25:17AM +0900, Tetsuo Handa wrote:
>> Since I don't know the meaning of "struct vt_consize"->v_clin (which is
>> commented
>> with "/* number of pixel rows per character */" but does it m
On 2020/09/16 17:26, Greg KH wrote:
> On Wed, Sep 16, 2020 at 09:01:06AM +0900, Tetsuo Handa wrote:
>> Greg, will you pick up this patch?
>>
>> It seems that finding the real cause of [3] and actually fixing [3] will be
>> difficult.
>> Since I can't reproduc
Greg, will you pick up this patch?
It seems that finding the real cause of [3] and actually fixing [3] will be
difficult.
Since I can't reproduce [3] locally, I will have to try flood of "#syz test"
requests
for debug printk() patches.
On 2020/09/11 7:57, Tetsuo Handa wrote
fbcon_scrolldelta() was removed by commit 50145474f6ef4a9c ("fbcon: remove soft
scrollback code").
#syz fix: fbcon: remove soft scrollback code
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
e633b1cc4e080c9
Reported-by: syzbot
Signed-off-by: Tetsuo Handa
Fixes: 39b3cffb8cf31117 ("fbcon: prevent user font height or width change from
causing potential out-of-bounds access")
Cc: George Kennedy
---
drivers/video/fbdev/core/fbcon.c | 2 +-
1 file changed, 1 insertion(+), 1 dele
Hello, Greg.
Since nobody is interested in this bug, can you directly pick up
this obvious patch without waiting for maintainer's response?
On 2020/08/31 19:37, Tetsuo Handa wrote:
> syzbot is reporting OOB read at vga_8planes_imageblit() [1], for
> "cdat[y] >> 4" can becom
syzbot is reporting OOB read at vga_8planes_imageblit() [1], for
"cdat[y] >> 4" can become a negative value due to "const char *cdat".
[1]
https://syzkaller.appspot.com/bug?id=0d7a0da1557dcd1989e00cb3692b26d4173b4132
Reported-by: syzbot
Signed-off-by: Tetsuo Handa
syzbot is reporting OOB read at vga_8planes_imageblit() [1], for
"cdat[y] >> 4" can become a negative value due to "const char *cdat".
[1]
https://syzkaller.appspot.com/bug?id=0d7a0da1557dcd1989e00cb3692b26d4173b4132
Reported-by: syzbot
Signed-off-by: Tetsuo Handa
Since transl_l[16] is accessed via cdat[y] >> 4, cdat[y] needs to be
evaluated as an "unsigned char" value in order to fit 0...15 range.
Signed-off-by: Tetsuo Handa
---
drivers/video/fbdev/vga16fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dri
On 2020/08/04 21:58, Greg Kroah-Hartman wrote:
> On Tue, Aug 04, 2020 at 08:15:43PM +0900, Tetsuo Handa wrote:
>> Do you think this approach is acceptable? Or, do we need to modify
>> set_origin() ?
>>
> I think what you have here is fine, as cleaning up set_orgin
Hello.
Commit 2ddef17678bc2ea1 ("drm/ttm: make TT creation purely optional v3") broke
vmwgfx .
At first I suspected it is "drm/atomic-helper: reset vblank on crtc reset" or
around that,
but bisection said it is not. I have no idea what is going on. Please have a
look.
--- Crash pattern 1 ---
On 2020/08/07 0:39, Daniel Vetter wrote:
> On Thu, Aug 6, 2020 at 5:28 PM Christian König
> wrote:
>>
>> My best guess is that you are facing two separate bugs here.
>>
>> Crash #1 is somehow related to CRTCs and might even be cause by the
>> atomic-helper change you noted below.
>
> Yeah, and
As of commit 47ec5303d73ea344 ("Merge
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next") on linux.git ,
my VMware environment cannot boot. Do I need to bisect?
[9.314496][T1] vga16fb: mapped to 0x71050562
[9.467770][T1] Console: switching to colour frame
Do you think this approach is acceptable? Or, do we need to modify set_origin()
?
On 2020/07/29 23:57, Tetsuo Handa wrote:
> syzbot is reporting UAF bug in set_origin() from vc_do_resize() [1], for
> vc_do_resize() calls kfree(vc->vc_screenbuf) before calling set_origin().
>
>
On 2020/07/30 20:16, Daniel Vetter wrote:
> Patch looks good, except ... does this compile? fbcon_update_vcs is
> defined in fbcon.h, and that doesn't seem to be included here ...
> Maybe what we want is an fb_set_var_ioctl in fbmem.c so that the fbcon
> interaction is a bit better hidden (but
bot
Suggested-by: Daniel Vetter
Signed-off-by: Tetsuo Handa
Reported-by: kernel test robot for missing #include
---
drivers/video/fbdev/core/fbmem.c | 8 ++--
drivers/video/fbdev/core/fbsysfs.c | 4 ++--
drivers/video/fbdev/ps3fb.c| 5 +++--
include/linux/fb.h | 2 --
igin() from
accessing outdated vc members.
[1]
https://syzkaller.appspot.com/bug?id=6649da2081e2ebdc65c0642c214b27fe91099db3
Reported-by: syzbot
Signed-off-by: Tetsuo Handa
---
drivers/tty/vt/vt.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/
bot
Suggested-by: Daniel Vetter
Signed-off-by: Tetsuo Handa
---
drivers/video/fbdev/core/fbmem.c | 8 ++--
drivers/video/fbdev/core/fbsysfs.c | 4 ++--
drivers/video/fbdev/ps3fb.c| 4 ++--
include/linux/fb.h | 2 --
4 files changed, 6 insertions(+), 12 deletions(-)
d
after returning from resize_screen(), and I assume
that not calling clear_selection() when resize_screen() will return error
is harmless, let's redo the check by moving resize_screen() earlier.
[1]
https://syzkaller.appspot.com/bug?id=c70c88cfd16dcf6e1d3c7f0ab8648b3144b5b25e
Reported-by: syzbot
S
On 2020/07/16 19:00, Daniel Vetter wrote:
> On Thu, Jul 16, 2020 at 12:29:00AM +0900, Tetsuo Handa wrote:
>> On 2020/07/16 0:12, Dan Carpenter wrote:
>>> I've complained about integer overflows in fbdev for a long time...
>>>
>>> What I'd like to see is somethin
On 2020/07/16 0:12, Dan Carpenter wrote:
> I've complained about integer overflows in fbdev for a long time...
>
> What I'd like to see is something like the following maybe. I don't
> know how to get the vc_data in fbmem.c so it doesn't include your checks
> for negative.
Yes. Like I said
On 2020/07/15 18:48, Dan Carpenter wrote:
>> @@ -216,7 +216,7 @@ static void bit_clear_margins(struct vc_data *vc, struct
>> fb_info *info,
>> region.color = color;
>> region.rop = ROP_COPY;
>>
>> -if (rw && !bottom_only) {
>> +if ((int) rw > 0 && !bottom_only) {
>>
On 2020/07/15 20:17, Tetsuo Handa wrote:
> On 2020/07/15 18:48, Dan Carpenter wrote:
>>> @@ -216,7 +216,7 @@ static void bit_clear_margins(struct vc_data *vc,
>>> struct fb_info *info,
>>> region.color = color;
>>> region.rop = ROP_COP
On 2020/07/14 18:13, Gu Jinxiang wrote:
> I've encountered [BUG: unable to handle kernel NULL pointer dereference at]
> which has call stack like your pattern2.
> And before this happended, I got a lot of memory allocation failure warnings.
> And my kernel is 3.10.0-327.62.1.el7.x86_64.
>
>
On 2020/07/15 2:15, George Kennedy wrote:
> Can you try the a.out built from the original Syzkaller modified repro C
> program? It walks 0-7 through xres and yres of the fb_var_screeninfo struct.
I'm not familiar with exploit code. What do you want to explain via this
program?
> struct
vc_rows * vc->vc_font.heigh do not
cause integer overflow.
[1]
https://syzkaller.appspot.com/bug?id=a565882df74fa76f10d3a6fec4be31098dbb37c6
Reported-and-tested-by: syzbot
Signed-off-by: Tetsuo Handa
---
drivers/video/fbdev/core/bitblit.c | 4 ++--
drivers/video/fbdev/core/fbcon_ccw.c | 4 ++--
drivers/
On 2020/07/14 16:22, Bartlomiej Zolnierkiewicz wrote:
> How does this patch relate to:
>
> https://marc.info/?l=linux-fbdev=159415024816722=2
>
> ?
>
> It seems to address the same issue, I've added George and Dan to Cc:.
George Kennedy's patch does not help for my case.
You can try
On 2020/07/14 19:27, Tetsuo Handa wrote:
> On 2020/07/14 16:22, Bartlomiej Zolnierkiewicz wrote:
>> How does this patch relate to:
>>
>> https://marc.info/?l=linux-fbdev=159415024816722=2
>>
>> ?
>>
>> It seems to address the same issue, I've added
ENINFO, );
and somehow hit unexpectedly long bit_clear_margins() loops. I don't know
why syzbot does not hit general protection fault, but it would depend on
environment because in my VMware environment ioctl(FBIOPUT_VSCREENINFO)
returns -EINVAL if var.xres == var.yres == 0.
[1]
https://syzkaller.a
On 2020/07/10 19:56, Greg Kroah-Hartman wrote:
> Where is the over/underflow happening here when we set a size to be so
> small? We should bound the size somewhere, and as you show, that's not
> really working properly, right?
It is bit_clear_margins() where integer underflow is happening
On 2020/07/11 15:16, Tetsuo Handa wrote:
> On 2020/07/10 19:56, Greg Kroah-Hartman wrote:
>> Where is the over/underflow happening here when we set a size to be so
>> small? We should bound the size somewhere, and as you show, that's not
>> really wo
g -ENOMEM.
[1] https://syzkaller.appspot.com/bug?extid=017265e8553724e514e8
Reported-and-tested-by: syzbot
Signed-off-by: Tetsuo Handa
---
drivers/tty/vt/vt.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt
Hello.
While trying to debug
https://syzkaller.appspot.com/bug?extid=017265e8553724e514e8 ,
I noticed that a crash can happen without opening /dev/ttyXX .
For example, while a driver which syzbot is reporting accepts screen with
var.xres = var.yres = 0 (and a crash is not visible until trying
hing that worth crashing the
system. Let's remove the ret_overrun variable and WARN_ON() test.
Link:
https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
Signed-off-by: Tetsuo Handa
Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
Fixes: 09ef09b4ab95dc4
On 2020/05/26 2:00, Daniel Vetter wrote:
> Forgot to add: I did run this quickly with vkms as secondary output.
> Good fireworks show, but there's an entire army of additional splats
> after the first one. The WARN_ON you're removing is only the
> messenger, the real bug is probably one of the
On 2020/05/26 13:18, Tetsuo Handa wrote:
> due to mode->crtc_clock <= 0. Thus, somehow initializing mode->crtc_clock > 0
> might be able
> to solve this problem.
Well, I came to think that vkms_enable_vblank() should return an error to the
caller
when drm_calc_timestampi
On 2020/05/26 0:21, Daniel Vetter wrote:
> On Mon, May 25, 2020 at 11:38:49PM +0900, Tetsuo Handa wrote:
>> Commit 3a0709928b172a41 ("drm/vkms: Add vblank events simulated by
>> hrtimers") introduced ret_overrun variable. And that variable was an
>> unuse
An unkillable task report
INFO: task syz-executor.2:10292 can't die for more than 143 seconds.
syz-executor.2 R running task26216 10292 7415 0x4006
Call Trace:
preempt_schedule_irq+0xb0/0x150 kernel/sched/core.c:4346
retint_kernel+0x1b/0x2b
RIP: 0010:bitfill_aligned+0x12/0x200
A fbcon bug found that allocation size was wrong.
https://groups.google.com/d/msg/syzkaller-bugs/TVGAFDeUKJo/uchTlvbFAQAJ
You can try adding printk() for examining values because you have reproducers.
___
dri-devel mailing list
1 - 100 of 143 matches
Mail list logo
