-
Notifications
You must be signed in to change notification settings - Fork 54.3k
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
fixed a typo #73
Open
vadik2014
wants to merge
1
commit into
torvalds:master
Choose a base branch
from
vadik2014:master
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
fixed a typo #73
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fixed a typo in .gitignore
retornaz
pushed a commit
to retornaz/linux
that referenced
this pull request
Feb 24, 2014
Turn it into (for example): [ 0.073380] x86: Booting SMP configuration: [ 0.074005] .... node #0, CPUs: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 [ 0.603005] .... node #1, CPUs: torvalds#8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 [ 1.200005] .... node #2, CPUs: torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 [ 1.796005] .... node #3, CPUs: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 [ 2.393005] .... node #4, CPUs: torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 [ 2.996005] .... node #5, CPUs: torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 [ 3.600005] .... node torvalds#6, CPUs: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 [ 4.202005] .... node torvalds#7, CPUs: torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 [ 4.811005] .... node torvalds#8, CPUs: torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71 [ 5.421006] .... node torvalds#9, CPUs: torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 [ 6.032005] .... node torvalds#10, CPUs: torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 [ 6.648006] .... node torvalds#11, CPUs: torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95 [ 7.262005] .... node torvalds#12, CPUs: torvalds#96 torvalds#97 torvalds#98 torvalds#99 torvalds#100 torvalds#101 torvalds#102 torvalds#103 [ 7.865005] .... node torvalds#13, CPUs: torvalds#104 torvalds#105 torvalds#106 torvalds#107 torvalds#108 torvalds#109 torvalds#110 torvalds#111 [ 8.466005] .... node torvalds#14, CPUs: torvalds#112 torvalds#113 torvalds#114 torvalds#115 torvalds#116 torvalds#117 torvalds#118 torvalds#119 [ 9.073006] .... node torvalds#15, CPUs: torvalds#120 torvalds#121 torvalds#122 torvalds#123 torvalds#124 torvalds#125 torvalds#126 torvalds#127 [ 9.679901] x86: Booted up 16 nodes, 128 CPUs and drop useless elements. Change num_digits() to hpa's division-avoiding, cell-phone-typed version which he went at great lengths and pains to submit on a Saturday evening. Signed-off-by: Borislav Petkov <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: Linus Torvalds <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
retornaz
pushed a commit
to retornaz/linux
that referenced
this pull request
Feb 24, 2014
commit 991fb3f "dev: always advertise rx_flags changes via netlink" introduced rtnl notification from __dev_set_promiscuity(), which can be called in atomic context. Steps to reproduce: ip tuntap add dev tap1 mode tap ifconfig tap1 up tcpdump -nei tap1 & ip tuntap del dev tap1 mode tap [ 271.627994] device tap1 left promiscuous mode [ 271.639897] BUG: sleeping function called from invalid context at mm/slub.c:940 [ 271.664491] in_atomic(): 1, irqs_disabled(): 0, pid: 3394, name: ip [ 271.677525] INFO: lockdep is turned off. [ 271.690503] CPU: 0 PID: 3394 Comm: ip Tainted: G W 3.12.0-rc3+ torvalds#73 [ 271.703996] Hardware name: System manufacturer System Product Name/P8Z77 WS, BIOS 3007 07/26/2012 [ 271.731254] ffffffff81a58506 ffff8807f0d57a58 ffffffff817544e5 ffff88082fa0f428 [ 271.760261] ffff8808071f5f40 ffff8807f0d57a88 ffffffff8108bad1 ffffffff81110ff8 [ 271.790683] 0000000000000010 00000000000000d0 00000000000000d0 ffff8807f0d57af8 [ 271.822332] Call Trace: [ 271.838234] [<ffffffff817544e5>] dump_stack+0x55/0x76 [ 271.854446] [<ffffffff8108bad1>] __might_sleep+0x181/0x240 [ 271.870836] [<ffffffff81110ff8>] ? rcu_irq_exit+0x68/0xb0 [ 271.887076] [<ffffffff811a80be>] kmem_cache_alloc_node+0x4e/0x2a0 [ 271.903368] [<ffffffff810b4ddc>] ? vprintk_emit+0x1dc/0x5a0 [ 271.919716] [<ffffffff81614d67>] ? __alloc_skb+0x57/0x2a0 [ 271.936088] [<ffffffff810b4de0>] ? vprintk_emit+0x1e0/0x5a0 [ 271.952504] [<ffffffff81614d67>] __alloc_skb+0x57/0x2a0 [ 271.968902] [<ffffffff8163a0b2>] rtmsg_ifinfo+0x52/0x100 [ 271.985302] [<ffffffff8162ac6d>] __dev_notify_flags+0xad/0xc0 [ 272.001642] [<ffffffff8162ad0c>] __dev_set_promiscuity+0x8c/0x1c0 [ 272.017917] [<ffffffff81731ea5>] ? packet_notifier+0x5/0x380 [ 272.033961] [<ffffffff8162b109>] dev_set_promiscuity+0x29/0x50 [ 272.049855] [<ffffffff8172e937>] packet_dev_mc+0x87/0xc0 [ 272.065494] [<ffffffff81732052>] packet_notifier+0x1b2/0x380 [ 272.080915] [<ffffffff81731ea5>] ? packet_notifier+0x5/0x380 [ 272.096009] [<ffffffff81761c66>] notifier_call_chain+0x66/0x150 [ 272.110803] [<ffffffff8108503e>] __raw_notifier_call_chain+0xe/0x10 [ 272.125468] [<ffffffff81085056>] raw_notifier_call_chain+0x16/0x20 [ 272.139984] [<ffffffff81620190>] call_netdevice_notifiers_info+0x40/0x70 [ 272.154523] [<ffffffff816201d6>] call_netdevice_notifiers+0x16/0x20 [ 272.168552] [<ffffffff816224c5>] rollback_registered_many+0x145/0x240 [ 272.182263] [<ffffffff81622641>] rollback_registered+0x31/0x40 [ 272.195369] [<ffffffff816229c8>] unregister_netdevice_queue+0x58/0x90 [ 272.208230] [<ffffffff81547ca0>] __tun_detach+0x140/0x340 [ 272.220686] [<ffffffff81547ed6>] tun_chr_close+0x36/0x60 Signed-off-by: Alexei Starovoitov <[email protected]> Acked-by: Nicolas Dichtel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
dongsupark
pushed a commit
to dongsupark/linux
that referenced
this pull request
Dec 17, 2014
As it's now possible to have arbitrary number of segments, mq-capable block drivers should set BLK_MQ_F_SG_MERGE in q->queue_flags. Especially virtio_blk must do it, __blk_segment_map_sg() may create too large sg lists. When QUEUE_FLAG_NO_SG_MERGE turned on, such sg lists could later trigger BUG_ON(total_sg > vq->vring.num) in virtqueue_add(). [ 26.763457] ------------[ cut here ]------------ [ 26.764147] kernel BUG at /home/mlin/linux/drivers/virtio/virtio_ring.c:160! [ 26.765010] invalid opcode: 0000 [#1] PREEMPT SMP [ 26.765273] Modules linked in: [ 26.765273] CPU: 3 PID: 25 Comm: kworker/u8:1 Not tainted 3.18.0-00030-g141405f torvalds#73 [ 26.765273] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014 [ 26.765273] Workqueue: writeback bdi_writeback_workfn (flush-254:0) [ 26.765273] task: ffff88001ebf0950 ti: ffff88001ebfc000 task.ti: ffff88001ebfc000 [ 26.765273] RIP: 0010:[<ffffffff81314359>] [<ffffffff81314359>] virtqueue_add_sgs+0x70/0x2fe [ 26.765273] RSP: 0000:ffff88001ebff6a8 EFLAGS: 00010002 [ 26.765273] RAX: 0000000000000000 RBX: ffff88001e1ad000 RCX: ffffea0000698540 [ 26.765273] RDX: ffffea0000698500 RSI: ffff88001ebff7c8 RDI: ffff88001ebff748 [ 26.765273] RBP: ffff88001ebff708 R08: ffff88001d911330 R09: 0000000000000020 [ 26.765273] R10: 0000160000000000 R11: ffff88001d7f0000 R12: ffff88001ebff7c8 [ 26.765273] R13: 0000000000000002 R14: 0000000000000082 R15: 0000000000000003 [ 26.777232] FS: 0000000000000000(0000) GS:ffff88001fd80000(0000) knlGS:0000000000000000 [ 26.777232] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 26.777232] CR2: 00007fd84f9e5000 CR3: 000000001cf6a000 CR4: 00000000000006e0 [ 26.777232] Stack: [ 26.777232] ffff88000000007f ffff880000000020 ffff88001ebff7d8 ffff88001d911330 [ 26.777232] 01ffea0000000003 0000007f00000080 0000000000000418 0000000000000000 [ 26.777232] ffff88001ebff748 ffff88001d911360 0000000000000002 ffff88001d911330 [ 26.777232] Call Trace: [ 26.777232] [<ffffffff81346b3b>] __virtblk_add_req+0x137/0x149 [ 26.777232] [<ffffffff812c027e>] ? part_round_stats+0x52/0x59 [ 26.777232] [<ffffffff812c6c2f>] ? __blk_segment_map_sg+0xbd/0x190 [ 26.777232] [<ffffffff812c6e07>] ? blk_rq_map_sg+0xb6/0x1cc [ 26.777232] [<ffffffff81346c9b>] virtio_queue_rq+0x14e/0x1ee [ 26.777232] [<ffffffff812ca138>] __blk_mq_run_hw_queue+0x1ac/0x2ad [ 26.777232] [<ffffffff812ca7f2>] blk_mq_run_hw_queue+0x3d/0x77 [ 26.777232] [<ffffffff812caf81>] blk_mq_insert_requests+0x103/0x156 [ 26.777232] [<ffffffff812cbdd5>] blk_mq_flush_plug_list+0xeb/0xfa [ 26.777232] [<ffffffff812c365f>] blk_flush_plug_list+0xb8/0x1e1 [ 26.777232] [<ffffffff812c379e>] blk_finish_plug+0x16/0x38 [ 26.777232] [<ffffffff811af1f9>] ext4_writepages+0x973/0xb66 [ 26.777232] [<ffffffff810dd9ff>] do_writepages+0x1e/0x2c [ 26.777232] [<ffffffff81145118>] __writeback_single_inode+0x84/0x298 [ 26.777232] [<ffffffff8106aa0d>] ? wake_up_bit+0x25/0x2a [ 26.777232] [<ffffffff8114638f>] writeback_sb_inodes+0x1fc/0x33d [ 26.777232] [<ffffffff81146544>] __writeback_inodes_wb+0x74/0xb9 [ 26.777232] [<ffffffff811466d5>] wb_writeback+0x14c/0x2eb [ 26.777232] [<ffffffff810dc7b1>] ? global_dirty_limits+0x1b/0x117 [ 26.777232] [<ffffffff81146b92>] bdi_writeback_workfn+0x1f6/0x40c [ 26.777232] [<ffffffff8104ded7>] process_one_work+0x1ca/0x376 [ 26.777232] [<ffffffff8104e319>] worker_thread+0x267/0x366 [ 26.777232] [<ffffffff8104e0b2>] ? process_scheduled_works+0x2f/0x2f [ 26.777232] [<ffffffff81051e7c>] kthread+0xd2/0xda [ 26.777232] [<ffffffff81490000>] ? ldsem_down_write+0x6/0x19f [ 26.777232] [<ffffffff81051daa>] ? kthread_freezable_should_stop+0x48/0x48 [ 26.777232] [<ffffffff81490b6c>] ret_from_fork+0x7c/0xb0 [ 26.777232] [<ffffffff81051daa>] ? kthread_freezable_should_stop+0x48/0x48 Signed-off-by: Ming Lin <[email protected]> [dpark: added a precise description] Signed-off-by: Dongsu Park <[email protected]>
dongsupark
pushed a commit
to dongsupark/linux
that referenced
this pull request
Dec 23, 2014
As it's now possible to have arbitrary number of segments, mq-capable block drivers should set BLK_MQ_F_SG_MERGE in q->queue_flags. Especially virtio_blk must do it, __blk_segment_map_sg() may create too large sg lists. When QUEUE_FLAG_NO_SG_MERGE turned on, such sg lists could later trigger BUG_ON(total_sg > vq->vring.num) in virtqueue_add(). [ 26.763457] ------------[ cut here ]------------ [ 26.764147] kernel BUG at /home/mlin/linux/drivers/virtio/virtio_ring.c:160! [ 26.765010] invalid opcode: 0000 [#1] PREEMPT SMP [ 26.765273] Modules linked in: [ 26.765273] CPU: 3 PID: 25 Comm: kworker/u8:1 Not tainted 3.18.0-00030-g141405f torvalds#73 [ 26.765273] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014 [ 26.765273] Workqueue: writeback bdi_writeback_workfn (flush-254:0) [ 26.765273] task: ffff88001ebf0950 ti: ffff88001ebfc000 task.ti: ffff88001ebfc000 [ 26.765273] RIP: 0010:[<ffffffff81314359>] [<ffffffff81314359>] virtqueue_add_sgs+0x70/0x2fe [ 26.765273] RSP: 0000:ffff88001ebff6a8 EFLAGS: 00010002 [ 26.765273] RAX: 0000000000000000 RBX: ffff88001e1ad000 RCX: ffffea0000698540 [ 26.765273] RDX: ffffea0000698500 RSI: ffff88001ebff7c8 RDI: ffff88001ebff748 [ 26.765273] RBP: ffff88001ebff708 R08: ffff88001d911330 R09: 0000000000000020 [ 26.765273] R10: 0000160000000000 R11: ffff88001d7f0000 R12: ffff88001ebff7c8 [ 26.765273] R13: 0000000000000002 R14: 0000000000000082 R15: 0000000000000003 [ 26.777232] FS: 0000000000000000(0000) GS:ffff88001fd80000(0000) knlGS:0000000000000000 [ 26.777232] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 26.777232] CR2: 00007fd84f9e5000 CR3: 000000001cf6a000 CR4: 00000000000006e0 [ 26.777232] Stack: [ 26.777232] ffff88000000007f ffff880000000020 ffff88001ebff7d8 ffff88001d911330 [ 26.777232] 01ffea0000000003 0000007f00000080 0000000000000418 0000000000000000 [ 26.777232] ffff88001ebff748 ffff88001d911360 0000000000000002 ffff88001d911330 [ 26.777232] Call Trace: [ 26.777232] [<ffffffff81346b3b>] __virtblk_add_req+0x137/0x149 [ 26.777232] [<ffffffff812c027e>] ? part_round_stats+0x52/0x59 [ 26.777232] [<ffffffff812c6c2f>] ? __blk_segment_map_sg+0xbd/0x190 [ 26.777232] [<ffffffff812c6e07>] ? blk_rq_map_sg+0xb6/0x1cc [ 26.777232] [<ffffffff81346c9b>] virtio_queue_rq+0x14e/0x1ee [ 26.777232] [<ffffffff812ca138>] __blk_mq_run_hw_queue+0x1ac/0x2ad [ 26.777232] [<ffffffff812ca7f2>] blk_mq_run_hw_queue+0x3d/0x77 [ 26.777232] [<ffffffff812caf81>] blk_mq_insert_requests+0x103/0x156 [ 26.777232] [<ffffffff812cbdd5>] blk_mq_flush_plug_list+0xeb/0xfa [ 26.777232] [<ffffffff812c365f>] blk_flush_plug_list+0xb8/0x1e1 [ 26.777232] [<ffffffff812c379e>] blk_finish_plug+0x16/0x38 [ 26.777232] [<ffffffff811af1f9>] ext4_writepages+0x973/0xb66 [ 26.777232] [<ffffffff810dd9ff>] do_writepages+0x1e/0x2c [ 26.777232] [<ffffffff81145118>] __writeback_single_inode+0x84/0x298 [ 26.777232] [<ffffffff8106aa0d>] ? wake_up_bit+0x25/0x2a [ 26.777232] [<ffffffff8114638f>] writeback_sb_inodes+0x1fc/0x33d [ 26.777232] [<ffffffff81146544>] __writeback_inodes_wb+0x74/0xb9 [ 26.777232] [<ffffffff811466d5>] wb_writeback+0x14c/0x2eb [ 26.777232] [<ffffffff810dc7b1>] ? global_dirty_limits+0x1b/0x117 [ 26.777232] [<ffffffff81146b92>] bdi_writeback_workfn+0x1f6/0x40c [ 26.777232] [<ffffffff8104ded7>] process_one_work+0x1ca/0x376 [ 26.777232] [<ffffffff8104e319>] worker_thread+0x267/0x366 [ 26.777232] [<ffffffff8104e0b2>] ? process_scheduled_works+0x2f/0x2f [ 26.777232] [<ffffffff81051e7c>] kthread+0xd2/0xda [ 26.777232] [<ffffffff81490000>] ? ldsem_down_write+0x6/0x19f [ 26.777232] [<ffffffff81051daa>] ? kthread_freezable_should_stop+0x48/0x48 [ 26.777232] [<ffffffff81490b6c>] ret_from_fork+0x7c/0xb0 [ 26.777232] [<ffffffff81051daa>] ? kthread_freezable_should_stop+0x48/0x48 Signed-off-by: Ming Lin <[email protected]> [dpark: added a precise description] Signed-off-by: Dongsu Park <[email protected]>
dongsupark
pushed a commit
to dongsupark/linux
that referenced
this pull request
Dec 29, 2014
As it's now possible to have arbitrary number of segments, mq-capable block drivers should set BLK_MQ_F_SG_MERGE in q->queue_flags. Especially virtio_blk must do it, __blk_segment_map_sg() may create too large sg lists. When QUEUE_FLAG_NO_SG_MERGE turned on, such sg lists could later trigger BUG_ON(total_sg > vq->vring.num) in virtqueue_add(). [ 26.763457] ------------[ cut here ]------------ [ 26.764147] kernel BUG at /home/mlin/linux/drivers/virtio/virtio_ring.c:160! [ 26.765010] invalid opcode: 0000 [#1] PREEMPT SMP [ 26.765273] Modules linked in: [ 26.765273] CPU: 3 PID: 25 Comm: kworker/u8:1 Not tainted 3.18.0-00030-g141405f torvalds#73 [ 26.765273] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014 [ 26.765273] Workqueue: writeback bdi_writeback_workfn (flush-254:0) [ 26.765273] task: ffff88001ebf0950 ti: ffff88001ebfc000 task.ti: ffff88001ebfc000 [ 26.765273] RIP: 0010:[<ffffffff81314359>] [<ffffffff81314359>] virtqueue_add_sgs+0x70/0x2fe [ 26.765273] RSP: 0000:ffff88001ebff6a8 EFLAGS: 00010002 [ 26.765273] RAX: 0000000000000000 RBX: ffff88001e1ad000 RCX: ffffea0000698540 [ 26.765273] RDX: ffffea0000698500 RSI: ffff88001ebff7c8 RDI: ffff88001ebff748 [ 26.765273] RBP: ffff88001ebff708 R08: ffff88001d911330 R09: 0000000000000020 [ 26.765273] R10: 0000160000000000 R11: ffff88001d7f0000 R12: ffff88001ebff7c8 [ 26.765273] R13: 0000000000000002 R14: 0000000000000082 R15: 0000000000000003 [ 26.777232] FS: 0000000000000000(0000) GS:ffff88001fd80000(0000) knlGS:0000000000000000 [ 26.777232] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 26.777232] CR2: 00007fd84f9e5000 CR3: 000000001cf6a000 CR4: 00000000000006e0 [ 26.777232] Stack: [ 26.777232] ffff88000000007f ffff880000000020 ffff88001ebff7d8 ffff88001d911330 [ 26.777232] 01ffea0000000003 0000007f00000080 0000000000000418 0000000000000000 [ 26.777232] ffff88001ebff748 ffff88001d911360 0000000000000002 ffff88001d911330 [ 26.777232] Call Trace: [ 26.777232] [<ffffffff81346b3b>] __virtblk_add_req+0x137/0x149 [ 26.777232] [<ffffffff812c027e>] ? part_round_stats+0x52/0x59 [ 26.777232] [<ffffffff812c6c2f>] ? __blk_segment_map_sg+0xbd/0x190 [ 26.777232] [<ffffffff812c6e07>] ? blk_rq_map_sg+0xb6/0x1cc [ 26.777232] [<ffffffff81346c9b>] virtio_queue_rq+0x14e/0x1ee [ 26.777232] [<ffffffff812ca138>] __blk_mq_run_hw_queue+0x1ac/0x2ad [ 26.777232] [<ffffffff812ca7f2>] blk_mq_run_hw_queue+0x3d/0x77 [ 26.777232] [<ffffffff812caf81>] blk_mq_insert_requests+0x103/0x156 [ 26.777232] [<ffffffff812cbdd5>] blk_mq_flush_plug_list+0xeb/0xfa [ 26.777232] [<ffffffff812c365f>] blk_flush_plug_list+0xb8/0x1e1 [ 26.777232] [<ffffffff812c379e>] blk_finish_plug+0x16/0x38 [ 26.777232] [<ffffffff811af1f9>] ext4_writepages+0x973/0xb66 [ 26.777232] [<ffffffff810dd9ff>] do_writepages+0x1e/0x2c [ 26.777232] [<ffffffff81145118>] __writeback_single_inode+0x84/0x298 [ 26.777232] [<ffffffff8106aa0d>] ? wake_up_bit+0x25/0x2a [ 26.777232] [<ffffffff8114638f>] writeback_sb_inodes+0x1fc/0x33d [ 26.777232] [<ffffffff81146544>] __writeback_inodes_wb+0x74/0xb9 [ 26.777232] [<ffffffff811466d5>] wb_writeback+0x14c/0x2eb [ 26.777232] [<ffffffff810dc7b1>] ? global_dirty_limits+0x1b/0x117 [ 26.777232] [<ffffffff81146b92>] bdi_writeback_workfn+0x1f6/0x40c [ 26.777232] [<ffffffff8104ded7>] process_one_work+0x1ca/0x376 [ 26.777232] [<ffffffff8104e319>] worker_thread+0x267/0x366 [ 26.777232] [<ffffffff8104e0b2>] ? process_scheduled_works+0x2f/0x2f [ 26.777232] [<ffffffff81051e7c>] kthread+0xd2/0xda [ 26.777232] [<ffffffff81490000>] ? ldsem_down_write+0x6/0x19f [ 26.777232] [<ffffffff81051daa>] ? kthread_freezable_should_stop+0x48/0x48 [ 26.777232] [<ffffffff81490b6c>] ret_from_fork+0x7c/0xb0 [ 26.777232] [<ffffffff81051daa>] ? kthread_freezable_should_stop+0x48/0x48 Signed-off-by: Ming Lin <[email protected]> [dpark: added a precise description] Signed-off-by: Dongsu Park <[email protected]>
dongsupark
pushed a commit
to dongsupark/linux
that referenced
this pull request
Jan 12, 2015
As it's now possible to have arbitrary number of segments, mq-capable block drivers should set BLK_MQ_F_SG_MERGE in q->queue_flags. Especially virtio_blk must do it, __blk_segment_map_sg() may create too large sg lists. When QUEUE_FLAG_NO_SG_MERGE turned on, such sg lists could later trigger BUG_ON(total_sg > vq->vring.num) in virtqueue_add(). [ 26.763457] ------------[ cut here ]------------ [ 26.764147] kernel BUG at /home/mlin/linux/drivers/virtio/virtio_ring.c:160! [ 26.765010] invalid opcode: 0000 [#1] PREEMPT SMP [ 26.765273] Modules linked in: [ 26.765273] CPU: 3 PID: 25 Comm: kworker/u8:1 Not tainted 3.18.0-00030-g141405f torvalds#73 [ 26.765273] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014 [ 26.765273] Workqueue: writeback bdi_writeback_workfn (flush-254:0) [ 26.765273] task: ffff88001ebf0950 ti: ffff88001ebfc000 task.ti: ffff88001ebfc000 [ 26.765273] RIP: 0010:[<ffffffff81314359>] [<ffffffff81314359>] virtqueue_add_sgs+0x70/0x2fe [ 26.765273] RSP: 0000:ffff88001ebff6a8 EFLAGS: 00010002 [ 26.765273] RAX: 0000000000000000 RBX: ffff88001e1ad000 RCX: ffffea0000698540 [ 26.765273] RDX: ffffea0000698500 RSI: ffff88001ebff7c8 RDI: ffff88001ebff748 [ 26.765273] RBP: ffff88001ebff708 R08: ffff88001d911330 R09: 0000000000000020 [ 26.765273] R10: 0000160000000000 R11: ffff88001d7f0000 R12: ffff88001ebff7c8 [ 26.765273] R13: 0000000000000002 R14: 0000000000000082 R15: 0000000000000003 [ 26.777232] FS: 0000000000000000(0000) GS:ffff88001fd80000(0000) knlGS:0000000000000000 [ 26.777232] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 26.777232] CR2: 00007fd84f9e5000 CR3: 000000001cf6a000 CR4: 00000000000006e0 [ 26.777232] Stack: [ 26.777232] ffff88000000007f ffff880000000020 ffff88001ebff7d8 ffff88001d911330 [ 26.777232] 01ffea0000000003 0000007f00000080 0000000000000418 0000000000000000 [ 26.777232] ffff88001ebff748 ffff88001d911360 0000000000000002 ffff88001d911330 [ 26.777232] Call Trace: [ 26.777232] [<ffffffff81346b3b>] __virtblk_add_req+0x137/0x149 [ 26.777232] [<ffffffff812c027e>] ? part_round_stats+0x52/0x59 [ 26.777232] [<ffffffff812c6c2f>] ? __blk_segment_map_sg+0xbd/0x190 [ 26.777232] [<ffffffff812c6e07>] ? blk_rq_map_sg+0xb6/0x1cc [ 26.777232] [<ffffffff81346c9b>] virtio_queue_rq+0x14e/0x1ee [ 26.777232] [<ffffffff812ca138>] __blk_mq_run_hw_queue+0x1ac/0x2ad [ 26.777232] [<ffffffff812ca7f2>] blk_mq_run_hw_queue+0x3d/0x77 [ 26.777232] [<ffffffff812caf81>] blk_mq_insert_requests+0x103/0x156 [ 26.777232] [<ffffffff812cbdd5>] blk_mq_flush_plug_list+0xeb/0xfa [ 26.777232] [<ffffffff812c365f>] blk_flush_plug_list+0xb8/0x1e1 [ 26.777232] [<ffffffff812c379e>] blk_finish_plug+0x16/0x38 [ 26.777232] [<ffffffff811af1f9>] ext4_writepages+0x973/0xb66 [ 26.777232] [<ffffffff810dd9ff>] do_writepages+0x1e/0x2c [ 26.777232] [<ffffffff81145118>] __writeback_single_inode+0x84/0x298 [ 26.777232] [<ffffffff8106aa0d>] ? wake_up_bit+0x25/0x2a [ 26.777232] [<ffffffff8114638f>] writeback_sb_inodes+0x1fc/0x33d [ 26.777232] [<ffffffff81146544>] __writeback_inodes_wb+0x74/0xb9 [ 26.777232] [<ffffffff811466d5>] wb_writeback+0x14c/0x2eb [ 26.777232] [<ffffffff810dc7b1>] ? global_dirty_limits+0x1b/0x117 [ 26.777232] [<ffffffff81146b92>] bdi_writeback_workfn+0x1f6/0x40c [ 26.777232] [<ffffffff8104ded7>] process_one_work+0x1ca/0x376 [ 26.777232] [<ffffffff8104e319>] worker_thread+0x267/0x366 [ 26.777232] [<ffffffff8104e0b2>] ? process_scheduled_works+0x2f/0x2f [ 26.777232] [<ffffffff81051e7c>] kthread+0xd2/0xda [ 26.777232] [<ffffffff81490000>] ? ldsem_down_write+0x6/0x19f [ 26.777232] [<ffffffff81051daa>] ? kthread_freezable_should_stop+0x48/0x48 [ 26.777232] [<ffffffff81490b6c>] ret_from_fork+0x7c/0xb0 [ 26.777232] [<ffffffff81051daa>] ? kthread_freezable_should_stop+0x48/0x48 Signed-off-by: Ming Lin <[email protected]> [dpark: added a precise description] Signed-off-by: Dongsu Park <[email protected]>
krzk
pushed a commit
to krzk/linux
that referenced
this pull request
May 2, 2015
ERROR: "foo * bar" should be "foo *bar" torvalds#73: FILE: mm/util.c:328: +static inline void * __page_rmapping(struct page *page) total: 1 errors, 0 warnings, 90 lines checked ./patches/mm-uninline-and-cleanup-page-mapping-related-helpers.patch has style problems, please review. If any of these errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: "Kirill A. Shutemov" <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
hzhuang1
pushed a commit
to hzhuang1/linux
that referenced
this pull request
May 22, 2015
Android: Disable PM Runtime config
torvalds
pushed a commit
that referenced
this pull request
Jul 22, 2015
Daniel Borkmann says: ==================== Couple of classifier fixes This fixes a couple of panics in the form of (analogous for cls_flow{,er}): [ 912.759276] BUG: unable to handle kernel NULL pointer dereference at (null) [ 912.759373] IP: [<ffffffffa09d4d6d>] cls_bpf_change+0x23d/0x268 [cls_bpf] [ 912.759441] PGD 8783c067 PUD 5f684067 PMD 0 [ 912.759491] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC [ 912.759543] Modules linked in: cls_bpf(E) act_gact [...] [ 912.772734] CPU: 3 PID: 10489 Comm: tc Tainted: G W E 4.2.0-rc2+ #73 [ 912.775004] Hardware name: Apple Inc. MacBookAir5,1/Mac-66F35F19FE2A0D05, BIOS MBA51.88Z.00EF.B02.1211271028 11/27/2012 [ 912.777327] task: ffff88025eaa8000 ti: ffff88005f734000 task.ti: ffff88005f734000 [ 912.779662] RIP: 0010:[<ffffffffa09d4d6d>] [<ffffffffa09d4d6d>] cls_bpf_change+0x23d/0x268 [cls_bpf] [ 912.781991] RSP: 0018:ffff88005f7379c8 EFLAGS: 00010286 [ 912.784183] RAX: ffff880201d64e48 RBX: 0000000000000000 RCX: ffff880201d64e40 [ 912.786402] RDX: 0000000000000000 RSI: ffffffffa09d51c0 RDI: ffffffffa09d51a6 [ 912.788625] RBP: ffff88005f737a68 R08: 0000000000000000 R09: 0000000000000000 [ 912.790854] R10: 0000000000000001 R11: 0000000000000001 R12: ffff880078ab5a80 [ 912.793082] R13: ffff880232b31570 R14: ffff88005f737ae0 R15: ffff8801e215d1d0 [ 912.795181] FS: 00007f3c0c80d740(0000) GS:ffff880265400000(0000) knlGS:0000000000000000 [ 912.797281] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 912.799402] CR2: 0000000000000000 CR3: 000000005460f000 CR4: 00000000001407e0 [ 912.799403] Stack: [ 912.799407] ffffffff00000000 ffff88023ea18000 000000005f737a08 0000000000000000 [ 912.799415] ffffffff81f06140 ffff880201d64e40 0000000000000000 ffff88023ea1804c [ 912.799418] 0000000000000000 ffff88023ea18044 ffff88023ea18030 ffff88023ea18038 [ 912.799418] Call Trace: [ 912.799437] [<ffffffff816d5685>] tc_ctl_tfilter+0x335/0x910 [ 912.799443] [<ffffffff813622a8>] ? security_capable+0x48/0x60 [ 912.799448] [<ffffffff816b90e5>] rtnetlink_rcv_msg+0x95/0x240 [ 912.799454] [<ffffffff810f612d>] ? trace_hardirqs_on+0xd/0x10 [ 912.799456] [<ffffffff816b902f>] ? rtnetlink_rcv+0x1f/0x40 [ 912.799459] [<ffffffff816b902f>] ? rtnetlink_rcv+0x1f/0x40 [ 912.799461] [<ffffffff816b9050>] ? rtnetlink_rcv+0x40/0x40 [ 912.799464] [<ffffffff816df38f>] netlink_rcv_skb+0xaf/0xc0 [ 912.799467] [<ffffffff816b903e>] rtnetlink_rcv+0x2e/0x40 [ 912.799469] [<ffffffff816deaef>] netlink_unicast+0xef/0x1b0 [ 912.799471] [<ffffffff816defa0>] netlink_sendmsg+0x3f0/0x620 [ 912.799476] [<ffffffff81687028>] sock_sendmsg+0x38/0x50 [ 912.799479] [<ffffffff81687938>] ___sys_sendmsg+0x288/0x290 [ 912.799482] [<ffffffff810f7852>] ? __lock_acquire+0x572/0x2050 [ 912.799488] [<ffffffff810265db>] ? native_sched_clock+0x2b/0x90 [ 912.799493] [<ffffffff8116135f>] ? __audit_syscall_entry+0xaf/0x100 [ 912.799497] [<ffffffff8116135f>] ? __audit_syscall_entry+0xaf/0x100 [ 912.799501] [<ffffffff8112aa19>] ? current_kernel_time+0x69/0xd0 [ 912.799505] [<ffffffff81266f16>] ? __fget_light+0x66/0x90 [ 912.799508] [<ffffffff81688812>] __sys_sendmsg+0x42/0x80 [ 912.799510] [<ffffffff81688862>] SyS_sendmsg+0x12/0x20 [ 912.799515] [<ffffffff817f9a6e>] entry_SYSCALL_64_fastpath+0x12/0x76 [ 912.799540] Code: 4d 88 49 8b 57 08 48 89 51 08 49 8b 57 10 48 89 c8 48 83 c0 08 48 89 51 10 48 8b 51 10 48 c7 c6 c0 51 9d a0 48 c7 c7 a6 51 9d a0 <48> 89 02 48 8b 51 08 48 89 42 08 48 b8 00 02 20 00 00 00 ad de [ 912.799544] RIP [<ffffffffa09d4d6d>] cls_bpf_change+0x23d/0x268 [cls_bpf] [ 912.799544] RSP <ffff88005f7379c8> [ 912.799545] CR2: 0000000000000000 [ 912.807380] ---[ end trace a6440067cfdc7c29 ]--- I've split them into 3 patches, so they can be backported easier when needed. ==================== Signed-off-by: David S. Miller <[email protected]>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Oct 18, 2015
WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() torvalds#46: FILE: drivers/gpu/drm/drm_gem.c:494: + BUG_ON(mapping_gfp_constraint(mapping, __GFP_DMA32) && WARNING: line over 80 characters torvalds#73: FILE: fs/btrfs/compression.c:485: + page = __page_cache_alloc(mapping_gfp_constraint(mapping, ~__GFP_FS)); WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() torvalds#183: FILE: fs/logfs/segment.c:60: + BUG_ON(mapping_gfp_constraint(mapping, __GFP_FS)); WARNING: line over 80 characters torvalds#228: FILE: fs/nilfs2/inode.c:359: + mapping_gfp_constraint(inode->i_mapping, ~__GFP_FS)); WARNING: line over 80 characters torvalds#237: FILE: fs/nilfs2/inode.c:525: + mapping_gfp_constraint(inode->i_mapping, ~__GFP_FS)); WARNING: line over 80 characters torvalds#249: FILE: fs/ntfs/file.c:529: + mapping_gfp_constraint(mapping, GFP_KERNEL)); WARNING: line over 80 characters torvalds#261: FILE: fs/splice.c:363: + mapping_gfp_constraint(mapping, GFP_KERNEL)); WARNING: line over 80 characters torvalds#290: FILE: mm/filemap.c:1725: + mapping_gfp_constraint(mapping, GFP_KERNEL)); total: 0 errors, 8 warnings, 205 lines checked ./patches/mm-fs-introduce-mapping_gfp_constraint.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Oct 21, 2015
WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() torvalds#46: FILE: drivers/gpu/drm/drm_gem.c:494: + BUG_ON(mapping_gfp_constraint(mapping, __GFP_DMA32) && WARNING: line over 80 characters torvalds#73: FILE: fs/btrfs/compression.c:485: + page = __page_cache_alloc(mapping_gfp_constraint(mapping, ~__GFP_FS)); WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() torvalds#183: FILE: fs/logfs/segment.c:60: + BUG_ON(mapping_gfp_constraint(mapping, __GFP_FS)); WARNING: line over 80 characters torvalds#228: FILE: fs/nilfs2/inode.c:359: + mapping_gfp_constraint(inode->i_mapping, ~__GFP_FS)); WARNING: line over 80 characters torvalds#237: FILE: fs/nilfs2/inode.c:525: + mapping_gfp_constraint(inode->i_mapping, ~__GFP_FS)); WARNING: line over 80 characters torvalds#249: FILE: fs/ntfs/file.c:529: + mapping_gfp_constraint(mapping, GFP_KERNEL)); WARNING: line over 80 characters torvalds#261: FILE: fs/splice.c:363: + mapping_gfp_constraint(mapping, GFP_KERNEL)); WARNING: line over 80 characters torvalds#290: FILE: mm/filemap.c:1725: + mapping_gfp_constraint(mapping, GFP_KERNEL)); total: 0 errors, 8 warnings, 205 lines checked ./patches/mm-fs-introduce-mapping_gfp_constraint.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Oct 22, 2015
WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() torvalds#46: FILE: drivers/gpu/drm/drm_gem.c:494: + BUG_ON(mapping_gfp_constraint(mapping, __GFP_DMA32) && WARNING: line over 80 characters torvalds#73: FILE: fs/btrfs/compression.c:485: + page = __page_cache_alloc(mapping_gfp_constraint(mapping, ~__GFP_FS)); WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() torvalds#183: FILE: fs/logfs/segment.c:60: + BUG_ON(mapping_gfp_constraint(mapping, __GFP_FS)); WARNING: line over 80 characters torvalds#228: FILE: fs/nilfs2/inode.c:359: + mapping_gfp_constraint(inode->i_mapping, ~__GFP_FS)); WARNING: line over 80 characters torvalds#237: FILE: fs/nilfs2/inode.c:525: + mapping_gfp_constraint(inode->i_mapping, ~__GFP_FS)); WARNING: line over 80 characters torvalds#249: FILE: fs/ntfs/file.c:529: + mapping_gfp_constraint(mapping, GFP_KERNEL)); WARNING: line over 80 characters torvalds#261: FILE: fs/splice.c:363: + mapping_gfp_constraint(mapping, GFP_KERNEL)); WARNING: line over 80 characters torvalds#290: FILE: mm/filemap.c:1725: + mapping_gfp_constraint(mapping, GFP_KERNEL)); total: 0 errors, 8 warnings, 205 lines checked ./patches/mm-fs-introduce-mapping_gfp_constraint.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
nhoriguchi
pushed a commit
to nhoriguchi/linux
that referenced
this pull request
Oct 30, 2015
WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() torvalds#46: FILE: drivers/gpu/drm/drm_gem.c:494: + BUG_ON(mapping_gfp_constraint(mapping, __GFP_DMA32) && WARNING: line over 80 characters torvalds#73: FILE: fs/btrfs/compression.c:485: + page = __page_cache_alloc(mapping_gfp_constraint(mapping, ~__GFP_FS)); WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() torvalds#183: FILE: fs/logfs/segment.c:60: + BUG_ON(mapping_gfp_constraint(mapping, __GFP_FS)); WARNING: line over 80 characters torvalds#228: FILE: fs/nilfs2/inode.c:359: + mapping_gfp_constraint(inode->i_mapping, ~__GFP_FS)); WARNING: line over 80 characters torvalds#237: FILE: fs/nilfs2/inode.c:525: + mapping_gfp_constraint(inode->i_mapping, ~__GFP_FS)); WARNING: line over 80 characters torvalds#249: FILE: fs/ntfs/file.c:529: + mapping_gfp_constraint(mapping, GFP_KERNEL)); WARNING: line over 80 characters torvalds#261: FILE: fs/splice.c:363: + mapping_gfp_constraint(mapping, GFP_KERNEL)); WARNING: line over 80 characters torvalds#290: FILE: mm/filemap.c:1725: + mapping_gfp_constraint(mapping, GFP_KERNEL)); total: 0 errors, 8 warnings, 205 lines checked ./patches/mm-fs-introduce-mapping_gfp_constraint.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Apr 26, 2016
Kyeongdon reported below error which is BUG_ON(!PageSwapCache(page)) in page_swap_info. The reason is that page_endio in rw_page unlocks the page if read I/O is completed so we need to hold a PG_lock again to check PageSwapCache. Otherwise, the page can be removed from swapcache. [27833.995833] ------------[ cut here ]------------ [27833.995853] Kernel BUG at c00f9040 [verbose debug info unavailable] [27833.995865] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [27833.995876] Modules linked in: [27833.995892] CPU: 4 PID: 13446 Comm: RenderThread Tainted: G W 3.10.84-g9f14aec-dirty torvalds#73 [27833.995903] task: c3b73200 ti: dd192000 task.ti: dd192000 [27833.995922] PC is at page_swap_info+0x10/0x2c [27833.995934] LR is at swap_slot_free_notify+0x18/0x6c [27833.995946] pc : [<c00f9040>] lr : [<c00f5560>] psr: 400f0113 [27833.995946] sp : dd193d78 ip : c2deb1e4 fp : da015180 [27833.995959] r10: 00000000 r9 : 000200da r8 : c120fe08 [27833.995968] r7 : 00000000 r6 : 00000000 r5 : c249a6c0 r4 : = c249a6c0 [27833.995979] r3 : 00000000 r2 : 40080009 r1 : 200f0113 r0 : = c249a6c0 ..<snip> [27833.996273] [<c00f9040>] (page_swap_info+0x10/0x2c) from [<c00f5560>] (swap_slot_free_notify+0x18/0x6c) [27833.996288] [<c00f5560>] (swap_slot_free_notify+0x18/0x6c) from [<c00f5c5c>] (swap_readpage+0x90/0x11c) [27833.996302] [<c00f5c5c>] (swap_readpage+0x90/0x11c) from [<c00f62dc>] (read_swap_cache_async+0x134/0x1ac) [27833.996317] [<c00f62dc>] (read_swap_cache_async+0x134/0x1ac) from [<c00f63c4>] (swapin_readahead+0x70/0xb0) [27833.996334] [<c00f63c4>] (swapin_readahead+0x70/0xb0) from = [<c00e87e0>] (handle_pte_fault+0x320/0x6fc) [27833.996348] [<c00e87e0>] (handle_pte_fault+0x320/0x6fc) from [<c00e8c7c>] (handle_mm_fault+0xc0/0xf0) [27833.996363] [<c00e8c7c>] (handle_mm_fault+0xc0/0xf0) from = [<c001ac18>] (do_page_fault+0x11c/0x36c) [27833.996378] [<c001ac18>] (do_page_fault+0x11c/0x36c) from = [<c000838c>] (do_DataAbort+0x34/0x118) [27833.996392] [<c000838c>] (do_DataAbort+0x34/0x118) from [<c000d8b4>] (__dabt_usr+0x34/0x40) Fixes: 3f2b1a0 ("zram: revive swap_slot_free_notify") Signed-off-by: Minchan Kim <[email protected]> Tested-by: Kyeongdon Kim <[email protected]> Cc: Hugh Dickins <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Apr 28, 2016
Kyeongdon reported below error which is BUG_ON(!PageSwapCache(page)) in page_swap_info. The reason is that page_endio in rw_page unlocks the page if read I/O is completed so we need to hold a PG_lock again to check PageSwapCache. Otherwise, the page can be removed from swapcache. [27833.995833] ------------[ cut here ]------------ [27833.995853] Kernel BUG at c00f9040 [verbose debug info unavailable] [27833.995865] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [27833.995876] Modules linked in: [27833.995892] CPU: 4 PID: 13446 Comm: RenderThread Tainted: G W 3.10.84-g9f14aec-dirty torvalds#73 [27833.995903] task: c3b73200 ti: dd192000 task.ti: dd192000 [27833.995922] PC is at page_swap_info+0x10/0x2c [27833.995934] LR is at swap_slot_free_notify+0x18/0x6c [27833.995946] pc : [<c00f9040>] lr : [<c00f5560>] psr: 400f0113 [27833.995946] sp : dd193d78 ip : c2deb1e4 fp : da015180 [27833.995959] r10: 00000000 r9 : 000200da r8 : c120fe08 [27833.995968] r7 : 00000000 r6 : 00000000 r5 : c249a6c0 r4 : = c249a6c0 [27833.995979] r3 : 00000000 r2 : 40080009 r1 : 200f0113 r0 : = c249a6c0 ..<snip> [27833.996273] [<c00f9040>] (page_swap_info+0x10/0x2c) from [<c00f5560>] (swap_slot_free_notify+0x18/0x6c) [27833.996288] [<c00f5560>] (swap_slot_free_notify+0x18/0x6c) from [<c00f5c5c>] (swap_readpage+0x90/0x11c) [27833.996302] [<c00f5c5c>] (swap_readpage+0x90/0x11c) from [<c00f62dc>] (read_swap_cache_async+0x134/0x1ac) [27833.996317] [<c00f62dc>] (read_swap_cache_async+0x134/0x1ac) from [<c00f63c4>] (swapin_readahead+0x70/0xb0) [27833.996334] [<c00f63c4>] (swapin_readahead+0x70/0xb0) from = [<c00e87e0>] (handle_pte_fault+0x320/0x6fc) [27833.996348] [<c00e87e0>] (handle_pte_fault+0x320/0x6fc) from [<c00e8c7c>] (handle_mm_fault+0xc0/0xf0) [27833.996363] [<c00e8c7c>] (handle_mm_fault+0xc0/0xf0) from = [<c001ac18>] (do_page_fault+0x11c/0x36c) [27833.996378] [<c001ac18>] (do_page_fault+0x11c/0x36c) from = [<c000838c>] (do_DataAbort+0x34/0x118) [27833.996392] [<c000838c>] (do_DataAbort+0x34/0x118) from [<c000d8b4>] (__dabt_usr+0x34/0x40) Fixes: 3f2b1a0 ("zram: revive swap_slot_free_notify") Signed-off-by: Minchan Kim <[email protected]> Tested-by: Kyeongdon Kim <[email protected]> Cc: Hugh Dickins <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
torvalds
pushed a commit
that referenced
this pull request
Apr 29, 2016
Kyeongdon reported below error which is BUG_ON(!PageSwapCache(page)) in page_swap_info. The reason is that page_endio in rw_page unlocks the page if read I/O is completed so we need to hold a PG_lock again to check PageSwapCache. Otherwise, the page can be removed from swapcache. Kernel BUG at c00f9040 [verbose debug info unavailable] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM Modules linked in: CPU: 4 PID: 13446 Comm: RenderThread Tainted: G W 3.10.84-g9f14aec-dirty #73 task: c3b73200 ti: dd192000 task.ti: dd192000 PC is at page_swap_info+0x10/0x2c LR is at swap_slot_free_notify+0x18/0x6c pc : [<c00f9040>] lr : [<c00f5560>] psr: 400f0113 sp : dd193d78 ip : c2deb1e4 fp : da015180 r10: 00000000 r9 : 000200da r8 : c120fe08 r7 : 00000000 r6 : 00000000 r5 : c249a6c0 r4 : = c249a6c0 r3 : 00000000 r2 : 40080009 r1 : 200f0113 r0 : = c249a6c0 ..<snip> .. Call Trace: page_swap_info+0x10/0x2c swap_slot_free_notify+0x18/0x6c swap_readpage+0x90/0x11c read_swap_cache_async+0x134/0x1ac swapin_readahead+0x70/0xb0 handle_pte_fault+0x320/0x6fc handle_mm_fault+0xc0/0xf0 do_page_fault+0x11c/0x36c do_DataAbort+0x34/0x118 Fixes: 3f2b1a0 ("zram: revive swap_slot_free_notify") Signed-off-by: Minchan Kim <[email protected]> Tested-by: Kyeongdon Kim <[email protected]> Cc: Hugh Dickins <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
ddstreet
pushed a commit
to ddstreet/linux
that referenced
this pull request
May 3, 2016
Kyeongdon reported below error which is BUG_ON(!PageSwapCache(page)) in page_swap_info. The reason is that page_endio in rw_page unlocks the page if read I/O is completed so we need to hold a PG_lock again to check PageSwapCache. Otherwise, the page can be removed from swapcache. [27833.995833] ------------[ cut here ]------------ [27833.995853] Kernel BUG at c00f9040 [verbose debug info unavailable] [27833.995865] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [27833.995876] Modules linked in: [27833.995892] CPU: 4 PID: 13446 Comm: RenderThread Tainted: G W 3.10.84-g9f14aec-dirty torvalds#73 [27833.995903] task: c3b73200 ti: dd192000 task.ti: dd192000 [27833.995922] PC is at page_swap_info+0x10/0x2c [27833.995934] LR is at swap_slot_free_notify+0x18/0x6c [27833.995946] pc : [<c00f9040>] lr : [<c00f5560>] psr: 400f0113 [27833.995946] sp : dd193d78 ip : c2deb1e4 fp : da015180 [27833.995959] r10: 00000000 r9 : 000200da r8 : c120fe08 [27833.995968] r7 : 00000000 r6 : 00000000 r5 : c249a6c0 r4 : = c249a6c0 [27833.995979] r3 : 00000000 r2 : 40080009 r1 : 200f0113 r0 : = c249a6c0 ..<snip> [27833.996273] [<c00f9040>] (page_swap_info+0x10/0x2c) from [<c00f5560>] (swap_slot_free_notify+0x18/0x6c) [27833.996288] [<c00f5560>] (swap_slot_free_notify+0x18/0x6c) from [<c00f5c5c>] (swap_readpage+0x90/0x11c) [27833.996302] [<c00f5c5c>] (swap_readpage+0x90/0x11c) from [<c00f62dc>] (read_swap_cache_async+0x134/0x1ac) [27833.996317] [<c00f62dc>] (read_swap_cache_async+0x134/0x1ac) from [<c00f63c4>] (swapin_readahead+0x70/0xb0) [27833.996334] [<c00f63c4>] (swapin_readahead+0x70/0xb0) from = [<c00e87e0>] (handle_pte_fault+0x320/0x6fc) [27833.996348] [<c00e87e0>] (handle_pte_fault+0x320/0x6fc) from [<c00e8c7c>] (handle_mm_fault+0xc0/0xf0) [27833.996363] [<c00e8c7c>] (handle_mm_fault+0xc0/0xf0) from = [<c001ac18>] (do_page_fault+0x11c/0x36c) [27833.996378] [<c001ac18>] (do_page_fault+0x11c/0x36c) from = [<c000838c>] (do_DataAbort+0x34/0x118) [27833.996392] [<c000838c>] (do_DataAbort+0x34/0x118) from [<c000d8b4>] (__dabt_usr+0x34/0x40) Fixes: 3f2b1a0 ("zram: revive swap_slot_free_notify") Signed-off-by: Minchan Kim <[email protected]> Tested-by: Kyeongdon Kim <[email protected]> Cc: Hugh Dickins <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Nov 25, 2016
WARNING: line over 80 characters torvalds#69: FILE: ipc/sem.c:1997: + * fastpath: the semop has completed, either successfully or not, from WARNING: line over 80 characters #70: FILE: ipc/sem.c:1998: + * the syscall pov, is quite irrelevant to us at this point; we're done. WARNING: line over 80 characters torvalds#73: FILE: ipc/sem.c:2001: + * spuriously. The queue.status is checked again in the slowpath (aka WARNING: line over 80 characters torvalds#74: FILE: ipc/sem.c:2002: + * after taking sem_lock), such that we can detect scenarios where we WARNING: line over 80 characters torvalds#75: FILE: ipc/sem.c:2003: + * were awakened externally, during the window between wake_q_add() and WARNING: line over 80 characters torvalds#84: FILE: ipc/sem.c:2009: + * User space could assume that semop() is a memory barrier: WARNING: line over 80 characters torvalds#85: FILE: ipc/sem.c:2010: + * Without the mb(), the cpu could speculatively read in user WARNING: line over 80 characters torvalds#86: FILE: ipc/sem.c:2011: + * space stale data that was overwritten by the previous owner total: 0 errors, 8 warnings, 127 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/ipc-sem-simplify-wait-wake-loop.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Davidlohr Bueso <[email protected]> Cc: Manfred Spraul <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Nov 30, 2016
WARNING: line over 80 characters torvalds#69: FILE: ipc/sem.c:1997: + * fastpath: the semop has completed, either successfully or not, from WARNING: line over 80 characters #70: FILE: ipc/sem.c:1998: + * the syscall pov, is quite irrelevant to us at this point; we're done. WARNING: line over 80 characters torvalds#73: FILE: ipc/sem.c:2001: + * spuriously. The queue.status is checked again in the slowpath (aka WARNING: line over 80 characters torvalds#74: FILE: ipc/sem.c:2002: + * after taking sem_lock), such that we can detect scenarios where we WARNING: line over 80 characters torvalds#75: FILE: ipc/sem.c:2003: + * were awakened externally, during the window between wake_q_add() and WARNING: line over 80 characters torvalds#84: FILE: ipc/sem.c:2009: + * User space could assume that semop() is a memory barrier: WARNING: line over 80 characters torvalds#85: FILE: ipc/sem.c:2010: + * Without the mb(), the cpu could speculatively read in user WARNING: line over 80 characters torvalds#86: FILE: ipc/sem.c:2011: + * space stale data that was overwritten by the previous owner total: 0 errors, 8 warnings, 127 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/ipc-sem-simplify-wait-wake-loop.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Davidlohr Bueso <[email protected]> Cc: Manfred Spraul <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Dec 2, 2016
WARNING: line over 80 characters torvalds#69: FILE: ipc/sem.c:1997: + * fastpath: the semop has completed, either successfully or not, from WARNING: line over 80 characters #70: FILE: ipc/sem.c:1998: + * the syscall pov, is quite irrelevant to us at this point; we're done. WARNING: line over 80 characters torvalds#73: FILE: ipc/sem.c:2001: + * spuriously. The queue.status is checked again in the slowpath (aka WARNING: line over 80 characters torvalds#74: FILE: ipc/sem.c:2002: + * after taking sem_lock), such that we can detect scenarios where we WARNING: line over 80 characters torvalds#75: FILE: ipc/sem.c:2003: + * were awakened externally, during the window between wake_q_add() and WARNING: line over 80 characters torvalds#84: FILE: ipc/sem.c:2009: + * User space could assume that semop() is a memory barrier: WARNING: line over 80 characters torvalds#85: FILE: ipc/sem.c:2010: + * Without the mb(), the cpu could speculatively read in user WARNING: line over 80 characters torvalds#86: FILE: ipc/sem.c:2011: + * space stale data that was overwritten by the previous owner total: 0 errors, 8 warnings, 127 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/ipc-sem-simplify-wait-wake-loop.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Davidlohr Bueso <[email protected]> Cc: Manfred Spraul <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Dec 8, 2016
WARNING: line over 80 characters torvalds#69: FILE: ipc/sem.c:1997: + * fastpath: the semop has completed, either successfully or not, from WARNING: line over 80 characters #70: FILE: ipc/sem.c:1998: + * the syscall pov, is quite irrelevant to us at this point; we're done. WARNING: line over 80 characters torvalds#73: FILE: ipc/sem.c:2001: + * spuriously. The queue.status is checked again in the slowpath (aka WARNING: line over 80 characters torvalds#74: FILE: ipc/sem.c:2002: + * after taking sem_lock), such that we can detect scenarios where we WARNING: line over 80 characters torvalds#75: FILE: ipc/sem.c:2003: + * were awakened externally, during the window between wake_q_add() and WARNING: line over 80 characters torvalds#84: FILE: ipc/sem.c:2009: + * User space could assume that semop() is a memory barrier: WARNING: line over 80 characters torvalds#85: FILE: ipc/sem.c:2010: + * Without the mb(), the cpu could speculatively read in user WARNING: line over 80 characters torvalds#86: FILE: ipc/sem.c:2011: + * space stale data that was overwritten by the previous owner total: 0 errors, 8 warnings, 127 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/ipc-sem-simplify-wait-wake-loop.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Davidlohr Bueso <[email protected]> Cc: Manfred Spraul <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Dec 8, 2016
WARNING: line over 80 characters torvalds#69: FILE: ipc/sem.c:1997: + * fastpath: the semop has completed, either successfully or not, from WARNING: line over 80 characters #70: FILE: ipc/sem.c:1998: + * the syscall pov, is quite irrelevant to us at this point; we're done. WARNING: line over 80 characters torvalds#73: FILE: ipc/sem.c:2001: + * spuriously. The queue.status is checked again in the slowpath (aka WARNING: line over 80 characters torvalds#74: FILE: ipc/sem.c:2002: + * after taking sem_lock), such that we can detect scenarios where we WARNING: line over 80 characters torvalds#75: FILE: ipc/sem.c:2003: + * were awakened externally, during the window between wake_q_add() and WARNING: line over 80 characters torvalds#84: FILE: ipc/sem.c:2009: + * User space could assume that semop() is a memory barrier: WARNING: line over 80 characters torvalds#85: FILE: ipc/sem.c:2010: + * Without the mb(), the cpu could speculatively read in user WARNING: line over 80 characters torvalds#86: FILE: ipc/sem.c:2011: + * space stale data that was overwritten by the previous owner total: 0 errors, 8 warnings, 127 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/ipc-sem-simplify-wait-wake-loop.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Davidlohr Bueso <[email protected]> Cc: Manfred Spraul <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Dec 10, 2016
WARNING: line over 80 characters torvalds#69: FILE: ipc/sem.c:1997: + * fastpath: the semop has completed, either successfully or not, from WARNING: line over 80 characters #70: FILE: ipc/sem.c:1998: + * the syscall pov, is quite irrelevant to us at this point; we're done. WARNING: line over 80 characters torvalds#73: FILE: ipc/sem.c:2001: + * spuriously. The queue.status is checked again in the slowpath (aka WARNING: line over 80 characters torvalds#74: FILE: ipc/sem.c:2002: + * after taking sem_lock), such that we can detect scenarios where we WARNING: line over 80 characters torvalds#75: FILE: ipc/sem.c:2003: + * were awakened externally, during the window between wake_q_add() and WARNING: line over 80 characters torvalds#84: FILE: ipc/sem.c:2009: + * User space could assume that semop() is a memory barrier: WARNING: line over 80 characters torvalds#85: FILE: ipc/sem.c:2010: + * Without the mb(), the cpu could speculatively read in user WARNING: line over 80 characters torvalds#86: FILE: ipc/sem.c:2011: + * space stale data that was overwritten by the previous owner total: 0 errors, 8 warnings, 127 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/ipc-sem-simplify-wait-wake-loop.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Davidlohr Bueso <[email protected]> Cc: Manfred Spraul <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
masahir0y
pushed a commit
to masahir0y/linux
that referenced
this pull request
Dec 12, 2016
WARNING: line over 80 characters torvalds#69: FILE: ipc/sem.c:1997: + * fastpath: the semop has completed, either successfully or not, from WARNING: line over 80 characters #70: FILE: ipc/sem.c:1998: + * the syscall pov, is quite irrelevant to us at this point; we're done. WARNING: line over 80 characters torvalds#73: FILE: ipc/sem.c:2001: + * spuriously. The queue.status is checked again in the slowpath (aka WARNING: line over 80 characters torvalds#74: FILE: ipc/sem.c:2002: + * after taking sem_lock), such that we can detect scenarios where we WARNING: line over 80 characters torvalds#75: FILE: ipc/sem.c:2003: + * were awakened externally, during the window between wake_q_add() and WARNING: line over 80 characters torvalds#84: FILE: ipc/sem.c:2009: + * User space could assume that semop() is a memory barrier: WARNING: line over 80 characters torvalds#85: FILE: ipc/sem.c:2010: + * Without the mb(), the cpu could speculatively read in user WARNING: line over 80 characters torvalds#86: FILE: ipc/sem.c:2011: + * space stale data that was overwritten by the previous owner total: 0 errors, 8 warnings, 127 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/ipc-sem-simplify-wait-wake-loop.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Davidlohr Bueso <[email protected]> Cc: Manfred Spraul <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 11, 2023
This is a BUG_ON issue as follows when running xfstest-generic-503: WARNING: CPU: 21 PID: 1385 at fs/f2fs/inode.c:762 f2fs_evict_inode+0x847/0xaa0 Modules linked in: CPU: 21 PID: 1385 Comm: umount Not tainted 5.19.0-rc5+ torvalds#73 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014 Call Trace: evict+0x129/0x2d0 dispose_list+0x4f/0xb0 evict_inodes+0x204/0x230 generic_shutdown_super+0x5b/0x1e0 kill_block_super+0x29/0x80 kill_f2fs_super+0xe6/0x140 deactivate_locked_super+0x44/0xc0 deactivate_super+0x79/0x90 cleanup_mnt+0x114/0x1a0 __cleanup_mnt+0x16/0x20 task_work_run+0x98/0x100 exit_to_user_mode_prepare+0x3d0/0x3e0 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x42/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Function flow analysis when BUG occurs: f2fs_fallocate mmap do_page_fault pte_spinlock // ---lock_pte do_wp_page wp_page_shared pte_unmap_unlock // unlock_pte do_page_mkwrite f2fs_vm_page_mkwrite down_read(invalidate_lock) lock_page if (PageMappedToDisk(page)) goto out; // set_page_dirty --NOT RUN out: up_read(invalidate_lock); finish_mkwrite_fault // unlock_pte f2fs_collapse_range down_write(i_mmap_sem) truncate_pagecache unmap_mapping_pages i_mmap_lock_write // down_write(i_mmap_rwsem) ...... zap_pte_range pte_offset_map_lock // ---lock_pte set_page_dirty f2fs_dirty_data_folio if (!folio_test_dirty(folio)) { fault_dirty_shared_page set_page_dirty f2fs_dirty_data_folio if (!folio_test_dirty(folio)) { filemap_dirty_folio f2fs_update_dirty_folio // ++ } unlock_page filemap_dirty_folio f2fs_update_dirty_folio // page count++ } pte_unmap_unlock // --unlock_pte i_mmap_unlock_write // up_write(i_mmap_rwsem) truncate_inode_pages up_write(i_mmap_sem) When race happens between mmap-do_page_fault-wp_page_shared and fallocate-truncate_pagecache-zap_pte_range, the zap_pte_range calls function set_page_dirty without page lock. Besides, though truncate_pagecache has immap and pte lock, wp_page_shared calls fault_dirty_shared_page without any. In this case, two threads race in f2fs_dirty_data_folio function. Page is set to dirty only ONCE, but the count is added TWICE by calling filemap_dirty_folio. Thus the count of dirty page cannot accord with the real dirty pages. Following is the solution to in case of race happens without any lock. Since folio_test_set_dirty in filemap_dirty_folio is atomic, judge return value will not be at risk of race. Signed-off-by: Shuqi Zhang <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 11, 2023
This is a BUG_ON issue as follows when running xfstest-generic-503: WARNING: CPU: 21 PID: 1385 at fs/f2fs/inode.c:762 f2fs_evict_inode+0x847/0xaa0 Modules linked in: CPU: 21 PID: 1385 Comm: umount Not tainted 5.19.0-rc5+ torvalds#73 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014 Call Trace: evict+0x129/0x2d0 dispose_list+0x4f/0xb0 evict_inodes+0x204/0x230 generic_shutdown_super+0x5b/0x1e0 kill_block_super+0x29/0x80 kill_f2fs_super+0xe6/0x140 deactivate_locked_super+0x44/0xc0 deactivate_super+0x79/0x90 cleanup_mnt+0x114/0x1a0 __cleanup_mnt+0x16/0x20 task_work_run+0x98/0x100 exit_to_user_mode_prepare+0x3d0/0x3e0 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x42/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Function flow analysis when BUG occurs: f2fs_fallocate mmap do_page_fault pte_spinlock // ---lock_pte do_wp_page wp_page_shared pte_unmap_unlock // unlock_pte do_page_mkwrite f2fs_vm_page_mkwrite down_read(invalidate_lock) lock_page if (PageMappedToDisk(page)) goto out; // set_page_dirty --NOT RUN out: up_read(invalidate_lock); finish_mkwrite_fault // unlock_pte f2fs_collapse_range down_write(i_mmap_sem) truncate_pagecache unmap_mapping_pages i_mmap_lock_write // down_write(i_mmap_rwsem) ...... zap_pte_range pte_offset_map_lock // ---lock_pte set_page_dirty f2fs_dirty_data_folio if (!folio_test_dirty(folio)) { fault_dirty_shared_page set_page_dirty f2fs_dirty_data_folio if (!folio_test_dirty(folio)) { filemap_dirty_folio f2fs_update_dirty_folio // ++ } unlock_page filemap_dirty_folio f2fs_update_dirty_folio // page count++ } pte_unmap_unlock // --unlock_pte i_mmap_unlock_write // up_write(i_mmap_rwsem) truncate_inode_pages up_write(i_mmap_sem) When race happens between mmap-do_page_fault-wp_page_shared and fallocate-truncate_pagecache-zap_pte_range, the zap_pte_range calls function set_page_dirty without page lock. Besides, though truncate_pagecache has immap and pte lock, wp_page_shared calls fault_dirty_shared_page without any. In this case, two threads race in f2fs_dirty_data_folio function. Page is set to dirty only ONCE, but the count is added TWICE by calling filemap_dirty_folio. Thus the count of dirty page cannot accord with the real dirty pages. Following is the solution to in case of race happens without any lock. Since folio_test_set_dirty in filemap_dirty_folio is atomic, judge return value will not be at risk of race. Signed-off-by: Shuqi Zhang <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Jan 11, 2023
This is a BUG_ON issue as follows when running xfstest-generic-503: WARNING: CPU: 21 PID: 1385 at fs/f2fs/inode.c:762 f2fs_evict_inode+0x847/0xaa0 Modules linked in: CPU: 21 PID: 1385 Comm: umount Not tainted 5.19.0-rc5+ torvalds#73 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014 Call Trace: evict+0x129/0x2d0 dispose_list+0x4f/0xb0 evict_inodes+0x204/0x230 generic_shutdown_super+0x5b/0x1e0 kill_block_super+0x29/0x80 kill_f2fs_super+0xe6/0x140 deactivate_locked_super+0x44/0xc0 deactivate_super+0x79/0x90 cleanup_mnt+0x114/0x1a0 __cleanup_mnt+0x16/0x20 task_work_run+0x98/0x100 exit_to_user_mode_prepare+0x3d0/0x3e0 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x42/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Function flow analysis when BUG occurs: f2fs_fallocate mmap do_page_fault pte_spinlock // ---lock_pte do_wp_page wp_page_shared pte_unmap_unlock // unlock_pte do_page_mkwrite f2fs_vm_page_mkwrite down_read(invalidate_lock) lock_page if (PageMappedToDisk(page)) goto out; // set_page_dirty --NOT RUN out: up_read(invalidate_lock); finish_mkwrite_fault // unlock_pte f2fs_collapse_range down_write(i_mmap_sem) truncate_pagecache unmap_mapping_pages i_mmap_lock_write // down_write(i_mmap_rwsem) ...... zap_pte_range pte_offset_map_lock // ---lock_pte set_page_dirty f2fs_dirty_data_folio if (!folio_test_dirty(folio)) { fault_dirty_shared_page set_page_dirty f2fs_dirty_data_folio if (!folio_test_dirty(folio)) { filemap_dirty_folio f2fs_update_dirty_folio // ++ } unlock_page filemap_dirty_folio f2fs_update_dirty_folio // page count++ } pte_unmap_unlock // --unlock_pte i_mmap_unlock_write // up_write(i_mmap_rwsem) truncate_inode_pages up_write(i_mmap_sem) When race happens between mmap-do_page_fault-wp_page_shared and fallocate-truncate_pagecache-zap_pte_range, the zap_pte_range calls function set_page_dirty without page lock. Besides, though truncate_pagecache has immap and pte lock, wp_page_shared calls fault_dirty_shared_page without any. In this case, two threads race in f2fs_dirty_data_folio function. Page is set to dirty only ONCE, but the count is added TWICE by calling filemap_dirty_folio. Thus the count of dirty page cannot accord with the real dirty pages. Following is the solution to in case of race happens without any lock. Since folio_test_set_dirty in filemap_dirty_folio is atomic, judge return value will not be at risk of race. Signed-off-by: Shuqi Zhang <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]>
aik
added a commit
to aik/linux
that referenced
this pull request
Jan 27, 2023
AMD SEV-ES guest kernels compiled without CONFIG_PARAVIRT crash when "perf" executes. "./perf record sleep 20" is an example. Some debugging revealed this happens when CONFIG_PARAVIRT_XXL is not defined. The problem seems to be that between DEFINE_IDTENTRY_RAW(exc_nmi) and actual reading of DB7 (which in turn causes #VC) every function is inlined and no stack frame is created (?). Replacing __always_inline with noinline in local_db_save() or native_get_debugreg() fixed the problem. Define local_db_save_exc_nmi() to demostrate that the problem better. The crash does not happen with CONFIG_PARAVIRT_XXL as in this case paravirt_get_debugreg() is used and there is an indirect call via PVOP_CALL1(). It has not been noticed as the most configs have CONFIG_XEN enabled which enables CONFIG_PARAVIRT_XXL. This happens with the recent tip/master, here is my test kernel and the config: https://github.com/aik/linux/commits/debug_dr7 Found this while testing DebugSwap (which also fixes the crash as it eliminates DB7 interception == #VC): https://lore.kernel.org/all/[email protected] Why is this crash happening and how to fix that? Thanks, aik-Standard-PC-i440FX-PIIX-1996 login: �[A[ 15.775303] BUG: NMI stack guard page was hit at 0000000003983d50 (stack is 000000007feb1fa4..00000000574369c2) [ 15.775314] stack guard page: 0000 [#1] PREEMPT SMP NOPTI [ 15.775316] CPU: 0 PID: 790 Comm: sleep Not tainted 6.2.0-rc4_aik-debugswap_ruby-954bhost torvalds#73 [ 15.775322] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown unknown [ 15.775323] RIP: 0010:error_entry+0x17/0x140 [ 15.775326] Code: f8 e9 98 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 56 48 8b 74 24 08 48 89 7c 24 08 52 51 50 41 50 41 51 41 52 41 53 53 <55> 41 54 41 55 41 56 41 57 56 31 f6 31 d2 31 c9 45 31 c0 45 31 c9 [ 15.775328] RSP: 0000:fffffe2446b2b000 EFLAGS: 00010097 [ 15.775332] RAX: fffffe2446b2b0a8 RBX: 0000000000000000 RCX: ffffffffb3a00fed [ 15.775333] RDX: 0000000000000000 RSI: ffffffffb3a00b69 RDI: fffffe2446b2b0a8 [ 15.775336] RBP: fffffe2446b2b0a8 R08: 0000000000000000 R09: 0000000000000000 [ 15.775337] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 15.775338] R13: 0000000000000000 R14: 000000000002dd80 R15: 0000000000000000 [ 15.775339] FS: 0000000000000000(0000) GS:ffff94b17dc00000(0000) knlGS:ffff94b17dc00000 [ 15.775340] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 15.775341] CR2: fffffe2446b2aff8 CR3: 00080000167b8000 CR4: 00000000003506f0 [ 15.775342] Call Trace: [ 15.775352] <NMI> [ 15.775355] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775357] ? exc_page_fault+0x11/0x120 [ 15.775360] ? asm_exc_page_fault+0x22/0x30 [ 15.775364] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775365] ? exc_page_fault+0x11/0x120 [ 15.775367] ? asm_exc_page_fault+0x22/0x30 [ 15.775368] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775369] ? exc_page_fault+0x11/0x120 [ 15.775371] ? asm_exc_page_fault+0x22/0x30 [ 15.775372] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775373] ? exc_page_fault+0x11/0x120 [ 15.775374] ? asm_exc_page_fault+0x22/0x30 [ 15.775375] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775376] ? exc_page_fault+0x11/0x120 [ 15.775378] ? asm_exc_page_fault+0x22/0x30 [ 15.775379] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775380] ? exc_page_fault+0x11/0x120 [ 15.775381] ? asm_exc_page_fault+0x22/0x30 [ 15.775382] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775383] ? exc_page_fault+0x11/0x120 [ 15.775384] ? asm_exc_page_fault+0x22/0x30 [ 15.775385] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775386] ? exc_page_fault+0x11/0x120 [ 15.775388] ? asm_exc_page_fault+0x22/0x30 [ 15.775389] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775390] ? exc_page_fault+0x11/0x120 [ 15.775391] ? asm_exc_page_fault+0x22/0x30 [ 15.775392] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775393] ? exc_page_fault+0x11/0x120 [ 15.775395] ? asm_exc_page_fault+0x22/0x30 [ 15.775396] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775397] ? exc_page_fault+0x11/0x120 [ 15.775398] ? asm_exc_page_fault+0x22/0x30 [ 15.775399] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775400] ? exc_page_fault+0x11/0x120 [ 15.775401] ? asm_exc_page_fault+0x22/0x30 [ 15.775403] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775404] ? exc_page_fault+0x11/0x120 [ 15.775405] ? asm_exc_page_fault+0x22/0x30 [ 15.775406] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775407] ? exc_page_fault+0x11/0x120 [ 15.775408] ? asm_exc_page_fault+0x22/0x30 [ 15.775409] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775410] ? exc_page_fault+0x11/0x120 [ 15.775412] ? asm_exc_page_fault+0x22/0x30 [ 15.775413] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775414] ? exc_page_fault+0x11/0x120 [ 15.775415] ? asm_exc_page_fault+0x22/0x30 [ 15.775416] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775420] ? exc_page_fault+0x11/0x120 [ 15.775421] ? asm_exc_page_fault+0x22/0x30 [ 15.775422] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775423] ? exc_page_fault+0x11/0x120 [ 15.775425] ? asm_exc_page_fault+0x22/0x30 [ 15.775426] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775427] ? exc_page_fault+0x11/0x120 [ 15.775431] ? asm_exc_page_fault+0x22/0x30 [ 15.775432] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775433] ? exc_page_fault+0x11/0x120 [ 15.775435] ? asm_exc_page_fault+0x22/0x30 [ 15.775436] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775437] ? exc_page_fault+0x11/0x120 [ 15.775438] ? asm_exc_page_fault+0x22/0x30 [ 15.775439] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775440] ? exc_page_fault+0x11/0x120 [ 15.775441] ? asm_exc_page_fault+0x22/0x30 [ 15.775442] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775443] ? exc_page_fault+0x11/0x120 [ 15.775445] ? asm_exc_page_fault+0x22/0x30 [ 15.775446] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775447] ? exc_page_fault+0x11/0x120 [ 15.775448] ? asm_exc_page_fault+0x22/0x30 [ 15.775449] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775450] ? exc_page_fault+0x11/0x120 [ 15.775454] ? asm_exc_page_fault+0x22/0x30 [ 15.775455] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775456] ? exc_page_fault+0x11/0x120 [ 15.775458] ? asm_exc_page_fault+0x22/0x30 [ 15.775459] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775460] ? exc_page_fault+0x11/0x120 [ 15.775461] ? asm_exc_page_fault+0x22/0x30 [ 15.775462] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775463] ? exc_page_fault+0x11/0x120 [ 15.775465] ? asm_exc_page_fault+0x22/0x30 [ 15.775466] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775467] ? exc_page_fault+0x11/0x120 [ 15.775468] ? asm_exc_page_fault+0x22/0x30 [ 15.775469] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775470] ? exc_page_fault+0x11/0x120 [ 15.775471] ? asm_exc_page_fault+0x22/0x30 [ 15.775472] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775473] ? exc_page_fault+0x11/0x120 [ 15.775475] ? asm_exc_page_fault+0x22/0x30 [ 15.775476] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775477] ? exc_page_fault+0x11/0x120 [ 15.775478] ? asm_exc_page_fault+0x22/0x30 [ 15.775482] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775483] ? exc_page_fault+0x11/0x120 [ 15.775485] ? asm_exc_page_fault+0x22/0x30 [ 15.775486] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775487] ? exc_page_fault+0x11/0x120 [ 15.775488] ? asm_exc_page_fault+0x22/0x30 [ 15.775490] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775491] ? exc_page_fault+0x11/0x120 [ 15.775492] ? asm_exc_page_fault+0x22/0x30 [ 15.775493] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775494] ? exc_page_fault+0x11/0x120 [ 15.775495] ? asm_exc_page_fault+0x22/0x30 [ 15.775496] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775497] ? exc_page_fault+0x11/0x120 [ 15.775499] ? asm_exc_page_fault+0x22/0x30 [ 15.775500] ? check_preemption_disabled+0x8/0xe0 [ 15.775502] ? __sev_es_ist_enter+0x13/0x100 [ 15.775503] ? exc_nmi+0x10e/0x150 [ 15.775505] ? end_repeat_nmi+0x16/0x67 [ 15.775506] ? asm_exc_double_fault+0x30/0x30 [ 15.775507] ? asm_exc_double_fault+0x30/0x30 [ 15.775508] ? asm_exc_double_fault+0x30/0x30 [ 15.775509] </NMI> [ 15.775509] <#VC> [ 15.775510] ? __show_regs.cold+0x18e/0x23d [ 15.775511] </#VC> [ 15.775511] <#DF> [ 15.775512] ? __die_body.cold+0x1a/0x1f [ 15.775513] ? die+0x26/0x40 [ 15.775517] ? handle_stack_overflow+0x44/0x60 [ 15.775518] ? exc_double_fault+0x14b/0x180 [ 15.775519] ? asm_exc_double_fault+0x1f/0x30 [ 15.775520] ? restore_regs_and_return_to_kernel+0x22/0x22 [ 15.775521] ? asm_exc_page_fault+0x9/0x30 [ 15.775522] ? error_entry+0x17/0x140 [ 15.775523] </#DF> [ 15.775523] WARNING: stack recursion on stack type 6 [ 15.775524] Modules linked in: msr efivarfs [ 15.837935] ---[ end trace 0000000000000000 ]--- Signed-off-by: Alexey Kardashevskiy <[email protected]>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Feb 1, 2023
If we bring up secondaries in parallel they might get confused unless we impose some ordering here: [ 1.360149] x86: Booting SMP configuration: [ 1.360221] .... node #0, CPUs: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 torvalds#8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 [ 1.366225] .... node #1, CPUs: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 [ 1.370219] .... node #0, CPUs: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71 [ 1.378226] .... node #1, CPUs: torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95 [ 1.382037] Brought 96 CPUs to x86/cpu:kick in 72232606 cycles [ 0.104104] smpboot: CPU 26 Converting physical 0 to logical die 1 [ 0.104104] smpboot: CPU 27 Converting physical 1 to logical package 2 [ 0.104104] smpboot: CPU 24 Converting physical 1 to logical package 3 [ 0.104104] smpboot: CPU 27 Converting physical 0 to logical die 2 [ 0.104104] smpboot: CPU 25 Converting physical 1 to logical package 4 [ 1.385609] Brought 96 CPUs to x86/cpu:wait-init in 9269218 cycles [ 1.395285] Brought CPUs online in 28930764 cycles [ 1.395469] smp: Brought up 2 nodes, 96 CPUs [ 1.395689] smpboot: Max logical packages: 2 [ 1.396222] smpboot: Total of 96 processors activated (576000.00 BogoMIPS) Do the full topology update in smp_store_cpu_info() under a spinlock to ensure that things remain consistent. [Usama Arif: fixed rebase conflict] Signed-off-by: David Woodhouse <[email protected]> Signed-off-by: Usama Arif <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Feb 8, 2023
The toplogy update is performed by the AP via smp_callin() after the BSP has called do_wait_cpu_initialized(), setting the AP's bit in cpu_callout_mask to allow it to proceed. In preparation to enable further parallelism of AP bringup, add locking to serialize the update even if multiple APs are (in future) permitted to proceed through the next stages of bringup in parallel. Without such ordering (and with that future extra parallelism), confusion ensues: [ 1.360149] x86: Booting SMP configuration: [ 1.360221] .... node #0, CPUs: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 torvalds#8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 [ 1.366225] .... node #1, CPUs: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 [ 1.370219] .... node #0, CPUs: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71 [ 1.378226] .... node #1, CPUs: torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95 [ 1.382037] Brought 96 CPUs to x86/cpu:kick in 72232606 cycles [ 0.104104] smpboot: CPU 26 Converting physical 0 to logical die 1 [ 0.104104] smpboot: CPU 27 Converting physical 1 to logical package 2 [ 0.104104] smpboot: CPU 24 Converting physical 1 to logical package 3 [ 0.104104] smpboot: CPU 27 Converting physical 0 to logical die 2 [ 0.104104] smpboot: CPU 25 Converting physical 1 to logical package 4 [ 1.385609] Brought 96 CPUs to x86/cpu:wait-init in 9269218 cycles [ 1.395285] Brought CPUs online in 28930764 cycles [ 1.395469] smp: Brought up 2 nodes, 96 CPUs [ 1.395689] smpboot: Max logical packages: 2 [ 1.396222] smpboot: Total of 96 processors activated (576000.00 BogoMIPS) [Usama Arif: fixed rebase conflict] Signed-off-by: David Woodhouse <[email protected]> Signed-off-by: Usama Arif <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Feb 9, 2023
The toplogy update is performed by the AP via smp_callin() after the BSP has called do_wait_cpu_initialized(), setting the AP's bit in cpu_callout_mask to allow it to proceed. In preparation to enable further parallelism of AP bringup, add locking to serialize the update even if multiple APs are (in future) permitted to proceed through the next stages of bringup in parallel. Without such ordering (and with that future extra parallelism), confusion ensues: [ 1.360149] x86: Booting SMP configuration: [ 1.360221] .... node #0, CPUs: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 torvalds#8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 [ 1.366225] .... node #1, CPUs: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 [ 1.370219] .... node #0, CPUs: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71 [ 1.378226] .... node #1, CPUs: torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95 [ 1.382037] Brought 96 CPUs to x86/cpu:kick in 72232606 cycles [ 0.104104] smpboot: CPU 26 Converting physical 0 to logical die 1 [ 0.104104] smpboot: CPU 27 Converting physical 1 to logical package 2 [ 0.104104] smpboot: CPU 24 Converting physical 1 to logical package 3 [ 0.104104] smpboot: CPU 27 Converting physical 0 to logical die 2 [ 0.104104] smpboot: CPU 25 Converting physical 1 to logical package 4 [ 1.385609] Brought 96 CPUs to x86/cpu:wait-init in 9269218 cycles [ 1.395285] Brought CPUs online in 28930764 cycles [ 1.395469] smp: Brought up 2 nodes, 96 CPUs [ 1.395689] smpboot: Max logical packages: 2 [ 1.396222] smpboot: Total of 96 processors activated (576000.00 BogoMIPS) [Usama Arif: fixed rebase conflict] Signed-off-by: David Woodhouse <[email protected]> Signed-off-by: Usama Arif <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Feb 15, 2023
The toplogy update is performed by the AP via smp_callin() after the BSP has called do_wait_cpu_initialized(), setting the AP's bit in cpu_callout_mask to allow it to proceed. In preparation to enable further parallelism of AP bringup, add locking to serialize the update even if multiple APs are (in future) permitted to proceed through the next stages of bringup in parallel. Without such ordering (and with that future extra parallelism), confusion ensues: [ 1.360149] x86: Booting SMP configuration: [ 1.360221] .... node #0, CPUs: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 torvalds#8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 [ 1.366225] .... node #1, CPUs: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 [ 1.370219] .... node #0, CPUs: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71 [ 1.378226] .... node #1, CPUs: torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95 [ 1.382037] Brought 96 CPUs to x86/cpu:kick in 72232606 cycles [ 0.104104] smpboot: CPU 26 Converting physical 0 to logical die 1 [ 0.104104] smpboot: CPU 27 Converting physical 1 to logical package 2 [ 0.104104] smpboot: CPU 24 Converting physical 1 to logical package 3 [ 0.104104] smpboot: CPU 27 Converting physical 0 to logical die 2 [ 0.104104] smpboot: CPU 25 Converting physical 1 to logical package 4 [ 1.385609] Brought 96 CPUs to x86/cpu:wait-init in 9269218 cycles [ 1.395285] Brought CPUs online in 28930764 cycles [ 1.395469] smp: Brought up 2 nodes, 96 CPUs [ 1.395689] smpboot: Max logical packages: 2 [ 1.396222] smpboot: Total of 96 processors activated (576000.00 BogoMIPS) [Usama Arif: fixed rebase conflict] Signed-off-by: David Woodhouse <[email protected]> Signed-off-by: Usama Arif <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
sirlucjan
pushed a commit
to CachyOS/linux
that referenced
this pull request
Feb 16, 2023
The toplogy update is performed by the AP via smp_callin() after the BSP has called do_wait_cpu_initialized(), setting the AP's bit in cpu_callout_mask to allow it to proceed. In preparation to enable further parallelism of AP bringup, add locking to serialize the update even if multiple APs are (in future) permitted to proceed through the next stages of bringup in parallel. Without such ordering (and with that future extra parallelism), confusion ensues: [ 1.360149] x86: Booting SMP configuration: [ 1.360221] .... node #0, CPUs: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 torvalds#8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 [ 1.366225] .... node #1, CPUs: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 [ 1.370219] .... node #0, CPUs: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71 [ 1.378226] .... node #1, CPUs: torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95 [ 1.382037] Brought 96 CPUs to x86/cpu:kick in 72232606 cycles [ 0.104104] smpboot: CPU 26 Converting physical 0 to logical die 1 [ 0.104104] smpboot: CPU 27 Converting physical 1 to logical package 2 [ 0.104104] smpboot: CPU 24 Converting physical 1 to logical package 3 [ 0.104104] smpboot: CPU 27 Converting physical 0 to logical die 2 [ 0.104104] smpboot: CPU 25 Converting physical 1 to logical package 4 [ 1.385609] Brought 96 CPUs to x86/cpu:wait-init in 9269218 cycles [ 1.395285] Brought CPUs online in 28930764 cycles [ 1.395469] smp: Brought up 2 nodes, 96 CPUs [ 1.395689] smpboot: Max logical packages: 2 [ 1.396222] smpboot: Total of 96 processors activated (576000.00 BogoMIPS) [Usama Arif: fixed rebase conflict] Signed-off-by: David Woodhouse <[email protected]> Signed-off-by: Usama Arif <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Mar 17, 2023
Currently, test_progs outputs all stdout/stderr as it runs, and when it is done, prints a summary. It is non-trivial for tooling to parse that output and extract meaningful information from it. This change adds a new option, `--json-summary`/`-J` that let the caller specify a file where `test_progs{,-no_alu32}` can write a summary of the run in a json format that can later be parsed by tooling. Currently, it creates a summary section with successes/skipped/failures followed by a list of failed tests and subtests. A test contains the following fields: - name: the name of the test - number: the number of the test - message: the log message that was printed by the test. - failed: A boolean indicating whether the test failed or not. Currently we only output failed tests, but in the future, successful tests could be added. - subtests: A list of subtests associated with this test. A subtest contains the following fields: - name: same as above - number: sanme as above - message: the log message that was printed by the subtest. - failed: same as above but for the subtest An example run and json content below: ``` $ sudo ./test_progs -a $(grep -v '^#' ./DENYLIST.aarch64 | awk '{print $1","}' | tr -d '\n') -j -J /tmp/test_progs.json $ jq < /tmp/test_progs.json | head -n 30 { "success": 29, "success_subtest": 23, "skipped": 3, "failed": 28, "results": [ { "name": "bpf_cookie", "number": 10, "message": "test_bpf_cookie:PASS:skel_open 0 nsec\n", "failed": true, "subtests": [ { "name": "multi_kprobe_link_api", "number": 2, "message": "kprobe_multi_link_api_subtest:PASS:load_kallsyms 0 nsec\nlibbpf: extern 'bpf_testmod_fentry_test1' (strong): not resolved\nlibbpf: failed to load object 'kprobe_multi'\nlibbpf: failed to load BPF skeleton 'kprobe_multi': -3\nkprobe_multi_link_api_subtest:FAIL:fentry_raw_skel_load unexpected error: -3\n", "failed": true }, { "name": "multi_kprobe_attach_api", "number": 3, "message": "libbpf: extern 'bpf_testmod_fentry_test1' (strong): not resolved\nlibbpf: failed to load object 'kprobe_multi'\nlibbpf: failed to load BPF skeleton 'kprobe_multi': -3\nkprobe_multi_attach_api_subtest:FAIL:fentry_raw_skel_load unexpected error: -3\n", "failed": true }, { "name": "lsm", "number": 8, "message": "lsm_subtest:PASS:lsm.link_create 0 nsec\nlsm_subtest:FAIL:stack_mprotect unexpected stack_mprotect: actual 0 != expected -1\n", "failed": true } ``` The file can then be used to print a summary of the test run and list of failing tests/subtests: ``` $ jq -r < /tmp/test_progs.json '"Success: \(.success)/\(.success_subtest), Skipped: \(.skipped), Failed: \(.failed)"' Success: 29/23, Skipped: 3, Failed: 28 $ jq -r < /tmp/test_progs.json '.results | map([ if .failed then "#\(.number) \(.name)" else empty end, ( . as {name: $tname, number: $tnum} | .subtests | map( if .failed then "#\($tnum)/\(.number) \($tname)/\(.name)" else empty end ) ) ]) | flatten | .[]' | head -n 20 torvalds#10 bpf_cookie torvalds#10/2 bpf_cookie/multi_kprobe_link_api torvalds#10/3 bpf_cookie/multi_kprobe_attach_api torvalds#10/8 bpf_cookie/lsm torvalds#15 bpf_mod_race torvalds#15/1 bpf_mod_race/ksym (used_btfs UAF) torvalds#15/2 bpf_mod_race/kfunc (kfunc_btf_tab UAF) torvalds#36 cgroup_hierarchical_stats torvalds#61 deny_namespace torvalds#61/1 deny_namespace/unpriv_userns_create_no_bpf torvalds#73 fexit_stress torvalds#83 get_func_ip_test torvalds#99 kfunc_dynptr_param torvalds#99/1 kfunc_dynptr_param/dynptr_data_null torvalds#99/4 kfunc_dynptr_param/dynptr_data_null torvalds#100 kprobe_multi_bench_attach torvalds#100/1 kprobe_multi_bench_attach/kernel torvalds#100/2 kprobe_multi_bench_attach/modules torvalds#101 kprobe_multi_test torvalds#101/1 kprobe_multi_test/skel_api ``` Signed-off-by: Manu Bretelle <[email protected]>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Mar 17, 2023
Currently, test_progs outputs all stdout/stderr as it runs, and when it is done, prints a summary. It is non-trivial for tooling to parse that output and extract meaningful information from it. This change adds a new option, `--json-summary`/`-J` that let the caller specify a file where `test_progs{,-no_alu32}` can write a summary of the run in a json format that can later be parsed by tooling. Currently, it creates a summary section with successes/skipped/failures followed by a list of failed tests and subtests. A test contains the following fields: - name: the name of the test - number: the number of the test - message: the log message that was printed by the test. - failed: A boolean indicating whether the test failed or not. Currently we only output failed tests, but in the future, successful tests could be added. - subtests: A list of subtests associated with this test. A subtest contains the following fields: - name: same as above - number: sanme as above - message: the log message that was printed by the subtest. - failed: same as above but for the subtest An example run and json content below: ``` $ sudo ./test_progs -a $(grep -v '^#' ./DENYLIST.aarch64 | awk '{print $1","}' | tr -d '\n') -j -J /tmp/test_progs.json $ jq < /tmp/test_progs.json | head -n 30 { "success": 29, "success_subtest": 23, "skipped": 3, "failed": 28, "results": [ { "name": "bpf_cookie", "number": 10, "message": "test_bpf_cookie:PASS:skel_open 0 nsec\n", "failed": true, "subtests": [ { "name": "multi_kprobe_link_api", "number": 2, "message": "kprobe_multi_link_api_subtest:PASS:load_kallsyms 0 nsec\nlibbpf: extern 'bpf_testmod_fentry_test1' (strong): not resolved\nlibbpf: failed to load object 'kprobe_multi'\nlibbpf: failed to load BPF skeleton 'kprobe_multi': -3\nkprobe_multi_link_api_subtest:FAIL:fentry_raw_skel_load unexpected error: -3\n", "failed": true }, { "name": "multi_kprobe_attach_api", "number": 3, "message": "libbpf: extern 'bpf_testmod_fentry_test1' (strong): not resolved\nlibbpf: failed to load object 'kprobe_multi'\nlibbpf: failed to load BPF skeleton 'kprobe_multi': -3\nkprobe_multi_attach_api_subtest:FAIL:fentry_raw_skel_load unexpected error: -3\n", "failed": true }, { "name": "lsm", "number": 8, "message": "lsm_subtest:PASS:lsm.link_create 0 nsec\nlsm_subtest:FAIL:stack_mprotect unexpected stack_mprotect: actual 0 != expected -1\n", "failed": true } ``` The file can then be used to print a summary of the test run and list of failing tests/subtests: ``` $ jq -r < /tmp/test_progs.json '"Success: \(.success)/\(.success_subtest), Skipped: \(.skipped), Failed: \(.failed)"' Success: 29/23, Skipped: 3, Failed: 28 $ jq -r < /tmp/test_progs.json '.results | map([ if .failed then "#\(.number) \(.name)" else empty end, ( . as {name: $tname, number: $tnum} | .subtests | map( if .failed then "#\($tnum)/\(.number) \($tname)/\(.name)" else empty end ) ) ]) | flatten | .[]' | head -n 20 torvalds#10 bpf_cookie torvalds#10/2 bpf_cookie/multi_kprobe_link_api torvalds#10/3 bpf_cookie/multi_kprobe_attach_api torvalds#10/8 bpf_cookie/lsm torvalds#15 bpf_mod_race torvalds#15/1 bpf_mod_race/ksym (used_btfs UAF) torvalds#15/2 bpf_mod_race/kfunc (kfunc_btf_tab UAF) torvalds#36 cgroup_hierarchical_stats torvalds#61 deny_namespace torvalds#61/1 deny_namespace/unpriv_userns_create_no_bpf torvalds#73 fexit_stress torvalds#83 get_func_ip_test torvalds#99 kfunc_dynptr_param torvalds#99/1 kfunc_dynptr_param/dynptr_data_null torvalds#99/4 kfunc_dynptr_param/dynptr_data_null torvalds#100 kprobe_multi_bench_attach torvalds#100/1 kprobe_multi_bench_attach/kernel torvalds#100/2 kprobe_multi_bench_attach/modules torvalds#101 kprobe_multi_test torvalds#101/1 kprobe_multi_test/skel_api ``` Signed-off-by: Manu Bretelle <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Sep 30, 2023
WARNING: else is not generally useful after a break or return torvalds#73: FILE: mm/memcontrol.c:3135: + return objcg; + } else { total: 0 errors, 1 warnings, 111 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-kmem-scoped-objcg-protection.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: David Rientjes <[email protected]> Cc: Dennis Zhou <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Muchun Song <[email protected]> Cc: Roman Gushchin (Cruise) <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: Vlastimil Babka <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Sep 30, 2023
WARNING: else is not generally useful after a break or return torvalds#73: FILE: mm/memcontrol.c:3135: + return objcg; + } else { total: 0 errors, 1 warnings, 111 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-kmem-scoped-objcg-protection.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: David Rientjes <[email protected]> Cc: Dennis Zhou <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Muchun Song <[email protected]> Cc: Roman Gushchin (Cruise) <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: Vlastimil Babka <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Oct 2, 2023
WARNING: else is not generally useful after a break or return torvalds#73: FILE: mm/memcontrol.c:3135: + return objcg; + } else { total: 0 errors, 1 warnings, 111 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-kmem-scoped-objcg-protection.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: David Rientjes <[email protected]> Cc: Dennis Zhou <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Muchun Song <[email protected]> Cc: Roman Gushchin (Cruise) <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: Vlastimil Babka <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Oct 2, 2023
WARNING: else is not generally useful after a break or return torvalds#73: FILE: mm/memcontrol.c:3135: + return objcg; + } else { total: 0 errors, 1 warnings, 111 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-kmem-scoped-objcg-protection.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: David Rientjes <[email protected]> Cc: Dennis Zhou <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Muchun Song <[email protected]> Cc: Roman Gushchin (Cruise) <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: Vlastimil Babka <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Oct 4, 2023
WARNING: else is not generally useful after a break or return torvalds#73: FILE: mm/memcontrol.c:3135: + return objcg; + } else { total: 0 errors, 1 warnings, 111 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-kmem-scoped-objcg-protection.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: David Rientjes <[email protected]> Cc: Dennis Zhou <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Muchun Song <[email protected]> Cc: Roman Gushchin (Cruise) <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: Vlastimil Babka <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
akiyks
pushed a commit
to akiyks/linux
that referenced
this pull request
Oct 5, 2023
WARNING: else is not generally useful after a break or return torvalds#73: FILE: mm/memcontrol.c:3135: + return objcg; + } else { total: 0 errors, 1 warnings, 111 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-kmem-scoped-objcg-protection.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: David Rientjes <[email protected]> Cc: Dennis Zhou <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Muchun Song <[email protected]> Cc: Roman Gushchin (Cruise) <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: Vlastimil Babka <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Oct 7, 2023
WARNING: else is not generally useful after a break or return torvalds#73: FILE: mm/memcontrol.c:3135: + return objcg; + } else { total: 0 errors, 1 warnings, 111 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-kmem-scoped-objcg-protection.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: David Rientjes <[email protected]> Cc: Dennis Zhou <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Muchun Song <[email protected]> Cc: Roman Gushchin (Cruise) <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: Vlastimil Babka <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Oct 10, 2023
WARNING: else is not generally useful after a break or return torvalds#73: FILE: mm/memcontrol.c:3135: + return objcg; + } else { total: 0 errors, 1 warnings, 111 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/mm-kmem-scoped-objcg-protection.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: David Rientjes <[email protected]> Cc: Dennis Zhou <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Muchun Song <[email protected]> Cc: Roman Gushchin (Cruise) <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: Vlastimil Babka <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Oct 22, 2023
This command: $ perf record -e cycles:k -e instructions:k -c 10000 -m 64M dd if=/dev/zero of=/dev/null count=1000 gives rise to this kernel warning: [ 444.364395] WARNING: CPU: 0 PID: 104 at kernel/smp.c:775 smp_call_function_many_cond+0x42c/0x436 [ 444.364515] Modules linked in: [ 444.364657] CPU: 0 PID: 104 Comm: perf-exec Not tainted 6.6.0-rc6-00051-g391df82e8ec3-dirty torvalds#73 [ 444.364771] Hardware name: riscv-virtio,qemu (DT) [ 444.364868] epc : smp_call_function_many_cond+0x42c/0x436 [ 444.364917] ra : on_each_cpu_cond_mask+0x20/0x32 [ 444.364948] epc : ffffffff8009f9e0 ra : ffffffff8009fa5a sp : ff20000000003800 [ 444.364966] gp : ffffffff81500aa0 tp : ff60000002b83000 t0 : ff200000000038c0 [ 444.364982] t1 : ffffffff815021f0 t2 : 000000000000001f s0 : ff200000000038b0 [ 444.364998] s1 : ff60000002c54d98 a0 : ff60000002a73940 a1 : 0000000000000000 [ 444.365013] a2 : 0000000000000000 a3 : 0000000000000003 a4 : 0000000000000100 [ 444.365029] a5 : 0000000000010100 a6 : 0000000000f00000 a7 : 0000000000000000 [ 444.365044] s2 : 0000000000000000 s3 : ffffffffffffffff s4 : ff60000002c54d98 [ 444.365060] s5 : ffffffff81539610 s6 : ffffffff80c20c48 s7 : 0000000000000000 [ 444.365075] s8 : 0000000000000000 s9 : 0000000000000001 s10: 0000000000000001 [ 444.365090] s11: ffffffff80099394 t3 : 0000000000000003 t4 : 00000000eac0c6e6 [ 444.365104] t5 : 0000000400000000 t6 : ff60000002e010d0 [ 444.365120] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [ 444.365226] [<ffffffff8009f9e0>] smp_call_function_many_cond+0x42c/0x436 [ 444.365295] [<ffffffff8009fa5a>] on_each_cpu_cond_mask+0x20/0x32 [ 444.365311] [<ffffffff806e90dc>] pmu_sbi_ctr_start+0x7a/0xaa [ 444.365327] [<ffffffff806e880c>] riscv_pmu_start+0x48/0x66 [ 444.365339] [<ffffffff8012111a>] perf_adjust_freq_unthr_context+0x196/0x1ac [ 444.365356] [<ffffffff801237aa>] perf_event_task_tick+0x78/0x8c [ 444.365368] [<ffffffff8003faf4>] scheduler_tick+0xe6/0x25e [ 444.365383] [<ffffffff8008a042>] update_process_times+0x80/0x96 [ 444.365398] [<ffffffff800991ec>] tick_sched_handle+0x26/0x52 [ 444.365410] [<ffffffff800993e4>] tick_sched_timer+0x50/0x98 [ 444.365422] [<ffffffff8008a6aa>] __hrtimer_run_queues+0x126/0x18a [ 444.365433] [<ffffffff8008b350>] hrtimer_interrupt+0xce/0x1da [ 444.365444] [<ffffffff806cdc60>] riscv_timer_interrupt+0x30/0x3a [ 444.365457] [<ffffffff8006afa6>] handle_percpu_devid_irq+0x80/0x114 [ 444.365470] [<ffffffff80065b82>] generic_handle_domain_irq+0x1c/0x2a [ 444.365483] [<ffffffff8045faec>] riscv_intc_irq+0x2e/0x46 [ 444.365497] [<ffffffff808a9c62>] handle_riscv_irq+0x4a/0x74 [ 444.365521] [<ffffffff808aa760>] do_irq+0x7c/0x7e [ 444.365796] ---[ end trace 0000000000000000 ]--- That's because the fix in commit 3fec323 ("drivers: perf: Fix panic in riscv SBI mmap support") was wrong since there is no need to broadcast to other cpus when starting a counter, that's only needed in mmap when the counters could have already been started on other cpus, so simply remove this broadcast. Fixes: 3fec323 ("drivers: perf: Fix panic in riscv SBI mmap support") Signed-off-by: Alexandre Ghiti <[email protected]> Tested-by: Clément Léger <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Oct 26, 2023
This command: $ perf record -e cycles:k -e instructions:k -c 10000 -m 64M dd if=/dev/zero of=/dev/null count=1000 gives rise to this kernel warning: [ 444.364395] WARNING: CPU: 0 PID: 104 at kernel/smp.c:775 smp_call_function_many_cond+0x42c/0x436 [ 444.364515] Modules linked in: [ 444.364657] CPU: 0 PID: 104 Comm: perf-exec Not tainted 6.6.0-rc6-00051-g391df82e8ec3-dirty torvalds#73 [ 444.364771] Hardware name: riscv-virtio,qemu (DT) [ 444.364868] epc : smp_call_function_many_cond+0x42c/0x436 [ 444.364917] ra : on_each_cpu_cond_mask+0x20/0x32 [ 444.364948] epc : ffffffff8009f9e0 ra : ffffffff8009fa5a sp : ff20000000003800 [ 444.364966] gp : ffffffff81500aa0 tp : ff60000002b83000 t0 : ff200000000038c0 [ 444.364982] t1 : ffffffff815021f0 t2 : 000000000000001f s0 : ff200000000038b0 [ 444.364998] s1 : ff60000002c54d98 a0 : ff60000002a73940 a1 : 0000000000000000 [ 444.365013] a2 : 0000000000000000 a3 : 0000000000000003 a4 : 0000000000000100 [ 444.365029] a5 : 0000000000010100 a6 : 0000000000f00000 a7 : 0000000000000000 [ 444.365044] s2 : 0000000000000000 s3 : ffffffffffffffff s4 : ff60000002c54d98 [ 444.365060] s5 : ffffffff81539610 s6 : ffffffff80c20c48 s7 : 0000000000000000 [ 444.365075] s8 : 0000000000000000 s9 : 0000000000000001 s10: 0000000000000001 [ 444.365090] s11: ffffffff80099394 t3 : 0000000000000003 t4 : 00000000eac0c6e6 [ 444.365104] t5 : 0000000400000000 t6 : ff60000002e010d0 [ 444.365120] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [ 444.365226] [<ffffffff8009f9e0>] smp_call_function_many_cond+0x42c/0x436 [ 444.365295] [<ffffffff8009fa5a>] on_each_cpu_cond_mask+0x20/0x32 [ 444.365311] [<ffffffff806e90dc>] pmu_sbi_ctr_start+0x7a/0xaa [ 444.365327] [<ffffffff806e880c>] riscv_pmu_start+0x48/0x66 [ 444.365339] [<ffffffff8012111a>] perf_adjust_freq_unthr_context+0x196/0x1ac [ 444.365356] [<ffffffff801237aa>] perf_event_task_tick+0x78/0x8c [ 444.365368] [<ffffffff8003faf4>] scheduler_tick+0xe6/0x25e [ 444.365383] [<ffffffff8008a042>] update_process_times+0x80/0x96 [ 444.365398] [<ffffffff800991ec>] tick_sched_handle+0x26/0x52 [ 444.365410] [<ffffffff800993e4>] tick_sched_timer+0x50/0x98 [ 444.365422] [<ffffffff8008a6aa>] __hrtimer_run_queues+0x126/0x18a [ 444.365433] [<ffffffff8008b350>] hrtimer_interrupt+0xce/0x1da [ 444.365444] [<ffffffff806cdc60>] riscv_timer_interrupt+0x30/0x3a [ 444.365457] [<ffffffff8006afa6>] handle_percpu_devid_irq+0x80/0x114 [ 444.365470] [<ffffffff80065b82>] generic_handle_domain_irq+0x1c/0x2a [ 444.365483] [<ffffffff8045faec>] riscv_intc_irq+0x2e/0x46 [ 444.365497] [<ffffffff808a9c62>] handle_riscv_irq+0x4a/0x74 [ 444.365521] [<ffffffff808aa760>] do_irq+0x7c/0x7e [ 444.365796] ---[ end trace 0000000000000000 ]--- That's because the fix in commit 3fec323 ("drivers: perf: Fix panic in riscv SBI mmap support") was wrong since there is no need to broadcast to other cpus when starting a counter, that's only needed in mmap when the counters could have already been started on other cpus, so simply remove this broadcast. Fixes: 3fec323 ("drivers: perf: Fix panic in riscv SBI mmap support") Signed-off-by: Alexandre Ghiti <[email protected]> Tested-by: Clément Léger <[email protected]> Tested-by: Yu Chien Peter Lin <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Oct 26, 2023
This command: $ perf record -e cycles:k -e instructions:k -c 10000 -m 64M dd if=/dev/zero of=/dev/null count=1000 gives rise to this kernel warning: [ 444.364395] WARNING: CPU: 0 PID: 104 at kernel/smp.c:775 smp_call_function_many_cond+0x42c/0x436 [ 444.364515] Modules linked in: [ 444.364657] CPU: 0 PID: 104 Comm: perf-exec Not tainted 6.6.0-rc6-00051-g391df82e8ec3-dirty torvalds#73 [ 444.364771] Hardware name: riscv-virtio,qemu (DT) [ 444.364868] epc : smp_call_function_many_cond+0x42c/0x436 [ 444.364917] ra : on_each_cpu_cond_mask+0x20/0x32 [ 444.364948] epc : ffffffff8009f9e0 ra : ffffffff8009fa5a sp : ff20000000003800 [ 444.364966] gp : ffffffff81500aa0 tp : ff60000002b83000 t0 : ff200000000038c0 [ 444.364982] t1 : ffffffff815021f0 t2 : 000000000000001f s0 : ff200000000038b0 [ 444.364998] s1 : ff60000002c54d98 a0 : ff60000002a73940 a1 : 0000000000000000 [ 444.365013] a2 : 0000000000000000 a3 : 0000000000000003 a4 : 0000000000000100 [ 444.365029] a5 : 0000000000010100 a6 : 0000000000f00000 a7 : 0000000000000000 [ 444.365044] s2 : 0000000000000000 s3 : ffffffffffffffff s4 : ff60000002c54d98 [ 444.365060] s5 : ffffffff81539610 s6 : ffffffff80c20c48 s7 : 0000000000000000 [ 444.365075] s8 : 0000000000000000 s9 : 0000000000000001 s10: 0000000000000001 [ 444.365090] s11: ffffffff80099394 t3 : 0000000000000003 t4 : 00000000eac0c6e6 [ 444.365104] t5 : 0000000400000000 t6 : ff60000002e010d0 [ 444.365120] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [ 444.365226] [<ffffffff8009f9e0>] smp_call_function_many_cond+0x42c/0x436 [ 444.365295] [<ffffffff8009fa5a>] on_each_cpu_cond_mask+0x20/0x32 [ 444.365311] [<ffffffff806e90dc>] pmu_sbi_ctr_start+0x7a/0xaa [ 444.365327] [<ffffffff806e880c>] riscv_pmu_start+0x48/0x66 [ 444.365339] [<ffffffff8012111a>] perf_adjust_freq_unthr_context+0x196/0x1ac [ 444.365356] [<ffffffff801237aa>] perf_event_task_tick+0x78/0x8c [ 444.365368] [<ffffffff8003faf4>] scheduler_tick+0xe6/0x25e [ 444.365383] [<ffffffff8008a042>] update_process_times+0x80/0x96 [ 444.365398] [<ffffffff800991ec>] tick_sched_handle+0x26/0x52 [ 444.365410] [<ffffffff800993e4>] tick_sched_timer+0x50/0x98 [ 444.365422] [<ffffffff8008a6aa>] __hrtimer_run_queues+0x126/0x18a [ 444.365433] [<ffffffff8008b350>] hrtimer_interrupt+0xce/0x1da [ 444.365444] [<ffffffff806cdc60>] riscv_timer_interrupt+0x30/0x3a [ 444.365457] [<ffffffff8006afa6>] handle_percpu_devid_irq+0x80/0x114 [ 444.365470] [<ffffffff80065b82>] generic_handle_domain_irq+0x1c/0x2a [ 444.365483] [<ffffffff8045faec>] riscv_intc_irq+0x2e/0x46 [ 444.365497] [<ffffffff808a9c62>] handle_riscv_irq+0x4a/0x74 [ 444.365521] [<ffffffff808aa760>] do_irq+0x7c/0x7e [ 444.365796] ---[ end trace 0000000000000000 ]--- That's because the fix in commit 3fec323 ("drivers: perf: Fix panic in riscv SBI mmap support") was wrong since there is no need to broadcast to other cpus when starting a counter, that's only needed in mmap when the counters could have already been started on other cpus, so simply remove this broadcast. Fixes: 3fec323 ("drivers: perf: Fix panic in riscv SBI mmap support") Signed-off-by: Alexandre Ghiti <[email protected]> Tested-by: Clément Léger <[email protected]> Tested-by: Yu Chien Peter Lin <[email protected]>
prabhakarlad
pushed a commit
to prabhakarlad/linux
that referenced
this pull request
Nov 8, 2023
This command: $ perf record -e cycles:k -e instructions:k -c 10000 -m 64M dd if=/dev/zero of=/dev/null count=1000 gives rise to this kernel warning: [ 444.364395] WARNING: CPU: 0 PID: 104 at kernel/smp.c:775 smp_call_function_many_cond+0x42c/0x436 [ 444.364515] Modules linked in: [ 444.364657] CPU: 0 PID: 104 Comm: perf-exec Not tainted 6.6.0-rc6-00051-g391df82e8ec3-dirty torvalds#73 [ 444.364771] Hardware name: riscv-virtio,qemu (DT) [ 444.364868] epc : smp_call_function_many_cond+0x42c/0x436 [ 444.364917] ra : on_each_cpu_cond_mask+0x20/0x32 [ 444.364948] epc : ffffffff8009f9e0 ra : ffffffff8009fa5a sp : ff20000000003800 [ 444.364966] gp : ffffffff81500aa0 tp : ff60000002b83000 t0 : ff200000000038c0 [ 444.364982] t1 : ffffffff815021f0 t2 : 000000000000001f s0 : ff200000000038b0 [ 444.364998] s1 : ff60000002c54d98 a0 : ff60000002a73940 a1 : 0000000000000000 [ 444.365013] a2 : 0000000000000000 a3 : 0000000000000003 a4 : 0000000000000100 [ 444.365029] a5 : 0000000000010100 a6 : 0000000000f00000 a7 : 0000000000000000 [ 444.365044] s2 : 0000000000000000 s3 : ffffffffffffffff s4 : ff60000002c54d98 [ 444.365060] s5 : ffffffff81539610 s6 : ffffffff80c20c48 s7 : 0000000000000000 [ 444.365075] s8 : 0000000000000000 s9 : 0000000000000001 s10: 0000000000000001 [ 444.365090] s11: ffffffff80099394 t3 : 0000000000000003 t4 : 00000000eac0c6e6 [ 444.365104] t5 : 0000000400000000 t6 : ff60000002e010d0 [ 444.365120] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [ 444.365226] [<ffffffff8009f9e0>] smp_call_function_many_cond+0x42c/0x436 [ 444.365295] [<ffffffff8009fa5a>] on_each_cpu_cond_mask+0x20/0x32 [ 444.365311] [<ffffffff806e90dc>] pmu_sbi_ctr_start+0x7a/0xaa [ 444.365327] [<ffffffff806e880c>] riscv_pmu_start+0x48/0x66 [ 444.365339] [<ffffffff8012111a>] perf_adjust_freq_unthr_context+0x196/0x1ac [ 444.365356] [<ffffffff801237aa>] perf_event_task_tick+0x78/0x8c [ 444.365368] [<ffffffff8003faf4>] scheduler_tick+0xe6/0x25e [ 444.365383] [<ffffffff8008a042>] update_process_times+0x80/0x96 [ 444.365398] [<ffffffff800991ec>] tick_sched_handle+0x26/0x52 [ 444.365410] [<ffffffff800993e4>] tick_sched_timer+0x50/0x98 [ 444.365422] [<ffffffff8008a6aa>] __hrtimer_run_queues+0x126/0x18a [ 444.365433] [<ffffffff8008b350>] hrtimer_interrupt+0xce/0x1da [ 444.365444] [<ffffffff806cdc60>] riscv_timer_interrupt+0x30/0x3a [ 444.365457] [<ffffffff8006afa6>] handle_percpu_devid_irq+0x80/0x114 [ 444.365470] [<ffffffff80065b82>] generic_handle_domain_irq+0x1c/0x2a [ 444.365483] [<ffffffff8045faec>] riscv_intc_irq+0x2e/0x46 [ 444.365497] [<ffffffff808a9c62>] handle_riscv_irq+0x4a/0x74 [ 444.365521] [<ffffffff808aa760>] do_irq+0x7c/0x7e [ 444.365796] ---[ end trace 0000000000000000 ]--- That's because the fix in commit 3fec323 ("drivers: perf: Fix panic in riscv SBI mmap support") was wrong since there is no need to broadcast to other cpus when starting a counter, that's only needed in mmap when the counters could have already been started on other cpus, so simply remove this broadcast. Fixes: 3fec323 ("drivers: perf: Fix panic in riscv SBI mmap support") Signed-off-by: Alexandre Ghiti <[email protected]> Tested-by: Clément Léger <[email protected]> Tested-by: Yu Chien Peter Lin <[email protected]>
roxell
pushed a commit
to roxell/linux
that referenced
this pull request
Nov 10, 2023
This command: $ perf record -e cycles:k -e instructions:k -c 10000 -m 64M dd if=/dev/zero of=/dev/null count=1000 gives rise to this kernel warning: [ 444.364395] WARNING: CPU: 0 PID: 104 at kernel/smp.c:775 smp_call_function_many_cond+0x42c/0x436 [ 444.364515] Modules linked in: [ 444.364657] CPU: 0 PID: 104 Comm: perf-exec Not tainted 6.6.0-rc6-00051-g391df82e8ec3-dirty torvalds#73 [ 444.364771] Hardware name: riscv-virtio,qemu (DT) [ 444.364868] epc : smp_call_function_many_cond+0x42c/0x436 [ 444.364917] ra : on_each_cpu_cond_mask+0x20/0x32 [ 444.364948] epc : ffffffff8009f9e0 ra : ffffffff8009fa5a sp : ff20000000003800 [ 444.364966] gp : ffffffff81500aa0 tp : ff60000002b83000 t0 : ff200000000038c0 [ 444.364982] t1 : ffffffff815021f0 t2 : 000000000000001f s0 : ff200000000038b0 [ 444.364998] s1 : ff60000002c54d98 a0 : ff60000002a73940 a1 : 0000000000000000 [ 444.365013] a2 : 0000000000000000 a3 : 0000000000000003 a4 : 0000000000000100 [ 444.365029] a5 : 0000000000010100 a6 : 0000000000f00000 a7 : 0000000000000000 [ 444.365044] s2 : 0000000000000000 s3 : ffffffffffffffff s4 : ff60000002c54d98 [ 444.365060] s5 : ffffffff81539610 s6 : ffffffff80c20c48 s7 : 0000000000000000 [ 444.365075] s8 : 0000000000000000 s9 : 0000000000000001 s10: 0000000000000001 [ 444.365090] s11: ffffffff80099394 t3 : 0000000000000003 t4 : 00000000eac0c6e6 [ 444.365104] t5 : 0000000400000000 t6 : ff60000002e010d0 [ 444.365120] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [ 444.365226] [<ffffffff8009f9e0>] smp_call_function_many_cond+0x42c/0x436 [ 444.365295] [<ffffffff8009fa5a>] on_each_cpu_cond_mask+0x20/0x32 [ 444.365311] [<ffffffff806e90dc>] pmu_sbi_ctr_start+0x7a/0xaa [ 444.365327] [<ffffffff806e880c>] riscv_pmu_start+0x48/0x66 [ 444.365339] [<ffffffff8012111a>] perf_adjust_freq_unthr_context+0x196/0x1ac [ 444.365356] [<ffffffff801237aa>] perf_event_task_tick+0x78/0x8c [ 444.365368] [<ffffffff8003faf4>] scheduler_tick+0xe6/0x25e [ 444.365383] [<ffffffff8008a042>] update_process_times+0x80/0x96 [ 444.365398] [<ffffffff800991ec>] tick_sched_handle+0x26/0x52 [ 444.365410] [<ffffffff800993e4>] tick_sched_timer+0x50/0x98 [ 444.365422] [<ffffffff8008a6aa>] __hrtimer_run_queues+0x126/0x18a [ 444.365433] [<ffffffff8008b350>] hrtimer_interrupt+0xce/0x1da [ 444.365444] [<ffffffff806cdc60>] riscv_timer_interrupt+0x30/0x3a [ 444.365457] [<ffffffff8006afa6>] handle_percpu_devid_irq+0x80/0x114 [ 444.365470] [<ffffffff80065b82>] generic_handle_domain_irq+0x1c/0x2a [ 444.365483] [<ffffffff8045faec>] riscv_intc_irq+0x2e/0x46 [ 444.365497] [<ffffffff808a9c62>] handle_riscv_irq+0x4a/0x74 [ 444.365521] [<ffffffff808aa760>] do_irq+0x7c/0x7e [ 444.365796] ---[ end trace 0000000000000000 ]--- That's because the fix in commit 3fec323 ("drivers: perf: Fix panic in riscv SBI mmap support") was wrong since there is no need to broadcast to other cpus when starting a counter, that's only needed in mmap when the counters could have already been started on other cpus, so simply remove this broadcast. Fixes: 3fec323 ("drivers: perf: Fix panic in riscv SBI mmap support") Signed-off-by: Alexandre Ghiti <[email protected]> Tested-by: Clément Léger <[email protected]> Tested-by: Yu Chien Peter Lin <[email protected]> Tested-by: Lad Prabhakar <[email protected]> #On Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
Kaz205
pushed a commit
to Kaz205/linux
that referenced
this pull request
Nov 19, 2023
[ Upstream commit 61e3d99 ] This command: $ perf record -e cycles:k -e instructions:k -c 10000 -m 64M dd if=/dev/zero of=/dev/null count=1000 gives rise to this kernel warning: [ 444.364395] WARNING: CPU: 0 PID: 104 at kernel/smp.c:775 smp_call_function_many_cond+0x42c/0x436 [ 444.364515] Modules linked in: [ 444.364657] CPU: 0 PID: 104 Comm: perf-exec Not tainted 6.6.0-rc6-00051-g391df82e8ec3-dirty torvalds#73 [ 444.364771] Hardware name: riscv-virtio,qemu (DT) [ 444.364868] epc : smp_call_function_many_cond+0x42c/0x436 [ 444.364917] ra : on_each_cpu_cond_mask+0x20/0x32 [ 444.364948] epc : ffffffff8009f9e0 ra : ffffffff8009fa5a sp : ff20000000003800 [ 444.364966] gp : ffffffff81500aa0 tp : ff60000002b83000 t0 : ff200000000038c0 [ 444.364982] t1 : ffffffff815021f0 t2 : 000000000000001f s0 : ff200000000038b0 [ 444.364998] s1 : ff60000002c54d98 a0 : ff60000002a73940 a1 : 0000000000000000 [ 444.365013] a2 : 0000000000000000 a3 : 0000000000000003 a4 : 0000000000000100 [ 444.365029] a5 : 0000000000010100 a6 : 0000000000f00000 a7 : 0000000000000000 [ 444.365044] s2 : 0000000000000000 s3 : ffffffffffffffff s4 : ff60000002c54d98 [ 444.365060] s5 : ffffffff81539610 s6 : ffffffff80c20c48 s7 : 0000000000000000 [ 444.365075] s8 : 0000000000000000 s9 : 0000000000000001 s10: 0000000000000001 [ 444.365090] s11: ffffffff80099394 t3 : 0000000000000003 t4 : 00000000eac0c6e6 [ 444.365104] t5 : 0000000400000000 t6 : ff60000002e010d0 [ 444.365120] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [ 444.365226] [<ffffffff8009f9e0>] smp_call_function_many_cond+0x42c/0x436 [ 444.365295] [<ffffffff8009fa5a>] on_each_cpu_cond_mask+0x20/0x32 [ 444.365311] [<ffffffff806e90dc>] pmu_sbi_ctr_start+0x7a/0xaa [ 444.365327] [<ffffffff806e880c>] riscv_pmu_start+0x48/0x66 [ 444.365339] [<ffffffff8012111a>] perf_adjust_freq_unthr_context+0x196/0x1ac [ 444.365356] [<ffffffff801237aa>] perf_event_task_tick+0x78/0x8c [ 444.365368] [<ffffffff8003faf4>] scheduler_tick+0xe6/0x25e [ 444.365383] [<ffffffff8008a042>] update_process_times+0x80/0x96 [ 444.365398] [<ffffffff800991ec>] tick_sched_handle+0x26/0x52 [ 444.365410] [<ffffffff800993e4>] tick_sched_timer+0x50/0x98 [ 444.365422] [<ffffffff8008a6aa>] __hrtimer_run_queues+0x126/0x18a [ 444.365433] [<ffffffff8008b350>] hrtimer_interrupt+0xce/0x1da [ 444.365444] [<ffffffff806cdc60>] riscv_timer_interrupt+0x30/0x3a [ 444.365457] [<ffffffff8006afa6>] handle_percpu_devid_irq+0x80/0x114 [ 444.365470] [<ffffffff80065b82>] generic_handle_domain_irq+0x1c/0x2a [ 444.365483] [<ffffffff8045faec>] riscv_intc_irq+0x2e/0x46 [ 444.365497] [<ffffffff808a9c62>] handle_riscv_irq+0x4a/0x74 [ 444.365521] [<ffffffff808aa760>] do_irq+0x7c/0x7e [ 444.365796] ---[ end trace 0000000000000000 ]--- That's because the fix in commit 3fec323 ("drivers: perf: Fix panic in riscv SBI mmap support") was wrong since there is no need to broadcast to other cpus when starting a counter, that's only needed in mmap when the counters could have already been started on other cpus, so simply remove this broadcast. Fixes: 3fec323 ("drivers: perf: Fix panic in riscv SBI mmap support") Signed-off-by: Alexandre Ghiti <[email protected]> Tested-by: Clément Léger <[email protected]> Tested-by: Yu Chien Peter Lin <[email protected]> Tested-by: Lad Prabhakar <[email protected]> #On Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
intersectRaven
pushed a commit
to intersectRaven/linux
that referenced
this pull request
Nov 20, 2023
[ Upstream commit 61e3d99 ] This command: $ perf record -e cycles:k -e instructions:k -c 10000 -m 64M dd if=/dev/zero of=/dev/null count=1000 gives rise to this kernel warning: [ 444.364395] WARNING: CPU: 0 PID: 104 at kernel/smp.c:775 smp_call_function_many_cond+0x42c/0x436 [ 444.364515] Modules linked in: [ 444.364657] CPU: 0 PID: 104 Comm: perf-exec Not tainted 6.6.0-rc6-00051-g391df82e8ec3-dirty torvalds#73 [ 444.364771] Hardware name: riscv-virtio,qemu (DT) [ 444.364868] epc : smp_call_function_many_cond+0x42c/0x436 [ 444.364917] ra : on_each_cpu_cond_mask+0x20/0x32 [ 444.364948] epc : ffffffff8009f9e0 ra : ffffffff8009fa5a sp : ff20000000003800 [ 444.364966] gp : ffffffff81500aa0 tp : ff60000002b83000 t0 : ff200000000038c0 [ 444.364982] t1 : ffffffff815021f0 t2 : 000000000000001f s0 : ff200000000038b0 [ 444.364998] s1 : ff60000002c54d98 a0 : ff60000002a73940 a1 : 0000000000000000 [ 444.365013] a2 : 0000000000000000 a3 : 0000000000000003 a4 : 0000000000000100 [ 444.365029] a5 : 0000000000010100 a6 : 0000000000f00000 a7 : 0000000000000000 [ 444.365044] s2 : 0000000000000000 s3 : ffffffffffffffff s4 : ff60000002c54d98 [ 444.365060] s5 : ffffffff81539610 s6 : ffffffff80c20c48 s7 : 0000000000000000 [ 444.365075] s8 : 0000000000000000 s9 : 0000000000000001 s10: 0000000000000001 [ 444.365090] s11: ffffffff80099394 t3 : 0000000000000003 t4 : 00000000eac0c6e6 [ 444.365104] t5 : 0000000400000000 t6 : ff60000002e010d0 [ 444.365120] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [ 444.365226] [<ffffffff8009f9e0>] smp_call_function_many_cond+0x42c/0x436 [ 444.365295] [<ffffffff8009fa5a>] on_each_cpu_cond_mask+0x20/0x32 [ 444.365311] [<ffffffff806e90dc>] pmu_sbi_ctr_start+0x7a/0xaa [ 444.365327] [<ffffffff806e880c>] riscv_pmu_start+0x48/0x66 [ 444.365339] [<ffffffff8012111a>] perf_adjust_freq_unthr_context+0x196/0x1ac [ 444.365356] [<ffffffff801237aa>] perf_event_task_tick+0x78/0x8c [ 444.365368] [<ffffffff8003faf4>] scheduler_tick+0xe6/0x25e [ 444.365383] [<ffffffff8008a042>] update_process_times+0x80/0x96 [ 444.365398] [<ffffffff800991ec>] tick_sched_handle+0x26/0x52 [ 444.365410] [<ffffffff800993e4>] tick_sched_timer+0x50/0x98 [ 444.365422] [<ffffffff8008a6aa>] __hrtimer_run_queues+0x126/0x18a [ 444.365433] [<ffffffff8008b350>] hrtimer_interrupt+0xce/0x1da [ 444.365444] [<ffffffff806cdc60>] riscv_timer_interrupt+0x30/0x3a [ 444.365457] [<ffffffff8006afa6>] handle_percpu_devid_irq+0x80/0x114 [ 444.365470] [<ffffffff80065b82>] generic_handle_domain_irq+0x1c/0x2a [ 444.365483] [<ffffffff8045faec>] riscv_intc_irq+0x2e/0x46 [ 444.365497] [<ffffffff808a9c62>] handle_riscv_irq+0x4a/0x74 [ 444.365521] [<ffffffff808aa760>] do_irq+0x7c/0x7e [ 444.365796] ---[ end trace 0000000000000000 ]--- That's because the fix in commit 3fec323 ("drivers: perf: Fix panic in riscv SBI mmap support") was wrong since there is no need to broadcast to other cpus when starting a counter, that's only needed in mmap when the counters could have already been started on other cpus, so simply remove this broadcast. Fixes: 3fec323 ("drivers: perf: Fix panic in riscv SBI mmap support") Signed-off-by: Alexandre Ghiti <[email protected]> Tested-by: Clément Léger <[email protected]> Tested-by: Yu Chien Peter Lin <[email protected]> Tested-by: Lad Prabhakar <[email protected]> #On Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
logic10492
pushed a commit
to logic10492/linux-amd-zen2
that referenced
this pull request
Jan 18, 2024
Fix sched_ext crashes on v6.6
gyroninja
added a commit
to gyroninja/linux
that referenced
this pull request
Jan 28, 2024
KSAN calls into rcu code which then triggers a write that reenters into KSAN getting the system stuck doing infinite recursion. #0 kmsan_get_context () at mm/kmsan/kmsan.h:106 #1 __msan_get_context_state () at mm/kmsan/instrumentation.c:331 #2 0xffffffff81495671 in get_current () at ./arch/x86/include/asm/current.h:42 #3 rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 #4 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 #5 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#6 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#7 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#8 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#9 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#10 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#11 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#12 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#13 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#14 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#15 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#16 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#17 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#18 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#19 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#20 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#21 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#22 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#23 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#24 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#25 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#26 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#27 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#28 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#29 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#30 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#31 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#32 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#33 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#34 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#35 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#36 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#37 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#38 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#39 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#40 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#41 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#42 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#43 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#44 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#45 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#46 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#47 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#48 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#49 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#50 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#51 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 #52 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 #53 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#54 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#55 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#56 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#57 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 #58 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#59 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#60 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#61 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#62 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#63 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#64 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#65 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#66 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#67 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#68 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#69 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 #70 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#71 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#72 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#73 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#74 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#75 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#76 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#77 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff86203c90) at ./arch/x86/include/asm/kmsan.h:82 torvalds#78 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff86203c90) at mm/kmsan/shadow.c:75 torvalds#79 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff86203c90, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#80 kmsan_get_shadow_origin_ptr (address=0xffffffff86203c90, size=8, store=false) at mm/kmsan/shadow.c:97 torvalds#81 0xffffffff81b1dc72 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=8, store=false) at mm/kmsan/instrumentation.c:36 torvalds#82 __msan_metadata_ptr_for_load_8 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:92 torvalds#83 0xffffffff814fdb9e in filter_irq_stacks (entries=<optimized out>, nr_entries=4) at kernel/stacktrace.c:397 torvalds#84 0xffffffff829520e8 in stack_depot_save_flags (entries=0xffffffff8620d974 <init_task+1012>, nr_entries=4, alloc_flags=0, depot_flags=0) at lib/stackdepot.c:500 torvalds#85 0xffffffff81b1e560 in __msan_poison_alloca (address=0xffffffff86203da0, size=24, descr=<optimized out>) at mm/kmsan/instrumentation.c:285 torvalds#86 0xffffffff8562821c in _printk (fmt=0xffffffff85f191a5 "\0016Attempting lock1") at kernel/printk/printk.c:2324 torvalds#87 0xffffffff81942aa2 in kmem_cache_create_usercopy (name=0xffffffff85f18903 "mm_struct", size=1296, align=0, flags=270336, useroffset=<optimized out>, usersize=<optimized out>, ctor=0x0 <fixed_percpu_data>) at mm/slab_common.c:296 torvalds#88 0xffffffff86f337a0 in mm_cache_init () at kernel/fork.c:3262 torvalds#89 0xffffffff86eacb8e in start_kernel () at init/main.c:932 torvalds#90 0xffffffff86ecdf94 in x86_64_start_reservations (real_mode_data=0x140e0 <exception_stacks+28896> <error: Cannot access memory at address 0x140e0>) at arch/x86/kernel/head64.c:555 torvalds#91 0xffffffff86ecde9b in x86_64_start_kernel (real_mode_data=0x140e0 <exception_stacks+28896> <error: Cannot access memory at address 0x140e0>) at arch/x86/kernel/head64.c:536 torvalds#92 0xffffffff810001d3 in secondary_startup_64 () at /pool/workspace/linux/arch/x86/kernel/head_64.S:461 torvalds#93 0x0000000000000000 in ??
gyroninja
added a commit
to gyroninja/linux
that referenced
this pull request
Jan 28, 2024
As of 5ec8e8e(mm/sparsemem: fix race in accessing memory_section->usage) KMSAN now calls into RCU tree code during kmsan_get_metadata. This will trigger a write that will reenter into KMSAN getting the system stuck doing infinite recursion. #0 kmsan_get_context () at mm/kmsan/kmsan.h:106 #1 __msan_get_context_state () at mm/kmsan/instrumentation.c:331 #2 0xffffffff81495671 in get_current () at ./arch/x86/include/asm/current.h:42 #3 rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 #4 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 #5 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#6 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#7 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#8 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#9 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#10 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#11 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#12 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#13 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#14 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#15 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#16 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#17 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#18 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#19 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#20 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#21 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#22 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#23 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#24 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#25 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#26 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#27 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#28 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#29 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#30 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#31 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#32 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#33 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#34 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#35 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#36 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#37 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#38 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#39 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#40 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#41 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#42 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#43 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#44 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#45 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#46 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#47 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#48 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#49 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#50 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#51 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 #52 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 #53 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#54 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#55 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#56 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#57 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 #58 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#59 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#60 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#61 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#62 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#63 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#64 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#65 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#66 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#67 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task+1012>) at ./arch/x86/include/asm/kmsan.h:82 torvalds#68 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/shadow.c:75 torvalds#69 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task+1012>, is_origin=false) at mm/kmsan/shadow.c:143 #70 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/shadow.c:97 torvalds#71 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36 torvalds#72 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:91 torvalds#73 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379 torvalds#74 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402 torvalds#75 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748 torvalds#76 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016 torvalds#77 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff86203c90) at ./arch/x86/include/asm/kmsan.h:82 torvalds#78 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff86203c90) at mm/kmsan/shadow.c:75 torvalds#79 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff86203c90, is_origin=false) at mm/kmsan/shadow.c:143 torvalds#80 kmsan_get_shadow_origin_ptr (address=0xffffffff86203c90, size=8, store=false) at mm/kmsan/shadow.c:97 torvalds#81 0xffffffff81b1dc72 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task+1012>, size=8, store=false) at mm/kmsan/instrumentation.c:36 torvalds#82 __msan_metadata_ptr_for_load_8 (addr=0xffffffff8620d974 <init_task+1012>) at mm/kmsan/instrumentation.c:92 torvalds#83 0xffffffff814fdb9e in filter_irq_stacks (entries=<optimized out>, nr_entries=4) at kernel/stacktrace.c:397 torvalds#84 0xffffffff829520e8 in stack_depot_save_flags (entries=0xffffffff8620d974 <init_task+1012>, nr_entries=4, alloc_flags=0, depot_flags=0) at lib/stackdepot.c:500 torvalds#85 0xffffffff81b1e560 in __msan_poison_alloca (address=0xffffffff86203da0, size=24, descr=<optimized out>) at mm/kmsan/instrumentation.c:285 torvalds#86 0xffffffff8562821c in _printk (fmt=0xffffffff85f191a5 "\0016Attempting lock1") at kernel/printk/printk.c:2324 torvalds#87 0xffffffff81942aa2 in kmem_cache_create_usercopy (name=0xffffffff85f18903 "mm_struct", size=1296, align=0, flags=270336, useroffset=<optimized out>, usersize=<optimized out>, ctor=0x0 <fixed_percpu_data>) at mm/slab_common.c:296 torvalds#88 0xffffffff86f337a0 in mm_cache_init () at kernel/fork.c:3262 torvalds#89 0xffffffff86eacb8e in start_kernel () at init/main.c:932 torvalds#90 0xffffffff86ecdf94 in x86_64_start_reservations (real_mode_data=0x140e0 <exception_stacks+28896> <error: Cannot access memory at address 0x140e0>) at arch/x86/kernel/head64.c:555 torvalds#91 0xffffffff86ecde9b in x86_64_start_kernel (real_mode_data=0x140e0 <exception_stacks+28896> <error: Cannot access memory at address 0x140e0>) at arch/x86/kernel/head64.c:536 torvalds#92 0xffffffff810001d3 in secondary_startup_64 () at /pool/workspace/linux/arch/x86/kernel/head_64.S:461 torvalds#93 0x0000000000000000 in ??
RevySR
pushed a commit
to RevySR/linux
that referenced
this pull request
Feb 23, 2024
This command: $ perf record -e cycles:k -e instructions:k -c 10000 -m 64M dd if=/dev/zero of=/dev/null count=1000 gives rise to this kernel warning: [ 444.364395] WARNING: CPU: 0 PID: 104 at kernel/smp.c:775 smp_call_function_many_cond+0x42c/0x436 [ 444.364515] Modules linked in: [ 444.364657] CPU: 0 PID: 104 Comm: perf-exec Not tainted 6.6.0-rc6-00051-g391df82e8ec3-dirty torvalds#73 [ 444.364771] Hardware name: riscv-virtio,qemu (DT) [ 444.364868] epc : smp_call_function_many_cond+0x42c/0x436 [ 444.364917] ra : on_each_cpu_cond_mask+0x20/0x32 [ 444.364948] epc : ffffffff8009f9e0 ra : ffffffff8009fa5a sp : ff20000000003800 [ 444.364966] gp : ffffffff81500aa0 tp : ff60000002b83000 t0 : ff200000000038c0 [ 444.364982] t1 : ffffffff815021f0 t2 : 000000000000001f s0 : ff200000000038b0 [ 444.364998] s1 : ff60000002c54d98 a0 : ff60000002a73940 a1 : 0000000000000000 [ 444.365013] a2 : 0000000000000000 a3 : 0000000000000003 a4 : 0000000000000100 [ 444.365029] a5 : 0000000000010100 a6 : 0000000000f00000 a7 : 0000000000000000 [ 444.365044] s2 : 0000000000000000 s3 : ffffffffffffffff s4 : ff60000002c54d98 [ 444.365060] s5 : ffffffff81539610 s6 : ffffffff80c20c48 s7 : 0000000000000000 [ 444.365075] s8 : 0000000000000000 s9 : 0000000000000001 s10: 0000000000000001 [ 444.365090] s11: ffffffff80099394 t3 : 0000000000000003 t4 : 00000000eac0c6e6 [ 444.365104] t5 : 0000000400000000 t6 : ff60000002e010d0 [ 444.365120] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [ 444.365226] [<ffffffff8009f9e0>] smp_call_function_many_cond+0x42c/0x436 [ 444.365295] [<ffffffff8009fa5a>] on_each_cpu_cond_mask+0x20/0x32 [ 444.365311] [<ffffffff806e90dc>] pmu_sbi_ctr_start+0x7a/0xaa [ 444.365327] [<ffffffff806e880c>] riscv_pmu_start+0x48/0x66 [ 444.365339] [<ffffffff8012111a>] perf_adjust_freq_unthr_context+0x196/0x1ac [ 444.365356] [<ffffffff801237aa>] perf_event_task_tick+0x78/0x8c [ 444.365368] [<ffffffff8003faf4>] scheduler_tick+0xe6/0x25e [ 444.365383] [<ffffffff8008a042>] update_process_times+0x80/0x96 [ 444.365398] [<ffffffff800991ec>] tick_sched_handle+0x26/0x52 [ 444.365410] [<ffffffff800993e4>] tick_sched_timer+0x50/0x98 [ 444.365422] [<ffffffff8008a6aa>] __hrtimer_run_queues+0x126/0x18a [ 444.365433] [<ffffffff8008b350>] hrtimer_interrupt+0xce/0x1da [ 444.365444] [<ffffffff806cdc60>] riscv_timer_interrupt+0x30/0x3a [ 444.365457] [<ffffffff8006afa6>] handle_percpu_devid_irq+0x80/0x114 [ 444.365470] [<ffffffff80065b82>] generic_handle_domain_irq+0x1c/0x2a [ 444.365483] [<ffffffff8045faec>] riscv_intc_irq+0x2e/0x46 [ 444.365497] [<ffffffff808a9c62>] handle_riscv_irq+0x4a/0x74 [ 444.365521] [<ffffffff808aa760>] do_irq+0x7c/0x7e [ 444.365796] ---[ end trace 0000000000000000 ]--- That's because the fix in commit 3fec323 ("drivers: perf: Fix panic in riscv SBI mmap support") was wrong since there is no need to broadcast to other cpus when starting a counter, that's only needed in mmap when the counters could have already been started on other cpus, so simply remove this broadcast. Fixes: 3fec323 ("drivers: perf: Fix panic in riscv SBI mmap support") Signed-off-by: Alexandre Ghiti <[email protected]> Tested-by: Clément Léger <[email protected]> Tested-by: Yu Chien Peter Lin <[email protected]> Tested-by: Lad Prabhakar <[email protected]> #On Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fixed a typo in .gitignore