Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

frame-larger-than in arch/powerpc/xmon/xmon.c #252

Open
shenki opened this issue Oct 30, 2018 · 2 comments
Open

frame-larger-than in arch/powerpc/xmon/xmon.c #252

shenki opened this issue Oct 30, 2018 · 2 comments

Comments

@shenki
Copy link
Member

@shenki shenki commented Oct 30, 2018

clang-7 and clang-8 (8.0.0-svn345470-1~exp1+0~20181028082208.133~1.gbpf10f36) result in this build error when building the ppc64 kernel:

arch/powerpc/xmon/xmon.c:452:12: warning: stack frame size of 2576 bytes in function 'xmon_core'
      [-Wframe-larger-than=]
static int xmon_core(struct pt_regs *regs, int fromipi)

Note that this is an error, as arch/powerpc builds with -Werror turned on.

@shenki

This comment has been minimized.

Copy link
Member Author

@shenki shenki commented Oct 30, 2018

@rnav did some digging and found out why xmon_core ends up so large:

Looks like it's to do with xmon_printf()
clang seems to be saving addresses to those in .rodata.str1.1 section on the stack

            798: R_PPC64_TOC16_HA    .rodata.str1.1+0x134e
     79c:    80 07 41 fa     std     r18,1920(r1)
     7a0:    00 00 54 3a     addi    r18,r20,0
            7a0: R_PPC64_TOC16_LO    .rodata.str1.1+0x185d
     7a4:    00 00 80 3a     li      r20,0
     7a8:    30 03 81 f8     std     r4,816(r1)
     7ac:    00 00 82 3c     addis   r4,r2,0
            7ac: R_PPC64_TOC16_HA    .rodata.str1.1+0x136f
     7b0:    28 03 81 f8     std     r4,808(r1)
     7b4:    00 00 82 3c     addis   r4,r2,0
            7b4: R_PPC64_TOC16_HA    .rodata.str1.1+0x1390
     7b8:    20 03 81 f8     std     r4,800(r1)
     7bc:    00 00 82 3c     addis   r4,r2,0
            7bc: R_PPC64_TOC16_HA    .rodata.str1.1+0x13b1
     7c0:    78 07 41 fa     std     r18,1912(r1)
     7c4:    18 03 81 f8     std     r4,792(r1)
     7c8:    00 00 82 3c     addis   r4,r2,0
            7c8: R_PPC64_TOC16_HA    .rodata.str1.1+0x13d2
     7cc:    10 03 81 f8     std     r4,784(r1)
     7d0:    00 00 82 3c     addis   r4,r2,0
            7d0: R_PPC64_TOC16_HA    .rodata.str1.1+0x13f3
     7d4:    08 03 81 f8     std     r4,776(r1)
     7d8:    00 00 82 3c     addis   r4,r2,0
            7d8: R_PPC64_TOC16_HA    .rodata.str1.1+0x1423
     7dc:    88 07 61 f8     std     r3,1928(r1)
     7e0:    00 00 7d 38     addi    r3,r29,0
> objdump -s -j .rodata.str1.1 ./xmon.o

