Thomas Hellstrom wrote:
> Most likely the spin_is_locked() function is not working on non - SMP
> systems (well how could it?). An oversight from my side.
You are right. I found a description in Documentation/scsi/ChangeLog.megaraid .
there are several checks present in the kernel
Tetsuo Handa wrote:
> From e314a1a1583e585d062dfc30c8aad8bf5380510b Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Mon, 19 May 2014 18:43:21 +0900
> Subject: [PATCH] gpu/drm/ttm: Use mutex_lock_killable() for shrinker
> functions.
>
> I can observe that RHEL7 enviro
[ 77.962348] [] shrink_slab+0x61/0xe0
[ 77.962348] [] kswapd+0x5f6/0x8e0
[ 77.962348] [] kthread+0xaf/0xd0
[ 77.962348] [] ? try_to_free_pages+0x540/0x540
[ 77.962348] [] ? trace_hardirqs_on+0xb/0x10
[ 77.962348] [] ret_from_kernel_thread+0x21/0x30
[ 77.9623
_lock(&_manager->lock))
>
> This is based on v3.15 with these patches.
Wow! I didn't know that my gcc does not emit warning on such a mistake.
Thank you for catching this.
--
>From 6e6774a87695408ef077cab576e76f7fa2cf4355 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-k
Konrad Rzeszutek Wilk wrote:
> On Sat, May 24, 2014 at 11:22:09PM +0900, Tetsuo Handa wrote:
> > Hello.
> >
> > I tried to test whether it is OK (from point of view of reentrant) to use
> > mutex_lock() or mutex_lock_killable() inside shrinker functions when
> >
Tetsuo Handa wrote:
> Konrad Rzeszutek Wilk wrote:
> > On Sat, May 24, 2014 at 11:22:09PM +0900, Tetsuo Handa wrote:
> > > Hello.
> > >
> > > I tried to test whether it is OK (from point of view of reentrant) to use
> > > mutex_lock() or mutex_l
>From 4e8d1a83629c5966bfd401c5f2187355624194f2 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp>
Date: Sat, 31 May 2014 09:59:44 +0900
Subject: [PATCH 3/5] gpu/drm/ttm: Use mutex_trylock() to avoid deadlock inside
shrinker functions.
I can observe t
>From c1af6a76f8566d049d3cf24635a43b4a83a6 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp>
Date: Sat, 31 May 2014 09:39:22 +0900
Subject: [PATCH 1/5] gpu/drm/ttm: Fix possible division by 0 in
ttm_dma_pool_shrink_scan().
list_empty(&_manager-
>From 19927a63c5d2dcda467373c31d810be42e40e190 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp>
Date: Sat, 31 May 2014 09:47:02 +0900
Subject: [PATCH 2/5] gpu/drm/ttm: Choose a pool to shrink correctly in
ttm_dma_pool_shrink_scan().
We can use &quo
>From d960cdf1e1c91172b86ab9517e576e5fb7e71785 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp>
Date: Sat, 31 May 2014 10:05:02 +0900
Subject: [PATCH 4/5] gpu/drm/ttm: Fix possible stack overflow by recursive
shrinker calls.
While ttm_dma_pool_shrink_sca
>From 357d4ba36284eee4c2a99085450a9039735767c6 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp>
Date: Sat, 31 May 2014 10:22:17 +0900
Subject: [PATCH 5/5] gpu/drm/ttm: Pass GFP flags in order to avoid deadlock.
Commit 7dc19d5a "drivers: convert sh
Andrew Morton wrote:
> Poor ttm guys - this is a bit of a trap we set for them.
Commit a91576d7916f6cce (\"drm/ttm: Pass GFP flags in order to avoid
deadlock.\")
changed to use sc->gfp_mask rather than GFP_KERNEL.
- pages_to_free = kmalloc(npages_to_free * sizeof(struct page *),
-
Andrew Morton wrote:
> On Wed, 12 Nov 2014 13:08:55 +0900 Tetsuo Handa i-love.sakura.ne.jp> wrote:
>
> > Andrew Morton wrote:
> > > Poor ttm guys - this is a bit of a trap we set for them.
> >
> > Commit a91576d7916f6cce ("drm/ttm: Pass GFP flags in or
>From d3cb5393c9c8099d6b37e769f78c31af1541fe8c Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp>
Date: Thu, 13 Nov 2014 22:21:54 +0900
Subject: [PATCH] drm/ttm: Avoid memory allocation from shrinker functions.
Commit a91576d7916f6cce ("drm/ttm:
>From 5c2f18ca300a1182e40f143b81e927426232b005 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp>
Date: Sun, 3 Aug 2014 19:59:35 +0900
Subject: [PATCH 1/5] gpu/drm/ttm: Fix possible division by 0 in
ttm_dma_pool_shrink_scan().
list_empty(&_manager-
>From ee941e18a3c05a7589b690669611c3f0895a2d5a Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp>
Date: Sun, 3 Aug 2014 20:00:40 +0900
Subject: [PATCH 2/5] gpu/drm/ttm: Choose a pool to shrink correctly in
ttm_dma_pool_shrink_scan().
We can use &quo
>From e945aa0d6518563835c3f279b9c7f9fc3f20b38b Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp>
Date: Sun, 3 Aug 2014 20:01:10 +0900
Subject: [PATCH 3/5] gpu/drm/ttm: Use mutex_trylock() to avoid deadlock inside
shrinker functions.
I can observe t
>From 16009d9def2c3087772e6c9dbec6c60950ae768b Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp>
Date: Sun, 3 Aug 2014 20:02:03 +0900
Subject: [PATCH 4/5] gpu/drm/ttm: Fix possible stack overflow by recursive
shrinker calls.
While ttm_dma_pool_shrink_sca
>From cf572226bd1f67305dc5477fccdc6daa30396994 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp>
Date: Sun, 3 Aug 2014 20:02:31 +0900
Subject: [PATCH 5/5] gpu/drm/ttm: Pass GFP flags in order to avoid deadlock.
Commit 7dc19d5a "drivers: convert sh
I booted a CONFIG_PREEMPT_NONE=y && CONFIG_SMP=n kernel (linux.git as of
9c982e86dbdb), and hit BUG_ON() at __vmw_cmdbuf_header_free().
--
static void __vmw_cmdbuf_header_free(struct vmw_cmdbuf_header *header)
{
struct vmw_cmdbuf_man *man = header->man;
check and reply if you found
problems.
Signed-off-by: Tetsuo Handa
Acked-by: Michal Hocko
Cc: Russell King # arm
Cc: # apei
Cc: # drbd
Cc: # mspec
Cc: # drm
Cc: Oleg Drokin # lustre
Cc: Andreas Dilger # lustre
Cc: # coda
Cc: # jffs2
Cc: Jan Kara # udf
Cc: # xattr
Cc: # ipc + mm
Cc
I'm doing memory allocation failure injection test using 3.19-rc5 and
it seems to me that there is a memory corruption bug in ttm or vmwgfx code.
-- Crash pattern 1 start --
[ 80.751971] [TTM] Failed allocating page table
[ 83.000393] BUG: unable to handle kernel NULL pointer
Andrey Ryabinin wrote:
> It's safe to call vfree() from rcu callback as in any other interrupt context.
> Commits you listed bellow didn't change anything in that respect.
> They made impossible to call vfree() under stuff like
> preempt_disable()/spin_lock()
I still cannot catch. According to
Thomas Hellstrom wrote:
> So to summarize. Yes, the drm callers can be fixed up, but IMO requiring
> vfree() to be non-atomic is IMO not a good idea if avoidable.
I agree.
I don't know about drm code. But I can find AppArmor code doing
kvfree() from dfa_free() from aa_dfa_free_kref() from
Hello.
I'm getting a boot failure (console stops) as of next-20170403~69.
next-20170403~70 and next-20170331 boot normally.
Would you check commit 8a2398eb335c11b1b33b860ff472c53c6b1bcc43("Merge
remote-tracking branch 'drm-misc/for-linux-next'") ?
--
%G[1.584230] ioc0: LSI53C1030
Sergey Senozhatsky wrote:
> On (07/06/17 19:28), Tetsuo Handa wrote:
> > Pressing SysRq-c caused all locks to be released (doesn't it ?), and console
>
> hm, I think what happened is a bit different thing. sysrq-c didn't
> unlock any of the locks. I suspect that ->bo
Hello.
I noticed that printing to consoles can stop forever because console drivers
can wait for memory allocation when memory allocation cannot make progress.
I was testing almost OOM situation and reproduced a situation where allocation
requests fall into infinite too_many_isolated() trap in
Code added by commit 060e2ad57041b42c ("drm/vmwgfx: Add and connect plane helper
functions") is hitting KASAN error shown below. I guess that either *vcs is
invalid or vcs->is_implicit is off-by-one.
--
[ 19.654429] Linux agpgart interface v0.103
[ 19.657444] agpgart-intel
On 2018/08/24 20:36, Michal Hocko wrote:
>> That is, this API seems to be currently used by only out-of-tree users. Since
>> we can't check that nobody has memory allocation dependency, I think that
>> hmm_invalidate_range_start() should return -EAGAIN if blockable == false for
>> now.
>
> The
On 2018/08/24 22:52, Michal Hocko wrote:
> @@ -180,11 +180,15 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn)
> */
> static int amdgpu_mn_read_lock(struct amdgpu_mn *amn, bool blockable)
> {
> - if (blockable)
> - mutex_lock(>read_lock);
> - else if
Two more worries for this patch.
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> @@ -178,12 +178,18 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn)
> *
> * @amn: our notifier
> */
> -static void amdgpu_mn_read_lock(struct amdgpu_mn *amn)
>
On 2018/08/24 22:32, Michal Hocko wrote:
> On Fri 24-08-18 22:02:23, Tetsuo Handa wrote:
>> I worry that (currently
>> out-of-tree) users of this API are involving work / recursion.
>
> I do not give a slightest about out-of-tree modules. They will have to
> accomodat
On 2018/08/27 16:41, Christian König wrote:
> Am 26.08.2018 um 10:40 schrieb Tetsuo Handa:
>> I'm not following. Why don't we need to do like below (given that
>> nobody except amdgpu_mn_read_lock() holds ->read_lock) because e.g.
>> drm_sched_fence_create() from d
lifecycle of crc_work is appropriately managed, fix this problem
by adding INIT_WORK() to vkms_atomic_crtc_reset() side.
[1]
https://syzkaller.appspot.com/bug?id=a5954455fcfa51c29ca2ab55b203076337e1c770
Reported-and-tested-by: syzbot
Signed-off-by: Tetsuo Handa
---
drivers/gpu/drm/vkms/vkms_crtc.
We need to call drm_modeset_acquire_fini() when drm_atomic_state_alloc()
failed or call drm_modeset_acquire_init() after drm_atomic_state_alloc()
succeeded.
Signed-off-by: Tetsuo Handa
Reported-by: syzbot
---
drivers/gpu/drm/drm_atomic_uapi.c | 3 +--
drivers/gpu/drm/drm_mode_object.c | 4
On 2019/01/03 18:04, Dmitry Vyukov wrote:
> On Thu, Jan 3, 2019 at 9:55 AM Maarten Lankhorst
> wrote:
>> Just guessing..
>>
>> Does this help?
Yes it will. And while at it, let's fix another one together.
From 291e42211e3cc6d85c915772717dd08d40fb5fed Mon Sep 17 00:00:00
(Moving most recipients to bcc: in order to avoid flooding.)
On 2019/03/12 13:08, Al Viro wrote:
> Umm... Might be a good idea to add some plausibility filters - it is,
> in theory, possible that adding a line in a comment changes behaviour
> (without compiler bugs, even - playing with __LINE__
Commit b30b61ff6b1dc37f in linux-next.git did not get in time for closing
previous report. I assume that a pull request will be sent shortly from
Daniel Vetter.
#syz fix: drm/vkms: Fix flush_work() without INIT_WORK().
___
dri-devel mailing list
This seems to be triggered by "pkg/report: skip printk and other printing
functions " on syzbot side.
The fix should be "kobject: Don't trigger kobject_uevent(KOBJ_REMOVE) twice."
in linux-next.git.
#syz dup: KASAN: use-after-free Read in string
___
syzbot found that a thread can stall for minutes inside
ion_system_heap_allocate() after that thread was killed by SIGKILL [1].
Let's check for SIGKILL before doing memory allocation.
[1]
https://syzkaller.appspot.com/bug?id=a0e3436829698d5824231251fad9d8e998f94f5e
Signed-off-by: Tetsuo Handa
On 2019/12/05 19: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:
>>>
>>> commit 2de50e9674fc4ca3c6174b04477f69eb26b4ee31
>>> Author: Russell Currey
>>> Date: Mon Feb 8 04:08:20 2016
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 the bug anyway.
> Perhaps you can exclude commits that only touch
Hello.
syzbot is reporting that memory allocation size at fbcon_set_font() is too small
because font's height is rounded up from 10 to 16 after memory allocation.
--
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index c9235a2f42f8..68fe66e435d3 100644
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
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
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
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
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
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
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
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
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
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
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
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
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.
>>
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
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 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
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/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
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
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
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/
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().
>
>
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
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.
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
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
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
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
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
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 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/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
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/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 --
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 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 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 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
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/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
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/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/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
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/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
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 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
1 - 100 of 143 matches
Mail list logo
