Linux-RISC-V Archive on lore.kernel.org
 help / color / Atom feed
From: Colin Ian King <colin.king@canonical.com>
To: David Abdurachmanov <david.abdurachmanov@gmail.com>,
	Andreas Schwab <schwab@suse.de>
Cc: "Albert Ou" <aou@eecs.berkeley.edu>,
	"Björn Töpel" <bjorn.topel@gmail.com>,
	syzkaller <syzkaller@googlegroups.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Tobias Klauser" <tklauser@distanz.ch>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	"Dmitry Vyukov" <dvyukov@google.com>
Subject: Re: syzkaller on risc-v
Date: Tue, 30 Jun 2020 14:37:58 +0100
Message-ID: <a0435841-bb81-ed10-23fa-aef323e741b0@canonical.com> (raw)
In-Reply-To: <CAEn-LTpDV5QQ1nkYVP9sE9T23YM_6cthT+LNUsLWYeQJ00xy7Q@mail.gmail.com>

I believe I'm also seeing some potential stack smashing issues in the
lua engine in ZFS on risc-v. It is taking a while for me to debug, but I
don't see the failure on other arches.  Is there a way to bump the stack
size up temporarily to test with larger stacks on risc-v?

Colin

On 30/06/2020 14:26, David Abdurachmanov wrote:
> On Tue, Jun 30, 2020 at 4:04 PM Andreas Schwab <schwab@suse.de> wrote:
>>
>> On Jun 30 2020, Dmitry Vyukov wrote:
>>
>>> I would assume some stack overflows can happen without KCOV as well.
>>
>> Yes, I see stack overflows quite a lot, like this:
>>
>> [62192.908680] Kernel panic - not syncing: corrupted stack end detected inside scheduler
>> [62192.915752] CPU: 0 PID: 12347 Comm: ld Not tainted 5.7.5-221-default #1 openSUSE Tumbleweed (unreleased)
>> [62192.925204] Call Trace:
>> [62192.927646] [<ffffffe0002028ae>] walk_stackframe+0x0/0xaa
>> [62192.933030] [<ffffffe000202b76>] show_stack+0x2a/0x34
>> [62192.938066] [<ffffffe000557d44>] dump_stack+0x6e/0x88
>> [62192.943098] [<ffffffe00020c2d2>] panic+0xe8/0x26a
>> [62192.947785] [<ffffffe00085ab9c>] schedule+0x0/0xb2
>> [62192.952561] [<ffffffe00085af36>] _cond_resched+0x32/0x44
>> [62192.957859] [<ffffffe0002f18ea>] invalidate_mapping_pages+0xe0/0x1ce
>> [62192.964193] [<ffffffe000370aa4>] inode_lru_isolate+0x238/0x298
>> [62192.970012] [<ffffffe000308098>] __list_lru_walk_one+0x5e/0xf6
>> [62192.975826] [<ffffffe000308516>] list_lru_walk_one+0x42/0x98
>> [62192.981470] [<ffffffe0003717e8>] prune_icache_sb+0x32/0x72
>> [62192.986941] [<ffffffe000358366>] super_cache_scan+0xe4/0x13e
>> [62192.992586] [<ffffffe0002f1fac>] do_shrink_slab+0x10e/0x17e
>> [62192.998142] [<ffffffe0002f2126>] shrink_slab_memcg+0x10a/0x1de
>> [62193.003957] [<ffffffe0002f5314>] shrink_node_memcgs+0x12e/0x1a4
>> [62193.009861] [<ffffffe0002f5484>] shrink_node+0xfa/0x43c
>> [62193.015067] [<ffffffe0002f583e>] shrink_zones+0x78/0x18c
>> [62193.020365] [<ffffffe0002f59f0>] do_try_to_free_pages+0x9e/0x23e
>> [62193.026352] [<ffffffe0002f65ac>] try_to_free_pages+0xb2/0xf4
>> [62193.031991] [<ffffffe000322952>] __alloc_pages_slowpath.constprop.0+0x2d0/0x6c2
>> [62193.039284] [<ffffffe000322e9a>] __alloc_pages_nodemask+0x156/0x1b2
>> [62193.045535] [<ffffffe00030c730>] do_anonymous_page+0x58/0x41c
>> [62193.051266] [<ffffffe00030f50e>] handle_pte_fault+0x12e/0x156
>> [62193.056994] [<ffffffe000310444>] __handle_mm_fault+0xca/0x118
>> [62193.062725] [<ffffffe000310532>] handle_mm_fault+0xa0/0x152
>> [62193.068278] [<ffffffe0002055ba>] do_page_fault+0xd6/0x370
>> [62193.073666] [<ffffffe00020140a>] ret_from_exception+0x0/0xc
>> [62193.079222] [<ffffffe0004fc16a>] copy_page_to_iter_iovec+0x4c/0x154
> 
> There was a report from Canonical that enabling gcov causes similar issues.
> 
> linux: riscv: corrupted stack detected inside scheduler
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1877954
> 
> Adding Colin to CC. So far we couldn't reproduce this locally, I
> guess, because we don't have the right config.
> 
> david
> 
> 
>>
>> or this:
>>
>> [200460.114397] Kernel panic - not syncing: corrupted stack end detected inside scheduler
>> [200460.121553] CPU: 0 PID: 32619 Comm: sh Not tainted 5.7.5-221-default #1 openSUSE Tumbleweed (unreleased)
>> [200460.131090] Call Trace:
>> [200460.133623] [<ffffffe0002028ae>] walk_stackframe+0x0/0xaa
>> [200460.139091] [<ffffffe000202b76>] show_stack+0x2a/0x34
>> [200460.144212] [<ffffffe000557d44>] dump_stack+0x6e/0x88
>> [200460.149335] [<ffffffe00020c2d2>] panic+0xe8/0x26a
>> [200460.154109] [<ffffffe00085ab9c>] schedule+0x0/0xb2
>> [200460.158969] [<ffffffe00085af36>] _cond_resched+0x32/0x44
>> [200460.164348] [<ffffffe000498572>] aa_sk_perm+0x38/0x138
>> [200460.169559] [<ffffffe00048d4b4>] apparmor_socket_sendmsg+0x18/0x20
>> [200460.175817] [<ffffffe0004508e0>] security_socket_sendmsg+0x2a/0x42
>> [200460.182061] [<ffffffe0006f4c0a>] sock_sendmsg+0x1a/0x40
>> [200460.195979] [<ffffffdf817210cc>] xprt_sock_sendmsg+0xb2/0x2b6 [sunrpc]
>> [200460.210450] [<ffffffdf81723bde>] xs_tcp_send_request+0xc6/0x206 [sunrpc]
>> [200460.224930] [<ffffffdf8171f538>] xprt_request_transmit.constprop.0+0x88/0x218 [sunrpc]
>> [200460.240731] [<ffffffdf81720610>] xprt_transmit+0x9a/0x182 [sunrpc]
>> [200460.254858] [<ffffffdf8171a584>] call_transmit+0x68/0xb8 [sunrpc]
>> [200460.268817] [<ffffffdf81726660>] __rpc_execute+0x84/0x222 [sunrpc]
>> [200460.282787] [<ffffffdf81726cea>] rpc_execute+0xac/0xb8 [sunrpc]
>> [200460.296493] [<ffffffdf8171c5ca>] rpc_run_task+0x122/0x178 [sunrpc]
>> [200460.314422] [<ffffffdf82e1533a>] nfs4_do_call_sync+0x64/0x84 [nfsv4]
>> [200460.332514] [<ffffffdf82e1541c>] _nfs4_proc_getattr+0xc2/0xd4 [nfsv4]
>> [200460.350813] [<ffffffdf82e1cafc>] nfs4_proc_getattr+0x48/0x72 [nfsv4]
>> [200460.363307] [<ffffffdf8292c1f6>] __nfs_revalidate_inode+0x104/0x2c8 [nfs]
>> [200460.376204] [<ffffffdf82926d18>] nfs_access_get_cached+0x104/0x212 [nfs]
>> [200460.389112] [<ffffffdf82926f20>] nfs_do_access+0xfa/0x178 [nfs]
>> [200460.401176] [<ffffffdf82927070>] nfs_permission+0x8e/0x184 [nfs]
>> [200460.406497] [<ffffffe000361936>] inode_permission.part.0+0x78/0x118
>> [200460.412838] [<ffffffe0003638ea>] link_path_walk.part.0+0x1bc/0x212
>> [200460.419086] [<ffffffe000363c7e>] path_lookupat+0x34/0x172
>> [200460.424559] [<ffffffe0003653de>] filename_lookup+0x5c/0xf4
>> [200460.430114] [<ffffffe00036551e>] user_path_at_empty+0x3a/0x5e
>> [200460.435931] [<ffffffe00035b838>] vfs_statx+0x62/0xbc
>> [200460.440966] [<ffffffe00035b92a>] __do_sys_newfstatat+0x24/0x3a
>> [200460.446870] [<ffffffe00035bafa>] sys_newfstatat+0x10/0x18
>> [200460.452339] [<ffffffe0002013fc>] ret_from_syscall+0x0/0x2
>>
>> Andreas.
>>
>> --
>> Andreas Schwab, SUSE Labs, schwab@suse.de
>> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
>> "And now for something completely different."
>>
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply index

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-30 12:48 Dmitry Vyukov
2020-06-30 12:57 ` Andreas Schwab
2020-06-30 13:26   ` Dmitry Vyukov
2020-06-30 13:33     ` Andreas Schwab
2020-06-30 13:40       ` Dmitry Vyukov
2020-06-30 13:45         ` Andreas Schwab
2020-06-30 13:49           ` Dmitry Vyukov
2020-06-30 13:52             ` Andreas Schwab
2020-07-01 10:42     ` Björn Töpel
2020-07-01 10:43       ` Björn Töpel
2020-07-01 11:34         ` Dmitry Vyukov
2020-07-01 13:52         ` Tobias Klauser
2020-06-30 13:03 ` Andreas Schwab
2020-06-30 13:26   ` David Abdurachmanov
2020-06-30 13:37     ` Colin Ian King [this message]
2020-06-30 13:57       ` David Abdurachmanov
2020-06-30 14:55         ` Andreas Schwab
2020-07-06 10:12         ` Colin Ian King
2020-07-14  1:21           ` Palmer Dabbelt
2020-06-30 13:07 ` Andreas Schwab
2020-06-30 13:20   ` David Abdurachmanov
2020-06-30 13:23     ` Dmitry Vyukov
2020-06-30 13:30     ` Andreas Schwab
2020-06-30 13:35       ` David Abdurachmanov
2020-06-30 13:43         ` Andreas Schwab
2020-07-02 22:00           ` Aurelien Jarno
2020-07-06  8:14             ` Andreas Schwab
2020-06-30 15:10 ` Tobias Klauser
2020-07-01 10:03   ` Dmitry Vyukov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a0435841-bb81-ed10-23fa-aef323e741b0@canonical.com \
    --to=colin.king@canonical.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=bjorn.topel@gmail.com \
    --cc=david.abdurachmanov@gmail.com \
    --cc=dvyukov@google.com \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=schwab@suse.de \
    --cc=syzkaller@googlegroups.com \
    --cc=tklauser@distanz.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-RISC-V Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-riscv/0 linux-riscv/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-riscv linux-riscv/ https://lore.kernel.org/linux-riscv \
		linux-riscv@lists.infradead.org
	public-inbox-index linux-riscv

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-riscv


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git