<snip>

 1320 20202074 72617020 3d202534 6c780a00     trap = %4lx..
 1330 64617220 3d20252e 31366c78 20202064  dar = %.16lx   d
 1340 73697372 203d2025 2e386c78 0a006d73  sisr = %.8lx..ms
 1350 72202020 203d2025 2e31366c 78202073  r    = %.16lx  s
 1360 70726730 203d2025 2e31366c 780a0070  prg0 = %.16lx..p
 1370 76722020 20203d20 252e3136 6c782020  vr    = %.16lx  
 1380 73707267 31203d20 252e3136 6c780a00  sprg1 = %.16lx..
 1390 64656320 2020203d 20252e31 366c7820  dec    = %.16lx 
 13a0 20737072 6732203d 20252e31 366c780a   sprg2 = %.16lx.
 13b0 00737020 20202020 3d20252e 31366c78  .sp     = %.16lx
 13c0 20207370 72673320 3d20252e 31366c78    sprg3 = %.16lx
 13d0 0a00746f 63202020 203d2025 2e31366c  ..toc    = %.16l
 13e0 78202064 61722020 203d2025 2e31366c  x  dar   = %.16l
 13f0 780a0073 72723020 20203d20 252e3136  x..srr0   = %.16
 1400 6c782020 73727231 20203d20 252e3136  lx  srr1  = %.16
 1410 6c782064 73697372 20203d20 252e386c  lx dsisr  = %.8l
 1420 780a0064 73637220 20203d20 252e3136  x..dscr   = %.16
 1430 6c782020 70707220 20203d20 252e3136  lx  ppr   = %.16
 1440 6c782070 69722020 20203d20 252e386c  lx pir    = %.8l
 1450 780a0061 6d722020 20203d20 252e3136  x..amr    = %.16
 1460 6c782020 75616d6f 72203d20 252e3136  lx  uamor = %.16

Clang:

       printf("Invalid number.\n");
    1ab0:    80 07 61 e8     ld      r3,1920(r1)
    1ab4:    01 00 00 48     bl      1ab4 <xmon_core+0x1a00>
            1ab4: R_PPC64_REL24    xmon_printf
    1ab8:    00 00 00 60     nop

GCC:

    printf("Invalid number.\n");
    6200:    00 00 62 3c     addis   r3,r2,0
            6200: R_PPC64_TOC16_HA    .rodata.str1.8+0x2420
    6204:    00 00 63 38     addi    r3,r3,0
            6204: R_PPC64_TOC16_LO    .rodata.str1.8+0x2420
    6208:    01 00 00 48     bl      6208 <xmon_core+0x1b98>
            6208: R_PPC64_REL24    xmon_printf
    620c:    00 00 00 60     nop
@shenki

This comment has been minimized.

Copy link
Member Author

@shenki shenki commented Oct 31, 2018

Kernel patch posted: https://patchwork.ozlabs.org/patch/991235/

This is a workaround. I think this should be fixed in clang though before we can consider this resolved.

fengguang pushed a commit to 0day-ci/linux that referenced this issue Oct 31, 2018
When building with clang (8 trunk, 7.0 release) the frame size limit is
hit:

 arch/powerpc/xmon/xmon.c:452:12: warning: stack frame size of 2576
 bytes in function 'xmon_core' [-Wframe-larger-than=]

Some investigation by Naveen indicates this is due to clang saving the
addresses to printf format strings on the stack.

While this issue is investigated, bump up the frame size limit for xmon
when building with clang.

Link: ClangBuiltLinux#252
Signed-off-by: Joel Stanley <joel@jms.id.au>
mpe added a commit to linuxppc/linux that referenced this issue Oct 31, 2018
When building with clang (8 trunk, 7.0 release) the frame size limit is
hit:

 arch/powerpc/xmon/xmon.c:452:12: warning: stack frame size of 2576
 bytes in function 'xmon_core' [-Wframe-larger-than=]

Some investigation by Naveen indicates this is due to clang saving the
addresses to printf format strings on the stack.

While this issue is investigated, bump up the frame size limit for xmon
when building with clang.

Link: ClangBuiltLinux#252
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
@tpimh tpimh added the low priority label Oct 31, 2018
nathanchance pushed a commit that referenced this issue May 7, 2019
[BUG]
When accessing a file on a crafted image, btrfs can crash in block layer:

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
  PGD 136501067 P4D 136501067 PUD 124519067 PMD 0
  CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.0.0-rc8-default #252
  RIP: 0010:end_bio_extent_readpage+0x144/0x700
  Call Trace:
   <IRQ>
   blk_update_request+0x8f/0x350
   blk_mq_end_request+0x1a/0x120
   blk_done_softirq+0x99/0xc0
   __do_softirq+0xc7/0x467
   irq_exit+0xd1/0xe0
   call_function_single_interrupt+0xf/0x20
   </IRQ>
  RIP: 0010:default_idle+0x1e/0x170

