If the memory size that use kmalloc() to allocate exceed MAX_ORDER pages,
it will hit the WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN)), so add memory
allocation flag __GFP_NOWARN to silence a warning, othervise, it will
cause panic if panic_on_warn is enable.
The calltrace is:
WARNING: CPU: 1 PID: 6298 at mm/page_alloc.c:4713 __alloc_pages_nodemask+0x339/0x7d0 mm/page_alloc.c:4713
Call Trace:
__alloc_pages_nodemask+0x339/0x7d0 mm/page_alloc.c:4713
alloc_pages_current+0xac/0x1e0 mm/mempolicy.c:2211
alloc_pages include/linux/gfp.h:532 [inline]
kmalloc_order+0x21/0xf0 mm/slab_common.c:1324
kmalloc_order_trace+0x18/0x150 mm/slab_common.c:1340
kmalloc include/linux/slab.h:560 [inline]
vc_uniscr_alloc+0x2b/0xb0 drivers/tty/vt/vt.c:353
vc_do_resize+0x319/0x12b0 drivers/tty/vt/vt.c:1203
vt_ioctl+0xa5f/0x29a0 drivers/tty/vt/vt_ioctl.c:840
tty_ioctl+0x27d/0x1420 drivers/tty/tty_io.c:2660
vfs_ioctl fs/ioctl.c:47 [inline]
ksys_ioctl+0xee/0x120 fs/ioctl.c:763
__do_sys_ioctl fs/ioctl.c:772 [inline]
__se_sys_ioctl fs/ioctl.c:770 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:770
do_syscall_64+0xa1/0x540 arch/x86/entry/common.c:294
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Fixes: d8ae72427187 ("vt: preserve unicode values corresponding to screen characters")
Signed-off-by: Chen Wandun <[email protected]>
---
drivers/tty/vt/vt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index bbc26d73209a..2b000b31a351 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -350,7 +350,7 @@ static struct uni_screen *vc_uniscr_alloc(unsigned int cols, unsigned int rows)
/* allocate everything in one go */
memsize = cols * rows * sizeof(char32_t);
memsize += rows * sizeof(char32_t *);
- p = kmalloc(memsize, GFP_KERNEL);
+ p = kmalloc(memsize, GFP_KERNEL | __GFP_NOWARN);
if (!p)
return NULL;
--
2.17.1
On Sat, 28 Mar 2020, Chen Wandun wrote:
> If the memory size that use kmalloc() to allocate exceed MAX_ORDER pages,
> it will hit the WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN)), so add memory
> allocation flag __GFP_NOWARN to silence a warning, othervise, it will
> cause panic if panic_on_warn is enable.
Wow! How do you manage that? You need something like a 1024x1024 text
screen to get such a big memory allocation.
Still, GFP_NOWARN is not a proper fix. This kmalloc() should rather be
replaced by vmalloc(), and corresponding kfree() should then be vfree().
There is no need for this allocation to be physically contiguous.
Nicolas
On Fri, Mar 27, 2020 at 10:55:14PM -0400, Nicolas Pitre wrote:
> On Sat, 28 Mar 2020, Chen Wandun wrote:
>
> > If the memory size that use kmalloc() to allocate exceed MAX_ORDER pages,
> > it will hit the WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN)), so add memory
> > allocation flag __GFP_NOWARN to silence a warning, othervise, it will
> > cause panic if panic_on_warn is enable.
>
> Wow! How do you manage that? You need something like a 1024x1024 text
> screen to get such a big memory allocation.
ioctl(VT_RESIZE) allows up to 32767x32767, unprivileged for a local user.
That's 4GB per console.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀ -- <willmore> on #linux-sunxi
⠈⠳⣄⠀⠀⠀⠀
On Sat, 28 Mar 2020, Adam Borowski wrote:
> On Fri, Mar 27, 2020 at 10:55:14PM -0400, Nicolas Pitre wrote:
> > On Sat, 28 Mar 2020, Chen Wandun wrote:
> >
> > > If the memory size that use kmalloc() to allocate exceed MAX_ORDER pages,
> > > it will hit the WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN)), so add memory
> > > allocation flag __GFP_NOWARN to silence a warning, othervise, it will
> > > cause panic if panic_on_warn is enable.
> >
> > Wow! How do you manage that? You need something like a 1024x1024 text
> > screen to get such a big memory allocation.
>
> ioctl(VT_RESIZE) allows up to 32767x32767, unprivileged for a local user.
> That's 4GB per console.
Right. And that's ridiculous. This ought to be limited to something much
saner.
Nicolas
On Sat, 28 Mar 2020, Adam Borowski wrote:
> On Fri, Mar 27, 2020 at 10:55:14PM -0400, Nicolas Pitre wrote:
> > On Sat, 28 Mar 2020, Chen Wandun wrote:
> >
> > > If the memory size that use kmalloc() to allocate exceed MAX_ORDER pages,
> > > it will hit the WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN)), so add memory
> > > allocation flag __GFP_NOWARN to silence a warning, othervise, it will
> > > cause panic if panic_on_warn is enable.
> >
> > Wow! How do you manage that? You need something like a 1024x1024 text
> > screen to get such a big memory allocation.
>
> ioctl(VT_RESIZE) allows up to 32767x32767, unprivileged for a local user.
> That's 4GB per console.
In fact that's not exactly true. The code has this protection:
if (new_screen_size > (4 << 20))
return -EINVAL;
The problem is with the unicode screen content whose buffer is larger
than the legacy glyph buffer. Still, the above test is a bit iffy as it
depends on the default MAX_ORDER value which is configurable.
Nicolas