[CAUSE]
The crafted image has a tricky corruption, the INODE_ITEM has a
different type against its parent dir:

        item 20 key (268 INODE_ITEM 0) itemoff 2808 itemsize 160
                generation 13 transid 13 size 1048576 nbytes 1048576
                block group 0 mode 121644 links 1 uid 0 gid 0 rdev 0
                sequence 9 flags 0x0(none)

This mode number 0120000 means it's a symlink.

But the dir item think it's still a regular file:

        item 8 key (264 DIR_INDEX 5) itemoff 3707 itemsize 32
                location key (268 INODE_ITEM 0) type FILE
                transid 13 data_len 0 name_len 2
                name: f4
        item 40 key (264 DIR_ITEM 51821248) itemoff 1573 itemsize 32
                location key (268 INODE_ITEM 0) type FILE
                transid 13 data_len 0 name_len 2
                name: f4

For symlink, we don't set BTRFS_I(inode)->io_tree.ops and leave it
empty, as symlink is only designed to have inlined extent, all handled
by tree block read.  Thus no need to trigger btrfs_submit_bio_hook() for
inline file extent.

However end_bio_extent_readpage() expects tree->ops populated, as it's
reading regular data extent.  This causes NULL pointer dereference.

[FIX]
This patch fixes the problem in two ways:

- Verify inode mode against its dir item when looking up inode
  So in btrfs_lookup_dentry() if we find inode mode mismatch with dir
  item, we error out so that corrupted inode will not be accessed.

- Verify inode mode when getting extent mapping
  Only regular file should have regular or preallocated extent.
  If we found regular/preallocated file extent for symlink or
  the rest, we error out before submitting the read bio.

With this fix that crafted image can be rejected gracefully:

  BTRFS critical (device loop0): inode mode mismatch with dir: inode mode=0121644 btrfs type=7 dir type=1

Reported-by: Yoon Jungyeon <jungyeon@gatech.edu>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=202763
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
mrchapp pushed a commit to mrchapp/linux that referenced this issue Nov 28, 2019
[ Upstream commit 9c87156 ]

When building with clang (8 trunk, 7.0 release) the frame size limit is
hit:

 arch/powerpc/xmon/xmon.c:452:12: warning: stack frame size of 2576
 bytes in function 'xmon_core' [-Wframe-larger-than=]

Some investigation by Naveen indicates this is due to clang saving the
addresses to printf format strings on the stack.

While this issue is investigated, bump up the frame size limit for xmon
when building with clang.

Link: ClangBuiltLinux#252
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mrchapp pushed a commit to mrchapp/linux that referenced this issue Nov 28, 2019
[ Upstream commit 9c87156 ]

When building with clang (8 trunk, 7.0 release) the frame size limit is
hit:

 arch/powerpc/xmon/xmon.c:452:12: warning: stack frame size of 2576
 bytes in function 'xmon_core' [-Wframe-larger-than=]

Some investigation by Naveen indicates this is due to clang saving the
addresses to printf format strings on the stack.

While this issue is investigated, bump up the frame size limit for xmon
when building with clang.

Link: ClangBuiltLinux#252
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mrchapp pushed a commit to mrchapp/linux that referenced this issue Nov 29, 2019
[ Upstream commit 9c87156 ]

When building with clang (8 trunk, 7.0 release) the frame size limit is
hit:

 arch/powerpc/xmon/xmon.c:452:12: warning: stack frame size of 2576
 bytes in function 'xmon_core' [-Wframe-larger-than=]

Some investigation by Naveen indicates this is due to clang saving the
addresses to printf format strings on the stack.

While this issue is investigated, bump up the frame size limit for xmon
when building with clang.

Link: ClangBuiltLinux#252
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mrchapp pushed a commit to mrchapp/linux that referenced this issue Nov 29, 2019
[ Upstream commit 9c87156 ]

When building with clang (8 trunk, 7.0 release) the frame size limit is
hit:

 arch/powerpc/xmon/xmon.c:452:12: warning: stack frame size of 2576
 bytes in function 'xmon_core' [-Wframe-larger-than=]

Some investigation by Naveen indicates this is due to clang saving the
addresses to printf format strings on the stack.

While this issue is investigated, bump up the frame size limit for xmon
when building with clang.

Link: ClangBuiltLinux#252
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mrchapp pushed a commit to mrchapp/linux that referenced this issue Nov 30, 2019
[ Upstream commit 9c87156 ]

When building with clang (8 trunk, 7.0 release) the frame size limit is
hit:

 arch/powerpc/xmon/xmon.c:452:12: warning: stack frame size of 2576
 bytes in function 'xmon_core' [-Wframe-larger-than=]

Some investigation by Naveen indicates this is due to clang saving the
addresses to printf format strings on the stack.

While this issue is investigated, bump up the frame size limit for xmon
when building with clang.

Link: ClangBuiltLinux#252
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mrchapp pushed a commit to mrchapp/linux that referenced this issue Nov 30, 2019
[ Upstream commit 9c87156 ]

When building with clang (8 trunk, 7.0 release) the frame size limit is
hit:

 arch/powerpc/xmon/xmon.c:452:12: warning: stack frame size of 2576
 bytes in function 'xmon_core' [-Wframe-larger-than=]

Some investigation by Naveen indicates this is due to clang saving the
addresses to printf format strings on the stack.

While this issue is investigated, bump up the frame size limit for xmon
when building with clang.

Link: ClangBuiltLinux#252
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Whissi pushed a commit to Whissi/linux-stable that referenced this issue Dec 1, 2019
[ Upstream commit 9c87156 ]

When building with clang (8 trunk, 7.0 release) the frame size limit is
hit:

 arch/powerpc/xmon/xmon.c:452:12: warning: stack frame size of 2576
 bytes in function 'xmon_core' [-Wframe-larger-than=]

Some investigation by Naveen indicates this is due to clang saving the
addresses to printf format strings on the stack.

While this issue is investigated, bump up the frame size limit for xmon
when building with clang.

Link: ClangBuiltLinux/linux#252
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Whissi pushed a commit to Whissi/linux-stable that referenced this issue Dec 1, 2019
[ Upstream commit 9c87156 ]

When building with clang (8 trunk, 7.0 release) the frame size limit is
hit:

 arch/powerpc/xmon/xmon.c:452:12: warning: stack frame size of 2576
 bytes in function 'xmon_core' [-Wframe-larger-than=]

Some investigation by Naveen indicates this is due to clang saving the
addresses to printf format strings on the stack.

While this issue is investigated, bump up the frame size limit for xmon
when building with clang.

Link: ClangBuiltLinux/linux#252
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
isjerryxiao added a commit to archlinux-jerry/Amlogic_s905-kernel that referenced this issue Dec 1, 2019
[ Upstream commit 9c87156 ]

When building with clang (8 trunk, 7.0 release) the frame size limit is
hit:

 arch/powerpc/xmon/xmon.c:452:12: warning: stack frame size of 2576
 bytes in function 'xmon_core' [-Wframe-larger-than=]

Some investigation by Naveen indicates this is due to clang saving the
addresses to printf format strings on the stack.

While this issue is investigated, bump up the frame size limit for xmon
when building with clang.

Link: ClangBuiltLinux/linux#252
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
acervenky added a commit to acervenky/quax_raphael-q that referenced this issue Dec 9, 2019
[ Upstream commit 9c87156cce5a63735d1218f0096a65c50a7a32aa ]

When building with clang (8 trunk, 7.0 release) the frame size limit is
hit:

 arch/powerpc/xmon/xmon.c:452:12: warning: stack frame size of 2576
 bytes in function 'xmon_core' [-Wframe-larger-than=]

Some investigation by Naveen indicates this is due to clang saving the
addresses to printf format strings on the stack.

While this issue is investigated, bump up the frame size limit for xmon
when building with clang.

Link: ClangBuiltLinux/linux#252
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.